04/08/23 1
Report on the Digital Library Federation Electronic Resource Management Initiative (ERMI), with a focus on XML schema for e-Resource licenses, plus news about CUL's
implementation of III's ERM product
Adam ChandlerCentral Technical Services
Cornell University Library
Metadata Working Group, September 24, 2004
2
"As libraries have worked to incorporate electronic resources into their collections, services and operations, most have found their existing Integrated Library Systems to lack important functionality to support these new resources. An earlier study (Jewell 2001) determined that a number of libraries had begun developing local systems to overcome these shortcomings, and the DLF Electronic Resource Management Initiative (ERMI) was organized to aid the rapid development of such systems by providing a series of inter-related documents to define needs and to help establish data standards."
Executive Summary, Digital Library Federation Electronic Resource Management Initiative Report, August 2004:
3
4
5
Presentation Outline
• Background: the DLF E-Resource Management Initiative
• Summary of DLF ERMI Deliverables• Results of ERMI XML and License
Information Investigation• Outstanding ERM Issues• Vendor/Library Initiatives• Cornell's Implementation of Innovative
Interfaces’ ERM Product
6
DLF ERMI Goals (Oct. 2002)
• Describe architectures needed to manage large collections of licensed e-resources
• Establish lists of elements and definitions• Write and publish XML Schemas/DTDs• Promote best practices and standards for
data interchange
http://www.diglib.org/standards/dlf-erm02.htm
7
DLF ERMI Steering Group
• Ivy Anderson (Harvard) • Adam Chandler (Cornell University) • Sharon Farb (UCLA)• Tim Jewell (Chair, University of Washington) • Kimberly Parker (Yale)• Angela Riggio (UCLA)• Nathan Robertson (Johns Hopkins)
8
ERMI Project Deliverables (under Creative Commons "Attribution" license)
• Problem Definition/Road Map
• Functional Specifications
• Workflow Diagram
• Entity Relationship Diagram
• Data Elements and Definitions
• XML Investigation
http://www.diglib.org/pubs/dlfermi0408/
9
Problem Definition/Road Map
• Introduction: The Need for Comprehensive Electronic Resource Management Systems
• Current Efforts to Create Electronic Resource Management Systems
• A Life-Cycle Based Overview• Background: Evolution and Organization of the
Project• Project Deliverables and Use Scenarios• Response to the Initiative and Future Considerations
10
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 a discussion of the most important features they might wish to purchase or incorporate into a locally-developed electronic resource management system, or use the specifications as an early draft vendor RFP for such a system.”
11
Functional Specifications
Example:
1. Identify what bibliographic entities (electronic and print) are covered by or provided through a given license, set of business terms, package, and/or online interface platform (hereinafter "interface").
12
Workflow Diagram
“Devising a detailed but generic workflow diagram was expected to help the steering group understand work processes, and thereby help assure that other documents would be developed appropriately and completely. Once available, the Workflow Diagram could provide a reference point for analyzing local workflows – which could lead to improved internal communication and more streamlined processes.”
13
14
Entity Relationship Diagram
“An Entity Relationship Diagram (ERD) is a standard system development tool that can help designers conceptualize and present groups of data elements (“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 assist future system designers.”
15
Entity Relationship Diagram
16
Data Elements and Definitions
“Providing a standardized list of entities and data elements was projected to save developers substantial time, and could prove particularly helpful to the development of data standards. As with the ERD, draft lists of data elements were discussed at the DLF/NISO workshop, and it was intended that the final, single list would be keyed to, and organized to reflect, the ERD.” [More than 300 elements.]
17
Data Elements and Definitions
18
XML Investigation Sub-group
• Adam Chandler (Cornell, Chair)• Sharon Farb (UCLA)• Nancy Hoebelheinrich (Stanford)• Angela Riggio (UCLA) • Nathan Robertson (Johns Hopkins)• Rick Silterra (Cornell)• Simon St. Laurent (O’Reilly & Associates)• Robin Wendler (Harvard) special thanks to:• Renato Iannella (developer of ODRL) • Susanne Guth (Wirtschaftsuniversität Wien)
19
Why License Focus?
• Originally considered a schema for the entire data dictionary, but . . .– Significant overlap with existing and emerging
schemas.– Limited functionality.
• Why licensing?– Area of considerable concern and current interest.– Significant commercial activity in defining and
schematizing.– Limited library activity in defining and
schematizing.
20
Uses for License Data Exchange
• Licensing elements actionable in an ERM system– Convey appropriate license restrictions.– Show or hide resources depending on
availability to certain groups.– Prompt staff for action
• Exchange with consortial partners• License feeds from vendors
21
Existing License/Rights Efforts
ONIX for Serials
<indecs>
METS
ODRL XrML
Rights are part of scope, but planned for later development.
“metadata framework.” Insufficiently precise.
Has developed a draft “simple rights schema” while more comprehensive RELs (XrML, ODRL) are being developed and debated.
22
ODRL“does not determine . . .
requirements of any trusted services . . . that utilize its language.”
“does not enforce or mandate any policies for DRM.”
“has no license requirements and is available in the spirit of ‘open source’ software.”
XrML“licenses can be interpreted and
enforced by the consumption application.”
“How will the industry benefit from XrML? Enables the creation of new revenue streams based on the ability to control the use and access of digital content and services”
“a portfolio of patented technologies. . . . if you use XrML in a context covered by the ContentGuard patents, then there may be a fee.”
ODRL vs. XrML (MPEG-21/5)
23
Read:
Coyle, Karen. "Rights Expression Languages: A Report for the Library of Congress." February, 2004. Available at:
http://www.loc.gov/standards/Coylereport_final1single.pdf
A Rights Expression Language (REL) is "a different kind of language; it is a formal language like mathematics or like programming code; it is language that can be executed as an algorithm" [Coyle 2003].
24
XML Container Model w/REL
XML
Rights Expression Language
Data Values
25
Pros?
Uses existing rights expression languageAvoids creation of library-specific metadata
standardHelps build momentum for open ODRLHelps bridge human license reading into
actionable computing values
? Builds a crosswalk between ERM systems and Digital Rights Management applications
26
ERMI Use Case Elements
Fair Use Clause Indicator Citation Requirement Details Display Digitally Copy Print Copy Scholarly Sharing Distance Education ILL Print or Fax ILL Secure Electronic Transmission ILL Electronic
Course Reserve Print Course Reserve Electronic / Cached Copy Electronic Link Permission Course Pack Print Course Pack Electronic Remote Access Walk-in Users Authorized User Groups Authorized Locations
27
ODRL Permissions Model
28
ODRL
<o-ex:agreement> <o-ex:asset> <!--Title information, etc.--> <!--description outside ODRL scope--> </o-ex:asset> <o-ex:context> <!--Information about the agreement--> </o-ex:context> <o-ex:permission> <o-dd:display /> <o-dd:print /> <o-dd:lend> <o-ex:constraint> <o-dd:count>5</o-dd:count> </o-ex:constraint> </o-dd:lend> </o-ex:permission></o-ex:agreement>
29
ERMI Extensions to ODRL
<o-ex:agreement>
<o-ex:permission>
<!--explicit permissions-->
<ermi:illprintorfax />
<ermi:pcoursepack />
</o-ex:permission>
<ermi:assumed-permission>
<o-dd:print />
<o-dd:display />
<ermi:scholarlysharing />
</ermi:assumed-permission>
</o-ex:agreement>
30
ERMI License ODRL Rights Expression
Many similarities in function & specificsODRL is extensible, non-prescriptive ERMI licensing needs more generic rights
statements ERMI needs more specific rights statements ODRL requires explicit permission assertions
(silence=prohibition)
“ODRL pictures the contracts which define the relationships as a series of checkboxes rather than a complex legal document written in somewhat creative English.”
31
ERMI Permission Values
Permitted (explicit) Permitted (interpreted) Prohibited (explicit) Prohibited (interpreted) Silent (uninterpreted) Not Applicable
via “out of the box” ODRL
32
Cons?
Inability to distinguish prohibitions from silence leads to loss of much useful data
“silence=denial” means extra work to identify and explicitly state all assumed permissions
Our “assumed permissions” extensions don’t mesh with ODRL processing model
Extensions increase validation demands Concern that ERMI usage may be incorrectly
used to limit users' activities (“Fair Use”)
33
Creative Commons license via RDF
"Unlike Digital Rights Management (DRM) technology, which tries to restrict use of digital works, Creative Commons is providing ways to encourage permitted sharing and reuse of works."
34
Results of CC RDF Experiment
The Creative Commons use case is very different from our ERM context
While we were able to show how it is possible to extend CC RDF to include our elements, we do not see how it is possible to actually validate the values in an ERM XML document using our extended CC RDF
Conclusion: Very little is gained from using this established REL. (However, RDF as a technology may still be useful to us.)
35
ERMI “Native Schema”
• The benefits of using XML as data exchange container are well established, but ODRL, MPEG 21/5 and Creative Commons RDF are all problematic within this context
• Therefore, we conclude that the focus in the near term should be placed on developing use specific XML application profiles that draw on ERMI elements and other namespaces (e.g., Dublin Core).
36
Characteristics of an Application Profile
• May draw on one of more existing namespaces
• Introduce no new data elements
• May specify permitted schemes and values
• Can refine standard definitions
Heery, Rachel; Patel, Manjula. "Application profiles: mixing and matching metadata schemas." Ariadne Issue 25 (24-Sep-2000). Available at: http://www.ariadne.ac.uk /issue25/app-profiles/intro.html
37
XML Container Model w/o/REL
XML
Application Profiles
Data Values
38
Outstanding ERM Issues (1)
• Consortium Support and Functionality– The focus of work of the Initiative has been
on the needs of individual libraries, rather than those of the library consortia to which so many libraries now belong.
• Usage Data– Pointer to “Project Counter”– Jeff Shim, Assistant Professor at FSU is
working on a white paper about this issue
39
Outstanding ERM Issues (2)
• Serials Description and Holdings– Pointer to NISO/EDItEUR Joint Working Party for
the Exchange of Serials Subscription Information
• Standard Identifiers– 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.
40
Outstanding ERM Issues (3)
• Data Standards and License Term Expression
• Interoperability– Watch for “VIEWS” initiative
41
ERMI Next Steps: There will be a meeting at the 2004 DLF Fall Forum to discuss the
following:
• Form joint LITA and ALCTS interest groups?• Renew "standards discussion" process?• Should there be a (or multiple) standard(s)?• What maintenance agency? • Develop "resource record" exchange
testbed?• Vendor development
42
Vendor Initiatives (1)
• Innovative Interfaces: “ERM” module announced 2003; some 60 sold to III customers, with another 4 or 5 stand alone (non-III)– “In creating this product, Innovative has
taken care to comply with the DLF’s (Digital Library Federation) emerging standard for describing electronic resources”
43
Vendor Initiatives (2)
• ExLibris: “Verde” product announced; release planned by end of 2004– From the outset, Verde was planned to address
the requirements of the Digital Library Federation electronic resource management initiative (DLF ERMI; see http://www.library.cornell.edu/cts/elicensestudy/home.html). The Verde system extends these requirements, particularly in its approach to library consortia and its provision of cost-analysis tools.
44
Vendor Initiatives (3)
• Endeavor: “Meridian” product announced at ALA (http://www.endinfosys.com/meridian)– “The system’s functionality is guided by the
requirements outlined by the Digital Library Federation’s Electronic Resource Management Initiative and interacts with integrated library systems, like Endeavor’s Voyager, for MARC and acquisitions data.”
45
Vendor Initiatives (3)
• Dynix: ERM White Paper available on the Dynix Web site, development to follow– “Dynix is a member of the DLF ERMI
Vendor Reactor Panel and believes that participation in the DLF ERMI will not only help accelerate the introduction of ERM solutions, but will also promote industry interoperability.”
46
Vendor Initiatives (3)
• SIRSI: System prototype shown at ALA
• VTLS: "Verify" product and rapid development plan announced; linking product marketing to NISO "Views" (Vendor Initiative for Enabling Web Services)
• Serials Solutions: in planning
47
Libraries and Consortia Developments
• Colorado Alliance (“Gold Rush”): enhanced ERM support later in 2004?
• Johns Hopkins HERMES: open source, but may or may not be maintained and developed
• UCLA “Erdb”: UC System evaluating alternatives, including possible Erdb expansion, III ERM, and Ex Libris Verde
48
ERM implementation at CUL …
49
Cornell ERM Functional Specs: Stakeholder Analysis
• February 2004, Karen Calhoun led a stakeholder analysis of CUL staff ERM needs
• DLF ERMI Functional Specifications were used as a basis for the interviews
50
ERM at Cornell (1)
• Signed contract with Innovative Interfaces, Inc. in summer 2004 for purchase of standalone ERM software
• Task force – Adam Chandler– Surinder Ghangas– Bill Kara– Jesse Koennecke– Maureen Morris– Scott Wicks (project leader)
51
ERM at Cornell (2)
• Server installed• Training completed• Next steps
– Resolve data migration details (bib, coverage)– Retool CUL workflow– Customize public interface– Input resource and license data– Set Find EJ switchover date
52
ERM Cornell Model
53
ERM Model
54
55
56
http://www.library.cornell.edu/cts/elicensestudy/
Or Google “Web Hub”
Adam Chandler
Questions and Comments