2024-09-19 Metadata Management Meeting notes

NoMeeting time: 11:30 AM EDT, 05:30 PM CEST, 04:30 PM BST

Meeting URL: https://zoom.us/j/527543204 . The meeting password can be found here.

 Date

Sep 19, 2024

Note taker

Laura Daniels, Lynne Fors, Alissa Hafele, Natascha Owens

Recordings

Recordings of meetings can be found in the Metadata_Management_SIG > Recordings folder on AWS from 2022 onwards: https://recordings.openlibraryfoundation.org/folio/metadata-management-sig/

Discussion items

Item

Presenter

Notes

Item

Presenter

Notes

Announcements



Thinking about attending the session Understanding mod-search and indexing at WOLFcon on Wednesday September 25, 2024 at 4:30pm BST? Please fill out this pre-session survey to help us get a better understanding of your expectations. Deadline Sept. 13, 2024: https://zbw-umfrage.limesurvey.net/133913?lang=en

Survey is still open despite deadline date.

MM SIG Working Meeting at WOLFcon: potential changes to Inventory to better support various non-MARC metadata. Related to pre-conference session https://wolfcon2024.sched.com/event/1eevQ/linked-data-production-foundations-where-are-we-now-where-are-we-going-how-do-we-get-there

No MM meeting next week due to WOLFcon. We will reconvene October 3rd.

Series browse requirements

@Christine Schultz-Richert

UXPROD-3741

Planning this feature for Sunflower

Use cases: consistency, troubleshooting, Acq: verify volume numbers, Determining if an order should be attached to a set or given a new bib record; Patron finds a volume of a series but wants to find more; Both discovery layer and mediated by staff

What should we include as part of series statement in browse?

Default mapping in FOLIO is currently 830s

Felix: Would expect the $v to be ignored

Pulling from the series statement in Instance record so if one Instance has same statement it will be aggregated in the Number of titles

Seems to be use cases for both having the $v and omitting it

Initial results to display without $v but include all others? ($x, $w, $z)

Leaving out certain subfields would limit our ability to differentiate between volumes or even series statements

How would you be able to omit subfields if we are using the string from the Instance data? 

More data displayed may mean that series are split, especially due to inconsistencies

Mention of the 440’s: our data is not clean so these are still present in many people’s data—would be important to map this to series statement

Jeffery Gerhard’s idea:

Not a lot of use to browse on something that will be different for every single record, better to consider title browse (map series title to alternative title type); but if we really wanted to do series specific we would have to change up the schema

 

 

 

 

 

 

PC updates

@Charlotte Whitt

Announcements: voting on mod-reading-room and ui-reading-room is in progress

September SIG Reports

Critical Service Patch (CSP) process / presentation by Oleksii Petrenko. Shifted from doing Hot Fix to CSP in 2022. CSP is a small and targeted software patch to address critial issues which are P1, or P2 bugs without a reasonably work arounds. Security CSPs has been excluded from the regular CSP process.

Note: For Poppy (R2 2023) then most of the 104 CSPs were Security/vulnerability CSPs.

Criteria for assigning P1 - P5 priorities - defined here: https://folio-org.atlassian.net/wiki/x/dY4o

Link to the slide deck here (insert when available).

Marc Veksler underlined the importance of getting Better Sample Data in the FOLIO reference environments.

Anything you’d like me to take back to the PC?

If you think of anything, feel free to message Charlotte.

BELA (Bulk Edit and Lists App)

Jennifer Eustis

No meeting.

Data Import Working Group

Jennifer Eustis

No meeting

quickMARC Subgroup update

Raegan Wiechert

No meeting

Chat

Laura Daniels 10:36 AM
I would assume the regular meeting is cancelled next week

Lynne Fors 10:41 AM
Where is the series statement being populated from? Field 490 or 830? Both of those fields are mapped to the Instance.

Felix Hemme  to  Everyone 10:42 AM
I would expect it to ignore the value that comes from $v.

Laura Daniels  to  Everyone 10:43 AM
I would exclude $x (ISSN) and $w (Bibliographic record control number)

Raegan Wiechert  to  Everyone 10:43 AM
I would want it to ignore $x, just because it is not added consistently and I wouldn't want two entries for the same series

Sheila Torres-Blank (she,her)  to  Everyone 10:43 AM
Omitting $v makes it difficult to see if a particular volume is held. I'd prefer to see $v.

Amanda Scott  to  Everyone 10:43 AM
Use case: perhaps as a subcategory of "consistency," determining if a series is classified together or separately.

Lynne Fors  to  Everyone 10:44 AM
The aggregated search would send you to a list that is not in series number order, which is hard to parse

Raegan Wiechert  to  Everyone 10:44 AM
Sometimes I would want $v, sometimes I wouldn't

Laura Daniels 10:45 AM
I think I'd want an initial results display without, with the option to drill down to a list that includes the $v

Lisa Lorenzo (Mich. State University Libraries) 10:45 AM
I was having the same thought as Laura. It would be nice if the search result list after you click on the series title would have the full series (with $v) as a column

Gerhard, Jeffery 10:45 AM
This doesn't really work when there is only a single field for the series statement. If you map without the volume number, then we lose utility in the Instance record

Magda Gad 10:47 AM
Do we have them listed if click on the series title?

Gerhard, Jeffery 10:51 AM
One way this could work without a schema change would be: map (most of) the 830 to an alternative title and type. Then the series statement could include $v. And then series browse could work on the alternative title instead of the series statement

Amanda Scott 10:51 AM
I think my institution still has records with 440s.

jeanette 10:52 AM
If we have a non standard mapping of 490s to series would they show up here?

Amanda Scott 10:56 AM
Yes, the music ones are important! :)

Lynne Fors 10:58 AM
Wouldn't the series ISSNs be in the ISSN index?

Laura Daniels 10:59 AM
we have to keep in mind we are talking about browse specifically, not search, right?

Sheila Torres-Blank (she,her) 10:59 AM
Not sure I'd expect to see ISSN in a Series browse index. It's not really part of the heading; just extra data.

Laura Daniels 11:02 AM
and is the index coming from the source data or from the instance data???

Laura Daniels 11:09 AM
I think this is a mapping question and Natascha is correct, we likely all do this slightly differently already

the numbering remains a collective concern, though, imo

numbering being $v

Gerhard, Jeffery 11:11 AM
I have an idea for how to meet this need, but it is a lot to explain. I don't think the approach we are seeing today is going to work

Laura Daniels 11:14 AM
Yes, title browse is a good idea

Sheila Torres-Blank (she,her) 11:15 AM
Fairly new user and I've wondering why there is no title browse. Would love that.

Lynne Fors 11:16 AM
Would definitely need a way to specify what kind of title

Gerhard, Jeffery 11:17 AM
to be honest, I believe our current OPAC uses a combined index on series and titles for the equivalent of a series browse

Laura Daniels 11:19 AM
440 is part of the default mapping if I remember correctly

Natascha Owens 11:23 AM
I'm pretty sure we have to add 440 and 490 to our mapping so I don't think it is part of the default