Vanguard-- Testing OCLC daily updates

Physical monographs published between 1980 and 1983 (and possibly 2015 or later)

UCSD and/or UCLA will put together a query collection in Worldshare Management System and demonstrate file processing

RMFG will develop normalization and matching rules for these updates

Update files for that query collection will be loaded into the NZ twice, towards the end of the Vanguard to give campuses time to become familiar with the environment and avoid major disruptions to other testing. RMFG will evaluate the impacts of the updates on campus IZ records

A lot of campuses have expressed interest in testing this for Vanguard since it may have implications for data clean-up ahead of go-live and since there are concerns about data loss. In addition, the potential for using OCLC updates aligns with the SILS principle of “One UC library collection” and with the goals around harmonization and reducing redundant work. It will be helpful for campuses to know what the workload is and what the potential gains are. The test set was chosen because the records are more likely to have updates and will not have the complications that serials can sometimes have. Two of the campuses also have experience processing serial updates. E-resources were left off because they behave very differently in Alma. Knowing how much can be updated using the OCLC service will also potentially impact the final order of NZ loading for go-live.

In order to allow testing of the impact of these files on other campuses without asking them to add their OCLC holding symbol to the query collection without knowing what those impacts will be, 3 campus symbols were chosen, knowing that the IZ impacts will very likely extend beyond those 3 campuses. For example: the query collection will not explicitly include OCLC holdings for UCSF or UCSB but the records delivered in the update file will likely overlay NZ records for which those campuses have holdings.

Check for data loss, particularly access points and other vital local data.

Create a rubric for assessing changes including things like encoding level, vernacular scripts, access points, RDA elements

Assess workload and time spent processing files

Check changes to NZ and impact on local IZ records

Liz confirmed with Orbis that they do not receive duplicate updates for records held by multiple campuses, so if 10 Orbis institutions own a resource they don’t get 10 updated copies if the record changes.

Orbis updates are handled centrally

UCSD: processes updates for serials and monos (minus special collections)

UCLA: processes updates for serials and actively looking at starting for monos

UCB: does not process updates

Some cataloging centers have not consistently been enhancing master records, and local data may be far superior to WorldCat data. (Example: https://catalog.library.ucla.edu/vwebv/holdingsInfo?bibId=4785626 vs. https://ucla.on.worldcat.org/oclc/19826640)

Some local authority control and bibliographic database maintenance may be better than what is available in WorldCat.

Sets (and possibly serials)

Special collections

Music

Hard to be sure of scale (likely thousands?)

Require manual review to be sure campuses actually want to accept the updated copy

Some data loss due to local data not ever being added to the master record and some data loss due to edits happening in OCLC (multi-volume sets in particular).

Local access points in bib records

Potential impact on bandwith for other decisions

Order of NZ loading

Depends on the potential for retrospective searching

Should we set up a centralized “Vanguard” collection or have each campus set one up on their own?

Centralized set up means choosing one campus to create the collection and handle the record delivery

Is there a campus that could take this on?

Does the same campus that sets up the collection have to do all of the processing or could processing be shared?

How to handle SCP resources?

Is NZ admin required?

Yes, CDL can create NZ admin accounts for whichever RMFG member(s) are testing this workflow.

Are other Vanguard campuses ok with one campus processing updates?

Timeline: when should we try to process the first update file?

Individual set up won’t have as much overhead per campus but also won’t give a sense of how record delivery for a consortia works

Scoping:

should we limit to a format or to a subset of Vanguard campuses?

Leave “--ER” holdings off to not interfere with SCP records?

only process change files a set number of times?