"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.

[gaurav]

Differences between the two searches are still present but are less pronounced.

However, we still do a bad job with "bone", because we return a whole bunch of bone-related diseases before we return UBERON:0002481 "bone tissue". This is presumably because those have a much higher clique identifier count (16 for "solitary bone cyst", 52 for "osteosarcoma", 18 for "bone osteosarcoma" and so on, as compared to 6 for bone tissue).

You can override this by providing a Biolink type (like biolink:AnatomicalEntity), but this is still unideal.

Not sure how to fix this, though.