search

OBOFoundry / OBOFoundry.github.io

Metadata and website for the Open Bio Ontologies Foundry Ontology Registry
http://obofoundry.org
Other
165 stars 202 forks source link

jsonld context entry for SWO is incorrect, as SWO does not use OBO PURLs #2307

Open cmungall opened 1 year ago

cmungall commented 1 year ago

Noticed by @wdduncan:

The OBO metadata pipeline assumes all PURLs registered are OBO PURLs. This is generally a good assumption

However, SWO is registered and uses its own ebi.ac.uk namespace

This means that the entry in http://purl.obolibrary.org/meta/obo_context.jsonld is incorrect

curl -L -s http://purl.obolibrary.org/meta/obo_context.jsonld | grep -A1 -B2 SWO
        "SPD": "http://purl.obolibrary.org/obo/SPD_",
        "STATO": "http://purl.obolibrary.org/obo/STATO_",
        "SWO": "http://purl.obolibrary.org/obo/SWO_",
        "SYMP": "http://purl.obolibrary.org/obo/SYMP_",

however, if you try URLs like http://purl.obolibrary.org/obo/SWO_0000001 they don't resolve

However, SWO URIs are of two forms:

the latter does not resolve

sqlite> select count(*) from node where id like '<http://www.ebi.ac.uk/efo/swo/SWO%';
710
sqlite> select count(*) from node where id like '<http://www.ebi.ac.uk/swo/SWO%';
861

The mistake in the OBO metadata propagates up to bioregistry. I would rather fix this at source here.

If we wish to allow non OBO PURLs then we need a new field for namespace_uri in the obo metadata - this would only be filled in for ontologies like SWO (possibly FMA in future). For SWO we'd ask to pick one of the two forms above, I assume the variance is a mistake.

Note that we have a separate discussion going with @allysonlister about SWO here:

Unfortunately it presents other issues due to differences in licensing. One option here is to have a special status for SWO (and perhaps FMA, see #21) that grandfathers it in as an ontology of interest but allows it to be treated differently for purposes of metadata and PURLs

cmungall commented 1 year ago

also, as an aside, the actual ontology and version IRIs used in SWO are not OBO PURLs, but only the OBO purls are resolvable..

curl -L -s http://purl.obolibrary.org/obo/swo.owl | grep -A1 '<owl:Ontology'
    <owl:Ontology rdf:about="http://www.ebi.ac.uk/swo/swo.owl">
        <owl:versionIRI rdf:resource="http://www.ebi.ac.uk/swo/swo/releases/2022-10-11/swo.owl"/>
allysonlister commented 1 year ago

Thanks for this ticket! It is tricky - and results from the age of the ontology. It was originally created by people from the EBI, and therefore the IRIs were generated from there.

The fact that there are still efo-based IRIs shows that the work I did in this ticket a few years ago wasn't complete.

As we decided back then that efo-based IRIs were a mistake and could be resolved, I'm happy to do that check again and remove those. I'll make a ticket in the swo repo for that. A quick look at the ontology shows that it seems back when I made that ticket, I missed the non-class efo-based IRIs, and there are now a few individuals and properties that still have them.

However, that still doesn't resolve the issue of not having purls. Is there some way I can refactor the ontology to use standard purls but still have the old EBI IRIs resolve? I still get SWO being cited by a number of publications through the year, so it is still being used and this would be a big change.

cmungall commented 1 year ago

Thanks!

Is there some way I can refactor the ontology to use standard purls but still have the old EBI IRIs resolve

That would be a question for EBI, as they are in control of http://www.ebi.ac.uk/swo/

or you could simply make a new release of SWO at the old namespace consisting solely of obsolete URIs with term-replaced-by to the new ones. There is potential for confusion here though.

But the more disruptive part is that users of SWO who don't use CURIEs will have to update all their URIs. There are tools to do this but this may still be a big upheaval if the ontology has been widely used.

Before embarking on this big change I'd recommend seeking clarification on a few questions:

  1. can exceptions to PURL policy be made on the OBO side? I would say yes, given that we already accepted the ontology, it's unreasonable of us to suddenly say, "oh we made a mistake and didn't check your PURLs, now make this hugely disruptive change or you're out", but there may be other perspectives
  2. does using OBO PURLs provide any advantages to your users or you as a maintainer? (I can see some maintenance advantages in that you are not tied to EBI)
  3. Does being listed in the OBO site give you any advantages, or is SWO happy to sit to the side? If the former then I'd start seeking clarification on your license issue too....
allysonlister commented 1 year ago

This release of SWO completes the refactoring: https://github.com/allysonlister/swo/releases/tag/v2023-03-05

Just over 50 IRIs were refactored; all other 'efo' IRIs in SWO are already obsoleted - just check their owl:deprecated flag.

That part of the work is done. I'm still not sure what to do about an overall change to OBO purls. I like the idea conceptually, but worry it might cause issues for users.

matentzn commented 1 year ago

We should probably capture a new property in the OBO metadata, baseiri which describes overwrites the standard OBO purl system.

nlharris commented 1 year ago

Maybe we should close this issue as fixed and open a new issue with Nico's point above:

We should probably capture a new property in the OBO metadata, baseiri which describes overwrites the standard OBO purl system.

cthoyt commented 10 months ago

@udp this issue is related to you asking for more explicit annotation of OBO URI format strings, since not all of the OBO Foundry ontologies actually use OBO PURLs! CHEMINF is another example besides SWO

nlharris commented 7 months ago

Maybe we should close this issue as fixed and open a new issue with Nico's point above:

Done, #2535

cmungall commented 2 months ago

I'm reopening this:

✗ curl -L -s http://purl.obolibrary.org/meta/obo_context.jsonld | grep -A5 -B5 SW
        },
        "STATO": {
            "@id": "http://purl.obolibrary.org/obo/STATO_",
            "@prefix": true
        },
        "SWO": {
            "@id": "http://purl.obolibrary.org/obo/SWO_",
            "@prefix": true
        },
        "SYMP": {
            "@id": "http://purl.obolibrary.org/obo/SYMP_",
            "@prefix": true
cmungall commented 2 months ago

In fact this is even more complicated as we can't make a single prefix for SWO

This is because