STORY: Preservation of MARC | MARC derived record

Continues

The purpose of this card is to develop an API that modifies how MARC derived records are created in order to incorporate data from the raw MARC table from MODLD- 643.

For any given instance, the API will need to merge resource data from the data graph with any corresponding instance data from the raw MARC table in two separate use cases.

1. Inventory

For MARC derived records passed onto FOLIO Inventory, metadata will be arranged by the 3-digit MARC tag and ordered from ‘least’ to ‘greatest’ (e.g. from MARC 001 to MARC 999). The source of the metadata (either from the data graph or the raw MARC table) is not factored into how the MARC derived record is created.

No changes are required for this use case, as the system currently outputs MARC derived records correctly to FOLIO Inventory.

2. MARC Preview

When an API call originates from the front end (e.g. when a cataloger selects the MARC Preview option in the Linked Data Editor), the data from the raw MARC table will be appended to the end of the MARC fields derived from the data graph (e.g. data from the raw MARC table will be added immediately after the 999 field taken from the data graph). Each “sub-section” of the MARC derived record - leading with metadata from the data graph and followed by metadata from the raw MARC table - will be ordered by 3-digit MARC tag, from least to greatest.

The reason for this change is to help the cataloger more easily identify how work performed in the Editor is rendered in the MARC derived record. By definition, metadata coming from the raw MARC table is reserved for elements that have not yet been mapped to the LDE workform. A cataloger is not able to view or edit these elements in the Editor. By appending these metadata elements to the end of the MARC derived record in MARC Preview mode, the cataloger can more easily see the fields that are tied to the Editor workform.