Pathway_visualization_meeting_NYC_July_2006

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

Schedule

== Topics Discussed ==

1. Graph layout
   1. Cellular localization
2. Visual representation/annotation
   1. BioPAX visual lanuage
   2. GenMAPP annotation
   3. Metanodes
3. BioPAX editor
   1. Hyperedge API b. Validator c. PAXServ
      1. API for BioPAX networks, analogous to DOM
4. Cytoscape Editor code walkthrough
5. Filtering/Searching

   1. Ethan’s QuickFind prototype b. Changes to vizmapper

6. Roadmaps (who is doing what and when)

Decisions

Experiments

TODO: fill in.

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.
2. Metanodes would be most useful for BioPAX part-whole relationships, like complexes and sub-pathways.
3. 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?

   1. One very modular way is to implement viewing the metanode and hyperedge information only with the view. This keeps the CyNetwork 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 CyNetwork. (refactoring GINY to not include metanode methods would be useful)

   2. This requires CyNetworkView to be desynchronized from the CyNetwork. Need to think about what would break if we did this.

   3. 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).
   4. May require custom edge rendering to implement various metanode and hyperedge views
4. 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.
5. 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.
   • TODO: Alex, add your notes here.
6. JLayeredPane on top of and below a network is useful for:
   1. Legend (requires pane above)
   2. Annotation objects e.g. notes pointing to a region of the network (pane above)
   3. Background images (requires pane below)

   4. May want to synchronize any objects (e.g. annotation notes) on the layered pane with the CyNetworkView 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.

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