Skip to end of metadata
Go to start of metadata




Discussion items

 Product Council update

Peter Murray reported. There was a discussion about project governance. Where and how are developments made. How do we coordinate decisions that are made at the SIG level.

 FOLIO Forum updateUpdate: In two weeks July 26 at 11:00 am Eastern is the next FOLIO forum. "User Experience Driven Design Method" is the title of the presentation. Nothing is set for August. In September, they hope to go back to two forums a month.
 Linked Data - MM SIG or its own SIG, or...
  • Lynn suggested that we take this question to the Folio Discuss forum. Peter Murray will begin a thread on the forum.
  • Product Council did not set up a time frame for when they would like a report back concerning Linked Data and BibFrame. Product Council would like to know what we in the Metadata Management SIG think needs to be done.

Per Peter: Linked Data came up at last week's Product Council meeting -- does it need a separate SIG?  Is the topic best handled by the MM SIG or a subset of the MM SIG?  The Product Council attendees thought it best to bring the topic to the MM SIG for their thoughts.

Lynn: let's discuss (briefly) at the meeting & decide how we want to have a conversation around this idea: Mailing list or FOLIO discuss? When does PC want a recommendation from the MM SIG

  • Peter Murray to create a Discuss topic to being the discussion.
 Update: FOLIO Codex Working GroupCodex Working Group meeting notes: 2017-07-07 FOLIO Data Model/Codex Working Group Meeting notes
 Codex Metadata Model discussion

Kathryn Harnish, Leap Forward Library Consulting


  • Kathryn is working in a consulting role surrounding the codex at the moment.
  • Email: kathryn at leapforwardlibraryconslting dot com
  • Slide: What is the codex?
    • Codex is a "thin layer" that will sit on top of the data to help normalize the data.
  • Slide: Assumptions
    • There must be enough data to identify and differentiate one resource from another.
    • Data relevant to only a single functional area does NOT need to be in the codex. Example: Cost information does not need to be displayed in the codex. Circ information does not need to be in the codex data. The codex is about when we're working across repositories.
    • Keep the codex lightweight. We want a set of common denominator fields.
  • Slide: Marching Orders
    • While focus is on print and electronic, but we should keep in mind resources that fit into other categories.
  • Slide: Methodology
    • There is an intention to allow individual libraries to customize the codex.
    • Instance: This essentially the representation of the resource. It is a combination of FRBR's expression and manifestation. Holdings/Item metadata is library specific.
  • Slide: About Instances
    • What triggers the creation of a new instance?
      • Should variant ISBNs trigger new instances? This may not be desirable in the end.
      • The danger is creating too many instances that users will have to sort through.
  • Slide: About Holdings & Item Data:
    • When we start to map up into the codex, Kathryn's recommendation is to flatten or combine holdings/item data. Kathryn is interested in hearing from the group ideas on how to flatten those elements without loosing data.
    • Question: How can the architecture support keeping two structures? Should we even worry about it? Kathryn and Ann-Marie both suggested our group focus on what we want to happen, and let the developers worry about "how."
    • Question: Christie Thomas asked what the implications are of having some info in the codex but other pieces of info not in the codex. How does this concept affect workflows across functional areas. Kathryn: when working in the acquisitions domain, for example, the full record would be accessible at this point. If the resource is coming from a Knowledge Base, then that info would be view-able and accessible at the point of need. The codex comes into play when the user would like to search across or see across several repositories. Vince added that the mindset is "microservices". Each domain has their own representation of a resource. The codex sits above that as a navigator. The user can always go from the codex "summary" to the more detailed information needed.
  • Slide: Conversation on This Approach
    • Vince proposed that use use cases to validate, instead of attempting to supply a full research effort. He mentioned the concept of a "straw man" which he hopes to elaborate on at the end of the meeting.
  • Slide: Sample Use Case - Searching
    • Kathryn noted the absence of "Subject" information on this slide. Subject information is planned to be kept outside of the codex.
  • Slide: Same Use Case - Resource Management
    • Mike asked what is meant by the Commerical Identifier. Kathryn stated that ISBN, ISSN - identifiers used at a trade level. A System Identifier is something that could be kept in an 001 field or an 035 field.
  • Slide: Instance Metadata Elements
    • Contributor - Kathryn is wondering how important that is.
  • Proposed Next Steps
    • Kathryn would like to meet on a regular basis with this group. Over the next few weeks we have to have long conversations to push the end result happen quickly.
    • Lynn suggested that Kathryn create a Discuss topic for each topic that she feels we need a "deep dive" into. Then we could summarize and prepare to discuss.
    • Mike Winkler asked whether we could do a "workshop" approach to give a larger portion of time.
    • Vince agreed that a workshop approach would be useful.

    • Kathryn Harnish will create a Discuss topic for each topic she would like us to explore further as a group.
 The straw-man ApproachVince Bareau

Vince displayed his Codex Metadata spreadsheet. Everything built is intended to work as a service and result in an API. This need for the many information points differentiates this from the way information has been traditionally presented in library systems. Vince would like to walk through this in more detail and to do the same thing for different services. Vince Bareau - will provide this document on the Google Drive, after he's had a chance to adjust it a bit. He will put it in the shared Codex Google Drive. 

Lynn and others asked that the group please utilize the Discuss forum more.

 Question/Comments from Chat 

From Lynn W to Everyone: 12:24 PM
PPT is linked from the MM SIG agenda

From Stacks Team to Everyone: 12:51 PM
Can there be more than one metadata source, assuming these are reconciled?

 From Michael Winkler to Everyone: 12:52 PM
good question, stacks team!

From Lynn W to Everyone: 12:52 PM
Vince - any thoughts on this? agreed that its a good question!

From Jacquie, Dracine, Sarah to Everyone: 12:53 PM
I want to mention that the publication data needs to be drawn from both the 260 and the 264. I realize my audio wasn't coming through very well on Friday.

From Laura Wright to Everyone: 12:54 PM

Re: publication data -- yes, needs to come from 260 and 264, plus for serials may need to come from other fields, since 26x$c is often not present but dates are important

From Jacquie, Dracine, Sarah to Everyone: 12:54 PM
Right, and both those fields are repeatable, so which ones to present in the Codex based on subfield coding, etc.

From Ann-Marie Breaux to Everyone: 12:56 PM
As to whether there can be more than one metadata source, assume yes. The most basic example: a library has a MARC record stored locally for an eBook, or eJournal, plus there is also a representation for that eResource coming from the external KB that they are using. So 2 metadata sources for the same eResource.

From Stacks Team to Everyone: 12:58 PM
though possibly more technical, my follow up to the multiple metadata source question would be: what triggers updates to a metadata record? For example, if a new source is identified, does it trigger updates?

From Jacquie, Dracine, Sarah to Everyone: 12:59 PM
I think that there isn't enough time left in July for a complete analysis of the model by functinal library staff. OK, then it's not a deadline, it's a start date?

From Ann-Marie Breaux to Everyone: 01:04 PM
When you say "metadata record," do you mean metadata in the Codex or metadata in the source? Hopefully updates in source metadata would trigger some sort of automatic upates to the Codex representation of that thing. It seems like more discussion is needed about updating metadata in general - when that source metadata is stored locally, when the source metadata is external and can be updated by users, and when the source metadata is exterbal and cannot be updated by users.

From Stacks Team to Everyone: 01:06 PM
To clarify, the example workflow I have in mind would have the Codex record initially generate based on a metadata record sourced from a KB. Further into the workflow additional, related sources may be identified (e.g.. a record from a vendor that differs from the KB record)

From Ann-Marie Breaux to Everyone: 01:07 PM
For tangible works, don't assume it's coming from a KB, at least in the way that discovery considers KB

Action items