Differences between revisions 58 and 59
← Revision 58 as of 2007-05-25 19:08:02 →
Size: 11503
Editor: cosiapat1
Comment:
← Revision 59 as of 2007-05-25 19:14:24 →
Size: 11669
Editor: cosiapat1
Comment:
Deletions are marked like this. Additions are marked like this.
Line 126: Line 126:
 1. 'Coordinate System'. This is kind of like a Legend in Cytoscape, except that it may need to update itself upon panning or zooming.  1. 'Coordinate System'. This is kind of like a Legend in Cytoscape, except that it may need to update itself upon panning or zooming.  Perhaps this could be implemented as a graphical annotation whose Component listens for Viewport''''''Change events and repaints itself with the appropriate labels.

Molecular Interaction Maps

Editor(s): Allan Kuchinsky

TableOfContents([2])

About this document

This is an official Request for Comment (RFC) for Supporting Molecular Interaction Maps in Cytoscape.

For details on RFCs in general, check out the [http://www.answers.com/main/ntquery?method=4&dsid=2222&dekey=Request+for+Comments&gwp=8&curtab=2222_1&linktext=Request%20for%20Comments Wikipedia Entry: Request for Comments (RFCs)]

Status

* preliminary draft, still brain-dead, take with a grain of NaCl.

How to Comment

To view/add 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. Be sure to include today's date and your name for each comment. Here is an example to get things started: ["/Comment"].

Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.

Proposal

A Molecular Interaction Map (MIM) is a diagram convention that is capable of unambiguous representation of networks containing multi-protein complexes, protein modifications, and enzymes that are substrates of other enzymes. MIMs are described in detail at http://discover.nci.nih.gov/mim/index.jsp and in a seminal article by Kohn et al at http://www.molbiolcell.org/cgi/content/abstract/E05-09-0824v1

An example MIM is below attachment:mim_eg.png

MIMs have been developed at the National Cancer Institute (specifically the Laboratory of Molecular Pharmacology). They are looking into what it would take to develop an Editor to create Molecular Interaction Maps (MIMs) in an editor to yield both a graphical view and a computer-readable format (preferrably BioPax). They are interested in seeing if such a MIM editor could be developed for Cytoscape.

MIM symbols are defined in the figure below:

attachment:Kohn_SymbDefH3.jpg

QUESTION: Is this the most recent definition of map symbols? In particular, are site-specific constructs, such as cleavage, still defined as requirements? ANSWER:There are a few changes. CovalentBinding has a new symbol. There are some requirements for site-specific constructs. There are a few additional symbols as well.

This proposal will specify the mapping between MIM constructs and their proposed counterparts in Cytoscape. A prioritized set of requirements will be presented. Enhancements needed in the editor, renderer, and/or other Cytoscape components will be identified.

Biological Questions / Use Cases

/MimEditorUseCaseComments

Kohn Notation Use Cases

Editor System Use Cases

General Notes

From an initial reading of the article by Kohn et al at http://www.molbiolcell.org/cgi/content/abstract/E05-09-0824v1, an initial description of potential mappings between MIM and Cytoscape constructs was derived. This is summarized in the figure below.

A newer version of the description of the notation is found in Kohn et al http://mct.aacrjournals.org/cgi/rapidpdf/1535-7163.MCT-06-0640v2

attachment:kohn_mappings.png

Further Notes from meeting at 2006 Cytoscape Developers Retreat

  • Need to map MIM to both model and view
    • How to represent 'non covalent binding'?
      • Model: Best mapped to a group. A and B are connected and are part of the group.
      • View: this is a use case for the group view
    • Asymmetric binding
      • Model: Regular edge between A and B, just needs a specific edge type
      • View: New type of custom edge graphic (will take some care with Nerius' edge drawing code)
    • Representation of multimolecular complexes
      • Model: A group of groups
      • View: part of the use case for group view
    • Covalent modification of protein A (post-translational modification = PTM)
      • Model: A is a node (representing unmodified protein); central node is a node (represented modified A) - every state is represented as a node. The PTM e.g. P is not a node, it is an annotation on the 'central' state node. The edge between A and its state is of type 'state of'. The set of all states is grouped to represent the set of all states of A.
      • View: Constraint: the states always move together (would be like a template)
    • Cleavage of of a covalent modification of protein A
      • Model: Hyperedge containing node1: Phtase (hyperedge attribute: enzyme), node2: phosphorylated A, node3: unphosphorylated A
      • View: Use case for hyperedge view
  • General constraints for automatic layout and the editor
    • Snap to grid
    • All lines need to be routed with only right or acute angles
    • Central node is only there if it is used (connected to something else in the diagram)
  • Next step: a special interest group should get together to hash the above out further. Current interested people are: Allan, Mirit, David, Gary, Aditya, Scooter, Alex; also general interest from Nathan, Kristina (GenMAPP editing), Ethan, Ben (BioPAX editing)
  • Implementation: Cytoscape core would ensure that the model and view requirements are met. Users: like GenMAPP, MIM, BioPAX editing would use the core functionality to create their own plugins that implemented their own pathway editing features.

Requirements

The following set of requirements is drawn from a consolidation of comments on the use cases. The requirements fall into two categories:

  • Infrastructure: changes required to underlying Cytoscape functionality, such as modifications to the renderer.
  • Customization: changes that require new functionality to be written on top of existing Cytoscape infrastructure, for example new group views to support complexes.

One general comment is that, for performance reasons, we may want to consider whether changes to rendering should only be implemented for high level of detail zoom factors.

The major requirements are:

  1. Snap-to-grid functionality. This is required for supporting right angle geometry in the layout rules. Having nodes positioned on grid points will make it feasible to connect nodes with lines that are strictly vertical or horizontal. This also allows drawing lines at other angles, e.g. diagonally across two grid points to get a 45-degree angle. Infrastructure changes would be required in the following Cytoscape components:

    • renderer: nodes should snap to grid when being moved. InnerCanvas should display grid points, upon request from the user. Granularity of the grid and granularity of displayed grid points should be configurable by the user. When moving a Node that is attached to a segmented edge, the anchor points of the edge should remain fixed in position and the connecting sub-edge should be stretched or compressed, depending upon the direction of the movement.

    • editor: nodes should be positioned on nearest grid point when dragged/dropped from the editor's palette. User should be able to draw multi-segment lines. That is, draw an edge to a particular grid point and the editor inserts a handle into the edge, then the user takes a 90-degree turn a continues to next chosen grid point.
    • graphical annotations: same implications as for renderer, with the additional requirement that a node should snap to grid when being stretched.

    • graph layout: we should have a specialized graph layout algorithm for MiMs. The existing orthogonal layout algorithm should be a good starting point.

    • Cytoscape desktop: the various Cytoscape modules need to know when they are in 'MiM' mode, i.e. when they need to enforce layout rules. This could be configurable by the user via an item on the Edit menu. Or it could be driven by a specialized 'MiMs' visual style. Is there a way to do this without having to add too much extra code in the editor and renderer for handling special cases.

    • readers and writers: when BioPAX is read in (and if we are in 'MIM' mode), then the specialized graph layout algorithm should be run and then the nodes should be offset to snap to the nearest grid point. When exporting a network to BioPAX, we need a way to save coordinate information. Does BioPAX support this or do we require a format such as XGMML for doing this?
  2. Grouping. This is required for supporting both composite objects, such as complexes, and abstractions, such as in the use of dot notation to represent the state of an object. Customizations need to be built on top of the following Cytoscape components.

    • editor. It would be useful to have a library of predefined 'templates' which would handle composites such as state combination. This functionality is currently being provided in the HyperEdge editor for the use case of biochemical reactions. We should be able to build on top of that infrastructure. This does not mean that we necessarily provide functionality for the user to define their own templates.

    • CyGroup: a number of abstractions should be represented as CyGroups. This includes dot in assymetric binding, cellular compartments, XXXX. In many situations, the GroupNode should be used to represent a MiMs grouping entity, e.g. a cellular compartment and its view. Many of these will require specialized CyGroupViewer implementations.

  3. 'Coordinate System'. This is kind of like a Legend in Cytoscape, except that it may need to update itself upon panning or zooming. Perhaps this could be implemented as a graphical annotation whose Component listens for ViewportChange events and repaints itself with the appropriate labels.

  4. Links on nodes. This is necessary to support Processes, wherein the user could jump to another map if the user performed a gesture, such as a doubleclick on a node that represents a process. This could be generalized to support the execution of an arbitrary function upon user gesture such as doubleclick.

Deferred Items

Open Issues

  1. Do they need site-specific connection of edges, e.g. as in proteolytic cleavage? From Mirit's presentation, it appears that metanodes would work just fine. ( see /ProteinBindingSites

and /ProteinDomains)

  1. How do we represent the "null" node, as in degradation product? (see /SpeciesDegradation)

  2. How do we represent "ditto" nodes, e.g. as in translocation? (see /ShowTransport)

  3. Would they need editor support for Manhattan topology, e.g. constraints on edge angles?

Backward Compatibility

Expected growth and plan for growth

References

Implementation Plan

  • [:Molecular Interaction Maps/Implementation Plan:/Implementation Plan]

Comments

Molecular_Interaction_Maps (last edited 2009-02-12 01:03:29 by localhost)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux