Backloading Bibliographic Records from I-Share Voyager Databases to OCLC

(revised April 2007)

This document describes the setup and workflow needed for I-Share libraries to backload bibliographic records from their Voyager database to OCLC so that the library’s OCLC institution symbol is set on the master record in WorldCat. This type of backloading project has been in use by ILCSO/I-Share libraries since 2003.

This document intentionally does not address the setup and workflow needed to backload to OCLC specific serials holdings data from Voyager MFHDs, in order to update a library’s LHR record (a.k.a., LDR, a.k.a. SILO records) in OCLC. That is a separate project, and the specifications for the LHR backloading project are still being negotiated with OCLC.

Overview

“Backloading” is a term used to describe an option that many I-Share libraries have elected to use so that their copy cataloging workflow can begin in the Voyager database rather than beginning in OCLC. Bibliographic records marked for backloading in the local Voyager database are extracted and submitted to OCLC so that the library's OCLC institution symbol is attached to the bib record in WorldCat. Libraries that have adopted this workflow in Voyager usually copy a bib record from the I-Share Universal Catalog into their local database, and mark the bib record so that it will be backloaded to OCLC.

Backloading will not generate any offline products, such as shelflist catalog cards or spine labels, so there are some limitations to including backloading in a library's workflow. It is the local library's decision whether or not to adopt backloading into their workflow. With the implementation of Group Services Pricing in Illinois in July 2004, there is no longer a per-record charge for backloading.

All I-Share libraries are profiled for backloading with OCLC, whether their current workflow relies on backloading or not. The idea is to have everything in place so if a library wants to adopt a workflow that uses backloading, the library can do so at any time and not have to wait for the paperwork to be completed with OCLC.

For new I-Share participating library projects, the implementation of backloading happens after a library is live on Voyager. In the past, the implementation steps for new libraries have been completed in an August-October timeframe after the initial conversion to Voyager. Libraries can begin using the workflow for backloading as soon as they are live on Voyager for cataloging. However, it can take a few months for all of the steps in the process to be completed, so that CARLI is able to routinely submit backloading data to OCLC on behalf of the library.

OCLC requires a profile for each backloading project. Part of the process in creating these profiles involves the submission of evaluation data for each library. Because the underlying Voyager bib data is the same for all I-Share libraries, the CARLI Office works directly with OCLC to create an OCLC "Batchload Project Definition" (i.e., a backloading profile document) for each I-Share library, including the extraction and FTP of the evaluation data and the approval of the paperwork for each project. Once we receive these profile documents from OCLC, CARLI staff will review and approve them as quickly as possible. After CARLI has approved all of the Batchload Project Definitions on behalf of I-Share libraries, we will send a copy of the profile document to the library's Technical Services contact, for your local records.

The CARLI Office also pays OCLC for the data evaluation fee on behalf of each I-Share library. OCLC is discounting their usual evaluation fee, and charging CARLI $100 per institution for this task.

Once the Batchload Project Definitions are approved, OCLC creates a customized project "setup" that automates the project on their end. Once that setup is completed, the evaluation data will be loaded into WorldCat, and CARLI can automate the process on our end to begin submitting additional backloading data for the library on a routine basis.

Frequency of Routine Backloads

One of the few "customizable" parts of the Batchload Project Definition is the frequency of backload data submissions to OCLC. By default, CARLI will set up each library's backloading profile to support MONTHLY data submissions. There are two other options for the frequency of extracting and backloading data to OCLC: WEEKLY and (as of March 30, 2007, for libraries participating in the WorldCat Local project ONLY) DAILY. If a library wishes to have their data backloaded to OCLC on either a weekly or daily schedule, the library’s I-Share Liaison should file a WRO (using WRO type “Other”) and indicate the desired frequency, to have CARLI Data Services staff change the backloading scripts to meet the library’s needs.

All libraries on a monthly backloading schedule have the data extracted from Voyager on the 3rd day of the month. There is a limit of 19 data files that can be FTPd to OCLC in a single day, so an individual library’s data may not be submitted to OCLC for up to a week after it is extracted. OCLC’s routines have the holdings set in WorldCat within a few days after they receive the file from CARLI. Therefore, an individual library on the monthly backload schedule may not see their holdings set in OCLC until the middle of the month.

For libraries that choose to have their bibs backloaded to OCLC on a weekly schedule, the data is extracted in the early morning on Thursdays and submitted to OCLC the same day, if possible (given the limit of 19 data files per day that can be sent to OCLC).

OCLC has told CARLI that it is possible (and easy) to change a library's backload frequency from what is originally profiled. So, if your library is OK with a monthly backload schedule for now, but at some point in the future you want to submit backload data on a weekly or daily schedule, this can be accommodated.

Backloading Workflow

There are several possible variations on this theme, but in general backloading is invoked when a bibliographic record is imported into the local Voyager database from the I-Share Universal Catalog. If the library wishes for the bib record to be backloaded to OCLC (so that the library's institution code is set for the bib in WorldCat), then library staff must check the "OK to export" flag in the System tab of the bibliographic record.

NOTE: The exception to this is for the four colleges that share the IEC database. The IEC libraries must check the “OK to export” flag in the MFHD record to enable backloading of the linked bib record to OCLC. Everything else in this document applies as described to the IEC colleges, except that IEC staff mark the MFHD’s OK to export flag rather than setting this value in the bib record.

Setting the OK to export flag in the bib record also sets an action date in the underlying Voyager tables. This action date is used in the extract program to select records for backloading. The extract scripts look for records in the local Voyager database that had the OK to export flag set since the last run of the extract program. Applicable records based on this action date are extracted to a dataset. CARLI scripts then FTP the library's bib record dataset to OCLC for processing.

For example, Library A is profiled for monthly backloads. Staff at Library A mark bib record 10000 as OK to export on March 18. The routine backloading script for Library A will look for all bib records having the OK to export option set between March 3 and April 2 (because the monthly extracts are done on the third day of each month). Therefore, bib record 10000 will be included in the backloaded data for Library A that is extracted from Voyager on April 3.

If your library has not used a backloading workflow previously but wishes to start backloading records to OCLC, all the library needs to do is to start setting the OK to export flag in the appropriate bib records. Once the library has a backloading profile established with OCLC and has been included in the CARLI scripts for this process, then any bib records marked as OK to export will be automatically extracted and submitted to OCLC on your behalf.

It is acceptable if your library chooses to never use the backloading workflow. This is a local library decision.

Original Cataloging

Even though all I-Share libraries will be profiled for backloading, libraries must still do their "original" cataloging on OCLC rather than in Voyager. Original cataloging in this context means full cataloging based on having the piece in hand for which an OCLC number is required.

OCLC's standard backload processing involves sending any "unresolved" backloaded records to a file that the library accesses via OCLC's PSWeb (Product Services Web). Unresolved records refer to an incoming backloaded record without an OCLC number that did not match an existing record in WorldCat based on OCLC's extended matching algorithm. Original cataloging would more than likely end up being an "unresolved" record in this context.

Libraries will need to retrieve the file of unresolved records from PS Web and then manually add them to WorldCat. Because of this workflow, libraries are strongly encouraged to do their original cataloging on OCLC rather than in Voyager.