| | - Introducing the Codex Data Model "strawman"
- describe the process for arriving at the proposed model
- review the proposed fields for each of the key objects
- Validation of "strawman"
- examine a number of key use cases (as time permits) to see if the proposed model can be used to satisfy them
- adjust the data model as needed
| VBar | Vince showed reviewed the elements of the Codex Metadata Model for the group. Vince's spreadsheet that will show how to present the data that will be in these objects: instance, item-holding, package, coverage, location, and work. Instance - Creator/Contributor - Do we want to have a single, repeatable creator field, or a single repeatable contributor field instead of a the two different types distinguished.
- Identifier.value - This recommends an array of identifiers, pulled in and treated equally.
- Identifier.type
What is and is not in this Instance sheet - Why is coverage not here? - Coverage is found with the Location Object, which is at the item level.
- Editions are not there. Vince did not consider this a critical piece.
Discussion - Peter wondered how the identifier type and values will be bound. Vince explained that the identifier would be a top level, within the array, they are paired up, so they will related.
- There is no need to distinguish the identifiers further, is the thought behind this.
- Ann-Marie is wondering if we need a qualifier along with the value and type of identifier.
- Peter is wondering if that could be part of the type. Ann-Marie stressed the need to understand what the difference is between multiple ISBNs within one record.
- Jackie at Duke asked about ISSN. The type of OSSNs coming in on records may not be easily identifiable. Jackie brought up the various types of ISSNs: Valid, Invalid — identified by subfields in the record.
- The information necessary to differentiate one resource from another. Examples include maps and musical scores. Vince asked if some of this could be captured in the Physical description field (format on Vince's sheet).
- The question as to the usefulness of "edition" was asked.
- Kristin - If we have a codex with the ability to work with every format type, it will be very complex.
- Aggregate works need to be considered. In the case of a series, the Acquisitions object would be the binding agent.
- Ann-Marie expressed that the codex is representative of the "things" once they are owned, regardless of how they were acquired. (Vince)
(Note - Minute taker had to step out for 10 minutes at this point) - Kathryn thought it would be helpful to look some library tasks and holding it up against Vince's model. There's a workflow component and an underlying data model. Can we focus on a few use cases? This exercise may give us clarity.
- Duke - What if we activate a package from a KB, then ingest MARC records separately into the Folio Codex? Would there be multiple records for the same purchase? Vince said this is a problem to be resolved. Vince felt this would be resolved at the Inventory module.
- Vince emphasized that we're trying to validate a use case against the model.
- Use Case: Would an order as it goes into Inventory then head to Codex be enough?
- Use Case: Series use case.
- Use Case: How would the Codex work if a record is triggered in the KB and then ingested via MARC load?
- Things that we do not hold in a KB will be view-able through the Codex.
- Ann-Marie asked about the data element of Uniform Titles. She feels this is an important element to have in Codex. Vince asked if we could have a canonical title or normalized title. Oliver wondered how close to the codex do they need to live? Can they be harvested for the purposes of relating like works.
- The question is can resources be distinguished once they are on on the screen? The machine's role is to locate these things that can then lead to more detail.
- Laura: What is in the codex vs. what displays in the codex? What is indexed in the codex?
|