Preliminary notes on changes (from Cate Boerema (Deactivated))
- 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.
Notes on discussion (from Kristen Wilson)
- Are source records locally stored?
- Yes
- But can also have referential records from external KBs
- Source records may be edited outside of FOLIO, but also thinking about having an editor within FOLIO
- Can referential workflows be used for MARC records?
- Yes
- But KB has to have an API and bridge module to be FOLIO compliant — deliver data in format specified by Codex
- Questions/concerns about how we will encourage vendors to be compatible with FOLIO
- What is the philosophy of cataloging?
- Is it a local catalog?
- Or a referential catalog?
- Needs to be able to support both
- Goal is to store less and less locally overtime
- Acknowledging this won’t happen over night
- Also important for FOLIO data to communicate with discovery tools and link resolvers
- Concerns about having duplicated records for KB and bib records for e-resource titles
- Use case: you have a local MARC record for an e-book and a referential KB record for the same ebook
- This would produce duplicate records in a search
- Could potentially set up a feature that would allow you to merge records — would need to define merge logic
- Could just merge for search results rather than actually merging records
- Some concerns for discovery — but some discovery layers may do the de-duping on their end
- Also concerns about when you start to bring in acquisitions components – where are these linked?
- And concerns about reporting – reports can't have duplicates
- Instance vs item levels
- Instance would be a particular edition of a work
- Item is the particular copy you hold
- Is instance differentiated between p and e?
- Assuming it isn't
- That means that costs and acq data have to be associated at item level
- Need more use cases to explore complexity
- E vs. p
- Serials vs monographs
- Suggestion to write some use cases to help test this theory
- Important to make sure we can answer common e-eresources questions — what do I have? why do I have it?
- Need to be able to do bulk changes
- How is referential data stored? Is it updated dynamically?
- Data in the Codex for that KB is what’s indexed and searchable
- If we want data to support non-cataloging workflows, it needs to be in the Codex
- App for making changes to MARC record will be separate
- Will there be the ability to have package and other types records based on external KB?
- Yes
- Package is V1, platform may come later
- Not sure if they will have the codex concept yet
- People like the idea of search returning packages and other record types in a single search
- Just need facets to be able to limit to certain types
- How to we move forward with use cases?
- Could come up with use cases and try to fit them into the current model
- See if there are points of failure
- Start with a quick spreadsheet where people can list use cases and analysis
- Mike Showalter will help put together a template and some examples
- Can assume that basic ERM functionality will be supported, so don’t need to focus as much on that
- Plan to meet and review what we have next Friday
- Cate will put slides on Discuss
- Consensus that eliminating the FOLIO detail record is the right decision