Returned TRAPI should be executable: DSL to workflow?

[dkoslicki]

I’ve seen this in a number of situations (eg. here) where there is confusion about why the TRAPI that ARAX returns is not executable. Given it seems reasonable to assume the system should be idempotent while still detailing what was done, I propose that we: Translate the DSL queries in the yml to the workflow language (basically this but in reverse) and incorporate this into the returned TRAPI.

That way when ARAX returns TRAPI, it will detail exactly what was done, and can be executed directly without edit (eg. Removing virtual edges from the query graph).

Thoughts from @edeutsch and @finnagin ?

[edeutsch]

Yes, agreed, I had the same thought after replying to Ryan.

There are substantial complexities, however.

• Definitely coming up with code that translates DSL --> workflow language would be cool.
• There are some complications in that DSL is potentially both a QueryGraph + Workflow
• It is possible for a TRAPI Query to contain both DSL and a Workflow (and a QueryGraph) possibly causing some confusion
• Our normal JSON window typically just shows the QueryGraph and not the DSL or the Workflow (although this is starting to bend a little bit
• Plus the issue of these virtual edges that we insert to cause complications
• Really the next major feature that is now ripe to do (@isbluis ) is to create the Workflow builder interface.
• The new way of performing queries would now/then be a QueryGraph+Workflow
• Where a "plain" QueryGraph would be accompanied by a default Workflow of lookup+score
• Not easy
• But definitely the next big thing!

[dkoslicki]

Agreed! Here's my $0.02 for you points:

• Definitely coming up with code that translates DSL --> workflow language would be cool.

@finnagin should be able to do that without issue. There may be a feature or two in the DSL that can't be accessed via the workflow language, but that will let us know what needs to be updated in the workflow language.

• There are some complications in that DSL is potentially both a QueryGraph + Workflow

I assume this can be solved with translating add_qnode and the like to QG items, so hopefully isn't too complicated.

• It is possible for a TRAPI Query to contain both DSL and a Workflow (and a QueryGraph) possibly causing some confusion

This would be quite complex, but given the sponsor's desire for "all via ARS", I figure we can safely assume no "typical" user will be doing this.

• Our normal JSON window typically just shows the QueryGraph and not the DSL or the Workflow (although this is starting to bend a little bit

This has been much appreciated. Quite a bit better than posting and copy/pasting results.

• Plus the issue of these virtual edges that we insert to cause complications

I imagine these would completely go away given that they would basically be included in the workflow language. Eg. If an NGD edge between n0 and n1 is encoded in the workflow part of the message, then no need to encode it in a virtual edge.

• Really the next major feature that is now ripe to do (@isbluis ) is to create the Workflow builder interface.

That would be ridiculously awesome! @isbluis here's the list of current operations, along with how we translate them to ARAXi, plus a real-world example

• The new way of performing queries would now/then be a QueryGraph+Workflow

Which is where things appear to be headed. So a good thing?

• Where a "plain" QueryGraph would be accompanied by a default Workflow of lookup+score

Yeah, we might have an interim "plain" QG happens to return a QG+workflow due to the internal decorating, but if the above is implemented, I think having an input "plain" QG returning a QG+workflow shouldn't be unreasonable.

[isbluis]

• Really the next major feature that is now ripe to do (@isbluis ) is to create the Workflow builder interface.

That would be ridiculously awesome! @isbluis here's the list of current operations, along with how we translate them to ARAXi, plus a real-world example

The latest version of the GUI now has a Workflow builder; feel free to try it out in devLM, or once it is pushed to test, @dkoslicki . https://arax.ncats.io/devLM/

[edeutsch]

The latest master is pushed out to all deployments

[finnagin]

This looks great @isbluis ! Great job!

Though the one thing I noticed was it looks like you may be pulling the drop down menu of operations from the list of all operations and not just the ones we have implemented. This list of implemented operations can be found here.

[edeutsch]

Ah, a good point I had not considered. This yields a few additional points:

1) The interface can be used to submit to other ARAs and the ARS and therefore only limiting it to ARAX operations is not always going to be what the user wants

2) But in many cases, it will

3) Thus maybe it would be fun idea to limit the set of operations to what the intended endpoints supports

4) Although there is a standardized language to determine what the supported operations are given a target resource, now that I think about it, there isn't a standardized URL for that. For ARAX and for some other implementations, the information is available at the URL like this: https://arax.ncats.io/api/arax/v1.2/openapi.json under /info/x-trapi/operations All TRAPI resources should advertise their supported operations in /info/x-trapi/operations. Unfortunately, the openapi.json may not always be available in the way that it is for us. Or maybe it is?

[edeutsch]

Note that is possible for https://arax.ncats.io/api/arax/v1.2/openapi.json : /info/x-trapi/operations to be not in sync with the code that Finn reference above. But that would be an oversight that needs to be fixed.

[isbluis]

This list of implemented operations can be found here.

Thanks, @finnagin !

I see that you have recently implemented a few more operations; is the list updated (e.g. _sort_resultsscore) ? The UI now uses this list to flag those operations that are not supported by ARAX.

[finnagin]

Thanks @isbluis ! Yeah the implemented list is updated with all the fully implemented operations. A couple of the operations I added need to be tweaked a little still but I will add them to the list when they are done.

[isbluis]

Excellent, thanks!

[dkoslicki]

This fell off the radar, being put on the AHM agenda since the purpose of this issue seems to have drifted

[dkoslicki]

Main idea: basically do workflow_to_araxi.py in reverse

[dkoslicki]

From 6/22 AHM: decided that the PSU new hire can follow up on this. It's nice to have, but not high prio