You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This ticket is based on discussion between @matthewhorridge & GO editors. It covers the behaviour of the search box in the top right of the Protege interface (from here called QuickSearch).
The modified QuickSearch in P5 searches many more fields than the old QuickSearch, but it doesn't have the features required for efficiently finding terms in large ontologies in which entities have long labels and additional annotation properties for synonyms or alternate labels.
Arbitrary or style-based decisions about long labels can effect the order of words and whether or not they are adjacent (e.g. 'heart development' vs 'development of heart'). The most efficient way to deal with this is to tune the autosuggest so that two strings separated by a space trigger a boolean AND search for labels with the two strings. The QuickSearch autosuggest system should be modified to have this behaviour. It would also be useful if the output was ordered such that hits to the start of the string come first. This, combined with alphanumeric sorting results in exact matches coming top.
Searching alternate label / synonym fields is also important, as is the ability to search by ID. The current search system allows this, but the results are easily overwhelmed by hits in other annotation property values (e.g. definitions, comments). Instead, the default QuickSearch should be limited to annotation properties chosen for rendering + (shortform) ID. It should then be possible to specify additional annotation properties for QuickSearch under preferences. It would also be useful if the autosuggest hit list included some indication of the type of annotation axiom that the hit comes from and perhaps also the rendered name of the term.
More advanced searches allowing configuration at search time and combinatorial searches would be best dealt with by a dedicated advanced-search plugin. This will be described in a second ticket.
The text was updated successfully, but these errors were encountered:
This ticket is based on discussion between @matthewhorridge & GO editors. It covers the behaviour of the search box in the top right of the Protege interface (from here called QuickSearch).
The modified QuickSearch in P5 searches many more fields than the old QuickSearch, but it doesn't have the features required for efficiently finding terms in large ontologies in which entities have long labels and additional annotation properties for synonyms or alternate labels.
Arbitrary or style-based decisions about long labels can effect the order of words and whether or not they are adjacent (e.g. 'heart development' vs 'development of heart'). The most efficient way to deal with this is to tune the autosuggest so that two strings separated by a space trigger a boolean AND search for labels with the two strings. The QuickSearch autosuggest system should be modified to have this behaviour. It would also be useful if the output was ordered such that hits to the start of the string come first. This, combined with alphanumeric sorting results in exact matches coming top.
Searching alternate label / synonym fields is also important, as is the ability to search by ID. The current search system allows this, but the results are easily overwhelmed by hits in other annotation property values (e.g. definitions, comments). Instead, the default QuickSearch should be limited to annotation properties chosen for rendering + (shortform) ID. It should then be possible to specify additional annotation properties for QuickSearch under preferences. It would also be useful if the autosuggest hit list included some indication of the type of annotation axiom that the hit comes from and perhaps also the rendered name of the term.
More advanced searches allowing configuration at search time and combinatorial searches would be best dealt with by a dedicated advanced-search plugin. This will be described in a second ticket.
The text was updated successfully, but these errors were encountered: