Introduce groups

[adrienrougny]

https://groups.google.com/forum/#!topic/sbgn-discuss/PXd-1YnlQi8

[hasanbalci]

Has this been discussed at all since 2018? The discussion above mentions that groups were dropped from SBGN PD L1V2 but I couldn't see them in SBGN PD L1V1.3 as well.

[hasanbalci]

Voting results on this issue:

Creating groups in SBGN maps

In SBGN 2.5, our first "hackathon" in Heidelberg, we discussed the possibility of "group", which would be structures putting together sets of nodes, without changing the semantics of the map. At that time, it was suggested for Process Descriptions, in order to implement "pathways". At the first SBGN competition, Bernard de Bono submitted an impressive ER map that also used such a feature. The discussion was continued on sbgn-discuss, see the very interesting and complete thread at 1. The discussion was resumed at HARMONY 2011, where it was felt to be mature enough to give rise to a vote.

The idea is to have a mechanism to "tag" an SBGN glyph as belonging to one or several groups. Those groups would correspond for instance to "pathways" or "metabolic network", glyphs associated with a disease or biological function. A group is not a compartment, and it is not a submap. It does not affect the syntax of the map, but is merely a multi-glyph annotation.

Groups would be a way for instance to organise nodes together in a certain subpart of the plan, or highligtht them in some way. Software would have to conserve groups, and it could thus be a way to lightly constrain the layout, without going all the way to specify position and size of the nodes. A group would not be "linked" to any node using edges, but would "contain" EPN/PN in PD, EN in ER, AN in AF (i.e. in PD and AF, a group could span several compartment). Groups could be named and could be annotated with "floating" annotations, similarly to the default compartment.

---

This vote is now closed. 11 votes have been filed. The results are:

Question 1. Are-you in favour of introducing a "group" feature in SBGN languages?

Choice	Votes	Fraction
Yes	10	90.9%
No	1	9.1%
I do not know	0	0%

Decision: The creation of groups will be introduced in the three SBGN languages.

Question 2: Should-we specify the way a group is displayed?

Choice	Votes	Fraction
Yes	7	63.6%
No	4	36.4%
I do not know	0	0%

Comments:

• In fact, to me, a "submap" in a PD diagram is a grouping as well.
  If we let submaps to be specified (whatever the way we choose - Q3 of this survey) when they are not collapsed, then submaps could be handled just like the way other types of groups are (so the two concepts could be merged). Compartments, on the other hand, are also groups but they are so special and significant that we prefer to classify and specify them distinctly.
• Maybe with several options. But people and tools need to know what to look for.
• SBGN is all about the graphical representation. Every feature should therefore also represent graphically, and it should be done in a standardized way.
• The representation should be different enough to prevent misinterpretation of the diagram.

Decision: the way of representing groups will be specified.

Question 3: If we were to advise a way to represent groups, what should it be (multiple answers possible)?

Choice	Votes	Fraction
A spatial grouping	4	36.4%
A contour	7	63.6%
A background	8	72.7%
Highlighting glyps	4	36.4%
Unsure	2	18.2%
None of the above	0	0%

Comments:

• This needs further discussion but a convex hull that tightly bounds all group members with a transparent background and possibly a contour could be used. Notice however that we should definitely allow overlapping of groups as one might like to show grouping w.r.t. biological function as well as grouping w.r.t. pathway abstractions.
• Representing groups through layout (spatial grouping, and to some extent, contour and background) is likely to become very difficult with large pathways (there's other layout constraints to take into account: compartments, + limiting edge crossing, etc.). Individual glyph highlights (color?) seem preferable (as graphically, the feature is fully "perpendicular" to the other containment idea expressed spatially by compartments)
• layout should not carry any meaning (therefore no spatial grouping), colour should not carry meaning (no background or highlighting)

Decision: The responses to this question are more nuanced. However, because of the result of Q2, we must take a decision. Since contour and background came clearly first, the editors decided to go for a background for the time being. In the future, explorations will be done to see if we can allow contours as well (Still allowing the backgrounds).