Cytoscape Wiki|
Size: 1116
Comment:
|
Size: 5576
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 10: | Line 10: |
|
I have included a [attachment:Cytoscape3.cys Cytoscape session file] that demonstrates the class hierarchy. The session includes a custom Link Out URL that will pull up the JavaDoc file for that interface. I have currently written proposed interfaces for CyNetwork, CyNode, CyEdge, CyModeObject, CyGroup, CyProject, and CyModelObject. Here is an image from the session: attachment:Cytoscape3ClassHierarchy |
I have included a [attachment:Cytoscape3.cys Cytoscape session file] that demonstrates the class hierarchy. The session includes a custom Link Out URL that will pull up the [http://lewis.compbio.ucsf.edu/Cytoscape3.0/doc/index.html JavaDoc] file for that interface. I have currently written proposed interfaces for CyNetwork, CyNode, CyEdge, CyModeObject, CyGroup, CyProject, and CyModelObject. Here is an image from the session: attachment:Cytoscape3ClassHierarchy.png |
| Line 16: | Line 14: |
|
{{{ Hi Scooter - this looks great! Questions and comments below. Thanks, Gary. Overall model ============ We should add CyHyperedge. Also, CyGroup and CyHyperedge shoudl extend CyModelObject. This will make it easier to write general methods like getSelected, which can apply to any network object. CyNetwork should not extend CyModelObject since you don't want to add a network to a network. Also, maybe change CyModelObject to CyNetworkObject. CyModelObject ============= is clone a deep copy? getIdentifier() - will this be unique across all CyModelObjects within a Cytoscape session? This could be useful for e.g. storing objects in hashes. What's the use case for getAttribute(java.lang.String attributeName)? CyNetwork ========= Should there be a remove change listener? Naming: use List instead of plurals? E.g. addEdgeList instead of addEdges. A list can contain one object and addEdge is very close to addEdges, so could be confusing. Should there be an addGroupList method? Should the CyNetwork be a factory for nodes, edges, etc.? If so, shouldn't the object be immediately added to the network? (some of the javadoc is not clear on this policy) Hyperedges should not be included in edges - they should be their own object, just like groups is separate. Overloading CyEdge with hyperedge will make simple graph algorithms much more complex to implement because you will have to check in many places to make sure you're not using a hyperedge edge. We should evaluate the Agilent hyperedge object for model inclusion as CyHyperedge. getDegree must include undirected, in, out. In general, we should probably have clearer separation between undirected and directed edge methods e.g. getDegree would give you everything, getDegreeIn, getDegreeOut, getDegreeUndirected (or use an enum to filter) would give you specific results. Same things with all edge methods, edgecount, getedgelist. Right now you can only filter with some methods and you can't specify to get only undirected. Naming: getEdgesList -> getEdgeList (avoid all use of plurals in all packages) Why is hide part of CyNetwork - should it only be part of the view? We may want to remove this altogether and just use remove/add Use case for isNeighbor? It could be useful, but maybe better as a utility method. Why not use the CyModelObject here? - can you not select groups and hyperedges? boolean isSelected(CyEdge edge) boolean isSelected(CyNode node) same thing goes for add, remove, unselect, etc. Don't think we need selectAllNodes, edges in there, as they are utility methods. Same with unselect. You can easily select all using setSelectedEdgeState + getNodeList. createEdge - change 'interaction' parameter to edgeType, or similar. CyNode ====== Group methods should only be in CyGroup, not in CyNode. Some of the methods in various packages are missing their return type. CyEdge ====== Again, remove hyperedge methods to simplify this. getInteraction() - should be getEdgeType. How will this be related to identifier? Is the edge type part of the ID like 2.x? I don't think it should, since this causes a lot of confusion. Need to be able to filter by edge type in getTarget type methods - source, target and none for the undirected case. This would be another good place for a global edge enum type: in, out, undirected. CyGroup ======= GetState - what is this? getViewer() returns string - should this be a groupviewer? CyGroupViewer ============= Shouldn't a viewer just register for a group change event? Maybe change listener should be on CyModelObject? CyNetworkChangeListener ======================= Should we have more enums for types of changes, like CyGroupViewer.ChangeType? We could just have all of these in one place. CyProject ========= addManipulation - too granular? Can we use comments for this? If necessary, we could add a type of comment, allowing attribute/value pairs. What does addFile do with the file once it's added? getname, but no setname? Should we be able to have subprojects? E.g. most IDEs have this. Where is the active state of the project set? There is no setActive method. setProjectPath - is this the name of the file storing the project? CyAttributes ============ Has anything changed here from the current CyAttributes? }}} |
Discussion Title : Cytoscape 3.0 Model |
Editor(s): ScooterMorris |
About this document
This document should serve to begin the discussion about the Cytoscape 3.0 model. At the 2007 Retreat, it was agreed that we would investigate a new class model for Cytoscape objects to replace the current, complicated combination of cytoscape, giny, ding, and fing models that currently provide the API for Cytoscape. Our goal at this point should be to design a model that provides a clean interface to cytoscape objects and provides the cleanest interface we can imagine for plugin writers.
General Notes
References
I have included a [attachment:Cytoscape3.cys Cytoscape session file] that demonstrates the class hierarchy. The session includes a custom Link Out URL that will pull up the [http://lewis.compbio.ucsf.edu/Cytoscape3.0/doc/index.html JavaDoc] file for that interface. I have currently written proposed interfaces for CyNetwork, CyNode, CyEdge, CyModeObject, CyGroup, CyProject, and CyModelObject. Here is an image from the session: attachment:Cytoscape3ClassHierarchy.png
Discussion
Hi Scooter - this looks great! Questions and comments below. Thanks, Gary. Overall model ============ We should add CyHyperedge. Also, CyGroup and CyHyperedge shoudl extend CyModelObject. This will make it easier to write general methods like getSelected, which can apply to any network object. CyNetwork should not extend CyModelObject since you don't want to add a network to a network. Also, maybe change CyModelObject to CyNetworkObject. CyModelObject ============= is clone a deep copy? getIdentifier() - will this be unique across all CyModelObjects within a Cytoscape session? This could be useful for e.g. storing objects in hashes. What's the use case for getAttribute(java.lang.String attributeName)? CyNetwork ========= Should there be a remove change listener? Naming: use List instead of plurals? E.g. addEdgeList instead of addEdges. A list can contain one object and addEdge is very close to addEdges, so could be confusing. Should there be an addGroupList method? Should the CyNetwork be a factory for nodes, edges, etc.? If so, shouldn't the object be immediately added to the network? (some of the javadoc is not clear on this policy) Hyperedges should not be included in edges - they should be their own object, just like groups is separate. Overloading CyEdge with hyperedge will make simple graph algorithms much more complex to implement because you will have to check in many places to make sure you're not using a hyperedge edge. We should evaluate the Agilent hyperedge object for model inclusion as CyHyperedge. getDegree must include undirected, in, out. In general, we should probably have clearer separation between undirected and directed edge methods e.g. getDegree would give you everything, getDegreeIn, getDegreeOut, getDegreeUndirected (or use an enum to filter) would give you specific results. Same things with all edge methods, edgecount, getedgelist. Right now you can only filter with some methods and you can't specify to get only undirected. Naming: getEdgesList -> getEdgeList (avoid all use of plurals in all packages) Why is hide part of CyNetwork - should it only be part of the view? We may want to remove this altogether and just use remove/add Use case for isNeighbor? It could be useful, but maybe better as a utility method. Why not use the CyModelObject here? - can you not select groups and hyperedges? boolean isSelected(CyEdge edge) boolean isSelected(CyNode node) same thing goes for add, remove, unselect, etc. Don't think we need selectAllNodes, edges in there, as they are utility methods. Same with unselect. You can easily select all using setSelectedEdgeState + getNodeList. createEdge - change 'interaction' parameter to edgeType, or similar. CyNode ====== Group methods should only be in CyGroup, not in CyNode. Some of the methods in various packages are missing their return type. CyEdge ====== Again, remove hyperedge methods to simplify this. getInteraction() - should be getEdgeType. How will this be related to identifier? Is the edge type part of the ID like 2.x? I don't think it should, since this causes a lot of confusion. Need to be able to filter by edge type in getTarget type methods - source, target and none for the undirected case. This would be another good place for a global edge enum type: in, out, undirected. CyGroup ======= GetState - what is this? getViewer() returns string - should this be a groupviewer? CyGroupViewer ============= Shouldn't a viewer just register for a group change event? Maybe change listener should be on CyModelObject? CyNetworkChangeListener ======================= Should we have more enums for types of changes, like CyGroupViewer.ChangeType? We could just have all of these in one place. CyProject ========= addManipulation - too granular? Can we use comments for this? If necessary, we could add a type of comment, allowing attribute/value pairs. What does addFile do with the file once it's added? getname, but no setname? Should we be able to have subprojects? E.g. most IDEs have this. Where is the active state of the project set? There is no setActive method. setProjectPath - is this the name of the file storing the project? CyAttributes ============ Has anything changed here from the current CyAttributes?