Display for Treats Edge for Creative Mode Results

[sstemann]

Alumni pointed out that when they read "treats" in the UI they assume that somewhere in the evidence Translator has this as a direct relationship. There are probably several ways this can be addressed. Deferring to UI team

Sometimes treats has all KS's Evidence

Sometimes treats has both KS's and ARA Evidence

Sometimes treats has just ARA

[gprice1129]

We think the first step to solving this issue is to make the distinction between inferred edges and support graphs that back those edges crystal clear on the UI.

[Genomewide]

@sstemann , @gprice1129 is right. We are working on new designs to resolve this. this also related to the 'change treats to 'may treats'' issue. I think we want to consider them in the same solution.

[mbrush]

Hi @Genomewide, @gprice1129, @dnsmith124 . Seeing several ticket come through after the Relay related to the issue of distinguishing the different types of paths that show up in the current support paths section of the
UI, and other closely related issues (e.g. #563, #263, #281, O&O #30)

Glad to see these topics coming to the fore - as you know I've been pushing for a reorg in this area for a while, and it seems we are now ready do make it happen!

Putting a few thoughts down in this ticket just to get eyes on them - about distinctions at several levels that I think should be made clear to improve user understanding and experience:

1. At the 'Edge' level: indicate knowledge level and agent type of Edges in graphs/paths displayed in the UI.
2. At the 'Support Path' level: distinguish Paths representing 'answer edges' (a source's statement of the result, which will be just a 'treats' edge from chemical to disease), from Paths representing the source's evidence/reasoning behind such a result (usually 2- or 3-hop paths, but in some cases a single hop).
3. At the 'Result' level: distinguish when a Result is based on answer edges representing established facts (curated knowledge assertions), vs inferences (computational predictions), vs text mined statements, vs some combination of these categories . . . and allow filtering/faceting on this information
4. At the 'Score' level: we need to decide if a uniform scoring definition and scale will be applied to Results based on these these three key categories of answers (i.e. how should we score results based only on ARA inference/prediction relative to scores based only on curated assertions, or text mined results, or combinations of these).

Where things stand now, I think we have or are very close to having the following elements in place that IMO are needed for a solution:

1. A shared terminology for describing these concepts /distinction (to be used consistently in communication and documentation, in naming properties and enums in the model, and in the tags/symbols shown to users in the UI)
2. A model to support representation of these distinctions in the data
3. UI functionality to be able to graphically display and filter/facet on these distinctions

What I don’t think we have yet is a decision/plan for the question of how to score and sort inferred results relative to lookup results, or text mined, etc.). But this issue could be made moot depending on how we address distinctions at the other levels above.

Sorry - this is a lot to consider all at once, and I know you all can't tackle it all at once. But these issues/distinctions (and the solutions for capturing them) are very interconnected - so it helps to consider them together, as we address one at a time.

I am in the process of writing up a summary of thoughts from myself and others about all this, and drafting some mock ups of some of possible UI features may inform your thinking. A work in progress, but would love to share them with your team before work on UI refactoring moves too far along.

[gprice1129]

Closing this issue. If you feel strongly it hasn't been addressed please re-open.