Electronic Resource Management Systems
Mark Ellingsen
THE NEED FOR ERM SYSTEMS
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).[1]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.[2]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.
FUNCTIONALITY
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 ERM INITIATIVE
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).
STANDARDS
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.
CONCLUSION
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.
REFERENCES
WEB SITES REFERRED TO IN THE TEXT
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
EDItEUR. http://www.editeur.org/
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/
Shibboleth. http://shibboleth.internet2.edu/
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/
Z39.50. http://www.loc.gov/z3950/agency/
Notes
[1] On the development of VERA see
Hennig (2002).
[2] For a paper on trends in library management systems see
Ebenezer (2003).
LIBER Quarterly, Volume 14 (2004), No. 3/4