Computer applications which deal with electronic resource management (ERM) are quite a recent development. They have grown out of the need to manage the burgeoning number of electronic resources particularly electronic journals. Typically, in the early years of e-journal acquisition, library staff provided an easy means of accessing these journals by providing an alphabetical list on a web page. Some went as far as categorising the e-journals by subject and then grouping the journals either on a single web page or by using multiple pages. It didn't take long before it was recognised that it would be more efficient to dynamically generate the pages from a database rather than to continually edit the pages manually. Of course, once the descriptive metadata for an electronic journal was held within a database the next logical step was to provide administrative forms whereby that metadata could be manipulated. This in turn led to demands for incorporating more information and more functionality into the developing application.
Before long, many institutions were devoting resources to developing and maintaining systems which could manage a range of electronic resources, including information regarding abstracting and indexing services as well as electronic journals. In early 2001, Tim Jewell of the University of Washington carried out a survey for the Digital Library Federation (DLF) of such in-house developments in North American universities (Jewell, 2001). This showed that libraries were trying to present and maintain information regarding e-resources, which often focussed on particular subsets of this information but that - as one would expect - there were many common features across the different systems being developed. One of the most well known of these systems is the one developed by MIT called VERA (Virtual Electronic Resource Access).However, these in-house developments were not confined to the US. For example, my own institution in the UK, the University of Bristol has also developed an ERM application, which allows staff to input metadata and users to search and browse titles.
What is interesting, however, is that these applications were developed in-house to respond to the lack of functionality within existing library management systems which handled the major part of library processes.It has taken some time for library system vendors to catch up and one can now find a list on the ERM Web Hub, provided by Cornell University, although this does not claim to be comprehensive. However, to my knowledge, as yet there has been no comprehensive comparison of the functionality provided by these systems similar to the one produced by Tim Jewel for in-house developed applications. As systems mature this will become an important task to help libraries make an informed choice.
In what follows I will indicate some of the functional areas that an ERM system should cover. In particular, I will emphasise some of the areas in which the functionality differs from that required by the management of print journals.
Like most other library resources, electronic resources need to be acquired in some way. However, the practice of acquiring and maintaining electronic journals differs in some important respects from the management of print journals. For example, libraries often acquire e-journals as part of a package of resources from an e-resource aggregator such as EBSCO. There is a need to determine which journals are covered by the package and for what period of time. In relation to that, users often need to know when a new issue is available. In the circumstance when there is no physical item sent to the library it is difficult for library staff to maintain this information. If libraries wish to keep track of that information then there is a need for some sort of electronic check-in process.
Access to the resource is another area where the electronic format differs from the printed version. Access to electronic resources is subject to the risk of network or host hardware disruption. There is a need to be able to flag the unavailability of an individual resource or a package of resources to the potential user early on, thus mitigating any frustration about the level of the service. Secondly, electronic resources are often licensed to the institution and this adds a further level of complexity, which is not attached to print journals. Furthermore, access is often restricted via network address or via some authentication and authorisation mechanism.
While the selection and evaluation of serials in the printed format is an important process, there are special considerations when it comes to the same process as applied to the electronic format. In particular, there are important elements to be recorded about the user interface such as the technical requirements for the evaluation and whether the local infrastructure can be configured to meet these criteria. For example, web browser compatibility and any associated plug-ins need to be recorded because this may have an impact on the rollout of browser configurations to library and faculty PCs or even whether the institution can support the interface at all. But it is not just technical considerations, which need to be taken into account. The usability of the interface needs to be evaluated and there may well be a choice of interfaces from different providers to the same package of resources or subsets thereof. The choice of interface needs to be justified to the faculties and the institution as a whole and the reasons for the choice need to be recorded.
Like print journals, e-journals need to be acquired and paid for, and the appropriate sums associated with the appropriate budgets. It is a fair assumption to make that the acquisitions module of the library management system should handle the recording of financial transactions at least while there is no standard interface to central institutional systems. However, as mentioned earlier, electronic journals are often bundled into packages. Although this is not unknown in the print world, the greater prevalence of e-journal packages necessitates a sophisticated package management process within the acquisition module. There needs to be a flexibility to have the option of binding the financial transaction to the whole package or to distribute portions of the transaction to the components of the packages, the individual titles. Furthermore, the print and electronic formats may be linked such that the cancellation of the print format may invalidate the license agreement for the electronic format. The system must be able to handle this link and embed the relationship within an appropriate workflow. There is also a need to handle situations where there are separate payments to the package licensor and to an interface or multiple interface providers. For example, one may pay Oxford University Press for the e-journal content but also pay both them and HighWire for the interfaces.
There are other aspects of administering the resource, which are specific to electronic resources. For example, some interface providers allow institutions to brand the interface so that users are aware that it is being paid for by that institution. Information about how the interface is branded should be kept within the ERM system so that electronic resource library staff can keep track of where branding occurs which would make it easier to make global changes. Consequently, the system would also need to record administrative accounts, i.e. usernames and passwords, to each interface provider where appropriate. Also, as mentioned earlier, it would be very useful if the e-resource librarian could flag whether an individual resource or a package of resources was not currently available across the network and to log periods of downtime. The latter would give the librarian some indication of the reliability of the resource and together with usage statistics could provide input into decision making as to whether to continue with the resource or interface provider. Of course, it is difficult to record the usage of resources particularly when the user moves away from locally administered web pages to an provider of a package of resources. More often than not library staff rely on statistics provided by the vendor and these statistics come in many formats. Recently, there have been moves to standardise usage statistics from vendors, of particular note in this field is COUNTER. There may be a requirement to upload COUNTER statistics into the ERM database so that usage statistics can easily be analysed together with other data pertaining to an e-resource.
Unlike print material, which does not usually come bundled with access restrictions, access to an electronic resource requires some form of authentication and authorisation. At the very least, an ERM system must be able to record information about the mechanisms used for authentication and be able to provide that information to users if necessary. One wouldn't expect it to handle the authentication mechanism itself as this would either be done at the host site or by some form of distributed authentication mechanism. However, what if only subsets of our users are authorised to use this resource? Again if we wish to present to users only those resources that they are authorised to use then it needs not be the ERM system which does that. Presentation of resources could be done via a portal and based upon user profiles to determine which resources the user was authorised to use. However, one would expect that the ERM system would provide some means of gathering all information pertinent to a resource and this may include which categories or groups of users were authorised to use it. It would be vital to see this information in one place if one were negotiating or re-negotiating agreements and contracts.
Electronic resources are increasingly governed by licensing terms and conditions. We expect the user to have read these or at least to be aware of the restrictions of use. Recording these restrictions within the ERM system would make it easier to present a summary of restrictions to the user. For example, whether the user can download material or use the items in course packs or whether the library staff can use the resource to satisfy interlending requests. Recording this information within an ERM database will allow libraries to display this information to users in a consistent manner.
These are just some of the functional areas that an e-resource management system should handle The functionality required by an electronic resource management system has evolved over time as library staff have become more acquainted with the processes involved with managing these resources and providers have gained experience in the provision of resources across the Internet.
The Digital Library Federation have been very proactive in encouraging the development of standards in this area. It was within this context that Tim Jewel conducted a survey of the functionality offered by in-house developed ERM systems in North America. Together with Adam Chandler of Cornell University they organised a web site to act as focus for this information (Medeiros, 2003). A meeting was held at the ALA annual conference in June 2001 which led to the setting up of an informal steering group. This group presented a workshop on ERM standards at a meeting sponsored by the DLF and NISO in June 2002. The workshop was not only attended by librarians but by library system vendors and serials publishers. It was agreed that standards were a key element to ensure successful developments of ERM systems and to this end it was agreed to provide a more formal and collaborative organisation to this work. A more formal steering committee was formed as well as two reactor panels to provide expert advice. One panel was made up of librarians with an interest or experience in managing electronic resources, and the other was made up of library system vendors and serials publishers amongst others.
The initiative's aim is to provide the community with a set of specifications, which would encourage the development of electronic resource management systems, based on standards and best practices. To this end it has produced a number of concrete deliverables. It has produced an entity-relationship diagram, supported by a data dictionary and a description of data structures, which maps data elements to the entities involved in electronic resources as well as to map the relationship between these entities. Secondly, it has produced a functional requirements specification and a workflow diagram Finally, the initiative looked at the possibility of providing an XML (Extensible Markup Language) schema to encapsulate some of the ERM data elements. XML is a mark up language, which is designed amongst other things to describe data and facilitate its exchange. An XML schema is a definition of the constraints which an XML document must adhere to. XML and associated schema can facilitate data exchange between electronic resource providers and the library, as well as between the library and other systems such as course management systems. The initiative has produced a schema for encapsulating license data as a proof of concept and how that schema may relate to existing rights expression languages such as the Open Digital Rights Language (ODRL) Initiative and the Creative Commons RDF schema. In particular, example use cases have been provided to deal with the exchange of licensing information. All these deliverables are attached as appendices to the final report, which is now available (Jewell, 2004).
An ERM system can be a module within an integrated library system or a stand-alone application. Whichever way the system is developed, it needs to be integrated not only with the ILS but with other applications and services. However, it should be noted that there is usually more than one way to integrate systems and it is not necessarily obvious which subset of data should reside in which application. The partition of data between an ILS, an ERM system, a link resolver database, e-resource aggregators and a LDAP (Lightweight Directory Access Protocol) directory service - to name a few data stores where information relevant to access to e-resources may be kept - is not a foregone conclusion. However, whichever architecture vendors opt for, application integration is made a whole lot easier if standards are adopted. In the following I would like to mention a few example to illustrate the possibilities and the importance of standards.
Some services may need to query an ERM system if the latter has its own database of e-journal metadata. Typically this could be done through a Z39.50 query or the newer Search/Retrieve Web Service (SRW) initiative based on web services standards. Metadata could also be exchanged between subscription agents and the ERM system. For example, the ONIX for Serials standard, developed by EDItEUR and NISO, can facilitate the exchange of serials subscriptions or holdings. It may also facilitate automatic electronic check-in.
The metadata in the ERM database could be used as a source of an OpenURL message package, which could be used as a basis for context sensitive linking. Context sensitive linking is often discussed within the context of access to an item level resource such as a journal article. However, the OpenURL standard can also be used to generate a link to the journal as a whole. This often occurs if there is not enough information in the OpenURL package to generate a link to the specific item. But it may also be useful to provide an OpenURL for each member of a list of e-journals. That list could be generated from the ERM system using other protocols such as SRW or Z39.50.
However, there may be cases where an e-resource is only available to a particular community within the institution. Bringing together user profile information with e-resource metadata as an access profile may be the job of the ERM system with the appropriate hooks into a directory service via the LDAP protocol. The ERM system can then provide information to third party applications in terms of presenting links to the resources tailored to the profile of the user. It may also provide metadata to an authorisation mechanism based around user identities such as Shibboleth, though this is not the only way this can be done. A combination of group information held in an LDAP directory and access information held at the data provider's site may suffice. There is more than one way to build user profiles for authentication and authorisation. This information can also be provided to a link resolver so that it is passed on to a data provider via the OpenURL protocol. Version 1.0 of the OpenURL standard allows for the passing of user information to the resource.
There are other standards, which are useful for application integration, and one of the most important is the Simple Object Access Protocol (SOAP). SOAP is an XML based protocol, which facilitates the exchange of information between applications and the calling of procedures remotely between applications over HTTP. It is one of the core standards for the web services architecture for integrating applications built on heterogeneous platforms A second standard which is of particular relevance to the integration of applications within portals is the Web Services for Remote Portlets (WSRP) standard. This allows portal developers to plug-in remote presentation oriented web services as a portlet. In particular, the ERM vendors need to provide a web service built to the WSRP standard to allow the embedding of the service within a library or institutional portal. Of course, the portal application itself needs to conform to the WSRP standard in order to plug in WSRP services As a matter of course, ERM vendors should provide appropriate interfaces, some of which may be provided as a web service, to facilitate the integration with other applications. Those services which may need to communicate with third party applications are candidates for development under the web services framework. As mentioned earlier, web services may be used for presentation purposes as in WSRP portlets or to facilitate communication and exchange of data between applications.
So, the development of ERM systems must take into account current and emerging standards if they are to integrate with the portfolio of library applications. However, it is just as important that they can be embedded within integration frameworks such as portals. There has long been a demand from both public sector and corporate organisations that library applications be seen as one component in the delivery of services to users. The key to interoperability is the development of systems which conform to standards as well as having published APIs. The importance of the emergence of web services as a set of standards for application integration should make it easier to integrate library applications with other institutional systems. Library system vendors need to build in these standards into their products.
In this paper we have looked at the emergence of ERM systems, the functionality that is required of them, and the push to adopt standards in their development. Many of these systems are not yet mature and it will be interesting to see how they develop over the coming years. What is of particular interest is how the management of electronic books may be integrated within these systems. The difference in scale of the amount of material and the technological and functional complexity in managing e-book resources within the context of a virtual or hybrid library is a challenge that has yet to be met.
COUNTER - Counting Online Usage of Networked Electronic Resources. http://www.projectcounter.org/
Creative Commons. http://creativecommons.org/
DLF - Digital Library Federation. http://www.diglib.org/dlfhomepage.htm
DLF ERM - Digital Library Federation Electronic Resource Management Initiative. http://www.diglib.org/standards/dlf-erm02.htm
HighWire Press. http://highwire.stanford.edu/
LDAP - Lightweight Directory Access Protocol. http://www.openldap.org/
NISO - National Information Standards Organization. http://www.niso.org/
NISO Committee AX- Development of an OpenURL Standard. http://library.caltech.edu/openurl/
ODRL - Open Digital Rights Language initiative. http://odrl.net/
ONIX for Serials. http://www.editeur.org/onixserials.html
OUP - Oxford University Press. http://www.oup.co.uk/
SOAP - Simple Object Access Protocol. http://www.w3.org/TR/soap/
SRW - Search/Retrieve Web Service. http://www.loc.gov/z3950/agency/zing/srw/
University of Bristol Information Services. http://www.bris.ac.uk/is
VERA - Virtual Electronic Resource Access.http://libraries.mit.edu/vera
Web Hub for Developing Administrative Metadata for Electronic Resource Management. http://www.library.cornell.edu/cts/elicensestudy/home.html
Web Services Activity Statement. http://www.w3.org/2002/ws/Activity
WSRP - Web Services for Remote Portlets. http://www.oasis-open.org/committees/wsrp
XML - Extensible Markup Language. http://www.w3.org/XML/
LIBER Quarterly, Volume 14 (2004), No. 3/4