Hackathon discussion issues

Notes from the hackathon

Cytoscape hackathon chat room

1 - Lessons learned in Cytoscape usability analysis - Melissa

• This is a summary of some lessons learned in studying biologists of varying levels of Cytoscape expertise, and analyzing their use of Cytoscape. See the summary document attached to this page.
• Suggestion: make this the first topic of the hackathon, as some of the points may be useful in the subsequent discussions.

2 - Foundation Architecture (GINY Refactoring) - Mike Smoot

• Edge IDs should be addressable, just like node IDs
• We should ensure that all of Cytoscape currently assumes directed edges - how/when do we deal with undirected edges?

• GINY metanode refactoring: remove meta methods - all functionality will be present in the metanode/group API. This will significantly simplify the GINY API and data structure allowing developers to be more confident that their algorithms will work on CyNetwork in general.

• Refactor the GINY interface/inheritance architecture: e.g. should we encapsulate GINY in CyNetwork? See CyNode_Identification

• Clean up depracated methods
• More Unit tests for giny to help us make these changes

• Clean up Cytoscape class – duplicated methods in CyNetwork vs. Cytoscape class and the general bloat of the Cytoscape class.

2a - Network specific (local) node and edge attributes - Mike Smoot

• Use case from GenMAPP group

• Use case from Agilent LiteratureSearch

2b - Memory management- Mike Smoot

• When networks are destroyed, nodes, egdes and their attributes are not actually deleted, but maybe there should be some garbage collection if users want. Also, this allows attributes to pop back up for new nodes that are identically named to previously deleted nodes

2c - Plugin Architecture- Mike Smoot

• How can plugins know which attributes are relevant to which network? ( who??)

3 - BioDataServer - Kei

• Kei will present the latest BioDataServer

• Discussion of Bookmarks

4 - Event handling - Mike Creech (Tues pm)

• right now components that do mouse event and mouse motion event handling can clobber each other. Do we need an overall event architecture that components can plug into?
• right now event declaration and listener store implementation is still spread out over a wide swath of the Cytoscape code. Should we consolidate into one event package?

• Check out the Cytoscape Event Handling Request For Discussion for more information.

5 - Integration of Hyperedges and Group APIs into the core (Tues pm)

• Hyperedges
• Group API

6 - Uncategorized (Tues pm, if time)

• What features should be in 3.0? There has been some brief discussion that the addition of metanode (group) and hyperedge concepts to the core (including some support for these in the UI) would qualify for 3.0 status.
• How should we deal with name clashes for cyattributes? Can we somehow detect name clashes and automate fixing these? Is this mainly a plugin issue?
• Plan for reducing the number of libraries Cytoscape depends on e.g. refactoring to remove dependence on Piccolo

7 - Cytoscape configuration (preferences, etc.) (Tues, if time)

• Currently we use the properties mechanism, but there might be some value in moving to an XML-based configuration file. We need to come to a consensus on how we're going to do this and make sure we have the appropriate mechanism for plugin developers to get configuration information and end-users to set configuration information.

8 - Molecular Interaction Maps

• see Molecular_Interaction_Maps

Extension - WED night

• Ben and Ethan topics (accumulated from Mon and Tue)
  • Ethan: Are there aspects of data-aux that we no longer need to slim it up? (e.g., XML readers; type information; regex handling; ant; jax utils; tar; zip; group; caster)
    • Response from Ethan: yes, yes, and yes. data-aux.jar is way too big, and we can get rid of most of the third-party libs.
  • Ben: Destroying nodes; removal from root graph. Do you know how this might break in Nerius' code? (i.e., buffered indexes?) He's given warning in the past that we should "go there." AllanK: but code to do this may already be implemented, see FRootGraph() class as public methods. Should we assume it's been thoroughly tested?

1 - Graphical Annotations

• how to accommodate arbitrary graphical annotations, such as text, legends, simple sketches, etc.
• how to distinguish between annotations that are attached to and move with nodes and edges, which can be handled by labels and custom graphics, from graphical annotations that are free standing

• how to incorporate graphical annotations into CyNetworks. What are the underlying data structures?

• Ben's work on enhancing the InnerCanvas class to handle multiple layers, i.e. a NetworkCanvas, ForegroundCanvas, and BackgroundCanvas.

• how to save and load graphical annotations.
• NOTE: the use of the term 'annotation' here is completely unrelated to the use of the the term 'annotation' to describe gene/protein annotations such as GO categories. Do we need a different term? "Decorations"? "Markup"?

2 - Graph Layout Architecture and Features

• breaking out common controls from algorithms
• can all algorithms be made to operate on a subset of network?
• controlling bounds of layout

Move to plugin expo:

1 - Technology sharing with InfoVis Toolkit (during plugin expo)

• see InfoVis_Toolkit

Friday morning

VizMapper/Filtering redesign

• see VizMapUI