Related product I-Share

Backloading Bibliographic Records from I-Share Voyager Databases to OCLC

This document describes the process for I-Share libraries to backload bibliographic records from their Voyager database to OCLC so that your 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. The document Backloading Data Sync Collection Setup further describes the steps to set up this service for new I-Share libraries. 

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. If an I-Share library is interested in automatically updating its LHR data in OCLC, please contact .


“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 may also be invoked for records imported into Voyager from a file or on records that already exist in your database.

Backloading will not generate any offline products, such as 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 several months for the setup to be completed with OCLC.

For new I-Share participating libraries, the implementation of backloading happens after a library is live on 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 submit backloading data to OCLC on behalf of your library.

Frequency of Routine Backloads

By default, CARLI sets up each I-Share 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 DAILY. If your library wishes to have your data backloaded to OCLC on either a weekly or daily schedule, your library’s I-Share Liaison or designate should file a WRO (using WRO type “Other”) and indicate the desired frequency for backloading. CARLI Systems Services staff will then change the backloading scripts to meet your library’s needs.

All libraries on a monthly backloading schedule have data extracted from Voyager on the 3rd day of the month.  OCLC’s routines have the holdings set in WorldCat a few days or weeks 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. 

Backloading Workflow

Backloading may be invoked for records imported into your local Voyager database from I-Share, from a file, or on records that already exist in your database.


1.  For most I-Share libraries, select the “OK to export” flag on the System tab of the bibliographic record, then “Save to DB”. 

OK to Export setting

The exception to this is the four colleges that share the Illinois Eastern Community College database and the three campuses of Southwestern Illinois College. These libraries must select the “OK to export” flag in the MFHD record to enable backloading of the linked bib record to OCLC.

If OK to export is already set on a record, you can trigger a new backload by selecting “Change to Today”, then “Save to DB”. 

Change to Today button

Setting the “OK to export” flag or “Change to Today” button, then “Save to DB” on a record will set an action date in the underlying Voyager tables.

2. The action date set in step 1 is used by the extract program to select those records to backload since the last extract. Applicable records are extracted to a dataset. 

3. CARLI scripts then FTP your library's bib record dataset to OCLC for processing through your backloading data sync collection.

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.

4. OCLC processes the dataset through your library’s data sync collection. If OCLC numbers are present in the records, they will match on WorldCat records and your holdings will be set. Records lacking OCLC numbers will be sent to unresolved files for your review. 

5. Library staff review cross reference reports.

When your backloading data sync collection processes, at least two people at your institution designated as backloading contacts should receive a report through email with the subject line: Bibliographic Record Processing Summary -- Data Synchronization. (To check or update your institution’s backloading contacts, please email The report will be attached in an Excel file. Within 24 hours of receiving this email, you should have access to your cross-reference reports and possibly a detailed exception file for 90 days in WorldShare Metadata Collection Manager -- My Files – Downloads.

WorldShare Metadata Collection Manager Downloads

The results in My Files - Downloads can be filtered by Reports to help narrow the results.

Reports filter option

Report file names will begin with metacoll.XXX.datasync (where XXX is replaced with your three-character OCLC symbol) followed by your collection ID. Cross-reference report file names end with .xrefrpt.txt and unresolved cross-reference reports end with unresxrefrpt.txt. You may also receive a detailed exception file, bibdetailexcpt.1.mrc.txt, to assist you with any unresolved records.

The files are easily read in Excel or WordPad, but we recommend avoiding basic Notepad since the column structure will be lost. 

Cross-reference reports (.xrefrpt.txt) list your local Voyager bib ids sent to OCLC in the left column, and list the corresponding OCLC numbers that matched in the right column. Your institution’s holdings were added to all of the WorldCat records represented by these OCLC numbers. 

Cross-reference report example

Unresolved cross-reference reports (unresxrefrpt.txt) list those records which did not match on existing WorldCat records and no holdings were added to indexed records in WorldCat. Instead, these records were added to WorldCat Staging and are available for review for 180 days before they are deleted by OCLC’s processing. They can be reviewed in OCLC Connexion using the temporary OCLC numbers assigned in the report. 

Your backloading profile should match only on OCLC numbers. If records are placed in an unresolved file, it is likely they lacked an OCLC control number. Please review any unresolved records since your holdings were not added to the appropriate WorldCat records. Often the best workflow is to search the bib id in your Voyager database to check for any OCLC numbers in the records that should have matched existing WorldCat records.

Unresolved Cross-reference report example
OCLC number in Voyager bibliographic record example

If you receive unresolved records and believe these should have matched existing WorldCat records, please let us know at . We are tracking any issues (listed below) and will report them to OCLC. 

If you plan to update unresolved records in your Voyager database by overlaying or adding OCLC numbers, please follow the safe bibliographic record replacement routine: and suppress the records first, wait the appropriate amount of time, then make the change. This will ensure the changes will correctly be reflected in the I-Share Union Catalog.

Issues reported:

9/19/2017: OCLC 10-digit control numbers are being discarded from data sync matching during backloading. As of 12/22/2017, OCLC continues to work on this issue.

Original Cataloging

Even though all I-Share libraries will be profiled for backloading, libraries must still do their "original" cataloging in 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.

As described in the backloading workflow above, the backloading process sends bibliographic records to OCLC to match WorldCat records based only on OCLC number matching. For those records that match, your library’s holdings are set in WorldCat. No bibliographic records are added to WorldCat during this process. Any records backloaded that lack OCLC numbers would be sent to an unresolved file for your review. 

Because of this, original cataloging must be first created in OCLC in order to ensure the bibliographic record is added to WorldCat and ensure an OCLC number is created. It can then be imported into your Voyager database. 

Getting Help

Please contact the  if you have any questions about the I-Share backloading process.

More information on OCLC's Batchloading processes see OCLC Batch Servies Users Guide

Revised April 2007; July 2012; January 2018