Need review of gene search spec

[sammyjava]

You said you want to look it over before assigning me, so look it over, @adf-ncgr .

[adf-ncgr]

OK, thanks. A couple of comments: The note in the spec that indicates the equivalence to the Intermine "create a list" I think means this is more or less different than the gene search page in the old site which wasn't primarily an identifier-lookup service. However, it's a good functionality to have, just something different from what I was envisioning. Salient difference from the Intermine UI:

• no need to indicate type if we're limiting it to a gene search (but should we?)
• intermine also provide the organism dropdown which is given here as optional. I think unless we are supporting "fuzziness" in our IDs it is probably unnecessary. The fuzziness that appears to be present it in admitting non-full yuck IDs, but this would probably require a dropdown that allowed specification of annotation version to really deal with as a pre-filter.
• the Intermine approach deals with ambiguity (aka fuzziness) by requiring the user to resolve it before proceeding. I think we probably don't need this.
• one of the examples goes to more extreme fuzziness ("19G041200" and no organism specified); not sure if we want to go to the length of looking for substrings of what we have in the db as the secondary identifier and/or name, especially if we take a significant performance hit against the typical use case.

results table should just reuse the components already developed for the description-based gene search, including the linkout approach when available.

nice to have: allow user to post result set to list creation page in mine; this and other set-based operations (e.g. send list of genes to GCV) may be supported by linkout service approach eventually.

[sammyjava]

Yeah, this isn't a gene search. If I want to search for a gene, I have a search term like "photosynthesis", not "Phvul.004G049100", in which case I'm not searching for a gene, I already know it. I'd call this a Gene lookup. Which is fine, but it's far short of what we have on the legacy site for searching for a gene.

I'm happy to code this up, but it's an inadequate offering for searching for a gene on the LIS site. I think it should be combined with other options like the existing gene description search, etc. etc. etc. I believe @adf-ncgr has just offered to spec something like that up. :)

[adf-ncgr]

OK, here's a quick sketch of what I think we'd want for search filters: Genus/species/strain matched as "equals" (for starters, we could just have these as free text, maybe someday we'd want them as dropdowns); gene name/id matched as "contains" (this wouldn't support lists of ids, which are better done under the spec from @cann0010 ; but it would support having non-full yuck as input and possibly getting back multiple choices) description matched as "contains"; gene family matched as "contains" (probably could be equals but there might be a desire to support both legfed_v1_0.L_3SHP0G and L_3SHP0G);

and for info returned: full yuck id (supporting linkouts) description genomic location gene family

I think this is a fairly straightforward extension of the existing lis-gene-search-element with a few extra fields added for both query and in the tabular return.

[sammyjava]

Did you know that a requirements doc never contains the word "possibly"? :) I'll de-vagueify it into an actual requirements doc and spec.

Oh, sorry, it's a sketch, not a requirements. My mistake.

[adf-ncgr]

I MAY in future decide to follow IETF RFC

[sammyjava]

I MAY in future decide to follow IETF RFC

That's still a bit fresh, being just 1997. (Great RFC to know about, thanks!)

[sammyjava]

Review gene-search README in adf-gene-search branch.

[StevenCannon-USDA]

Highjacking this thread with something vaguely apropos of specification and design (and cycles, @sammyjava): The velocipedia. You are welcome.

[adf-ncgr]

You are raising the bar for hijackers, @cann0010

[adf-ncgr]

@sammyjava do you want comments about the prototype as part of this issue thread or as a new issue?

[sammyjava]

I'll close this since we're reviewing a prototype demo, not the spec itself.