CDL Electronic Resource ManagementRequirements

7/8/08

Business Need

The CDL needs a flexible, automated electronic resource management system (ERMS), tool, or set of tools to create greater efficiencies in the acquisition and ongoing management of Tier 1 and CDL-managed Tier 2 resources. The basic goals of this system or set of tools will be to serve as a database of record for licensed content managed by the CDL, organize CDL workflow, and provide critical information to campus librarians, while minimizing redundancy of data entry and multiple system management. Areas of core functionality include:

  1. Collection development processes and workflow to supportthe acquisition of tier 1 and tier 2 resources (both licensed and open access), including selection, evaluation, and de-selection
  2. Licensing processes and workflow
  3. Access provision and administration, including functions necessary to implement resources within the CDL environment
  4. Ongoing management and tracking of resources over time (i.e. contract management, business terms, campus and vendor contacts, and other administrative information);
  5. Communication with campus stakeholders about Tier 1 and Tier 2 resources and the processes supporting them.

Providing information to end-users (i.e. students, faculty, and other library patrons) is not a goal of the CDL ERM system, although the ability to communicate terms of use to end users via an intermediate system (such as the SFX services menu) is a desirable (but not mandatory) attribute.

Definitions

  • A&I: Abstracting and Indexing
  • Constituent resource: an electronic resource that is contained within a parent electronic resource (the latter, a package).
  • ERMI: The Digital Library Federation’s (DLF’s) Electronic Resource Management Initiative ( resulting in a proposed standard for ERM Systems.
  • Package: an electronic resource that contains other, constituent resources (children). Packages may be ‘fixed’ (e.g. aggregator databases) or ‘selective’ (comprised of titles that are individually selected for inclusion (e.g. most journal publisher packages).
  • Shared print: As used here, refers to print items that are received as a concomitant to a Tier 1 or Tier 2 electronic license.
  • Standalone resource: a single electronic resource with no parent-child hierarchical relationships. In general, a standalone resource functions like a package without any children.
  • Tier 1:Material that is licensed for all 10 campuses (or 9 campuses if the content is non-medical and UCSF is excluded). The CDL negotiates the license and in most cases, all UC users have access to this material. It may be funded, in whole or in part, by the CDL. Occasionally, resources licensed by fewer than 9 campuses are considered Tier 1 if the acquisitions and licensing processes have been handled by the CDL.
  • Tier 2: Material that is licensed, with the assistance of the CDL, for users at three or more campuses. Funding is generally shared by the General Libraries on the campuses involved. There may be a nominal CDL contribution; for example, to ensure that no UC campus pays more than it would by licensing the resource directly from the provider.
  • Tier 3: Material that is licensed and funded by the General Library at a single campus for users on that campus. Tier 3 resources may be separately licensed by multiple campuses. Some Tier 3 resources may be linked to a CDL license through a campus-specific amendment (“assisted Tier 3”).
  • Tier 4: Material that is licensed by individual subscribers or funded by units other than a UC campus general library, and to which access may be limited to specific individuals or groups.

Scope

The CDL analysis and requirements specificationsare focused on shared digital content – primarily ejournals and A&I or fulltext databases, including ebook aggregations – acquired and managed by the CDL on behalf of the UC libraries. Specifically, the present solution must support the selection, evaluation, implementation and ongoing management of Tier 1 resources and those Tier 2 resources to which CDL provides support (generally in the form of acquisitions support). Mass digitized books are excluded from this definition.

Resources that are not supported by CDL are out of the current scope unless they are linked to a CDL license as an “assisted Tier 3”. For resources in that category, only minimal information sufficient to document the CDL license relationship will be maintained.

Other Assumptions

  • SFX is and will continue to be the link resolver in use throughout UC
  • Acquisitions, SFX data entry, and shared cataloging activities are and will continue to be performed by CDL staff at UC San Diego.
  • Acquisitions information is recorded in the Innovative Interfaces Millennium System but may be migrated from this system in the (near) future.
  • Actual invoice payment and cost recovery for campus co-shares are implemented directly in the UC San Diego financial system and will continue to be so for the foreseeable future.
  • Cataloging for Tier 1 and CDL-supported Tier 2 resources (as well as some other Tier 2 resources) is and will continue to be performed in the Innovative Interfaces Millennium System at UC San Diego

Preferences

Although not required, CDL will give preference to proposed solutions which provide the following:

  • Minimized administrative burden on CDL Infrastructure group;
  • A user interface that implements common usability features;
  • A user interface that complies with:WorldWideWebConsortium(W3C)“WebContentAccessibilityGuidelines” and Section508oftheRehabilitationActof1973,asamended(29U.S.C.794d).
  • Full functionality across standard desktop platforms (Windows and Mac).
  • Open access to the datastore, through some API or other kind of web service.

Time Table

  • March-May: Finalize CDL requirements document
  • June-July: Evaluate system options against CDL requirements
  • August: Select system approach (build or buy) and develop a project plan and timetable

Data Model Requirements / Interrelationships

Following the DLF-ERMI model, the CDL ERMS solution must enable users of the system to:

  1. Identify what bibliographic entities (electronic and shared print) are covered by or provided through a given license, set of business terms, package, provider, and/or platform/access service; and
  2. Associate the characteristics of a given license, set of business terms, package, provider, and/or platform/access service with all of the bibliographic entities to which they apply.
  3. For a record of any given type (resource, provider, license, etc.), link directly to a related record to view and/or update information (e.g. from resource to license, license to provider, provider to license or resource, etc.)
  4. Manage and maintain information about these entities in an efficient manner with a minimum of redundancy; for example, by allowing contact information for a given provider or library staff member, or license information pertaining to a given license, to be updated once and made available to all of the bibliographic and other entities to which it applies

A list of records and required data elements is included as an Appendix to this document. Record types are not definitive – that is, an alternate data model may be implemented – as long as the indicated data elements are present in a form that supports the required functionality. Additional site-definable fields should be liberally provided.

Functional Requirements

  1. Workflow Management - General

1.1.It should be possible to establish a site-defined workflow for key activities in the eresource life cycle. For example, it should be possible to send notifications to designated staff or departments or to place resources in a queue for further action by those units to trigger actions such as the placing of an order, completion of cataloging, and implementation of access management by designated staff. Examples of specific workflow requirements requiring support will be identified in the appropriate functional section.

1.2.Linking capabilities:

1.2.1.Email addresses, urls, and other links should be actionable.

1.2.2.In general, all note fields should support hyperlinks to external information.

1.3.The system should support both ad hoc and automated (rule-based) notifications and other actions based on state changes, calendar date, time elapsed, and other triggers. Examples of specific requirements will be identified in the appropriate functional section.

1.4.Role-based authorization is mandatory to control access to specific system features; for example to limit access to financial or administrative functions to designated staff, or to permit read but not write access to some or all functions.

1.5.Custom fields and custom option values. The system should allow for site-specific values for such fields as “status.” In addition, it should be possible to set additional custom “flags.” It should be possible to base a report selection on custom values.

  1. Selection and Evaluation

The system should support the ability to enter new records for resources under consideration and manage the selection and evaluation workflow bytracking the selection and evaluation process for resources under consideration through acquisition or rejection, including the following:

2.1.Create new and/or provisional records for resources that are not currently in the system’s knowledgebase

2.2.Associate a requested resource with a particular bibliographer group.

2.3.Assigna CDL-definable selection status to new resource records and to unlicensed records in the system’s knowledgebase, if applicable (i.e. if the system offers a knowledgebase including both licensed and unlicensed resources), and associate particular actions with those statuses as further outlined below. Examples of such statuses might include “New Request,” “On Trial,” “Under Consideration,”“Recommended,” “Approved,” “Rejected,” “On Hold,” “Active,” or “Cancelled.”

2.3.1.Selection status and associated actions should be assignable to standalone resources, packages, and (for selective packages only) individual constituents of packages (for use in title management projects). Constituents of fixed packages should not be available for individual selection and workflow.

2.4.For resources on trial, record trial start and end dates

2.4.1.Trigger notifications to designated recipients based on those dates (e.g. advance notification of an impending trial end date)

2.4.2.Record a trial URL, and make that actionable

2.4.3.Make trial resources available in a secure manner through the library’s resource tool of choice to authorized users (if wanted) and staff

2.5.For resources on trial or under consideration, record a decision due date

2.5.1.Send an alert to designated recipients n days prior to decision date (desirable / optional)

2.6.Allow staff to submit comments about resources that are on trial or under consideration (either directly or via a web-based form) (desirable / optional)

2.7.Record price and offer details for resources under consideration, including prices for different scenarios and links to external documentation. May be accomplished via a free-text note field (field must be of adequate length)

2.8.Record information about the availability of MARC records

2.9.Record the names and email addresses of one or more reviewers

2.10.Record notes aboutthe decision to acquire or reject a new title, including links to external documentation.

2.11.Purge rejected records from the system, sequester into a history archive, or retain such records with notes about the decision process (including a link to external information if wanted), at the library’s discretion.

2.12.Generate displays of resources and associated information based on selection status

2.13.Generate reports of resources based on selection status, trial date, and/or decision due date, including the ability to designate which fields are included in the report

  1. Licensing

3.1.Support the following relationships:

3.1.1.identify what license agreements are in effect from a given provider

3.1.2.identify what license agreements are applicable to a given resource or set of resources

3.1.3.link one or more license agreements to another license agreement as an amendment

3.1.4.record a historical chain of license agreements

3.2.Record the categories of users that are authorized for access to a given resource

3.3.Record the sites (i.e. campuses or other participants)that are authorized for access to a given resource

3.4.For terms of use including, but not limited to, interlibrary loans, reserves, and course packs:

3.4.1.Identify whether a given resource may be used for the service and under what conditions

3.4.2.Generate reports of all resources that may or may not be used for the service

3.5.Record additional license terms (permissions, restrictions, and obligations of the parties), such as:

3.5.1.confidentiality provisions

3.5.2.cure period for breach

3.5.3.termination conditions and requirements

3.5.4.amount or percentage of allowable downtime

3.5.5.other site-definable key terms

3.6Record metadata needed for contract management and auditing purposes, such as:

3.6.1.license commencement and expiration dates

3.6.2.duration of agreement

3.6.3.renewal type (automatic or explicit) (desirable / optional)

3.7.Record official contract notice address and associated requirements (e.g., delivery requirements)

3.8.Indicate whether archival and perpetual rights are available and under what conditions

3.8.1.Generate reports of this information

3.9.Provide a link to an online and redacted version of a license agreement

3.10.Retain archival versions of license terms and conditions if desired, including the ability tomap previous terms of agreement to the bibliographic entities and dates for which such terms applied;

3.11.Assign a library negotiating contact to a given license (name, affiliation, email)

3.12.AssignCDL-definable status fields to licenses, with status notes. Examples might include “Under Review,” “In Negotiation,” “Awaiting Signature,” “Current,” “Expired”

3.13.For licenses requiring explicit renewal:

3.13.1.Notify negotiating contact n days in advance of license expiration date

3.13.2.Generate reports of licenses set to expire on or before a given date, or within a range of dates

3.14.Provide automated tools to update license expiration dates when a resource is renewed, or describe how this function is accomplished

3.15.Support workflow for breach investigation and cure activities and other activities that may be required to fulfill license obligations, including:

3.15.1.Differentiate type of breach: access, download, performance, content, etc.

3.15.2.Monitoring and notification processes in support of compliance.

3.15.3.Reporting that provides cumulative incident data.

3.16.Describe plans, if any, for future support of ONIX-PL (import and/or export)

  1. Implementation and Access Management

For newly licensed or acquired resources ready for implementation, support the following information and workflow:

4.1.Record the campus or other participants for which access should be available

4.2.Record the following access information:

4.2.1.Vendor-supplied access url

4.2.2.Indicator of what type of permanent URI is assigned (BibPurl, SFX OpenURL or PID)

4.2.3.Access URIs for multiple campuses

4.2.4.Requested activation date (optional)

4.2.5.Start date of subscription

4.3.Record information necessary to configure external authentication and access systems (including proxy services)

4.4.Generate notifications and/or exports of URI information to appropriate linked or external systems according to local requirements (e.g., notification or export to cataloging and information technology departments or systems)

4.5.Support a site-defined checklist, or the ability to link to an external checklist, to track workflow for activating a new resource (see attached CDL Checklist)

4.5.1.Establish a site-defined routing workflow for resources that are approved for purchase. For example, it should be possible to send notifications to designated staff or departments or to place resources in a queue for further action by those units to trigger actions such as the placing of an order, completion of cataloging, and implementation of access management by designated staff

4.6.Record provider and participant contact information

4.6.1.Tier designation

4.6.1.1.If Tier 2, record lead campus and local contact information (name, campus affiliation, email - linked via a separate table)

4.6.2.Resource Liaison ((name, campus affiliation, email - linked via a separate table)

4.6.3.Multiple provider contacts (sales, licensing, technical, other)

4.6.3.1.Including site-defined role, name, title, phone, email – linked via a separate table)

4.6.3.2.Ability to designate contact to whom IP address updates should be sent

4.6.3.3.Ability to designate who maintains the IP addresses; the vendor or CDL

4.6.3.4.Ability to indicate if the vendor has been granted access to the WorldCat Registry records to maintain their access files

4.7.Administrative information should be able to be recorded at the package level to avoid redundancy when appropriate.

  1. Resource Administration and Ongoing Management

5.1.Record administrative url, username, and password, and associated notes

5.1.1.Restrict access to this information to authorized staff (optional?)

5.2.For a given resource or provider, indicate whether IP addresses must be registered online directly by the customer

5.2.1.Record url, username, and password for IP address registration

5.2.2.Restrict access to this information to authorized staff (optional?)

5.3.Store lists of IP addresses associated with a given campus or other unit for which licensing is performed, (e.g. labs).Preferred approach: a link into the CDL’s IP address service so we only are maintaining IP address information is one place

5.3.1.Generate reports of this information

5.3.2.Provide automated e-mail notification to designated online provider contacts (vendor or CDL staff) when IP addresses are updated

5.4.Record URL of server status provided by vendor (optional)

5.5.For selective packages only, allow status and holdings to be set for individual constituents

5.6.Allow linking to relevant access and administrative information at the appropriate level (constituent, package, or interface/platform)

  1. Usage Data and Assessment

6.1.Minimum requirements

6.1.1.Record usage statistics url, username, and password, and associated notes

6.1.2.Indicate whether statistics are COUNTER compliant, including version and date of adoption

6.1.3.Record historical information about platform changes

6.2.Desirable

6.2.1.Load and store usage data associated with individual resources, providers, and reported campus through automated or batch mechanisms

6.2.2.Support the SUSHI harvesting protocol to automatically collect the usage reports from library content provides into a central data storage database.

6.2.3.Store usage data over time, without restriction as to the number of years of data that can be retained

6.2.4.Provide the ability to load a variety of value metrics from various sources and associate these with usage data for analysis and reporting purposes, including list price, price paid, impact factors, holding information and other site-definable characteristics (e.g. UC authorship data)

6.2.5.Provide the ability to export this data to Excel or similar format for further analysis and reporting

6.2.6.Provide the ability to manipulate and analyze these data within the system (desirable / optional)

6.2.7.Store all kinds of usage reports that are available to harvest from vendors’ platforms: including Journal Reports (JR1, JR2), Database Reports (DB1, DB2, DB3), Books and Reference Works (BR1, BR2, BR3, BR4, BR5, BR6) and Consortium Reports (CR1, CR2)