2025-01-10 Meeting notes

Announcements?

External Data Store URI in Inventory Administrative Metadata

@Kalli Mathios

Draft to be discussed, added to Jira

Zoom Chat:

Would we maybe want both a link to the display of LD source, and also a directly link to edit of the LD source?

That is what is being implemented in the Action menu by the Citation team.

LINKED_DATA will be provided by Citation for the Linked Data Module.

What about using the Identifiers group in the Instance metadata?

This would align with how OCLC numbers are recorded for MARC records in the FOLIO instance

@Timothy Ryan Mendenhall (he/him) to me the question is if this is a privileged identifier in some way.

It’s believed that identifier types can be customized, although identifier types tend to be numbers

They are locked to the Marc mapping for people using Marc I think

I think getting it into the data model is the big lift, so from that perspective I like the limited focus. Once it's in the data model then it is easier to spin off stories on how to use it in UI or business logic.

I like the idea of having the URI in administrative data. It makes sense there to me. That is where other administrative metadata appears in the UI.

You could create a unique identifier type for the UI, but there may be a complexity in protecting it or maintaining it when updating the rest of the description from the source.

So I’m a little unsure on the identifier approach, while different sources to me is something very different than one identifier in MARC and another identifier in MARC.

Do we know what Citation do for linking Works, Agents, etc. into Inventory

I’m contradicting myself a bit, thinking that Admin-metadta might be a good place for the URI.

They are. They will be mapped or not. It is not possible to update some identifier types and not others if you are using the baked in MARC to instance mapping. But if you are building a custom integration, you could create a more nuanced process for managing the identifiers.

So, I am going back to the issue of storing the URI in a field that has a data type of URI - I don't think that is possible in the FOLIO data model? Even the URIs in the electronic access block are stored as strings in the data. I understand the desire for a specific data type, but I don't think that is a constraint that FOLIO has applied before and I am not sure what it would take. But I could be wrong.

Keeping the initial scope to just the data model is best; otherwise we’re creating too much work.

Where to have it in the data model is something we have a say about; how to implement is up to the developers.

The fact that this is an identifier for a “record,” not an identifier for an entity can cause problems if the two are conflated

Linked Data data is a different representation of the instance compared with the MARC representation of the same instance

We actually don’t have them in the same place in Libris! =)
The identifier (mainEntity) is in Adminmetadata, the identifiers that actually refer to the resource is in identifiers.

Technically JSON schema can be constrained to accept particular types of string data (e.g. a UUID or a URI)

A good idea to separate out identifiers that manage the description that is feeding this instance.

We could implement this new Administrative data source identifier, with a similar construction like Instance resource identifiers.

              A Settings > Inventory page > Administrative source identifier …?

And UUID is definitely controlled. The data type is still string, of course, it's just a constrained string.

·       Right. But I don't think any of the URI fields in FOLIO are constrained in any way. We are always finding non URL data there!

But I guess what I'm saying is that I think it's an implementation question, in the end, not a question of the data model itself, which does support constraining string values.

Could this be called something like "SRS identifier"?

“Instance source URI”?

I think that's good, yes. "SRS" refers to something specific in the FOLIO context.

SRS (Source Record Storage) is very much aligned with MARC in FOLIO.
And several institutions do not use SRS, e.g. the German Library Networks

But won't eventually BIBFRAME be put into SRS?
Or possibly other formats?

Charlotte Whitt 9:51 AM
The Linked Data app does not store in SRS, but in something called GraphQL, and if using a 3rd party tool, then the storage would also be outside of FOLIO

Wayne Schneider 9:52 AM
Well, this is something very different, though -- it's an external source entirely

Stories

·       Used by developers to do the actual work. Usually have multiple stories.

Revisit/Update Charge
(if time allows)

Where does a statement like this belong? (Adapted from our conversation with the Product Council in November)

What do we mean by Open? We champion Linked Open Data. This is partly an ideological stance. But open also means choice of tools, options for integration, an environment in which we can experiment and are not bound to any specific framework.