OCLC WorldCat Updates in Alma
- Corinna Baksik
Table of Contents
Background
- formerly known as Bibliographic Notification Service (BNS)
- In Aleph, implemented April 1, 2013.
- In Alma, Phase 1 implemented in December 2021. Phase 2 implemented in April 2022.
- Old info:
- On-going working group wiki: /wiki/spaces/LibraryTech/pages/37488396, including example problems page.
- Original implementation project wiki, including final report: /wiki/spaces/itsprojects/pages/37355533
- Changes to handling of added authors and LCSH subject headings in 2015: https://harvardwiki.atlassian.net/wiki/x/QqqUAg
Eligible records
Bib Types / Levels
- LDR/06 = a (Language material)
- LDR/06 = c (Notated music)
- LDR/06 = g (Projected medium)
- LDR/06 = j (Musical sound recording)
EXCLUDED if:
- LDR/08 = a (Archival control)
- Part of Data Sync Archival/Manuscript collection "Trusted Partner processing" (i.e. 040 $e is any of: amim|appm|dacs|dcrmg|dcrmm|dcrmmss, and 502 is not present and 040.c.DLC is not present)
- As of 12/19/22: serials/integrating resources (LDR/07 = s or i)
OCLC symbols
- OCLC will only send us a record if one of the Harvard symbols are present.
Triggers for updated records from WorldCat
We will receive records from OCLC if any of the fields in the table below change.
Changes you make to records in Connexion under a Harvard symbol will be included in the files we receive from OCLC.
| Field | Note |
|---|---|
| Enc Lvl LDR/06 | Only if updated to ^, I, 7 |
| 008 | |
| 020 | |
| 022 | |
| 035 | OCLC number only |
| 019 | former OCLC number, will be translated to 035 $z |
| 050 | |
| 066 / 880 | Indicates presence of non-Latin script |
| 1XX | |
| 247 | |
| 34X | |
| 362 | |
| 38X | |
| 505 | |
| 520 | |
| 538 | Esp. useful for music |
| 6XX | Only 2nd indicators 0 or 2 |
| 655/*7 | |
| 7XX | |
008/06 | Type of date / pub status |
Enhancement / Merge details for the WorldCat Updates automated process
REMINDER: Some fields with $5 are retained no matter what. See Alma Merging Algorithms and Protected Fields, incl. valid subfield 5 codes. So, when the table below has "remove Alma," it is shorthand for "remove Alma fields except for the documented protected fields).
ALSO, some modifications to OCLC records are performed before they are brought into Alma, such as the removal of certain fields with $5. These norm rules are applied to incoming OCLC records before matching occurs. Full norm rule.
For incoming OCLC records with all Enc Levels | ||
|---|---|---|
MARC field | "Prefer Alma record" NO-OVERLAY BIBS | "Prefer OCLC record" Bibs without NO-OVERLAY See reminder above about protected fields. |
| 022 | Replace all (remove Alma, add OCLC) | Replace all (remove Alma, add OCLC) |
| 035 | Replace if number has changed | Replace all (remove Alma, add OCLC) |
041 | Replace if present in OCLC | Retain Alma only if field is absent in OCLC |
043 | Import if tag is absent | Retain Alma only if field is absent in OCLC |
050 / 060 | Import if tag is absent | Retain Alma only if field is absent in OCLC |
246 except 2nd ind. 8 | Import all unique values | Retain Alma only if field is absent in OCLC |
| 247 | Import all unique values | Retain Alma only if field is absent in OCLC |
| 340, 344, 345, 346, 347, 348 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
| 362 |
Import if tag is absent | Replace all (remove Alma, add OCLC) |
| 382 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
490 | Do not import | Replace all (remove Alma, add OCLC) |
504 | Import if tag is absent | Retain Alma only if field is absent in OCLC |
505 | Import if tag is absent | Retain Alma only if field is absent in OCLC |
510 | Import all unique values | Retain Alma only if field is absent in OCLC |
520 | Import if tag is absent | Retain Alma only if field is absent in OCLC |
| 538 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
| 546 | Import if tag is absent | Retain Alma only if field is absent in OCLC |
600 / 610 / 611, 2nd ind. 0 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
| 600 / 610 / 611, 2nd ind. 2 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
| 647, 648 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
650 / 651, 2nd ind. 0 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
| 650 / 651, 2nd ind. 2 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
655, except: | Import if tag is absent Note - we tested imported all unique values but it caused redundant fields due to differences in $0 $1 etc
| Replace all (remove Alma, add OCLC) |
| 700, 710, 711 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
752 | Import if tag is absent | Retain unique Alma values |
76X linking fields | Import all unique values | Replace all (remove Alma, add OCLC) |
770, 772 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
| 776 (other format available) | Overlay | Replace all (remove Alma, add OCLC) |
780, 785 | Import if tag is absent | Replace all (remove Alma, add OCLC) |
800 / 810 / 811 / 830 | Do not import | Replace all (remove Alma, add OCLC) |
| 991 "Reason for update" field from OCLC (see note) | Import | Import |
991 "Reason for update" field
Note - you are free to manually upgrade any record with new copy regardless of the presence of a 991 field.
- This will contain information from OCLC describing the trigger for sending the record to us
- If this field contains 019, it means that the OCLC record has been merged. We do not retain the 019 field, but we do update the 035 $a and $z. The 019 will be reflected in the 035 $z.
- Just because a field is listed here, it does not necessarily mean that the field was added to our record. For example, if trigger was the inclusion of new 650 fields, per the table above these new fields might not get added. The 991 with the "reason for update" would still be present. If a field is noted in 991, but is not present in the record, it may also mean the field was deleted from the OCLC record.
- The date of file delivery from OCLC will be in field 991 $b YYYY-MM-DD
- 991 is searchable in Advanced Search as Local field 991 WorldCat Updates trigger
| "Reason for update" examples | Comment |
|---|---|
| OCLC control number change - WorldCat record variable field(s) change: 019 | Merged record in OCLC. 035 of Alma record will be overlaid with new 035 a+z |
| OCLC control number change - WorldCat record variable field(s) change: 019, 050, 600, 700, 752 | Merged record, as well as other fields |
| WorldCat record variable field(s) change: 650, 651, 655 | Field changes only |
| WorldCat record encoding level change | Encoding level change |
| WorldCat record encoding level change - WorldCat record variable field(s) change: 050, 650 | Encoding level change and other fields |
| WorldCat record DtSt change | Change to 008/06 - Type of date/Publication status |
| NOTE: variable fields will only be listed if they are one of the "triggers." The record may have changes in other fields as well |
Notes on the handling of some fields
- 880 fields – cannot guarantee that these would match the transliterated pair. The only way this could work is if we overlaid the record, as opposed to enhancing it.
600, 610, 611, 650, 651 (LCSH, MeSH) – these are only imported if the HVD record had zero instance of the particular field. We do not attempt to compare headings and import unique values because we would end up with headings of both new and old forms, since Alma and OCLC authority control doesn't happen on the same day.
- 700, 710, 711 – Same issue as above, including further duplicates due to variations in relator terms (e.g. author updated to joint author).
- 776 - Same as above, where variations occur in form of headings, and changes to OCLC numbers when merges happen
- 362 - cannot bring in all unique values without creating problematic redundant fields, or adding a correct field and leaving in an outdated one
- 600/610/611/650/651 - for records without no-overlay, we must drop our values if present and replace with OCLC values, otherwise we will end up with improper fields when headings change from one field to another, such as headings that change from 650 to 600 (e.g. fictional characters)
- For some examples of the above problems from the Aleph days, visit /wiki/spaces/LTSWikiArchive/pages/43297346
Matching
OCLC numbers in both the 035 $a and $z will be used for matching. HVD records will receive the latest version of the 035 $a $z field from OCLC.
If multiple matches are found:
- The records with match on $a will be preferred (as opposed to records that match on $z)
- Otherwise, the record with the most recent creation date will be used