2020-12-17 Metadata Management Meeting notes

Thank you to all who contributed to last week's discussion and to the Google doc gathering requirements.

This week we are summarizing and synthesizing the requirements into recommendations with priorities.

As with last week's document, please feel free to comment or to edit the document/sheet directly.

Some specifics to address:

SRS + quickMARC – expanding beyond bibliographic data? (holdings, authorities?) adding create function (for bib, holdings)?

OCLC integration – expanding development so we can pull from save files?

MarcEdit integration –

Realistic prioritization across requirements

• Laura offered to speak in person with anyone who would like to talk about this. Please contribute to document. 
• Add to the document
  • Mike Gorrell - Development of OCLC single record import is going well. Local save files are not accessible, yet. Development geared towards starting in FOLIO and pulling records into FOLIO from OCLC. Accessing save files may be available via TCP/IP mechanism. Pulling will only be able to pull in the master record from OCLC.
  • Desire for this to be compatible with SkyRiver.
  • Emphasis that this is a first step towards integration.
  • Jesse talked about the requirements inside of workflow considerations for the OCLC integration. Considering acquisitions vs. cataloging needs too.
  • OCLC APIs may be another avenue to consider for the future.
  • Christie - What is the functionality that is needed in the next 6 months by the gap left by the lack of MarcCat? Incorporating this into the document. Chicago is thinking at a more granular level than what is presented on the documents. Laura encouraged adding a level of specificity that Christie is suggesting. Chicago is thinking about what they can live with for a while as opposed to where they eventually want to be.  Important to keep track of both. Christie gave the example: QuickMARC would be much more effective if you could delete more than one field at a time. 
  • Kyle (via chat) - "Growing API support strikes me as likely as more institutions adopt FOLIO. Shooting records at a TCP/IP port came to be supported only because there was enough demand in the marketplace for it. Having said that, it's a more specialized mechanism"
  • Update spreadsheet or synthesis Word Doc? Laura said update whichever makes sense to the contributor. 
  • Jessica (via chat) - "Would it help if we critiqued QuickMarc? I think these comments really help get at the middle ground between current QuickMarc and a full-fledged cataloging utility."
  • Column B (priority) - Should we rank them now, or wait until we know more about the feasibility of suggestions.
  • Catherine (via chat) - "MARC --> FOLIO --> MARC translation would leave a lot of room for translation errors. We have spent a long time maintaining and fixing our MARC records and we don't want to risk losing that work."
  • Kyle (via chat) - "The lossiness and things is really a separate issue. MARC is a transmission format designed for writing to tape and practically no system actually stores in MARC. It is possible that the best way to do this is to encode the binary MARC is the best way to do this, but it will make any kind of bulk operations much more problematic because you have to break up and rebuild the binary structure to do anything"
  • Can we use QuickMARC to edit MARC holdings?
  • Need to store, create, edit, and delete holdings data. 
  • Charlotte (via chat) - MM-SIGs recommendation for allowing MFHD 
  • Subfolder "FOLIO Metadata Management SIG > MARC Data in FOLIO"
  • Jesse (via chat) - "This is such an important effort here in this document, kudos to all who have synthesized"
  • Jacquie stressed importance of ergonomics in cataloging - keyboard strokes vs. mouse operations

Only if time permits it. Feed back on UIIN-372

Felix Hemme

Theodor Tolstoy