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

[cmungall]

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:

• http://www.ebi.ac.uk/swo/SWO_0000001
• http://www.ebi.ac.uk/efo/swo/SWO_0000394

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:

• Update SWO metadata: clarify license, update description, mark inactive #1040.

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]

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"/>

• http://www.ebi.ac.uk/swo/swo.owl - 404
• http://www.ebi.ac.uk/swo/swo/releases/2022-10-11/swo.owl - 404

[allysonlister]

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]

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]

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]

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

[nlharris]

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]

@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]

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

Done, #2535

[cmungall]

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]

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

This is because

• Organizations: e.g http://www.ebi.ac.uk/swo/organization/SWO_9000019 ! European Bioinformatics Institute
• Maturity levels: e.g. http://www.ebi.ac.uk/swo/maturity/SWO_9000061 ! Development status
• Objectives: e.g. http://www.ebi.ac.uk/swo/objective/SWO_4000001 ! spreadsheet editing
• Licenses: e.g http://www.ebi.ac.uk/swo/license/SWO_1000001 ! Creative Commons
• Main namespace: e.g. http://www.ebi.ac.uk/swo/SWO_0000589 ! k-nearest neighbour classification