COB Revised

[jamesaoverton]

This revision is based on the results of the September 2024 COB workshop.

Changes have not yet been vetted. We need to compare to the previously released cob.owl file and ensure that we aren't dropping any important terms.

The biggest change here is a src/ontology/cob-edit.tsv file, which is a ROBOT template that replaces cob-edit.owl. Given COB's small size and tight integration, I think that a template is a good choice for editing, but this needs discussion. I may have bent ODK conventions to the breaking point.

The src/scripts/split-cob-edit.py script splits the cob-edit.tsv into three "modules":

• BASE has only terms in the COB ID space
• FULL has all the BASE terms, and other OBO terms used to define them and fill out COB
• ROOT has all of FULL, plus "root" terms from various OBO ontologies, which demonstrate the interoperability of OBO

I think that the most controversial part of the current version is the 'REPLACED' and 'REPLACEMENT' object properties. I added temporary object properties such as 'has material part' with tight domains and ranges, and used these in the logical axioms of the terms in the sheet. The split-cob-edit.py script replaces these temporary object properties with existing object properties, such as RO 'has part'. The existing object properties may have domains and ranges that we were trying to leave out of COB, such as 'continuant'.

[jamesaoverton]

Looking at the diff, I already see some changes I want to make:

• remove obo:COB_module annotations from the OWL files
• figure out language tags for labels

[jamesaoverton]

@cmungall I'd appreciate your feedback on the overall approach here.

[cmungall]

I'm afraid I only have time now for a cursory look.

Minor: cob-to-external is now subsumed into cob-edit. This makes sense (we should make sure to sync docs in this PR or closely after). It looks like not everything is accounted for. E.g. we had a lot of narrow classes e.g ZFA roots. Maybe these are of less importance but I think we should have a trail here, maybe leave behind a rump cob-to-external with the entries not in cob-edit

Domains and ranges: we still need to solve this problem (#213). This PR improves over the current release (which actually injects domains and ranges that are too strict).

[jamesaoverton]

I made a few improvements:

• remove COB:module and COB:module_reason annotations
• obsolete some terms, based on discussions at the workshop
• restore some terms that were in the previous release -- these still need discussion and are marked as such in the cob-edit.tsv file
• restore some missing ontology metadata
• update the generated OWL files

@sebastianduesing Can you please sanity check the cob.owl, cob-base.owl and cob-root.owl files for me?

[sebastianduesing]

I went through those three files to check for the following:

1. All terms are in the right module(s).
2. The new terms are in the right modules and placed correctly in the hierarchy.
3. Expected metadata is present.

Everything looks good on points 1 and 2. While checking on point 3, I noticed a problem: cob-edit.tsv lists the ID of IAO:'definition' as IAO:0000015. This is actually the ID for IAO:'information carrier'. The correct ID for IAO:'definition' is IAO:0000115.

I think this mix-up started in the workshop Google Sheet; I've now fixed it there. Let me know if you'd like me to add a commit here to fix it in cob-edit.tsv. If there's anything else I should be checking for, just let me know of that too and I'll do another look-over.

[jamesaoverton]

Thanks @sebastianduesing! I think this is in good enough shape to share and discuss.

Still to do:

• discuss some remaining terms: marked as "TO DISCUSS" in cob-edit.tsv
• update documentation
• language tags for labels and definitions (a ROBOT template column either uses language tag or it does not, but the use of language tags in the source ontologies will be mixed, which could cause problems with false duplicates for labels and definitions)
• @cmungall's suggestion to trace dropped imports: while OBO is very strict that an ontology should never just drop its own terms (they should be obsoleted), I don't see a problem with dropping terms that we no longer want to import from another ontology, i.e. ZFA or XAO. I could be convinced otherwise.
• RO axioms that have domain/range constraints with BFO classes above the COB shoreline #213: sort out domains and ranges for imported relations

[matentzn]

Is the idea to hardcode whatever is needed from RO and OMO into COB templates?

[jamesaoverton]

In the short-term, yes: I only wanted very specific axioms and annotations from RO and OMO.

In the medium-term we need to import terms from many ontologies into COB, very carefully. I don't know exactly what we should do.

[jamesaoverton]

Direct links to download the OWL files:

• https://github.com/OBOFoundry/COB/raw/refs/heads/revised/cob.owl
• https://github.com/OBOFoundry/COB/raw/refs/heads/revised/cob-base.owl
• https://github.com/OBOFoundry/COB/raw/refs/heads/revised/cob-root.owl