2018-10-11 Metadata Management Meeting Notes

OAI-PMH: Harry questioned if more information is needed by the group as to what this is and the function it serves in the library world. Other reason for this project is that there is a development team that is ready to work on this. Harry mentioned that our discussion about marking records for deletion is relevant to this topic.

Presentation slides: https://docs.google.com/presentation/d/157JFC_OVN0W69zTqPKhlr13o40Gyh8lPBE8sMsLNDFI/edit#slide=id.g43252da617_2_79

• The service that requests from harvesters is what is being targeted for FOLIO.

Question:
Why is an OAI being considered as opposed to an API when OAI is a more restrictive protocol than API.

Answer:
This service will be making use of FOLIO's APIs, but the OAI-PMH is more compatible for vendors who are already set up to communicate with this protocol. For example, if Primo is your discovery service, Harry doesn't think it is reasonable to expect that they will write an API for a few years, but they are set up to receive calls via OAI-PMH. The long view according to Harry is that APIs will be the future.

ERM

• September presentation of German library networks data flow environment. Participants are invited to share their own dataflows in order to take them into consideration by the ERM sub group.
• UMass Amherst has given a demo of Coral ERM. They recently migrated to Coral.
  
  

MARCCat

• Group spent time today trying to solve and clarify what is expected of the system to appear on a results screen.
• Development can begin when this issue has been solved.

Data Import

• Subgroup has been focusing on the setting screens for Actions, Matching, Mapping.
• Much is happening in development. Tomorrow is the end of the first full sprint. They have finished the overall architecture document. The lead architects will review this.
• The developers are working on the landing page.
• The next area of development will be the file upload.
• There is a meeting with @Cult next week to make sure there is clarity on the interaction. Ann-Marie noted that @Cult already has ISBN normalization code so that is does not have to be built.

Please add to this spreadsheet: https://docs.google.com/spreadsheets/d/1XkHDYCfY5Xl7rpcP_MIg5ZAkQrbBfpsQ4rtNTEWSrdE/edit#gid=0

• Harry added to the spreadsheet.
• Laura asked that members add columns/edit/rename as desired. Homework: If you care about deletion behavior, please look at this spreadsheet and add to it, comment and/or questions are welcome. Dependencies in other apps are of concern.
• Ann-Marie Ideas of "Delete" and "Mark for Delete". New concept of "Hiding" still in db but a user without certain privileges would not see them. This may be useful in this conversation. Use Case: A user wants to load a MARC record, but only for the purposes of supplying information for Inventory. The user would like to not keep the MARC record. Keeping that MARC record may be necessary so a dependency is not broken, but not wanted in the main data source. "Hidden" would be a way to "archive" this component, without it coming into play in daily functions.
• Purge feature - Some systems offer this for records that have no dependencies.