MARC variable field 009

MARC variable vield 009 is a locally defined field that indicates that the OCLC number and 008 field were automatically inserted into a record that previously lacked them.

The 009 field should be retained unless you make sure that the OCLC number is correct for the record and that the record is the correct record for the material in question.

Background

This project was undertaken in 2000 and 2001 as part of the preparation for the consortium's migration from Geac Libs+ to Sirsi Unicorn, so that the catalog would be as "clean" as possible for the migration, as consortial staff and the project manager from Sirsi were concerned that any malformed catalog records might have been rejected by the load software.

More than 112,000 records in the catalog at that time (around 15-18% of the entire catalog) were non-OCLC records that had been purchased from various vendors (primarily CLSI and AutoGraphics) in the early days of the consortium's efforts to implement an online catalog. These records lacked an OCLC number (many of them instead had a "CLSI" number or an "AutoGraphics" number in the 001 field) and many of them also had an 008 field that contained only the date created and not any other fixed field data.

Because there were too many records involved for catalogers to fix manually, almost all the records themselves were otherwise at least usable as is, and the costs for exporting that many records from WorldCat would be somewhat prohibitive, a set of computer macros were used to identify records that needed fixing, search WorldCat for a match, copy the 001, 003, and 008 fields from the WorldCat record, and paste those fields into the local record, using the OCLC Macro Language with a combination of the OCLC Cataloging MicroEnhancer (CatME) and OCLC Passport for Windows (PfW) software.

Methodology

The macros searched for WorldCat records using any of several strategies, depending on what data was available in the record:

• ISBN
• ISSN & LCCN
• LCCN
• UPC
• Music publisher number
• Author's last name, title, first word of publisher's name, and Date 1/publication date

All searches that included an LCCN were limited to Library of Congress records only on the first pass.

Whenever a search retrieved a single hit, if the title of the WorldCat record exactly matched the title of the local record, the 001, 003, and 008 fields were copied into the local record.

Whenever a search retrieved a single hit with an author or title that were similar but not exact (such as records that had title and subtitle in a single subfield rather than in two subfields), the macros reported the titles of each for a human operator to examine and decide whether the match was close enough or not. This is the only time records with a single hit were seen by a human, and even then, only the titles were seen.

Whenever a search retrieved multiple hits or no hits, it was put aside for manual record selection.

Problems

Because of lax record matching by the vendors when finding MARC records from the consortium's local catalog cards, and because of lax standards locally over the years for when to use an existing record vs. when to create a new record, the OCLC number and fixed field that the macros copied over could have been those of the wrong edition (1st vs. 2nd), the wrong version (1963 version vs. 1989 version, translation by John Smith vs. translation by Jack Jones), or the wrong format (regular print vs. large print or board book, mass market paperback vs. trade hardcover).

Because of those lax local standards dating back even to the original catalog cards, it is also possible that the OCLC number the macros added correctly matched the record, but that the record itself is not actually the correct record for the material on the shelf.

Due to this uncorrectable blind spot in the matching logic, the macros added an 009 field with the data "clsMacroFix" to every record they edited, so that any catalogers who then happened up on these records could know that the OCLC number and fixed field may not be correct.

Current status and local procedures

Thanks to this project, many of these records now contain the correct OCLC number and fixed field. However, the data flaws that existed then still exist today, so there is no way to for a computer program to prove the OCLC number's correctness for any given record. Therefore, the 009 fields still serve their intended purpose and should not be purged en masse.

If you come across a record with an 009 field and have time to verify that the OCLC number is the correct one for that record, and that that record is the correct record for the attached item(s), then feel free to delete the 009 field.

Many of these records also use pre-ISBD punctuation, have minimal description, and lack subject headings and added entries. Those records should be upgraded to current standards, if you have time, though this is not required.

If you do not have time to verify that the OCLC number and record are correct, then please retain the 009 field in the record.