Last month's issue of Computers in Libraries carried my "Helping You Buy" feature on electronic resource management (ERM) systems. We looked at some of the main points of what this genre of software aims to accomplish, the workflows involved in electronic resource management, and some of the products currently available. I hope that it provided some practical information on this important genre of software for libraries.
Along that same vein, this month's column considers some of the broader issues at play in the way that libraries manage and provide access to electronic resources versus how they manage their print collections. One of my main concerns as I think about library automation involves how everything fits together into a comprehensive environment. Given the sparse resources typically available in libraries, we need all the efficiencies we can find.
Multiple Formats-Multiple Systems?
As I look at the current state of the art in products available for managing electronic resources, it seems like there's still lots of room for improvement, especially in the areas of integration and interoperability. The products available for managing electronic resources now include a strong set of features to coordinate the information and automate the work related to this type of content. The main problem that I see lies in how to tie in electronic content with the library's broader environment, both in terms of the work performed by staff members behind the scenes and in the way that it is presented to users.
An obvious issue involves the deployment of separate systems to manage electronic and print collections. In academic libraries especially, the typical arrangement involves using the ILS to manage the print collection with electronic content handled by electronic resource management systems and OpenURL link servers. As public libraries become more heavily involved with electronic content, they will soon face similar needs. Is this really the most efficient arrangement? How did we end up with such a bifurcated approach?
I think this problem goes back to the way integrated library systems were originally designed and how they have evolved over time. The ILS emerged during the time when library collections exclusively resided on print or other physical formats. As library collections evolved to include electronic content, the core ILS continued its specialization in print. Some accommodations were made for electronic content, but not to the extent that libraries could rely on them as a comprehensive tool.
The late 1990s saw the beginning of a proliferation of products that specialize in some aspect of managing or providing access to electronic resources. These products were designed to be operated separately from the ILS and could be implemented in libraries regardless of which one they used. This approach led to discrete products for OpenURL linking, federated search, electronic resource management, and new-generation catalogs.
I see this trend toward separate products for these new areas of functionality to be driven by both technical and business concerns. On the technical side, much of what these new applications needed to accomplish did not fit within the existing ILS architecture and data structures. The infrastructure necessary to support these functions was not already in place inside the ILS, and it would be more expedient to create separate products than to extend the existing ILS internal architecture.
In addition to these technical issues, business factors contributed to the provision of tools oriented to electronic content as separate products. The development of software to deliver this functionality involves considerable cost. There's a lot more incentive to package this functionality as a new product that can be licensed separately than to integrate it into existing products. Creating products that operate separately and can be sold to libraries that run any ILS presents a great opportunity to market to libraries running the ILS of competing companies. It's beneficial for a company to get its foot in the door of other libraries. For example, selling a link resolver to a library running a competitor's ILS not only brings in some new revenue but also presents the opportunity to build a relationship with that library to cultivate new sales in the future. Overall, spawning new products represented a far more attractive business strategy than reworking the existing core automation products to handle electronic content.
The arrangement involving separate products for managing print and electronic content results in a more loosely coupled environment, where multiple applications operate independently internally, though they may need to exchange data in areas of functional overlap. User interfaces may need to draw from multiple applications to present a unified representation of the library's print and electronic collections. This loosely coupled architecture for library automation implies a need for standard ways for these systems to communicate with each other, both in terms of data and elements of functionality.
Reliance on separate systems for managing print and electronic content stands as a given in today's library automation environment. At least in the short- to medium-term, libraries will need to deal with this arrangement. Right now, the area of most urgent concern involves rapid development of standards.
Loose Integration Requires More Standards
To sustain a loosely coupled automation environment, there needs to be a robust set of standard protocols for the exchange of data and services among these independent systems. Existing protocols such as Z39.50, SRU/W, NCIP, OpenURL, and OAIPMH play an important role in this automation model. Yet many gaps remain where new standards must be created to allow these systems to function together efficiently.
Some of the initiatives underway to develop new protocols needed for this loosely coupled environment include the following:
- The Cost of Resource Exchange (CORE), organized through the National Information Standards Organization, charged to develop a new standard for the exchange of data elements related to cost, fund, vendor, and invoices. This protocol targets communications among products such as the ILS, the electronic resource management system, payment and procurement systems, and the business systems of subscription agents (www.niso.org/ news/pr/view?item_key=cf864b64c8 5f36c3692178685f719f345d70ccdd).
- The Digital Library Federation formed the ILS Discovery Interfaces task group to develop a set of protocols for the integration of next-generation catalogs with the ILS. The new genre of interfaces needs to be able to extract bibliographic and other types of data from the ILS for the purpose of indexing this content and needs a reliable method to display realtime status of items, as well as ways to deliver patron services. A preliminary set of protocols, called the Berkeley Accord, was released on March 6, 2008, with a follow-up session planned by the task group for Aug. 7, 2008 (http://diglib.org/ architectures/ilsdi).
- EDItEUR is developing an ONIX for Licensing Terms - a standard for describing the terms involved in the licenses that libraries make with publishers. The variability and complexity of these terms present significant challenges for electronic resource management systems. Having a standard approach for describing and exchanging this data will allow a higher degree of automation for the way that electronic resource management systems handle licensing terms (www.editeur.org).
Other protocols will emerge over time. Ultimately, it would be ideal to have a set of protocols that form a comprehensive API (applications programming interface) that would address all of the internal data and functionality components involved across the range of library automation components. Such an ideal seems unlikely to see complete fulfillment in the short-term, though the existing standards plus these new initiatives represent good progress.
Moving Toward Comprehensive Resource Management
Although the current reality of library automation involves separate products for the management of electronic content and the print collections, I see the need to work toward a more comprehensive approach in the way that libraries manage their collections. The proportions of electronic content relative to print will likely continue to increase, though I don't see print collections disappearing from libraries entirely within any foreseeable time frame.
Print and electronic content seem to be becoming more intertwined. The transition of journals from print to electronic has largely played out. We're now seeing some of the same dynamics with books. Many libraries have begun adding ebooks to their collections in large numbers. Mass digitization projects stand to make an enormous impact on the way that libraries deal with their large collections of print monographs.
I'm hoping to see the evolution of library automation tools toward a more comprehensive and integrated approach for managing content, regardless of its format. Especially as electronic content continues to grow, a disjointed approach to the management and access of resources will not serve libraries well.
A more comprehensive resource management environment could take a variety of forms. One path might involve continued evolution of the current product categories but with everstronger points of integration. This approach would require aggressive development of standards, at ever-more granular levels, to allow these separate products to cooperatively form a more coherent system.
I also expect to see some companies rework their separate products into a single comprehensive resource management system. Such a product might result from merging the ILS, ERMs, and link resolver into a unified system. These products have quite a bit of overlapping data and functionality. Reorganizing these functions into a more integrated whole seems to offer one approach to a more efficient environment. Libraries currently carry a fairly heavy burden in managing many separate applications. We don't need more systems to manage, we need systems capable of managing more types of content.
Although this might sound like recreating a large monolithic system, that's not what I have in mind. Rather, a more comprehensive resource management environment should be built on top of the service-oriented architecture, assembled from a set of lightweight components that can be flexibly combined into a higher-level integrated environment.
I also don't rule out the possibility of an entirely new automation environment designed from the ground up to accommodate the realities of today's libraries, with their hybrid collections of electronic content and print materials. This route would take much longer to result in deliverable products so will likely not come in time to solve the immediate needs that libraries face for more efficient automation.
I see the convergence of print and electronic resource management as a fundamental issue. How we face this question will shape the alternatives as library automation products evolve. As electronic resource management becomes a bigger part of what libraries do, I hope that we find ways for this activity to develop into a model of comprehensive resource management.
