Improvements to Analyze Phenotypes input

monarch-initiative / monarch-legacy

Monarch web application and API

BSD 3-Clause "New" or "Revised" License

42 stars 37 forks source link

Improvements to Analyze Phenotypes input #994

Open jmcmurry opened 9 years ago

jmcmurry commented 9 years ago

Easy

[ ] CURIE or CURIE prefix absolutely needs to be part of the autocomplete box otherwise apparent duplicates are confusing. We are currently not getting that distinction until after selection:

screen shot 2015-10-09 at 10 43 53

Moderately easy?

[ ] Enable identifiers to be entered eg HP:0011304, not just labels. We would ultimately probably want to be a little more fault tolerant with the ID syntax (underscore, space, prefix variation), but a strict lookup would be fine for now.

I would be surprised if the existing backend needed to be modified to make these changes, but please let me know if I'm mistaken.

Needs thought; postpone this

[ ] Enable multiple items to be pasted (delimited with newline or semicolon? Both?) What if there are tokens that aren't recognized as term labels or identifiers, then what? Text annotator? Does Text annotator recognize IDs?

kshefchek commented 9 years ago

It looks like we're not sharing code (maybe for good reason) between the navbar autocomplete and analyze page autocomplete. I will add the equivalency fiiltering code to remove duplicates here.

For searching on IDs, we don't currently store curies in SciGraph (unless imported from an ontology). There have been some offline discussions but we should make an official ticket in the SciGraph repo.

jmcmurry commented 9 years ago

@kshefchek If you remove duplicates in analyze page autocomplete, will it put multiple exact matching terms in the list? (eg. HP and MP). If so, this is probably fine, perhaps desirable anyway. The user can always remove one if necessary.

kshefchek commented 9 years ago

If I were to copy the functionality from the navbar autocomplete, we would only be showing the user the collapsed ID/label. But I would think this is desirable over showing the user all equivalent IDs in the phenotype list which would be potentially confusing.

kshefchek commented 9 years ago

Thinking about https://github.com/monarch-initiative/monarch-app/issues/994#issuecomment-146951868 a little more, we have graph and vocabulary services that accept curies as input. So we could theoretically try to match on a user entered ID assuming it is entered correctly and in the correct format (curie rather than fragment).

For example, a user enters HP:0000175 which has 0 matches in autocomplete, we could attempt a match via the vocabulary/id service and present this to user in the autocomplete box: http://geoffrey.crbs.ucsd.edu:9000/scigraph/vocabulary/id/HP:0000175

Would this behavior be useful while we enable searches on curies?

kshefchek commented 9 years ago

The analyze autocomplete is now filtering out equivalent classes, @jmcmurry could you clarify the following?

"CURIE or CURIE prefix absolutely needs to be part of the autocomplete box" - Do we still want this?
"Enable identifiers to be entered eg HP:0011304, not just labels" - See above comment
Enable multiple items to be pasted (delimited with newline or semicolon? Both?) - Could we simply add an input box. just like the gene id box under compare? This could go under the autocomplete area. Or we could get fancier with this.
What if there are tokens that aren't recognized as term labels or identifiers, then what? Text annotator? Does Text annotator recognize IDs? - (I think discussed offline) SciGraph does not yet store curies so this would be blocked until that functionality is added.

jmcmurry commented 8 years ago

"CURIE or CURIE prefix absolutely needs to be part of the autocomplete box" - Do we still want this?

I think so, but less crucial if we get the species filtering working (eg. autocomplete on only human terms, or only on HPO terms, etc)

"Enable identifiers to be entered eg HP:0011304, not just labels"

I still think this is important but think that scigraph annotator is a better route than building yet another kind of input interface; I hope it would be more forgiving and intuitive.