2017-06-16 Meeting notes

• What are the next steps for the Codex and data model?

Harry presented wireframes developed by Cate representing how the data in the codex is laid out. To recap, the codex is format neutral (it should be able to handle MARC, Dublin Core, etc.). It is an abstraction/simplification of the data that can be edited as it's stored locally. An example of how this works - if a MARC record is loaded into the system, the system tries to match it up with a codex record. If there is no match, a codex record is created from scratch. If you are not starting from a MARC (or other imported record), you should be able to create a codex record. Codex records can have a relationship with both the MARC (or other format) record and a knowledgebase record.

The current plan is that when searching, all options including items with no holdings will be displayed. Ideally, library staff will be able to make a purchase from a vendor, such as YBP, and the resource will automatically be activated in the discovery layer.

• Question: Should holdings be merged with non-holding records? Merge based on ISBN, OCLC#, or ISSN.
  It's better to err on the side of more duplicates than less duplicates so we don't end up with records getting merged that shouldn't be merged.

Records from external knowledgebases will be pulled in using an API.

• Question: What are the chances of other commercial companies opening their knowledgebases up?
  It's hard to have discussions without a system in place. EBSCO has been in preliminary talks with OCLC. They are willing to plug in their knowledgebase. There is no time frame and OCLC, and most other companies, are waiting to see how FOLIO progresses before committing.

FOLIO needs to be able to plug into other kbs such as Gracenote for music records.

• Comment: If EBSCO opens up their kb but forces people to use their link resolver, for example, this will be a barrier to entry.

Other questions/comments:

• Question: Do we want to see items where we don't have holdings?
  It would be good to have both options - limit to holdings or see all.
• Question: Are platforms needed? Is this a filter or location?
  Platforms are important because a platform may have metadata, such as admin credentials or contacts, that only applies to that platform and not all of a publisher's resources. A platform may have several packages so it would be higher up on the hierarchy.
• Comment: It's important that when pulling records from an external kb that there is a way for data from aggregators to automatically be updated when titles move in and out because it's not feasible to keep up with this otherwise.
• Question: Are there records in the system that are not for a specific resource, something that will not display to the public?
  Yes, for example platform fees or consortial fees, etc.
• Question: Is fund management a separate task, should it be in a separate place from resource management?
  We need access but it doesn't necessarily have to be in resource management - it could be elsewhere.