Related product I-Share

Safe Bibliographic Record Replacement Routines

Background

From time to time, the bibliographic record in a local I-Share database needs to be replaced with updated content, including the addition of, change to, or removal of the number stored in the bib record’s 035 $a. This field most commonly contains the OCLC control number, but in the Voyager environment, other data can be stored in the 035 $a.

A common workflow scenario is when the bib record used for ordering via Acquisitions proves not to be the desired bibliographic record when the item is in hand at the time of cataloging. Another scenario involves replacing old or short records in the database (e.g., a “MARCette” from our previous consortial database) with current data, including the addition of an OCLC control number.

The following steps illustrate how bib records that, for whatever reason, need to have any changes made to the 035 $a data can be corrected in the local database, and how to also have the change reflected in the I-Share Union Catalog (UC). These steps apply any time the bib gets a new number in the 035 $a, any edits are made to an existing 035 $a, or any 035 $a is deleted. The common workflow of replacing order records will be used as a descriptor in the remainder of this document, but it should be noted that this routine applies any time data in the 035 $a is changed. Please note that these steps also apply when library staff use the functionality to overlay/merge two existing records in the local database, if the “target” record will be getting a new or revised 035 $a (See the “Special Note...” section near the end of this document for more details about the overlay/merge functionality and the safe bib replace routine).

Definitions of Suppression

The key to the Safe Bibliographic Record Replacement Routines is suppression of the bibliographic record. The record needs to be OPAC-suppressed or UC-suppressed before the 035 data are changed so that the existing UC bib and holdings are deleted properly before the updated record is fed into the UC. Because we rely on the 035 $a field as the primary match point in the UC’s duplicate detection algorithm, changes to the 035 $a data can result in bibs (and the library’s holdings linked to those bibs) being discarded from the feed into the UC if the incoming record matches on more than one existing UC bib. For more information about duplicate detection in the I-Share Union Catalog.

NOTE: These steps do not apply to routine updates or replacement of a bib record that do not involve changes to the 035 $a. If the 035 $a data is not changing, just edit or replace the bib as needed; no suppression of the bib is required for the sake of the UC under these circumstances. 

Exactly which routine you must follow depends on whether or not the bibliographic record was originally entered into Voyager as OPAC-suppressed or UC-suppressed, and if the record is suppressed already at the time the replace transaction is to be performed. 

“OPAC-suppressed” means that the Suppress from OPAC box is checked in the System tab of the bibliographic record.

“UC-suppressed” means that the bibliographic record contains a $u nouc in the 049 field following the CARLI “Suppress from UC” option. For more information on the Suppress from UC option.

The bib record’s History tab is useful in determining when a record was marked as suppressed. If the bib was OPAC-Suppressed, the History tab’s final column called “Suppress Action” will contain a value of Y. If the bib is not OPAC-Suppressed, the Suppress Action column will contain a value of N. If the bib has been edited multiple times, there will be multiple entries in the History tab, but the most recent transaction will reveal if the bib is currently OPAC-Suppressed, and if so, the date that the suppression took place (per the first column in the History tab, called “Date/Time”).

Because the Suppress from UC option is a CARLI workaround to Voyager functionality, there is no corresponding entry for this action appearing in the bib’s History tab. If a bib contains an 049 field with a $u nouc, that means it is currently UC-suppresssed; the bib’s History tab will reveal when the bib was last edited, and one can infer that at least by that last transaction date, the bib has been UC- Suppressed.

Workflows

Prior to November 2007, the daily feed of bibs from the local databases into the Union Catalog was accomplished via a single extract of the data performed daily, followed by the daily load of the extracted data beginning at 9 p.m. In an effort to help local cataloging workflows become more efficient with regard to this suppress/replace routine, as of November 13, 2007, CARLI began to do the extracts (only) from the local databases on an hourly basis. The extracts begin at X:45 each hour, and are completed no later than X:59 each hour (where the X refers to the variable hour). The exact minute/second that an extract will take place from any one of the various I-Share databases cannot be predicted precisely, so allowing 15 minutes for all extracts to take place across all I-Share databases is the safest way to offer predictability of the desired outcomes in the UC when a single bib has both a suppress and replace transaction in the same day. The extracted data from throughout the day will continue to be loaded (in chronological order) into the UC only once, beginning at 9 pm.

For example, this means that a bib marked as suppressed using either method at 8:15 a.m. could be replaced beginning at 9:00 a.m. Likewise, a bib marked as suppressed at 2:44 p.m. could be replaced beginning at 3:00 p.m.

However, a bib marked as suppressed at 9:50 a.m. should be replaced no sooner than 11:00 a.m., so that the suppress transaction would be sure to be found in a different hourly extract from the replace transaction.

Yes or No logic for when to replace bib record

The mechanism for determining the time of the suppress transaction is to look at the bib record’s History tab. While a personal office clock may indicate a time of 8:44 a.m., for the purposes of this routine, the time that really matters is that of the CARLI server. If the History tab shows that the bib was suppressed at 8:44 a.m., then it would be safe to replace that bib beginning at 9:00 a.m. But if the bib’s History tab shows the last update as taking place at 8:46 a.m., then the replace would need to wait until 10:00 a.m. to be sure the replace transaction is placed in an extract file that will be loaded after the extract file containing the suppress transaction.

If a library has local workflows or processes that rely on suppressing a bib on Day 1 and replacing the bib the following day (“Day 2”), these can continue unchanged, despite the increased number of extracts from the local databases throughout the day. References in the rest of this document to “Day 1” and “Day 2” have been changed to “Day/Hour 1” and “Day/Hour 2” in an effort to recognize both the original and revised workflow options.

Workflow for Bibs Entered Originally or Currently Marked as OPAC-Suppressed/UC-Suppressed

If you choose to enter bibliographic records as OPAC-suppressed/UC-suppressed at the time of ordering, or if a check of the bib record’s History tab shows the bib’s last transaction is prior to today and the bib is OPAC-Suppressed/UC-Suppressed, then replacement of a wrong record with a correct one is easy:

  1. Identify the correct record and note its OCLC control number

  2. Edit (or add) the 035a field of the incorrect bib to match the correct OCLC number, entering it in the form (OCoLC)ocm12345678 or (OCoLC)ocn123456789 and “Save to Database”.

  3. Import the correct bib to your catalog. Duplicate detection (In the Cataloging Client’s Preferences>General tab, the Bibliographic Import/Replace Profile must be set to “OCLCConditional”) will match the new bib to the wrong bib in your database and offer the Replace option. Choose “Replace”.

  4. The bib will be replaced and saved. Suppression will be lifted due to the replacement of the record. The correct bib and holding will be delivered to the Union Catalog.

Workflow for Bibs NOT Entered or Currently Marked as OPAC-Suppressed/UC-Suppressed

If you choose NOT to enter bibliographic records as OPAC-suppressed/UC-suppressed at the time of ordering, or if the bib is not currently marked as OPAC-suppressed/UC-suppressed, then replacement of a wrong record with a correct one is more complicated because of the relationship between the record in your database and its counterpart in the Union Catalog. The complicating factor is that the bib needs to be suppressed in the local DB so that the corresponding UC bib is deleted before the 035 $a data is changed in the local DB and the corrected record is fed into the UC.

  1. Without making any changes to the bib’s 035 $a data, mark the bib as either OPAC- Suppressed or UC-Suppressed on “Day/Hour 1.” Put the item aside until the next day/hour.

  2. On “Day/Hour 2”, identify the correct record and note its OCLC control number.

  3. Edit (or add) the 035a field of the incorrect bib to match the correct OCLC number, entering it in the form (OCoLC)ocm12345678 or (OCoLC)ocn123456789 and “Save to Database”.

  4. Import the correct bib to your catalog. Duplicate detection (In the Cataloging Client’s Preferences>General tab, the Bibliographic Import/Replace Profile must be set to “OCLCConditional”) will match the new bib to the wrong bib in your database and offer the Replace option. Choose “Replace”.

  5. The bib will be replaced and saved. Suppression will be lifted due to the replacement of the record. The correct bib and holding will be delivered to the Union Catalog.

In the majority of cases, following this routine will produce the desired results in the Union Catalog (as well as your local database). The incorrect bib and your holdings on that bib will be deleted from the UC as a result of the suppression done on “Day/Hour 1.” The corrected bib will be added to the UC (if it is not already present) and your holdings will be attached to the correct bib in the UC as a result of the replace/update transaction done on “Day/Hour 2.”

However, there is one scenario that can result in your holdings not being added to the UC as a result of the replace transaction done on “Day/Hour 2”. Despite following the routine described above, the replace may not produce the desired results if the original UC record had 035a=(MYLIBdb)nnnn (“035a=(MYLIBdb)nnnn” refers to the database code and Voyager bib ID of the record in the local database) and Holding=OtherLib, AND the OCLC number added to your local bib is also present on a different bib in the UC. In this scenario, because of the Holdings from another library, the UC bib is not deleted when you perform the suppress operation. When the edited bib with new OCLC number is sent to the UC, it may match the old bib on the (MYLIBdb)nnnn 035a as well as another existing bib on OCLC number. Multiple matches cause the incoming record to be discarded, resulting in no UC holdings for your library.

If you completed all of the steps above, but the library’s holdings are not represented on the correct bib in the UC, there is an optional alternative that may give the desired results:

  1. Add the correct bib as new in your local database and attach or relink holdings.

  2. Then, if you can (if the bib is not attached to a PO, etc.), delete the incorrect bib from your database. If you cannot delete the bib (because it is attached to a PO, etc.), leave the wrong bib suppressed in your database.

  3. Two days later (after the UC’s overnight update and the subsequent load of UC updates into the VuFind public catalog view of the UC the following day) your library’s holdings in the UC should be linked to the bib added as new to your database.

If all steps described above were followed, but the library’s holdings are still not linked to the desired bib in the UC, library staff can contact the CARLI Office for assistance. When problems such as this are reported to CARLI, staff can usually correct the problem by manually editing/relinking bibs and holdings in the UC database. It should be noted that CARLI does not have the resources to do this sort of manual correction in the UC routinely or pre-emptively. However, if a library reports a specific problem with UC bibs to CARLI staff, they will do what they can to manually rectify the situation, as time allows.

Special Note Regarding Safe Bibliographic Replacement and Voyager Overlay/Merge Functionality

Beginning with Voyager version 7.1, an authorized user can overlay/merge two existing bibliographic records in the local database. See the Voyager Cataloging User’s Guide, section “Changing Records with Bibliographic Overlay/Merge in Cataloging” in Chapter 4, for more details on this functionality.

This functionality involves a “target” record and a “source” record. The target record has the content that will be changed (i.e., the “bad” record), but its Voyager record ID number is retained in the database. The source record (i.e., the “good” record) has the content that remains in the database, but the source record is usually deleted at the end of the merge processing.

In the I-Share environment, if the target record is not already suppressed by either method, and it will receive a new or revised 035 $a in the course of the overlay/merge transaction, the target record is subject to the safe bib replacement routine so that the overlay/merge will be reflected properly in the UC. Library staff performing overlay/merge transactions need to remember to check for the suppression status of the target record, and if needed, suppress the target record in Day/Hour 1, and then complete the overlay/merge transaction in Day/Hour 2.

Getting help

Questions about the content of this document should be sent to the