Add pipeline check for inferred equivalent classes within an ontology

[cmungall]

See for example
obophenotype/human-phenotype-ontology#522

Oort should already produce this report. Investigate options for making this more promiment

[cmungall]

PR for HP: obophenotype/human-phenotype-ontology#1031

@nicolevasilevsky can you start working on these:

https://github.com/obophenotype/human-phenotype-ontology/blob/9c36be164c2a85c09b492633b3b32bf0169448a7/src/ontology/reports/equivalentClasses.csv

[nicolevasilevsky]

what is the action item here? Is it to determine why these classes are considered equiv? For most of these, I think the logical definitions are the same, which is why they are being inferred as equiv classes.

[cmungall]

Yes, immediate action is to fix the logical defs. Remember, a bad axiom is often worse than no axiom.

[drseb]

Please do not just remove axioms. Checking the hierarchy and/or class merging also has to be considered

Sent from mobile

On 06.09.2016, at 21:41, Chris Mungall notifications@github.com wrote:

Yes, immediate action is to fix the logical defs. Remember, a bad axiom is often worse than no axiom.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[cmungall]

good point. Many of these are 'bad smells' indicating a need to merge. @drseb, how would you like to proceed? Should Nicole create a new ticket for each one of these, where we can give the +1/-1 on ways to proceed? That's how I would do it, but I'm a splitter when it comes to tickets, you may prefer to group.

…

On 6 Sep 2016, at 13:34, Sebastian Köhler wrote: Please do not just remove axioms. Checking the hierarchy and/or class merging also has to be considered

[drseb]

Ok. This is probably a good start:

• If the two classes are "highly similar" (read text-def) and one of them just needs another qualifier like progressive, localised, pathologic,... just add the qualifier. If the qualifier is not in PATO, but is a candidate for PATO, then let's discuss.
• If the two terms are highly similar, but one of them has a text-def that clearly separates him from the other term, and we don't have way to express this difference in OWL, remove the logical def of the more specific class. (Check set of ancestor classes)
• If the two classes are really equivalent, check the set of ancestors. If one of them has ancestors that should apply to the other class, then file an HPO-ticket.
• If the two classes are really equivalent, check the set of ancestors. If one of them INCORRECTLY has ancestors that the other does not have, then file an HPO-ticket.
• If the two classes are really equivalent (i.e. also have the 'same' set of ancestors) then merge them. (Please be very cautious with term merging as this has consequences for annotation data all over the world. Ask Peter, Chris, Melissa, or me for merge-instructions if you need a reminder)

Please handle them one-by-one and be verbose in commits. Maybe do only 5-10 per day such that I have a chance to check them (because I still have only limited time per day to work at the moment)

Let me know if I forgot something.

@cmungall @pnrobinson @mellybelly

[cmungall]

I am in perfect agreement. @nicolevasilevsky will you make a start?

[nicolevasilevsky]

I will! :)

[cmungall]

Robot should be used to report inferred equivalencies moving forward. Asking @dougl1sqrd if you have questions.

[cmungall]

is this done?

[nicolevasilevsky]

No, a lot of these tickets are still open. I'll look at these open tickets and see if I can move them along.