1	The DLF E-Resource Management Initiative: Project Report DLF Fall Forum Albuquerque, NM November 17, 2003
2	Talk Outline 1. Background and E-Resource Management Functions 2. The DLF E-Resource Management Initiative 3. Impact, Challenges, and Next Steps 4. Questions and Comments
3	Background and E-Resource Management Functions
4	Context for E-resource Mgmt. High demand for “24x7” access E-resource budget shares continue to grow (mostly digital environment in 5 years?) Budget issues driving shift to e-only journal access Dynamic marketplace & business models “Google-ization” (make it easy or forget it!) E-resources are complex (to describe, fund, and support) Impact of licensing
5	Some E-resource tasks not supported by current library systems Generating and maintaining alpha and subject lists Loading “aggregator” holdings information License term negotiation, tracking, and communication processes Wide staff involvement in selection & support Problem tracking Escalation/ triage paths Planned, cyclical product reviews Systematic usage reporting Result: creation of many separate documents and/or applications
6	Tracking Development Work : the “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/)
7	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
8	The DLF E-Resource Management Initiative
9	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)
10	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
11	Original Project “Deliverables” Problem Definition/Road Map Workflow Diagram Functional Specifications Entity Relationship Diagram Data Elements and Definitions XML Schema
12	“Refined” Deliverables 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
13	“Refined” Deliverables 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?
14	ERM Metadata Standards Comparison
15	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)
16	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)
17	Workflow Flowchart Overview Contemplating Product Selection Initial Review (3 “parallel processes”) License Technical Feasibility Business Issues Implementation Routine Maintenance/Renewal
18	Workflow Flowchart (1)
19	Workflow Flowchart (2)
20	Workflow Flowchart (3)
21	Workflow Flowchart (4)
22	Functional Requirements Outline Based on specifications developed jointly by Harvard and MIT for discussions with Ex Libris Introduction and Goals Guiding Principles Functional Requirements (47 main points) General (4) Resource Discovery (7) Bibliographic Management (2) Access Management (5) Staff Requirements (29) General interface requirements (4) Selection and evaluation processes (9) Resource administration and management (11) Business functions (5)
23	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
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	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
26	Core Requirements (1) Record license permissions and agreement metadata Authorized users Permissions and restrictions Obligations of the parties Administrative metadata Link to redacted license Support selection and acquisition workflows through customizable routing and notification tools
27	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
28	Core Requirements (3) Troubleshooting Incident log / call tracking Ability to flag resources as unavailable Incident history reports to monitor vendor performance Vendor contact information Complex business information Pricing models Cancellation restrictions Cost-sharing and consortial arrangements Archival rights Renewal actions and decisions
29	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)
30	Entity-Relationship Diagram
31	ERD: Major Entities and Relationships
32	ERD: Major Entities and Relationships
33	ERD: Major Entities and Relationships
34	ERD: Major Entities and Relationships
35	Entity-Relationship Diagram
36	Data Element Dictionary: Overview Brief history Structural simplicity Data Element Name Identifier Definition Comments Groundwork for Data Structure and ERD
37	Data Element Dictionary
38	Data Elements: Considerations Overlap/integration with existing metadata schema ISO 11179 Element names Defining complex concepts Exhaustibility/flexibility Recommending standards for element values
39	Data Structure Overview ERD + DED --> ??? Data Dictionary Elements plus entity identifiers plus pointers between entities Data Dictionary Definitions plus data types functionality optionality & cardinality
40	ERMS Data Structure
41	XML investigation sub-group Adam Chandler (Cornell University) Nancy Hoebelheinrich (Stanford University) Angela Riggio (UCLA) Nathan Robertson (Johns Hopkins) Robin Wendler (Harvard University)
42	XML Investigation Scope 1. Possible use case examples 2. Focused special attention on problem of formatting coverage data 3. Feasibility of XML schema to represent elements and entities 4. Next steps
43	Possible use case examples (1) Link resolver data exchange between vendor and library. Possible elements: title, title level coverage, user group license terms Publisher e-resource title list. Possible elements: title, package name, title level coverage, discounts, issn Possible exchange of data between the library ERMS and other campus systems such as course web sites?
44	Possible use case examples (2) METS escrow. To preserve resources in an archive, it is necessary to know the license terms that apply to objects. It would also be helpful to point to an image of the full text of the license. Possible place for an XML schema to guide exchange of trial information between vendors and libraries?
45	Possible use case examples (3) Imagine a web service between libraries and vendors for reporting and communicating support incidents. Both parties would then have a self archiving record of all troubleshooting. Transmission of IP ranges to vendors and contact info to libraries Exchange license data with a contracting partner
46	Coverage data (1) ERM requires a holdings / coverage schema that is: Rich enough to accommodate "routine" irregularities (supplements, indexes, unusual numbering and chronologies) Simple enough to facilitate easy production and common adoption by libraries and vendors Interoperable with schemas in existing systems Current standards and methods seem to be either rich or simple, but not both
47	Coverage data (2) NISO to begin work on abstract holdings schema and corresponding XML schema in early 2004. (Based on the Z39.50 schema, emphasizing functionality, clarity, simplicity) Rather than develop yet another competing standard, we recommend participation in the NISO development, and hope to adapt the resulting XML schema to our needs
48	Feasibility of XML schema to represent elements and entities Robin has developed a proof-of-concept schema that is available on the Web Hub. It includes Dublin Core and MODS namespace/schemas, with a slot for rights expression
49	XML Next Steps Continue recent conversation with Renato Iannella on how the Open Digital Rights Language may 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
50	Impact, Challenges, and Next Steps
51	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? DLF project offers first comprehensive schema, data model and tools specifically designed to address e-resources. What further work is necessary to guide or maintain development in this area?
52	Issues and Implications (1) Environment--highly dynamic, logarithmic growth, high cost, multidimensional nature, complex relationships 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
53	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?
54	Where to from here? (1) Project wrap-up (by DLF Spring Forum) Project report System survey Cross-check existing documents Round out draft schema
55	Where to from here? (2) Market Continue to encourage vendor development III, ExLibris, Dynix, others at various stages of product development, announcement, etc. Standards “Vet” parts of schema, etc. to different groups Determine future of schema as a standard Need “Maintenance Agency”? Other ideas--Come to BOF Tues. 4-6 http://www.library.cornell.edu/cts/elicensestudy/home.html
56	Questions and Comments http://www.library.cornell.edu/cts/elicensestudy/home.html