Notes from a meeting about visual representation in Cytoscape held at the Computational Biology Center at Memorial Sloan-Kettering Cancer Center in New York City, July 5-8,2006

Participants: Allan Kuchinsky, Alex Pico, Ethan Cerami, Ben Gross, Gary Bader, Doron Betel, Emek Demir, Rich Bonneau, Chris Sander

== Topics Discussed ==

 1. Graph layout 
    a. Cellular localization 
 1. Visual representation/annotation 
    a. BioPAX visual lanuage 
    a. GenMAPP annotation 
    a. Metanodes 
 1. BioPAX editor 
    a. Hyperedge API 
    a. Validator 
    a. PAXServ 
       i. API for BioPAX networks, analogous to DOM
 1. Cytoscape Editor code walkthrough 
 1. Filtering/Searching 
    a. Ethan’s !QuickFind prototype 
    a. Changes to vizmapper 
 1. Roadmaps (who is doing what and when)

== Decisions ==

=== Experiments ===
 1. Custom node rendering, e.g. include small circles for PTMs (Ben) 
 1. Layered panes (Allan) 
    a. Background pane
    a. Legend and notes pane
    a. “Bubble” subgraph placement/routing  (including linkage between layers)
        i. dependency: ethan’s code for attribute assignment
        i. “Brick” subgraph placement/routing (Ethan)
 1. Text Paint images (Ben) 
 1. Look at decorator pattern (Ben) 
 1. Gene -> cell compartment map (Alex) 
 1. Cytoscape editor interface to PAXServ (Ben) 
 1. Complexes as metanodes (Ethan) 

=== Additional requirements ===


Issues for visual representation of pathways:
 1. Hyperedge would be most useful for BioPAX interactions, but would require edges connected to other hyperedges (metanodes is not as useful, since hyperedges have attributes that could be used to represent the types of nodes involved e.g. substrate, product). Current hyperedge API does not support edges connected to other edges.
 1. Metanodes would be most useful for BioPAX part-whole relationships, like complexes and sub-pathways.
 1. Hyperedge and metanode viewing would require Cytoscape to be aware of different types of nodes and edges, since hyperedge and metanodes need to be treated specially by normal graph algorithms, like shortest path and layout.  How can this be implemented to not interfere with existing algorithms?
  a. One very modular way is to implement viewing the metanode and hyperedge information only with the view. This keeps the Cy''''''Network model for normal binary graphs, the hyperedge API model for hyperedge information and the metanode API model for metanode information (with no duplication of information between these). Only code that needs to know about hyperedges or metanodes would access the respective APIs to get information – they would not get information about metanodes/hyperedges from Cy''''''Network. (refactoring GINY to not include metanode methods would be useful)
  a. This requires Cy''''''Network''''''View to be desynchronized from the Cy''''''Network.  Need to think about what would break if we did this.
  a. Also, would require metanode and hyperedge aware network and attribute browser e.g. to display correct number of edges in the network viewer – and likely other parts of Cytoscape if we want to create complete integration (this is likely a lot of work).
  a. May require custom edge rendering to implement various metanode and hyperedge views
 1. Metanode viewing optimization – how does child view x,y coordinate system relate to global network coordinate system? Use case: view metanode that is represented by a translucent box and allow user to interact with the child nodes while in the box (PATIKA and INOH pathway editors implement this). PATIKA group found important optimizations here, like not updating the x,y coordinates of the metanode children when the metanode was being moved by the user on the screen.
 1. GenMAPP requirement: annotation labels (as a new type of node) – anchor point on edges, text, brackets (easily implemented by metanodes – bracket is a visual style), objects.
  * The major design issue that was agreed upon was to keep annotations separate from the current "node&edge" network model
  * ''Annotations'' being free-floating text or graphical objects that are not directly associated with a biological entity, process, etc. 
  * ''Nodes'' could include biologically meaningful text ("Apoptosis"), graphics representing a protein, or cellular compartments that would exist as, or be labels of, nodes to which edges/arrows could be connected.
  * The separation could be accomplished in three ways:
   a. Use JLayeredPanes to separate the object types and create layers with particular properties/purposes and associated with different models (see next point below)
   a. Add another network layer in the data model "under" Cy''''''Network to distinguish non-node objects
   a. Add a new attribute for node type:
    i. Alter Cy''''''Network to ignore "annotation" node type
    i. Alter every plugin/algorithm to ignore "annotation" node type
  * Options b. and c. seem like a potential cans of worms (wrt the Editor, selection and layout algorithms), while option a. opens up a whole host of potential functionality (see next point below). So, we have formulated experiments with JLayeredPanes and GlassPanes to test feasibility.
 1. JLayeredPane on top of and below a network is useful for:
  a. Legend (requires pane above)
  a. Annotation objects e.g. notes pointing to a region of the network (pane above)
  a. Background images (requires pane below)
  a. May want to synchronize any objects (e.g. annotation notes) on the layered pane with the Cy''''''Network''''''View e.g. to keep notes close to the nodes they point to. Probably not useful when there are lots of shapes on the pane because of issues with speed and overload of objects making the notes hard to read.
  a. This may require changing the implementation of the background in cytoscape to be the lowest background pane instead of in the network pane.

Issues for Graph layout:
 * Decision: We can’t solve the layout problem 100% (it's too difficult), so we should work towards semi-automated layout, where manual layout is aided by various layout tools. For example:
  * Allowing selected regions of the graph to be laid out by all layout algorithms
  * Providing a layout toolbar for common lay out actions
  * Allow locking of nodes into user-defined x,y positions, then laying out the rest of the graph. Locking can be 'weighted' as well, where the amount of times a user clicks on a node, the slower it moves in the layout.
  * Providing a dynamic layout where the user can easily interact with the graph as it is being laid out e.g. locking nodes and having the rest of the graph laid out automatically around the locked nodes.
  * Providing layout patterns for specific types of nodes/edges - like a BioPAX style biochemical reaction
  * Providing tools that lay out specific regions e.g. an alignment sweep tool (like the eclipse graph editor framework has) or selective layout, where the user moves a mouse over regions of the graph to lay it out, without having to first select the nodes and lay them out.