Separating the discovery layer from the ILS
From LLN
Separating the discovery layer from the ILS
Originally appeared in slightly different form as a March 14, 2008 post on PALINET discovery tools
by John Houser, published March 17, 2008
At the recent Code4Lib Conference in Portland and the VALE Next Generation Academic Library System Symposium at The College of New Jersey, I was involved in a series of conversations with colleagues about the open source discovery tools, the new OCLC Grid Services WorldCat API and the roles that library consortia might play in creating better library systems. Reflected in those conversations are two apparently diverging trends that might, in fact, be brought together by new technology.
On the one hand, there are libraries, tired of the limited functionality and restrictions placed upon them by their current ILS [Integrated Library System], creating new, custom, (and often open source) discovery tools on top of their ILS. Their goals include better search interfaces and functionality, integration of digital repositories and other local data, and better integration with existing library and institutional website designs. This would seem to be a trend towards greater customization of library software interfaces.
On the other hand, there is the old but ongoing movement towards consolidation of metadata across many institutions, driven by the desire to increase access to information and the need to reduce costs through resource sharing and economies of scale. OCLC has been working in this arena for years. Also driving this trend is the frustration many librarians feel with the expensive and yet inadequate federated search systems that are currently available. Complaints about federated search options center on performance and lowest common denominator search functionality (due to inconsistent metadata across systems and inconsistent implementation of searching standards and communications protocols). I heard virtually the same blunt comment at both conferences, “Federated search doesn’t work.”
So, on the one hand, we have the desire for a unique interface and integration with local systems and resources, and on the other hand, we have the need to share a common metadata store. How are these trends to be reconciled? One answer is to continue to consolidate metadata in large repositories such as WorldCat but to separate those data repositories’ data stores from their discovery layers and to connect the two with an application programming interface or API. Happily, the folks at OCLC seem to have seen the light. The new WorldCat API promises to allow library software developers to create local discovery systems that integrate local search results with search results from the vast WorldCat store of library metadata and holdings information. David Walker from California State University demonstrated just such a system at Code4Lib.[1] What would make the WorldCat API even more useful is if OCLC were to make available through it metadata harvested from the many public data stores accessible on the network—such as they’ve begun to do with WorldCat Local. The ability to add (for a fee, of course) access to commercial metadata would make the API a better service yet. It’s not clear what OCLC’s plans are in this regard, but if you are an OCLC member and you are engaged in or thinking about creating a new discovery tool for your library, now would be a good time to be talking to OCLC about this new service.
This same approach of formally separating the discovery layer from the data store might be used in a consortium setting. One barrier to the successful implementation of shared systems in large consortia can be the reluctance of larger institutions (or those with significant systems support) to give up local control over their search interface. Might we see a consortium some time soon that offers a shared ILS or union catalog with both a shared discovery tool and a full-featured API that libraries could choose to use in conjunction with their own locally developed discovery tool? Or might we see a consortium that produces only an API to their system? There are various open source projects in active development now that could be enhanced to work in such a system. They include Villanova’s VuFind, The University of Virginia’s Blacklight project and Oregon State University’s LibraryFind. What features would such an API (or set of APIs in the case of a full ILS) have to support in order for such a system to work? Where are additional APIs needed?
The Digital Library Federation (DLF) seems to have set out to answer just those questions. At one of the sessions at Code4Lib, Emily Lynema and Terry Reese discussed a draft report from the DLF ILS Discovery Interface Task Force that attempts to outline, broadly, a set of functional requirements and related standards that would be needed to separate discovery layer from the rest of an ILS. You can add your comments on this draft at their wiki.
Notes
- ↑ I recorded a podcast with Don Hamparian, OCLC Portfolio Manager for the WorldCat API and David Walker while at Code4Lib. Look for it soon in the Technology Conversations series of PALINET Podcasts.
Related articles
- Why look at open source now? - John Houser discusses the significance of open source and why this is a particularly opportune time to consider it.
- Future catalogs: food for thought - Eric Lease Morgan offers a visionary set of future possibilities for the "catalog."
- Innovation notes includes examples of libraries using discovery layers to improve existing catalogs.
- Category:Open source - You'll find a range of related articles on open source listed here.
