2024-09-05 Metadata Management Meeting notes

Owned by Raegan Wiechert
Last updated: Sep 05, 2024 by Alissa Hafele
11 min read

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 5, 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



No announcements

Version History & Last Updated Data Use Cases

@Khalilah Gambrell

Notes

  • Feedback really important in order to get reqs clarified by end of September at latest - see wiki page above

  • What changes do catalogers care about?

    • agreement that list looks good

    • agreement to change MARC bib to 4th in priority list

    • Could there be a setting to turn off what user made changes?

    • Could logs be cleared after certain number of years?

      • ablility to export them

      • configurable per library

    • Would like to see change tracker in Users, Serials, Orders (already there)

      • working on pattern used in Orders

  • What changes should user see?

    • level of detail looks good. Source of change and date/time would be great start if incremental development is needed.

    • How will you see the change history on item or holdings?

      • open record to see

    • It would be nice to see the change field highlighted

      • would functionality be useful without since this won’t be available in sunflower? yes

    • Changed is in bold - what else could this say? Khalilah will check

    • Would there be any data in change history at the point of creation if there have been no further edits?

      • no

  • What is an update - see wiki page with use cases

    • section added to table for what should NOT be considered an update

  • Additional requirements

    • do libraries that don’t want to see user data still want to see user vs system change? Felix says yes.

    • How many years should be displayed/kept?

      • how many changes?

      • It should be configurable, and by number of changes plus how many years to retain data (even if not available in UI)

        • some records won’t get edited for number of years

      • what should be the default? nothing specified yet. Maybe 10-15 updates

        • would like to see if there are more, even if not accessible for viewing in UI

      • Lynn - I would want to keep the whole change/version history and make it available for viewing when it's wanted by selecting an expansion (show more function), but only show the latest 10-15 changes.

    • Could we query the updates in the future?

      • An API would be great for getting at all of the data. I think that the latest 5-10 updates in the UI would more than sufficient.

        • others think UI support required for users to get to data not in displayed

    • What would be displayed in the version history in case a staff user record is deleted in the Users app? Something like "User not available"?

  • System updates vs. User updates

    • need to know about both

    • need to be able to differentiate

    • Further conversations on this should happen and table added to wiki for “what should not be shown”

 

 

 

 

 

 

PC updates

@Charlotte Whitt

2024-09-05 Product Council Agenda and Meeting Notes

Announcements: At the PC Shoulder meeting at WOLFcon, the PC will plan for the coming year

Presentation on new functionality. Seeking the PC’s approval to incl. the modules into the Ramsons release:

  1. mod-marc-migrations (backend module)

    1. Any mapping rules updates require all existing bib/authority records to be touched to apply these updates. This is current a very slow and manual process; e.g. the process can run for weeks

    2. The new module can run in simultaneuosly tracks. 100.000 records was in preliminary test run in 5-10 minutes. If increasing the resources you can achieve a faster mapping. See more here. Inconsistens or optimistic locking errors are stored in logfiles; but not in the data base. Technical and Design specifications, see here. This does not impact linking between bibs and authority records.

  2. mod-record-specifications (backend module, aka Mr Specs)

    1. Support tenant level MARC validation. Ramsons requirements. The quickMARC UI has been updated to throw warning when editing. This check is happening in the API. But not preventing the record to be stored, unless it is errors. This work do apply to ECS too.

Finally - anything you want me to bring back to the PC?

BELA (Bulk Edit and Lists App)

Jennifer Eustis

2024-09-03 BELA Meeting Notes

This week focused on the Lists App. We saw new functionality for Ramsons, https://folio-org.atlassian.net/jira/software/c/projects/UXPROD/boards/249 . We also discussed https://folio-org.atlassian.net/browse/UILISTS-79 or the need to add an indicator when additional data is waiting to be displayed. This led to several comments on UI such as the language of “Test query” when it is a preview or how it’s not evident how to refresh the data. The group asked for a shortcut key for refresh. We also discussed https://folio-org.atlassian.net/browse/MODINVSTOR-1159 and https://folio-org.atlassian.net/browse/MODFQMMGR-158 which mean to search and also display all elements in the effective item call number. It was highlighted that Inventory doesn’t have this type of element where all enumeration (enum, crhon, year caption, display summary, volume, copy number, call no prefix and suffix, call no) elements are there. Is there a need for such a system generated field in Inventory?

Data Import Working Group

Jennifer Eustis

No meeting this week. With the release of Quenelia, some have commented on the set for deletion functionality. The working group will be returning to this issue and has highlighted wanted functionality in .

quickMARC Subgroup update

Raegan Wiechert

No meeting this week

Chat

08:36:05 From Laura Daniels to Everyone:
Yes, this accurately represents my expectations
08:37:26 From Felix Hemme to Everyone:
I agree. Knowing when a record has been edited and what has been changed during this action.
08:38:20 From Felix Hemme to Everyone:
I know it is annoying, but what about a customization to not store the user data who did the change?
08:38:36 From Felix Hemme to Everyone:
Like a setting to turn it on/off.
08:38:47 From Laura Daniels to Everyone:
Reacted to "Like a setting to tu..." with ➕
08:38:48 From Sheila Torres-Blank (she,her) to Everyone:
Reacted to "Like a setting to tu..." with ➕
08:39:02 From Christie Thomas (she/her) to Everyone:
Reacted to "Like a setting to tu..." with ➕
08:41:47 From Lloyd Chittenden (Marmot Library Network) to Everyone:
This needs to be broader than just cataloging. It should be implemented the same in Orders, Serials, Users, other apps.
08:42:08 From Jennifer Eustis to Everyone:
Replying to "This needs to be bro..."

It is in Orders. It's great!

08:42:39 From Laura Daniels to Everyone:
I love this level of detail. Just knowing the source of change and date/time would also be a great start, if the development needs to be incremental
08:42:49 From Jennifer Eustis to Everyone:
Reacted to "I love this level of..." with 💯
08:43:32 From Lloyd Chittenden (Marmot Library Network) to Everyone:
Also consider ECS, tracking central records and shadow records.
08:43:44 From Laura Daniels to Everyone:
Related to Felix's comment, it would also be nice to have a rolling time period where these logs get cleared, so we are not storing years of change information if we don't want to.
08:43:53 From Jennifer Eustis to Everyone:
Reacted to "Related to Felix's c..." with 💯
08:43:53 From Felix Hemme to Everyone:
Reacted to "Related to Felix's c..." with 💯
08:43:58 From Raegan Wiechert to Everyone:
Reacted to "Related to Felix's c..." with 💯
08:44:06 From Felix Hemme to Everyone:
Replying to "Related to Felix's c..."

I was just typing this in :)

08:44:41 From Christie Thomas (she/her) to Everyone:
Reacted to "I love this level of..." with 💯
08:45:23 From Christie Thomas (she/her) to Everyone:
Reacted to "Related to Felix's c..." with 💯
08:45:39 From Jennifer Eustis to Everyone:
It'd be great to be able to configure that in settings but also have access to all the logs and be able to export them
08:46:31 From Lynne Fors to Everyone:
Replying to "It'd be great to be ..."

Yes! change history retention should be configurable by each library to suit their own workflows

08:46:34 From Sheila Torres-Blank (she,her) to Everyone:
Reacted to "Related to Felix's c..." with 💯
08:46:59 From Laura Daniels to Everyone:
Reacted to "It'd be great to be ..." with ➕
08:52:03 From Lynne Fors to Everyone:
It could be helpful to flag the changes more prominently
08:52:43 From Lynne Fors to Everyone:
Replying to "It could be helpful ..."

08:53:46 From Laura Daniels to Everyone:
Yes! Some information is better than none.
08:53:54 From Lynne Fors to Everyone:
Reacted to "Yes! Some informatio..." with ➕
08:53:58 From Felix Hemme to Everyone:
Reacted to "Yes! Some informatio..." with ➕
08:54:57 From Lynne Fors to Everyone:
Would a new record say "Created"?
08:55:27 From Christie Thomas (she/her) to Everyone:
Would there be any data in change history at the point of creation if there have been no further edits?
08:55:59 From Laura Daniels to Everyone:
Replying to "Would there be any d..."

08:56:35 From Felix Hemme to Everyone:
Looking at the second mockup could give a glimpse at the holdings/item view. Fullscreen with a second pane.
08:56:51 From Lynne Fors to Everyone:
Replying to "Would there be any d..."

08:58:53 From Lloyd Chittenden (Marmot Library Network) to Everyone:
Circulations should not be updates.
08:58:58 From Laura Daniels to Everyone:
Reacted to "Circulations should ..." with 💯
08:59:00 From Ryan Tamares - Stanford Law Library to Everyone:
Reacted to "Circulations should ..." with 💯
08:59:02 From Lynne Fors to Everyone:
Reacted to "Circulations should ..." with 💯
08:59:41 From Felix Hemme to Everyone:
Replying to "Circulations should ..."

09:00:52 From Felix Hemme to Everyone:
Yes!
09:02:59 From Ellis Butler to Everyone:
seconding it being configurable
09:04:50 From Jennifer Eustis to Everyone:
10
09:04:50 From Felix Hemme to Everyone:
What would be displayed in the version history in case a staff user record is deleted in the Users app? Something like "User not available"?
09:04:56 From Lisa Furubotten TA&M to Everyone:
so, would we be able someday to do a query on the changes? for example: show me all records where such and such happened... in that case I'd want to keep all the data (if I could query)
09:05:09 From Laura Daniels to Everyone:
I think it's X number of updates rather than time
09:05:11 From jeanette to Everyone:
Number of changes
09:05:12 From Jennifer Eustis to Everyone:
I was thinking of displaying 10 and for years I'm not sure
09:05:45 From Amanda Scott to Everyone:
Sometimes that would be helpful to track and other times it would not, in my view (responding to Felix).
09:06:15 From Laura Daniels to Everyone:
I think orders don't have as much potential change over time?
09:06:22 From Felix Hemme to Everyone:
Reacted to "Sometimes that would..." with 🙏
09:06:34 From Felix Hemme to Everyone:
Reacted to "I think orders don't..." with ➕
09:06:39 From Laura Daniels to Everyone:
Reacted to "I was thinking of di..." with ➕
09:06:46 From Jennifer Eustis to Everyone:
Reacted to "I think orders don't..." with ➕
09:06:52 From Laura Daniels to Everyone:
Replying to "I was thinking of di..."

09:06:59 From jeanette to Everyone:
Years seems problematic because a record might have an issue but was updated 10 years ago
09:07:01 From Lynne Fors to Everyone:
I would want to keep the whole change/version history and make it available for viewing when it's wanted by selecting an expansion (show more function), but only show the latest 10-15 changes.
09:07:08 From Laura Daniels to Everyone:
Reacted to "Years seems problema..." with 💯
09:07:13 From Jennifer Eustis to Everyone:
Reacted to "Years seems problema..." with 💯
09:07:18 From Julie Darken to Everyone:
Reacted to "Years seems problema..." with 💯
09:07:22 From Mary Aycock (she/her) to Everyone:
Reacted to "Years seems problema..." with 💯
09:07:44 From Lisa Furubotten TA&M to Everyone:
Reacted to "I would want to keep..." with 👍
09:07:47 From Julie Darken to Everyone:
Reacted to "I would want to keep..." with 👍
09:08:11 From Ryan Tamares - Stanford Law Library to Everyone:
Reacted to "I would want to keep..." with 👍
09:08:59 From Laura Daniels to Everyone:
Replying to "I was thinking of di..."

09:09:55 From Christie Thomas (she/her) to Everyone:
Reacted to "I would want to keep..." with 👍
09:10:13 From jeanette to Everyone:
Reacted to "I would want to keep…" with 👍
09:11:05 From Laura Daniels to Everyone:
I'd want longer than a year
09:11:10 From Lynne Fors to Everyone:
Reacted to "I'd want longer than..." with ➕
09:11:11 From Mary Aycock (she/her) to Everyone:
Reacted to "I'd want longer than..." with ➕
09:11:14 From Christie Thomas (she/her) to Everyone:
Is that for display in the UI or in the data? Or both?
09:11:16 From Julie Darken to Everyone:
Reacted to "I'd want longer than..." with ➕
09:11:42 From Lisa M English to Everyone:
👍
09:11:50 From Charlotte Whitt to Everyone:
Is it possible to qualify what updates to display?
09:11:51 From Laura Daniels to Everyone:
Replying to "I'd want longer than..."

09:11:59 From Christie Thomas (she/her) to Everyone:
I would definitely want longer than a year and the ability to make a decision about when to purge the data. I think we would default to keeping it unless it became a burden.
09:12:22 From Charlotte Whitt to Everyone:
So updates of an item related to the holdings being updated, to be filtered out
09:12:26 From Felix Hemme to Everyone:
Reacted to "I would definitely w..." with ➕
09:12:28 From Julie Darken to Everyone:
Reacted to "I would definitely w..." with ➕
09:12:30 From Jennifer Eustis to Everyone:
Reacted to "I would definitely w..." with ➕
09:12:34 From Lynne Fors to Everyone:
Reacted to "I would definitely w..." with ➕
09:12:49 From Christie Thomas (she/her) to Everyone:
Good question, Charlotte. For older updates we might just want a date stamp and a user.
09:12:59 From Lynne Fors to Everyone:
Reacted to "Good question, Charl..." with ➕
09:13:29 From Christie Thomas (she/her) to Everyone:
An API would be great for getting at all of the data. I think that the latest 5-10 updates in the UI would more than sufficient.
09:13:36 From Laura Daniels to Everyone:
Reacted to "An API would be grea..." with 💯
09:14:02 From Lynne Fors to Everyone:
I would want both so that all users of different skill levels could have access to the data
09:14:10 From Mary Aycock (she/her) to Everyone:
Reacted to "I would want both so..." with ➕
09:16:13 From Christie Thomas (she/her) to Everyone:
That is an excellent point, Nancy. I agree.
09:16:36 From Lynne Fors to Everyone:
Reacted to "That is an excellent..." with ➕
09:16:50 From Amanda Scott to Everyone:
Reacted to "That is an excellent..." with ➕
09:16:56 From Julie Darken to Everyone:
Reacted to "That is an excellent..." with ➕
09:17:48 From Christie Thomas (she/her) to Everyone:
Could there be a way to pull the entire change history from a record via Lists?
09:18:13 From Lynne Fors to Everyone:
Replying to "I would want both so..."

09:22:35 From Felix Hemme to Everyone:
The source updated should just change if an edit was initiated by editing this record, regardless if it is via API, in the Inventory API or via Bulk Edit. But if a staff user receives a piece in Receiving and this updated the item record, then this is not an intentionally change to the item by this user. Does that make sense?
09:22:48 From Laura Daniels to Everyone:
Reacted to "The source updated s..." with 💯
09:22:52 From Raegan Wiechert to Everyone:
Reacted to "The source updated s..." with 💯
09:22:53 From Felix Hemme to Everyone:
But I doubt that we have this context...
09:23:03 From Christie Thomas (she/her) to Everyone:
Reacted to "The source updated s..." with 💯
09:23:15 From Charlotte Whitt to Everyone:
Will it be helpful to define the concept of the record, and updates of the given record, and what is transactional updates - e.g. change of item status
09:23:42 From Charlotte Whitt to Everyone:
Reacted to "The source updated s..." with 💯
09:24:37 From Lynne Fors to Everyone:
Sometimes transactional updates helps with trying to figure out what happened to a physical item, such as it got received but never came to cataloging