Summary:
HL is sending 25,000 items in three shipments to Google for scanning (Phase 1: two shipments in November and one in December). Iron Mountain is managing the pulling and shipping of materials from the Harvard Depository to Google Ann Arbor. At the time of HD pull, items are permanently withdrawn from HD.
The deaccession of items from HD and the shipment to Google do not coincide. Items are deaccessioned weekly from HD by IM and then batched together into larger shipments. Google requires item metadata in advance of the items' arrival for scanning. Items will subsequently be shipped to ReCAP for accession and final storage following the Google processing.
In January 2019 (continuing through March 2019), an additional 25,000 items will be pulled and withdraw from HD for the project (Phase II).
Project Workflows:
Phase I: Target is to pull and transfer 25,000 items in three shipments to Google.
Delivery 1 - November 12
Delivery 2 - December 3
Delivery 3 - December 21 TBD
Phase II: Second pull and transfer of 25,000 items in three shipments to Google.
Dates TBD
Procedure:
- Items are pulled from HD by Iron Mountain and pw'ed.
- Pat puts these files into a directory "off root" on sherlock. All of us should have access by entering cd /google in the home directory. Pat says he has been sending files with barcode only, but the files he copied into /google all contain bookcart number as well. I cat'd the files together and edited into barcode only. That file is: HD_bookcarts_combined_200_242_barcodeonly.txt and it contains 12,430 barcodes. I will use the file as input to an itemized set, and to an analytics and send files of metadata today (11/30)..
- Iron Mountain batches items from weekly pulls into three shipments to Google (Ann Arbor) according to the schedule indicated.
- Item manifests (lists of barcodes) should be given to LTS in advance of shipments so that LTS can properly process items.
- LTS will process items as follows:
- Run a report to break shipments down by location so that they can be properly mapped to the correct ReCAP destination location
- Metadata extracted as per Google spec and sent to Google
- Copy list of barcodes and paste into the Barcode prompt for the report on the Alma Analytics menu called RES-Physical items details with core holdings, bib data - Flexible. Compare the number of items input to the number of rows in the report to see that they match.
- Post the report to this page (See below)
- Create an Excel file for barcodes only. Use file to create an itemized set in Alma. See Google metadata - bookcarts 200-242 for an example.
- Open publishing profile called: Google@item level. Publishing profiles are under Resources menu in Alma.
- Select Edit on the profile. Update the parameter for Set name with the name of the itemized set. Update File name prefix with a name like: harvard_bookcart_200-242. Save profile.
- Select Run on the profile to run the export. Output files go kant /dropbox/alma/alma/google
- Copy the files to your local machine and then upload to shared Google Drive. Google automatically ingests files. No notification needed. Contact bbunnell@google.com for access (or Allison might be able to sent a sharing invitation).
- Google contact for metadata is Kurt Groetsch kgroetsch@google.com
- Create itemized sets by location and run a process to update sets to permanent RD location
- Run a job > change physical items on the set
- Change type: Permanent; New library: same as current owning library (no library ownership change); New location: mapped to corresponding RD collection for new/updated holdings
- Place items into transit awaiting post-processing ReCAP accession
- A revised EOD script will be used (see documentation on /wiki/spaces/LibraryTechServices/pages/59098446). Items will appear to have been put into transit from the owning library's main circ desk (i.e., WID_CIRC); the goal is simply to put the items in transit from a circulation desk which does not have a reshelving relationship with the items.
- Regular End of day process/file from ReCAP returns items to "on-shelf" status (removing Transit status). Any waiting request would be sent to RD to pull in next transfer.