Copyright (c) 2008 NISO
|Summary||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.|
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.
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.
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.
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.
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.
|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.|
Following the release of the revised draft specification, next steps included a second round of discussion with potential implementers to discuss the recommendations in some detail to identify problems, set priorities, gauge interest, and work toward initial implementations.
The DLF called a second meeting, again on the UC Berkeley campus, on August 7, 2008, including Task Group members and the developer community. Developers represented at this meeting included SirsiDynix, Ex Libris, VUFind (Villanova University), the eXtensible Catalog (University of Rochester), Innovative Interfaces, Talis, OCLC, LibLime, Polaris Library Systems, and BiblioCommons.
The primary agenda for the meeting involved focusing on the Level 1 functions, or the ILS Basic Discovery Interface. Success established at this basic level will provide a foundation for extending the API through the additional recommended functions.
Through the course of the day, participants worked through the four functions that comprise the BDI.
The function of harvesting data from the ILS to be ingested into a discovery interface relies on OAI-PMH. Some of the issues of OAI-PMH relative to the BDI involve the format of the records, how to deal with deleted records, and details related to harvest intervals. Participants agreed that Dublin Core would stand as the minimal level record, but MARC-XML would be highly recommended for systems that support MARC. Deleted records present complications because ILSís have a variety of approaches in dealing with items that have been withdrawn from the collection. The group agreed that if the item was no longer available for discovery thenit should be presented on an OAI-PMH response as a deleted record. A full harvest involves an OAI-PMH request with no data parameter. Incremental harvest involve providing the date option, indicating the interval desired. Deleted records must be provided for both full and incremental harvests.
This function addresses the need to provide additional information to a discovery interface beyond the basic bibliographic record. These expanded records would provide information such as holdings associated with each record. The components of this response would include the bibliographic identifier, the bibliographic record, and the associated MARC holdings records. Other item-specific elements that should be returned include the location, call number, format, availability, barcode identifier, and other housekeeping data maintained by the ILS. Discovery Systems in need of this item-level information might choose to use HarvestExpandedRecords instead of HarvestBibliographicRecords.
This function allows a discovery system to query the ILS regarding the real-time status of a title or item. In addition to the basic availability information already specified, participants agreed it would be useful to add location as text strings as an optional response element. Options apply for either title or item level availability. For a title-level request, the response will include the availability messages of each of the associated items.
At Level 1, expected functionality involves a hand-off back to the LS OPAC for user functions such as placing a hold or recall. This function requires documenting and supporting a template for a persistent URL that will invoke a page that provides a set of services for the item specified.
The discussions of the August meeting resulted in the need for some, though fairly minor, revisions in the recommendations for the Level 1 Basic Discovery Interface API. The Task Group will be reconvened to produce these revisions. Developers were highly encouraged to proceed with implementations. Developers identified tools needed for implementations such as a reference implementation and validation tools. Ideally, a set of service descriptions in WSDL (Web Services Description Language) would be produced to fully document the API. Talis volunteered to work on a validation tool for the XML schemas involved in the API. Developers were encouraged to proceed with at least experimental implementations, with the DLF Fall Forum on November 12, 2008 as the next opportunity for developers to demonstrate components and projects that support some aspect of the ILS-Discovery Interface APIs.
|Type of Material:||Article|
Information Standards Quarterly|
|18 - 19|
|Marshall Breeding is the Director for Innovative Technology and Research for the Vanderbilt University Library and the creator of Library Technology Guides (www.librarytechnology.org). Breeding participated in both meetings described in this report.|
|Last Update:||2012-12-29 14:06:47|
|Date Created:||2008-08-19 15:48:03|