Page Comparison

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.