Codex: There is still a format-agnostic FOLIO “codex” record containing the brief instance-level data we need for most searches, results and non-cataloging workflows. We are thinking 20 – 30 fields will suffice.
Details: Instance details, however, will not be stored and edited in a FOLIO detail record but, rather, in the source record itself. FOLIO will contain apps for viewing and editing source record formats (e.g. integrated MARCedit).
Codex Editability:
Codex records that are automatically created by distilling a local source record are uneditable because edits must be done in the native source format
Codex records that are manually created without an associated source record are fully editable
Codex records from external KBs may or may not be editable depending on what is supported by the KB
Benefits of new approach:
No need to specify detailed descriptive record formats for different types of resources (this would be massive project)
Only need to determine the crosswalk/mapping from native source formats into the limited set of Codex fields as opposed to a much larger number of detail record fields (another big savings in terms of analysis effort)
No need to worry about syncing edits between the detail record and its attached source record(s). There is just one source of truth.
Exported MARC records will include all the original record data plus any edits that have been made within FOLIO without the need for complex overlay functionality.
Downsides:
Perpetuates the primacy of MARC to a certain extent. Not entirely, though. Specialized editor apps could be added to the product for any type of source record or descriptive format imaginable. Plus, codex records can be created without an associated source record.
Only the codex metadata would be available for non-cataloging workflows in FOLIO. We think this is okay, as long as we properly define the codex data. Need to work with the SIGs to understand if this will work.
