Page Comparison

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:

1. Items are pulled from HD by Iron Mountain and pw'ed. Pat sends weekly lists to Leila
2. Iron Mountain batches items from weekly pulls into three shipments to Google (Ann Arbor) according to the schedule indicated.
3. Item manifests (lists of barcodes) should be given to LTS in advance of shipments so that LTS can properly process items.
4. LTS will process items as follows:
   1. Run a report to break shipments down by location so that they can be properly mapped to the correct ReCAP destination location
   2. Metadata extracted as per Google spec and sent to Google
   3. Create itemized sets by location and run a process to update sets to permanent RD location
      1. Run a job > change physical items on the set
      2. 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
   4. Place items into transit awaiting post-processing ReCAP accession 
      1. A revised EOD script will be used (see documentation on Divinity.py). Divinity.py was developed for the Divinity transfer project, but can be reused for this purpose. Items will appear to have been put into transit from the DIV_CIRC desk, but this has no effect on the process at all; the goal is simply to put the items in transit from a circulation desk which does not have a reshelving relationship with the items. 
   5. 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.