|
I-Share | News
Effect of OCLC Number Changes in the I-Share Environment
11/09/06
Revised 1/31/2007
As of November 12, 2006, OCLC implemented some changes to the ISBN numbers in WorldCat, as well as changes to the structure of the OCLC control numbers. This memo concerns the effect of the changes to OCLC control numbers in I-Share Voyager databases.
In their Technical Bulletin 253, OCLC announced that beginning Sunday, November 12, 2006, OCLC would implement changes to the format of the OCLC control number to support a 9-digit number. As part of this change, OCLC also announced that they began to output the OCLC control number in an 035a field in addition to the 001 field.
BACKGROUND INFO ABOUT OCLC NUMBERS IN VOYAGER
When bib records are added to the database via either bulk import (i.e., batch loads) or via the cat client, Voyager functionality has been to concatenate the 001 and 003 fields in the raw MARC record to create an 035a field that is visible in the client, and indexed in the underlying Voyager tables. These are the OCLC control numbers that you should be used to seeing in Voyager bib records, and are in the following format:
035 $a (OCoLC)ocm00456789
035 $a (OCoLC)ocm87654321
The new 9-digit OCLC number will be in the format:
035 $a (OCoLC)ocn123456789
For the sake of this memo, I will call the version of the OCLC numbers shown above the "derived 035" because the "ocm87654321" part of the number comes from the 001 field, and the "(OCoLC)" comes from the 003 field. This Voyager functionality remains the same after 11/12/2006. OCLC stated in TB 253 that the OCLC control number and OCoLC prefix will also continue to be output in the 001/003 fields.
In TB 253, OCLC also announced that starting on 11/12/06, they also began automatically generating an 035 field that will contain the OCLC control number, in the following format:
035 $a (OCoLC)456789
035 $a (OCoLC)87654321
035 $a (OCoLC)123456789
For the sake of this memo, I will call the version of the OCLC number shown above the "second 035" because when imported into Voyager, these numbers would create a second 035 field visible in the cat client and indexed in the underlying Voyager tables. Note that these "second 035" fields do not contain the "ocm" or "ocn" prefix and they do not have leading zeroes when the number is less than 8 digits in length.
In TB 253, OCLC also provided access to a file of test records using the new OCLC number formats. CARLI staff have done tests using these records for both bulk import (batch loads) as well as manually importing the test records using the Voyager cataloging client. The test results have implications for I-Share libraries, and hence this memo.
CARLI staff tests have shown that there are inconsistencies with the 9 digit OCLC numbers in Voyager duplicate detection. These inconsistencies were reported to Endeavor in September (incident #126048) and Endeavor updated the status of this incident to "Fixed in Voyager 6.2.1." (As a reminder, I-Share libraries are currently on Voyager version 6.1.1.). Endeavor has released version 6.2.1, but we do not know at this time when/if this version will be implemented in the I-Share databases.
Also, we don't know for sure when the number of records in WorldCat will reach 100,000,000 and thus require the OCLC control number to be a nine-digit number. OCLC is obviously planning for this occurrence, and so are the systems that receive their bib data.
THE PROBLEM(S)
When the incoming bib has a derived nine-digit OCLC number AND the new second 035, Voyager's normalization routine is somehow dropping the ninth digit during duplicate detection. This means that an incoming bib with a nine-digit 035a in the format (OCoLC)ocn123456789 will match an existing bib with an eight-digit 035a in the format (OCoLC)ocm12345678.
This problem does NOT appear to occur when the incoming bib contains ONLY the derived OCLC number, and not the second 035 that began to be generated by OCLC on 11/12/06.
Technically, this issue regarding the second 035 also affects OCLC numbers of less than 9 digits. Our testing showed there are inconsistencies in how Voyager is indexing the second 035 fields in the underlying Voyager tables, depending on the number of digits in the second 035. CARLI staff believe that these inconsistencies should not have the same potential to cause false matches in duplicate detection when the second 035 is eight digits or less, UNLESS the bib has been edited so that the existing OCLC number is in a format other than (OCoLC)ocmNNNNNNNN. But because some workflows involve staff manually adding/editing the OCLC number, we wanted to bring this possibility to the attention of our tech services community, and use the workarounds below, just to be safe.
THE SOLUTION(S)/WORK-AROUND(S)
Again, the problem with duplicate detection appears to only occur when the incoming bib contains both a derived OCLC number AND the second 035. There are different work-arounds depending on the method of "delivery" of the OCLC records.
BULK IMPORT
CARLI staff have added a step to the pre-processing routine for OCLC bibs added via bulk import to remove the second 035 altogether. We believe this should prevent the false match problem in duplicate detection for all bibs received since 11/12/06 in the "daily EDX file" from OCLC. As a reminder, these are bibs that a library generates via update or produce transactions on OCLC, and that get loaded into Voyager using one of the I-Share "modes." Libraries should not need to do anything different on OCLC starting on 11/12/06 for these types of transactions.
RECORDS EXPORTED FROM OCLC VIA THE CONNEXION CLIENT VERSION 1.60
Connexion client 1.60 does NOT automatically generate the second 035 field. So, there is nothing that libraries using Connexion client 1.60 are required to change to deal with this issue.
That said, libraries using the 1.60 client may want to set their Options to delete the 035 field from exported records, just to be safe. This is done by going to Tools/Options/Export tab and then clicking on the Remove Fields option/Field Export Options. Add field 035 to the Bibliographic Records section of this window. When done, click OK.
It is assumed that when libraries upgrade their Connexion client to version 1.70, that this setting will be carried over after that upgrade. CARLI staff have heard from a few libraries that have already upgraded to version 1.70 that this was true for the majority of workstations, but occasionally the settings had to be manually adjusted in Connexion client 1.70 after the workstation was upgraded.
RECORDS EXPORTED FROM OCLC VIA THE CONNEXION CLIENT VERSION 1.70 (RELEASED: DECEMBER 2006)
Connexion client 1.70 DOES automatically generate the second 035 field. The fix to Voyager was not received/implemented in I-Share by the time Connexion client 1.70 was released. So, when I-Share libraries upgrade to the version 1.70 of the Connexion client, it is very important that the option to delete the 035 field from exported records be applied as soon as possible after the upgrade. This is done by going to Tools/Options/Export tab and then clicking on the Remove Fields option/Field Export Options. Add field 035 to the Bibliographic Records section of this window, if not already present from Connexion client 1.60. When done, click OK.
I-Share library staff will want to either verify that this option (as well as other Connexion client options) carried over after the upgrade to version 1.70, or set it for the first time if this option was not set under version 1.60.
RECORDS EXPORTED FROM OCLC VIA THE CONNEXION BROWSER, AS OF 11/12/2006
The second 035 IS included in records exported from the Connexion browser, as of 11/12/2006. Also on that date, the browser was enhanced to allow users to set the option to delete the 035 field from these records. Libraries using Export from the OCLC Browser need to set this option in the browser using the steps below, to prevent the export of the second 035:
- Log into the OCLC Connexion Browser and navigate to the "General" tab.
- Choose the "Admin" button.
- Choose "Export Options" from the list.
- In the "Fields to Delete on Export" section, add 035 to the "Bibliographic Records" box.
- Click the "Save My Default" button to save this change.
RECORDS COPIED FROM THE UNIVERSAL CATALOG OR ANOTHER I-SHARE DATABASE, AS OF 11/12/2006
CARLI tests show that bibs copied from another I-Share database (including the Universal Catalog) into the local database that contain BOTH the derived 035 as well as the second 035 have the same issues with duplicate detection as described above. In theory, if bibs with the second 035 never make it into the local databases, they should also not migrate into the Universal Catalog. However, since there is the human element involved here, it is possible that some of these second 035 fields could be found in the UC after 11/12/06.
Therefore, staff that copy bibs from the UC should pay attention to the format of the 035 data before the bibs are saved to the local database. CARLI staff will be updating our documentation about steps to take when copying bibs from the UC with this new information, but that task is not yet complete. Please be aware of the second 035 issues and delete them if found in UC bibs before saving those bibs to your local DB.
Of course, staff want to RETAIN derived OCLC numbers in bibs copied from the UC. Again, these "good" OCLC numbers are in the format below, and should not be deleted:
035 $a (OCoLC)ocm00456789
035 $a (OCoLC)ocm87654321
035 $a (OCoLC)ocn123456789
We appreciate your cooperation. Please contact the CARLI Office if you have any additional questions about this matter.
Print
Return
|
View Calendar
Email Lists
