← Revision 41 as of 2006-03-02 17:15:58
Size: 6510
Comment:
|
← Revision 42 as of 2006-03-02 20:34:17 →
Size: 6855
Comment:
|
Deletions are marked like this. | Additions are marked like this. |
Line 2: | Line 2: |
* /CommentSemantics (is {{{Group}}} a good word to use? what other wording would you suggest?) |
|
Line 46: | Line 48: |
* Would having {{{ModelGroupingStrategy}}} and {{{ViewGroupingStrategy}}} interfaces meet your model-view separation? If so, I can't think of how the methods in these interfaces would be different, but for conceptual clarity, we could do this. |
Please review the Java-Docs at http://db.systemsbiology.net/cytoscape/grouping/doc/ and comment.
/CommentSemantics (is Group a good word to use? what other wording would you suggest?)
To give you a better idea of how the interfaces work together, here is an example:
// Example 1. Algorithm calculated groups: CyNetwork [] groups = someAlgorithm.calculateGroups(someArgs); groupManager.addGroupsToNetwork(myNetwork); GroupingStrategy collapsingStrategy = GroupingStrategyFactory.createGroupingStrategy(GroupingStrategyFactory.COLLAPSING_STRATEGY); GroupingStrategy stackingStrategy = GroupingStrategyFactory.createGroupingStrategy(GroupingStrategyFactory.STACKING_STRATEGY); for(int i = 0; i < groups.length; i++){ // Layout the nodes in a column stackingStrategy.group(myNetwork,groups[i]); if(groups[i].nodeCount() > SOME_LIMIT) // collapse groups that are too large collapsingStrategy.group(myNetwork,groups[i]); }
Notes:
I decided to name the interfaces in this API using the group word instead of the MetaNode word. A MetaNode is a way of grouping nodes/edges in a graph. The more general concept is grouping.
The GroupingManager is an interface to the data structure that stores groups for Cytoscape networks. We have not decided what data structure will do this. Alternatives that have been mentioned in the past are:
CyAttributes
CyNodes (as it is done currently)
- A new data structure
Here is my opinion on each:
CyAttributes Requires that a node (if we use node CyAttributes) or an edge (if we use edge CyAttributes) be created per group. Only in one case (COLLAPSING_STRATEGY) is a node per group needed. The other grouping strategies do not need new nodes or edges. Additionally, there is no safe way of storing information that tells us to which network a group belongs, since the node that functions as a key in CyAttributes can be manipulated very easily by users (removing it, adding it to a new network, etc).
CyNode Also requires a node per group. This was originally done because when we were designing the GINY API, we were not thinking of the more general grouping problem. We were thinking of MetaNodes only.
A new data structure. This could be a data-structure that resembles CyAttributes (some sort of map structure) but that does not require the creation of a node per group. Also, this data structure would be hidden, so that the only way of interacting with it is GroupingManager. I vote for this.
Comments:
AllanK: Does the GroupingStrategy, as it is currently defined, conflate the model and the view? Should model-oriented strategies be orthogonal to view-oriented strategy? It seems to me that COLLAPSING_STRATEGY should be applicable to STACKING_STRATEGY and the other view-oriented strategies. That is, wouldn't one want to be able to collapse and expand a stacked group in the same manner in which you'd want to collapse and expand a non-stacked group?
- Iliana: Yes, you should be able to collapse a stack. See the sample code above.
- AllanK: Then would it really necessary to have a model-oriented option like COLLAPSING_STRATEGY, at least at the model level? That is, if all the other strategies allow collapsing, then do we need a collapsing option? If we didn't, then we could treat all grouping strategies are view-oriented, which might be cleaner. If we did need some model-oriented grouping strategies, then I wonder if it might be cleaner to keep them separated from the view-oriented grouping strategies.
Would having ModelGroupingStrategy and ViewGroupingStrategy interfaces meet your model-view separation? If so, I can't think of how the methods in these interfaces would be different, but for conceptual clarity, we could do this.
AllanK: This is related to the issue above. Should groups be inherently hierarchical? Would that simplify the object model? Are there any situations where you would not want to be able to nest groups? I can certainly see that in the STACKING_STRATEGY people will likely want the ability to hierarchically compose these stacks and have the ability to alternative vertical and horizontal partitioning.
- Iliana: Nested grouping could be done like this:
// Example 2. Creating nested groups CyNetwork subgroup = methodThatGetsASubgroup(); CyNetwork [] groups = groupManager.getGroupsInNetwork(myNet); Map args = new Hashtable(); for(int i = 0; i < groups.length; i++){ if(groups[i].getIdentifier().equals(SOME_NET_ID)){ groupManager.addGroupToNetwork(groups[i], subgroup); // nest a group // recursive collapse: args.put(CollapsingStrategy.IS_RECURSIVE, Boolean.TRUE); collapsingStrategy.group(myNet,groups[i],args); // collapses the nested group // OR, stack subsubgroup, collapse subgroup: args.put(CollapsingStrategy.IS_RECURSIVE, Boolean.FALSE); stackingStrategy.group(groups[i],subgroup); // stack nested group collapsingStrategy.group(myNet,groups[i],); // collapse top level group } } // This is code in a GroupingStrategy: public boolean group (CyNetwork network, CyNetwork subnetwork, Map args){ if(args.containsKey(IS_RECURSIVE) && args.get(IS_RECURSIVE).equals(Boolean.TRUE)){ // recursive grouping, use GroupManager.getGroupsInNetwork to get groups within groups... CyNetwork [] subsubgroups = groupManager.getGroupsInNetwork(subnetwork); // .. do stuff }else{ // non-recursive, do stuff... } }
AllanK: I wonder if the spelling of the method getGroupedInNetworks() may be a little awkward? Should we use an alternative spelling such as getContainingNetworks()?
Iliana: I changed it to getContainingNetworks(). Thanks.
AlexP: The thorough documentation makes this all much more transparent. Thanks, Iliana. I like the more generic "grouping" terminology. It fits well with the limited goals of metanodes in 2.3. Concerning theGroupingManagerand the issue of data structure, I am not expert enough to have a full vote, but your reasoning seems sound (e.g., hidden is safer).
- Kristina: I am wondering how the three different data structures mentioned above would each work in coloring the metanode based on the underlying child nodes. If there is for example expression data available for each of the nodes in the metanode, then we would want the metanode to be colored based on these colors, for example in a striped manner or with the average color. It is not clear to me if the two data structures mentioned first (which require a node be created) would pose a problem in this kind of coloring.