Carol Kellett gave a presentation on problems that have come to rise with respect to bulk importation of records.

Problem 1 -- Bulk import of records with embedded order data (EOD)

Some vendors can provide files of MARC records that include embedded order data. Voyager's bulk import program can use the EOD to build purchase orders with line items already linked to the bib records that are imported into the bib database.

Carol reported that Blackwell North America supplies records with EOD. UH Hamilton had been using BNA's EOD service, and UH Hilo wanted to also start receiving records from BNA with embedded order data.

Problems arise when there is already a record for the title in the UH shared database, making the incoming record with EOD data a duplicate record. A standard Add Conditional bulk import profile will bounce the incoming record into a problems file. The bulk import function in Voyager 2000 and Voyager 2001.1 does not support adding imported purchase order data to an existing bib. The embedded data remains in the bounced record and no purchase order is built. For each bounced record, an operator must manually create the purchase order and line item and link it to the existing bib record. (NOTE: The same problem exists for embedded data used to build holdings and items. If the incoming bib is bounced as a duplicate, the holdings and item data is not automatically added either.)

Carol reported that Voyager 2001.2 is supposed to support adding imported mfhd/item/purchase order data to an existing record. She explained that there were two options for handling files of records with EOD in the meantime. One interim solution would be to import BNA records with an Add Unconditional profile, so that no records bounced, but the result would be duplicate bib records that could not be deduplicated due to the linked purchase orders. The other interim solution would be to continue using Add Conditional profiles, and manually add purchase orders and/or mfhds and items when the incoming record that carried the data bounced as a duplicate. Carol reported that, since relatively few titles get bounced, UH Manoa and UH Hilo Acquisitions staff had said that continued use of Add Conditional profiles to prevent the addition of duplicate records would be acceptable to them.

Problem 2 -- Files of records with different classification schemes

Voyager bulk import can only code records for one classification scheme per load. If a file contains records that use different schemes, (e.g. LC classification and Supt. of Gov. Docs. classification), some records will be coded incorrectly. Carol advised that records with different classification schemes be separated into different files. When the files are sent to the Systems office for bulk import, Systems should be told which file uses which classification scheme.

Problem 3 -- Shortcomings in the Add Conditional profile

Carol asked the catalogers to be aware that not all duplicate records are caught during bulk import due to shortcomings in the Add Conditional profile. The shortcomings are the same ones that exist for manually adding a record. The Add Conditional profile looks for exact matches in specified subfields of specified tags, (for example, 020 subfield a). The problem is that all data in the subfield has to be identical in both records for the profile to detect a match. If an incoming and an existing record have the same ISBN, but in one record the 020a only contains the ISBN, while in the other record, 020a contains the ISBN followed by some text such as (hbk.) or (acid-free paper), the Add Conditional profile won't detect a match.

In the shared database, catalogers compensate for shortcomings in the duplicate detection profile by doing several searches for a title before adding a record. Bulk import rules can't be configured to compensate for the same shortcomings, so operators need to continue to be on the lookout for new sets of duplicate records in the shared database.

1. Reproduction notes

   The original guidelines for handling multiple versions of the same bibliographic entity had stated that reproduction notes should go in the holdings 843 tag rather than the bib 533 tag. Hamilton catalogers had asked if the guidelines could be modified so that reproduction notes could go in the bib 533 tag when a reproduction alone is being cataloged. At the January 2002 SCCC meeting, the committee could not come to agreement on the proposed change. The group decided to ask the WebVoyage Committee for input.
   [ NOTE: Minutes of the January discussion are in section V. 4. at http://www.hcc.hawaii.edu/sccc/min/minutes012802_1.html
   Minutes of the original decision can be found in section 3 at http://www.hcc.hawaii.edu/sccc/min/minutes091701_1.html ]

   Michelle reported that the WebVoyage Committee had no opinion on the issue, but that a compromise solution had been proposed by Paul Beck. Under the compromise, when a reproduction alone is being cataloged, the guidelines requiring that the reproduction note go in the holdings 843 still apply. However, the cataloging library can also place the reproduction note in the bib 533, if it wishes. That way, if another library adds an alternate version or the original version, it can delete the 533 without having to contact the first library about moving the data into the holdings 843.

   The proposed compromise solution was approved: When cataloging a reproduction alone, libraries choosing to include a reproduction note should either (a) put that information in the holdings note tag (843) alone or (b) put that information in both the holdings note tag (843) and the bib note tag (533). When a 533 note tag is included, it is with the understanding that the tag may be deleted by another library using the record for a different version of the same bibliographic entity.

2. 007 fixed field data

   The original guidelines for multiple version records had also stated that libraries which choose to include 007 fixed field data must put the data in the holdings record, but have the option of also putting the 007 data in the bibliographic record. If a different version is added by a library that also chooses to include 007 fixed field in the holdings and bib, a format hierarchy, (based on which format limits are most useful to patrons), will be used to determine which format is reflected in the bib-level 007.

   Hamilton catalogers pointed out that in Voyager, there can be more than one bib-level 007. Only the first 007 is used by WebVoyage when a format limit is used. It was proposed that the guidelines be revised to eliminate the requirement that 007 data be put in the holdings record. Michelle Sturges agreed to meet with Sharon Ouchi for further discussion of the proposal.

Hamilton Cataloging asked for clarification on what to do with the 591 notes in another library's brief acquisitions record when using the record for an item in hand. Acquisitions staff present stated that the 591 XXX:ACQREC note does not need to be retained. It was decided that, when using another library's brief acquisitions bib for an item in hand, it is okay to delete the 591 ACQREC note. Since brief acquisitions order records are suppressed from PAC display, the record needs to be unsuppressed. The 591 suppx note can also be deleted, once the record is unsuppressed. If unsuppressing the bib results in another library's order information displaying in WebVoyage, be sure to contact the library so that they can suppress the order information at the holdings level.

Committee members reviewed the draft versions of two documents "Guidelines for Working with Other Libraries' Preliminary and Minimal Bib Records" and "Things to Remember When Adding Periodical Holdings." Several revisions were suggested. Michelle said she would distribute the revised versions via e-mail and give copies to Nadine Leong-Kurio for addition to the SCCC web site.

1. VUGM highlights

   Michelle cited presentations from VUGM that she found especially useful or interesting. Some of the presentations were available for download from the Endeavor SupportWeb site, including Session #89 Cataloging Workflow with Voyager, Session #48 LinkFinder from Concept to Reality, Session #64 Streamlining Acquisitions/Cataloging Workflow, and Session #79 Jumping Out of the Box.

   Michelle reported that she had gone to VUGM hoping to learn as much as possible about various extension products and the way they interact with cataloging. Use of the EnCompass product does not have an impact on cataloging, as the catalog is just one of many databases that EnCompass can be configured to search simultaneously. Use of Citation Server, with or without LinkFinder, does have a significant impact on cataloging, since a unique data element has to be specified in each MARC record to link holdings in the catalog to the article, abstract or citation retrieved via Citation Server. If the data element is accidentally deleted, the link is broken. LinkFinder also complicates use of successive entry serials cataloging, since links have to be included in each record for each title change. Michelle observed that, when the WebVoyage Committee decides to expand use of Citation Server beyond the Hawaii Pacific Journal Index, it will have to work closely with SCCC from the outset to make sure all links are in place and protected from loss via editing, merge operations or deduplication activities. Two libraries have created products that allow an operator to log into the live or test database without having to touch the voyager.ini file. One product, from the University System of Georgia, is available at SupportWeb. The other product, from a library in Australia, is supposed to be posted to the list PACVUG-l.

   Michelle also reviewed changes in Voyager 2001.1 likely to affect cataloging.

2. When to delete and when to keep 650 tags with 2nd indicator 4

   Michelle reminded catalogers that rules for the handling of 650 tags with second indicator 4 differ, depending on whether they are present in a record being added or a record already in the database. Libraries are strongly encouraged to delete 650 4 tags from records they are adding to the database, since they are local headings from a non-UH library.

   However, some UH libraries use 650 4 tags for local headings. Libraries therefore should use the following guidelines when they find 650 4 tags in records that are already in the UH database:

   • If you encounter a record in the UH shared database where there are identical 650 tags, one with 2nd indicator 4 and one with 2nd indicator 0, the 650 tag with 2nd indicator 4 can be deleted.

   • If you encounter a 650 tag with 2nd indicator 4 in the UH Shared database, and it is an exact match for an LCSH, you can change the indicator from 4 to 0.

   • If you encounter a 650 tag with 2nd idicator 4 in the UH Shared database, and it does not match an LCSH, it should be left alone.

3. Display of donor notes

   SCCC decided that, should the WebVoyage Committee approve the display of donor notes, the 541 tag would become the tag for donor information that displays, and the locally-defined 971 tag would remain the tag for donor information that does not display. (NOTE: In June the WebVoyage Committee decided not to approve display of donor notes.)

4. Proposed schedule for upgrading to Voyager 2001.1

   SCCC reviewed the Systems Office proposal for upgrading databases to Voyager 2001.1. Prior to version 2001, all databases on a server had to be upgraded at the same time, but with version 2001, databases can be upgraded separately. The Committee approved the proposed timeline, which scheduled the UH test database for upgrade on 7/8/2002 and the UH live database for upgrade on 7/22/2002.