Cytoscape Wiki|
← Revision 10 as of 2008-01-30 17:09:28
Size: 3609
Comment:
|
← Revision 11 as of 2008-01-30 17:46:48 →
Size: 5824
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 71: | Line 71: |
|
Following are a set of assumptions that were developed with the plugin model (we kept going around in circles on various issues until we wrote up a list of our assumptions). Each assumption is considered with respect to its implications on the C3 model: 1. HyperEdges are mutable. The plugin model has mutable hyperedges with the ability to add and remove edges and nodes. Two situations where mutability is desired are: a. when you don't have all the edges, nodes and other hyperedges defined to build the complete hyperedge (especially in the chicken-or-the-egg case of connecting two hyperedges). a. when editing hyperedges--incrementally adding, removing, and connecting hyperedges to other structures. If the C3 model defines CyHyperEdges to be immutable, like CyEdges, then there must be a way to deal with a) and b) or there must be good evidence that a) and b) can be restricted. 1. A HyperEdge may have more than one CyNode with the same CyEdge interaction type. This brings up the more fundamental question of how hyperedges are semantically structured--how are parts of the hyperedge defined, referenced, and traversed? Structure is obviously needed. For example, is your are building a Krebs Cycle, you might want to define hyperedges containing products, mediators, and substrates. If you are building something else, the structuring may be completely different. Without structure, how would you ask, if the 'product' of a given hyperedge was the CyNode 'CO2'? The plugin model uses ''interaction types'' to define structure. An interaction type is just a String that represents the role a Node plays within a hyperedge (in the implementation, this translates to a CyEdge attribute named "interaction" being added to the CyEdge). These interaction types are used my many plugin model operations to allow construction and searches. For the C3 model, if no scheme is provided for structuring hyperedges, the API is certainly simplified. However, each set of users will be forced to come up with their own conventions for determining hyperedge structure and will also have to supply middleware code to construct, traverse, and search their hyperedges. |
Discussion Title : Hyperedges |
Editor(s): ... |
About this document
This document considers some of the issues with adding hyperedges to Cytoscape 3. These issues are presented by looking at the feedback and lessons learned in implementing the HyperEdgeEditor plugin.
Introduction and Terminology
A hyperedge is an Edge that connects two or more Nodes. Hyperedges may be useful for representing more complex structures like reactions and protein complexes.
Since this document makes heavy reference to the HyperEdgeAPI, a good familiarity with the existing HyperEdgeEditor plugin is essential. See the [#anchorname References] section for information on how to familiarize yourself with this plugin.
The HyperEdgeEditor plugin, adds hyperedge functionality to Cytoscape 2.6 (referred to here as the plugin model). The future Cytoscape 3 hyperedge model will be referred to as the C3 model. There is a skeleton framework for the C3 model in fastGraphCy3 trunk (http://chianti.ucsd.edu/svn/csplugins/trunk/ucsd/mes/fastGraphCy3/src/org/cytoscape/model/).
Status
How to Discuss
To view/add discussion comments, click on any of 'Comment' links below. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Try to keep the discussion as concrete and constructive as possible. Be sure to include today's date and your name for each comment.
Discussion Topic
Source of Issue
Complexities
Use Cases
Possible Solution Strategies
General Notes
References
The HyperEdgeEditor plugin adds an underlying hyperedge model (the HyperEdge API) to Cytoscpe 2.6, along with a very simple editor for creating and editing hyperedges. More information can be obtained on the HyperEdgeEditor plugin from the following sources:
See HyperEdgeAPI for more info about the underlying hyperedge model.
JavaDocs for the hyperedge model is available at [http://www.cytoscape.org/agilent/build/api-docs/index.html Java HyperEdge API Java Documents].
Source code for hyperedge model is available via SVN from grenache.ucsd.edu/cellar/common/svn/csplugins/trunk/agilent/creech/HyperEdge.
See cytoscape.hyperedge.HyperEdge for an overall description of terms and assumptions.
Source code for the hyperedge editor is available via SVN from grenache.ucsd.edu/cellar/common/svn/csplugins/trunk/agilent/creech/HyperEdgeEditor
Once the HyperEdgeEditor is loaded, two sample hyperedge networks via File->Import->HyperEdge Sample Networks. This will build two hyperedge networks--Glycolysis Reaction network and a Krebs Cycle network. You can look at the source code that generates these two networks in cytoscape.hyperedge.editor.SampleNetworks.java
Discussion
Following are a set of assumptions that were developed with the plugin model (we kept going around in circles on various issues until we wrote up a list of our assumptions). Each assumption is considered with respect to its implications on the C3 model:
HyperEdges are mutable.
- The plugin model has mutable hyperedges with the ability to add and remove edges and nodes. Two situations where mutability is desired are:
- when you don't have all the edges, nodes and other hyperedges defined to build the complete hyperedge (especially in the chicken-or-the-egg case of connecting two hyperedges).
- when editing hyperedges--incrementally adding, removing, and connecting hyperedges to other structures.
If the C3 model defines CyHyperEdges to be immutable, like CyEdges, then there must be a way to deal with a) and b) or there must be good evidence that a) and b) can be restricted.
A HyperEdge may have more than one CyNode with the same CyEdge interaction type.
This brings up the more fundamental question of how hyperedges are semantically structured--how are parts of the hyperedge defined, referenced, and traversed? Structure is obviously needed. For example, is your are building a Krebs Cycle, you might want to define hyperedges containing products, mediators, and substrates. If you are building something else, the structuring may be completely different. Without structure, how would you ask, if the 'product' of a given hyperedge was the CyNode 'CO2'?
The plugin model uses interaction types to define structure. An interaction type is just a String that represents the role a Node plays within a hyperedge (in the implementation, this translates to a CyEdge attribute named "interaction" being added to the CyEdge). These interaction types are used my many plugin model operations to allow construction and searches.
For the C3 model, if no scheme is provided for structuring hyperedges, the API is certainly simplified. However, each set of users will be forced to come up with their own conventions for determining hyperedge structure and will also have to supply middleware code to construct, traverse, and search their hyperedges.