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
relates to other issues on /search such as #1657 where we need to implement navigation through assets matching the search query.
ATM we already have multiple search implementations (default one, new /search, @djarecka working on LD based search, me and @candleindark on datalad-registry which would also provide search through dandisets metadata). I think that it would be useful to design separation between search backends and navigation through search results we provide on the archive. It would need defining an API and data structures to exchange between search engine and search results navigation/visualization on the archive. At minimum the data structure could be a list of dandisets with assets (UUIDs/paths) matching in each.
edits:
Aspects to keep in mind
We might qualify search results in terms of "precision". Echoing the Searching for names with accented characters. #1941 use case, some search engines might return "approximate" hits (e.g. via fuzzy matching) and it might be desirable to separate out "exact" matches, from approximate. Moreover we might even want to facilitate search backends to have a parameter to disable/control approximate matching.
The text was updated successfully, but these errors were encountered:
Not quite sure what you are asking for here. Each search modality needs its user interface to be coupled fairly tightly to its implementation, right? For example, for faceted search you need to be able to specify facets. Some modalities may share an element, like the text search bar, but in those cases you'd still need to tell the system which type of search you want to do.
Are you saying we should create clean APIs for all the search modalities so that anyone can write a custom UI for them?
I am not talking about search "parameters specification model" (which we might want to talk about next ;) ), but rather "search results model" to start with. If we all agree on the "search results model", then we could have some generic web UI which would consume results from any search backend and display them. I will try to come up with one to show to make it clearer on what I am talking about.
relates to other issues on
/search
such as #1657 where we need to implement navigation through assets matching the search query.ATM we already have multiple search implementations (default one, new
/search
, @djarecka working on LD based search, me and @candleindark on datalad-registry which would also provide search through dandisets metadata). I think that it would be useful to design separation between search backends and navigation through search results we provide on the archive. It would need defining an API and data structures to exchange between search engine and search results navigation/visualization on the archive. At minimum the data structure could be a list of dandisets with assets (UUIDs/paths) matching in each.edits:
Aspects to keep in mind
The text was updated successfully, but these errors were encountered: