Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

search comments/issues, synonyms #5540

Open
hexylena opened this issue Nov 15, 2024 · 0 comments
Open

search comments/issues, synonyms #5540

hexylena opened this issue Nov 15, 2024 · 0 comments

Comments

@hexylena
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant