Provide cob-base and redirect cob-to-external.owl to it

[balhoff]

curl -L -O 'https://purl.obolibrary.org/obo/cob/cob-to-external.owl' returns 404.

[balhoff]

Seems like this happened before (#196). But I have been loading this into Ubergraph for a long while, and it just disappeared in the last few weeks.

[jamesaoverton]

I think you should use https://purl.obolibrary.org/obo/cob.owl instead. cob-to-external.owl doesn't make sense since #288. I can add a PURL entry to redirect that.

[jamesaoverton]

OBOFoundry/purl.obolibrary.org#1024

[jamesaoverton]

Longer explanation. Our src/ontology/cob-edit.owl file used to mint COB IDs for all sorts of terms, including perfectly good terms from other ontologies. We had a src/ontology/components/cob-to-external.tsv SSSOM file that would "rewire" those to use the external term IDs. At the COB Workshop in September 2024, we went through all our classes and decided whether to use a COB ID or an external ID. PR #288 reflected those decisions. This eliminated the need for cob-to-external.owl.

Further: the primary cob.owl that we published for years was the "rewired" version using the cob-to-external mappings: https://github.com/OBOFoundry/COB/blob/v2024-09-20/src/ontology/cob.Makefile#L48. So I think there was never really a need to use cob-to-external.owl. But I may be misunderstanding the Ubergraph use case?

[balhoff]

Thanks @jamesaoverton, that makes sense. Ubergraph is loading cob-base also, but I don't think it contains enough axioms, so I will load cob.owl. Unfortunately cob.owl will duplicate labels and definitions for external terms. I think for cob it would make sense to have a "base" file that injects relations such as electric charge SubClassOf characteristic. This is missing from cob-base. I want the axiom but not the PATO term annotations.

[jamesaoverton]

Ok, I can see how that would be useful for Ubergraph. We can create a new version of cob-to-external.owl for that.

I'm way over budget on my COB/OBO hours right now. Can anyone else take this on?

[balhoff]

Okay! No rush. I am loading cob.owl for now. I think these axioms should just be included in cob-base.

[matentzn]

@balhoff can you provide something more of a conceptual recipe for this?

Say we have

PATO:1 sub CHEBI:2 sub COB:3 - would I only include CHEBI:2 sub COB:3? And have PATO:1 floating? or directly under COB:3?

What about other axiom types (equivalence etc)?

[balhoff]

I think if an axiom is provided by COB, and the axiom is not provided by some other ontology, then it should be in the base file. So if PATO:1 sub CHEBI:2 is something COB gets from PATO, it shouldn't be included. But if it is an axiom the COB developers introduced, it should be included. This could be done by doing the automatic base then merging in the edit file.