Adam Chandler Central Technical Services Cornell University Library Metadata Working Group, September 24, 2004

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 Chandler Central Technical Services Cornell University Library Metadata Working Group, September 24, 2004

2. Executive Summary, Digital Library Federation Electronic Resource Management Initiative Report, August 2004: "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."

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

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: 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]. Coyle, Karen. "Rights Expression Languages: A Report for the Library of Congress." February, 2004. Available at: http://www.loc.gov/standards/Coylereport_final1single.pdf

24. XML Container Model w/REL XML Rights Expression Language Data Values

25. Pros? • Uses existing rights expression language • Avoids creation of library-specific metadata standard • Helps build momentum for open ODRL • Helps bridge human license reading into actionable computing values ? Builds a crosswalk between ERM systems and Digital Rights Management applications

26. ERMI Use Case Elements

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 & specifics • ODRL 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 via “out of the box” ODRL • Permitted (explicit) • Permitted (interpreted) • Prohibited (explicit) • Prohibited (interpreted) • Silent (uninterpreted) • Not Applicable

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)