Legend:

Recommendation

• Daily updates for non-serials will be processed starting September 20, 2021

  • This lines up with the final dates to remove 856 fields system-wide and provides a short period of adjustment for all of the campuses

• Non-serials will be automatically overlaid using the import profile noted below.

• Campus “-ER” holdings set by CDL are out of scope until SCP finishes its own cleanup and a plan for updating these records is in place in order to minimize confusion

  • In cases where SCP brings records from CDL IZ to NZ, SCP would ideally get the updated OCLC records to import into NZ 

• Campuses can exclude individual records from being overlaid during the daily updates by adding this field:

  • 903## $$aExclude from WorldCat Daily Updates

  • The 903 should be used as sparingly as possible in order for the entire system to benefit from daily updates

  • The 903 field does not preclude campus catalogers from manually overlaying the bib via OCLC export, it only excludes the record from the automated overlay process

WorldShare Collections (created by UCSD):

    Non-serials

• Holdings: CUV, CUY, CLU, CUS, CUI, ZAP, ZAS, UCILW, LLB, CBG, CUX, CLETH, UCFTA, CUN, MERUC, MERA, CUT, RQE, CRU, CUZ

• NOT Mt:cnr

• Trigger for record delivery: any changes to master

• Records updated/holdings added after 01/01/2021

• Include 908 field with structure: WorldCat Daily Updates [YYYY-MM-DD] [reason for record output]

    Serials:

• Holdings: CUV, CUY, CLU, CUS, CUI, ZAP, ZAS, UCILW, LLB, CBG, CUX, CLETH, UCFTA, CUN, MERUC, MERA, CUT, RQE, CRU, CUZ

• Mt:cnr

• Trigger for record delivery: any changes to master

• Records updated/holdings added after 01/01/2021

• Include 908 field with structure: WorldCat Daily Updates [YYYY-MM-DD] [reason for record output]
  

Alma production import profiles:

• Non-serials:

  • WorldShare “New” and “Updates” files (and merges)

  • Note that “New” records should already have a record in Alma with the right 035, for example a brief “on order” record with an 035 added for the sake of matching. 

    • For now: RMFG is not going to filter anything other than records with the 903 noted below

    • No inventory creation

    • “allUC” Normalization #1

    • “allUC” Merge #1

    • Indication rule to filter out records with:

      • 903## $$aExclude from WorldCat Daily Updates

    • Don’t publish to OCLC (or any other external source), check impact on campus publishing profiles

    • Upon no match, do not import, stage report for campuses

    • Multi-matches: skip record and do not import

      • CDL staff will download the multi-match file and re-run it through a designated multi-match profile. The job will pause and require someone to manually handle the job and tell Alma to merge all of the matches. The UCs will allow automatic merge & combine for these situations given that the records will have been combined in OCLC already

    • Ignore CZ

• Serials have a lot more to consider, will need to start later than monos and likely reconsider file frequency and import profile structure. Start date for Serials is still TBD

  • Serials:

    • Indication rule to filter out records with:

      • 903## $$aExclude from WorldCat Daily Updates

    • No inventory creation

    • Upon match: do not import, stage report for campuses

    • “allUC” Normalization

    • Don’t publish to OCLC (or any other external source), check impact on campus publishing profiles

    • Upon no match, do not import, stage report for campuses

    • Multi-matches: skip record and do not import

    • Ignore CZ

• Campuses that already have updates running for serials can continue to process the updates if they are able do so. They are not obligated either way.   

Reasoning

• Campuses that currently process Daily Updates for serials also perform manual review

• RMFG had originally planned on more granular filtering during the loads for some specific resource types in the hopes of staging reports for campuses to review but found that staging reports based on import profile results is incredibly difficult at the consortial level. Rejected records are only put into MARC formats vs. Excel or csv, making it difficult to generate lists. In addition, without the ability to note which campuses have holdings on a given record, there is a tremendous burden placed either on the CDL-side to generate complex reports, or on the RMFG side to do the same with the data after the records have been posted. It is substantially easier to allow a wide range of records to be imported and ask for campus review/input on the process so that we can develop reliable filters later.

• WorldCat Daily updates are one of the most concrete examples of making trade-offs for the wider good. They require that campus staff relinquish some degree of control in exchange for the ability to take advantage of the work that’s happening at thousands of other libraries, in the hopes that there is more benefit than detriment. Knowing that every other consortia we’ve consulted has found them useful and has benefited from this trade-off, RMFG is confident that the UCs will see similar results once we have refined our processes.

Assessment

• Campuses are encouraged to review the effects of the WorldCat Daily Update imports on any areas of concern (for example: music scores, audio/visual resources, special collections). This can be done by searching for the 908 text above in addition to any relevant indices (resource type, location, etc.)

• If significant issues are found, campuses should:

  • Restore the previous version of the record if needed

  • Add this 903 field: 903## $$aExclude from WorldCat Daily Updates to prevent further overlays (if desired)

  • Make corrections in OCLC (to the extent possible)

  • Alert their RMFG rep to the issue so that the group can tailor the import profile over time

Background

WorldCat updates is a process where OCLC will deliver a set of records to a library based on actions taken in OCLC (including editing, merging, setting and unsetting holdings) and based on a “query collection” set up in WorldShare. In the UC case, that includes a list of holdings symbols and what types of changes we want to trigger record delivery. If a change listed in our collection happens to a record with one of the holdings symbols in the list, OCLC delivers a new copy of that record for central processing as we see fit. Records get delivered in sets that include:

• New records: the record never previously had *any* of the holdings symbols in our pre-set list attached but it does now. (These does not include merged records)

• Updated records: a record had at least one of the pre-set holdings symbols and was changed in whatever way we specify. This can be very granular (for example: only updates to 880 data) or very broad (“any change to the record”) (These do not include merged records)

• Merged records (also known as “control number changes,”): at least one of the holdings symbols in the list had holdings on a record that’s been merged in OCLC.

• Deletes: all of the holdings symbols from our list have been removed from the record in OCLC. We will not get “deletes” so long as someone in the UC system still has a symbol attached. (These also do not include merged records)

    WorldCat updates does not set or unset holdings at any point in the process. The only connection between WorldCat Updates and OCLC holdings is that the WorldCat Updates relies on a set of holdings symbols to decide which records to deliver. OCLC does not add records to Alma for us and it doesn’t delete them, it just sends us files of records for us to then add as we see fit. In a consortium it makes the most sense to do this in the NZ since it reduces duplication. For example, if 7 of us have holdings set on a given journal record and the title ceases publication. If all 7 campuses have their own version of WorldCat updates set up then they all get the same notification that the title ceased. Then all 7 of them, likely at different times, go to update the NZ copy of the record with the new closed dates. The first campus to do that would be the one to actually make the correction and the other 6 would just be checking and possibly overlaying a record for no reason. If we were to instead load that record one time, centrally, it saves everyone the trouble. 

Action Log