NEXT-GENERATION LIBRARY CATALOGS, or discovery interfaces, represent a major trend in library automation. Commercial and open source development of these products abounds. As more libraries become interested in providing interfaces into their collections using applications other than the online catalog module packaged with their integrated library system, improved interoperability is one of the key issues they face.
The current deployments of discovery interfaces largely depend on interactions with the ILS dependent on proprietary interactions with the local ILS requiring considerable expertise and effort. The Digital Library Federation (DLF) aims to foster a more standardized environment where discovery interfaces can work with any given ILS through a uniform set of application programming interfaces.
DLF forms the ILS-DI Work Group
Toward this goal, the DLF charged a workgroup called the Integrated Library System Discovery Interface Task Group, or (ILS-DI) to explore issues and to develop an applications programming interface (API) to address the interoperability issues between these two kinds of systems.
The committee of representatives from DLF partner institutions, chaired by John Mark Ockerbloom (University of Pennsylvania) also includes Terry Reese (Oregon State University), Patricia Martin (California Digital Library), Emily Lynema (North Carolina State University), Todd Grapppone (University of South California), Dave Kennedy (University of Maryland), David Bucknum (Library of Congress), and Dianne McCutcheon (National Library of Medicine).
The ILS Discovery Interface Task Group, initially formed in the summer of 2007, documents its work at www.diglib.org/architectures/ilsdi/. This resource contains the group's official recommendations, example implementations, and a link to a wiki site with supplemental information related to ongoing work.
Assessing Needs and Interest
One phase of the task group's work involved conducting a poll of libraries to assess their current experiences with discovery interfaces and future intentions. The poll revealed that the majority of libraries surveyed are not satisfied with the traditional OPAC and had plans to implement external products, either commercially provided or open source, to enhance the environment experienced by their users. More detailed information on the questions and responses of the survey are available on the Task Group's web site. The task group produced a draft that described the areas of functionality involved in the interactions between discovery interfaces and ILS products and proposing one or more protocols that could serve as bindings. Whenever possible, the committee relied on existing standards or protocols for the bindings. This draft, now superseded, was made available to the broader library and development community for reaction and comment.
The Berkeley Accord
On March 6, 2008, the DLF convened a meeting on the UC Berkeley campus that brought the Task Group together with representatives from organizations involved in developing integrated library systems or discovery interface. The purpose of this group involved discussion of the proposed API and an attempt to reach some level of consensus on what parts of the recommendations could be adopted and implemented.
The development community represented at that meeting included SirsiDynix, Innovative Interfaces, LibLime, Polaris Library Systems, VTLS, Ex Libris, and Talis, BiblioCommons, OCLC, and Medialab Solutions. Of this group, some develop ILS products, others discovery interfaces, and some offer both types of systems.
The discussions of this meeting identified three areas essential for a basic programmatic interface between an ILS and discovery systems. These functions included harvesting, availability, and linking. Harvesting involves the wholesale and incremental export of records from the ILS. The Open Archives Initiative Protocol for Metadata Harvesting (OAI-PMH) addresses this functionality and was proposed as the preferred binding for this function. Availability involves providing a mechanism for a discovery interface to determine the real-time circulation status of an item known to the discovery interface through a harvested record. The proposed binding for availability would be a simple REST interface that returns item status data. Linking provides a stable mechanism for invoking a page for a given item that provides detailed information and any relevant services, such as placing a hold or recall.
This led to the focus on these three functions (harvesting, availability, and linking), with many of the details to be worked out in the future. Each of the developer representatives was polled about their commitment toward supporting these recommendations. Most voted to support the recommendations, though many stipulated qualifications depending on how the details were resolved in the future. Innovative Interfaces abstained with the same basic concern. The general consensus surrounding these functions as the basis for the ILS Basic Discovery Interface, has also been called the Berkeley Accord.
Revised Draft Specification
Following the March 2008 Berkeley meeting, the Task Group prepared a new document representing the recommendations for the interoperability profile. “DLF ILS Discovery Interface Task Group (ILS-DI) Technical Recommendation: An API for effective interoperation between integrated library systems and external discovery applications,” dated June 4, 2008, summarizes the activities of the process to date, presents a new draft of the APIs, and is available through the Task Group's website.
The document takes the approach of multiple levels of the API, starting at the Basic Discovery Interfaces (BDI), or Level 1, that provides the minimal level of functionality for a discovery interface to work with an ILS, and included to levels of record harvesting, realtime availability, and linking. At this level, the discovery interface would rely on the native OPAC of the ILS for many aspects of functionality. Levels 2 through 4 provide protocol support that allows the external discovery interface to take over increasing levels of OPAC functionality. At Level 4, the discovery interface can completely replace the OPAC, including such features for specific library types as managing fines, e-commerce payments, and course reserves.
The revised document included specific functions and bindings that would constitute API's at each of the four levels. Though the number and complexity of the API elements increases for each level, the task group aimed to use existing standards and protocols when possible.
In addition to creating the document, at least one task group member, John Mark Ockerbloom (University of Pennsylvania) has created a prototype reference implementation of the Level 1 API against a database of online books.
Berkeley II: Engaging the Developer Community
| Level | Functionality Goals | Description / Examples |
|---|---|---|
| 1 | Basic discovery interfaces (BDI) | Minimal set of functions necessary to support an external discovery interface. Relies on native OPAC for most enduser services. |
| 2 | Elementary OPAC supplement | Two-way interaction with the ILS OPAC |
| 3 | Elementary OPACalternative | Basic functions needed for the discovery interface to operate without the ILS OPAC for most functions. While it may rely on the ILS OPAC for some advanced features, at this level most users should find the external discovery interface an attractive alternative. |
| 4 | Robust/domain specific discovery platforms | Provides support for the external discovery interface at a level where it can provide all types of searching and patron interaction otherwise handled by the OPAC. This would include types of features specific to some types of libraries, not expected by others, such as advanced holds, fines and payment features for public libraries and course reserves for academic libraries. |
