This page represents the work of the FOLIO Codex/Data Model Working Group. Separate meetings were started on June 28, 2017. Discussions and activity around the Codex also occurred directly within the Resource Management SIG and the Metadata Management SIG. Search capabilities for Codex have been developed for the FOLIO Aster release. Further work may occur in the future.
Google drive folder for the group: https://drive.google.com/drive/folders/0B7-0x1EqPZQKN21rWVMwX0pDR1E
- Original Data Domain Model (April 2017)
- April Discuss Post on Data Domain Model
- 2017-04-12 MM Minutes
- 2017-04-20 MM Minutes
- 2017-05-12 Minutes (and another version) from Joint RM/MM meeting on Data Domain Model
- 2017-05-26 Minutes from Joint RM/MM meeting on Data Domain Model
- 2017-06-02 RM Minutes
- 2017-06-01 MM Minutes
- 2017-06-16 RM Minutes (discussion with Harry Kaplanian)
- 2017-06-22 MM Minutes
Possible working definition for the FOLIO Codex
As a platform for library-centric apps, FOLIO’s approach to descriptive metadata is to create a high-level subset of metadata elements that all FOLIO apps must understand while retaining the detailed descriptive metadata record for apps that can understand and make use of that detail. For instance, the app that checks in and checks out physical books does not need to understand the precise nature of the MARC 245 indicators and subfields; it just needs a title to display on the screen to confirm to the operator that the item at hand is the item being checked out. Likewise, an app that counts the usage of a particular thesis does not need to understand the metadata elements that distinguishes a thesis advisor from the degree candidate. This subset of metadata is being called the FOLIO Codex.
The concept of a subset of common metadata elements is similar to Dublin Core. At the time of writing, the exact contents of the FOLIO Codex have not been established, but (like Dublin Core) it is anticipated to be somewhere between 20 and 40 elements. The Codex record is most often derived from a source record in a native metadata format such as MARC or MODS or PBCore or FGDC. In creating this subset, apps can operate on library holdings no matter which description format is used. When the native metadata format is changed, the corresponding FOLIO Codex record is regenerated. (The FOLIO Codex concept acknowledges that there can be records for which the Codex metadata format could be the native metadata format.)
A FOLIO Codex record contains a pointer to its source record, and Codex records can come from any number of sources (‘knowledge bases’). A typical library could have a silo of bibliographic records representing the physically held collection, records from one or more commercial content providers (e-serial and e-book platforms), and records from digital object repositories hosted by the library. Options are in development for handling deduplication and merging of records from multiple knowledge bases. Also under discussion is the ability to provide a local “overlay” of information that modifies the knowledge base record as well as functionality that can automatically update the stored copy of the knowledge base record when the source changes.
[From The Intersection of Repositories with the FOLIO Library Services Platform whitepaper.]