The Digital Library Federation (DLF) is a consortium of thirty-three members and five allied organizations that are pioneering the use of electronic information technologies to extend library collections and services. We pride ourselves on our ability to concentrate the talent of our librarians and technologists on issues of shared importance. The Electronic Resources Management Initiative (ERMI) is one such collaboration and has proved to be a timely and wide-reaching endeavor, finding a ready audience in libraries, systems vendors, and standards organizations.

The problem this initiative addresses is a pervasive one: when libraries acquire licensed electronic resources, they must comprehend, transmit, and inform others about the many financial, legal, and access aspects of these arrangements. The acquisitions and licensing processes are complex-publishers transmit this information to libraries in a variety of paper and electronic formats, and the number of licensed electronic products that libraries are collecting is increasing rapidly. Such situations tend to spawn local, ad hoc fixes. By contrast, the DLF ERMI has created a coordinated solution, developing the common specifications found in this important publication for the management of license agreements, related administrative information, and the internal processes associated with licensed electronic resources.

Even when it was in draft form, response to this work has been swift and gratifying. Major vendors of library systems have been informed by the recommendations of the ERMI report as they design license management capacities into their software suites. The developers of ONIX, the metadata scheme used widely by academic and trade publishers, are looking closely at adopting ERMI as they consider their license expression needs, and the United Kingdom's national serials union catalogue (SUNCAT) is testing ERMI as it seeks to express and store licenses within this developing national service.

David Seaman
Executive Director
Digital Library Federation

• Executive Summary
• Report
• Appendix A: Functional Requirements
• Appendix B: Workflow Diagram
• Appendix C: Entity Relationship Diagram for Electronic Resource Management
• Appendix D: Data Element Dictionary
• Appendix E: Electronic Resources Management System Data Structure
• Appendix F: XML Investigation
• Background documents and discussion list

--

As libraries have worked to incorporate electronic resources into their collections, services, and operations, most of them have found that their existing integrated library systems (ILSs) are not capable of supporting these new resources. A 2001 study by Jewell [1] determined that a number of libraries had begun developing local systems to overcome these shortcomings. The Digital Library Federation (DLF) Electronic Resource Management Initiative (ERMI) was organized to support the rapid development of such systems by producing a series of interrelated documents to define needs and to help establish data standards.

A National Information Standards Organization (NISO) and DLF workshop in May 2002 led to the creation of a steering group that would guide the development of the ERMI. In addition, the DLF invited librarians, library-system vendors, and representatives of related organizations to serve on two project advisory groups. The steering group shared draft versions of the documents it was developing with members of these two reactor panels. The drafts were also made publicly available via Cornell University's Web Hub for Developing Administrative Metadata for Electronic Resource Management (available from http://www.library.cornell.edu/cts/elicensestudy/).

This publication contains the report and appendixes developed by the steering committee during the course of its work. The report itself is intended to serve as a road map for electronic resource management (ERM). It outlines ERM system needs and discusses and illustrates screens from systems that are already in place at such institutions as the Massachusetts Institute of Technology (MIT), University of California, Los Angeles (UCLA), and the Johns Hopkins University (JHU). Appendix A summarizes in detail some 50 functional requirements of an effective ERM. Appendix B provides a diagram that outlines some differences between workflows for print and electronic resources. This appendix also contains diagrams for more specific phases of the e-resource life cycle.

Appendixes C, D, and E are closely linked. Appendix C is an entity-relationship diagram that illustrates how groups of data elements relate to one another. Appendix D is a data dictionary encompassing more than 300 elements. Appendix E covers data structure, grouping the data elements by entity and keying them to the functional requirements. The concluding XML investigation discusses and compares some existing rights expression languages (RELs). It notes that while it is desirable for libraries, publishers, and vendors to have a standardized, XML-based way to describe key terms of license agreements, no current RELs or schemas seem practical or usable without major modification. To fill this need, the authors propose creation of a native ERM schema based on the ERMI data dictionary.

--

The work of the ERMI has been received very favorably by both librarians and vendors, several of whom are already developing systems based in large part on this report and appendixes. Among several areas needing additional work are functional requirements for consortia, specifications for incorporation and reporting of usage data, and further development of data standards.

--

A few years ago, Cornell University Libraries' strategic plan included the bold and startling prediction of a "mostly digital environment" for that library system by 2005 (Cornell Libraries 2000). Whether or not this prediction proves to be accurate for Cornell or would apply to most other libraries, it is clear from Association of Research Libraries (ARL) expenditure-trend data that spending for electronic resources (e-resources) has been growing much more rapidly than have the materials budgets of which such resources are usually a part. In the 2001-2002 academic year, at least a few ARL libraries were already spending half their materials budgets for e-resources (ARL 2002, 2003). Libraries are in the midst of a profound shift toward reliance on e-resources, and this reliance seems to have deepened within the last year or two as libraries have shed paper journal subscriptions to help pay for online access.

Meanwhile, user behavior and attitudes seem to be changing even more quickly. For example, nearly half of the undergraduates surveyed by Outsell, Inc., for a recent study of the scholarly information environment indicated that they used e-resources either exclusively or almost exclusively (Friedlander 2002). That study also showed that many faculty and graduate students would like to see more journals available to them electronically. However, as many librarians can attest, demand for expanded access to e-resources is only part of the story. Users now compare their libraries' services to such recent innovations as the Google search engine and Amazon.com, and they expect libraries to provide similar levels of simplicity, power, and convenience.

These developments provide the context for what many librarians find to be a daunting and increasingly complex challenge: successfully managing their collections of e-resources. In an earlier study of DLF-member library practices, Jewell (2001) identified some noteworthy trends in how these libraries selected and acquired licensed e-resources and presented information about them to users. Perhaps of greatest importance for the present discussion, most of the responding DLF libraries had found that their existing ILSs were incapable of supporting these functions and had begun to design and build local automated tools to fill the gaps.

One fundamental management problem that some of these systems were meant to address is the need to describe larger and larger numbers of bibliographic databases and to present that information to users. Another challenge lies in the nature and characteristics of some of the new resources. For example, most libraries now spend significant amounts of money on aggregator databases. Available from companies such as EBSCO, Gale, LexisNexis, and ProQuest, these databases provide access to the contents or partial contents of large numbers of periodicals. Although such collections often provide substantial benefits, reliably and routinely determining which journals they provide--for what periods of time, in what format, and with what degree of currency or completeness--has been an elusive goal. The growth of electronic journals (e-journals) and databases has heightened this problem while complicating and transforming the processes associated with acquiring and servicing library materials.

--

The 2001 DLF report cited above noted that users were often presented with special alphabetical or subject lists of e-resources to help meet this descriptive or resource-discovery need. Aggregator databases had become a staple within this group, and many of the libraries had begun to experiment with listing their contents along with subscribed e- journals. Since the research for the DLF report was conducted, companies such as Serials Solutions, TDNet, and EBSCO have begun to offer services aimed at filling these needs, but few ILSs that can fully support or interact with them have become available. In recent years, libraries have also begun linking their indexing and full-text resources through proprietary database vendor solutions and broader, standards-based tools Ex Libris's SFX, thus not only providing greater user convenience but also adding a layer of complexity to the management of e-resources.

Other changes that are much less visible to users have also been taking place. As e-resources have become pervasive, formal license agreements have come to supplement or supersede copyright law as the basis for defining and determining their appropriate use. Despite the welcome and promising appearance of model licenses (Cox 2000; Council on Library and Information Resources 2001) and other efforts to standardize license terms, libraries have been investing substantial time and effort in the review and negotiation of license terms. Local license negotiations may become complex and protracted, involving staff at multiple levels of both licensor and licensee organizations. As a result, some libraries had begun making special efforts to track the status of a particular negotiation, describe its important license terms, and present those terms to users and staff.

At the same time, libraries have been entering into complex, consortium-based purchasing arrangements with other libraries. These arrangements are characterized by ongoing financial commitments and new communication, evaluation, and decision-making processes. Once acquired, these resources must be supported through specialized skills and new kinds of information. Recognizing the complexity of some resources and user expectations for convenience, some libraries have begun to provide instructional and other specialized information directly to their users via their Web sites.

Another defining facet of the new electronic environment revealed in the 2001 DLF study is that large numbers of staff from disparate units of larger libraries had begun playing new and important specialized roles in the selection, support, and evaluation of e-resources. Most of these staff had needs for a wide range of specialized information. For example, staff members in different areas might need to know the status of a given resource within the local acquisition and licensing process. Others might need to know access details, whether access problems related to a particular resource had arisen, and who was involved in what specific troubleshooting activities. Several libraries were also implementing planned, cyclical reviews of their e-resources, and--with that in mind--beginning to systematically gather and report all available information on their use.

--

Libraries' emerging interest in ERM systems prompted Jewell and Adam Chandler at Cornell to establish in 2001 a Web hub to exchange information about local systems and foster communication among interested librarians. As local systems were identified, librarians involved in developing them were systematically asked about their systems' functions and data elements, and the elements were analyzed and summarized in the DLF report previously mentioned (Jewell 2001, p. 26). Seven functional areas were identified: listing and descriptive, license-related, financial and purchasing, process and status, systems and technical, contact and support, and usage. Informal discussions were also begun concerning the value of standardizing functional descriptions, element names, and definitions to support these functions.

Within a year or two, some 20 libraries and vendors had announced that they had produced or were planning to produce such systems (table 1).

Table 1. Library-Based ERM Initiatives
• * California Digital Library
• * Colorado Alliance (Gold Rush)
• * Columbia University
• * Griffith University (Australia)
• * Harvard University
• * Johns Hopkins University (HERMES)
• * Massachusetts Institute of Technology (VERA)
• * North Carolina State University
• * University of Notre Dame
• * Pennsylvania State University (ERLIC)
• * Stanford University
• * University of Texas (License Tracker)
• * Tri-College Consortium (Haverford, Bryn Mawr, and Swarthmore)
• * University of California, Los Angeles
• * University of Georgia
• * University of Michigan
• * University of Minnesota
• * University of Virginia
• * Willamette University
• * Yale University

--

Each system developed by a library reflects particular local requirements and development constraints, and many systems exhibit creative and noteworthy features. Rather than provide an exhaustive review of these systems, this discussion focuses on features of just a few of them. Its purpose is to begin to identify elements of an ideal, but achievable, system for managing e-resources.

The Pennsylvania State University (Penn State) Libraries' ERLIC (Electronic Resources Licensing and Information Center), established in 1999, is a good example of a system that was designed to address a fairly limited need but whose functions have been expanded substantially (Penn State Libraries 2001). Developed using Microsoft Access to track the status of orders and to anticipate renewals, ERLIC, and now ERLIC2, have evolved into centralized sources of ordering, access, authentication, and licensing information (Stanley et al. 2000; Alan 2002). The MIT Libraries' VERA (Virtual Electronic Resource Access) system was developed about the same time as Penn State's and also exhibits a wide spectrum of functions (Duranceau 2000a; Duranceau 2000b; Hennig 2002). It offers both extensive support for "back-office" staff functions and requirements and numerous noteworthy public Web page-design features. Yale University's schematized treatment and public presentation of license terms serves as an interesting supplement to MIT's approach to the same problem.

Like ERLIC and VERA, UCLA's ERDb system was developed to provide a wide range of functionality. While its functionality and screen designs are of substantial interest and will be explored in the following pages, related working documents (Farb 2002) also articulate useful guidelines that could be generally applied to ERM-system development. Under these guidelines, a system should

• * accommodate growth
• * design for flexibility
• * be offered "one database, but many views"
• * avoid unnecessary duplication
• * be capable of phased implementation

Similarly broad in scope is JHU's HERMES, which stands for Hopkins Electronic Resource Management System (Cyzyk and Robertson 2003). Based on PostgreSQL and Cold Fusion, HERMES has recently been made available on an open-source basis. While intended to support such functions as the dynamic generation of public Web pages, HERMES is of special interest because of the careful analysis of staff roles, workflows, and associated functional requirements that have gone into it. Also worthy of mention is Gold Rush, developed by the Colorado Alliance of Research Libraries (Stockton and Machovec 2001). Gold Rush was the first commercially available system to incorporate substantial functionality for e-resource subscription management. Reasonably priced and offering support both for individual libraries and library consortia, Gold Rush enables a central consortium administrator to "push" out to member libraries a record with a range of information pertaining to an e-resource.

--

Records management has been defined as the "systematic control of all organizational records during the various stages of their lifecycle: from their creation or receipt, through their processing, distribution, maintenance and use, to their ultimate disposition" (Robek et al. 1996). Effective management of e-resources depends on the execution of a wide range of functions that follow a slightly different life cycle. For example, while libraries at present generally do not have to deal with the creation of licensed e-resources, they do need to evaluate new products and services, and there are other fairly close parallels between a simplified records management life cycle model and one for e-resources.

Table 2 outlines many of the tasks involved in managing e-resources and the staff who may be involved in different life cycle phases. The table is based on the functions and reports available to staff users of HERMES and largely follows the DLF Electronic Resource Management Initiative (ERMI) workflow sequence (see Appendix B).The column headings refer to five roles that Hopkins staff play in the process: selector and superselector, acquisitions administrator, library computing systems administrator, and public display administrator. Each of these roles is described in the following paragraphs.

1. Product consideration and trial process. At JHU, a selector is responsible for identifying a resource, determining whether a trial is necessary, and gathering preliminary license information. The acquisitions administrator is responsible for negotiating a trial license, if needed. The selector recommends whether to proceed following a trial, which the superselector then approves or disapproves. Additional details, such as trial URLs, passwords, and publicity, are established and recorded during this phase.

2. Acquisition processes. These processes involve three fairly distinct subprocesses that may take place simultaneously. At JHU, the acquisitions administrator is responsible for license negotiation and for entry of related information into HERMES, and the computing services administrator determines technical feasibility and gives or withholds permission to proceed. Remaining tasks, also the responsibility of the acquisitions administrator, relate to funding and purchase.

3. Implementation. During this phase, authentication details are worked out and recorded, any necessary database configuration is performed, and the resource and any appropriate components are cataloged and incorporated into public Web pages. The descriptive tasks during this phase can be difficult and time-consuming, particularly if the resource in question is an e-journal or aggregator package containing large numbers of journals or other content. Public Web page presentations can be provided in a number of ways and, as will be shown later, could include the provision to staff and users of information about licensing terms. It may also be necessary to make the resource known to a link resolver or proxy server.

--

4. Product maintenance and review. One of the important tasks within this phase is subscription renewal, which can be triggered by date-configurable reminders to staff and could involve price or license-term renegotiation. Another task is maintenance of the holdings, or coverage, information encountered during the implementation phase. Additional tasks that could figure in the renewal process include acquiring and making usage data available to staff and identifying and resolving problems relating to access and other technical issues.

--

--

--

3.2.1. Product Consideration and Trial Processes

The preceding life cycle, task, and role inventory may not correspond closely with the screen displays that staff actually see when using ERM systems or their derivatives. For example, the functions listed on table 2 could be reorganized and presented according to staff role--as they are within the HERMES. This underscores the value of one of UCLA's aforementioned design principles: "One database, many views." Another example of multiple views and an alternative organization of similar information is this screen from MIT's VERA (figure 1).

In this view, information from different life cycle phases, such as acquisition (purchase order number and vendor), implementation (URL, location), and product maintenance and review (renewal date, technical support contact, information about usage data) is presented together, presumably because the staff who use this screen need to see it simultaneously.

--

Figure 2 shows a view from UCLA's ERDb system. Called a Resource Screen, it includes information relevant to multiple e-resource life cycle phases. In addition to basic identifying or descriptive information that will be useful and used throughout the resource life cycle, selection information (e.g., sponsoring unit and selector), as well as acquisitions information (e.g., vendor and purchase order number) can be seen.

--

Figure 3 depicts the License Screen, another view of ERDb information related to the same resource. In addition to identifying the licensor, or negotiator, for UCLA and a link to a redacted version of the relevant license, this screen provides space for a detailed analysis of the specific rights and other details included in the license.

3.2.2. Implementation Processes and Public Web Pages: Alphabetical and Subject Presentations

Libraries commonly present users with multiple routes to licensed resources, including OPAC catalog entries, alphabetical and subject Web page listings, e-reserve links, and links connecting index or abstract entries to the corresponding full text. The mechanisms used to provide these presentations are generally hidden from public view. Figure 4 shows what UCLA users encounter when they follow a link from the library's gateway page to Online Materials.

--

As many other libraries do, UCLA distinguishes between e-journals and article databases. Accordingly, those distinctions need to be made within its database. UCLA's alphabetical and subject presentations (figures 5 and 6, respectively) are similar to those of many other libraries.

--

--

Helping drive and support these presentations is information gathered and maintained via the ERDb Title View (figure 7), such as the basic bibliographic data for the resource. Another view, to be released shortly, relates the component titles of a particular e-journal package to a parent record that is necessary for a number of functions, such as linking license terms to particular titles. The Title View also enables the association of a resource with both Subjects (figure 8) and Types of Resources (figure 9).

--

--

3.2.3. Implementation Processes and Public Web Pages: Extended Information

Like UCLA's ERDb system, MIT's VERA is used to generate subject (figure 10) and alphabetical (figure 11) Web pages for databases and e-journals. VERA is also used to describe e-resource availability by specific location and to manage and generate resource-specific URLs.

--

--

The way in which VERA incorporates and presents a wide range of other information using special-purpose icons is especially noteworthy (see the lower left corner of fig. 11). For example, the "Go" button indicates that a resource is available to the MIT community from off-campus, the "?" icon leads to search tips and other documentation, and the "C" icon leads to information about upcoming classes on using the specific resource. The universal "Not" symbol also indicates the existence of resource-specific access problems. Of even greater interest is the way in which VERA incorporates license information. In addition to the generic message about appropriate and inappropriate use of resources that precedes the resource list, the "L" icon indicates when more specific license-related information is available. For example, figure 11 shows an entry for the Abstracts of the Papers Communicated to the Royal Society of London--provided by JSTOR. The "L" icon leads the user to a summary of key provisions of the JSTOR license (fig. 12) that governs its use.

--

Yale University Library's public e-resource pages also integrate instructional and licensing information in clear and understandable ways. For example, figure 13 shows an alphabetical listing of databases in the social sciences, including Academic Universe.

--

When users click on the Academic Universe entry, they are taken to the display of additional information shown in figure 14, which includes a group of Help tools as well as a link to Permitted Uses of Databases.

--

The Permitted Uses of Databases link takes users to the appropriate section of a lengthy document summarizing permitted uses for many or most of the library's licensed resources (fig. 15).

--

This presentation is noteworthy for at least three reasons. First, the resources' licenses have been analyzed to determine their provisions in eight key areas, with a simple "yes" or "no" indicating whether or not a particular use is permitted. Second, the summary grid provides space to expand where needed on any of the key terms. Third, the presentation allows for a link to the full Terms and Conditions. In this case, the link takes users to the LexisNexis Web page (fig. 16), but it could just as easily take them to a locally digitized version of an institution-specific license.

--

An interesting contrast to the MIT and Yale license-information presentations is provided by the simple Terms of Use section from the Colorado Alliance's Gold Rush Staff Toolbox (fig. 17). Whereas MIT's and Yale's summaries are designed for use by those library systems alone, Gold Rush can provide summary license terms to all libraries sharing the system and particular resources.

--

3.2.4. Product Maintenance and Review

Once access to a product has been established and its availability made known to staff and users, any number of problems may arise. For example, a vendor or another information provider may need to take a product offline for brief or extended periods for planned maintenance or to correct unanticipated technical difficulties. Occasionally, vendor files of a subscriber's IP addresses may fail to reflect recent changes or become corrupted, and this will affect access to subscribed services. Delays in product invoicing and payment may lead to outages, especially at the beginning of a month. These problems may manifest themselves in a variety of ways, such as prompts for usernames and passwords or other messages that may be difficult to understand. Still more vexing may be that an access problem related to a particular publisher's package of e- journals or an aggregator service can affect all its component journals--entries for which may be dispersed through an online catalog or Web list of journals available online.

When any of these circumstances arise, it may be difficult or impossible for a library to effectively manage communication with staff and affected users. One promising approach to staff communication is shown in figure 18, which depicts a Status screen from UCLA's ERDb system. The upper half of this screen displays basic information about the resource in question, while the lower half provides space to record information about a reported incident, such as a user's name, IP address, Internet service provider, and browser; a description of the problem; the action required; and the present status of the problem.

--

Another approach to communicating problems such as some of those mentioned above is shown in figure 19, which is a mock-up of a Billboard function envisioned for Penn State's ERLIC2. This feature would allow users or staff to quickly identify any resources to which access was likely to be a problem at a particular time.

--

The project that eventually became the DLF ERMI began with the Web hub developed by Jewell and Chandler. At the time the hub was created, the ALCTS Technical Services Directors of Large Research Libraries Discussion Group developed an interest in ERM and agreed to sponsor an informal meeting on the topic at the June 2001 American Library Association (ALA) annual conference. That meeting attracted some 40 librarians and led to further discussions of functions and data elements. Shortly thereafter, an informal steering group was formed that included Jewell, Chandler, Sharon Farb and Angela Riggio from UCLA, Nathan Robertson from JHU, Ivy Anderson from Harvard, and Kimberly Parker from Yale. This group worked with Patricia Harris and Priscilla Caplan at NISO and Daniel Greenstein (then at the DLF). These individuals undertook discussions of possible standards that ultimately led to the presentation of a NISO/DLF Workshop on Standards for Electronic Resource Management in May 2002. The workshop was attended by approximately 50 librarians and representatives from a number of vendors and publishers, including EBSCO, Endeavor, Ex Libris, Fretwell-Downing, Innovative Interfaces, SIRSI, and Serials Solutions.

At the workshop, in addition to presentations and discussions concerning the nature and extent of ERM, a proposed entity relationship diagram (ERD) and several lists of data elements were presented and discussed. One important outcome of this meeting was the formation of a consensus that standards to help guide the development of ERM systems were indeed desirable. This affirmation led the workshop steering group to consider a

--

Accordingly, the steering group developed and submitted to the DLF a proposal for an ERMI. The aim of this project was to formalize and provide further shape and direction for efforts that had previously been very informal and ad hoc. Its primary goal was to foster the rapid development of systems and tools for managing e-resources--whether by individual libraries, consortia, or vendors--and, more specifically, to

• * describe the functions and architectures needed to enable systems to effectively manage large collections of licensed e-resources;
• * establish lists of appropriate supporting data elements and common definitions;
• * write and publish experimental XML Schemas/DTDs for local testing;
• * identify and promote appropriate best practices; and
• * identify and promote appropriate standards to support data interchange.

The DLF accepted the proposal in October 2002. The seven librarians who organized the May 2002 NISO/DLF workshop became the steering group for the new initiative. The steering group's task has been to continue the efforts already begun and produce the documents, or deliverables, described below.

The steering group held weekly conference calls for two years. In addition, to provide for ongoing expert advice, two reactor panels, or advisory groups, were formed. One panel (table 3) consisted of librarians deemed specially qualified by their experience and interest in ERM systems to provide the kinds of feedback needed.

--

Table 3. DLF ERMI Librarian Reactor Panel
• * Bob Alan (Penn State)
• * Angela Carreno (New York University)
• * Trisha Davis (Ohio State University)
• * Ellen Duranceau (MIT)
• * Christa Easton (Stanford University)
• * Laine Farley (California Digital Library)
• * Diane Grover (University of Washington)
• * Nancy Hoebelheinreich (Stanford University)
• * Norm Medeiros (Haverford College)
• * Linda Miller (Library of Congress)
• * Jim Mouw (University of Chicago)
• * Andrew Pace (North Carolina State University)
• * Ronda Rowe (University of Texas)
• * Jim Stemper (University of Minnesota)
• * Paula Watson (University of Illinois)
• * Robin Wendler (Harvard University)

Members of the steering group and the librarian reactor panel communicated in a number of ways. First, several members of the panel and of the steering group attended a special meeting held in conjunction with the DLF Spring 2003 Forum in New York City. Steering group members established a groupware site at UCLA using Microsoft's SharePoint software. This facilitated sharing of draft documents, task lists, and information on upcoming meetings and deadlines. The site was also used to post questions for the panel members and to provide space for responses and replies. Since not all members of the reactor panel were able to use the SharePoint site, questions and responses were also distributed via e-mail. As needed, the steering group invited panel members who posted comments and questions to participate in the conference calls. The steering group members found that the discussions and feedback substantially enhanced their understanding of the problem, and many comments and questions led to refinements of the deliverables.

The second panel, the vendor reactor panel, consisted of representatives from a range of other organizations with interests in the problems to be addressed by the initiative. This group comprised representatives from a number of integrated ILS providers and other companies serving the library market (table 4).

--

Table 4. DLF ERMI Vendor Reactor Panel
• * Tina Feick (SWETS Blackwell)
• * Ted Fons (Innovative Interfaces, Inc.)
• * David Fritsch (TDNet)
• * Kathy Klemperer (Harrassowitz)
• * George Machovec (Colorado Alliance)
• * Mark Needleman (SIRSI)
• * Oliver Pesch (EBSCO)
• * Chris Pierard (Serials Solutions)
• * Kathleen Quinton (OCLC Online Computer Library Center, Inc.)
• * Sara Randall (Endeavor)
• * Ed Riding (Dynix)
• * Jenny Walker (Ex Libris)

Communication patterns between the steering group and the vendor panel differed from those used with the librarian panel. While the vendor group was provided with versions of the draft documents and the questions being posted to the librarians, there was relatively little further communication about those documents at the time. Nevertheless, many of the companies represented on the vendor panel have continued to express strong interest in the project. ILS vendors have been especially responsive. Many discussions have involved steering group members. For instance, Innovative Interfaces, Inc. (III) has pursued development of an ERM module since spring 2002. Tim Jewell has been involved in related discussions and has kept the company informed of ongoing work on data elements (see below) so that III's elements could be as consistent with them as possible. Ex Libris has also performed substantial analytical work preparatory to product development; Ivy Anderson has contributed heavily to those efforts, especially to the statement of functional requirements that has helped guide it. More recently, Dynix held predevelopment meetings in which Nathan Robertson was involved, and the company has now developed an internal white paper describing the architecture of a future system that references the steering group's work.

The ERMI has developed and made available a number of deliverables. An overarching goal has been to control costs and save time by providing a series of interrelated documents on which libraries and vendors could base their efforts. It was expected that the documents might be put to a variety of other uses as well. The documents and some of their anticipated uses are as follows:

• * Problem Definition and Road Map. The purpose of the road map was to offer an overview of the ERM problem, provide examples of the creative approaches some libraries have taken to solving it, and highlight problems needing resolution.

---

--

• * Workflow Diagram. Devising a detailed but generic workflow diagram was expected to help the steering group understand work processes and thereby help ensure that other documents would be developed appropriately and completely. A workflow diagram could provide a reference point for analyzing local workflows, which could lead to improved internal communication and more streamlined processes.
• * Functional Specifications. This document was intended to clearly and comprehensively identify the functions that an ERM system would serve. Libraries could use it to support discussions of the features they might wish to purchase or incorporate into a locally developed ERM system or use the specifications in a draft request for proposals from vendors.
• * Entity Relationship Diagram. An ERD is a standard system-development tool that can help designers conceptualize and present groups of data elements, or entities, and their interrelationships. As noted earlier, a draft ERD was presented during the DLF/NISO workshop, and a revised version was expected to help clarify discussions during the initiative and to assist future system designers.
• * Data Elements and Definitions. Providing a standardized list of entities and data elements was projected to save developers substantial time. Such a list could also be helpful in the development of data standards. Draft lists of data elements were discussed at the NISO/DLF workshop, and it was intended that the final, single list would be keyed to, and organized to reflect, the ERD. To invoke a naturalistic comparison, the ERD (as a sketch of a whole system), could be likened to a tree, while the data elements could be compared to its leaves.
• * XML Schema. The XML schema was intended to extend the value of a standardized list of entities and elements by providing a means for exchanging data. Such a schema could provide partners a platform upon which to test the sharing of license information across different systems while giving an additional boost to local library and vendor development efforts.
• * Final Report. A final report would integrate these documents and present them as a whole.

The importance and potential value of standards to ERM systems is fundamental. A primary motivation for establishing standards in this case is to lessen vendor development costs and risks and thereby accelerate the development process. In addition, although it is conceivable that ERM systems might be developed and marketed as standalone systems, it seems likely that they will need to be overlaid on or otherwise linked to existing tools, such as serials or acquisitions systems, online catalogs, and e-resource gateways (Warner 2003). It is therefore critical to establish predictable pathways among variant data streams. Libraries that have developed their own systems or that wish to do so in the short term, might hope ultimately to transfer their data to a vendor system. If agreement on standards could be reached, those libraries could develop, modify, or align their

--

These considerations led the steering group to survey and monitor the status and development of standards that might dovetail with or otherwise have relevance for its work. Farb and Riggio (2004) summarized the results of that investigation as follows:

Increasingly, we are learning about new metadata schemata, structures, and standards designed to address various communities and constituencies. To date, however, none exist that address the dynamic, multidimensional, and legal aspects of acquiring and managing licensed e-resources over time.

Table 5 provides a rough mapping of the planned DLF ERMI metadata schema coverage against several others designed to address specific aspects of ERM. The first seven column labels indicate general functional areas that need to be addressed by standards, and the right-hand column shows whether or not a particular effort is proprietary, which the steering group regarded as an important determinant of potential value to libraries and other interested parties. The row labeled "DLF ERMI" indicates the steering group's assessment that its work addressed all seven functional areas in a significant way, although attention to the "Usage" category was less extensive than for the others. While related standards efforts are shown as having focused on fewer areas--such as identification and description--it should not be assumed that the steering group expected its work to take the place of other efforts. Instead, the intent was to identify areas of common interest and avoid duplication of effort.

--

This section reviews what has been learned in the process of developing the various ERMI documents and the results of the XML investigation. The documents themselves may be found in the appendixes.

4.3.1. Functional Requirements (Appendix A)

In spring 2003, staff from Harvard's and MIT's libraries met with staff from Ex Libris to discuss possible work on an ERM tool. While lists of likely data elements were available and discussed, attention quickly turned to the question "But what is the functionality?" To answer that question, Harvard and MIT libraries' staff, led by steering group member Ivy Anderson and MIT's Ellen Duranceau, collaborated to write a description of the functionality needed in an ERM system. This document was subsequently broadened for use as a DLF ERMI deliverable.

The functional requirements identify and describe the functions needed to support e-resources throughout their life cycles, including selection and acquisition, access provision, resource administration, staff and end-user support, and renewal and retention decisions. The requirements are based on the following guiding principles:

• * Print and e-resource management and access should be through an integrated environment.
• * Information provided should be consistent, regardless of the path taken.
• * Each data element should have a single point of maintenance.
• * ERM systems should be sufficiently flexible to make it possible to easily add new or additional fields and data elements.

In addition, a few core requirements for ERM systems were identified. For example, systems should be able to represent the relationships among individual e-resources, packages, licenses, and online interfaces; associate the characteristics of a given license, interface, or package with the resources to which it applies; and provide robust reporting and data-export capabilities.

This document encompasses 47 requirements, more than half of which discuss functionality needed to support staff. The scope of the requirements can be seen from the following category summary.

• * General (4 requirements). These include the three core requirements in more precise language, and state that "security features to control staff views and maintenance rights" are also required.

---

--

• * Resource Discovery (7 requirements). These requirements address the need for making resources available through, or pass information about them to, OPACs and Web presentation services and for contextual presentation of license information at the point of access.
• * Bibliographic Management (2 requirements). These address the need for a single point of data entry, maintenance for bibliographic information, and the ability to import aggregator holdings and subscription-management data.
• * Access Management (5 requirements). This group covers the management of basic access-related information such as Uniform Resource Identifiers (URIs), User IDs and passwords, and lists of institutional IP addresses, as well as the requirement to interoperate with or submit data to related technical systems such as proxy servers and persistent naming services.
• * Staff Requirements (29 requirements)
  • o General Interface Requirements (4 requirements). The staff interface should be organized into views that are optimized for particular areas of staff activity or interest such as resource acquisition, troubleshooting, license administration, or administration and statistics.
  • o Selection and Evaluation Processes (9 requirements). An ERM system should support the recording of actions and other information at various steps in what may be decentralized processes. It also must have the capability to perform specified actions or to send alerts in defined circumstances. The library should be able to customize actions and triggers to support a site-specific workflow.
  • o Resource Administration and Management (11 requirements). This group describes functionality related to administrative user names and passwords, local configuration options, hardware and software requirements, problem-solving and troubleshooting support, the ability to flag resources as unavailable, and the ability to store information about usage data.
  • o Business Functions (5 requirements). This group covers pricing models, cancellation restrictions, renewal and termination activities, and cost-sharing and consortial-relationship information.

To help make the functional requirements as universally applicable as possible, the steering group reviewed and discussed them with members of the librarian reactor panel, who were asked to distinguish between the requirements they saw as core or essential, and those that were not. The steering group found it gratifying (although vendors may find it dismaying) that every requirement was considered core by at least one member of the reactor group. Nevertheless, it is possible to identify some of the functions that this group viewed as most critical.

--

One of the most important requirements was the ability to manage the relationships among bibliographic entities (i.e., individual titles) and the packages, licenses, and interfaces through which they are made available. Another important requirement was the ability to store access-related information such as URLs, user IDs and passwords, and institutional IP addresses. The ability to record authorized-user categories and other license permissions, restrictions, and metadata about the agreement itself was viewed as equally important. Not surprisingly, the ability to store license permissions and associated metadata was one of the most frequently cited requirements, and the ability to link to an online version of a redacted license was also desired by most panelists. Offering a single point of maintenance for bibliographic and other descriptive data and facilitating electronic transfer of holdings and other subscription data from external providers were also identified as essential, as was supporting institutional workflows via customized routing and notification tools.

Other core or essential features included the ability to store information about administrative IDs and passwords and information about and access to usage statistics.

The following themes also emerged in the reactor panel discussions:

• * Most libraries want to be able to use their existing ILSs for core acquisitions functions such as ordering, budgeting, and fund accounting. However, these systems must be enhanced to accommodate the additional functionality required by e-resources. If ERM is implemented in a stand-alone application, libraries will generally choose to continue to perform core acquisitions activities in their ILSs but may want to export some data to the ERM system for analysis and reporting.
• * The relationship of the descriptive data in an ERM system to other descriptive systems such as the OPAC, federated search tools, and link resolution services is a matter of concern for many libraries. All agreed that minimizing duplicative data and enabling these systems to "talk to" one another was important. As one reactor said, the OPAC should be recognized as the home of MARC bibliographic data.
• * Usage statistics are an increasing focus of interest for many libraries. In addition to relying on vendor-provided usage data, many libraries collect such data locally. The steering group asked the panel members whether an ERM system should store usage data or merely point users to external data sources. Although most respondents found pointers to be adequate, a number felt that a common framework for storing and presenting statistics from disparate sources should be provided.
• * Many large libraries use persistent URIs. Support for them can be critical to the library's operation. In general, libraries that assign persistent URIs want to be able to record them in the ERM system. Many agreed that being able to generate persistent URIs was both desirable and feasible since the algorithms by which they are assigned tend to be highly formulaic.

--

4.3.2. Workflow Diagram (Appendix B)

The purpose of the workflow diagram was to provide a detailed overview of the activities associated with managing the life cycle of electronic products (e-products). A starting point was the realization that while there are some similarities between the acquisition and management processes for traditional, physical library materials and those for e-products, many issues are unique to e-products.

Some of these differences are obvious from the overview flowcharts in Appendix B. For example, e-products routinely require a licensing process and may pose technological challenges for implementation. Activities associated with acquiring and activating a networked product are substantially different from those associated with the receipt and processing procedures for physical items. Maintenance, troubleshooting, and license renewal for e-products are quite unlike the circulation, physical storage, and repair issues for physical objects.

The flowchart for the project, developed primarily by Kimberly Parker and Nathan Robertson, reflects these complex realities by breaking down a model workflow into the four main subprocesses identified for HERMES in section 3.1. Each subprocess is depicted through its own diagram. The first subprocess, Product Consideration and Trial Processes, traces typical steps from the point at which library staff become aware of the availability of an e-resource of interest, through trial and evaluation steps, to the "Proceed/Don't proceed" decision point. A decision to proceed would trigger three other processes shown in the diagram (since they typically occur concurrently)--License Negotiation, Technical Evaluation, and Business Negotiation.

Once all these processes reach the "approval to proceed" point, the third major set of processes is triggered. These are labeled Implementation Processes and encompass such disparate steps as product registration and configuration, cataloging and inclusion in appropriate Web pages, and activities related to availability and handling of usage data. The final set of processes is Product Maintenance and Review. Among the functions included in the routine maintenance category are the capture of usage statistics, troubleshooting and problem resolution, routine product changes from the vendor (e.g., URL revisions), and revisions to public documentation.

--

4.3.3. Data Entities, Elements, and Structure (Appendixes C, D, and E)

Three of the deliverables are tied especially closely to one another: the ERD, the data element dictionary, and the data structure. The ERD is a visual representation of ERM concepts and the relationships between them. The data element dictionary identifies and defines the individual data elements that an ERM system must contain and manage, but leaves the relationship between the elements to be inferred by the reader. The data structure associates each data element with the entities and relationships defined in the ERD. Together, the three documents form a complete conceptual data model for ERM.

An ERD is often used as a way to visualize a relational database. Each entity represents a database table, and relationship lines represent the keys in one table that point to specific records in related tables. ERDs may also be more abstract, not necessarily capturing every table needed within a database but simply diagramming the major concepts and relationships. The ERD developed for the ERMI is of the latter type. It is intended to present an abstract, theoretical view of the major entities and relationships needed for management of e-resources, but does not identify every table that would be necessary for an ERM database.

The data element dictionary, which now includes roughly 300 elements, grew out of a data dictionary developed for UCLA's ERDb. It lists the elements alphabetically by data element name and includes an identifier, definition, and, where deemed necessary, comments. To the extent possible, element naming and definitions were based on guidelines provided by International Standards Office (ISO) 11179. In addition, an effort was made to identify and use element names already included in other relevant metadata schemas such as Dublin Core, ONIX, ONIX for Serials, and METS. A more detailed discussion of these standards and schemas and of how the work of the initiative relates to them is provided in Appendix F.

The data structure document integrates the ERD and the data element dictionary by mapping the data elements from the dictionary to the approximately two dozen entities depicted in the ERD. In addition to the names and definitions, the data structure indicates element type (e.g., logical, pointer, text), use or functionality (including references to specific points in the functional requirements document), suggested values, optionality (whether optional or mandatory), repeatability (whether the element carries a unique value or can be repeated), and selected notes or examples for additional clarity.

Some of the two dozen defined entities, such as the entities for Electronic Resource and for Interface, could be characterized as serving a primarily descriptive function. A large number of data elements are required to summarize license terms. For example, a Terms Defined entity includes groups for identification, user group, and terms of use--which itself contains some 30 elements covering such license provisions as fair use, scholarly sharing, interlibrary loan, and course packs.

--

There are also entities for Acquisition and Processing Workflow, and for Access Information and Administrative Information. Some entities can be used for a variety of purposes. For example, the Organization entity can be used to record information about any business, vendor, provider, publisher, licensor, etc., with which a library does business related to e-products.

Since the elements identified, named, and defined for this part of the project were seen as possibly forming the core for an emerging data exchange standard, the lists have been available via the Web hub for some time. Communication with two ILS vendors (Innovative Interfaces and Ex Libris) that have been actively working on ERM systems has been especially close, and both have undertaken substantial work to see that their data elements are consistent with those of the initiative.

4.3.4. XML Investigation (Appendix F)

The final proposed deliverable was an XML schema that would foster the development of metadata standards for the exchange of information about e-resources, e-resource packages, and licenses. During fall 2003, a group was formed to pursue this work. Coordinated by Adam Chandler, it included fellow steering group members Sharon Farb, Angela Riggio, and Nathan Robertson, plus Robin Wendler (Harvard), Nancy Hoebelheinrich (Stanford), and Simon St. Laurent (O'Reilly & Associates). Rick Silterra (Cornell) joined the effort later. Because this part of the project depended on finalizing work on the data entities, elements, and structure, it was impractical to get very far ahead of that part of the project. The desire to complete the project in a timely way and make it available for comment and use also meant that time available for this part of the project was fairly limited. The data element work was informed and affected by what the steering group knew of emerging work elsewhere on standards, including the work of the NISO/EDItEUR Joint Working Party for the Exchange of Serials Subscription Information.

The XML investigation began with a consideration of the uses to which an ERM schema might be put. These possible uses included

• * exchange among vendors and libraries of data for use in link resolvers, including user group license terms;
• * publisher e-resource title lists;
• * packaging actionable license terms with associated objects in a preservation archive (e.g., using METS);
• * dissemination of license and administrative data to members of a consortium; and

---

--

• * exchange of license data with a contracting partner.

With these many possibilities in mind, XML group member Wendler developed a draft schema for general use that included Dublin Core and MODS name space and schemas, and a slot or placeholder for rights expression. As the group discussed the draft and as the NISO/EDItEUR and XrML/ODRL dynamics further unfolded, it became clear that a more fruitful approach would be to concentrate on a limited number of practical scenarios. Since license terms have been of substantial concern to libraries for several years, but no directly related, known XML work had yet taken place within that community, it was decided to focus on license terms. The group focused on two sets of elements:

• * a short quick-fix set that would best describe license terms that staff and users would most need to know; and
• * a broader license set of elements that could be most usefully shared by two libraries or other entities such as a publisher or consortium and a library.

Members of the group selected the required elements from the DLF ERM system data structure document and created instance documents with data that were then used to develop a schema optimized to these narrow uses.

Because of the many potential advantages of relying on existing schemas, the group looked for work that was closely related or that might be adapted to the purposes it had in mind. Apparent similarities led to investigation of work on digital rights management (DRM), and rights expression languages (RELs). As Karen Coyle has described in her recent report for the Library of Congress (Coyle 2004), two well-established RELs currently vie for recognition as the standard for media products such as movies in DVD format. The first of these, now referred to as MPEG-21/5, grew out of the XrML language developed by a company named ContentGuard. The second is called the Open Digital Rights Language, or ODRL. These initiatives are intended not only to enable a rights holder to describe what a user may do with a particular resource but also to confer substantial control of user behavior on the implementing party. The XML group learned of the existence of extensive patent claims related to MPEG-21/5, and its strong preference for open standards led it to focus on ODRL.

A third initiative that sparked interest is from Creative Commons and is based on the resource description framework (RDF). The intent of the Creative Commons approach, unlike that of the MPEG-21/5 and ODRL, is to provide a means for authors to declare the terms on which they are making works available free of charge via the Internet, rather than to exert control. The group elected to focus some of its attention on the Creative Commons schema, and four schemas (corresponding to the two use cases described above) were developed: one for ODRL, another based on the Creative Commons RDF, and two for native ERMI, which were based on ERMI project elements and values.

--

The attempt to use ODRL met with mixed results. While ODRL proved to be extensible and flexible, learning to use it effectively was time-consuming and would have taken much longer without the generous assistance of Renato Iannella and Susanne Guth of the ODRL initiative. For example, the group found that only the form of the XML documents could be validated in the ODRL schema that the group developed, meaning that any value (including invalid ones) would be accepted. (Iannella told us subsequently that it is possible to validate a document more completely, but time did not allow us to alter our demonstration ODRL schema to incorporate that feature.) In addition, it is necessary to describe all permitted uses under ODRL; this is clearly inconsistent with libraries' expectations that they should be able to make reasonable uses of resources that are not prohibited by licenses.

A greater degree of success was hoped for with the Creative Commons RDF, because it was not designed to support direct control of use and its ethos is consistent with open access and fair use. While less constraining and more extensible than the ODRL, it unfortunately also lacks provision for validating structure and data types. The group consequently concluded that the Creative Commons RDF could not provide a basis for license description and communication.

These discoveries led to work on the third alternative, the aforementioned native ERMI license-expression development. In essence, this would entail establishing a name space for license expression on the basis of elements and values from the ERMI data dictionary and data structure documents. Its benefits include the ability to simply use any of those elements and values, to avoid time required to adapt other existing RELs to purposes for which they may be ill suited, and to have greater syntax and value validation. One added benefit that was found in the process of creating the two test native ERMI schemas is that they were more compact than those created using either ODRL or the Creative Commons RDF. Because of this "best fit," the group believes that discussion of standardized license expression within the library and scholarly publishing communities should focus on the native ERMI alternative in the near term.

Now that the results of the DLF ERMI have been fully described, it is time to briefly consider responses to the work from the library and vendor communities and to review selected areas where members of the steering group feel that additional work is most needed.

The main reason behind the development of the ERMI was the realization that few libraries had the tools needed for successful management of e-resources and that developing such systems would be time-consuming and complex. From the beginning, the members of the ERMI steering group felt that solving such a problem would require extensive collaboration and investment. It is consequently very satisfying to report that librarians and vendors have had very positive reactions to the initiative.

--

• o The Colorado Alliance plans to improve and enhance the Gold Rush product in 2004.
• o Dynix announced development of an electronic management module during the 2004 ALA annual conference.
• o EBSCO has developed an electronic journal service that incorporates significant ERM functionality and uses an e-resource life cycle diagram in its literature.
• o Endeavor has announced plans to develop a full-function ERM product named Meridian for release in 2005.
• o Ex Libris has announced development of a product named Verde that will draw upon the SFX knowledge base. Initial release is planned by the end of 2004.
• o Harrassowitz has announced plans for HERMES 2.0, a service that will incorporate ERM features.
• o Innovative Interfaces, Inc. has developed an ERM module that is moving from development and beta testing into production.
• o Serials Solutions has an ERM product in its near-term plans.
• o SIRSI has developed a prototype system that was shown at the 2004 ALA annual conference.
• o VTLS announced plans this spring to develop an ERM product called Verify (VTLS 2004).

As these vendors develop their products and services, they and the libraries they serve inevitably will find places where the ERMI products will seem lacking or incomplete. Accordingly, they will devise new and helpful approaches to solving some of the problems sketched out in this report or to problems not yet identified. In that spirit, we would like to identify some problems that we were unable to solve within our time constraints, but that merit further work.

--

5.2.1. Consortium Support and Functionality

The ERMI has focused on the needs of individual libraries rather than on those of the library consortia to which so many libraries now belong. That has allowed rapid headway to be made, but a broader view that takes consortial support functions into account is highly desirable. Doing so is complicated by the fact that library consortia differ substantially from one another. Some, such as Ohiolink and CDL have significant amounts of central funding and a broad service mandate, while others function more as buying clubs and have correspondingly more limited missions, staffing, and goals. Nevertheless, some steps in this direction have been taken within the last several months. The extent of consortial support desired at the "central funding/broad mandate" end of this continuum was suggested in an assessment conducted for CDL (Wright 2003), which referenced the work of the ERMI. In March 2004, the University of California (UC) system libraries' System-Wide Operations and Planning Advisory Group (SOPAG) followed up on this assessment with a retreat to discuss ERM needs. Each library in the UC system sent representatives to this meeting. Although the functionality and architecture described in the ERMI documents was discussed and endorsed, attention was also given to SOPAG requirements seen needing a higher profile or not addressed in the DLF initiative. For example, CDL expends significant effort tracking which member libraries participate in which voluntary buy-in purchases and what cost shares apply. Additionally, evaluation and negotiation of e-journal packages requires the ability to track current print and e-journal subscription information at both the individual campus and consortial levels and to link to it other information such as cost, usage and Thompson ISI (Institute for Scientific Information) "impact factor." Given the likelihood that CDL libraries will continue to use different ILSs and ERM systems, the need for data standards and interoperability noted above is especially acute.

Following the SOPAG ERM retreat, two relevant sessions were held at the International Coalition of Library Consortia (ICOLC) meeting. The first session focused on consortial administrivia and offered an opportunity for consortium managers to discuss the kinds of information they must track and communicate to vendors and member libraries and related support tools they have devised. Librarians who have followed the ERM discussions would have recognized many themes, including the diversity of data needed (such as library and vendor contacts IP ranges, and renewal dates, and reliance on various spreadsheets and databases to do that work). The second session was on managing e-resources across the consortium. It featured descriptions of the work of the DLF, the UC system, and the Gold Rush product. Attendees expressed substantial interest in vendor developments, their support of consortia, and data standards. A subsequent ERMI steering group discussion of points raised during these ICOLC sessions concluded that the ERMI data model supports, or can be extended to address, key consortial requirements, but that a more careful review was needed. Since CDL is engaged in analyzing its requirements, it is conceivable that a document resulting from that process could be developed into a more generic statement of consortial ERM requirements and released under ICOLC auspices.

--

5.2.2. Usage Data

Although there is some provision for usage data within the ERMI data model, it would be desirable to better describe both the analyses libraries will perform on the data available to them and how such data might be passed more easily to libraries for incorporation into their ERM systems. Important sources for analyses of functionality are model usage-data programs such as the Data Farm developed at the University of Pennsylvania (Zucca 2003; University of Pennsylvania Libraries 2004) and ARL's E-metrics initiative (Association of Research Libraries 2004). Project COUNTER's code of practice for the "recording and exchange of online usage data" will undoubtedly become an increasingly important standard in this area, and the recently announced availability of an XML DTD for COUNTER usage reports is particularly welcome, as it will pave the way for smoother and more effortless transport of usage data.

5.2.3. Resource Succession

One issue related to the ERMI data model is that individual journals frequently pass from one publisher to another, or from platform to platform. As this happens, it may be difficult to keep track of the particular license terms, archival rights, and access information related to each change.

5.2.4. Data Standards

As important as these efforts are, they seem unlikely to succeed in the long run unless work to develop and maintain relevant data standards continues along with them.

• * Serials Description and Holdings. Knowing that the NISO/EDItEUR Joint Working Party for the Exchange of Serials Subscription Information was working to develop a standard exchange format for serials subscription data, the ERMI steering group decided to rely on that group's work rather than to develop a competing standard. The steering group regards the work of the joint working party as fundamentally important and looks forward to further developments.
• * Standard Identifiers. The steering group concluded that a single global e-resource identification system or registry for packages, providers, and interfaces could make it possible to exchange certain kinds of information far more reliably and precisely than at present.
• * License Term Expression. Resolving issues related to standardized communication about intellectual property, licensing, and permitted use will also require additional work. Luckily, there is evidence of interest in this problem. For example, discussions at the recent CONSER Summit on Serials in the Electronic Environment suggested that some publishers may be ready to experiment with providing public versions of their licenses to libraries, and there was interest in establishing a test-bed of licenses marked up in XML for

  ---

  --

  importing into local ERM systems. There have also been discussions of the possibility of establishing a standard data dictionary for publisher licensing and rights expression, using the ERMI data dictionary as a starting point.
• * Interoperability. It seems reasonable to question whether or not stand-alone ERM applications can be developed that are truly capable of integration into ILSs from other vendors. While the steering group believes that standardizing data elements is an important step in this direction, it is possible that a new initiative called VIEWS, which is aimed at "enabling web services between disparate applications used in libraries," may be another (Dynix 2004).

Resolving these issues will require organized, cooperative efforts from libraries, consortia, publishers, serial agents and support companies, and library system vendors, as well as effective structures for communicating about them.

The new electronic environment in which libraries, publishers, and vendors operate has evolved quickly and become quite complex in relatively short order, but the complexities we now recognize could pale in comparison to those that may be just around the corner--as investments in e-resources grow, technical innovation continues, and business models evolve. No matter how the environment evolves, new tools, standards, smart choices, and collaboration will be needed. We hope that the DLF ERMI has enabled all these activities to happen more quickly and to be more efficient and effective.

--

• Alan, Robert. "Keeping Track of Electronic Resources to Keep Them on Track." PowerPoint presentation, 17th Annual North American Serials Interest Group (NASIG), Williamsburg, VA, June 20-23, 2002.
• Association of Research Libraries. "Collections and Access for the 21st-Century Scholar: Changing Roles of Research Libraries. ARL: A Bimonthly Report on Research Library Issues and Actions from ARL, CNI, and SPARC, no. 225 (December 2002), http://www.arl.org/newsltr/225/index.html.
• ------. ARL Supplementary Statistics 2001-2002. Washington, D.C.: Association of Research Libraries, 2003. http://www.arl.org/stats/pubpdf/sup02.pdf.
• ------. E-Metrics: Measures for Electronic Resources. Washington, D.C.: Association of Research Libraries, 2004. http://www.arl.org/stats/newmeas/emetrics/.
• Cornell University Library. "Cornell University Library Digital Futures Plan: July 2000 to June 2002." Ithaca, NY: Cornell University Library, 2000. http://www.library.cornell.edu/staffweb/CULDigitalFuturesPlan.html.
• Cornell University Library. "Digital Library Federation Meeting, November 2002." Summary, 2002. http://www.library.cornell.edu/cts/elicensestudy/dlf2002fall/home.htm.
• Counter Online Metrics. "COUNTER: Counting Online Usage of Networked Electronic Resources," Web site, 2004. http://www.projectcounter.org/.
• Cox, John. "Model Generic Licenses: Cooperation and Competition." Serials Review 26, no. 1 (2000):3-9.
• Coyle, Karen. "Rights Expression Languages: A Report for the Library of Congress." White paper, 2004. http://www.loc.gov/standards/Coylereport_final1single.pdf.
• Cyzyk, Mark, and Nathan D.M. Robertson. "HERMES: The Hopkins Electronic Resource Management System." Information Technology and Libraries 22, no. 3 (2003): 12-17.
• Digital Library Federation. "DLF Electronic Resource Management Initiative." Project description, 2002. http://www.diglib.org/standards/dlf-erm02.htm.
• Duranceau, Ellen Finnie. "License Compliance." Serials Review 26, no. 1 (2000):53-58.
• ------. "License Tracking." Serials Review 26, no. 3 (2000):69-73.

---

--

• Dynix. Web site. Dynix. http://www.dynix.com/
• Farb, Sharon E. "UCLA Electronic Resource Database Project Overview." PowerPoint presentation, ALA Midwinter 2002, New Orleans, LA, January 18, 2002. http://www.library.cornell.edu/cts/elicensestudy/ucla/ALAMidwinter2002.ppt.
• Farb, Sharon E., and Angela Riggio. "Medium or Message: A New Look at Standards, Structures, and Schemata for Managing Electronic Resources." Library Hi Tech 22, no. 2 (2004):144-152.
• Friedlander, Amy. Dimensions and Use of the Scholarly Information Environment: Introduction to a Data Set Assembled by the Digital Library Federation and Outsell, Inc. Washington, D.C.: Digital Library Federation and Council on Library and Information Resources, 2002. http://www.clir.org/pubs/reports/pub110/contents.html.
• Hennig, Nicole. "Improving Access to E-Journals and Databases at the MIT Libraries: Building a Database-Backed Web Site Called 'VERA'." Serials Librarian 41, no. 3/4 (2002):227-254. http://www.hennigweb.com/publications/vera.html.
• International Standards Office. International Electrotechnical Commission.
• International Standard 11179, Information Technology, "Specification and
• Standardization of Data Elements." Geneva, Switzerland: ISO/IEC, 1995-2000.
• Jewell, Timothy D. Selection and Presentation of Commercially Available Electronic Resources. Washington, D.C.: Digital Library Federation and Council on Library and Information Resources, 2001. http://www.clir.org/pubs/reports/pub99/pub99.pdf.
• Johns Hopkins University Libraries. "HERMES--Hopkins Electronic Resources ManagEment System." Web site. Johns Hopkins University Libraries. http://hermes.mse.jhu.edu:8008/hermesdocs/.
• National Information Standards Organization and Digital Library Federation. "NISO/DLF Workshop on Standards for Electronic Resource Management, May 2002." Notes, slides, and other materials. Ithaca, NY: Cornell University Library, 2002. http://www.library.cornell.edu/cts/elicensestudy/nisodlf/home.htm)
• National Information Standards Organization. "NISO/EDItEUR Joint Working Party for the Exchange of Serials Subscription Information." Web site. http://www.fcla.edu/~pcaplan/jwp/.
• Nawrocki, Robert F. 2003. "Electronic Records Management," in Encyclopedia of Library and Information Science. New York: Marcel Dekker, 2003.

---

--

• Okerson, Ann S., principal investigator, Alex Edelman, Georgia Harper, Earl Hood, and Rod Stenlake. "CLIR/DLF Model License," Liblicense: Licensing Digital Information, 2001. Council on Library and Information Resources, Digital Library Federation, and Yale University Library. http://www.library.yale.edu/~llicense/modlic.shtml.
• Robek, M.F., G.F. Brown, and D.O. Stephens. 1996. Information and Records Management, 4th ed. New York: McGraw Hill, 1996.
• Stanley, Nancy Markle, Angelina F. Holden, and Betty L. Nirnberger. "Taming the Octopus: Getting a Grip on Electronic Resources." Serials Librarian 38, no. 3-4 (2000):363-368.
• Stockton, Melissa, and George Machovec. "Gold Rush: A Digital Registry of Electronic Journals." Technical Services Quarterly 19, no. 3 (2001):51-59.
• University Libraries, The Pennsylvania State University. "Data Farm." Web page, 2004. Pennsylvania State University. http://metrics.library.upenn.edu/prototype/datafarm/.
• University Libraries, The Pennsylvania State University. "ERLIC Shareware: Electronic Resources and Licensing Information Center." Pennsylvania State University Libraries, 2001. http://www.libraries.psu.edu/tas/fiscal_data/electronicresources.htm.
• Visionary Technology in Library Solutions. "'VIEWS': A Newly Created Vendor Initiative for Enabling Web Services Announced. Online article. VTLS, 2004.
• http://www.vtls.com/Corporate/Releases/2004/21.shtml.
• Warner, Beth Forrest. "Managing Electronic Resources in Today's ILMS Environment." PowerPoint presentation, ALCTS Managing Electronic Resources: Meeting the Challenge Symposium, ALA Midwinter Meeting, Philadelphia, PA, January 24, 2003. http://kudiglib.ku.edu/Personal_prsns/ALA_Preconf_2003MW.htm.
• Cornell University Library. "Web Hub for Developing Administrative Metadata for Electronic Resource Management." Web site. Cornell University Library. http://www.library.cornell.edu/cts/elicensestudy/.
• Wright, Alex. "California Digital Library Electronic Resource Management Assessment: Final Report." Oakland, CA: California Digital Library, 2003.
• Zucca, Joseph. "Traces in the Clickstream: Early Work on a Management Information Repository at the University of Pennsylvania." Information Technology and Libraries 22, no. 4 (2003):175-179.

--

Ivy Anderson, Sharon E. Farb, Adam Chandler, Timothy Jewell, Kimberly Parker, Angela Riggio, and Nathan D. M. Robertson

The goal envisioned in these requirements is a system that supports management of the information and workflows necessary to efficiently select, evaluate, acquire, maintain, and provide access to e-resources in accordance with their business and license terms. Such a system should support the service requirements of e-resources while building on existing investments in library technology, through seamless interaction and efficient sharing of data with traditional MARC-based online catalogs, Web portals, federated searching tools, local resolution services, local authentication and access-management systems, and traditional library-management functions. Whether implemented as a stand-alone system or as part of an existing library-management system, the ERM functions should complement, rather than duplicate, the capabilities of other systems deployed by the library.

This document outlines the broad areas of functionality that are required in such an ERM system. It is not intended, at this stage of development, to be a detailed description of every function needed, but rather to provide an overview of the main functions required of the system. The examples under each functional area are representative and illustrative, rather than exhaustive.

The ERM system should offer an integrated environment that supports both management and access, without maintaining duplicate systems. The system should offer a capacity for global updating and flexible addition of fields. It should offer the ability to hide fields and records from public view and have a single point of maintenance for each data element. It should support interoperation and dynamic data sharing with existing OPACs, Web portals, library-management systems, and link resolution services. It should offer users consistent information, regardless of the path they take in seeking it. Finally, the ERMS should, over time, support the ability to store, access, search, and generate reports of the information that it contains.

FUNCTIONAL REQUIREMENTS

General Requirements

--

The ability to support complex, multiple-to-multiple relationships that accurately map how resources, business terms, licenses, and other components interrelate is an essential building block for supporting the functionality described throughout this document.

The companion Entity Relationship Diagram for Electronic Resource Management (see Appendix C) presents a schematic representation of these relationships.

For all areas of functionality described in this document, it must be possible to

• 1. Identify what bibliographic entities (electronic and print) are covered by or provided through a given license, set of business terms, package, or online interface platform (hereinafter "interface");
• 2. Associate the characteristics of a given license, set of business terms, package, or interface with all the bibliographic entities (electronic and print) to which they apply;
• 3. Offer security features to control staff views and maintenance rights
  • 3.1. hide confidential information from certain staff
  • 3.2. restrict the ability to add, update, or delete certain data (field by field) to designated staff
  • 3.3. provide the ability to construct simplified data views by hiding unused fields; and
• 4. Perform ad hoc queries and generate reports across a broad range of fields and table values.

Resource-Discovery Requirements

While adequate facilities for searching and browsing for e-resources already exist in OPACs and portals at many libraries (through searches of author, title, alternate titles, cross-references, subjects, keywords, and other descriptors), facilities to cull e-resources for resource-discovery purposes are lacking at other institutions. Ideally, the ERM system should provide a user interface for libraries that require one as well as a means of integrating appropriate license data into the results of searches within externally deployed systems.

The ideal system should also provide Web developers database table- or view-level access and the ability to bypass the native interface to query and present data to the user in any number of custom-configurable ways. An ERMS implementation should include a dedicated user interface that is able to capture appropriate data in other systems or to share its information with elements in other supported systems to create unified user displays, including the capabilities described below.

It should be possible to:

• 5. Make resources available through or pass on information about resources to OPACs and Web-presentation services using traditional resource discovery methods, including the ability to search and browse by author, title, alternate titles, cross-references, subject, and keywords, facilitate the generation of dynamic, database-driven

  ---

  --

  Web pages that constitute pathfinders, course- or discipline-specific pages, or lists of selected e-resources in a given subject area and of a given type (e.g., e-journals, article databases) while supporting fully customizable presentation templates that are not limited to the branding and look and feel of the native interface;
• 6. Offer contextual presentation of relevant license information to the user at the point of access, regardless of the access path taken through any supported tool,
  • 6.1. make apparent to users whether or not they are authorized for access under the license
  • 6.2. display relevant permitted uses, use restrictions, and special requirements such as:
    • 6.2.1. permission to use in course packs, course Web sites, and distance education
    • 6.2.2. unusual prohibitions, such as record download limits and time of day restrictions
    • 6.2.3. citation requirements;
• 7. Support site-defined and auxiliary descriptive data. Such data might include:
  • 7.1. locally defined fields for descriptive needs not covered in existing MARC records
  • 7.2. a free-form note
  • 7.3. locally defined lists and descriptors;
• 8. Make available information about and provide access to other versions of the resource being viewed, including links to catalog holdings information for physical manifestations and direct links to all accessible electronic versions;
• 9. Make available information about issues particular to the online interface, such as inaccessible or nonsubscribed portions not marked as such at the site, unusual log-on and log-off requirements, and navigation or accessibility features;
• 10. Flag resources as unavailable in real time, with an optional explanatory note (see also Administrative and Management Functions); and
• 11. Offer advisory notices of planned downtime and other time-sensitive information.

Bibliographic Management Requirements

In many libraries, both traditional and auxiliary bibliographic data may be distributed among a variety of systems, including the library-management system, a federated searching portal, and a link resolution service. Nevertheless, to the extent possible, each unique data element should have to be maintained only once. Updates in one system should be automatically reflected in corresponding systems, either through the dynamic sharing of data or, where redundant storage cannot be eliminated, by propagation to other systems. Loading of data from external systems should also be supported.

--

Specifically, it should be possible to:

• 12. Provide a single point of maintenance for bibliographic and auxiliary descriptive data that can be exchanged or shared between the OPAC, portal lists, federated search tools, local resolution services, and other bibliographic systems and services; and
• 13. Import subscription-management data from external providers using standard software and developing protocols,
  • 13.1. lists of titles, ISSNs, and uniform resource identifiers (URIs) delivered in Excel or delimited format
  • 13.2. changes to titles and dates of coverage in aggregated databases communicated via any XML-based or standards-based data transfer protocol, such as ONIX for serials
  • 13.3. holdings updates supplied by a publisher or subscription agent to facilitate electronic check-in.

Access-Management Requirements

All libraries rely on authentication and access-management systems that are external to the systems and tools described in this document. These external systems may be as straightforward as reliance on the remote-authorization mechanism of an online provider (via IP addresses or user names and passwords) or as complex as a locally developed access-management service that assigns persistent identifiers to resources, passes connection requests to a system that validates users according to a local authentication scheme (e.g., Kerberos), and routes valid users through a proxy server. Institutions with complex local environments can be expected to have customized systems and tools with which to perform these functions, and the ERM system must interoperate with them.

The ERMS should accommodate both simple and complex environments with a disparate range of needs. To accomplish this, the following generalized requirements are necessary:

• * Management of basic access-related information, such as URIs, user IDs and passwords, and lists of institutional IP addresses;
• * Support for the creation of persistent URIs and for additional data elements required to support complex local access management services, such as proxy servers; and
• * A set of export functions by which an ERMS can communicate its information to a local system or service.

Specifically, it should be possible to:

• 14. Store and maintain access URIs and make these actionable for end users, according to local requirements:

  ---

  --

  • 14.1. store vendor-supplied primary and secondary URIs (e.g., for mirror sites) used for access to the resource
  • 14.2. support the creation, storage, and updating of persistent URIs and/or integration with external systems for managing persistent identifiers
  • 14.3. support authentication and access systems (such as proxy servers or statistics- generating scripts), allowing for URIs to be constructed on the fly on the basis of stored data elements
  • 14.4. generate notifications and/or exports of URI information to appropriate linked or external systems according to local requirements (e.g., notification or export to cataloging and information technology departments or systems)
  • 14.5. provide seamless functional integration with external systems that record this information (e.g., through a shared pointer);
• 15. Integrate proxy server/access management with other functionality
  • 15.1. provide a means for seamless integration of proxy server access for all or selected users and all or selected resources;
• 16. Store lists of IP addresses used to register access to specific resources and provide automated e-mail notification to online providers when IP addresses are updated,
  • 16.1. support the creation and maintenance of multiple lists of IP addresses that can be associated or disassociated with one or more licensed locations and linked to one or more bibliographic entities
  • 16.2. for a given resource or online provider, indicate whether IP addresses are/were registered online and record the registration URI
  • 16.3. send automated e-mail notifications to vendors and providers when IP addresses are updated and record the date on which notifications are sent. Include the ability to record an acknowledgment date. This implies the ability to designate a vendor or provider contact address for IP address-notification purposes;
• 17. Store one or more user IDs and passwords and provide the ability to generate secure screen displays of this information for authorized users and staff, with associated text or for JavaScript autosubmission; and
• 18. Implement access restrictions,
  • 18.1. record authorized user categories and authorized sites, including the ability to associate specific actions with those elements, such as:
  • 18.1.1. generating staff and user displays
  • 18.1.2. implementing access controls
  • 18.1.3. exporting information to a local access-management system (technical system in use at your institution such as an authentication system and/or proxy server (see also Resource Administrative and Management Functions).

--

STAFF REQUIREMENTS

Staff Interface

An ERM system requires a staff interface that enables library staff to efficiently carry out the work described in the sections that follow. The interface should be organized into views that are optimized for particular areas of staff activity or interest, such as resource acquisition, troubleshooting, license administration, or administration and statistics. Details of appropriate interface design are not addressed in these requirements; these are left to the art and discretion of system developers.

Through this interface, staff should be able to:

• 19. Search, browse, and retrieve records by attributes unique to e-resources, such as license, vendor, interface, record status, licensed site, consortium, and library selector or other local contact individual;
• 20. View the full range of information appropriate to the staff member's security profile and functional role;
• 21. To the extent possible, link to other relevant information stored in library management systems, portals, or related systems; and
• 22. View records that are hidden from the public.

Selection and Evaluation Process

During the selection and evaluation process, it is typically necessary for a decentralized group of individuals to coordinate a complex and iterative series of steps. The ERM system should provide support for recording actions at each of these steps and be capable of performing specified actions upon completion of a given task and of sending alerts when anticipated actions do not occur.

A typical selection and evaluation process might involve the following steps and require the following reminders and notifications, all built from stored action dates and locally definable status fields:

• * Build request record for trial;
• * Flag resource as trial;
• * Notify interested parties that trial is live and provide the access instructions and expiration date (triggered by trial start date and e-mail address[es] input into request record);
• * Allow staff (and, optionally, users) to access the trial via stored URL;
• * Send reminder to those notified of a trial that expiration date is near (triggered by trial end date and e-mail address[es] input into request record);
• * Record opinions of key players and final purchase decision, allowing for both central and local input of opinions and funding commitments into notes fields in request record;

---

--

• * Prompt licensing/acquisitions contact to report purchase decision (triggered by decision date input into request record). The most common options are "Approve," "Reject," or "Put on Hold"; and
• * For resources that are approved for purchase, additional statuses and actions would be required, including
• * notify licensing contact to obtain and negotiate license, and remind this contact if license is not completed by a given deadline (triggered by stored licensing contact, notification of approved status, and deadline input at time of approval)
• * notify access contact if status has not changed to "live" by deadline (triggered by inputting likely access date into system at time of approval)
• * notify cataloging and selector/product sponsor, as well as other interested parties, when access is available (triggered, for example, by changing status to "Live" and by stored e-mail address[es] related to this purchase).

The companion Electronic Resource Management Workflow Flowchart provides a detailed diagrammatic view of workflow decision and action points (see Appendix B).

To support these processes, it should be possible to:

• 23. Create provisional records for resources that may or may not be permanently acquired and track the selection and evaluation process through acquisition or rejection;
• 24. Assign locally definable status fields to request records and associate particular actions with those statuses. Examples of such fields include "New Request," "On Trial," "Trial Expired/Decision Pending," "Approved," "Rejected," and "On Hold";
• 25. Assign locally definable fields to request records for license routing and status and associate particular actions with those fields. Site should be able, for example, to define a list of individuals from whom sign-off is required, send reminders to license reviewers, and record approval or rejection status, with notes;
• 26. Assign multiple local contact individuals and site-defined roles to both request records and permanent resource records;
• 27. Send e-mail notifications to individuals designated as local or licensing contacts;
• 28. .Make trial resources available in a secure manner through the library's resource tool of choice to authorized users (if wanted) and staff
  • 28.1. store trial URIs and passwords and make these available, securely if necessary
  • 28.2. flag items unambiguously as trial resources, with associated public and staff notes
  • 28.3. record a trial expiration date and, optionally, send an alert to designated recipients n days prior to trial expiration;

---

--

• 29. Record a decision due date and, optionally, send an alert to designated recipients n days prior to decision date;
• 30. Establish a site-defined routing workflow for resources that are approved for purchase. For example, it should be possible to send notifications to designated staff or departments or to place resources in a queue for further action by those units to trigger actions such as the placing of an order, completion of cataloging, and implementation of access management by designated staff; and
• 31. Purge rejected records from the system, sequester into a history archive, or retain such records with notes about the decision process (including a link to written evaluations if wanted), at the library's discretion.

Resource Administration and Management Functions

The functions described in this section pertain to activities required to fulfill license obligations and to administer and support resources that have been acquired. Some of the data and functions pertain to the license itself, while others pertain to the management of individual resources. The system should be able to record data at the most efficient level required to avoid redundancy, relying on the relationships among entities to make the information available at other applicable levels (e.g., individual resource, package, or interface).

It should be possible to:

• 32. Store license rights and terms for reference, reporting, and control of services
  • 32.1. for services including, but not limited to, interlibrary loans, reserves, distance education, course Web sites, and course packs,
    • 32.1.1. identify whether a given title may be used for the service and under what conditions
    • 32.1.2. generate reports of all materials that may or may not be used for the service with notes about under what conditions, and
  • 32.2. include a mechanism for adding new services, allowing staff to specify the name of the service and associated actions such as public displays, reports, and alerts;
• 33. Record the categories of users and sites that are authorized for access to a given resource and generate displays for end users and staff on the basis of this information (see also Access Management Requirements);
• 34. Support breach investigation and cure activities and other activities that may be required to fulfill license obligations

  ---

  --

  • 34.1. record the cure period for breach and generate alerts at library-specified intervals on the basis of this information when a breach has been reported
  • 34.2. provide a breach-incident log in which to record reports of alleged breaching activity, including date and source of initial report, open/closed status, resolution date, and actions taken. This should have the capability of generating reports on commonalities of breaches (e.g., type of breach, department showing regular breaches)
  • 34.3. include a mechanism for adding fields in which to record unusual compliance requirements that the library may want to track, including implementation status and date and the ability to generate reports or alerts on the basis of this information. Examples might include a requirement to post notices to end users or to destroy locally held copies upon termination (see also Termination Activities);
• 35. Record additional license terms and metadata for contract management and auditing purposes, such as license commencement date, duration of agreement, confidentiality provisions, and other site-definable key terms;
• 36. Provide the ability to display or link to an online version of a license agreement;
• 37. Manage the library's archival rights in electronic content,
  • 37.1. record whether permanent rights to the year level exist in a given resource and, if so, their source, dates of coverage, manner of execution, and the applicable license through which rights are provided. It should be possible to associate multiple archival field clusters with a given resource to track successive rights with multiple providers
  • 37.2. retain archival versions of license terms and conditions if desired, so that preexisting terms of agreement can be mapped to the bibliographic entities and dates for which such terms applied;
• 38. Support the administration of e-resources,
  • 38.1. store administrative URIs, IDs and passwords, and associated notes and make them available to authorized staff
  • 38.2. store subscriber numbers used to register online journals that are tied to print
  • 38.3. provide the following capabilities for configuration options, including but not limited to features such as institutional branding, hooks to holdings, Z39.50 and OpenURL support,
    • 38.3.1. identify whether a given title supports the feature and whether it has been implemented, with associated notes
    • 38.3.2. generate reports of all materials that do or do not support the specified feature, including implementation status

    ---

    --

    • 38.3.3. include a mechanism for adding new features, allowing staff to specify the name of the feature, implementation status, notes, and associated actions such as report generation,
  • 38.4. record the number of licensed concurrent users for a given resource, interface, or pooled user group (including pooled consortium users)
  • 38.5. record cataloging-related data such as,
    • 38.5.1. the availability and quality of MARC records for package items that include individual entities, including the status of loading or prioritization and additional notes
    • 38.5.2. the person or unit responsible for cataloging, if applicable
    • 38.5.3. related specifications, such as specific entries or other data to be included in cataloging records;
• 39. Support library instructional activities,
  • 39.1. store information about training accounts (URIs, IDs and/or passwords) and other user instruction arrangements and make these securely available to staff arranging for training classes and (optionally) to end users
  • 39.2. record information about and/or provide links to available documentation for staff and end users
  • 39.3. record information about and/or provide links to training classes;
• 40. Support management of and access to usage statistics,
  • 40.1. indicate whether usage statistics are provided, and record associated data such as frequency, delivery method, and available format(s)
  • 40.2. record URIs and IDs and passwords for access to online statistics
  • 40.3. store or provide information about and/or links to locally stored data
  • 40.4. if local storage of usage statistics is supported, provide the ability to download locally stored data into a spreadsheet for manipulation purposes
  • 40.5. generate staff displays for access to usage data
  • 40.6. provide a note field for special information pertaining to usage statistics (e.g., missing time periods or data errors)
  • 40.7. generate reports or notifications indicating when usage statistics should be available, based on the frequency parameter established in 40.1;
• 41. Support the troubleshooting of access and performance-related problems,
  • 41.1. record the amount or percentage of allowable downtime provided in the license agreement for performance monitoring purposes
  • 41.2. store information about the provider's normal maintenance window, and include the ability to display this information to the end user
  • 41.3. store information on locally defined notes for local performance monitoring Web sites/programs

  ---

  --

  • 41.4. display URI of server status provided by vendor
  • 41.5. display to staff who perform troubleshooting elements such as URI and proxy information, hardware and software requirements, number of licensed concurrent users, subscription expiration dates, local contact information (site-defined), and vendor contact information
  • 41.6. provide the ability to flag resources as temporarily unavailable, with both staff and public notes. It must be possible to apply the flag to individual titles, to all titles in a given package, or to all titles that use a given online interface (see End- User Requirements)
  • 41.7. integrate a support incident log into the system to record and track problems, including date and source of initial report, category and description of problem, open/closed status, resolution date, and a record of actions taken,
    • 41.7.1. provide the ability to route open problem reports to appropriate local contacts for further action including email capability for routing of problem/troubleshooting reports
    • 41.7.2. generate alerts for unresolved problems at site-defined intervals
    • 41.7.3. generate incident history reports on demand by resource, package, interface, and vendor for performance monitoring and auditing purposes,
  • 41.8. [Desirable]: calculate the duration of downtime incidents based on data recorded in the log, and generate an alert if downtime exceeds the amount or percentage of allowable downtime provided for in the license agreement; and
• 42. Facilitate communication with vendors,
  • 42.1. record multiple vendor contacts, including name, title, e-mail address, phone, and fax numbers, including the ability to assign site-defined contact roles. It should be possible to assign multiple roles to a single contact (technical support, customer support, sales, billing support)
  • 42.2. provide the ability to generate standard notifications of IP addresses and changes to vendors
  • 42.3. record official contract notice address and associated requirements (e.g., delivery requirements)
  • 42.4. provide the ability to generate email messages to designated technical support contacts from data in the incident log.

Business Functions

Many of the business activities described here are related to, and may already be accomplished through, functionality that exists in a traditional library learning management system. Although item 44 in this section affirms the general requirement to support traditional acquisitions-related functions, such as ordering, fund accounting, and the ability to commit and expend budgets and to generate budget reports, it does not attempt to describe these requirements in detail, on the assumption that full acquisitions functionality will continue to reside within a library management system. These

--

It should be possible to:

• 43. Make complex business information available to staff,
  • 43.1. store a description of the pricing model applicable to the resource
  • 43.2. know what license agreement is applicable to a given set of business terms
  • 43.3. know what print resources are subscribed to that are part of a package
  • 43.4. where there are restrictions on cancellation of print subscriptions
    • 43.4.1. record this information
    • 43.4.2. if the system is integrated with a library management system that supports print resources, warn (or block with override by authorized staff) attempts to cancel print subscriptions
  • 43.5. where price caps exist for multiyear agreements
    • 43.5.1. record this information
    • 43.5.2. calculate renewal invoices to ensure that price caps are not exceeded, where possible
  • 43.6. if the system is integrated with a library management system that supports print resources, prompt the library to evaluate retention of associated print subscriptions at renewal;
• 44. Facilitate the acquisitions process,
  • 44.1. perform traditional acquisitions functions such as:
    • 44.1.1. fund accounting
      • 44.1.1.1. commit, expend, and update budgets
      • 44.1.1.2. Produce budget and expenditure reports
    • 44.1.2. ordering
      • 44.1.2.1. ability to assign and issue purchase orders in any standardized format or protocol. For example, print, e-mail, or EDI transactional transmissions such as X.12, EDIFACT, or other XML-based suites
      • 44.1.2.2. purchase orders should accommodate site-defined data elements unique to e-resources, such as IP addresses and activation instructions
    • 44.1.3. invoice payment
  • 44.2. support cost sharing among departments and fund lines based on fixed numbers, percentages of some characteristic such as use, total budget or population, or special formulas
  • 44.3. support the ability to pay from one fund and charge costs against multiple funds belonging to distinct budget or administrative units according to the above algorithms;
• 45. Facilitate cooperation with consortial partners in a license agreement,

  ---

  --

  • 45.1. for resources acquired through a consortium, record the name of the consortium, relevant notes, and, optionally, the names of other participating institutions or the materials available as a result of participation of consortial partners
  • 45.2. store name and contact information for key consortial contacts;
• 46. Facilitate the renewal process,
  • 46.1. record the expiration date and update this date automatically upon renewal
  • 46.2. record the advance notice period for renewal (in the form n days prior to expiration), and calculate a renewal notification date based on this information
  • 46.3. generate a report or send an alert to designated recipients n days prior to renewal-notification date, with associated note. It should be possible to assign a system default period that can be overridden for a given resource (similar to existing claim functions)
  • 46.4. record whether renewal is automatic or explicit and generate an action report and/or alert N days prior to renewal or notification date for resources requiring explicit renewal
  • 46.5. record renewal action or decision and date
  • 46.6. provide pointers or links to written evaluations associated with renewal decisions; and
• 47. Facilitate termination actions and decisions,
  • 47.1. record whether termination by the library during the contract term is permitted, and if so, record the advance-notice period and applicable conditions (e.g., breach, specific nonperformance, any)
  • 47.2. record whether termination by the licensor during the contract term is permitted, and if so, record the advance-notice period and applicable conditions (e.g., breach, specific nonperformance, any)
  • 47.3. store the termination date and reason for termination
  • 47.4. provide pointers and/or links to written evaluations associated with termination
  • 47.5. record license conditions to be fulfilled upon termination (such as the requirement to destroy locally held copies) and generate alerts based on this information (see also Resource Administrative and Management Functions)
  • 47.6. provide the ability to archive licensing information for noncurrent licenses whose terms remain applicable to previously licensed material
  • 47.7. provide the ability to manage, record, and report on permanent or perpetual access rights following termination of a current agreement.

--

Kimberly Parker, Nathan D. M. Robertson, Ivy Anderson, Adam Chandler, Sharon E. Farb, Timothy Jewell, and Angela Riggio

The Electronic Resource Management Workflow Flowchart provides a detailed overview of the activities associated with managing the life cycle of electronic products, and is intended to be generally applicable to the processes followed at most institutions. The flowchart highlights functions and processes that are necessary for the acquisition and ongoing management of electronic products. While there are some similarities between the acquisition and management processes for traditional physical library materials and those for electronic products, there are many issues and complexities unique to electronic products. The following overview diagrams of physical resource and e-resource workflows highlight the similarities and differences between the two processes:

As the diagrams illustrate, there are substantial differences between physical and electronic product management. Electronic products routinely require a licensing process, and may pose technological challenges for implementation. Acquiring and activating an electronic product differs substantially from

--

Throughout the flowchart a number of processes are depicted in detail while others are not. The processes with detailed workflow representations are those where most institutions proceed in a similar fashion and where the processes for electronic products diverge fairly significantly from physical formats. Processes without great detail in the workflow are either those where different institutions have differing processes or those where traditional workflows (with perhaps minor variations) are employed in processing the electronic products.

The following diagram is the complete Electronic Resource Management Workflow Flowchart. (Note that page references within the flowchart refer to chart pages, not pages of this appendix). Explanatory endnotes follow the diagram.

--

--

1. A decision to "proceed" indicates that the product's content has been evaluated during the preceding consideration process and a serious effort to acquire the product should begin.

2. While the parallel processes represented on page 2 are shown as following after a trial period if one takes place, in some cases the parallel processes may begin during the trial period if one is held, and the trial will assist in answering questions raised during the parallel review processes.

3. "Technically feasible?" represents a review of whether the product will function without difficulty within the institution's technical environment, or, if not, whether an acceptable level of effort will allow the product to function.

4. "Business issues" embodies an extensive list of important concepts. Among the items that might be investigated in this grouping are: price, archival needs, interface trajectory, vendor quality, branding capability, usage statistics, MARC record availability and price (if appropriate), instructional ports/accounts (if appropriate), OpenURL compliance, deep-linking capability, etc.

5. It is entirely possible that the license will already be signed by this point, or that the license signing process is completely divorced from the order process. The "order/register/formally sign license" action point is completed when the institution has formally committed to acquiring the product in every way necessary.

6. The action of notifying catalogers and service administrators (e.g. proxy server manager, OpenURL resolver manager, broadcast search service manager, etc.) may occur at any number of points. This item was placed early in the workflow diagram to emphasize that some products are problematic for service managers and early notification is often very beneficial.

7. "Routine product maintenance" encompasses a large array of functions not detailed here. Among the functions included in this concept are the capture of usage statistics, troubleshooting and resolving problems, routine product changes from the vendor (such as URL revisions), revisions to public documentation, etc.

8. "Product review" on page 4 is simply a truncated form of the review of a new product that occurs on page 2. The extent of the review may vary from product to product and from institution to institution.

--

Nathan D. M. Robertson, Ivy Anderson, Adam Chandler, Sharon E. Farb, Timothy Jewell, Kimberly Parker, and Angela Riggio

This document is an entity relationship diagram (ERD) for a system to manage e-resources. An ERD is a model that identifies the concepts or entities that exist in a system and the relationships between those entities. An ERD is often used as a way to visualize a relational database: each entity represents a database table, and the relationship lines represent the keys in one table that point to specific records in related tables. ERDs may also be more abstract, not necessarily capturing every table needed within a database, but serving to diagram the major concepts and relationships. This ERD is of the latter type, intended to present an abstract, theoretical view of the major entities and relationships needed for management of e-resources. It may assist the database design process for an ERM system, but does not identify every table that would be necessary for an e-resource management database.

This ERD should be examined in close consultation with other components of the Report of the DLF Electronic Resource Management Initiative, especially Appendix D (Data Element Dictionary) and Appendix E (Data Structure). The ERD presents a visual representation of e-resource management concepts and the relationships between them. The Data Element Dictionary identifies and defines the individual data elements that an e-resource management system must contain and manage, but leaves the relationship between the elements to be inferred by the reader. The Data Structure associates each data element with the entities and relationships defined in the ERD. Together, these three documents form a complete conceptual data model for e-resource management.

There are several different modeling systems for entity relationship diagramming. This ERD is presented in the "Information Engineering" style. Those unfamiliar with entity relationship diagramming or unfamiliar with this style of notation may wish to consult the following section to clarify the diagramming symbology.

ENTITIES

Entities are concepts within the data model. Each entity is represented by a box within the ERD. Entities are abstract concepts, each representing one or more instances of the concept in question. An entity might be considered a container that holds all of the instances of a particular thing in a system. Entities are equivalent to database tables in a relational database, with each row of the table representing an instance of that entity.

--

Remember that each entity represents a container for instances of the thing in question. The diagram below has an entity for student and another for school. This indicates that the system being modeled may contain one or more students and one or more schools.

So far, no relationship between students and schools has been indicated.

RELATIONSHIPS

Relationships are represented by lines between entities. Relationship lines indicate that each instance of an entity may have a relationship with instances of the connected entity, and vice versa.

The diagram above now indicates that students may have some relationship with schools. More specifically, there may be a relationship between a particular student (an instance of the student entity) and a particular school (an instance of the school entity).

If necessary, a relationship line may be labeled to define the relationship. In this case, one can infer that a student may attend a school, or that a school may enroll students. But if necessary, this relationship could be labeled for clarification:

Read the first relationship definition, attends, when tracing the relationship left to right or top to bottom. Read the second definition, enrolls, when tracing the relationship right to left or bottom to top.

OPTIONALITY AND CARDINALITY

Symbols at the ends of the relationship lines indicate the optionality and the cardinality of each relationship. Optionality expresses whether the relationship is optional or mandatory. "Cardinality" expresses the maximum number of relationships.

As a relationship line is followed from an entity to another, near the related entity two symbols will appear. The first of those is the optionality indicator. A circle ( ( ) indicates that the relationship is optional--the minimum number of relationships between each instance of the first entity and instances of the related entity is zero. One can think of the circle as a zero, or a letter "O" for optional. A stroke ( | ) indicates that the relationship is mandatory--the minimum number of relationships between each instance of the first entity and instances of the related entity is one.

--

The second symbol indicates cardinality. A stroke ( | ) indicates that the maximum number of relationships is one. A crow's-foot () indicates that many such relationships between instances of the related entities might exist.

The following diagram indicates all of the possible combinations:

In our model, we wish to indicate that each school may enroll many students, or may not enroll any students at all. We also wish to indicate that each student attends exactly one school. The following diagram indicates this optionality and cardinality:

It is important to note that relationship optionality and cardinality constraints apply specifically to the system being modeled, not to all possible systems. According to the example modeled above, a school might not enroll any students--that relationship is optional. A school without students is not much of a school, and indeed if the system being modeled were a school system enrollment database, the relationship would probably be mandatory. However, if the system being modeled is an extracurricular honors program, there may be schools that have no students currently participating in the program. Consider the function of the system and consult the other documents in the data model to clarify modeling decisions.

--

BRIDGE ENTITIES

When an instance of an entity may be related to multiple instances of another entity and vice versa, that is called a many-to-many relationship. In the example below, a supplier may provide many different products, and each type of product may be offered by many suppliers:

While this relationship model is perfectly valid, it cannot be translated directly into a relational database design. In a relational database, relationships are expressed by keys in a table column that point to the correct instance in the related table. A many-to-many relationship does not allow this relationship expression, because each record in each table might have to point to multiple records in the other table.

In order to build a relational database that captures this relationship, it is necessary to build a bridge between the two entities that uniquely expresses each relationship instance. This can be modeled in an ERD with a bridge entity, an entity box containing a diamond, which may replace the many-to-many relationship. (The diamond is used in other ER modeling systems to indicate relationships, or may be viewed as the joining--the bridge--of the many-to-many crow's-feet).

This diagram expresses the same relationship as the diagram above. Each instance of the provides bridge entity indicates that a certain supplier can provide a certain product.

In addition to explicitly depicting a relational database structure that can capture a many-to-many relationship, the bridge entity has an additional function in abstract entity-relationship modeling: A bridge entity may capture attributes that are specific to the relationship between instances of the bridged entities. In the supplier and product example, a product does not have an inherent cost; it only has a cost in relation to the supplier who sells it. Similarly, a supplier may not have a uniform delivery time; delivery times may vary in relation to the product being delivered. Any attributes that are dependent on the relationship would be associated with the relationship's bridge entity.

RECURSIVE RELATIONSHIPS

Instances of entities may have relationships with other instances of the same entity. These relationships may be drawn with relationship lines that begin and end connected to the same entity. Common occurrences of these recursive relationships include parent/child relationships:

--

The diagram above indicates that a person may be the father of zero or many persons, and that a person may have zero or one father. (Not every person's father will be recorded in the system, so the relationship is modeled as optional).

MULTIPLE RELATIONSHIPS BETWEEN ENTITIES

An entity may have multiple relationships with another entity. These are depicted in the ERD with multiple relationship lines connecting the two entities:

The diagram above indicates that an employee may be the salesperson assigned to zero or many clients, and an employee may be the customer service representative for zero or many clients. Each client has exactly one salesperson and exactly one customer service representative. Each client's salesperson may or may not be the same employee as the client's customer service representative; each relationship is treated independently.

ENTITY SUBTYPES

There are times when it is convenient to depict relationships that apply to an entire class of things, as well as depict relationships that apply only to certain types of the larger class. Entity subtypes accommodate these relationship depictions. In the ERD, entity subtypes may be depicted by entity boxes shown within larger entity boxes. The large entity represents the class, and the smaller boxes depict the subtypes.

--

The example above depicts an inventory entity, with the subtypes of vehicle and part. A vehicle has one or many parts, and every part is associated with one and only one kind of vehicle (according to this diagram, there are no interchangeable components). All items in inventory, whether they are vehicles or parts, have a manufacturing location, but only vehicles are of a particular model.

EXCLUSIVE-OR RELATIONSHIP

If an entity instance may have either one relationship or another, but not both, the constraint may be modeled with an exclusive-or relationship, represented as a tree with a solid dot where the tree branches. The entity attached to the trunk of the tree is the one subject to the exclusive-or constraint. No relationship is indicated between entities attached the branches.

The diagram above indicates that each convict is assigned to a prison, or to a parole officer, but not both. A prison may have zero or many convicts, a parole officer may have zero or many convicts, and there is no relationship between prisons and parole officers.

INCLUSIVE-OR RELATIONSHIP

If an entity instance may have either one or more relationships, but must have at least one of the possible relationships, the constraint may be modeled with an inclusive-or, represented as a tree with a hollow dot where the tree branches. As with the exclusive-or constraint, the entity attached to the trunk of the tree is the one subject to the constraint, and the entities attached to the branches are not related to one another by this construction.

--

The diagram above indicates that a farm must have either livestock or a crop, or may have both. Any given type of livestock may belong on zero or many farms, and any given type of crop may be grown on zero or many farms.

The following diagram is the complete Entity Relationship Diagram for Electronic Resource Management. It presents an abstract, theoretical view of the major entities and relationships needed for management of e-resources:

--

--

Unlike other modeling systems, entity relationship diagrams (ERDs) do not explicitly depict situations in which entity instances are expected to inherit attributes or relationships of related entity instances.

This data model assumes the following relationship inheritance constraints:

• An e-resource may inherit its interface's relationship with an acquisition, administrative information, or access information. Alternatively, the e-resource may have a separate acquisition, administrative information, and/or access information from its interface.
• An e-resource must inherit its interface's relationship or relationships with licenses (and with the terms defined by the interface's licenses--although different terms from a different license may prevail for the e-resource).
• An e-resource may inherit its parent e-resource's relationship with an acquisition, administrative information, or access information. Alternatively, the child e-resource may have a separate acquisition, administrative information, and/or access information from its parent.
• An e-resource must inherit its parent e-resource's relationship or relationships with licenses (and with the terms defined by the parent's licenses--although different terms from a different license may prevail for the child e-resource).

Although the overall diagram is large and complex, most of the entities and relationships depicted in the ERD are relatively straightforward, and can be fully understood in consultation with the definitions provided in Appendix D (Data Element Dictionary) and Appendix E (Data Structure).

Several of the relationships depicted merit further explanation.

ELECTRONIC PRODUCT AND ITS SUBTYPES

The electronic product entity represents electronic things that may be acquired, licensed, or managed. Electronic product encompasses interfaces, e-resource packages, packages of packages, and individual e-resource titles.

--

Many attributes and relationships are shared by all electronic products, regardless of whether the electronic product is an interface, package, or individual title. For example, all types of electronic products may be licensed, may be acquired, may undergo a product trial, etc. On the other hand, interfaces and e-resources do have some unique characteristics and in certain cases need to be handled in distinct ways. The electronic product entity and its subtypes accommodate the depiction of these relationships.

E-RESOURCE RECURSIVE RELATIONSHIP

The e-resource entity represents e-resource packages, packages of packages, and individual e-resource titles. Any given e-resource title may be a standalone product, or may be a part of an e-resource package. An e-resource package could in turn be part of a larger package. These possible relationships are accommodated with the optional recursive relationship for e-resources:

THE ORGANIZATION ENTITY

The organization entity represents any business, vendor, provider, publisher, licensor, etc. with which a library does business related to electronic products. Generally, one records the same attributes of an organization, such as name and address, regardless of the role the organization plays. Furthermore, a single organization frequently fills several roles in the e-resource management environment, functioning as vendor, licensor, publisher, and/or provider.

--

Rather than create separate entities for each role, which may contain duplicate instances of one another, the model contains the single organization entity, with the role or roles of the organization dependent on the relationship or relationships in which the organization participates:

For definitions of the roles indicated by these relationships, see Appendix D (Data Element Dictionary) and Appendix E (Data Structure).

TERMS DEFINED AND PREVAILING TERMS

Each license and each acquisition defines (or may define) a set of associated rights and restrictions on the usage and management of the electronic products covered by the license or acquisition. In some cases, certain terms are defined in licenses, while in other agreements those same term concepts might be defined in the business agreement. To accommodate the uncertainty of where certain rights, responsibilities, and other terms might be defined in any given situation, we have modeled a separate terms defined entity:

The terms defined entity is able to record all possible rights, responsibilities, and other terms, including terms that are typically defined in licenses (such as "interlibrary loan" or "scholarly sharing" permissions), as well as terms that are typically defined in acquisitions or business terms (such as "number of concurrent users").

--

Use, rights, and restrictions for any given e-resource may be governed by multiple agreements, both legal license terms and negotiated acquisition terms. Each acquisition defines one set of terms, and each license defines one set of terms. Through each electronic product's relationship with an acquisition and its relationship with one or more licenses, one can find all of the terms defined instances that apply to each e-resource.

It may occur that among several terms defined instances that apply to a given electronic product, some of the individual terms are in conflict; this is especially likely in situations where multiple license agreements cover a single electronic product. In such cases it is necessary to determine which of the conflicting terms prevail for the electronic product in question. This is modeled with the prevailing terms entity, and its relationships with the terms defined entity:

The prevailing terms entity represents all possible terms, just as the terms defined entity does, but for each term merely points to the terms defined entity that prevails. The four relationship lines depicted in the drawing actually represent many relationships: one for each defined term. So while each electronic product may be governed by many different acquisitions and licenses that define terms, each electronic product is governed by at most one complete set of prevailing terms.

--

This entity relationship diagram depicts the major concepts and relationships needed for managing e-resources. It is neither a complete data model depicting every necessary relational database table, nor is it meant to be a proscriptive design for implementations of ERM systems. Alternate models may capture the necessary attributes and relationships. Hopefully this document, along with the other components of the Report of the DLF Electronic Resource Management Initiative will assist developers with envisioning the complexity of the environment that an ERM system must address, and ensure that crucial relationships and features will be included in ERM products.

--

Angela Riggio, Ivy Anderson, Adam Chandler, Sharon E. Farb, Timothy Jewell, Kimberly Parker, Nathan D. M. Robertson

In the context of the DLF ERMI work, the Data Element Dictionary serves as a basic reference document. It compliments the Data Structure (Appendix E), which expresses the attributes and relationships between the data elements, and the Entity Relationship Diagram (Appendix C), which defines relationships between concepts that exist between groupings of data elements in a system.

The Data Element Dictionary has a very simple structure, consisting of four items. The data element name is the full name given to each element in the Dictionary. The identifier is the name by which other programs will identify a particular element. For example, the element "E-Product Role" will be called "eprole" when used in an XML schema. The data element definitions describe each element. Every effort was made to write the element names and definitions in compliance with ISO 11179, Specification and Standardization of Data Elements. The Data Element Dictionary also includes an optional comments column, which offers examples for data element values or describes situations in which these data elements might be used. This section also identifies other standards from which a particular data element has taken its definition, or it may recommend that a particular standard be used when entering a value for that element into an ERM system.

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

• Bridge (Bridge Entity): The bridge entity allows for the unique expression of each single relationship between two entities when they are linked by a many-to-many relationship. A bridge can also capture unique attributes of each individual relationship (for more information, see Appendix C: Entity Relationship Diagram for Electronic Resource Management)
• Consortium: A group embodying two or more libraries or organizations that enter into a cooperative purchasing agreement for a particular electronic product
• Electronic Product (Electronic Product): In this model, an electronic product represents a superclass. It is comprised of the Electronic Resource Entity and the Interface Entity (for more information, see Appendix E: Electronic Resources Management System Data Structure)
• Electronic Resource(Electronic Resource): Material encoded for manipulation by computer, including texts, sounds, images, numeric data, computer programs, etc. alone or in combination, as well as materials that require the use of peripheral devices directly connected to a computer (e.g. CD-ROM drive or player) or that require a connection to a computer network (e.g. the Internet). -AACR2
• Entity: A high-level concept within a data model. An entity can be represented as a table in a relational database (for more information, see Appendix C: Relationship Diagram for Electronic Resource Management)
• External Linking: The provision within an electronic product of context-sensitive hyperlinks leading to external resources
• Interface: The software platform or website through which a particular e-resource is made available
• IP Address: A number that identifies the network, node, server, or individual workstation that transmits or receives information via the Internet
• Online Administration Module: An administrative interface supplied by the provider for library staff use wherein the public interface of the electronic product can be modified to local specifications
• Platform Simultaneous Users: A limitation on the number of users who may access an interface simultaneously. This number is distinct from the use limit set on individual resources contained within the interface, and may impact access to a particular resource if the simultaneous use of other resources has taken up some or all of the available interface user allowance

---

--

• Pooled Users: A limited number of simultaneous users which is shared by a group of partner libraries. One institution could exploit all of the available user slots in the pool at any given time. Within this model, pooled users are generally shared within a consortium
• Print Version: The paper-based form of an electronic resource, which often serves as the basis for the electronic content
• Provider: The organization or service that supplies electronic access to the electronic content
• Publisher: The organization responsible for the production of the information contained in the product
• Related Version: The print or other tangible form of an electronic resource, which often serves as the basis for the electronic content
• Subscriber Branding: The presence of the subscriber name, identifier, logo, or symbol on an electronic resource, which identifies the subscriber as the party responsible for making the resource available at a particular institution or to a specific user group
• Uniform Resource Identifier (URI): Identifies the method of access, the location, and the file name of an e-resource
• Uniform Resource Locator (URL): A particular kind of URI which locates a file residing on the Internet
• Vendor: The organization responsible for accepting payment for the electronic product

--

Kimberly Parker, Ivy Anderson, Adam Chandler, Sharon E. Farb, Timothy Jewell, Angela Riggio, and Nathan D. M. Robertson

• Introduction
• Electronic Product Set
• Electronic Resource Entity
• Electronic Resource ID
• Electronic Resource Entity Identifier Group
• Work Associated With E-Resource
• Electronic Resource Acquisition
• Electronic Resource Prevailing Terms
• Electronic Resource Access Information
• Electronic Resource Administrative Information
• OCLC Number
• Electronic International Standard Serial Number
• Electronic International Standard Book Number
• Digital Object Identifier
• Local System Number
• Subscription Identifier
• Other Identifier Source
• Other Identifier Number
• Electronic Resource Entity Title Group
• Electronic Resource Title 134
• Electronic Resource Alternate Title
• Electronic Resource Entity Linked Resources Group
• Electronic Resource Interface
• Electronic Resource Contained By
• Electronic Resource Contains
• Electronic Resource Entity Other Description Group
• Electronic Resource Package Type
• Language
• Format
• Resource Type
• Update Frequency
• Description
• Public Note
• Electronic Resource Entity Holdings Group
• Electronic Holdings
• Embargo Period
• Electronic Resource Entity Status Group
• Electronic Resource Status
• Electronic Resource Suppression Indicator
• Interface Entity
• Interface ID
• Interface Acquisition
• Interface Prevailing Terms
• Interface Access Information
• Interface Administrative Information
• Interface Name
• Interface Digital Object Identifier
• Interface Other Identifier Source
• Interface Other Identifier Number
• Interface Provider

---

--

• Medium
• Interface Status
• Interface Public Note
• Acquisition Entity
• Acquisition ID
• Acquisition Entity Identifier Group
• Acquisition Vendor
• Purchase Order Number
• Acquisition Entity Consortial Group
• Consortial Agreement Indicator
• Acquisition Entity Renewal and Termination Group
• Purchase Renewal Date
• Purchase Renewal Tickler
• Renewal Status
• Renewal Decision Date
• Termination Date
• Termination Reason
• Acquisition Entity Price and Payment Group
• Price
• Discount On Price
• Pricing Model
• Print Cancellation Restriction Indicator
• Print Cancellation Note
• Price Cap
• Payment Detail
• Payment Note
• Acquisition Entity Local Group
• Acquisition Note
• Locally Defined Acquisition Fields
• License Entity
• License ID
• License Entity Identifier Group
• License Name
• License Type
• License Uniform Resource Identifier
• License Uniform Resource Identifier Type
• Physical License Location
• License Entity Review Group
• License Status
• License Reviewer
• License Reviewer Note
• Licensing Note
• License Entity Date Group
• License Execution Date
• License Start Date
• License End Date
• License End Date Tickler
• License Duration
• License Entity Parties Group
• Licensor
• Licensee
• Licensing Agent
• License Delivery Instruction
• License Entity Linked Licenses Group
• License Replaced By
• License Replaces
• Electronic Product / License Bridge Entity
• Electronic Resource License ID
• Electronic Resource Licensed
• Interface Licensed

---

--

• License For Electronic Product
• Terms Defined Entity
• Terms Defined ID
• Terms Defined Entity Identifier Group
• Acquisition Creating Terms
• License Creating Terms
• Terms Defined Entity Amount Group
• Amount
• Amount Note
• Terms Defined Entity Authorized User Group
• Authorized User Definition
• Local Authorized User Definition Indicator
• Terms Defined Entity Terms of Use Group
• Fair Use Clause Indicator
• All Rights Reserved Indicator
• Database Protection Override Clause Indicator
• Citation Requirement Detail
• Digitally Copy
• Digitally Copy Term Note
• Print Copy
• Print Copy Term Note
• Scholarly Sharing
• Scholarly Sharing Term Note
• Distance Education
• Distance Education Term Note
• Interlibrary Loan Print Or Fax
• Interlibrary Loan Secure Electronic Transmission
• Interlibrary Loan Electronic
• Interlibrary Loan Record Keeping Required Indicator
• Interlibrary Loan Term Note
• Course Reserve Print
• Course Reserve Electronic / Cached Copy
• Course Reserve Term Note
• Electronic Link
• Electronic Link Term Note
• Course Pack Print
• Course Pack Electronic
• Course Pack Term Note
• Remote Access
• Walk-In User Term Note
• Local Use Permission Term Fields
• Terms Defined Entity Restrictions Group
• Concurrent User
• Pooled Concurrent Users
• Concurrent User Note
• Other User Restriction Note
• Other Use Restriction Note
• Terms Defined Entity Perpetual Rights Group
• Perpetual Access Right
• Perpetual Access Holdings
• Perpetual Access Note
• Archiving Right
• Archiving Format
• Archiving Note
• Terms Defined Entity Obligations Group
• Accessibility Compliance Indicator
• Completeness Of Content Clause Indicator
• Concurrency With Print Version Clause Indicator
• Intellectual Property Warranty Indicator
• Confidentiality Of User Information Indicator
• UCITA Override Clause Indicator

---

--

• Clickwrap Modification Clause Indicator
• Indemnification By Licensor Clause
• Indemnification By Licensee Clause Indicator
• Indemnification Clause Note
• Confidentiality Of Agreement
• Confidentiality Of Agreement Note
• Governing Law
• Governing Jurisdiction
• Applicable Copyright Law
• Cure Period For Breach
• Cure Period For Breach Unit Of Measure
• Content Warranty
• Performance Warranty Indicator
• Performance Warranty Uptime Guarantee
• Maintenance Window
• Renewal Type
• Non-Renewal Notice Period
• Non-Renewal Notice Period Unit Of Measure
• Terms Defined Entity Termination Obligations Group
• Licensee Termination Right Indicator
• Licensee Termination Condition
• Licensee Notice Period For Termination
• Licensee Notice Period For Termination Unit Of Measure
• Licensor Termination Right Indicator
• Licensor Termination Condition
• Licensor Notice Period For Termination
• Licensor Notice Period For Termination Unit Of Measure
• Termination Right Note
• Termination Requirements
• Termination Requirements Note
• Terms Defined Entity Notes Group
• Terms Note
• Local Use Terms Fields
• Prevailing Terms Entity
• Prevailing Terms ID
• Prevailing Terms Entity Amount Group
• Prevailing Amount
• Prevailing Amount Note
• Prevailing Terms Entity Authorized User Group
• Prevailing Authorized User Definition
• Prevailing Local Authorized User Definition Indicator
• Prevailing Terms Entity Terms of Use Group
• Prevailing Fair Use Clause Indicator
• Prevailing All Rights Reserved Indicator
• Prevailing Database Protection Override Clause Indicator
• Prevailing Citation Requirement Detail
• Prevailing Digitally Copy
• Prevailing Digitally Copy Term Note
• Prevailing Print Copy
• Prevailing Print Copy Term Note
• Prevailing Scholarly Sharing
• Prevailing Scholarly Sharing Term Note
• Prevailing Distance Education
• Prevailing Distance Education Term Note
• Prevailing Interlibrary Loan Print Or Fax
• Prevailing Interlibrary Loan Secure Electronic Transmission
• Prevailing Interlibrary Loan Electronic
• Prevailing Interlibrary Loan Record Keeping Required Indicator
• Prevailing Interlibrary Loan Term Note
• Prevailing Course Reserve Print
• Prevailing Course Reserve Electronic / Cached Copy

---

--

• Prevailing Course Reserve Term Note
• Prevailing Electronic Link
• Prevailing Electronic Link Term Note
• Prevailing Course Pack Print
• Prevailing Course Pack Electronic
• Prevailing Course Pack Term Note
• Prevailing Remote Access
• Prevailing Walk-In User Term Note
• Prevailing Local Use Permission Term Fields
• Prevailing Terms Entity Restrictions Group
• Prevailing Concurrent User
• Prevailing Pooled Concurrent Users
• Prevailing Concurrent User Note
• Prevailing Other User Restriction Note
• Prevailing Other Use Restriction Note
• Prevailing Terms Entity Perpetual Rights Group
• Prevailing Perpetual Access Right
• Prevailing Perpetual Access Holdings
• Prevailing Perpetual Access Note
• Prevailing Archiving Right
• Prevailing Archiving Format
• Prevailing Archiving Note
• Prevailing Terms Entity Obligations Group
• Prevailing Accessibility Compliance Indicator
• Prevailing Completeness Of Content Clause Indicator
• Prevailing Concurrency With Print Version Clause Indicator
• Prevailing Intellectual Property Warranty Indicator
• Prevailing Confidentiality Of User Information Indicator
• Prevailing UCITA Override Clause Indicator
• Prevailing Clickwrap Modification Clause Indicator
• Prevailing Indemnification By Licensor Clause
• Prevailing Indemnification By Licensee Clause Indicator
• Prevailing Indemnification Clause Note
• Prevailing Confidentiality Of Agreement
• Prevailing Confidentiality Of Agreement Note
• Prevailing Governing Law
• Prevailing Governing Jurisdiction
• Prevailing Applicable Copyright Law
• Prevailing Cure Period For Breach
• Prevailing Cure Period For Breach Unit Of Measure
• Prevailing Content Warranty
• Prevailing Performance Warranty Indicator
• Prevailing Performance Warranty Uptime Guarantee
• Prevailing Maintenance Window
• Prevailing Renewal Type
• Prevailing Non-Renewal Notice Period
• Prevailing Non-Renewal Notice Period Unit Of Measure
• Prevailing Terms Entity Termination Obligations Group
• Prevailing Licensee Termination Right Indicator
• Prevailing Licensee Termination Condition
• Prevailing Licensee Notice Period For Termination
• Prevailing Licensee Notice Period For Termination Unit Of Measure
• Prevailing Licensor Termination Right Indicator
• Prevailing Licensor Termination Condition
• Prevailing Licensor Notice Period For Termination
• Prevailing Licensor Notice Period For Termination Unit Of Measure
• Prevailing Termination Right Note
• Prevailing Termination Requirements
• Prevailing Termination Requirements Note
• Prevailing Terms Entity Notes Group
• Prevailing Terms Note
• Prevailing Local Use Terms Fields

---

--

• User Group Entity
• User Group ID
• User Status
• User Proxy Information
• User Note
• Available To User Bridge Entity
• Available To User ID
• Terms Record Associated With User Group
• User Group Associated With Term
• User Group Permission Legal Interpretation
• User Group Permission Operational Value
• Location Entity
• Location ID
• Location Name
• Location IP Subset
• Location Proxy Information
• Location Note
• Available To Location Bridge Entity
• Available To Location ID
• Terms Available To Location
• Location Assigned To Term
• Location Permission Legal Interpretation
• Location Permission Operational Value
• Access Information Entity
• Access Information ID
• Access Information Entity Identifier Group
• Primary Access Uniform Resource Identifier
• Primary Access Uniform Resource Identifier Type
• Alternate Uniform Resource Identifier
• Alternate Uniform Resource Identifier Type
• Local Persistent Uniform Resource Identifier
• Local Persistent Uniform Resource Identifier Type
• Access Information Entity Authentication Group
• Implemented Authorization Method
• Alternate Authorization Method
• Electronic Product User Identifier
• Electronic Product User Password
• Electronic Product Local User Identifier
• Electronic Product User Password Note
• IP Address Registration Method
• IP Address Registration Instruction
• IP Addresses Registered For Access
• Date IP Addresses Registered
• IP Address General Note
• Access Information Note
• Access Information Entity Proxy Group
• Proxy Server Decision Indicator
• Proxy Registration Status
• Domain Name
• Access Information Entity Z39.50 Group
• Z39.50 Address
• Z39.50 Port
• Z39.50 Attributes
• URI To Z39.50 Information
• Z39.50 Database Name Long
• Z39.50 Database Name Short
• Z39.50 Authentication Information
• Administrative Information Entity
• Administrative Information ID
• Administrative Information Entity Identifier Group

---

--

• Administrative Uniform Resource Identifier
• Administrative Uniform Resource Identifier Type
• Administrative Identifier
• Administrative Password
• Administrative Password Note
• Administrative Information Entity Configuration Group
• Configurable Session Timeout Indicator
• Session Timeout Value
• Logout Uniform Resource Identifier Indicator
• Logout Uniform Resource Identifier Value
• Logout Uniform Resource Identifier Type
• User Interface Configuration Indicator
• Subscriber Branding Indicator
• Subscriber Branding Activation Status Indicator
• Subscriber Branding Note
• Personalization Services Indicator
• Z39.50 Indicator
• Hook to Holdings Indicator
• Holdings Link Activated Indicator
• Provider Reference Linking Indicator
• Inbound Linking Indicator
• Inbound Linking Activation Status Indicator
• OpenURL Compliance Indicator
• OpenURL Activation Status Indicator
• Linking Note
• MARC Record Availability Indicator
• MARC Record Note
• Interface Languages Availability Indicator
• Interface Language Implemented
• Local Use Administrative Fields
• Administrative Information Entity Usage Statistics Group
• Usage Statistics Availability Indicator
• Statistics Standard Compliance
• Usage Statistics Delivery Method
• Usage Statistics Format
• Usage Statistics Frequency
• Usage Statistics Online Location
• Usage Statistics User Identifier
• Usage Statistics Password
• Usage Statistics Addressee
• Usage Statistics Note
• Usage Statistics Locally Stored
• Administrative Information Entity Support Group
• Hardware Requirement
• Software Requirement
• Maintenance Window Value
• Provider System Status Uniform Resource Indicator
• Provider System Status Uniform Resource Indicator Type
• Product Unavailable Indicator
• Product Advisory Note
• Local Performance Monitoring Note
• Incident Log
• Training Information
• Administrative Documentation
• User Documentation
• Processing Workflow Entity
• Process ID
• Processing Workflow Entity Identifier Group
• Interface In Process
• Electronic Resource In Process
• Processing Workflow Entity Pre-Selection Group

---

--

• Electronic Product Pre-Selection Expected Decision Date
• Electronic Product Pre-Selection Cost Information
• Electronic Product Evaluation History
• Electronic Product Pre-Selection Note
• Processing Workflow Entity In-Process Group
• Order Request Date
• Order Request Note
• Authentication Status
• Z39.50 Access Status
• Cataloging Request Date
• Cataloging Priority
• Access Confirmation Indicator
• Access Tested Date
• Local Services Status
• Interface Customization Status
• Publicity Status
• Instructional Tools Status
• Public Display Release Status
• Usage Data Setup Status
• In Process Note
• Processing Workflow Renewal and Termination Group
• Electronic Product Renewal Review Status
• Electronic Product Renewal Expected Decision Date
• Electronic Product Renewal Status Note
• Electronic Product Evaluation History
• Electronic Product Termination Status
• Electronic Product Termination Status Note
• Workflow Rules Entity
• Trial Entity
• Trial ID
• Electronic Resource On Trial
• Interface On Trial
• Trial Uniform Resource Indicator
• Trial Uniform Resource Indicator Type
• Trial Username
• Trial Password
• Trial Start Date
• Trial Expire Date
• Trial Available To Public Indicator
• Trial License Required Indicator
• Trial Note
• Consortium Entity
• Consortium ID
• Consortium Name
• Consortium Alternate Name
• Consortium Address
• Consortium Note
• Partner Library Entity
• Partner Library ID
• Partner Library Name
• Partner Library Alternate Name
• Partner Library Address
• Partner Library IP Ranges
• Partner Library Note
• Consortial Participation Bridge Entity
• Consortium Participation ID
• Consortial Acquisition
• Consortium Acquiring
• Consortial Partner
• Consortial Fund Contribution

---

--

• Number Of Consortial Participants
• Consortial Issues Note
• Library Entity
• Library ID
• Library Name
• Library Alternate Name
• Library Address
• Library Locations
• Proxy Information
• Library Note
• Library Acquisition Bridge Entity
• Library Acquisition ID
• Acquisition Coordinated
• Library Cooperating
• Cost Share
• Cost Share Percentage
• Cost Share Note
• Organization Entity
• Organization ID
• Organization Name
• Organization Alternate Name
• Organization Address
• Notice Address Licensor
• Organization Note
• Organization Library Bridge Entity
• Organization Library Bridge ID
• Organization Working With Library
• Library Working With Organization
• Account Identifier Assigned To Library
• Contact Entity
• Contact ID
• Contact Name
• Contact Title
• Contact Address
• Contact Email Address
• Contact Phone Number
• Contact Fax Number
• Contact Role
• Organization Represented
• Consortium Represented
• Library Represented
• Partner Library Represented
• Contact Responsibilities Bridge Entity
• Contact Responsibilities ID
• Contact Responsible
• E-Resource Under Care
• Interface Under Care
• License Under Care
• Acquisition Under Care
• E-Product Role
• Work Entity
• Work ID
• Electronic Resource Title Continues
• Electronic Resource Title Continued By
• International Standard Text Code
• Subject
• Uniform Title
• Author

---

--

• Related Version Entity
• Related Version ID
• Work Associated With Related Version
• Related Version Title
• Print International Standard Book Number
• Print International Standard Serial Number
• Local Record Number
• Print Price
• Print Subscription Identifier
• Appendix A1 Contact Roles
• Appendix A2 User Groups
• Notes
• Index to Entities, Groups, and Elements

--

This document is a data structure and supporting tool for understanding and interpreting the interaction between the Entity Relationship Diagram and the Data Elements Dictionary. The Data Structure maps the elements defined in the Data Elements Dictionary into the entities defined by the Entity Relationship Diagram in a way that supports the functional specifications delineated in the Functional Requirements and the workflow described in the Workflow Flowchart document. As part of a data model, the Data Structure is not intended to be absolutely prescriptive. System designers should feel free to develop their own approach to integrating the elements and entities. However, designers are cautioned from deviating too widely from the concepts of the below approach, as any deviations will need to be transformable for the purposes of data sharing and migration.

The following pieces of information may be helpful in understanding the presentation of the data model in the Electronic Resource Management System Data Structure.

Data Elements and Definitions are extracted from the Data Element Dictionary with as little variation as possible. However, some elements that are duplicates of others in concept (e.g. elements in the Prevailing Terms entity), or pointers, which are in essence a reference to another entity, may not be listed in the Data Element Dictionary.

Element Types are restricted to text, numeric, logical, date, unique ID, or pointers. Unique IDs are only used for the record identifiers in each entity. Pointers are ID elements from another entity which either supply information from that other entity where needed in the one containing the pointer, or which establish a type of relationship. For example, a one-to-many relationship requires the listing of a pointer to the ID from the "one" side of the equation in the entity of the "many" side of the equation.

System Use / Functionality is used to describe ways the system software may use or need to treat the element or the expected functionality the element is expected to fulfill. References to the outline of the Functional Requirements are made either in the Notes of an entity (for those specifications that the entire entity fulfills) or in the System Use / Functionality area. Functional Requirement outline references are made in the following form: FR#.# and those not recorded in this area are annotated in the Appendix Notes. Not all functional uses of every element are spelled out, but the annotation in the Data Structure is intended to point out the integration of the data model with the Functional Requirements document. Another use of this System Use / Functionality area is to record the binding of paired or grouped elements. Some pairs or groups are simply logical associations, as when the unit of measure should be attached to the element recording the item being measured. Other pairs or groups are functional necessities, as when the pair or group repeats as a pair or group and is actually a surrogate representation of a separate nested table of elements.

Values record the suggested possible entries for an element, or the suggested possible layout of such entries. A few value lists of extensive length are recorded as appendices. System implementers may use alternate terminology as appropriate.

The Optionality area records whether an element is required. The key to the abbreviations is:

• R = Required
• RA = Required if Applicable
• O = Optional

--

The Repeatability area supplies information on the unique or repeating nature of the element.

The Notes / Examples area provides a space to clarify further details about the element or raise issues that are still unresolved.

A number of entities with lengthy lists of elements are separated into Groups for the sake of convenience and clarity. There is no functional purpose to the groupings and they may be ignored for the purpose of system design structures.

The terms electronic product and electronic resource have been shortened to e-product and e-resource throughout this document for brevity's sake; refer to the Data Dictionary, Appendix D, for full element names.

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--

--