Consider adding example identifiers for ontologies in metadata

[cthoyt]

I'd like to propose we add a new optional field for the ontology metadata to store an example identifier.

It appears that the configuration files for the purl.obolibrary.org repository already contain example terms using the "short form" syntax, which is like a CURIE but with an underscore _ as the delimiter, so perhaps these could be taken in.

Here's an example for AMPHX: https://github.com/OBOFoundry/purl.obolibrary.org/blob/133f728664392330251717ee4c0f4564c0d1799b/config/amphx.yml#L11-L12

Related: I recently made a comment #400 (comment) on a thread talking about different properties of ontologies that could be used to classify them, potentially moving towards a real definition of "reference" vs. "application" ontology. Having this as a first class annotation of an example could address one of the issues that tells us if an ontology mints its own identifiers

[matentzn]

Not sure the redundancy is worth it. The preferredPrefix gives you all you need to know to construct a valid id, and any given ID constructed may be obsolete at some point in the future.. We should add stuff to the metadata only if a use case demands it; I would kinda prefer the identifier regex, but I am also happy if that lives in something outside like bioregistry.. What is the exact use case you are trying to address?

[cthoyt]

@matentzn you got me too fast! I just updated the text on the top to say this

Related: I recently made a comment #400 (comment) on a thread talking about different properties of ontologies that could be used to classify them, potentially moving towards a real definition of "reference" vs. "application" ontology. Having this as a first class annotation of an example could address one of the issues that tells us if an ontology mints its own identifiers

[jamesaoverton]

Note that the example_terms in the OBO PURL config files are not indented to be CURIEs. They are the Term ID part of the Term IRI, in conformance with the OBO ID Policy. You can see the current policy document here http://www.obofoundry.org/id-policy. I admit it's a bit confusing, because the PURL system was designed when a previous ID Policy document used this language explicitly.

[cthoyt]

Note that the example_terms in the OBO PURL config files are not indented to be CURIEs. They are the Term ID part of the Term IRI, in conformance with the OBO ID Policy. You can see the current policy document here http://www.obofoundry.org/id-policy. I admit it's a bit confusing, because the PURL system was designed when a previous ID Policy document used this language explicitly.

Thanks for the link. I wonder if there is a situation where one of the example terms can't be readily considered as a CURIE by replacing the underscore _ with a colon :. Maybe for APOLLO_SV this is an issue since the prefix itself contains the delimiter used?

[jamesaoverton]

My point is that the OBO PURL system was designed to fill a specific, narrow purpose. It converts the YAML config files into Apache .htaccess files. For example, it doesn't really know about the purl.obolibrary.org domain, so you can run it locally like http://localhost:8080/obo/OBO_0000070.

If you want to convert those example_terms to CURIEs, then I would suggest constructing an IRI by concatenating http://purl.obolibrary.org/obo/ with the Term ID OBI_000070 to get http://purl.obolibrary.org/obo/OBI_0000070, and then using the prefixes defined in obo_context.jsonld to convert that IRI to a CURIE. If that doesn't work, there's a bug somewhere.

[cthoyt]

The good news is there are provably no bugs in the obo_context.jsonld file, as demonstrated by this code running without printing anything:

import requests

URL = 'https://raw.githubusercontent.com/OBOFoundry/OBOFoundry.github.io/master/registry/obo_context.jsonld'
res = requests.get(URL).json()
for prefix, uri_prefix in res["@context"].items():
    if not uri_prefix.endswith(f"{prefix}_"):
        print(f"bug in {prefix}: {uri_prefix}")

So effectively, doing the operations you mentioned is the same as the string replacement, assuming that the the combination of the OBO ontology prefix and local identifier is more important than the specific OBO PURL (which for this use case, it is)

[balhoff]

There are serious bugs in the obo_context.jsonld, in that it is not usable for IRI shortening with JSON-LD: w3c/json-ld-syntax#329 😉

[jonquet]

FYI: MOD has included idot:exampleIdentifier for this purpose.
https://github.com/sifrproject/MOD-Ontology/blob/master/mod-v1.4_profile.rdfs#L903

This metadata field is not supper useful, although it could be sometime (e.g., to see a concrete example of how the URI of the ontology and the code/identifier of the term are actually appended to form a term URI)

@matentzn The preferred prefix is another metadata field in MOD. It "recommends" a prefix to use.
https://github.com/sifrproject/MOD-Ontology/blob/master/mod-v1.4_profile.rdfs#L779

[matentzn]

@balhoff what could we do to fix obo context? Tldr on that ticket you linked..

[balhoff]

@balhoff what could we do to fix obo context? Tldr on that ticket you linked..

I'll open another ticket.

[matentzn]

@jonquet thanks for these suggestions, I would have no objections to map the metadata elements in OBO to these properties if it does not disrupt any of the current OBO infrastructure (which I don't think it would)

[cthoyt]

Thanks everyone for the discussion. My ultimate goal was to make sure that Bioregistry could import OBO Foundry ontologies, including an example. Since it's required that OBO Foundry ontologies have PURL configuration and that it can be deterministically accessed via URL, my original goal is solvable without making any convolution of concerns.