270 likes | 392 Views
OCLC Reclamation Project. Summer 2010 CCC June 3, 2010 rev. 8/05/2010. 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. Cataloging in Orbis.
E N D
OCLC Reclamation Project Summer 2010 CCC June 3, 2010 rev. 8/05/2010
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
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
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
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
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
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
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
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
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
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
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 <TBD> • At intervals, a file of these numbers (the xref file) will be sent to YUL
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 <TBD><Orbis ID #> • 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)
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)
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
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
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 <TBD><Orbis ID>, and the 079 master ID, and deletes any 035s found in the record
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
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)?
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
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
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
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
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
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!
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