Skip to content
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

Open
cbizon opened this issue Aug 23, 2022 · 8 comments
Open

Extra Information / Merging #77

cbizon opened this issue Aug 23, 2022 · 8 comments

Comments

@cbizon
Copy link
Collaborator

cbizon commented Aug 23, 2022

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.

@edeutsch
Copy link
Collaborator

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.

@cbizon
Copy link
Collaborator Author

cbizon commented Aug 24, 2022

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.

@cbizon
Copy link
Collaborator Author

cbizon commented Aug 25, 2022

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?

@CaseyTa
Copy link
Collaborator

CaseyTa commented Aug 25, 2022

@edeutsch, Would the modified qgraph approach be able to support merged responses from multiple ARAs with different topographies?

@cbizon
Copy link
Collaborator Author

cbizon commented Aug 26, 2022

@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.

@CaseyTa
Copy link
Collaborator

CaseyTa commented Aug 26, 2022

@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.

@cbizon
Copy link
Collaborator Author

cbizon commented Aug 26, 2022

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.

@mbrush
Copy link

mbrush commented Dec 1, 2022

Adding links to recent documents outlining proposals for representing extra information in TRAPI message, as discussed on Nov 17 and Dec 1 TRAPI calls.

  • LucidChart Diagrams illustrating a rich CM query and results merging scenario, on which data examples illustrating modeling proposals will be based - see here (you need to have/create Lucidchart account to view . . . ping me if you want a static pdf)
  • A data example representing this scenario as TRAPI json - see here
    • . . . as of Dec 1 only the message sent form ARAGORN to the ARS in the scenario is provided. The messages from ARAX to the ARS, and from the ARS to the UI (which holds the merged Result and supporting / extra info) are forthcoming.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants