Diff for "Outdated_Cytoscape_3.0/HyperEdges"

TableOfContents([2])

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:

1. See HyperEdgeAPI for more info about the underlying hyperedge model.

2. JavaDocs for the hyperedge model is available at [http://www.cytoscape.org/agilent/build/api-docs/index.html Java HyperEdge API Java Documents].

3. 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.

4. Source code for the hyperedge editor is available via SVN from grenache.ucsd.edu/cellar/common/svn/csplugins/trunk/agilent/creech/HyperEdgeEditor

5. 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:

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:

   1. 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).
   2. 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.

2. A Hyperedge may have more than one CyNode with the same CyEdge interaction type.

   1. Hyperedge semantic structure

      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 you 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.

   Given this definition of interaction types, this assumption states that a hyperedge may have two different CyNodes with the same interaction type. This is needed for situations like NEED EXAMPLE HERE.

3. A Hyperedge may have more than one CyEdge to the same CyNode. In some Reactions, a component can play multiple roles in the same reaction. For example, in the Glycolysis reaction, Ca2+ acts as both an inhibiting and activating modulator for pyruvate kinase I.

   The plugin model handles this assumption by the fact that a hyperedge may contain two or more CyEdges to the same node--each with a different interaction type.

   For the C3 model, this implies that a CyHyperEdge cannot simply consists of a List of Source and Target CyNodes. We need to be able to manage link attribute interaction type information with the link to a specific Node. So, in the above example, a hyperedge would have two (sub)edges to the CyNode "Ca2+", one with one attribute type (e.g., inhibiting) and the other with a different attribute type (activating) and we would need to be able to choose one and manipulate it independent from the other.