Remote work project ideas for Technical Services

The OCLC online save files for all outgoing symbols, but especially for HLS, need to be cleaned up before the symbols are deleted (as part of the OCLC Data Sync Project).  Staff (or units) should review their own records in its online save files (including those saved there by vendors on behalf of the unit), delete any records that are not needed anymore, and save records they need in a local save file. Staff who use online constant data should review and document it if they want to re-create them in the new symbol.  And any records that are currently worked on and need to remain in the online save file must have the cataloger’s name in “my status”.

Managing online save files in OCLC Connexion

Alma to OCLC Symbol Mapping

OCLC Reclamation - collection analysis, clean-up and enhancement (Status by Library)

• Suppressed holdings with active items:  103,609 / 266,599
• These migrated this way from Aleph. It's not clear whether the library has these holdings/items

For offsite materials, can send lists to HD to see whether it's on shelf

I claim items I purchased, as I will know their disposition. -Gwen Speeth (see note)

T.Moody - claims all Baker Library items

Outstanding items still at a status of Technical Migration need to be reviewed and handled appropriately. Aleph item processing statuses are in Item Note 3 for reference. The largest subcategory are the Ordered-Received items from Aleph that are still at Alma status Technical Migration.

Link to export of all items with process status Technical-Migration. Please download and slide/dice as needed for your unit.

Remember: many of these data elements are searchable in Alma as well (Process Status, Item Note 3, etc.)

Those working on these items should contact last known person to interact with them.

Item Process Type: Technical Migration - Analysis/Cleanup

• Migrated POLs in review (most lacked attached item records in Aleph)
• Migrated POs in review (these may mostly be one to one correspondents to the migrated POLs in review

for reproductions - these are records where the Type value is inconsistent with the holdings fields indicating the work is a reproduction. Corrections in Alma and in WorldCat (if appropriate)

for manuscripts - correcting Type d, f, t for works that are actually a print facsimile, or material other than manuscript. Corrections in Alma and in WorldCat (if appropriate) 

reviewing and correcting errors that can’t be resolved in batch, such as Sparse records. Prioritize Critical and Severe errors, but could also handle errors characterized as minor for Data Sync that impede access in other ways --such as invalid 041 fields.

Reviewing report output and using the information to identify records for batch cleanup (based on Berenson clean-up)

Reports of records in Microform collections that lack 843 and/or 007 fields

Reports of records in NET collections or otherwise identified as a digital surrogate that   lack 843 and/or 007 fields

Reports of Type j, m, g bibs where holding is coded as a reproduction

Reports of records coded as reproduction that have multiple holdings formats

OCLC Data Sync: records with non-English language of cataloging

These should have the 035 and 040 removed from them so they link to the correct record in WorldCat

Can be done via batch as part of OCLC Data Sync.

Some units may wish to review the records themselves and update the catlaoging. These can be searched in Alma through the index "Brief Level" containing keywords 02 Non-English cataloging

• Prior to the implementation of MARC 5XX holding notes, important special collections information about binding, provenance etc. was added to the 852 |z, a generic public display note. This problem is that this info should be searchable but because it’s in 852 |z it isn’t searchable. 
• Special collections info from 852 |z should be moved to holdings 5XX notes so that 1) they are indexed 2) they display better to the user. There are too many of these to do manually. 
• For 852 $z that contained "Consult circ desk," several hundred thousands of these have been removed, but not where the note also included volume information. These should be cleaned-up manually, checking that the volume info is in the item enum/chron field.

• 9/15/20 - for items at Process Type Missing, CB changed policy to blank
• Same for Lost

• Handling backlog of reports
• Expanding the scope to include reports that had previously been deemed beyond our capacity

Some are being handled by ITS MC

Berenson staff will correct codes for any records for which BER has a holding – Paris

Case 1: incorrect field: 041 should be 043
Case 2: inappropriate punctuation, e.g., ""(swe)""
Case 3: extraneous numbers, e.g., ""1 engrus""
Case 4: extraneous internal spaces, e.g., ""f in""
Case 5: word instead of code, e.g., ""thai""
Case 6: intended subfield code in value, e.g., ""h ben"" or "" ǂa""

Whatever appears in an 041 subfield will be broken up into three-character chunks during conversion to MODS, e.g., ""thai"" becomes <mods:languageTerm authority=""iso639-2b"" type=""code"">tha and <mods:languageTerm authority=""iso639-2b"" type=""code"">i"

008/06 "c" meant "actual date and copyright date" for non-serials prior to 1995. "c" was redefined during format merging to "serial item currently published". Old “c” values were not systematically converted to “t”, so what is actually a copyright date now looks like a bad serial date. Dates in 008/07-10 and 008/11-14 are being misinterpreted for older records with the obsolete Type of Date coding.

E.g., notice start date and end date below:
<mods:dateIssued>[1929?], c1922</mods:dateIssued>
<mods:dateIssued encoding=""marc"" point=""start"">1929</mods:dateIssued>
<mods:dateIssued encoding=""marc"" point=""end"">1922</mods:dateIssued>

Possible fix: Look for records where (LDR/07 NE “c” and NE “i”) AND 008/06=”c”, change 008/06 to “t”.