35
Managing E-resources Across the Consortium: DLF Project and Data Standards Developments ICOLC New Orleans, LA March 16, 2004

Managing E-resources Across the Consortium: DLF Project and Data Standards Developments ICOLC New Orleans, LA March 16, 2004

Embed Size (px)

Citation preview

Managing E-resources Across the Consortium:

DLF Project and Data Standards Developments

ICOLCNew Orleans, LAMarch 16, 2004

The quick take

DLF E-resource Management Initiative began 2 years ago, focus on individual libraries

Project nearing completion Data standards being proposed, discussed Vendors developing products Consortial requirements, impact, implications

not addressed . . . Until NOW!

Session Plan

The DLF E-Resource Management Initiative and Library Consortia – Tim Jewell

Colorado Alliance’s Gold Rush and subscription management functions – Alan Charnes

Current ERM Activities at the University of California – Beverlee French

Discussion Consortial ERM Requirements? Consortial support of library ERMs? Next Steps for ICOLC?

The DLF E-Resource Management Initiative

and Library Consortia

Tim Jewell

E-resource tasks not supported by current library systems

Generating, maintaining alpha and subject lists Loading “aggregator” & e-journal holdings information License term negotiation, tracking, communication

Authorized users Authorized use

ILL, Course packs, E-reserves “Scholarly Sharing”

Good faith efforts to communicate terms Administrative info. (authentication, contacts, etc.) Problem tracking & “triage” Planned, cyclical product reviews Systematic usage reporting Result: creation of many separate documents and/or

applications

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

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

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

Groups involved Steering Committee (7 members)

Cornell, Harvard, Johns Hopkins, UCLA, UW, Yale

Librarian Reactor Panel (17 members) Representatives from many libraries with ERM experience:

NC State, Ohio State, Penn State, Stanford, UT-Austin, etc.

Vendor Reactor Panel (12 members) Ex Libris, III, Endeavor, Dynix, SIRSI EBSCO, Colorado Alliance, Harrassowitz, OCLC, SWETS

Blackwell, Serials Solutions, TDNET,

Deliverables & Use 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

Deliverables & Use 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?

Functions

Support the ‘Life Cycle’ of electronic resources: Selection and acquisition Access provision Resource administration and support Renewal and retention decisions

Selection and Acquisition

Mount TrialsEvaluate

Content, interface Technical compatibility

Select Arrange funding / make deals

Negotiate LicenseOrder

Access ProvisionManage IP addresses and passwords Store & maintain URLsCatalog / add to resource discovery

portalsRecord/present license terms?Provide remote access services (e.g.

via proxy server) Interface with local authentication and

authorization servicesAssign persistent names

Resource Administration

Keep track of administrative IDs and passwords

Configure resources for local use user interface options institutional branding link resolvers

Mechanisms for restricting access to administrative functions

Support

Staff and end users Hardware and software requirements Downtime information Incident logging User support, documentation and training Designated vendor and local support

contacts Mechanisms for disseminating information to:

Reference librarians Help desk staff

Renewal/Retention Discussions

Information needed for renewal and retention decisions Problem history Downtime records Usage statistics Renewal reminders/ticklers

ERM Metadata Standards Comparison

Workflow Flowchart Overview “Thinking About” Product Selection Initial Review (3 “parallel processes”)

License Technical Feasibility Business Issues

ImplementationRoutine Maintenance/Renewal

Workflow Flowchart (1)

consideracquisition

recommendto consortia?

notify consortiaof product

consideration

notify internalstaff of productconsideration

product trial?

no

yes

negotiatedtrial licenserequired?

product trialstart

initiate triallicensingprocess

yes

no

yes

yes

activate trial inpublic interface

announce trialdeactivate trial

in publicinterface

gather andconsider trial

feedback

proceed?

nono

log decision andreason not to

proceed

no yes

toAp.2

determine if trialwill be public

public trial? public trial?

yes

noyes

no

from Ep.4

product trial end

trial licenseterms

acceptable?

negotiate triallicense terms

negotiationprogress

expected?

noyes

supplyauthentication

info (IPaddresses) to

provider

recordadministrativeinfo: contact,

problemprocedures, etc.

notification of newproduct

Workflow Flowchart forElectronic Resource Management

p. 1 of 4

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: 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

Functionality “Quick Take”

Store and display data not presently accommodated in current systems For End Users

Auxiliary descriptive data License information (permitted uses and restrictions) Availability Technical and platform-specific issues

For Staff License information (more detailed) Administrative IDs and passwords Configuration and management information Usage statistics and training information

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

Data Element Dictionary

Entity-Relationship Diagram

ELECTRONIC PRODUCT

PRINT VERSION

WORK

E-RESOURCE

ACQUISITIONUSER GROUP

AVAILABLE TO

LICENSE

LIBRARY

CONSORTIAL

PARTICIPATION

ORGANIZATION

is licensee

publishes

provides

vends

includes/is part of

TERMS DEFINED

E-PRODUCT/

LICENSE

negotiates

ACCESS

INFO

ADMIN

INFO

is licensor

LOCATION

AVAILABLE AT

CONSORTIUM

PARTNER LIBRARY

INTERFACE

delivers

WORKFLOW RULES

CONTACT

PROCESSING

WORKFLOW

TRIAL

PREVAILING TERMSCONTACT

RESPONSIBILITIES

negotiates

LIBRARY

PARTICIPATION

ERMS Data StructureAdministrative Information Entity Support Group

Definition: Used to record information necessary to support use of the electronic resource

Elements Hardware Requirements, Software Requirements, Maintenance Window Value, Provider System Status Uniform Resource Indicator,Provider System Status Uniform Resource Indicator Type, Resource Unavailable Flag, Resource Advisory Note, Incident Log,Training Information, Administrative Documentation, User Documentation

Notes FS36.5

Element DefinitionElementType

System Use /Functionality

Values Optionality Cardinality Notes / Examples

HardwareRequirements

Information about hardware requirements text R N

SoftwareRequirements

Information about software requirements text R N e.g., browser versions, plug-ins, fonts, andspecial client software

MaintenanceWindow Value

The provider's regularly-scheduleddowntime window for this resource

text FS36.2 R N

Provider SystemStatus UniformResource Indicator

The URI at which the provider posts systemstatus information

text hypertext linkfunctionality.Paired elementwith ProviderSystem StatusUniformResourceIndicator TypeFS36.4

Layout: URI.Latest Draft:UniformResourceIdentifiers (URI):Generic Syntax(RFC 2396)(August 1998)

R N

Provider SystemStatus UniformResource IndicatorType

The type of URI used to post system statusinformation

text Paired elementwith ProviderSystem StatusUniformResourceIndicatorFS36.4

URL, URN, etc RA N

ResourceUnavailable Flag

A flag that indicates that a resource is notavailable

logical public displayFS9

Yes / No O N may trigger a particular action

Resource AdvisoryNote

A note used to describe a problem with aresource, provide advance notice ofanticipated downtime, or convey othertemporary information.

text may be used forpublic displayFS6.2, FS9,FS10, FS36.6

O N

Local PerformanceMonitoring Notes

Information concerning Web sites orprograms that do local performancemonitoring

text FS36.3 O N

Incident Log A log of downtime and problem reports andtheir resolution

text FS36.7 O N An external call tracking system may be usedinstead.

TrainingInformation

Information about special arrangementsavailable for training, for example, tocircumvent simultaneous user restrictions

text FS34.1, FS34.3 O N May also include training contact names andother general information

Value might be a URI pointing to trainingdocumentation or interactive tutorials.

AdministrativeDocumentation

Information about and/or location ofdocumentation available for resourceadministrators

text FS34.2 O N

User Documentation Information about and/or location ofdocumentationavailable for end users

text FS34.2 O N

XML Investigation Scope

1. Much work elsewhere on descriptive data exchange (ONIX for Serials, etc.)

2. Concerns about XrML, MPEG-21 and other proprietary standards led to focus on license elements and 2 use cases:

a. License-related elements for library to library/consortium to library sharing

b. Shorter set of license elements for staff and users.

3. Next steps: presentation at DLF Spring Forum

What Next?

Market Response

Vendors Gold Rush Innovative Interfaces ExLibris Dynix Endeavor

Open Source Johns Hopkins (Hermes)

Project wrap-up (by DLF Spring Forum)

“What’s missing?” Functionality to support consortia? Usage data functionality?

Cross-check existing documentsRound out draft schemaSystem surveyProject report

Standards Issues (1)

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

Standards Issues (2)

Licensing Can “legal subtleties” be encoded? Can we share license descriptions?

“Players”: publishers, vendors, libraries Political ramifications Legal issues: XML expression of digital rights

Can we do this in a standardized way? Can it be done for “local” e-collections?

ERM and Consortial Issues

Different consortium types Shared Mission/Collaborative Collection

Development/Integrated Services “Buying Club”

Different staffing, roles and expectationsVarying ILSs, other tools within group

ERMs and Consortial “Administrivia”: Possible Connections

Descriptive Data (bibliographic, holdings) Contact Information Management

Vendors Libraries

Administrative Information Concurrent users IP’s

License Information Usage Information Workflow and status tracking Troubleshooting and problem tracking Need for data standards, interoperability