-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extra Information / Merging #77
Comments
My opinion is this: there are only two serious options on the table here (1 and 2), and the “ARAX way”, where the QueryGraph is altered to reflect the topography of the answer is not visible to anyone voting (it is implicitly hidden in 1 but I don't think this is widely understood). I think it would be better to have a 3-way vote between the 3 main options that have been proposed. I also suggest that we tackle this issue at the Relay in an extended discussion; attempting to decide this in 40-minute increments is not very efficient or effective IMO. |
By 3 way vote do you mean splitting option 1 into one version with dummy indices and one with adding to the qgraph? Would you be willing to update the slides to include the 'ARAX way'? I don't mind restarting the vote once the slides better represent the approaches, but I honestly don't know what's left to say about these, I feel like we've discussed them to death and just need to pick. |
I think that the slide update would be adding NA and _extra1, _extra2, and _extra3 to the picture of the query graph on slides 6 and 10 is what the changes would be? Is that correct? |
@edeutsch, Would the modified qgraph approach be able to support merged responses from multiple ARAs with different topographies? |
@CaseyTa yes it can - the qgraph would contain the union of all the different topographies across all ARAs and results. In each result, it's possible that not every of the new qgraph nodes/edges would be bound in that particular result. |
@cbizon Thanks. I was initially thinking this would be messy for determining which are the distinct topographies (when looking at the qgraph alone), especially if any ARAs use branched logic in their query, but this is probably no more confusing than not modifying the qgraph. |
Yes, and like I said above, the original idea is that the decision of modifying or not the qgraph is a second order question that can be decided on after the initial decision if option 1 wins. But I think that @edeutsch and @dkoslicki disagree and would rather see an option that explicitly shows modification of the qgraph. |
Adding links to recent documents outlining proposals for representing extra information in TRAPI message, as discussed on Nov 17 and Dec 1 TRAPI calls.
|
We have been discussing the question of extra information in TRAPI, which comes up in several contexts including creative mode and merging of results across ARAs. Over the course of several weeks, we have developed three options:
Option 0b: A simple option in which inference provenance is not fully tracked ❤️
Option 1: Include extra nodes and edges in the normal bindings along with extra provenance information 🚀
Option 2: include extra nodes and edges grouped together in "analysis" or "explanations" inside of a result 👀
Option 3: I don't have enough information; I need more worked examples 👎
These slides: https://docs.google.com/presentation/d/1CPJUEuWh-WxU-Fta3kof6drQC5FJX5MBcRnlDKnjog8/edit#slide=id.g146ea2e88f5_0_47 run through two examples and show what the TRAPI looks like in each case.
As pointed out on the call, the examples are written using dummy nodes, but could be updated to not make that assumption - the role of dummy nodes is not really what we're voting on here. If one of the options with dummy nodes wins, that will be a subsequent discussion.
So please vote on one of the options above adding the emoji next to your favored option on this comment. Feel free to advocate for your preferred solution below.
The text was updated successfully, but these errors were encountered: