add extra_edges and extra_nodes to Result

[patrickkwang]

Servers occasionally want to return more information than was asked-for in the query graph. Rather than modifying the query graph and adding bindings, which could be confusing to the client, it may be more sensible to create fields in each result in which to store this "extra" information.

extra_nodes and extra_edges could be simple lists of knowledge-graph node ids and edge ids, respectively. Then each result is a subgraph of the knowledge graph in which a subset of nodes and edges are bound to elements from the query.

One potential problem with this approach is that it does not allow specification of exactly where in the result graph an extra edge is used. A result in general may include the same knowledge-graph node bound to multiple query-graph nodes, and an extra edge may be relevant to any number of these node instances. Which one(s) will be ambiguous.

[edeutsch]

A quick note to say that I agree that we should address this together. We are currently adding what we are calling "virtual edges" to both the QueryGraph and KnowledgeGraph to convey information that is not in the original QueryGraph. I don't quite understand where you are proposing to put these extra_nodes and extra_edges, can you say where you're envisioning them? And then, assuming we are not voted off the island in March, I agree we should all put our thoughts and examples together and try to come up with a clever way of doing this. All in the same way. Thanks.

[patrickkwang]

Sorry, that was unclear.

“results”: [{
    “node_bindings”: [...],
    “edge_bindings”: [...],
    “extra_edges”: [“abc”, “def”, ...],
    “extra_nodes”: [“MONDO:XXX”, “CHEBI:XXX”, ...]
}, ...]

[patrickkwang]

This suggestion is motivated by a KP under development that returns, with each individual result, a set of potentially interesting extra nodes/edges. There is no guarantee that these sets of extra stuff have a consistent structure. To bind these to elements in the query graph, the KP would need to add a query node/edge for each extra element in all results. The query graph would become enormous and the bindings would add no information.

For extra data of this sort, it seems reasonable to allow additional, unbound elements in each result. For many other types of extra data, it will still make more sense to augment the query graph and apply the appropriate bindings.

[edeutsch]

Decision from TRAPI call 2021-10-28:

Eric will post an issue on the Op&WF group about how to add information that is not in the original query_graph. Keep open but link to open Op&Wf issue. DONE.