1. OCLC Reclamation Project Summer 2010 CCC June 3, 2010 rev. 8/05/2010 8/5/20101

2. Background Funded by Arcadia grant Institution records currently represented in OCLC: ◦ former RLIN records ◦ non-roman script cataloging performed on OCLC following the RLIN merge 8/5/20102

3. Cataloging in Orbis Cataloging in Orbis not represented in OCLC – No original cataloging of serials currently loaded – Records keyed by OCLC recon ("PK" file) – Manuscript records Missing YUL IRs--all records cataloged in Orbis & exported to OCLC up till reclamation – Original: if a master record (e.g. a vendor record) is in OCLC, only YUS symbol added; master record does not upgrade; no IR generated – Original: if no master record, YUL record becomes master but no IR generated – Copy cataloging: YUS symbol added, but no changes reflected in master record; no IR to record the changes 8/5/20103

4. Maintenance in Orbis Current policy: updates to Orbis records are not re-exported to OCLC because: ◦ Master records not created by Yale cataloging are not updated ◦ IRs would not be updated either because no IR exists or existing IR would not have a link to the re- exported Orbis record ◦ Re-exported archival records generate a new master record As a result, changes not reflected in OCLC include: serial & multipart recataloging, LCSH updates by Cat. Mgt., miscellaneous recataloging 8/5/20104

5. Reclamation: What is/is not Sent All records sent to OCLC except: – 852 with In Process, On Order, UNCAT anywhere in the MFHD ($h, $x, etc.) Records with UNCAT, etc. in one MFHD but also a cataloged MFHD will be sent – 852 with location yulint (licensed or not) – Suppressed records – Unsuppressed records with all MFHDs suppressed – MARCIVE government document records (because of licensing agreement) Volume holdings are not part of the reclamation project 8/5/20105

6. Reclamation: Results All YUL records sent have holdings symbol added to the appropriate master record If no corresponding master record, master record will be created NEW institution record corresponding to every Orbis record included in the reclamation, whether or not a master needs to be made Expect manuscripts to be able to replace master records 8/5/20106

7. Scan and Delete Once the process starts, OCLC will begin by deleting all current YUL institution records YUS symbol already on the master record will remain during the process Following the reclamation, if a master record associated with a YUS symbol did not match on an Orbis record, the YUS symbol will be deleted – Will affect all yulint records created in Orbis that were exported to OCLC 8/5/20107

8. Processing Interval (Gap Period) OCLC has a maximum number of records that YUL can send in a file, so the Orbis records sent for reclamation will be staggered Mudd Gov Doc recon will probably go first Files can be sent daily--file size may be limited, but the processing is rapid Some files will be sent separately for special processing--records for manuscripts & archives 8/5/20108

9. Changes in Workflow During the Gap Primarily affects non-roman script cataloging – Day 1 of the gap period: creation of non-roman IRs should cease (any IRs created in OCLC will be deleted by the scan & delete program) – Maintenance on any IRs created previously should cease (make a note to check when the new IRs are available) – For new cataloging during the gap period, edit an existing master record or create a new master record as appropriate; use the master record as the basis for the download to Orbis 8/5/20109

10. Changes in Workflow During the Gap Acquisitions. – Any acquisition workflow that begins with OCLC rather than Orbis to verify YUL holdings should rely instead on Orbis during the gap period – Records created in error may be deleted Catalog Management. No maintenance in OCLC during the gap period All new cataloging & updates during the gap period will be held in queue for loading into OCLC until the reclamation is completed 8/5/201010

11. Changes in Workflow During the Gap Cataloging in Orbis: "SEND" in exportQ will place the record in the queue file for MARS only; the record will no longer be sent to OCLC--this will be permanent Primary effect on public services: absence of regular loading of new cataloging during the gap period in WorldCat Some features of the public version of WorldCat that depend on the IR will not be available (but IR representation is spotty anyway) ILL does not expect to be affected 8/5/201011

12. Reclamation & Orbis Reclamation will make use of the OCLC algorithms to match each Orbis record with the appropriate master record or create a new master record if one is not found In addition to setting holdings on the master record, the reclamation process will create a corresponding institution record with its own OCLC ID number and with the master record number stored in field 079, and a 035 field with the Orbis ID number preceded by At intervals, a file of these numbers (the xref file) will be sent to YUL 8/5/201012

13. Reclamation & Orbis The YUL program, using the xref file, will use the Orbis ID number match to identify the Orbis record; the Orbis ID number will be loaded as 035 The YUL program will insert the IR number into the record as 035 (OCoLC)ocm/n The YUL program will insert the master record number in 079 Any 035s in the record prior to the update will be deleted (so we won't confuse the master record 035 with the IR 035) 8/5/201013

14. Reclamation & Orbis Records with code p (manuscripts & archives) ◦ master record will be replaced by the Orbis version ◦ Orbis 69x will be converted to 6xx _4 for the master record; 69x tags unconverted on the IR ◦ new IR will be created (all old IRs will be deleted by scan & delete process) 8/5/201014

15. Post-Reclamation Non-roman cataloging resumes creating IR in OCLC Non-roman cataloging resumes maintenance of IR in OCLC Acquisitions searching for non-roman materials begins in OCLC again Catalog management resumes maintenance on OCLC 8/5/201015

16. Post-Reclamation Cataloging staff continue to enter records newly cataloged for Orbis in the queue for MARS using exportQ program Following MARS processing, a file of processed records are sent to YUL for loading back into Orbis [as usual], but in addition a file of the processed records (including records with 880 fields) is sent to OCLC Records restricted by license will be sent to MARS in a separate file and a copy of the file will not go to OCLC 8/5/201016

17. Post-Reclamation Using the MARS file, OCLC applies the same reclamation algorithms to identify matches: – sets holdings symbol on existing master records – creates master record if no match found – creates IR – creates xref file YUL uses the xref file to insert the 035 IR, the 035, and the 079 master ID, and deletes any 035s found in the record 8/5/201017

18. Post-Reclamation On a continual basis, YUL program will send a file of all updated Orbis records with a "history" entry to OCLC ◦ Updated records sent to OCLC will replace the existing IR based on the 035 match; the master record will not be replaced (exception: code p) Non-roman workflow: ◦ IRs with 880 fields updated in OCLC, need to be re- exported back to Orbis (to register as "history")--the re-export/overlay will trigger a re-export of the record back to OCLC as part of the "history" file ◦ IRs with 880 fields updated in Orbis (by Cat. Mgt.) will replace the OCLC IR as part of the "history" file 8/5/201018

19. Some Issues (Standard Phrases) Units that do not routinely enter In Process, On Order, or UNCAT in the MFHD of uncataloged records--should the units begin using the standard phrases to ensure that the cataloging process does not send a steam of updates to OCLC? Will the xref process delete any 035s that have some local use (even though libraries should not be using 035 for this purpose)? 8/5/201019

20. Some Issues (Recat Overlays) Staff re-cataloging in Orbis can potentially break the link between the Orbis record and the IR by overlaying the record with the 035 IR number with a record imported from OCLC or LCDB ◦ Recommendation: use "tile" to first copy the match point 035s and 079 in the target record into the record to be imported 8/5/201020

21. Some Issues (yulint) How to identify and export yulint records created in Orbis into OCLC Recommend: catalog online titles in OCLC and export to Orbis using the non-roman workflow (subsequent slide) ◦ Alternative: create a different location code (yulintx?) for bib records cataloged in Orbis -- same display to the public 8/5/201021

22. Some Issues (880 records) All records with 880 fields--including records copy cataloged by roman script staff--will be sent to OCLC after MARS processing Any maintenance on non-roman IRs in OCLC performed in the period between the original export to MARS and the loading of the MARS processed file into OCLC will be overlaid, but ◦ the "interval update" is reflected in the Orbis record since the IR updated in OCLC during the MARS interval will have been re-exported to Orbis by the cataloger ◦ the re-exported OCLC IR registers in "history" when it overlays the Orbis record, so the updated Orbis record will be re-exported back to OCLC in the regular history file updates 8/5/201022

23. Some Issues (880 continued) Recataloged IRs & Orbis updates ◦ Orbis record with 880s updated by Cat Mgt is exported to OCLC with the rest of the history file ◦ If the updated IR overlays the new Orbis record before the exportQ red flag is turned on, the updated version goes to MARS for processing ◦ If the exportQ red flag is turned on, the updated IR should not be exported to Orbis ◦ If the updated IR overlays the Orbis record after the exportQ red flag is turned off -- wiping out any MARS updates -- the record can be re-exported manually to MARS -- the re-processed record will be sent with the new cataloging file for loading into OCLC, match on the 035/079 of the IR and replace it 8/5/201023

24. Some Issues: Other Libraries' IRs (1) New cataloging in Orbis (does not apply to cataloging in OCLC) ◦ Searching: if an OCLC IR record is downloaded instead of the master record, searcher should delete all OCLC 035s and delete the 079 ◦ Cataloging: for new cataloging only, assume a record with a 079 is another library's IR and  Delete the OCLC 035 (assumption is that it is the other library's IR)  Delete the 079 (to avoid confusion w/non-YUL IR)  Post-exporting, the xref file processing will enter the YUL IR number in 035 and re-enter the master # in 079 8/5/201024

25. Some Issues: Other Libraries' IRs (2) Maintenance -- Apply only to cataloged records ◦ Do not delete the OCLC 035. Assumption is that it is the 035 for the YUL IR ◦ Do not delete the 079. Assumption is that it is the master record ID ◦ Post-reclamation, if the record is updated in Orbis, it is automatically exported; absence of the 035 will probably generate a second IR ◦ If you overlay a cataloged record with a 035/079, be sure to copy the 035/079 from the target record into the imported record before performing the overlay! 8/5/201025

26. Some Issues: Non-Roman IRs New Cataloging: YUL IR is created in OCLC & exported to Orbis ◦ OCLC program generates a 079 for the YUL IR derived from the master record ID number; the 079 is carried over into the Orbis record as part of the import into Orbis ◦ As part of the importing process, Voyager generates a 035 derived from the YUL IR number Maintenance ◦ Maintenance on OCLC will be on the IR  Updated record imported into Orbis--no change in 035 or 079 ◦ Maintenance on Orbis (Catalog Mgt)  Updated Orbis record queued automatically to re-export  Based on 035 match, the re-exported Orbis record will overlay the OCLC IR 8/5/201026

27. Other Issues and Questions? 8/5/201027