align imports from omo and iao

[stap-m]

Description of the issue

Related to #1738

Several classes are imported twice from (1) IAO and from (2) OMO. This should be cleaned up.

ToDos:

• [x] check, whether IAO and OMO import eachother
• [x] check which of our imported classes originate in IAO
• [x] check which of our imported classes originate in OMO

Ideas of solution

Provide a list, which classes should be imported from which ontology. Sort out the imports accordingly.

Workflow checklist

• [ ] I discussed the issue with someone else than me before working on a solution
• [ ] I already read the latest version of the workflow for this repository
• [ ] The goal of this ontology is clear to me

I am aware that

• [ ] every entry in the ontology should have a definition
• [ ] classes should arise from concepts rather than from words

[viktorwichern]

Okay, so I checked the BFO, IAO and OMO imports. As far as I've seen, three BFO classes are contained in the other imports: BFO_0000001 (entity) --> contained in IAO BFO_0000002 (continuant) --> contained in IAO BFO_0000031 (generically dependent continuant) --> contained in IAO and OMO

If I'm not mistaking, the OMO import is completely redundant. It only contains three classes: BFO_0000031 (generically dependent continuant) IAO:0000030 (information content entity) IAO:0000027 (data item) all of which are already either in the BFO or imported IAO. The ONLY thing that I could find our OMO import has and the others don't is two annotation properties: may be identical to ontology term requester

Annotation properties which are in both BFO and imported IAO: BFO:0000180 (BFO CLIF specification label) BFO:0000179 (BFO OWL specification label) curator note definition definition source editor note editor preferred term elucidation example of usage has associated axiom(fol) has associated axiom(nl) owl:backwardCompatibleWith owl:deprecated owl:incompatibleWith owl:priorVersion owl:versionInfo rdfs:comment rdfs:isDefinedBy rdfs:label rdfs:seeAlso term editor

[h-spinde]

Agreed on the OMO being redundant. There are some OMO specific classes, but none of them are being used in the OEO, and "may be identical to" as well as "ontology term requester" are actually contained in the newest IAO. (The IAO import also seems to include a few BFO classes that are never actually used at all, such as "obsolete dependent continuant" (BFO_0000005), so we might want to clean that up as well.) Edit: Just saw that the classes I mentioned are already removed in the new import.

[l-emele]

Quote from OMO:

An ontology specifies terms that are used to annotate ontology terms for all OBO ontologies. The ontology was developed as part of Information Artifact Ontology (IAO).

So we should only expect OMO to contain annotation properties that are not in BFO or IAO.

[stap-m]

Edit: Just saw that the classes I mentioned are already removed in the new import.

You are referring to the updated extract-iao-module.sh in oeo-tool repo in branch feature-tidy-iao-import, right?

[stap-m]

If I'm not mistaking, the OMO import is completely redundant. It only contains three classes:

Agreed on the OMO being redundant. There are some OMO specific classes, but none of them are being used in the OEO, and "may be identical to" as well as "ontology term requester" are actually contained in the newest IAO.

So we should only expect OMO to contain annotation properties that are not in BFO or IAO.

The IAO Readme states, that IAO fully imports OMO already. Thus, I'd propose to only import from IAO.