search

monarch-initiative / monarch-ui

The previous version of the Monarch Initiative website
https://previous.monarchinitiative.org/
BSD 3-Clause "New" or "Revised" License
17 stars 28 forks source link

variant phenotype association inconsistent #310

Open pnrobinson opened 4 years ago

pnrobinson commented 4 years ago

Why does this variant associated with phenotypes https://beta.monarchinitiative.org/phenotype/HP:0002149#variant

but this one doesn't https://beta.monarchinitiative.org/variant/ClinVarVariant:549402

I am not sure that it is a good idea to show variant-phenotype links (the transitivity is tricky) anyway and would recommend we remove the links

kshefchek commented 4 years ago

We removed human variant to phenotype, or at least this is the intention. I think here we're seeing mouse variants related to this HP term because it has been merged with MP:0008821. In the next version of Upheno these direct equivalences will go away (cc @matentzn)

matentzn commented 4 years ago

Yeap. In fact, I think that for the site, we could even consider switching to upheno2 already.. Its just owlsim and semantic similarity based apps that need a more conservative approach with testing etc..

kshefchek commented 4 years ago

noting that "we removed human variant to phenotype" only partially applies to the edge has_phenotype, we have variant to phenotype coming from GWAS via a different RO relation, and we have UDP case variant to phenotype linked with has_phenotype. There are also a handful of MONDO ids that end up classified as variants due to some integration error. We track these in our qc but we should aim to fix these at some point.

jmcmurry commented 3 years ago

todo: make clear when you go to HPO and there's an equivalent MP that the associations are via a grouping. Take info from overview tab.

kshefchek commented 3 years ago

as Nico mentioned - this scenario disappears with upheno2, so I vote we do nothing and wait for that to make it to production