Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 20 Next »

See Best Practices for Decision Pages and Tags for groups
Legend: NOT STARTED STALLED DECIDED

Status

IN PROGRESS

Description

Prevent duplication of database level records (e-collections) coming from the NZ, where multiple instances of a title are essentially the same content or may duplicate locally acquired content.

Phase 4 AEFG proposal
Models for one bib record to many
Survey results - randomly selected participants with conflicting suggestions

Decision summary

Escalate to OT
Coordinating at ERES subteam level is problematic:

  • Our previous request for feedback by campus included group input (ERES, ACQ & DISC and non-SILS) randomly selected rather than broad systematic inquiry;

  • Feedback was contradictory and specific to the local system understanding, together with varying stages of data cleaning relevant to that campus, as well as the familiarity with local and CDL collections under examination;

  • ERES is unable to project manage the necessary consensus building due to the diversity of units and departments involved (technical services, discovery, public services, instructional services, user experience assessment, etc.). Some groups are represented within SILS and some are non-represented.

  • OT has the ability to examine this problem more broadly, including holistic computer system functionality (Alma, Primo, CDI, database search), alternative search tools such as LibGuides A-Z List, product purchase models (Tier 1, 2 and 3) and display inter-connectivity between IZ and NZ, and more.  

  • OT can determine the project priority, weighing tension between the SILS principles' desire for a great user experience vs reality of human resource level needed to make this deliverable possible.

Owning group

Originating group: ERES+ Paula Pascual

Approver

Consulted

Informed

Decision-making process

Decision consideration arose from request by SCP via CDL ERES Rep requesting guidance for activating an e-collection record when NZ has a series of e-collections for one vendor that all lead to one URL/one platform. Although CDL hoped for immediate feedback, ultimately the discussion surfaced broader factors and lack of consensus on approach for a solution.

Priority

Escalate to OT for advice

Target decision date

Date decided

Recommendation

The E-Resources Operations Sub-team initially recommended that in principle users should be provided with collection-level records for multi-part e-collections for discovery in UC Library Search. Collection-level records for Tier 1 and 2 resources should be managed by CDL in the Network Zone, so that individual campuses do not need to manage their own copies of the records. Although CDL hoped to provide a more in-depth needs analysis, ERES acknowledges that there is wide variation in the nature of our e-collections, so it is not possible to have a single recommendation for how to treat the collections and that experience with local use cases show that goals for outcome can vary by product and requestor. Cataloging decisions for migrated collections might need case-by-case examination to determine patterns, in consultation with relevant stakeholders (DISC, CKGs, reference, instructional design, user experience). Collectively, all relevant stakeholders need to identify user experience goals and generate a decision process for future collections, potentially manage as a stage of the acquisitions process for product specific decisions, or other model. Given this request came shortly after the formation of SILS, some period of time was provided CDL in order to become more familiar with the Alma/Primo record structure. However, in review of the delay, ERES recognizes that CDL output is only one factor in the outcome of this work and ultimately ERES has too narrow of a perspective to understand public services, reference and instruction needs. ERES recommends escalation to OT for a broader examination.

Impact

Stakeholder group

Impact

DISC

  • Campus representatives can provide feedback and recommendations for treatment for individual collections.

  • Consider impact of campus search scope and CDI

  • Can provide feedback on what information about the collections to convey to end-users.

ERES

  • Provides guidance on how to “link” the collection-level bibliographic records with the relevant collections in Alma to support local staff who work on:

    • access problems

    • Order information

    • licensing information

    • Analytics reports

SCP + CDL staff

  • CDL staff are responsible creating and maintaining the collection-level bibliographic records on inventory in the NZ. Concern that Alma collection descriptive records are not acceptable for discovery, and work around might be necessary to create a general/parent/umbrella bibliographic record that would stand in for the combined individual modules.

  • CDL will continue to set up collection level records on multipart collections, as CDL determines what seems best for any given collection. If anything develops later with a SILS team or group’s decisions about procedures or best practices that causes us to change our workflows, CDL will review it then.

User Experience

Given Tier 1, 2 and 3 acquisitions models, e-collection records will have a different outcome, have varying models based on vendor, interactivity of records between IZ and NZ content, and other factors such as search scopes set up in Primo.

CKGs, Instruction and reference services

  • Campuses can use and coordinate data for multiple tools, such as LibGuides A-Z Database List or Primo Database search, so combined metadata management output affects ability and consistency in achieving reference and instructional goals.

  • Different subject disciplines use and reference resources differently, so having their expertise applied to multi-series e-collection entries can ensure naming conventions match names used in professional disciplines.

Background

E-collections in Alma are structured to support back-end management, and are may not support discovery. Collections containing multiple modules often have separate entries for each module, and Alma collection descriptive records have been described as ‘not acceptable for discovery,’ so from a cataloging standpoint, the action to follow Alma instructions to unsuppress the collection-level bibliographic records results in both metadata management and discovery problems. Requests are usually made by library colleagues outside of technical services and have a specific use case they are trying to fulfill. This type of environmental scan to develop use cases and test with display scenarios exceeds the scope of ERES expertise.

Dependencies

  1. Given the varying nature of Tier 1, 2 and 3 e-collections, it is difficult to preemptively develop any and all possible cataloging models, and determine which model should be applied to each multi-part collection. This may require a permanent or sustained examination to consider all factors and develop workflows.

  2. Since there will not be a one-to-one relationship between the collection-level records and the individual Alma collections, managing the bibliographic records will need to be accomplished in consideration of local collections and will require consideration.

Questions to consider (ERES generated)

  1. How much ongoing review will be needed for:

    1. brand-new collections?

    2. new “modules” of an existing collection?

    3. existing collections that may need different treatment?

    4. collections that move between different providers?

  2. How will the general/parent/umbrella bibliographic record be linked to the relevant collections it is used for? Will that information be available to end-users in UC Library Search, or limited to Alma? In Alma, will campus staff be able to see the information, or would it be limited to the NZ?

Action Log

Action/Point Person

Expected Completion Date

Notes

Status

Consult with SCP - Lisa MacKinder

COMPLETED

Follow-up with Sherry

COMPLETED

Example of a multi-series database:

  • No labels