Meaningful glyphs for edges about noctua HOT 17 CLOSED

This mostly was added in last push (bar, arrow, wedge, diamond), but I need someone to give a default (maybe a teeny wedge) and go through the used parts of the RO...

from noctua.

@huaiyumi , could you make a very short list of which of the most likely used RO relations would fall under the three categories that you initially listed?

from noctua.

Could use Custom to make other limited shapes as well, but given the mechanism, they might start looking wonky pretty fast.

from noctua.

Marking as "upstream" since the remaining bits that need to be worked out should be between @huaiyumi and @cmungall .

from noctua.

bar

• RO:0002212 negatively regulates
• RO:0002408 directly inhibits

arrow

• RO:0002213 positively regulates
• RO:0002406 directly activates

diamond

• RO:0002413 directly provides input for

from noctua.

@huaiyumi what do you suggest for the indirect forms of these relations? Keep the endpoint glyph constant but make the edges dotted/dashed?

from noctua.

Note too self: add this is metadata to RO, derive json from there

from noctua.

Technically fixed now as described, but leaving open until we get feedback from @huaiyumi .

from noctua.

closing as only configuration in current state

from noctua.

From @thomaspd ; current minimal working subset:

 A really nice thing for visualization, both in the figures (3 and 4) and in Noctua, would be to have meaningful symbols at the termini of all edges in the graph:

    any “positively regulates” relations (or its children) should have a solid arrowhead (filled triangle)
    Any “negatively regulates” (or children) should have a bar (-|)
    Any other relation should have an open arrowhead (->)

from noctua.

For those interested in having edge glyphs in Noctua, I'd like to review a bit of history.

At one point, early on, Noctua did have the edge glyphs. Starting with just the obvious "arrow" to indicate direction, more were added. Unfortunately, what was available (I believe circle, ellipse, triangle, diamond, rectangle, square, with "line" being simulated with a degenerate form of one of the others) did not map cleanly onto what was desired. In the end, we took them away because it was decided that it would be "too confusing" if not perfect. In fact, even the simple "arrow" was taken away as that had an implied meaning for some users. In practice, this was apparently true--there have been less complaints, and besides the occasional question question about which way an edge is going, people have not been vocal.

Theoretically, we could overload what is available in our toolkit library and have our own, but for the sake of expediency we went with what was available. As well, it's worth nothing that the glyphs were not particularly nice looking, which probably did not help.

I've wanted to get these back in for a while, they may look a little better this time around, but I think it's important to agree on a minimal working set when moving forward.

from noctua.

I suggest that our edges be consistent with the modulating arcs in SBGN.

from noctua.

necessary stimulation in unlikely to be easily doable. As well, I'm not sure what the last two are.
Also, as an issue from the past, how would we show the direction of an edge for something like part of?

from noctua.

We probably only have the first 3. The last two are logic arcs, such as 'and', 'or', etc. We don't have them in LEGO right now.

from noctua.

It strikes me we may be conflating requirements for editing with requirements for end-user visualization.

I'm not sure having the glyphs above is such a high priority for GO editors at this stage (others should weigh in; for me the main thing is clearly distinguishing the start from the end, which I always get confused)

For end-users, we know we won't use jsplumb, we'll use cytoscape.js, or one of the derivatives like SBGNViz.js. Here is example of SBGNViz, all the required arrowheads should be there: http://www.cs.bilkent.edu.tr/~ivis/SBGNViz.js/sample-app/#

(Of course, eventually we want to blend end-users into editors, but one step at a time)

from noctua.

I agree that the SBGN symbols are for end users, but it probably helps the editors if the edges are consistent in the curation tool if it is not too much work. Of course, it is less critical.

from noctua.

from noctua.