search

geneontology / noctua

Graph-based modeling environment for biology, including prototype editor and services
http://noctua.geneontology.org/
BSD 3-Clause "New" or "Revised" License
37 stars 12 forks source link

Meaningful glyphs for edges #18

Closed huaiyumi closed 7 years ago

huaiyumi commented 10 years ago

activate - arrow -> inhibition - bar -| neutral, such as upstream - diamond -<>

kltm commented 10 years ago

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

kltm commented 10 years ago

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

kltm commented 10 years ago

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

kltm commented 10 years ago

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

cmungall commented 10 years ago

bar

arrow

diamond

cmungall commented 10 years ago

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

cmungall commented 10 years ago

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

kltm commented 10 years ago

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

kltm commented 10 years ago

closing as only configuration in current state

kltm commented 7 years ago

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 (->)
kltm commented 7 years ago

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.

huaiyumi commented 7 years ago

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

image
kltm commented 7 years ago

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?

huaiyumi commented 7 years ago

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.

cmungall commented 7 years ago

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)

huaiyumi commented 7 years ago

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.

thomaspd commented 7 years ago

I agree we don’t want to conflate editor requirements with end-user viz requirements. But my original email referred specifically to editor requirements. I think just distinguishing between those three types (at a minimum) will be very helpful for editors, with the added bonus that they will also help anyone who views the graphs. Huaiyu’s email suggested to me that we should add a fourth type, with a diamond at the end, to indicate a causal relation where the directionality (positive or negative) is not specified.

Thanks, Paul.