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
as a: gtn user
i want to: search for long read / ONT
so that: I can find long read tutorials
I've searched:
ont (nothing useful)
long (nothing useful, also nothing useful when filtered on)
oxford (one tutorial, title match)
nanopore: many correct results.
i've got a branch for pagefind, but, realy this is an issue of ranking and annotating and defining synonyms people might want to search for.
synonyms
we should consider adding a file with 'synonyms' for every tag, something like:
nanopore, ont, long read, long-read, oxford
genome browser, jbrowse, igv
short read, ngs, illumina
where every term on the row is equivalent, and then whenever any of those tags are used, all of their synonyms would be included transparently for the user (in a visually hidden way.) then we could consider prioritising exact matches to those (visually hidden) tag synonyms.
it'd mean controlling the tags a bit more carefully, maybe even linting on them to make sure they're defined in our synonyms file with appropriate synonyms.
why not an ontology?
we already have one, but people don't use it because it's hard to search, and doesn't provide synonyms that we need, not in a useful way. if someone demands an ontology, the more user-friendly implementation is going to be letting folks do free text tags and then either mapping those onto an ontology later by hand.
we want to balance the UX for contributors with UX for users, and this is one of those potentially low ROIs, so we want to keep contributor UX low if possible. We aren't currently tracking the search terms people use but, we should consider doing so. Even without session information we'd probably get interesting data.
why (not) an ontology pt 2
the case of genome browser and jbrowse/igv are transparently one of an ontology, where they're child terms and searching for genome browser should maybe return both, but searching for children shouldn't.
one would be inclined to say "if it's an ontology we get those relationships for free" which is true, but we don't get the implementation for free which is perhaps a more important point, we still need to write that.
The text was updated successfully, but these errors were encountered:
as a: gtn user
i want to: search for long read / ONT
so that: I can find long read tutorials
I've searched:
i've got a branch for pagefind, but, realy this is an issue of ranking and annotating and defining synonyms people might want to search for.
synonyms
we should consider adding a file with 'synonyms' for every tag, something like:
where every term on the row is equivalent, and then whenever any of those tags are used, all of their synonyms would be included transparently for the user (in a visually hidden way.) then we could consider prioritising exact matches to those (visually hidden) tag synonyms.
it'd mean controlling the tags a bit more carefully, maybe even linting on them to make sure they're defined in our synonyms file with appropriate synonyms.
why not an ontology?
we already have one, but people don't use it because it's hard to search, and doesn't provide synonyms that we need, not in a useful way. if someone demands an ontology, the more user-friendly implementation is going to be letting folks do free text tags and then either mapping those onto an ontology later by hand.
we want to balance the UX for contributors with UX for users, and this is one of those potentially low ROIs, so we want to keep contributor UX low if possible. We aren't currently tracking the search terms people use but, we should consider doing so. Even without session information we'd probably get interesting data.
why (not) an ontology pt 2
the case of genome browser and jbrowse/igv are transparently one of an ontology, where they're child terms and searching for genome browser should maybe return both, but searching for children shouldn't.
one would be inclined to say "if it's an ontology we get those relationships for free" which is true, but we don't get the implementation for free which is perhaps a more important point, we still need to write that.
The text was updated successfully, but these errors were encountered: