Request to Indicate that results are shown because they are subclasses of the input query

[sstemann]

Steps:

1. In the CI UI run query What chemicals may treat Dystonic Disorder: https://ui.ci.transltr.io/results?q=c881b19e-f619-4199-a2db-f9ce8ad5e17b
2. Notice that some paths do not end in the queried disease. This is by design that results are shown for diseases that are subclasses of the input disease but a user may need something to understand that the specific disease has been expanded upon. Maybe users would get it immediately but logging it for discussion.

[sierra-moxon]

from TAQA:

• in the results, we see treatments for many diseases (in this case its a subclass return, which is good and expected, but not transparent to the user)
• confusing to users, they aren't aware of the hierarchy
• if the name returned for the disease isn't exactly the one from NodeNormalizer, then we tag the UI with "subclass of" -- just assume it? -- Anne: could just say "related disease" - yep we like that. Matt: it depends on your definition of "related disease"? For the user that wants subclass of. Mike: Indicate subclass of but use different language.

[sierra-moxon]

@balhoff - can we assume subclass_of for all related diseases? (is this an architecture rule @cbizon?)

[cbizon]

In the case that an identifier different from the query identifier is returned in an answer, there should be a query_node_id (or something similar) that specifies which query node that identifier should go with. The only way that should happen is by subclassing, but I do think maybe we should make that explicit, probably using an auxiallry graph @uhbrar @mbrush

[sierra-moxon]

@uhbrar - do you think this is a use case that is good for auxiliary graphs? :)

[colleenXu]

Note that I added the questions my team has on "ID-expansion" behavior as well as my own impressions and suggestions (not my teams).

My (again, not my teams) short answer is that I'm not enthusiastic about using auxiliary graphs to address this issue.

[sierra-moxon]

from TAQA:
from architecture - we will use aux graphs, but not implement them until after higher priority 1.4 items are implemented. There is enough info in TRAPI atm to implement this in the UI now, but they would need to "redo" it when the aux graph is implemented.

Andy: what is the EPC for the path/graph?
Chris B: one of the reasons the new solution will be helpful (currently no place to put EPC).
Matt: this is called "logical entailment" (pls correct Matt if I got this wrong).
Bill: sometimes these come from SEMMEDDB, not just ontology.

[sstemann]

subclass of shows in the paths now