Records in the Alliance Network Zone (NZ) that contain two or more different OCLC numbers in separate 035$a ‘Other System Number’ subfields cause problems when they need to be overlaid and with record management.
In March 2016, the Alliance implemented merge and overlay rules that allow 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 (outdated) bib records when an overlay occurs or from incoming bib records when a merge occurs.
When loading records to the NZ, Alliance policy requires members to use the “Unique OCLC Identifier” match method whenever possible. This is because using a match point other than the OCLC number (e.g., ISXN, Vendor ID) can cause an existing NZ bib record (for example OCLC #123) to be overlaid with a record with a different OCN (for example OCLC #345) if they share the match point, creating an NZ bib record with two OCLC numbers. Please see the Alliance documentation on Alma import profiles for more detailed information about match points.
Are there NZ bib records that contain conflicting OCLC numbers?
All non-CZ records in the Network Zone with conflicting OCLC numbers have been cleaned up. An ongoing process is in place to identify any new conflicting OCLC numbers in NZ records.
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 Process
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, determine whether the conflicting OCNs are now part of a single WorldCat record or belong to multiple WorldCat records 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 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 know of two problems that 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” (per OCLC Quality Control) 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.
The second remaining issue 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. Please see the Alliance documentation on Alma import profiles for more detailed information about match points.
Background
Software: Alma
Written by: Bob Thomas; Lesley Lowery
Last updated: 4/13/2023
Nature of last update: Removed outdated language, added links to relevant policies.