Deprecate entity using GO profile is adding axioms into an imported file

[anitacaron]

I tested the functionality using CL Ontology.

As you can see in the screenshot below, the annotations added as part of the deprecation workflow are added to the cellxgene_subset instead of in the main file.

[gouttegd]

This is not specific to the GO profile. The same thing happens with other profiles as well.

This is because the cellxgene_subset component contains not only the oboInOwl:inSubset annotation axioms, but also declaration axioms for every concerned classes.

When deprecating an entity, to determine in which ontology the annotation axioms should be added, Protégé is looking for an ontology that:

• contains the to-be-deprecated entity in its signature, and
• contains a declaration axiom for the to-be-deprecated entity.

The first ontology that matches those criteria is used. But we don’t control the order in which the ontologies are tested (they are stored in a Set, which does not guarantee any particular iterating order), so if both the “main” ontology (in the present case cl-edit.owl) and one of its imports happen to contain declaration axioms for the to-be-deprecated entity, it may very well happen (as it indeed does happen here) that the import, rather than the main ontology, will be picked.

Not sure we can do anything about that. Apart from using the presence of declaration axioms, I can’t think of any foolproof heuristic that would be guaranteed to always identify the “correct” ontology in which the deprecation axioms should belong.