Should we use the fancy supporting graph infrastructure for subclass inference?

[edeutsch]

There was some musing about whether simple subclass inference as performed by KPs should also use the auxiliary / supporting graph infrastructure.

This seemed appealing to some. But others felt that there was no need to take something that is already working and change it so substantially. We are undecided. This issue is a placeholder to consider this further and make a decision.

This issue illustrates the ongoing conversation: https://github.com/NCATSTranslator/Feedback/issues/117

[colleenXu]

Our team is still thinking this through, and we have asked for help in the reasonerapi Slack channel. I'm pasting my post from that channel below.

This post has links to graphics/slides for the result.node_bindings.query_id implementation (Q1) vs using auxiliary-graphs / needing to create edges (Q2).

---

Topic 1: how to represent a result when ID-expansion is done?

AKA an entity-curie on a QNode was expanded to include ontology-descendants. In the migration guide, we saw that query_graph cannot be modified, and result.node_bindings must only include QNodes from query_graph.

Q1: Is it still okay to use result.node_bindings.query_id to represent that ID-expansion was done? See my example here

Q2: If the answer to Q1 is no, then what is the recommended way to represent the info in my example?

• I walk through that same info here, trying to use TRAPI 1.4 auxiliary graphs + creating edges...but I'm not sure that this is correct. It also seems kinda complicated / hard to parse.

Q3: If the answer to Q2 is to use auxiliary graphs + create edges ... then is "nesting" okay?

• AKA one edge e0 references an auxiliary graph gA (in its attributes). gA is a list of edges, one of which is e5. e5 also references an auxiliary graph, gZ
• we ask because if we use auxiliary graphs/creating-edges for ID-expansion AND for collapsing multi-hop paths from creative-mode, this is a situation that could happen...

[colleenXu]

And now for my impressions (not representing my teams as a whole):

A. implementing result.node_bindings.query_id should be much easier for our team (we haven't done it yet because we have been waiting for more guidance)

• Perhaps if query_id was universally used across tools, this would help?

B. while our team can most likely implement an auxiliary-graph / creating-edges method, I'm not enthusiastic about it...

• it's more complicated and wordy to use, based on the walk-through I did above...(affecting memory/storage negatively?)
• there's also the potential issue I raise in Q3, where "nesting" of edges-auxiliary-graphs could happen. I think "nesting" introduces complications, and it could happen less if we agreed to NOT use auxiliary-graphs in some cases.
• we've been thinking of ID-expansion (our term for this) as a separate "operation" from "lookup", one that doesn't involve adding any edges to the query-graph or knowledge-graph. Dunno if operations/workflow work has any info related to this...

C. I understand that users find it confusing when descendant-terms are used, when that's not what they asked for. I wonder...

• for now:
  • could the UI have a toggle to show/hide paths (dunno what to call UI-results) that use the descendant terms?
  • could the UI explain that tools are doing ID-expansion? (that descendant terms may show up in the results, and how to look up the original ID you used and its relationship with the ID that showed up)
• Maybe it'd help if we could turn on / off the ID-expansion behavior? For example, if we could add a tag for query-nodes with user-specified IDs, to control whether our tools do ID-expansion on those nodes or not...

[edeutsch]

There is a PR here: https://github.com/NCATSTranslator/ReasonerAPI/pull/420/commits/e9c41d59a8e9e30f28f9491b4bbb970b80bae8d6

that proposes to implement this. I believe @vdancik and @andrewsu and @dkoslicki were interested in commenting on this proposal? See also @colleenXu comments above.

[colleenXu]

@edeutsch I think the example in the PR needs some edits:

• the auxiliary graph key is subclass_explanation_1 but the KG edge uses the support graph a0
• is the attribute_type_id correct for the KG edge? It says "attribute_type_id": "infores:support_graphs"....

[edeutsch]

thanks! @uhbrar would you see if you can fix?

[uhbrar]

Yes, I've gone ahead and fixed that. Thanks!