"Bone" works well when autocomplete=true but breaks when autocomplete=false

[gaurav]

When autocomplete is set to true, we set the query parameter query to e.g. (water) OR (water*) so that we can include cases where the search query is incomplete (e.g. (bloo) OR (bloo*) lets us find blood).

When autocomplete is false, we set query to just (water). In most cases this works fine, but sometimes this presents very different results. Compare:

• https://name-resolution-sri.renci.org/lookup?string=bone&autocomplete=true&offset=0&limit=10&exclude_prefixes=UMLS
• https://name-resolution-sri.renci.org/lookup?string=bone&autocomplete=false&offset=0&limit=10&exclude_prefixes=UMLS

We can restore the previous results by repeating the search query twice as before, i.e. (bone) OR (bone). I tried that out in a branch and confirmed that it does work:

NameResolution/api/server.py

Line 301 in 8006348

query = f"({string_lc_escaped}) OR ({string_lc_escaped})"

Looking at the explain output, it looks like both queries set off a search for "bone bone", which might be pulling the correct UBERON term higher up:

    "rawquerystring":"(bone) OR (bone*)",
    "querystring":"(bone) OR (bone*)",
    "parsedquery":"+(DisjunctionMaxQuery((names:bone | (preferred_name_exactish:bone)^10.0 | preferred_name:bone)) DisjunctionMaxQuery((names:bone* | preferred_name:bone* | (preferred_name_exactish:bone*)^10.0))) DisjunctionMaxQuery(((names:\"bone bone\")^2.0 | (preferred_name:\"bone bone\")^3.0))",
    "parsedquery_toString":"+((names:bone | (preferred_name_exactish:bone)^10.0 | preferred_name:bone) (names:bone* | preferred_name:bone* | (preferred_name_exactish:bone*)^10.0)) ((names:\"bone bone\")^2.0 | (preferred_name:\"bone bone\")^3.0)",

    "rawquerystring":"(bone) OR (bone)",
    "querystring":"(bone) OR (bone)",
    "parsedquery":"+(DisjunctionMaxQuery((names:bone | (preferred_name_exactish:bone)^10.0 | preferred_name:bone)) DisjunctionMaxQuery((names:bone | (preferred_name_exactish:bone)^10.0 | preferred_name:bone))) DisjunctionMaxQuery(((names:\"bone bone\")^2.0 | (preferred_name:\"bone bone\")^3.0))",
    "parsedquery_toString":"+((names:bone | (preferred_name_exactish:bone)^10.0 | preferred_name:bone) (names:bone | (preferred_name_exactish:bone)^10.0 | preferred_name:bone)) ((names:\"bone bone\")^2.0 | (preferred_name:\"bone bone\")^3.0)",

So the real solution here would be to improve the search so that we don't need to duplicate terms. The clique count I'm currently testing might help with that, but the scores might also be different enough that that doesn't make a difference. If that's the case, we'll need to be smarter about this.