�The DLF
E-Resource Management Initiative:
Project Report

	DLF Fall Forum
	Albuquerque, NM
	November 17, 2003

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

Background and
E-Resource Management Functions

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

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

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/)

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

The DLF
E-Resource Management Initiative

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)

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
	https://www.diglib.org/standards/dlf-erm02.htm

Original Project �Deliverables�

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

�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

�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?

ERM Metadata Standards Comparison

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)

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)

Workflow Flowchart Overview

	Contemplating Product Selection
	Initial Review (3 �parallel processes�)
		License
		Technical Feasibility
		Business Issues
	Implementation
	Routine Maintenance/Renewal

Workflow Flowchart (1)

Workflow Flowchart (2)

Workflow Flowchart (3)

Workflow Flowchart (4)

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)

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

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

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

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

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

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

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)

Entity-Relationship Diagram

ERD: Major Entities and Relationships

ERD: Major Entities and Relationships

ERD: Major Entities and Relationships

ERD: Major Entities and Relationships

Entity-Relationship Diagram

Data Element Dictionary: Overview

	Brief history
	Structural simplicity
		Data Element Name
		Identifier
		Definition
		Comments
	Groundwork for Data Structure and ERD

Data Element Dictionary

Data Elements: Considerations

	Overlap/integration with existing metadata schema
	ISO 11179
	Element names
	Defining complex concepts
	Exhaustibility/flexibility
	Recommending standards for element values

Data Structure Overview

	ERD + DED --> ???
	Data Dictionary Elements
		plus entity identifiers
		plus pointers between entities
	Data Dictionary Definitions
		plus data types
		functionality
		optionality & cardinality

ERMS Data Structure

XML investigation sub-group

	Adam Chandler (Cornell University)
	Nancy Hoebelheinrich (Stanford University)
	Angela Riggio (UCLA)
	Nathan Robertson (Johns Hopkins)
	Robin Wendler (Harvard University)

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

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?

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?

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

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

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

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

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

Impact, Challenges, and
Next Steps

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?

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

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?

Where to from here? (1)

	Project wrap-up (by DLF Spring Forum)
		Project report
		System survey
		Cross-check existing documents
		Round out draft schema

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

Questions and Comments

	http://www.library.cornell.edu/cts/elicensestudy/home.html