search

NCATSTranslator / OperationsAndWorkflows

A repo for the nascent "operations and workflow" language
0 stars 5 forks source link

How to encode extra information beyond the initial query graph? #59

Open edeutsch opened 3 years ago

edeutsch commented 3 years ago

The issue https://github.com/NCATSTranslator/ReasonerAPI/issues/95 over in the TRAPI repo has lain unattended for a long while. After some discussion at last week's TRAPI call, it was felt that this an Operations and Workflow topic instead. The main question perhaps is:

Do we want to be changing the client's query graph to represent extra information? (ARAX at least does this) Or do we want to have a TRAPI extension that allows "extra edges" and "extra nodes" that don't bind to the query graph? (This is Aragorn/Robokop's strategy?)

Once we can determine what is the best way to do it, then the TRAPI group can address any schema changes needed to make it happen.

patrickkwang commented 3 years ago

I think there are cases where it makes sense to modify the query graph, and cases where it does not. So we need some sort of mechanism for extra information. We imply one such mechanism here: https://github.com/NCATSTranslator/OperationsAndWorkflows/blob/main/operations/README.md#general-message-formatting-requirements

This indicates that extra nodes/edges should be bound to the dummy query graph key "". But other conventions would also work. Prefixing dummy keys with "_", for example, would allow distinctions between different sorts of extra bindings, though it's not clear to me what sense the client would make of those distinctions.