OCLC Worldshare Collection Manager Maintenance

Overview

The OCLC Worldshare Collection Manager (WCM or WMS), is knowledge base provided with our access to OCLC. Unlike our other knowledge bases (such as SerialsSolutions or EDS), selection of titles in the knowledge base has no impact on display of our holdings in our local discovery layers. Selection can have an impact for display in Worldcat which can impact Interlibrary Loan. However, at time of writing, the display impact is a secondary concern. The primary benefit of WMS is that it maintains collections of titles and OCLC records for our various subscriptions. By maintaining the collections as described here, we can receive OCLC record delivery whenever the titles are added, updated, or deleted. The process isn't perfect - and the collection delivery still requires considerable effort and validation.

These procedures will guide you through the basics of regular maintenance and management of our collection delivery. They are not a comprehensive guide on usage of the OCLC WMS environment. For help with using the OCLC WMS system beyond what is instructed here, you should either check with the author of these procedures, your supervisor, or by checking for external documentation.

Additional information about OCLC WMS can be found on their website and through the OCLC WMS listserves (OCLC-Cataloging <OCLC-CAT@OCLC.ORG> and OCLC Forum, community@oclc.org).

Information on how to create an account can be found here.

Collections

Collections were initially selected through a combination of efforts by Interlibrary Loan in 2014/2015 and then by comparing our SerialsSolutions holding. WMS will update our holdings by our selections of titles in OCLC Connexion as well. Since our main use for WMS is for collection delivery, we tend to be concerned with specific collections. These collections have been selected (on finding and selecting) and MARC record delivery (on record delivery) has been enabled in separate files. We try to prefer customizable record sets but they aren't always available. We generally set the collections to be delivered once per week and then check for new deliveries on Mondays.

You should change the collection configurations with consultation from the supervising librarian. Several of the collections initially selected have been turned back off due to redundancy or ineffectiveness. However, they're mostly updated as they come up so it is very possible a change is likely.

Ongoing Maintenance

Each Monday, or the first available day of the week, the person responsible for the ongoing maintenance of the delivered files should check for updated files and then process them. The rest of these procedures provide guidance on how to do that while FAU Libraries are still using this system, Genload, and Aleph.

Record Retrieval

See these procedures for the actual retrieval of records:

http://www.oclc.org/support/services/collection-manager/documentation/service-specific-settings/MARC-settings/record-retrieval-ftp.en.html

Each collection can generate 3 types of files depending on the nature of the updates for the sets. These are:

• 1. New (eg: metacoll.FGM.new.W20160916.T173251.ScienceDirectAllEbooks.1.mrc)

  2. Updates (eg: metacoll.FGM.updates.W20160916.T173251.SageKBAllTitles.1.mrc)

  3. Deletes (eg: metacoll.FGM.deletes.M20160827.T115024.JSTORArtsSciencesXIII.1.mrc)

The new and updates are treated largely the same. The deletes are handled slightly differently - covered later. For the sets, please download all three types.

On the records page, you'll find more records than those we're actually concerned with.

• • Unnamed records (eg. metacoll.FGM.updates.W20160916.T173251.1.mrc) do not need to be downloaded or evaluated. These are generally the catch-all records beyond the targeted collections

  • Level3Encoding records are maintained through slightly different procedures and do not need to be downloaded or evaluated in this process (eg. metacoll.FGM.updates.W20160916.T173251.Level3Encoding.1.mrc)

  • ClinicalKey records are maintained elsewhere - this collection has been turned off for MARC record delivery so you shouldn't see these

Evaluating "New" and "Updates" Files

For a given "new" or "update" file the procedure is the same, as follows:

• 1. Prepare your genload profile. You should be using the "fau-oclcmatch-eres" profile (Z:\GenLoad_Profiles\fau-oclcmatch-eres.pro). The profile should have "Don't Load for HOL for BIB Match/Replace" options and for "ITEM."

• 1. Load the file into Genload and ensure that "Report" is check. Process and send the records. No files will load. However, it will generate a log with useful information about new records, merges, and multiple duplicates.

  2. Evaluate the Genload log file. Records that merge and where the HOL is skipped (due to an existing holding record) require no further evaluation. Items not being added is of interest but it is not required in this process that they be added. When the logs are very short, the assessment of the log is fairly easy. However, if the logs are very long (and can be over 100 titles), you can use the "Large_Genload_File_Analysis.xlsx" to identify which records require further review. The spreadsheet is fairly simple to use - just be sure not to overwrite the formulas when you save it. (file:///Z:\GenLoad\OCLC_WMS_Maintenance\Large_Genload_File_Analysis.xlsx)

  3. Evaluation of the results will largely follow this flow chart (also available here: https://www.lucidchart.com/invitations/accept/7862879a-1263-4973-aa06-22e5b61172bf):

• 1. Multiple Duplicates will be addressed elsewhere

Resolving Multiple Duplicates

A multiple duplicate is when the system number of the record to be loaded (usually the 003/001 combination) matches multiple MARC 035 fields already in Aleph. For example if OCLC record #894270585 has both Aleph bib 033327138 and 030781835 with MARC 035 value of (OCoLC)894270585 then Genload will through a Multiple duplicates found error.

eg: 9/22/2016 10:41:32 AM Record 1 skipped - Multiple duplicates found... 033327138 030781835

When the Genload log identifies a multiple duplicate, you must assess whether we have holdings on one of duplicates and if we can combine the records. We can combine the records if the other record is really an equivalent record (i.e. not a vendor record with an OCLC number or some other complicating factor - this is somewhat of a judgement call) and we're the only school with holdings on the other record. If we're not the only school with holdings, then we won't be able to eliminate the multiple duplicate.

If we cannot resolve the multiple duplicate, we should send the duplicates to Melissa Stinson at FLVC in accordance with the Shared Bib Guidelines.

If you can't resolve the multiple duplicates, you'll have to manually add our holdings and URL to one of the records.

Delete Files

The hope with delete files is that we don't find matches. The flowchart is altered because a non-match doesn't mean we don't have the title. So instead, we have to determine if the title has been removed from the collection or else if the OCLC number has simple been changes (in which case, there might be a corresponding "New" record for the same title). To check this, you'll need to the use the collection page in OCLC WMS. See if the title is still there. Then see if the OCLC number matches what they sent us in the delete file - it most likely won't since it has been deleted (but may have already been added back in). Check Aleph for the new OCLC number or for the title. If the title is completely removed from the collection, check by title to see if we have a record for it in Aleph. If so, check access. If there is no access, check for alternative access on the A-Z list (if a journal). If no access is available, you'll need to check for perpetual access. This will vary by the collection. We shouldn't lose access for some collections. Check with the supervising librarian or else with acquisitions and collection management/eResources. Once no perpetual access has been confirmed, you'll withdraw the title or at least delete the record.