Open kltm opened 11 years ago
About SHH, there are actually some very large differences between what is happening behind the scenes on Grebe's autocompletion and on the general/landing page autocompletion.
In Grebe's case, we're searching document classes that are completely specific to the entity, so we're able to feed it information like "since this is a term, we know that there may be synonyms" or "this is a gene product, so display the species in the dropdown".
However, in the general case, the backing document type is: a title, a label, and an unstructured jumble of random searchable things. This allows us to search for terms and gene products (and anything else we might want) seamlessly at the same time, but it leaves us with no way of reconstructing what we're looking at.
A possible solution would be to add the species to the label where applicable, but this might make the search a little strange in some cases. Another way might be to add a secondary non-seachable "display" field to the document type specifically to give dropdowns something to work with, but would require a schema change and reload.
I think we need to customize things a little for genes/gene products here.
For a gene like sonic hedgehog, there will be multiple entries each with a symbol "SHH", "SHH", "Shh", shh". Sometimes if it's zebrafish there's been a gene duplication you have "shha" "shhb" as two separate entries.
The average person who is coming in via a gene search may not care for genes outside their species - they just expect the search to work for their species of interest. If they start typing "SHH" and they see a list with no way of disambiguating they will get frustrated.
I don't think we want to append species to the symbols in the general case - this would show up redundantly in many cases. But for autocomplete some context should be show one way or another. Autocomplete doesn't need to be perfect for genes - it's a hard problem, and many people know the exact symbol for their species anyway. It just has to be a bit more transparent.
I'm not sure I follow your proposed solution. Mine would be that there is a separate (non-searchable) field for every entry in the general document type that would be the default display in an autocomplete context. In this context, the display field for items derived from terms would look much like it does now, but the display fields for items derived from gps would look like:
SYMBOL [DB:ID, G. species]
David has another example where this might be useful: to be able to display ontology in various term closures. The idea would then be to have an optional "*_display_label" field that would be picked before label in display contexts. Alternatively, and possibly more sanely since this will end in a lot of special cases, we can make the filters try the handlers before doing the normal render. Hopefully this would not slow things down so much.
As an aside, there is an override in the display code in jQuery that allows the addition of arbitrary structures in the dropdown. This can be used to add a secondary metadata string in small to help clarify the results. This could be added as options to the widget initializer.
We did this for the autocomplete in monarch: http://monarchinitiative.org/
https://github.com/monarch-initiative/monarch-app/commit/a925044dc874452a41838089823e5606130bacc2
From David:
One thing I did notice was that when using the quick search box on a gene symbol such as SHH, the species does not display in the suggestions box. It does display from Grebe. I think we need the species.