monarch-initiative / monarch-legacy

Monarch web application and API
BSD 3-Clause "New" or "Revised" License
42 stars 37 forks source link

analyze/phenotypes should link to model-view grid #119

Closed harryhoch closed 10 years ago

harryhoch commented 10 years ago

Analyze /phenotypes should include the model-view grid that is shown on the disease page.

should this be on a different tab on the same page , or should we reithink the analyze/phenotypes page more generally?

mellybelly commented 10 years ago

Not sure what we want for sneek peek, but presumably in the longer run we will want to be able to choose the species for which we have a set of phenotypes, and what species we want to return. examples:

HP terms => mouse models (standard view now) MP terms => similar mouse models MP terms => similar zebrafish models MP terms=> similar diseases HP terms => similar diseases HP terms => similar zebrafish models

Not sure how to enable ZP queries, its not very user friendly and we are not ready to take EQs.

coming soon: HP terms => similar worm or fly models MP terms => similar worm or fly models

I like the idea of having the model view be the default view, with the option to see all models on a different tab.

harryhoch commented 10 years ago

Thoughts on putting this view directly beneath the input fields currently in use?

cmungall commented 10 years ago

I think the grid should be accessible via an additional click (1) it takes some time to construct (not the grid's fault, comes down to the inability to join in fed queries) (2) the current search allows you to scroll through a potentially very large number of ranked hits, I think it makes sense to only show a subset of these in the grid view.

Not clear what the best transition might be; could be useful to select a set of results, or just take the top n and feed it to the grid view.

cmungall commented 10 years ago

Melissa, not sure I understand your comment.

Once we have the phenotype category in the vocabulary index, we can restrict the autocomplete to be phenotypes only. At first this will be HP, MP and ZP (but is extendable by adding relevant imports to monarch.owl). I agree ZP is not user friendly, we could restrict it by not placing it as a subclass of phenotype but this isn't very satisfactory. Ultimately we need more facets in the vocabulary index to customize the autocomplete for specific needs.

MP, HP and ZP are all in the same phenotype soup linked by equivalence axioms. Any of these can potentially retrieve results from another species. Currently we load human diseases, mouse genes and zebrafish genes into owlsim. The phenotype ontology soup is potentially a confusing situation for users, but that's the ingredients we have to work with, until we have a GO for phenotypes.

I think EQ querying would be too complex for most, but it would be useful to allow queries for, say "limb" and get limb phenotypes. Users don't think in terms of our stratification of ontologies. The limb query would be easy to handle on the owlsim side - we'd translate it to a class expression and use that, Elk doesn't care. It would be harder however to have a monarch page for "limb" which retrieves the correct results. This is essentially use case 2 in https://support.crbs.ucsd.edu/browse/LAMHDI-140

mellybelly commented 10 years ago

Sorry if not clear. My point is that the user will come in with info for one species, and want results on either the same species or another species of their choosing. I think you are suggesting that they are going to type in their phenotypes and not know what they are autocompleting on - I think this is desired behavior (except when they have a list of IDs, but that is different). The problem is that ZP is not very user friendly for autocomplete/browse. Do we have a priority order of label display for equivalent classes? Seems like something simple to this effect could be helpful? At least for the page labels?

I agree EQ querying is too complicated (not sure I would ever want this), but maybe we can later enable querying and even browsing based on anatomy and taking them to phenotype pages involving those anatomies based on the class expressions as you suggest. I like this idea. Yes exactly use case 2 - and as you point out there, sometimes a user might want only zebrafish results, other times "uber" results. And probably when they want zfish results, they really want the uber results filtered for only zfish results to take advantage of the extra inferencing in uberon.

harryhoch commented 10 years ago

Chris:

Regarding accessing the grid, I'm ok with accessing it via an additional click. Does it make sense to add a tab below the input fields?

In terms of transitions, I think it would be ideal to just take the n input phenotype terms and and to hand them off to owlsim to display the top n models in the modelview. Is this feasible?

cmungall commented 10 years ago

I think tabbed results may make sense, I don't have strong opinions.

However, currently we load everything onto a single HTML page, with the tabs merely hiding/showing, so we would still have a page load time issue, unless we add some extra smarts (e.g. some jquery that dynamically loads a new page on tab selection)

harryhoch commented 10 years ago

Fair point. Regarding the loading, is it feasible to pull up the owlsim model results for the arbitrary set of phenotype inputs? On Feb 9, 2014, at 4:06 PM, Chris Mungall notifications@github.com wrote:

I think tabbed results may make sense, I don't have strong opinions.

However, currently we load everything onto a single HTML page, with the tabs merely hiding/showing, so we would still have a page load time issue, unless we add some extra smarts (e.g. some jquery that dynamically loads a new page on tab selection)

— Reply to this email directly or view it on GitHub.


Harry Hochheiser University of Pittsburgh Department of Biomedical Informatics harryh@pitt.edu 412 648 9300

cmungall commented 10 years ago

Harry - yep, that's how the page is driven at the moment

harryhoch commented 10 years ago

great. @cborromeo , can you look at this?

harryhoch commented 10 years ago

this is done