Subjects - schemeURI: encourage use of versionIRIs of controlled vocabularies, ontologies, subject schemes and the like

[SArndt-TIB]

What is the problem that your suggestion solves?

Ontologies, controlled vocabularies and other terminological resources may change over time. It may be helpful to add version info to the subject terms from such terminological resources, so that it is transparent what version of a term a resource refers to.

What solution might meet your needs?

There are several options:

• Update the documentation of the DataCite Metadata Schema for schemeURI so that it recommends to provide the versionIRI of an ontology/ controlled vocabulary whenever possible, instead of just its IRI. The documentation could also add some more examples for schemURIs that use versionIRIs.
• it may be useful to distinguish between a vocabulary's canonical IRI and the its version IRI, it may be an option to introduce a new subfield to DataCite subject, so that users can distinguish between the schemeURI of a subject and the schemeVersionURI of a subject

Your name

Susanne Arndt

Your organization

Technische Informationsbibliothek

What alternatives have you tried or considered?

versionIRIs for terms, but this is not feasible

Is there anything else you would like to share?

No response

What group(s) would benefit from your suggestion?

• DataCite members registering DOIs and metadata and administering accounts
• Developers building integrations with DataCite services
• Harvesters who index DataCite DOIs and metadata
• Individuals or institutions analyzing DataCite DOIs and metadata
• DataCite staff
• Other

If other group(s), please describe.

users of DataCite metadata

[rebeccaringuette]

This same concern is also becoming an issue for our efforts in NASA Heliophysics to incorporate controlled vocabularies and taxonomies.

[allysonlister]

Hi there! A related suggestion from me, thank you:

I was hoping to re-use DataCite's resource types for our own purposes (tagging our content in FAIRsharing) for model and outputmanagamentplan. However I can only presume the 'official' IRIs for these resource types are not the readthe doc links I have found, and was wondering what IRIs should be used to unambiguously references these types? I've discovered https://schema.datacite.org/meta/kernel-4/include/datacite-resourceType-v4.xsd but there is no apparent IRI I can use to reference these resource types.

That leaves us with two options:

1. Use an alternative terminology: possible, but as DataCite is so prevalent in the community, not ideal.
2. Use a 'placeholder' URL such as https://datacite-metadata-schema.readthedocs.io/en/4.6/appendices/appendix-1/resourceTypeGeneral/#outputmanagementplan which is also not ideal.

I feel linking to a readthedocs page isn't the right idea for what we want, so it's likely that for now, at least, we will be going with solution 1. Thank you for providing such a great resource and I hope I can make more use of it in future!

[KellyStathis]

Thanks for this suggestion, @allysonlister! There's another suggestion for a DataCite ontology here: #148. In your case, are you primarily interested in having the term IRIs?

[allysonlister]

Yes that is my primary interest; I'm also in agreement with what @graybeal says in that thread at #148 (comment)

While term IRIs are what I'd like, I'm agnostic about the format - whatever works best for you but one of RDF, OWL, Turtle, SKOS would all be good.

I note that @selgebali (hi there!) mentions a number of external-to-datacite (AFAIK) terminologies that provide persistent IRIs for DataCite terms at #148 (comment). The main issue with this, and why I don't use them, is twofold:

1. because they are not official terminologies, they are harder to find
2. more importantly, because they are not official (AFAIK) terminologies, there is no presumption of persistence or longevity from my point of view. I don't want to implement a version that isn't officially recognised and might not be here next year.

Thanks!

[KellyStathis]

Thanks for this suggestion, @SArndt-TIB! You can definitely use a version-specific schemeURI in the Subject property. We can also look at adding some examples of this.

Out of curiosity, what controlled vocabulary(ies) are you using that you are hoping to include in the Subject property?

[SArndt-TIB]

None in particular, @KellyStathis - this is just a general concern, that it may be useful to relate back to a particular version than just the latest one.

[rebeccaringuette]

I have an example for this. Take the Unified Astronomy Thesaurus https://astrothesaurus.org/. This is a thesaurus of terms relevant to Astronomy, Space Physics, and Solar Physics. Any of the terms (e.g., solar flares) is likely to have the definition updated over time as our understanding of the science progresses with new research. However, this also means that a term used from an earlier version of the UAT in DataCite metadata for a dataset may not have the same meaning as a term in a later set, so being able to indicate the version of UAT (currently 5.1) would be advantageous to maintaining accurate metadata. @rmcgranaghan

[stephw-tib]

Thanks for raising this, and for the concrete examples in this thread.

As part of work within PID4NFDI https://pid.services.base4nfdi.de/ , we are publishing the DataCite terms as linked-data artifacts (classes, properties, vocabularies) with resolvable IRIs and distributions (JSON-LD/Turtle/RDF).

Where this still needs design input is whether documentation guidance is enough, or whether a dedicated field (for example a scheme version URI) would materially improve interoperability and downstream reuse. We’d be very interested in getting your input. Please provide your feedback while the RFC is still open https://github.com/datacite/schema.datacite.org-linked-data.
I am looping in @selgebali as she did this work and can answer further questions.

[allysonlister]

Thanks this is just what would be useful for us! for example, output management plan would have an identifier of https://schema.stage.datacite.org/linked-data/vocab/resourceTypeGeneral/OutputManagementPlan

[graybeal]

I don't know if this general response is useful, but here goes. (Regarding the original post to use versioned IRIs for the terms of an ontology--note, not just the ontology itself. More recent comments are about #148 and I'll respond to them on that thread.)

When we designed the MMI ontology repository 20+ years ago (?!), Luis Bermudez and I designed the IRIs to have two forms: (1) version-embedded (using a timestamp as the version indicator), and (2) unversioned. So someone could access each term either way. And we definitely tracked ontology versions, so you could at least compare across versions. Alas, we didn't have the political skill to get funding to take advantage of that cleverness, so although we've managed to persist the repo (at https://mmisw.org/) it isn't in common use today and can't leverage that design.

Through this we found that experts were divided—some loved versioned terms because it could 'lock in' meaning; others felt that semantic identifiers shouldn't be used and that once minted, an identifier's basic meaning should never change, so versioning shouldn't be a thing. More recently many principled ontology developers have started identifying when each change is made to an ontology term—but still without versioning the term. But at least if you know when the term was used, you have a fair idea of what its state was at the time.

There are more subtleties to consider. If some term (or lots of terms) in an ontology changes, should all the terms be reversioned? Rigorously speaking, I'd say yes, because the context of the entire ontology changes with any change to its content. But if you're changing the ontology regularly, now you'll have multitudes of identifiers for what is essentially a single term. Tracking those relationships is going to be miserable for all the tools that are trying to figure out what is (related to, sameAs, almost sameAs) what else.

To achieve the same goal today, my recommendation would be treating each major change to the ontology as deserving a different ontology ID, as with DC and DCTerms. This effectively gives new identifiers to all the duplicate terms that are carried over. But as that community knows, that distinction creates its own confusion, as non-experts try to keep everything straight while ontologists try to keep it all rigorous. You can have both at the same time if you're particularly clever, but I think that just gets you both the best, and the worst, of both worlds.

[rebeccaringuette]

Maybe it is enough to encourage the use of versioned IRIs if they exist, and leave the convention of whether a version is used (or not) to the people that manage the ontology.

[SArndt-TIB]

Hi @graybeal , thanks for your comments. My original post would expect something like this, which would already be doable with the schema as is, if you put the owl:versionIRI of the ontology or the vocabulary (not of terms!) into the schemUri and use the canonical identifier of the term. That would introduce the same problem of aggregating information about the scheme, I guess. It would, however, enable to look up the particular record about that entity at the time it was attached as a subject to a resource, since we expect the versions to remain accessible and the versionIRI to be resolvable. I did not necessarily mean to have versioned identifiers for a term.

  "subjects": [
    {
      "subject": "http://purl.obolibrary.org/obo/AGRO_00000015",
      "subjectScheme": "conventional tillage process",
      "schemeUri": "http://purl.obolibrary.org/obo/agro/releases/2022-11-02/agro.owl",
      "valueUri": "http://purl.obolibrary.org/obo/AGRO_00000015",
    }
  ],

The question is whether the documentation should encourage or discourage this usage.

[selgebali]

Hi folks,
Thank you so much for all of your input, and as I am currently working on the versioning strategy models, I wanted to share the one I am considering for the linked-data namespace, because I think it addresses part of the concern here while keeping the namespace manageable.

My current proposal is:

• keep canonical DataCite term IRIs stable across releases
• publish a new frozen versioned snapshot for each schema release, for example 4.6, 4.7, etc.
• maintain a separate current/latest pointer for clients that just want the default current release

So for a DataCite term such as subject, the canonical IRI would stay the same. What changes from release to release is not the term IRI itself, but the versioned manifest/distribution that contains and describes that term.

In other words:

• canonical IRI = stable identifier for the DataCite term
• versioned snapshot = exact release-specific description of that term
• current pointer = convenience entry point for “latest”

This means I am not proposing versioned per-term endpoints. I am proposing versioned release artifacts.

An important implication is that a machine cannot recover exact DataCite-version provenance from the canonical IRI alone. If a client stores only the stable DataCite IRI for subject, and later dereferences it, it will get the current/latest meaning. It will not automatically know whether the original usage was based on 4.6 or 4.7.

So if exact DataCite-version provenance matters, the client needs to persist one more piece of information alongside the stable IRI, for example:

• the DataCite schema version, such as 4.6
• or the versioned snapshot IRI, such as the datacite-4.6 manifest/distribution

I also want to distinguish this from the Subject property discussion itself:

• schemeUri is about the external subject scheme / ontology / vocabulary from which the subject term comes
• so schemeUri can be used to point to the relevant version of that external scheme
• but schemeUri does not by itself express which DataCite schema version was used

So there are really two separate versioning questions here:

1. Which version of the external subject vocabulary was used?

This can be expressed via schemeUri when the vocabulary provides a versioned IRI.

2. Which version of the DataCite schema was used?

This needs to be captured separately if exact DataCite-version provenance is required.

For me, the advantage of this approach is that it gives us:

• stable DataCite term IRIs
• frozen historical release snapshots
• a latest-version pointer for convenience
• no need to mint new IRIs for every term on every schema release

But the tradeoff is that exact DataCite-version provenance is only available if the consuming system stores version context in addition to the canonical DataCite IRI.

Without explicit DataCite version info
This records the subject term and the external subject scheme version, but not which DataCite schema version was used.

{
"subjects": [
{
"subject": "Solar flares",
"subjectScheme": "Unified Astronomy Thesaurus",
"schemeUri": "https://astrothesaurus.org/releases/5.1/uat",
"valueUri": "https://astrothesaurus.org/uat/1496"
}
]
}

What this tells a machine:

• the subject is Solar flares
• the term came from the UAT
• the UAT version used was 5.1
• but it does not say whether the surrounding record was created against DataCite 4.6 or 4.7

With explicit DataCite version info
DataCite metadata itself does not currently have a standard field for “DataCite schema version used for this record”, so this would need to be carried separately by the application, profile, wrapper, or processing context.

Example wrapper object:

{
"dataciteSchemaVersion": "4.6",
"dataciteSchemaSnapshot": "https://schema.stage.datacite.org/linked-data/dist/datacite-4.6.jsonld",
"metadata": {
"subjects": [
{
"subject": "Solar flares",
"subjectScheme": "Unified Astronomy Thesaurus",
"schemeUri": "https://astrothesaurus.org/releases/5.1/uat",
"valueUri": "https://astrothesaurus.org/uat/1496"
}
]
}
}

What this tells a machine:

• the DataCite term structure should be interpreted in the context of DataCite 4.6
• the subject term itself comes from UAT 5.1

If you want to show the distinction even more clearly
You can present it like this:

{
"datacite": {
"schemaVersion": "4.6",
"schemaSnapshot": "https://schema.stage.datacite.org/linked-data/dist/datacite-4.6.jsonld"
},
"subjects": [
{
"subject": "Solar flares",
"subjectScheme": "Unified Astronomy Thesaurus",
"schemeUri": "https://astrothesaurus.org/releases/5.1/uat",
"valueUri": "https://astrothesaurus.org/uat/1496"
}
]
}

That makes the two versioning layers very visible:

• schemeUri = version of the external subject vocabulary
• schemaVersion / schemaSnapshot = version of DataCite itself

Finally, please checkout the work itself: https://github.com/datacite/schema.datacite.org-linked-data and maybe we can move the discussions there.

[SArndt-TIB]

Thanks for sorting this discussion out so nicely, @selgebali 😃

[rebeccaringuette]

There is already a "schemaVersion" field in DataCite XML and JSON output (e.g., https://commons.datacite.org/doi.org/10.48322/6cfb-rq65). However, the entries into this field are not version specific as "http://datacite.org/schema/kernel-4" and "http://schema.datacite.org/meta/kernel-4/metadata.xsd" resolves to the latest versions only. Perhaps the entry into these fields becomes version specific? It would also be useful to add this field to the DataCite documentation.
On the related topic, specifically the request to indicate the version of a taxonomy or dictionary a term was sourced from, perhaps adding an optional "schemaVersion" field into the Subject object would be simple enough to support current usage, borrow from current usage, and improve the desire to specify more details?

[graybeal]

First: Overall everything here is top-notch, lots of great work to bring this into existence.

So testing my understanding of your excellent description, and offering comments based on that understanding. My discussion focuses specifically on DataCite vocabulary terms (like ResourceTypeGeneral/Book) used to describe a digital artifact.

Let me know if you want me to move my 3 notes to separate tickets.

If I am using a DataCite metadata schema to define my metadata, I will have declared which (versioned) schema (e.g., 4.6) I am using inside the metadata instance, and so my use of ResourceTypeGeneral/Book will follow the context of version 4.6 and that's the corresponding definition that applies. I can't access the 4.7 version of the vocabulary until I change my DataCite metadata schema. (Is that right? Or is it possible for a metadata instance to be silent about which schema version it is following?)

If I am using some other metadata schema but want to use a DataCite-compatible metadata attributes, I will define a schema appropriately. So references for a certain 'resourceType' field would constrain values to only DataCite ResourceTypeGeneral values. Assuming my template schema uses semantic IRIs to constrain the category values, there are two possibilities here as to what is needed: (A) an IRI for a fixed list of possible values that will never change because it's versioned, or (B) an IRI for an always-current list of possible values.

In one sense, I can specify either of those, because there's a version-specific dist/ for the ontology files (https://github.com/datacite/schema.datacite.org-linked-data/blob/main/dist/datacite-4.6.ttl) and a non-version-specific JSON-LD file for the specific concept (https://github.com/datacite/schema.datacite.org-linked-data/blob/main/vocab/resourceTypeGeneral/resourceTypeGeneral.jsonld). But the latter is not the whole ontology,

Note 1: Is there a fixed IRI location where the latest ontology will be publicly maintained? (This would ideally be where the namespace resolves as well, crudely speaking.) If I'm missing it my apologies. Otherwise I'd like to suggest a non-versioned set of distribution files, a la https://github.com/datacite/schema.datacite.org-linked-data/blob/main/dist/datacite.ttl | rdf | jsonld. (If I am trying to always present the latest version of the ontology in a tool like BioPortal, or refer to it in a blog post, I expect to be able to specify the 'latest-greatest' location just once, and the file at that location will be updated whenever the vocabulary changes.)

Note 2: It seems the dist/ files are not self-identifying, in that once the contents are downloaded, you can not tell from the contents what you have. As a general rule ontologies do contain their own version identification and other self-describing metadata, for all the usual FAIR reasons. (See MOD, recommend at least the 2.0 version.) Even/especially in the 'non-versioned' or most recent ontology, showing the actual version number is important for downstream applications and repositories.

Note 3: A minor thing, but ideally the namespace embedded in each term could be specified as the default namespace in the TTL (and will eventually be resolvable for the ontology and its terms).

(Now returning to my understanding of how this could work.) Then finally, because CEDAR relies on an intermediary (BIoPortal) to support any term lookup needs, if someone wanted to refer to a specific version of the ontology in BioPortal, they would want to need to upload that specific (4.6) version as something like DATACITE-46 (similarly to ICD9, ICD10). Otherwise to use the always current version they would go to the general DATACITE listing. Does that work for you?

[selgebali]

Hi John!
Thank you, this is very helpful!! and I think we are broadly aligned.

I have now updated the repo so that the namespace exposes both:

• frozen versioned distributions such as datacite-4.6 and datacite-4.7
• a moving non-versioned full distribution for the latest release, exposed as datacite.jsonld / datacite.ttl / datacite.rdf
• I am keeping datacite-current as an explicit machine-readable pointer, while datacite.* is now the actual latest full ontology payload.

That means the model is now:

• canonical term IRIs remain stable
• versioned release artifacts remain frozen
• datacite.* always resolves to the latest full ontology
• datacite-current.* continues to indicate what the current default target is

On your Note 2: the versioned distribution files now include ontology-level metadata such as identifier, title, source, created date, license, and owl:versionInfo, so they are self-identifying once downloaded. I agree this is important for FAIR downstream use.

On your BioPortal/CEDAR example: yes, that understanding works for me. A consumer that wants a fixed release can use the versioned distribution directly, while a consumer that wants “always current” can use the non-versioned datacite.* location.

I hope this helps and please do let me know if you have planned implementation in mind.

[graybeal]

So are there versioned term IRIs also, or does the user access that through a complex term object as previously discussed? I think an equivalent question is, does the namespace of the ontology (and hence the terms) remain the same across all the distributions, or does it change for datacite-4.6 vs datacite-4.7?