2025-06-25 Data Import SIG Meeting Notes

2025-06-25 Data Import SIG Meeting Notes

Recordings are posted Here (2022+) and Here (pre-2022)                   Slack channel for Q&A, discussion between meetings

Requirements details Here                                                                    Additional discussion topics in Subgroup parking lot

 

Attendees: @Jennifer Eustis , @Whitney Christopher , @Lynne Fors , @Kalvin Van Gaasbeck , @Ryan Taylor @Ryan Mendenhall , ChurchD, Julianne Newberry, @Katie Rahman , @Stephanie Spratt , DeAnn-Neosho, @Jacob Dudley , @Susan Jones (Deactivated) , rpitamiello, @Yael Hod , @Mary Aycock , @Sheila Torres-Blank , @Kim Wiljanen
Notetaker: 

Links:

Agenda: 

Topic

Who

Meeting Notes

Related Jira

Decisions/Actions

Announcements

ALL

Details Notes for Ramsons

 

7/23: Meeting on Authorities. We will be joined by @Jeanette Kalchik @Kalli Mathios @Alissa Hafele @Sheila Torres-Blank Mary Company @Emily Semenoff who will lead the discussion on authorities primarily related to Data Import and batch processes.

 

 

Lab Sessions: Need Volunteers Still

Jennifer

  • Monday 9 am EST: Jennifer E + volunteer

  • Day?, 4pm PST: Yael + volunteer

  • Thursday 3-4 pm EST: Rob, Whitney, Lynne

 

 

UXPROD-4080: Review and fix MARC Updates for individual fieldsDraft

Ryan

Notes: Need to define expectations for MARC updates by specific field.

(Spreadsheet with some current behaviors as of Q release:

)

Two distinct use cases for MARC Bibliographic Updates (when targeting a specific field or fields only.) - 1) Merge - add fields from the incoming file to the existing FOLIO record without deleting any content already in the record. 2) Overlay (maybe use replace here instance of overlay?) - replace a field with the same field in the incoming record.

Note - that we could use existing terminology such as for repeatable fields in the holdings and item records. (Statistical codes, etc.)

Does not account for the ability to match on a single field when there are many fields present, such as 035 fields that begin with (OCoLC). Borrow matching logic for this? Or use a field mapping profile? Would need to define expectations in a multiple match scenario. In the (OCoLC), what would we expect to happen in a scenario where there are multiple 035$a fields that begin with (OCoLC).

Do we need to have UI options for differentiating between repeatable and non-repeatable field? Or should we treat all fields as potentially repeatable?

RT will take this discussion back to the team for discussion and analysis. Jira will remain in Needs Review status for now.

Q: Is it possible to embed a job profile in another job profile?  This almost feels a bit like a job profile within a job profile?

A: It is not possible? Discuss at a future meeting?

 

 

Upcoming meetings/agenda topics: --

 

Chat: