* GaryBader - What is the definition of a group in Cytoscape?  Is it just a set? If so, what things can be in the set?  Is this correct? "A group is a set of one or more nodes (CyNode) and zero or more edges (CyEdge) that connect nodes in the group. A group can be treated as a node (CyNode) itself by being the source or target of an edge."

I said one or more nodes because I assume it doesn't make sense for a group to have zero nodes - is that true?  Maybe there is a case for a group to have zero nodes.

This is different than the hyperedge, which is a set of two or more nodes.  The hyperedge cannot contain other edges and cannot be treated as a node itself.  (I'm assuming that it doesn't make sense to create a hyperedge with 0 or 1 nodes).

 * IlianaAvila - In the interfaces I created, the word {{{group}}} is always closely tied to the relationship between a subnetwork and its containing network:

  * {{{GroupManager.addGroupToNetwork(network, subnetwork)}}}: record the fact that {{{subnetwork}}} is a group in {{{network}}}
  * {{{GroupingStrategy.group(network, subnetwork)}}}: depict {{{subnetwork}}} as a group in {{{network}}}

The reason why I don't simply call a {{{group}}} a {{{subnetwork}}} or a {{{network}}} is because the word {{{group}}} suggests that the nodes and edges contained in it are held together by a special relationship that other subnetworks in the containing network don't have. So, the word {{{group}}} could also be seen as an adjective for {{{subnetwork}}}: a {{{grouped subnetwork}}} is a subnetwork that has been deemed to be a special subnetwork (because its nodes and/or edges are related to each other in some special way) in the containing network. 
Does that make sense? I hope so...
 * MikeSmoot: I understand your point, but I worry that we're conflating the user experience with the programmer experience when deciding these terms.  It is reasonable to me that a cytoscape user would want to see dialog boxes or menu items presented in terms of groups. From the user perspective there is something special about a particular subnetwork so it seems reasonable to refer to a group as something different than a subnetwork.  However, from a programmers perspective, is the terminology necessary?  Is there any distinction that a programmer sees between a subnetwork and a group?
 * IlianaAvila - What alternative term could we use from a programmers perspective? If we use {{{subnetwork}}}, how would our interface and method names look? And, are these clear to a novice Cytoscape programmer that is trying to group subnetworks? Here is an attempt to use {{{subnetwork}}}:
  * {{{SubnetworkManager.tagSubnetwork(CyNetwork net, CyNetwork subnet); SubnetworkManager.getTaggedSubnetworks(CyNetwork net);}}}
  * {{{SubnetworkVisualizer}}}: visualize subnetworks (interface)
  * {{{SubnetworkModeler}}}: change the model to represent a subnetwork (interface) 
 

<<BR>>

would the interface make more sense if the methods looked like this?:

 * {{{GroupManager.markSubnetworkAsGroup(network,subnetwork)}}}
 * {{{GroupingStrategy.groupSubnetwork(network, subnetwork)}}}
   * MikeSmoot: Yes!  (Assuming that we stick with the grouping terminology (see my note above)  and assuming that we really aren't adding new nodes and edges to a network.)  
   * IlianaAvila - Done. I revised the API to use these new method names.
<<BR>>

 * GaryBader - Can a group be used as a CyNode?  Can I create a CyEdge that has a group as a source or target?
 * IlianaAvila - You should be able to. To depict a group as a {{{CyNode}}} you use the {{{COLLAPSING_STRATEGY}}}. Then, there needs to be a way of the user obtaining the {{{CyNode}}} that represents the group. This could be done in a number of ways. One of them could be changing the returned object of the {{{GroupingStrategy.group(network,subnetwork)}}} method from a boolean to an {{{Object}}} that the user should cast to the appropriate type.
 * That sounds like a nice feature to allow the group to be a node or not.  When you are using a compound graph, the group is always a node (as we require for BioPAX mapping).  It would be better if there was a specific method for this type of operation, since it would be common for those users using a compound graph.  Also, if the group was a node, then there would have to be a CyNode created in the model, where this would not be the case for a non-node group, which could just be created in the view.  However, this may be too complex and we may always want the group to be a CyNode (created in model and view).  The model/view separation is still not clear to me - are there some use cases that require a model, but no view (or vice versa)?