jsheunis
commented
1 year ago Another idea:
The schema can accept additional fields without failing to validate. This means that metadata containing new fields can be passed to the catalog without having to update the catalog schema. If e.g. an extra property additional_display_definitions is passed, where this is an object providing semantic definitions of the keys and values in additional_display, these definitions could be rendered in the catalog as extra information.
For example, let's say we have additional_display property of a dataset-level metadata item:
"additional_display": [
{
"name": "SFB1451",
"icon": "fa-solid fa-flask",
"content": {
"homepage": "https://github.com/allisonhorst/palmerpenguins",
"CRC project": "INF",
"data controller": {
"email": "ahorst@ucsb.edu",
"name": "Allison Horst"
},
"sample (organism)": [
"Adelie penguin (Pygoscelis adeliae; NCBITaxon_9238)",
"Gentoo penguin (Pygoscelis papua; NCBITaxon_30457)",
"chinstrap penguin (Pygoscelis antarcticus; NCBITaxon_79643)"
],
"sample (organism part)": "body proper (UBERON_0013702)",
"Used for": "Testing effort for DBI backends \u2014 The dataset is used as example data for testing data base backend features in automated tests (https://dbitest.r-dbi.org/)"
}
}
],then the agent creating this metadata item could also include another property additional_display_definitions:
"additional_display_definitions": [
{
"name": "SFB1451",
"keys": {
"homepage": "https://schema.org/mainEntityOfPage",
"CRC project": "",
"data controller": {
"self": "https://w3id.org/dpv#hasDataController",
"email": "https://schema.org/email",
"name": "https://schema.org/name"
},
"sample (organism)": "",
"sample (organism part)": "",
"Used for": "http://www.w3.org/ns/prov#hadUsage"
},
"values": {
"homepage": {},
"CRC project": {},
"data controller": {
"email": {},
"name": {}
},
"sample (organism)": {},
"sample (organism part)": {},
"Used for": {}
}
}
]Both keys and values are included above, since either or both could have semantic definitions. But it's not expected that both or either would always be provided or necessary.
mslw
It would be ideal if datalad's whole metadata handling and rendering stack could work with JSON-LD data in a seamless way.
An example use-case is the tabby-to-catalog pipeline: if we have JSON-LD records coming out of
tabbyfiles, how do we handle these records in order to have the rich semantic information rendered sensibly in a catalog?Let's use the current catalog schema, here a part of the specific schema for a dataset, as an example to work from:
The dataset schema has several properties that can be contained in an incoming metadata record, and a minimal amount of properties are required. There are properties that expect specific fields and formats (e.g.
author, which should havegivenName,familyName, etc) and there are properties that can receive generic key-value pairs (e.g.additional_displayandtop_display).How should we approach updates to such a schema in order to allow JSON-LD data through
Idea 1
If we want to define catalog schema terms ourselves, i.e. turn it into a semantic schema, we could for example add a
definitionfield to each property which would contain a definition URL from some accessible ontology.Idea 2
We could add another generic key-value property to the schema, something like
semantic_metadata, which would allow for passing the term definitions along with the key and value, for multiple records. This could then get a dedicated display area in a catalog's dataset page.Idea 3
Perhaps the catalog should somehow evolve into something that can just interpret and render any JSON-LD document, or at least those adhering to some convention as described by a given context. This whole concept needs further exploration, and possible a paradigm shift in terms of how metadata is added to a catalog and rendered by it.