2017-06-01 Metadata Management Meeting Notes

https://discuss.folio.org/t/metadata-model-deck-from-discussion-with-mm-and-rm-sig/827 - follow up on last week's joint RM/MM meeting 5/26, where Cate presented the revised metadata model for the FOLIO Metadata Concept (outcome of the Dublin meet). Lynn briefly went over some of the highlights in the new model, and mentioned a couple of points the MM need to talk more about at this meeting, and probably circle back to at following meetings.

Lynn pointed out:

• the Codex record will be format-agnostic containing 20-30 fields - this is where the MM SIG can provide input and give some directions on which fields to include, and also do some pre-work on mapping MARC fields to Codex fields, and also other meta data formats
• the Codex records which are derived from Source Records or External KB records will not be editable in the FOLIO Codex. It will be possible to create native records as Folio Codex records, but editing of the source records will happen in e.g. OCLC, or maybe in a FOLIO copy of of the source record.
• the biggest advantages of the revised model is the elimination of the intermediary FOLIO detailed record. Al sorts of complications are avoided by doing so.
• the biggest disadvantage would be: Only one source record can be linked to each Codex record - a one-to-one relationship. Chew Chiat Naun mentioned that we still need to solve how info from different sources can be tied in to the Codex record, e.g. package information, some local information from separate sources. Lynn agreed, and she could also see instances, where the same e-book title appearing in several e-book packages coming from a KB. Dracine said this was one of her concerns too, the collapsing of data around a single work, a single instance.
• right now we are talking about instance level records, but in the metadata model there is a work level above the instance level, and how that is going to influence the display, has not been explored, or discussed yet
• it can be problematic if the purchase order is based on a merge of similar or identical records from different sources based on the vendors metadata.
• future updates of merged instance records needs to be discussed. This underscore the need for determination of what metadata do we need in the Codex record
• administrative metadata in the Codex record - the record history, e.g. what processes brought the record into the system, order record information, who updated the record
• Ann-Marie Breaux could see a duplicate situation, if you order your e-books in one way, and manage the metadata in a KB. All the ERM data, is metadata, e.g. information about payment, and when a title is bought. It feels like you have two versions of everything.

What is the FOLIO Codex metadata? A standard set, a smaller set of metadata pieces that would be primarily for non-cataloguing search and workflow work

• Peter explained that the purpose of the search component is searching in support of workflows; discovery is out of scope
• In terms of searching for discovery, the intention is that FOLIO will pass source records and other metadata from other FOLIO apps to the discovery layer for indexing

Anne L. Highsmith said, we have been talking about item- and holdings records, and since the thinking now is that the source record will be kept as authoritative in the revised model, then what about MARC holdings records? Will they be stored, and editable. All agreed that was a good question, and this is relevant to add to the use case document. Mike Showalter agreed in the need to add use cases for holdings metadata, and for items metadata.

In the deck shown by Cate last week slide 16 and 17 gives an example of the metadata envisioned in different material types of records:

Lynn explained that the work with the use cases will show which elements will be relevant. Hopefully do we not end up with a gigantic list, but a more manageable list of data elements. Lynn told that she have added row #13: Add Electronic Theses & Dissertations to Codex - and ended up with several questions. An open question: do we need to have all records (we own) in the Codex, even if they are not part of the workflow, but only part of the Discovery layer.