Mini-Retreat One

• September 12-13, 2008

• [http://www.ucsd.edu/maps/index.jsp?mapid=601&wid=601&iws=false&cat=&t=m&z=15&opacity=50&ll=32.88178563936398,-117.23437786102295 "Department of Bioengineering"] (Powell-Focht Bioengineering Hall), UC San Diego, Room 291

• Mike's cell: 858-228-7242
• Mike's office: 858-822-4756

Topics for Discussion

• Progress on merging the new CyNetwork and CyAttributes model with the 3.0 branch.

  • CyAttributes API changes based on retreat discussions (Trey's references [:CytoscapeRetreat2008/Design:notes]), CyDataTable

• Discussion of how Groups will fit in to the model package.

• Discussion of how HyperEdges will be handled.

• Progress on ViewModel API?

• Division of Labor - figure out what tasks can be separated out amongst other groups.

Goal

• Get the application and at least one core plugin working with the new CyNetwork and CyAttribute models.

Meeting Notes

• Gary opinion, Sep8 - Re: groups. Groups definitely belong in the model, but they should be kept separate from the core network model. There should be a CyGroups API similar to the one that exists that keeps track of all group information. Algorithms that work on simple graphs (most of the existing Cytoscape and plugin code) will not need to know about groups and those that need groups will be able to access the information using the CyGroups API. Group views on the other hand will likely need a lot of custom node shape functionality in the view layer. This is how Hyperedges should work as well.

• Piet opinion, Sep9 - Re: goal. Isn't division of coding-labour one of the goals of these mini-retreats also?
• Scooter, Sep 11 - I'm starting to get concerned that people might be spending too much time moving plugins over the Cy3 trunk without knowing how much the API is still in flux. We still haven't even talked about the View API much and a lot of plugins leverage various view features extensively. I think we should talk about exactly how people should be viewing Cy3 at this stage. We're going to have a lot of people really upset with us if they do a lot of work that has to be completely redone. On the other hand, we want people to give us input about what's missing in the tree, so some work is warranted.

• Discussion: When do we extend CyNetwork vs. use well-known attributes? In the case of compound networks (metaNodes) we decided that they required additional semantics, so CyNetwork was extended. In the case of HyperGraphs, we're going to use nodes in any case, so we are not going to change the semantics. Therefore, a connector node will be identified by the NODE_TYPE_ATTR attribute.

ViewModel / Presentation Requirements

• Extensibility is key.

• What is the granularity of extensibility? Should it be Node and Edges (i.e. NodeRenderer, EdgeRender), Network (just one renderer for the whole shebang), or VisualProperty (one renderer per visual property)?

• Where are VisualProperties defined? Are they a function of a renderer or are they intrinsic to the ViewModel. Should there be a third class (e.g. VisualPropertyProvider)?

  • Who handles serialization and de-serialization?

  • Should there be default or "essential" set of VisualProperties?

  • How doe VisualProperties meaningful in one context (e.g. Paint in java) get translated into a different context where the concept isn't meaningful (e.g. there is no Paint in SVG)?

• ViewModel must not depend on the Renderer. Cytoscape's data layers should be usable without a Renderer. Imagine a webservice.

• How to handle multiple layers of a presentation? Background/foreground images?

Plans and Decisions