The DLF Electronic Resource Management Initiative

1. The DLF Electronic Resource Management Initiative Sharon E. Farb Angela Riggio UC Electronic Resource Management Planning Meeting March 11, 2004 UC Irvine

2. Talk Outline Overview and Context of Digital Resource Management Initiatives The DLF E-resource Management Initiative How Can This Work Be Used In UC-wide Environment? Impact, Challenges, And Next Steps Questions And Comments

3. Context for Digital-Resource Mgmt. Logarithmic growth of d-resources High demand for 24/7 access Digital resource budget shares continue to grow (mostly digital environment in 5 years?) Budget issues driving shift to d-only journal access Dynamic marketplace & business models Impact of licensing D-resources are complex (to acquire, describe, fund, and troubleshoot and support) �Google-ization� (make it easy or forget it!)

4. Digital Resource Management Systems and Initiatives California Digital Library Colorado Alliance (Gold Rush) Columbia Griffith University (Australia) Harvard (ExLibris) Johns Hopkins (HERMES) (Dynix) MIT (VERA) (ExLibris) Michigan Minnesota Notre Dame Penn State (ERLIC) Stanford Texas (License Tracker) Tri-College Consortium (Haverford, Bryn Mawr, Swarthmore) UCLA (erdb) University of Georgia University of Washington (III) Virginia Willamette University Yale

5. Chaos or Convergence? Other related work in progress Increasing vendor development and library-vendor collaboration NISO/EDItEUR Joint Working Party for the Exchange of Serials Information (ONIX for Serials) Project COUNTER�Usage statistics ODRL�Open Digital Rights Language (v. XrML) Shibboleth�Authentication What has not been designed: a consortial, interactive, collaborative digital resource management tool. Re vendor development: products and service development widespread: EBSCO, Harrasowitz, Serials Solutions, Ulrichs NISO/EdIteur Joint Working Party---establish XML schema metadata subscriptions for serials. Q: Should holdings be prescriptive or actionable. JWP created �use cases�. Less detailed than Z39.50 more detailed than original JWP. Nathan Robertson, DLF Johns Hopkins, member, Pricilla Kaplan, James Mouw, LC,Re vendor development: products and service development widespread: EBSCO, Harrasowitz, Serials Solutions, Ulrichs NISO/EdIteur Joint Working Party---establish XML schema metadata subscriptions for serials. Q: Should holdings be prescriptive or actionable. JWP created �use cases�. Less detailed than Z39.50 more detailed than original JWP. Nathan Robertson, DLF Johns Hopkins, member, Pricilla Kaplan, James Mouw, LC,

6. ERM Metadata Standards Comparison

7. DLF ERMI Steering Group: Tim Jewell (University of Washington) Ivy Anderson (Harvard) Adam Chandler (Cornell) Sharon Farb (UCLA) Angela Riggio (UCLA) Kimberly Parker (Yale) Nathan D. M. Robertson (Johns Hopkins)

8. DLF ERMI Goals Formal Describe architectures needed Establish lists of elements and definitions Write and publish XML Schemas/DTD�s Promote best practices and standards for data interchange Informal Promote growth and development of vendor and local ERM systems and services http://www.diglib.org/standards/dlf-erm02.htm . .

9. Project Deliverables Problem Definition/Road Map Workflow Diagram Functional Specifications Entity Relationship Diagram Data Elements and Definitions XML Schema

10. Librarian Reactor Panel (17 members) Bob Alan (Penn State) Angela Carreno (NYU) Trisha Davis (Ohio State) Ellen Duranceau (MIT) Christa Easton (Stanford) Laine Farley (CDL) Diane Grover (Washington) Nancy Hoebelheinreich (Stanford) Norm Medeiros (Haverford) Linda Miller (LC) Jim Mouw (Chicago) Andrew Pace (NCSU) Carole Pilkinton (Notre Dame) Ronda Rowe (Texas) Jim Stemper (Minnesota) Paula Watson (Illinois) Robin Wendler (Harvard)

11. Vendor Reactor Panel (12 Members) Tina Feick (SWETS Blackwell) Ted Fons (Innovative Interfaces) David Fritsch (TDNet) Kathy Klemperer (Harrassowitz) George Machovec (Colorado Alliance) Mark Needleman (SIRSI) Oliver Pesch (EBSCO) Chris Pierard (Serials Solutions) Kathleen Quinton (OCLC) Sara Randall (Endeavor) Ed Riding (Dynix) Jenny Walker (ExLibris)

12. Entity-Relationship Diagram

13. Data Element Dictionary: Overview Brief history Structural simplicity Data Element Name Identifier Definition Comments Groundwork for Data Structure and ERD

14. Data Element Dictionary

15. Data Elements: Considerations Overlap/integration with existing metadata schema ISO 11179 Element names Defining complex concepts Exhaustibility/flexibility Recommending standards for element values

16. Data Structure Overview ERD + DED = Data structure Data Dictionary Elements plus entity identifiers plus pointers between entities Data Dictionary Definitions plus data types functionality optionality & cardinality The Data Structure provides the final rounding picture to a model whose description began with the Entity Relationship Diagram and the Data Element Dictionary. This document is the ERMI-recommended approach to turning the conceptualization of the ERD and the DED into something approaching a relational database design. Each of the elements in the Dictionary have been mapped into entities described in the ERD. Some new �elements� have been inserted to represent the needed relationships between entities that were described in the ERD as well. Finally, each element has been annotated with information about data type (numeric, text, logical, date, etc.) functionality (outline labels from the Functional Requirements document are included) optionality cardinality and other needed notes or examplesThe Data Structure provides the final rounding picture to a model whose description began with the Entity Relationship Diagram and the Data Element Dictionary. This document is the ERMI-recommended approach to turning the conceptualization of the ERD and the DED into something approaching a relational database design. Each of the elements in the Dictionary have been mapped into entities described in the ERD. Some new �elements� have been inserted to represent the needed relationships between entities that were described in the ERD as well. Finally, each element has been annotated with information about data type (numeric, text, logical, date, etc.) functionality (outline labels from the Functional Requirements document are included) optionality cardinality and other needed notes or examples

17. ERMS Data Structure A number of the entities have quite long lists of elements that are mapped to them. For convenience, we have created conceptual groups within entities where elements relating to similar issues are collated. These groups have no function other than to make the data structure more humanly readable. This particular portion of the quite long Data Structure shows a group within the Administrative Information entity. You will note there is a summary at the top of the outline, again to provide convenience for those using the data structure. The meat of the outline of each entity is the information associated with each element -definition type functionality values optionality cardinality and notes and examples. And with that, I will let the Data Structure speak for itself, and let us move on to XML.A number of the entities have quite long lists of elements that are mapped to them. For convenience, we have created conceptual groups within entities where elements relating to similar issues are collated. These groups have no function other than to make the data structure more humanly readable. This particular portion of the quite long Data Structure shows a group within the Administrative Information entity. You will note there is a summary at the top of the outline, again to provide convenience for those using the data structure. The meat of the outline of each entity is the information associated with each element -definition type functionality values optionality cardinality and notes and examples. And with that, I will let the Data Structure speak for itself, and let us move on to XML.

18. "The process of definition begins not with an abstract metadata schema but with a functional analysis of the application that the metadata schema and the commercial and procedural rules are designed to support.� -- DOI Handbook, 5.7.2 Form Follows Function -- Louis Sullivan In the scintillating world of systems analysis and design, this is what we�ve managed to torture that wonderful phrase into. Graceful or pedestrian, -- the point of course being, that we have to start with a functional perspective before we can proceed talk about data elements.In the scintillating world of systems analysis and design, this is what we�ve managed to torture that wonderful phrase into. Graceful or pedestrian, -- the point of course being, that we have to start with a functional perspective before we can proceed talk about data elements.

19. Development of the Specs Series of meetings between Harvard and MIT, Spring 2003 to discuss possible work with Ex Libris on ERM development DLF Data Element Set (now Data Structure and Data Element Dictionary) �But what is the functionality???� Ensuing document formed the basis for the current DLF document

20. Functional Requirements:Guiding Principles Integrated environment for management and access Interoperation and/or exchange of data with existing services: OPACs, web portals, library management systems, link resolution services� Single point of maintenance for each data element

21. Functions Support the ongoing and persistent �life cycle� or �continuum� of digital resources Selection and acquisition Access provision Resource administration and support Renewal and retention decisions

23. Selection and Acquisition Mount Trials Evaluate Content, interface Technical compatibility Select Arrange funding / make deals Negotiate License Order

24. Access Provision Manage IP addresses and passwords Store & maintain URLs Catalog / add to resource discovery portals Provide remote access services (e.g. via proxy server) Interface with local authentication and authorization services Assign persistent names Authentication and Authorization may or may not be within the library�s purview. But even absent this degree of local control, every institution that provides access to restricted resources has to manage ip addresses, sometimes on a resource-by-resource basis if resources are licensed for specific sub-populations such as the medical school or law school or occasionally for specific departmental or in-building subnets. And since local ip addresses can change, keeping records of which ip addresses have been registered can be crucial to problem-solving and also to monitoring license compliance. Most will also have to register resources with a proxy server or similar remote access service, or provide relevant information to other campus units that provide such services. Although not a focus of the access and administration breakout session, I�ve also included resource discovery portals under this rubric, which of course relies on on descriptive metadata as well as access-related data.Authentication and Authorization may or may not be within the library�s purview. But even absent this degree of local control, every institution that provides access to restricted resources has to manage ip addresses, sometimes on a resource-by-resource basis if resources are licensed for specific sub-populations such as the medical school or law school or occasionally for specific departmental or in-building subnets. And since local ip addresses can change, keeping records of which ip addresses have been registered can be crucial to problem-solving and also to monitoring license compliance. Most will also have to register resources with a proxy server or similar remote access service, or provide relevant information to other campus units that provide such services. Although not a focus of the access and administration breakout session, I�ve also included resource discovery portals under this rubric, which of course relies on on descriptive metadata as well as access-related data.

25. Administration Keep track of administrative IDs and passwords Configure resources for local use user interface options institutional branding link resolvers etc. Mechanisms for restricting access to administrative functions Most of us don�t have an obvious place to keep track of administrative IDs and related information. Usually this is information that you want to restrict in some way - one doesn�t necessarily want every library staff member to go in and change resource configurations to suit their preferences, or the preferences of their specific segment of the user community, at will. And it also may be useful to be able to track the options that are available for a given resource and record decisions you have made, although when we sit down to talk about this, it might be worth discussing how many of us would be diligent about keeping such good records.Most of us don�t have an obvious place to keep track of administrative IDs and related information. Usually this is information that you want to restrict in some way - one doesn�t necessarily want every library staff member to go in and change resource configurations to suit their preferences, or the preferences of their specific segment of the user community, at will. And it also may be useful to be able to track the options that are available for a given resource and record decisions you have made, although when we sit down to talk about this, it might be worth discussing how many of us would be diligent about keeping such good records.

26. Support Staff and end users Hardware and software requirements Downtime information Incident logging User support, documentation and training Designated vendor and local support contacts Mechanisms for disseminating information to: Reference librarians Help desk staff While it�s desirable to restrict access to administrative login information, it�s desirable to make support information as widely available as possible, both for staff and end users. If there is a local contact for a given resource - a selector or, in our case, a resource steward, for example - that information needs to be recorded. Hw / SW requirements for example can be displayed in OPACS or web portals; Reference and instruction librarians will want to know about training resources, including things like whether a dedicated training server is available or whether the contract provides for onsite user training by the vendor. Problem tracking -- that is, retaining a history of problems and their resolution - can be very useful both for ongoing support and for resource evaluation. This sort of tracking can basic or very detailed. UCLA is developing a full-blown call-tracking module as part of its eresource management system. While it�s desirable to restrict access to administrative login information, it�s desirable to make support information as widely available as possible, both for staff and end users. If there is a local contact for a given resource - a selector or, in our case, a resource steward, for example - that information needs to be recorded. Hw / SW requirements for example can be displayed in OPACS or web portals; Reference and instruction librarians will want to know about training resources, including things like whether a dedicated training server is available or whether the contract provides for onsite user training by the vendor. Problem tracking -- that is, retaining a history of problems and their resolution - can be very useful both for ongoing support and for resource evaluation. This sort of tracking can basic or very detailed. UCLA is developing a full-blown call-tracking module as part of its eresource management system.

27. Renewal Information needed for renewal and retention decisions Problem history Downtime records Usage statistics Renewal ticklers Well as we all know, in licensing content today we�re also licensing service. Many of our contracts have provisions that apply a financial penalty for poor performance, usually related to downtime, but occasionally for other performance failures as well, such as slow response time or delayed or incomplete content. I�m sure everyone in this room can attest to the prevalence of such failures and the amount of time we are spending on them. With some exceptions of course, many online content providers have not yet learned how to be good service providers. But right now we don�t have very good tools for keeping the records that we need to exercise these provisions, or indeed to fulfill our own obligations to manage these services effectively. So we desperately need tools both to help us be more efficient in tracking problems and to keep records that can serve us well at renewal negotiation time. We also don�t have good tools for keeping track of the usage statistics that vendors, to their credit, are increasingly making available. One needs to track things such as how the statistics are made available - whether online or delivered via email for example - what the access instructions are, and/or documentation about local treatment such as posting statistics online for library selectors and administrators.Well as we all know, in licensing content today we�re also licensing service. Many of our contracts have provisions that apply a financial penalty for poor performance, usually related to downtime, but occasionally for other performance failures as well, such as slow response time or delayed or incomplete content. I�m sure everyone in this room can attest to the prevalence of such failures and the amount of time we are spending on them. With some exceptions of course, many online content providers have not yet learned how to be good service providers. But right now we don�t have very good tools for keeping the records that we need to exercise these provisions, or indeed to fulfill our own obligations to manage these services effectively. So we desperately need tools both to help us be more efficient in tracking problems and to keep records that can serve us well at renewal negotiation time. We also don�t have good tools for keeping track of the usage statistics that vendors, to their credit, are increasingly making available. One needs to track things such as how the statistics are made available - whether online or delivered via email for example - what the access instructions are, and/or documentation about local treatment such as posting statistics online for library selectors and administrators.

28. Functional Requirements: (excerpt) 32. Store license rights and terms for reference, reporting, and control of services 32.1 For services including but not limited to ILL, 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 conditions

29. Core Requirements (2) Support integrated bibliographic access and management Provide relevant license information to the end user Share and/or exchange bibliographic data with other local systems and data exchange partners Store access-related information urls, IDs, passwords, ip addresses Store administrative information Administrative urls, IDs, passwords Configuration information (Z39.50, MARC records, OpenURL resolvers) Usage statistics metadata

30. Functional Requirements:Reactor Panel Themes Minimizing duplicative data among systems Which is the system of record? �Consistent information for the user regardless of the path taken�-- is this realistic? Appropriate locus of acquisitions functionality ERMS or LMS Usage statistics Pointers vs. Containers Access management Optional support for persistent URIs Functional integration with local access management environment (e.g. proxy servers)

31. XML Investigation Scope Possible use case examples Focused special attention on problem of formatting holdings data Feasibility of XML schema to represent elements and entities Next steps

32. Possible Use Case Examples A web service between libraries and vendors for reporting and communicating support incidents Transmission of IP ranges to vendors and contact info to libraries Exchange license data with a contracting partner 1. Both parties would then have a self archiving record of all troubleshooting 1. Both parties would then have a self archiving record of all troubleshooting

33. XML Next Steps Continue work with Renato Iannella: how may the Open Digital Rights Language be used to represent license terms? Create instance documents to demonstrate possible use of the DLF ERMI base schema Secondary product: further refinement of our element set attributes

34. Summary Managing electronic resources over time creates unique challenges for libraries of all types What functionality and metadata are required to support persistent e-resource management across and among UC and other libraries? DLF project offers first comprehensive schema, data model and tools specifically designed to address e-resources throughout their lifecycle What further work is necessary to guide or maintain development in this area?

35. Issues and Implications (1) Overall d-environment�highly dynamic, logarithmic growth, high cost, multidimensional nature Library environment�particularly complex Hard to predict the future�plethora of business models Growing reliance and investment in e-resources with no guarantees re digital archiving or persistent access

36. Issues and Implications (2) No single global identification system No registry or authority list of identifiers, packages or providers Vocabulary issues Privacy and confidentiality re authentication Usage data--COUNTER, ARL e-metrics? Open v. proprietary standards Customization and standardization Interoperability of stand-alone ERM?

37. No Silver Bullet A variety of initiatives and projects addressing various aspects of d-resource management To date, none has specifically addressed the complexity and challenge of consortia This planning meeting is an opportunity to begin that discussion