Stanford Tracer Bullets

Annotations for metadata flowchart

A. Order placed

1. Data created (from BIB 9XX) -- For orders placed in vendor databases, the vendor sends order data in the bib record 9XXs, which are used to automatically generate the order record. For other kinds of orders, ACQ staff creates the order record manually in Symphony.
2. Provisional data created (BIB) -- For orders placed in vendor databases, the vendor sends the provisional bib records to be automatically loaded into Symphony. For other kinds of orders, ACQ staff creates provisional bib records in Symphony or imports OCLC copy.
3. Special handling instructions noted (BIB 9XX) -- For example, rush handling on receipt.
4. Data published -- Searchworks indexes and displays the provisional bibliographic data.
5. BIBFRAME transform -- Possible first BIBFRAME transform to allow discovery of on-order items.

B. Records received

1. Data updated (from BIB 9XX) -- N/A
2. Provisional data replaced with full data (BIB) -- Matches on title control number in Symphony; preprocessing required to match on order ID first for Casalini.
3. Tracking initialized with status "ON ORDER" (ITEM) -- Item record is automatically created during the full record load.

C. Items received

1. Tracking updated: "IN PROCESS" (ITEM) -- ACQ receiver wands item to pull up associated bib record, and changes the location to register that the item has arrived at SUL.

D. Manual updates

1. Data updated to match item & local standards (BIB) -- Depending on the state of the metadata, this work may be done by ACQ or CLASS. See the receiving workflow for more detail.
2. Tracking updated (iterative): routing directions and history (BIB 9XX) -- Each time the item changes hands, the 910 field is updated. This is used to track the location of the item, to troubleshoot any issues that arise during processing or later, and to direct where the item should go next.
3. Tracking updated: manual metadata work marked complete (BIB 9XX) -- The cataloging date in the 916 field is updated from "NEVER" to the current date. This registers that manual work on the metadata is done, and that the item will proceed to Binding and Finishing.
4. Tracking updated: shelving location (ITEM) -- This shows that processing is complete and that the item is ready for use.

E. Automatic updates

1. Backstage: data replaced with authorities updated (BIB) -- MARC records in Symphony are overlaid with the updated records returned from Backstage.
2. Nielsen, digital bookplates: additional data inserted (BIB 9XX) -- Nielsen data is inserted as 905, 920, and 986 fields; these are indexed in SearchWorks as the corresponding 5XX fields. For digital bookplates, a 979 field is inserted with a link to the bookplate object in the SDR.
3. Casalini, OCLC: additional data inserted (BIB) -- Casalini TOCs are downloaded as PDFs, and a link to the local file is added as an 856. OCLC master record numbers are inserted as an 079.
4. BIBFRAME transform -- Possible later BIBFRAME transform to minimize the work required to keep both datasets in sync.

F. External updates

1. OCLC: SUL holdings updated -- N/A

This diagram represents metadata only (not file management or other admin tasks) for objects described entirely through the self-deposit tool Hydrus. The boxes under "Self-deposit interface" represent the metadata-related tasks a user can perform through that interface. The leftmost column of boxes are metadata tasks contained within the self-deposit tool. The right column of boxes involves writing data to DOR. Except where otherwise specified, these tasks apply to description of both collections and items. Currently this model is more commonly used for deposits originating from non-SUL users.

This diagram represents metadata only (not file management or other admin tasks) for objects that are accessioned through the self-deposit tool Hydrus by SUL staff and cataloged by the MDU in MARC. The boxes under "Self-deposit interface" represent the metadata-related tasks an internal user performs through that interface in this workflow. Currently this model is commonly used for digital files received by Acquisitions or acquired by curators. The self-deposit tool serves as a convenient way to get a file into the SDR, notify MDU staff that cataloging is needed, and pass information such as the catkey and purl for the object to MDU. New items are deposited to existing collections that have been set up with the appropriate rights, permissions, etc. 

The tracer bullet focuses on the metadata flow rather than the file management portion of this scenario, as the upcoming adoption of Hyku will have a significant impact. For the purposes of the tracer bullet, we are working with digital objects already deposited into the SDR and described via Hydrus. The "depositor" (actually metadata staff) will describe the objects in CEDAR based on the records in SearchWorks, but will reformulate the metadata in CEDAR independently rather than doing a simple mapping from MODS. One possible step is to generate an operational MODS record for SDR use from the RDF description, but for the purposes of the tracer bullet this operational record will not actually be written to the repository.