Cytoscape Wiki(note: this page is simply some ideas collected by DanielAbel, it does not signify a consensus among cytoscape developers; feel free to edit or comment.)
The Idea
current (i.e. <3.0) cytoscape has a primary selection (nodes colored yellow, by default) and a 'reverse selection' (those nodes that are selected in AttributeBrowser; by default green).
The idea came up during CytoscapeRetreat2008 that having multiple selections could be useful.
Current usage
Currently selection is used in the following ways:
- quick grouping (marking a sub-group of nodes in the network); For
- example, some clustering plugins (MCODE, etc.) use it like this, in addition, the 'reverse selection' can be used like this from the
AttributeBrowser (sort in browser according to some numerical attribute, select highest or lowest n nodes, check in graph view how that correlates with network structure)
- example, some clustering plugins (MCODE, etc.) use it like this, in addition, the 'reverse selection' can be used like this from the
- Marking the nodes to run an operation on (moving nodes, etc.); only
- the 'primary selection' is used like this. This is occasionally used by plugins to refresh some other view: selecting some nodes might automatically update some other widget showing some attributes of those nodes.
At least one plugin was mentioned during CytoscapeRetreat2008 (I think it was GLay, by Gang Su) that creates and manipulates a VisualStyle instead of the selection in order to allow it to be used with other clustering plugins (MCODE). (So that the clusters identified by GLay can be compared with the clusters identified by MCODE)
Having a single selection allows easy synchronisation of selected state, which might be useful for different plugins to inter-operate. (For example having clustering plugins which allow selection of a cluster on one widget, and select the nodes of that cluster in the main view; interoperate with a plugin that shows attributes about sub-group of nodes, for example how homogeneous they are. In this case having a single selection means that these two plugins can naturally work together seamlessly.)
On the other hand, for other types of plugins, having separate selections would be better. (Comparing clusters created with different clustering plugins.)
Open Issues
Apparently, in 3.0, selection will be an attribute and will be less hard-coded in the model or view; thus, having an arbitrary number of selections will be possible. The real questions are:
- how is selection status shown? (what happens for overlapping
- selections?) -- node color might not be the best idea, showing selection as node border might be easier and better. The node border could show multiple selections by allowing several borders around each node (sort-of "rainbow border").
- How can the user select which selections to sync and which to keep
- separate? I.e. how to avoid losing the advantages of shared selections? (one possibility is to allow plugins to define selections they want to use and have a widget where the user can select which of these are to be the same; I.e. a clustering plugin would have a 'shown-cluster' selection, another plugin could have a 'analyse-homogenity-subgroup' and the user could set both to be 'focus group 1' thereby specifying that he wants these two to be synced.)
Terminology
Using 'focus group' instead of 'selection' might be better, to avoid confusion. (And the default graph view would have a focus group called 'selection' which is the nodes and edge selected by the user.)