1. Managing E-resources Across the Consortium: DLF Project and Data Standards Developments ICOLC New Orleans, LA March 16, 2004

2. The quick take  DLF E-resource Management Initiative began 2 years ago, focus on individual libraries  Project nearing completion  Data standards being proposed, discussed  Vendors developing products  Consortial requirements, impact, implications not addressed...  Until NOW!

3. Session Plan  The DLF E-Resource Management Initiative and Library Consortia – Tim Jewell  Colorado Alliance’s Gold Rush and subscription management functions – Alan Charnes  Current ERM Activities at the University of California – Beverlee French  Discussion  Consortial ERM Requirements?  Consortial support of library ERMs?  Next Steps for ICOLC?

4. The DLF E-Resource Management Initiative and Library Consortia Tim Jewell

5. E-resource tasks not supported by current library systems  Generating, maintaining alpha and subject lists  Loading “aggregator” & e-journal holdings information  License term negotiation, tracking, communication  Authorized users  Authorized use  ILL, Course packs, E-reserves  “Scholarly Sharing”  Good faith efforts to communicate terms  Administrative info. (authentication, contacts, etc.)  Problem tracking & “triage”  Planned, cyclical product reviews  Systematic usage reporting  Result: creation of many separate documents and/or applications

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

7. Tracking Development Work : the “Web Hub”Web Hub  Adam Chandler (Cornell) and Tim Jewell  Work begun for earlier DLF study  Project descriptions and contacts  Local documents  Listserv  (http://www.library.cornell.edu/cts/elicensestudy/)

8. 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. Groups involved  Steering Committee (7 members)  Cornell, Harvard, Johns Hopkins, UCLA, UW, Yale  Librarian Reactor Panel (17 members)  Representatives from many libraries with ERM experience: NC State, Ohio State, Penn State, Stanford, UT-Austin, etc.  Vendor Reactor Panel (12 members)  Ex Libris, III, Endeavor, Dynix, SIRSI  EBSCO, Colorado Alliance, Harrassowitz, OCLC, SWETS Blackwell, Serials Solutions, TDNET,

10. Deliverables & Use Scenarios (1)  Problem Definition/Road Map  “System Survey”  Help understand scope of need, options  Final Project Report  What did we do, how far did we get, and what’s unresolved?  Begin defining next steps  Workflow Diagram  Internal analysis and planning  Functional Requirements  Define details of needed functionality for:  Local and Vendor system planning  Source for RFP’s

11. Deliverables & Use Scenarios(2)  Entity Relationship Diagram (“Tree”)  Aid to conceptualization  Data Elements and Definitions  Data Element Dictionary (“Leaves”)  Data Structure (“Where the Leaves Go”)  Accelerate development processes  XML Investigation  Foster data interchange for  Future data migration  Vendor to Library data interchange  Library to Library data interchange?

12. Functions  Support the ‘Life Cycle’ of electronic resources:  Selection and acquisition  Access provision  Resource administration and support  Renewal and retention decisions

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

14. Access Provision  Manage IP addresses and passwords  Store & maintain URLs  Catalog / add to resource discovery portals  Record/present license terms?  Provide remote access services (e.g. via proxy server)  Interface with local authentication and authorization services  Assign persistent names

15. Resource Administration  Keep track of administrative IDs and passwords  Configure resources for local use  user interface options  institutional branding  link resolvers  Mechanisms for restricting access to administrative functions

16. 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

17. Renewal/Retention Discussions  Information needed for renewal and retention decisions  Problem history  Downtime records  Usage statistics  Renewal reminders/ticklers

18. ERM Metadata Standards Comparison

19. Workflow Flowchart Overview  “Thinking About” Product Selection  Initial Review (3 “parallel processes”)  License  Technical Feasibility  Business Issues  Implementation  Routine Maintenance/Renewal

20. Workflow Flowchart (1)

21. 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

22. Functional Requirements: General  Represent relationships among individual e- resources, packages, licenses, and online interfaces  Associate characteristics of a license, interface, or package with the resources to which it applies  Provide robust reporting and data export capabilities

23. Functionality “Quick Take”  Store and display data not presently accommodated in current systems  For End Users  Auxiliary descriptive data  License information (permitted uses and restrictions)  Availability  Technical and platform-specific issues  For Staff  License information (more detailed)  Administrative IDs and passwords  Configuration and management information  Usage statistics and training information

24. 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

25. Data Element Dictionary

26. Entity-Relationship Diagram

27. ERMS Data Structure

28. XML Investigation Scope 1. Much work elsewhere on descriptive data exchange (ONIX for Serials, etc.) 2. Concerns about XrML, MPEG-21 and other proprietary standards led to focus on license elements and 2 use cases: a. License-related elements for library to library/consortium to library sharing b. Shorter set of license elements for staff and users. 3. Next steps: presentation at DLF Spring Forum

29. What Next?

30. Market Response  Vendors  Gold Rush  Innovative Interfaces  ExLibris  Dynix  Endeavor  Open Source  Johns Hopkins (Hermes)

31. Project wrap-up (by DLF Spring Forum)  “What’s missing?”  Functionality to support consortia?  Usage data functionality?  Cross-check existing documents  Round out draft schema  System survey  Project report

32. Standards Issues (1)  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 ERMs?

33. Standards Issues (2)  Licensing  Can “legal subtleties” be encoded?  Can we share license descriptions?  “Players”: publishers, vendors, libraries  Political ramifications  Legal issues: XML expression of digital rights  Can we do this in a standardized way?  Can it be done for “local” e-collections?

34. ERM and Consortial Issues  Different consortium types  Shared Mission/Collaborative Collection Development/Integrated Services  “Buying Club”  Different staffing, roles and expectations  Varying ILSs, other tools within group

35. ERMs and Consortial “Administrivia”: Possible Connections  Descriptive Data (bibliographic, holdings)  Contact Information Management  Vendors  Libraries  Administrative Information  Concurrent users  IP’s  License Information  Usage Information  Workflow and status tracking  Troubleshooting and problem tracking  Need for data standards, interoperability

36. e-ILL Management Wish List  Stable, standardized definitions  Clear, brief “rights” summary by journal  Accurate “rights” summary by journal  Clear description of local policy by title  Practical data structure  Clear, usable interfaces for input, editing, display

37. e-ILL encoding 1: DLF  Numerous data elements  12+ for Terms of Use  5 of these are for ILL  Predefined values for 4 of ILL elements  Possible added coding for local policies as needed?