please put an 'x' next to your name in the list below the "Discussion items" if you are attending. Thanks!


Recordings of meetings can be found in the Metadata_Management_SIG > Recordings folder on Google Drive:

Discussion items

No MM meeting next week

May 6 meeting cancelled (conflict with PCC OpCo)

Next meeting will be May 13

PC update


Philip's report:

  • Announcements: Pointing exercise is due tomorrow. 
  • PC planning will look at list
  • Iris will be released on schedule 
  • 160 people were on site for the Shanghai Libraries
  • Ability to assign and take away permissions in bulk was mentioned. There is no PO or development team yet for this. PC Executive Council developed use cases for bulk permissions. There is a complex workaround, so may be a P1 issue. This will be written up as an Epic.  Should this be a user setting or a new app?
  • Kelly reported on Iris release, noting it is missing data import functionality. They will be using the hotfix. May 28 is the hotfix deadline for data import. Kelly noted uncertainty as to what will be included in the Iris release.
  • Need to develop features vs. need for automated testing. Product council will work with capacity planning.
  • Kristin Martin - questioned updates, development schedules, and whether libraries should delay implementation.
  • Reaction (from Jacquie) - "On Phil's point, I am frustrated with the very low-numbered Jiras languishing.  Some of which describe foundation functionality."

Laura's report on ElasticSearch

  • More people are needed to give input into searching.
  • Ann-Marie (via chat) - "We should get some acq folks - definitely searching issues in orders when you have lots of them."
  • Laura is volunteering to do work towards this. The PC asked for an RA and RM member (Charlotte mentioned in chat)
  • Charlotte has a group that will be working on the UI with Kimmie. The other group will look at refining some of the functionality.
  • Ann-Marie via chat: "Does the search group cover both the Elastic Search (Magda) and the MARC SRS MARC search work (Jenn C). The SRS part doesn't have a UI, so maybe not?"
  • Charlotte: It is important that ElasticSearch gets up to speed as soon as possible.
  • Please reach out to Laura or Magda if someone would like to work on this.
Other updates, announcements

Reminder of Documentation Needs page

Formal documentation:

  • Workflow will be at the second stage of documentation. 
  • Jesse pointed out that third party pieces used in conjunction with FOLIO 
  • Dennis is taking what is written and turning it into the formal documentation.
  • Documenting for Honeysuckle while simultaneously creating features of Iris and future versions.
  • Charlotte - if no libraries are on Honeysuckle, then shouldn't Honeysuckle work be deprecated. Jesse Lambertson will speak to Marcia about this. 
  • Ann-Marie sees the wisdom in documenting Honeysuckle since it is a current fairly stable version.
  • Laura encouraged people to keep contributing to the wiki. 
  • Jesse - this is a public facing global document that we're creating in
  • Patty - Thought FOLIO community was only going to support the current release and one past that. 
  • "One more announcement that I'm not sure has been shared here: FOLIO was reaccepted into the Google Season of Docs." – Dennis (via chat)
  • Conclusion: Do not worry about contributing to the Documentation Needs page.

Related titles

updates on UXPROD-1892

Slide deck 

Question: Would we want the HRID to be a link in addition to the title?
Some comments to switch the link form the title to the Instance HRID. This would mean retraining for some libraries and staff. Format was added to the related instance description.

Question: Relationship information ordered alphabetically, as opposed to MARC order. 

Ann K (via chat): "Alma/Primo uses 773 for bound with relationships"

The 77X fields do not have particular associated meanings.

Z39.50 & MarcEditJesse Lambertson

The API functionality is not ready for MarcEdit yet, however Z39.50 is a standard integration with MarcEdit. Jesse has found that searching via Z39.50 and MarcEdit is working. 

MarcEdit can interact with holdings records. Can we get access to that if we need to in a prioritized way? (Laura, via chat, "Holdings data are not stored in MARC YET"

Nothing can be written back to FOLIO with Z39.50. 

How do we push this functionality forward for this? Laura asked if Jesse could do a demo for this. Jesse agreed. Z39,50 supports MARC21. 

Jenn (via chat), "I think clarifying how apps external to data import use data import before proceeding with marc edit would be good as far as writing but that’s just my 2 cents. Like finish oclc first." "Using MarcEdit as the source from which data import would do its job" - Pushing from MarcEdit does not support updates or overlays, only creation.

Christie - Should we return to the MarcEdit document? There is a lot of overlap currently. What are our MarcEdit use cases? "Ann - our workflows right now are ETL - export them from data export. Edit with MarcEdit. And then put back in with Data Import. It is how we work with our current system as we have no direct integration between MarcEdit and our system."

Ann-Marie (via chat) - "Yes, bulk edit in FOLIO resolves a lot of these use cases."

It think Jessica meant MARC8 vs. Unicode.
From Jacquie Samples to Everyone:  12:34 PM
yes, Z39.50 supports Unicode.
From Ann K. (she/her) to Everyone:  12:35 PM
Great idea @christie
From Ann-Marie Breaux to Everyone:  12:36 PM
Yep - absolutely, Christie.
And to me, this is a situation where ideally we make tools available, instead of making custom solutions for each source
From Laura (she/her) Daniels to Everyone:  12:36 PM
are the MarcEdit use cases in Confluence? or google drive?
From Jenn to Everyone:  12:36 PM
+1 christie our priorities are like well we could do this or this or this depending on what the state of DI/global edit/other imports are…
From Jesse Lambertson to Everyone:  12:37 PM
yeah, where is this uses-case document? I would love to see that if I have not
From Jenn to Everyone:  12:37 PM
I hate to say it but an “edge” api for DI and then pick your tool to talk to it
From Christie Thomas (she/her) to Everyone:  12:37 PM
I think that there was a marcedit use cases survey that went around? I am not sure where the results of that survey are.
From Me to Everyone:  12:38 PM
If data import won't bring records back in, putting resources into this seems wrong
From Christie Thomas (she/her) to Everyone:  12:38 PM
+1 Jenn and Ann-Marie. Ultimately I think we should be able to pick our tool.
From Ann K. (she/her) to Everyone:  12:38 PM
I think for us, if we don’t have bulk edit capabilities for Marc records in folio, then MarcEdit.
But if we can get bulk edit in Folio it’s less important
From Jacquie Samples to Everyone:  12:38 PM
I would prefer to be able to batch processes within FOLIO.
From Charlotte Whitt to Everyone:  12:39 PM
Bulk edit i sUXPROD-120
From Jacquie Samples to Everyone:  12:39 PM
MarcEdit seems like another work around.  and ETL as a work around doesn't function right now.
From Ann-Marie Breaux to Everyone:  12:39 PM
Yes, bulk edit in FOLIO resolves a lot of these use cases.
From Christie Thomas (she/her) to Everyone:  12:39 PM
Ann - our workflows right now are ETL - export them from data export. Edit with MarcEdit. And then put back in with Data Import. It is how we work with our current system as we have no direct integration between MarcEdit and our system.
From Ann K. (she/her) to Everyone:  12:40 PM
Yes @christie—we do a lot of the same
From Jacquie Samples to Everyone:  12:40 PM
On the other hand, we do currently use MarcEdit every day to validate MARC prior to loading into our current system. So, I would like an integration, but not as a work around for bulk edit processes within FOLIO.
From Ann K. (she/her) to Everyone:  12:40 PM
We can batch edit in aleph, but not all the things we do
From Christie Thomas (she/her) to Everyone:  12:40 PM
We do still have the problem of performance and scale, but I am not sure that MarcEdit would solve that for us.
From Ann K. (she/her) to Everyone:  12:41 PM
We would love them to be integrated if possible. Just wish list
From Robert Scheier to Everyone:  12:41 PM
I do like the our current system’s ability to create load profiles which are extremely flexible

Productivity stats "alternative" – postponed Laura Daniels

Demo of Cornell's planned approach until UXPROD-2867 - Getting issue details... STATUS is implemented

(see Alternatives for Features Still in Development)




Aaron TrehubAuburn

Ann-Marie BreauxEBSCO

Ann KardosUMass Amherst


Charlotte WhittIndex Data

Christie ThomasChicago
     Christin Seegerthbz

Colin Van AlstineSmith (FC)

Damian Biagi

Dennis BridgesStacks

Dennis ChristmanDuke University
     Douglas ChorpitaGoethe Uni Frankfurt

Dracine HodgesDuke University

Felix Hemme


Filip Jakobsen

Jacquie SamplesDuke University

Jason KovariCornell

Jenn ColtCornell

Jennifer EustisUMass Amherst

Jessica JaneckiDuke University

Joshua BartonMichigan State

Kristen WilsonIndex Data
xLaura DanielsCornell

Lisa FurubottenTexas A&M

Lisa McCollLehigh University

Lisa SjögrenChalmers

Lynn Whittenberger
xMagda ZacharskaEBSCO

Martina Schildt


Molly DriscollEBSCO

Nancy Lorimer


Natascha OwensChicago

Niels Erik Nielsen

Patty WanningerEBSCO
xPhilip Schreur
xRita Albrechthebis-Verbundzentrale

Sara ColglazierMHC/5C

Tiziana Possemato

Theodor Tolstoy


Wayne Schneider

Index Data

    xJesse LambertsonUniversity of Chicago

Raegan Wiechert

Missouri States University

Patricia RatkovichUniversity of Alabama

Khalilah GambrellEBSCO