Open jmcmurry opened 8 years ago
The breadcrumb part of this is relevant also for phenotypes
For future debugging purposes, Crigler-Najjar. One result is the disease group and ostensible duplicate is the disease; labels of parent and child overlap.
Moving @cmungall comment from https://github.com/monarch-initiative/monarch-app/issues/1383#issuecomment-256595748
"Currently the distinction between disease and disease-group is a pure UI level hack that exists to prevent killer queries. If a disease has subclasses then it is treated as a disease group and we use a template that doesn't make phenogrid on the main tab (to avoid scenarios where we have high level diseases like 'skeletal disease' with 1000s of phenotypes blowing things up).
We should have a better fix for this, but it serves its purpose for now. However, we shouldn't let this arbitrary distinction go further. The subclass test is not meaningful. For example, an OMIM class can have orphanet clinical subtypes.
There may be methods to create subsets of distinct diseases based on a methodoligical criterion. For example, for Mendelian diseases, we can count diseases based on 1:1 correspondence with genes (ie OMIM). But how does this work for common disease? What is a disease and disease groups when it comes to cancer?
These are interesting questions we will be exploring in MonDO but for now let's not proliferate a fake distinction."
I like the idea of showing hierarchy as part of search - I do this when I query on the command line. But this should probably be an extra enhancement ticket, as there are architectural issues to consider here. We should focus on what can be done with the existing index for this round.
Moving @mellybelly comment from https://github.com/monarch-initiative/monarch-app/issues/1383#issuecomment-256171590
"RE disease groups, lets discuss that on ontology call, i don't think there can be a 1-to-1 correspondence with genes and diseases."
Currently the distinction between disease and disease-group is a pure UI level hack that exists to prevent killer queries.
@cmungall @harryhoch do you think it would be better to state the number of subclasses rather than make an arbitrary binary distinction?
@harryhoch says
"Interesting question. In the ideal sense, Monarch could be very well-suited for helping people ask questions like - "what can differing model systems tell us about the various manifestations of what we call 'Parkinson's disease'". That said, I'm completely with @cmungall - defining these classes is likely to be exceedingly difficult.
@jmcmurry, I assume your question lies in how do we display "disease" vs. "disease groups"? Right now we have different displays that, if anything, fail to make the distinction clear. I like the idea of including the number of subclasses, but I think that we should consider whether we want to have "disease groups" as continuing entities, and, if so, how we might design displays that would make them useful."
TLDR: Desired features
Backstory:
I was searching Monarch for all genes implicated in all forms of
Fanconi anemia
. Our default label for the disease group isFanconi's anemia
and it is therefore difficult to get to. (Related to #1282).1)
Fanconi's anemia
is not in the autocomplete results unless you add the apostrophe.Thus, I instead did a site search for 'fanconi' and got hundreds of results. As I've mentioned on many occasions, the lack of indication regarding why some results appear makes it very confusing for the uninitiated user as to what the results mean (lexical match to search term, or an asserted association). Many of these, due to the fact that the word "fanconi" is exceptionally specific, are actually implicated in Fanconi. So, if those genes are what someone is expecting to find, they wouldn't immediately notice an issue. However, in other scenarios, we would be misleading the user into interpreting biological meaning on the basis of lexical similarity alone. For instance 'spider fingers' is a hit when searching for 'spider legs'; these phenotypes have nothing to do with each other as far as I can tell. Moreover even if site search is NOT biologically misleading, in and of itself it is feature-poor (no facets, no filters, no ranking, frequently missing taxa, etc).
Thus, in order to get to the disease group, one has to know or explore what the distinction is between these two entries:
One entry is a member of the disease group, and the other is the disease group. At the time, I didn't realize this. (Because of the uppercase/lowercase pair, I figured that the latter might have been the rare occurrence of an animal disease in our system). At any rate, I selected the upper case one
Fanconi Anemia
which got me toDisease: Fanconi Anemia, Complementation Group a
which is more specific than I wanted.... It defaulted to phenogrid, so I clicked to the overview tab and navigated up a level using the ontology browser. This could have been avoided by distinguish "disease" and "disease group" (in both autocomplete and search) in the first place, and by showing matches on synonyms differently to matches on label. See also #1008