Generalise QC check that ensures that all terms fall under preferred root

[matentzn]

If there is a preferred root declaration, then all terms in the base-namespace must fall under at least one class with a preferred root tag. See obophenotype/cell-ontology#725 (comment)

[gouttegd]

@matentzn Do you want to add that to the odk:validate command already used for #1175?

[matentzn]

Yes. i think as for the general pattern - we can try the feature in the ODK robot plugin, and if we think its useful, migrate it to ROBOT core?

[gouttegd]

we can try the feature in the ODK robot plugin, and if we think its useful, migrate it to ROBOT core?

Sounds good.

I think this should be the general pattern for ROBOT plugins:

(1) Is the command highly specific to one project?

Then make your own plugin. It’s easy, and we don’t want ROBOT to end up with a command for every single task imaginable (that was the mistake of OWLTools).

Typical examples would be Uberon’s uberon:merge-species and uberon:create-species-subset commands.

(2) Can the command be useful for a handful of projects?

Then maybe consider making a distinct plugin, that is not tied to any single project.

(3) Can the command be useful for many projects?

Then consider adding it to the ODK plugin – especially if you think that command should be used as part of any standard ODK workflow.

Once the command had been in the ODK plugin for a while (let’s say at least a full ODK major release cycle), consider submitting it to upstream ROBOT.

(4) Is the command intended to work around a bug in upstream ROBOT?

Then submit a proper fix to ROBOT first! And then only add the command to the ODK plugin (or any other plugin) as a temporary workaround that should be removed as soon as a version of ROBOT is available in which the bug is fixed.

Typical example would the current’s odk:normalize --merge-axioms true, which I hope to remove if/when ontodev/robot#1240 is merged (or ontodev/robot#1239 is fixed by any other means).

Likewise if the command implements a new feature that would fit nicely into one of the existing ROBOT commands (like odk:normalize --add-source, which I hope is a temporary workaround until ontodev/robot#1242 is merged).

[matentzn]

I agree, this is a great way to put it!

[gouttegd]

@matentzn How do you envision that check to interact with the COB alignment check?

I can imagine three possibilities:

(A) Completely independent checks

Checking that all terms fall the declared preferred root(s) (which I would henceforth call “self-alignment”) would be implemented in the same odk:validate command as COB alignment, but would work completely independently.

That is, odk:validate would have two modes:

• if an upper ontology is specified with the --upper-ontology (or --upper-ontology-iri) option, then the command checks alignment against the terms of that upper ontology;
• otherwise (no upper ontology specified), the command checks self-alignment.

To check both alignment against COB and alignment against preferred roots, just repeat the command, as in:

$ robot odk:validate --input my-ontology.owl --report-output self-align-violations.tsv \
        odk:validate --upper-ontology-iri http://purl.obolibrary.org/obo/cob.owl --report-output cob-align-violations

I think this would be the most useful and flexible (useful because flexible) approach.

(B) Check for alignment against either COB roots or preferred root(s)

The command behaves as if the preferred roots declared by the ontology were part of the upper ontology. That is, the ontology is considered “aligned” if all its classes are subclasses of any of the COB root class or any of the preferred roots.

This would allow any ontology to “circumvent” COB by using its own roots. Whether it is a good thing or not is an open question (I am inclined to think it would not be a good thing).

(C) Check for alignment against COB roots and preferred root(s)

The command checks that all classes are subclasses of a preferred root, and that the preferred roots themselves are subclasses of a COB roots.

In effect, quite similar to (A) (when calling the command twice to do both checks), but less flexible.