2024-09-24 Metadata Management Working Meeting @ WOLFcon 2024

Welcome and introduction

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

Findings from the Linked Data Foundations session on September 23rd:

• Instance metadata source: Can’t store source of record and source format in one property. Would be interesting to store the source (e.g. Libris) and the source format (e.g. MARC or JSON-LD). Felix' thoughts from 2020 on this: Metadata Source Codes -- Instance

• The National Library of Sweden has identified more needs for their management of metadata:

  • Store statistical data

  • Can’t distinguish multiple languages (e.g. original language and language of translation)

  • Need more granularity when recording year of publication.

  • Need to store properties to retrieve records for bulk edit operations

• Revisit the role of Inventory.

• Do we need to store (more) URI’s in Inventory?

• When looking at the source record via Actions > View source:

  • Should there be an option to switch between multiple serializations of a schema, e.g. MARC 21 plain, MARC 21 XML, JSON-LD, Turtle etc.

  • When looking at a linked data source record, should the URI’s display as is or should the actual values be retrieved and displayed? Maybe the latter would be more helpful to the staff user.

Instance Source Code

Challenge in how the data is encoded within the source code of FOLIO itself and not managed by reference data. There is little benefit in having this information in the code and any benefit could be reproduced via a configuration approach.

Also, we are using one code and conveying two different types of information with one code. We need to indicate the data source and the standard/format. See the MMetadata Source Codes -- Instance. (Document has not been updated since 2020.)

If we add a new property and change the values need to account for historical data change and new field population on implementation at the point of upgrade or migration. Could possible set default values or replacement values for these properties. This will add complexity to the upgrade. It will be a big lift for the developers to figure out how to do it in a way that does not impact operations in order to update all instance. But it may be the price we have to pay.

The idea is good, but there is concern about recording vendor information here as was proposed by one individual. Need to discuss the extent of these fields. Question about whether we need to note the source or just the format.

What will having these new properties enable us to do? How would MARVA know to open the MARVA app or another app?

The UI does have a notion of plugins so can imagine an action where a defined data source can launch a specified editor. For instance, defined data source LD Marva would open in MARVA.

Also brings us back to the notion of view source. What are the use cases for this vs edit? Need to articulate this?

What are the impacts of cross-app functionality? How would these changes interact with other applications? Import / export / orders, etc.

There is agreement that we should pursue the new field in the MM Sig.

Inventory display and search

There is a MARC search API that is working very well for data that is only available in the MARC record, but there is no UI. There is obscure data in MARC and obscure data in Bibframe. People have to do intensive searching in inventory. Those two things are incompatible. Inventory is coming a behemoth and MARC 2.

Question about URIs in Inventory records. Would this help? See discussion broken out below.

Dream of codex. Everyone is using Inventory and we have different ways of searching inventory. Circulation search and view vs catalogers search and view. Inventory is trying to do all things and is failing at all of them.

Potential of different views in inventory. For circulation and for catalogers.

Display of the search results - MCL is only a thin-thread implementation and was never intended to be the final search result. We need to fix the search display problem.

Managing URIs in inventory

What do we want inventory to do? What needs to be in inventory vs what does not need to be inventory? Do we have an operational need to manage URIs in inventory?

Maybe not the place for managing URIs, but maybe a display of the URI is important for differentiation and reporting.

More administrative URIs, when present it is useful to have those be live. Right now the only place to put a live URI is in the Electronic Resource block.

There is a need to search for a URI.

Leads back into the question of where caching happens.

Are there needs for URIs at the holdings and item level?

Question about searching URIs in Inventory - need to solve the problem of being able to search URIs in Inventory. Cannot currently search URLs in electronic resource block

Prioritizing all of the above -

What are we thinking in terms of prioritizing this work? Thinking ahead to Trillium. There is already lots of prioritized work that we are thinking about?

Do we need to revisit the Inventory roadmap and vision since it has been so long since work in the backlog has been discussed?

Also the challenge of how it is hard to do any work on inventory because it is so big. Now is the time because of the work being done on Eureka.

Updating the roadmap could be a good thing because it would demonstrate to PC that we have thought this through. It would also allow us to order and prioritize work. It will also provide transparency in support of collaborations with other sigs.

Have a series of meetings to articulate our vision and move on to the roadmap and priorities.

One approach is to socialize what has happened in the linked data space and good reason for us to visit the overall roadmap. An LD primer may be needed. This is at the root of inventory and this is what it was supposed to do.

Other opportunities to rethink - inventory is not serving RA very well. And Acquisitions. We need to make sure that we have the buy-in of these groups to make big changes.

We need to build an ecosystem - libraries need to make multiple decisions. Not just one thing. We need to demonstrate that FOLIO is robust and FOLIO can demonstrate that it is where it needs to be.