There once were thousands of bib records in the Alliance Network Zone (NZ) that contained two or more different OCLC numbers in separate 035$a ‘Other System Number’ subfields. These records caused problems when they needed to be overlaid (either by the automated daily load of OCLC updated bib records or a manual download using Connexion), or manually edited.
Summary
Why does this problem exist?
There are two separate causes for the presence of bib records in the NZ with multiple OCLC numbers. First, during the early years of automatic loading of updated OCLC WorldCat records to the NZ, a merge rule was used that retained all 035 fields from the existing Alma bib record when an NZ bib record was overlaid. In those days, this was necessary so that vendor record numbers such as Marcive brief shipping record numbers and YBP title record numbers, which are not present in the OCLC WorldCat records, would not be lost when an Alliance NZ bib record was overlaid with an updated record from OCLC. However, it was recognized at the time that this approach had a negative side effect that when two records were merged in WorldCat, some records when overlaid in the Alma NZ would have both the old and new OCLC records numbers in separate 035$a subfields. However, it was felt that this negative side effect was worth the benefit of retaining the vendor record numbers after records were overlaid.
The second known cause for the presence of these records is when an Alliance library loads vendor records (such as YBP records) and uses a match method (in the import profile) which allows matching on a data point other than OCLC number (such as the ISBN). When using a match point other than the OCLC number, an existing NZ bib record (for example OCLC #123) can potentially be overlaid with a different OCLC WorldCat record (for example OCLC #345), creating an NZ bib record with two OCLC numbers – OCLC #123 (the correct OCLC number) and OCLC #345 (an inappropriate OCLC number).
How do we stop new ocurrences of this problem?
In March 2016, we were able to implement merge and overlay rules that both allows retention of the vendor record numbers, while not retaining out-of-date OCLC 035 fields. Now import profiles (and the Connexion download configuration) that use these Alliance NZ merge rules no longer retain OCLC 035 fields from existing bib records when an overlay occurs or from incoming bib records when a merge occurs.
What happens to all the NZ bib records that already contain multiple, different OCLC numbers?
Records in the Network Zone that are not linked to the CZ have been identified and the conflicting OCNs have been resolved.
What happens to records in my IZ that contain multiple, different OCLC numbers?
Members are encouraged to identify and clean up any IZ-only records with conflicting OCNs using the process below.
Cleanup
Identifying conflicting OCNs:
In Alma Analytics, navigate to Shared Folders > Community > Reports > Consortia > Orbis Cascade Alliance > Cataloging. Copy the report named “Identify Conflicting OCNs in 035a”. Paste the report into your institution’s folder or your “My Folders” area. The report is set up to exclude records that are linked to the NZ or the CZ (though you will find that CZ records DO get in). Save the report and run it. Export the results to Excel or use a CSV export if you have a lot of records.
The report gives the MMS ID of each record with conflicting OCN values in its MARC 035$a fields. The report also provides the conflicting OCN values for each record. Use the MMS ID values from the Analytics report to create a set of the records with conflicting OCNs in Alma. Remove from the set (and your report):
- Any records linked to the CZ – These are notorious for having conflicting OCNs, but are Ex Libris’s responsibility to correct.
- Any records linked to the NZ – These will be cleaned up in a regular process by Alliance staff.
Evaluation/Cleanup
For each remaining record in the set and report, you will need to determine whether the conflicting OCNs are now part of a single WorldCat record or belong to multiple WorldCat records. This can be determined by searching for one of the conflicting OCNs in WorldCat and observing whether the other OCN is present in the 019 field.
For records where all of the conflicting OCNs are present in a single WorldCat record, then the conflicting OCNs come from an unresolved merge, and can be cleaned up by simply exporting the current record from WorldCat to your IZ.
The records that have OCLC numbers from multiple WorldCat bib records will have to be fixed manually. You will need to examine each of these records and decide which WorldCat record is the best match for the attached inventory, or if the inventory needs to be moved to a different bib record entirely.
Other OCN Problems
Will these changes and cleanup projects fix all the problems we know of with OCN accuracy?
No. We already know of two problems that will require additional exploration and development of separate solutions.
First, when OCLC merges records (either by the OCLC Quality Control team or the automated DDR software), in a small number of cases the merges are found to be inappropriate (e.g., different editions or formats) and OCLC “unmerges” the records. As a percentage, the number of records “unmerged” is fairly small. However, ‘there is no way to tell from looking at a bib record that it was involved in a record recovery’ and OCLC does not maintain a publicly accessible list of records which have been “unmerged.” Some Alliance libraries have defined logical sets which look for a format mismatch between a bib record and the attached inventory. This may identify some of the “unmerged” records. However, we need to continue looking for a better method of identifying “unmerged” records.
The second remaining issue, that we know of so far, is when libraries need to use a match method other than ‘Unique OCLC Identifier Match Method.’ These imports will continue to run the risk of overlaying one WorldCat bib record with a different WorldCat record. The TSWG YBP EOCR Load Group provided guidance in September 2016 on how to conduct import loads to minimize these “bad overlays”, but they remain a known risk.
Background
Software: Alma
Current phase: NA
Written by: Bob Thomas; Lesley Lowery
Approved by: NA
Last updated: 3/7/2022
Nature of last update: Removed outdated language, added cleanup procedure for IZ-only records.