obophenotype / upheno

The Unified Phenotype Ontology (uPheno) integrates multiple phenotype ontologies into a unified cross-species phenotype ontology.
https://obophenotype.github.io/upheno/
Creative Commons Zero v1.0 Universal
76 stars 17 forks source link

Alternate strategies to avoid ontology conflation, make MP and HP siblings #171

Open cmungall opened 8 years ago

cmungall commented 8 years ago

to avoid #169

we could mint upheno classes that are superclasses of MP/HP. This means rather than

MP:abnormal-X Equiv HP:abnormal-X

which is very powerful axiomatically, which has the downside of increasing likelihood of errors

Instead we would have

UPHENO:<new> abnormal-X
   MP:abnormal-X (mouse)
   HP:abnormal-X (human)

(we could affix labels, similar to what we might do for genes)

We would not place any inferences into sources; all inferences would be within upheno or linking upheno to sources.

This would allow simple filtering to see unmodified MP or HP

alternative

alternatively we could mark axioms with their provenance and allow selective propagation. But this is hard for multiple reasons, and will require changes to scigraph and the golr loader.

Thoughts from all welcome, esp @drseb

drseb commented 7 years ago

I like the idea.

Question: a user is looking at the page for "Macular dystrophy (human)". From a UI-perspective it might be hard to make clear that now only human genes/variants are shown and the user has to actually click something to get inferred genes/variants from mouse. How would you imagine this?

Looking at your example:

UPHENO:<new> abnormal-X
   MP:abnormal-X (mouse)
   HP:abnormal-X (human)

What are the MPs and HPs here? Xrefs? Subclasses?

cmungall commented 7 years ago

In this proposal MP and HP are subclasses of the UPHENO.

You are correct about the UI

cmungall commented 7 years ago

We could also include 'homology' links between MP-HP-WBPhenotype etc, this would facilitate easier navigation in the UI, rather than hop-up-hop-down

cmungall commented 7 years ago

Another difficulty: currently the official OWL defs for species-specific ontologies use species-neutral ontologies (GO, CL, Uberon, CHEBI). We would need to either:

The injection step is not appealing as it could create confusion having two different official OWL defs. For the DPs, it would be tedious to manually have to add the clause each time (though less of a problem if we are generating from csvs).

cmungall commented 7 years ago

For the algorithm that builds the species-neutral grouping classes:

  1. For all ss ontologies, For each ss class C, generate a sn class C': remove taxon clause and modify labels to disambiguate
  2. Run reasoner and merge equivalence cliques. Note it is impossible for this step to merge to ss classes from different ontologies. This will only merge two sn classes, or a sn class into a ss class (where in-taxon=human)
  3. Remove any sn class that is not the inferred MRCA of two sn classes from two distinct species.
matentzn commented 6 years ago

I very much support all suggestions here. I know UI/application is a concern, but the transformation required from this model proposed here to the one needed does not sound like something a little generic script cant handle. I will start running some tests with beginning September.

We need to carefully consider the "homology" question. @dosumis suggests to interpret UBERON classes by default as implicit homology mappings (which has its own problems: we can never guarantee that direct subclasses of an UBERON class conform to the same conceptual level of abstraction, think this model:

HP:Arm sub UBERON:limb MP:Right Arm sub UBERON:limb (Right arm different level of abstraction from arm) MP:Manus sub UBERON:limb

I guess that according to @dosumis suggestion, UBERON:limb cannot be a homology class; so it will be tough to weed out all the UBERON classes that should not be viewed as homology groupings. But - maybe NOT! We will find out :) (Now that I think of it: maybe homology classes in UBERON can be restricted to all those classes that are conceptual (and actual) LEAVES of the UBERON class graph)

cmungall commented 6 years ago

I suggest not complicating this further with the homology question. We can explore strategies for using phylogenetic knowledge to boost cross-species ranking as a separate concern; also using uberon antislims like non_informative to avoid classes like "PATO:ruffled and inheres_in some multicellular anatomical structure"

dosumis commented 6 years ago

I guess that according to @dosumis suggestion, UBERON:limb cannot be a homology class

Relationship of homology to class hierarchy can be confusing. I think limbs can be considered serial homologues and as such are useful groupings for inference purposes (at least within tetrapoda). But a generic parent 'appendage' (including tails in tetrapods) is not. Appendage should be in the Uberon 'antislim' - probably along with most or all of CARO.

cmungall commented 6 years ago

Relationship of homology to class hierarchy can be confusing. I think limbs can be considered serial homologues and as such are useful groupings for inference purposes (at least within tetrapoda).

limb is already restricted to tetrapoda. Waaay back we had a terrible generic conception of limb that came from GO that was "appendage on which an animal walks".

But a generic parent 'appendage' (including tails in tetrapods) is not. Appendage should be in the Uberon 'antislim' - probably along with most or all of CARO.

Agreed.