Diff for "Hackathon2005"

This is just a brainstorming session right now. We can prioritize discussion and ideas for projects later.

• Discuss the difference between node hide and delete concepts -> Goal: get conceptual clarity and a plan to document/implement any necessary changes based on this. Also select/deselect vs. flag/unflag

HACKATHON NOTES: Delete

Concepts

• GINY is the API for all graph-related stuff (view and model). It is independent of Cytoscape. It contains:

  • RootGraph: contains nodes/edges

  • GraphPerspective: contains nodes/edges

  • GraphView

• FING implements GINY. PHOEBE implements the view part of GINY. But, this is hidden from users and Cytoscape.
• Cytoscape builds on GINY by extending or implementing.
• Cytoscape components:

  • CyNetwork extends GraphPerspective

  • CyNetworkView extends GraphView

  • CyNode implements cytoscape.giny.Node extends giny.model.node

  • CyEdge same as CyNode

  • CyAttributes - we are happy with this

  • cytoscape.visual: Mapping, Visual Style, Calculators, Manager, etc.
  • Filters API

How things are right now with delete stuff

• Cytoscape API: removeNode/removeEdge with a "permanent" argument
• Cytoscape API: addNode/addEdge with with a "create" argument

• Cytoscape API: createNode, but not add it to any CyNetwork. We like this.

• GINY API: hide, not in GP(GraphPerspective) but still in RG (RootGraph)

• GINY API: restore, add it back to the GP

Meeting proposals about delete

• Proposal, Global remove: Cytoscape.remove()

• Proposal, Local remove: CyNetwork.remove()

• Encourage coders to use Cytoscape methods, not GINY methods? CONTROVERSIAL...
• Do we hide GINY from coders?

• (not related to delete) Proposal for a GraphObject class that Edge and Node extend. This would simplify the API by not having methods like this: removeNode, removeEdge, addNode, addEdge, etc. High priority for 2.3!

• Final conclusion: OK, yes the OO design of CyNetwork is ugly, but, we are not going to fix it now. We are going to document.

• Delete and attributes. Local and global attributes? Tag attributes into types (user loaded or computed)? It is clear that we want local network attributes. If a network is destroyed, then its local attributes would also be deleted. We could have a UI to separate attributes that users want to keep, and attributes that users do not want to keep (when nodes/edges/nets are deleted).

• Conclusion on delete and attributes: Local (CyNetwork), global (Cytoscape). Seems to solve most of the problems in that you can choose whether attributes are local or global.

• Separate hairy issue: deleting and plugins. A plugin could delete attributes or graph-objects that other plugins need. Plugins should never try to talk to each other, if they did, there is lots of potential for bugs. Need Plugin "Good Citizen" guidelines. If plugins do not follow these rules, they risk not being used. This is a documentation issue.

• Improve conceptual clarity and better document the core and graph model - Is the root graph a multigraph or a graph? Is the root graph directed, undirected or mixed? How about graph perspective? Can nodes or edges be duplicated? etc.
• Discuss switching to a numbered node system instead of the current node ID as a string system
  • This may be required for some graph editing use cases (having nodes with no name yet) and two nodes with the same name.
• Discussion of undo manager
• Prioritize subsystems for refactoring
• Discuss new documentation options e.g. wiki based, which can be translated to PDF and Java help.
• Plan core code cleanup - removing old libraries, old classes, clean up of package structure
• How can we package code so it is easier for developers to load - we have a problem with core plugin and library code being in too many places.
• Clarify and document the difference between core and non-core and decide on policies for making future decisions on this.

• Review community development process and core coding conventions, etc -> goal is to increase quality of our codebase and application

• Discuss user interface standardization issues (Benno brought this up 2 years ago)

• MetaNodes

• Discussion of how to handle "compound" node types -- e.g. complexes, families (sets) (related to MetaNodes above...) (Note: I'd like to make this a high priority for discussion. Alex Pico of the GenMAPP project will be participating in the Hackathon and can go into considerable depth on the requirements for these constructs. It would be very useful to have this discussion while we have the opportunity to pick Alex's brain).

• Discuss new rendering engine that Nerius is building

• Simplifying file formats and implementing the save session feature. Does .sif need to have two ways to specify interactions? Do we need GML if we have a save session file?

HACKATHON NOTES: File formats

Current types of file formats in Cytoscape:

• sif, network, i/o
• gml, network, i/o
• noa, attr, i/o
• eda, attr, i/o
• expression, TP, i/o

• .onto, .anno, .syno, .obo (BioDataServer)

• GO .onto, .anno, .syno, (Kei)

Issues on each file format:

• expression file: should be a noa file
• GO: information gets loaded onto runtime memory, not reasonable for big species,(different topic: databases)
• GML: We are not respecting the format. Node integer IDs are ignored.

Action items:

• Test Rowan's file format for attributes

• Other items under general heading: Questions/Issues/TODO on saving state below

Related topic:

• State saving
  • Kei is working on this for 2.3. Summary of his strategy:
  • zip contains all needed files
  • network files: XGMML
  • cysession.xml: tree strcture of loaded nets, cyto-panels state
  • vizmap.props
  • cytoscape.props
  • Uses JAXB (Sun library for serializing)
  • schema files are used to define contents of XGMML and XML files: XGMML.xsd, cysession.xsd

    Questions/Issues/TODO on saving state

  • how do we package? zip? Group agreed to use zip.
  • save sif files or XML files? Maybe an exporter between the two formats would be a good solution.
  • Package all files inside a directory that then gets zipped (so that when it gets unzipped, all files are within a single directory)
  • Time-stamp the zip
  • Naming issues: .cys or .cyto file extension

  • Plugins should be able to save their state. A listener for "state saving" would be a good strategy. Plugin coders would be responsible for saving their own state (writing and reading). Plugin API could have two methods to write and read. Details are somewhat complicated, but we all agree that it is doable and needed. This is not planned for 2.3, but we can discuss it.

  • Optional interface to select files that should be included in the zip? Maybe just add option to delete attributes or other types of data that user does not want in the state. This probably belongs to the deletion item in this list.
  • Other ideas thrown during the meeting: filter used to specify what data to save. Default filter saves everything.

  • Avoid duplication: only save the RootGraph, and a separate file would list for each GraphPerspective what nodes and edges it contains?

  • Big question: Should RootGraph be saved?, and a separate file contain what nodes/edges are in GraphPerspectives? or, do we only save GraphPerspectives? This is related to WHAT DELETE MEANS!!! So maybe, we leave this point to later. Use cases that need the RootGraph saved: Hyperedges (or meta-nodes), and undo.

  • Other big questions: Should the RootGraph be visible to users?

• Do we need to standardize context menus for nodes and edges or is the current model fine? It seems to be working fine, but will it scale? One reason for standardizing in the core is that the current model uses Piccolo and that may be replaced.
• Cytoscape and databases. For example, GO structure is too big, and should not be loaded into runtime memory. Would be nice to have a database API.
• ID mapper services. Hard bioinformatics problem. Very much needed.
• Event model.
• Please add your discussion points here.