5/22/10 1 Report on the Digital Library Federation Electronic ...

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

alc28@cornell.edu

Questions and Comments