As Peter Brantley, executive director of the Digital Library Federation, announced last week, we have an agreement with many of the developers and vendors of integrated library systems and discovery applications to support a basic set of functions to allow ILS’s and discovery applications to interoperate. (I’ve written about this effort previously here and here.)

This basic set is a subset (what we’re calling “Basic Discovery Interfaces” or “level 1”) of the full set of functions we will be recommending, and we still have to specify some of the details about how the Level 1 functions will be invoked by discovery applications. But it’s a very important first step. The functions it includes should enable an interesting array of discovery applications to work with a variety of ILS’s. And I hope that our work will result in some useful implementations soon, and help encourage further interoperability and standards to develop, based on our recommendations.

The functions, in summary, are

• Harvesting bibliographic and, when requested, expanded records from an ILS, in full or incrementally. (Expanded records also include information on holdings, availability, and other data relevant to discovery not in the bibliographic record proper.) This allows independent search indexes to be made for a library’s cataloged content. The recommended technology (or “binding”) will involve OAI-PMH. (Someone asked whether this would just export Dublin Core, the only metadata format OAI-PMH requires. Our answer: it’s supposed to include, at minimum, all the data in the bibliographic record that’s relevant for discovery. So for an ILS with MARC records, for instance, simple unqualified Dublin Core would not suffice, but MARC-XML records using a suitable XML schema like marc21 could.) [Editor note: this paragraph was changed 17 April, after re-reading Peter’s announcement]
• Querying for availability of items in real time. This allows users to see if they can obtain information they’ve discovered in the library’s collection. Our recommended binding will involve a simple REST interface, with a URL request and a simple, expandable XML reply. (There are other ways of querying availability, including through NCIP, but given how difficult it’s been to get full implementations of NCIP, we want to make the basic required functionality as simple as possible. There’s been some discussion of what would be desirable on the ILS-DI Google group, which is open to the public.)
• Linking back to any item in the OPAC, in a stable way, so that users can make requests on the item using the native OPAC/ILS interface interface if desired. We plan to allow ILS’s to declare a URL template, which would include the appropriate bibliographic or item identifier from the harvested records, for links back to the item. (Someone asked whether an OpenURL should be used here. It could be used, and we’d love to see an OpenURL-based suggested template. The basic functionality required here, however, doesn’t need the sophisticated features of the OpenURL, so while OpenURLs could well be a particularly useful way to formulate both this simple linkback and more sophisticated, detailed OPAC linkback requests, we don’t plan to require OpenURL at Level 1.)

We’ll be releasing a new draft with more detail on the Level 1 functions within the next week, in time for people to read it before the next DLF Forum in Minneapolis, where we’ll be having a Birds of a Feather session to talk about implementing and building on our recommendations. I’m also hoping to have a sample implementation of the Level 1 functions very soon for The Online Books Page, and have implemented some of the functions already. (The OBP is not an ILS, but like an ILS, it manages bibliographic records and mediates access to texts; and the functions we specify in Level 1 can also be useful for interoperating with the Online Books Page collection.) I hope to see other implementations for ILS’s and other systems before long.

We’re hoping that this pre-Forum draft release can be the last full release before the official recommendation is released later this spring, to give folks the opportunity to point out any errors, ambiguities, or confusing aspects of what we recommend and specify. We hope to make any necessary corrections in short order, release the final recommendation, and then go sit on the beach and drink tequilas implement these functions, build cool new discovery applications, and help develop a community for using ILS data and services in productive and innovative ways.

I’m excited about what lies ahead, and if you are as well, I hope you’ll be a part of that community.