This page describes the Cytoscape architecture and a vision for where we want the architecture to be in the long-term.

Note: While it we need to clearly decribe Cytoscape subsystems, it is important that most sections of this page not go into too much detail so that the overall architecture is apparent.

TableOfContents

Core data structures

This section provides a very brief summary of core data structures meant as an executive summary, not exhaustive documentation.

• Application level

  • CyNetwork - The network model which stores CyNode and CyEdge objects. The data structure is a "mixed directed/undirected compound multigraph". This data structure has the following properties:

    • Is a set of nodes (CyNode)

    • Nodes are currently identified by a unique string

    • Is a set of edges (CyEdge)

    • Edges connect 2 nodes (source and target)
    • Edges can be directed or not (boolean flag)
    • Edges are currently identified by a unique string
      • Cytoscape (in the Cytoscape class) imposes an additional constraint that the identifier must be named "node1 (edgeType) node2".
    • Multiple edges between nodes are allowed, though they must have different identifiers (this is a multigraph)
    • Nodes can contain other nodes and optionally edges. If a node contains other nodes and edges, it is called a metanode. The metanode concept is not actually modeled, rather a node may have children nodes/edges or parent nodes and an edge may have parent nodes. These concepts are called metachildren or metaparents, but are generally not referred to.

    • Many CyNetwork instances can exist in Cytoscape

  • CyNetworkView - The view which is responsible for drawing a CyNetwork to e.g. the screen, an image file. There is currently one view per CyNetwork and this view mirrors the CyNetwork perfectly, so if a CyNode exists in a CyNetwork, it will be drawn in the CyNetworkView.

    • Each view contains a CyNodeView and a CyEdgeView for each node/edge in the CyNetwork model.

  • CyAttributes contains a multi hash map, which stores node and edge attributes. This acts like an in memory database keyed by a unique string (e.g. the CyNode or CyEdge string identifier) and can store the following types as values:

    • Simple mode: Boolean, Integer, Double, String
    • Advanced mode: List, Map

  • Visual mapper - a map from data (node/edge) attributes to visual attributes

    • VisualStyle - encapsulates all calculators in a visual style

    • NodeAppearanceCalculator - calculates the appearance of a Node

    • EdgeAppearanceCalculator - calculates the appearance of an Edge

    • TODO: There are other data structures here
• Libary level (should be hidden from application level)

  • GINY - http://csbi.sourceforge.net/ (implemented as FING)

  • Piccolo - http://www.cs.umd.edu/hcil/jazz/

Refactoring status

• Needs refactoring, community review process (as of Feb.2006):

  • CyNetwork is still at version 1

  • Library level needs to be hidden from application level. Currently, e.g. GINY is available for use in Cytoscape, but this confuses the use of CyNetwork. We need to encapsulate all libary objects within Cytoscape application layer objects.

  • Visual mapper is at version 3 (version 1 in Cytoscape 1.0, rewritten by Trey's group to current GUI, refactored by Ethan to current state), but has not been community reviewed.

• Has been refactored, passed community review process (as of Feb.2006)

  • CyAttributes is at version 2 (previously called GraphObjAttributes). Reviewed in ["RFC 1"].

Miscellaneous data structures

This section briefly describes data structures that are part of the Cytoscape application, but are not considered core concepts. This generally means that the typical developer does not need to know about them because they are useful mainly for internal Cytoscape use or are planned to be removed.

• ExpressionData - stores data read by from an expression data file. Can also be used to access this data, but the data is also copied to CyAttributes. It would be best if this data is only stored in CyAttributes and a utility class was available for dealing with expression type data in a general way.

• BioDataServer - stores gene annotation and synonym data

  • Thesaurus - a hashmap of synonyms, used for node unique identifier equivalence mapping
  • Ontology - a directed acyclic graph used to store ontologies like the Gene Ontology (GO)
  • Annotation - a mapping from a string identifier to an ontology term in the Ontology object

• Filters - TODO: describe

Refactoring status

• Needs refactoring, community review process (as of Feb.2006):

  • ExpressionData - Needs to be eventually replaced by CyAttributes (though some utility methods for expression data, or more generally any type of data like expression data, would be useful, this should not be a core class). E.g. the expression data file import/export features may need to use some features from this class.

  • BioDataServer - Needs to be refactored or rewritten

• Has been refactored, passed community review process (as of Feb.2006)

Cytoscape Core Subsystems

• Startup
  • Initialization
  • Plugin loading
• GUI
  • Menu set up

  • CytoPanels

  • Node/edge selection
  • Layout
  • Undo/redo
  • Visual mapper
  • Help
  • Annotation/ontology viewer
• Load/Save (to new .cys format)
• Import/Export
  • SIF import/export
  • GML import/export

  • Expression data import (currently in the ExpressionData class, but should be a reader). This also may need a writer?

  • Node attributes import/export
  • Edge attributes import/export

• BioDataServer (needs a rewrite)

  • Ontology reading
    • Old manifest file format reader
    • New OBO format reader
  • Synonym reading

Refactoring Status

• It would be nice to provide an API for registering import/export plugins and migrate all core import/export code to core plugins using this API. This would help keep the core of Cytoscape small, thus reducing complexity.

Cytoscape Core Plugin Systems

• GUI
  • Cytoscape node/edge attributes graphical browser (browser.jar)
  • Filters (filter.jar)

  • Network editor (CytoscapeEditor.jar

  • Align/distribute nodes (control.jar)
  • Right-click menu on view (yeast-context.jar)
  • Layout

    • Hierarhical layout (HierarchicalLayout.jar)

    • yFiles layout (yLayouts.jar)

Many new systems are needed, as described in ["Future Cytoscape Features"]

Wiki page TODO

*General notes about design philosophy - when in doubt, keep it simple *Add note about model vs. view *Define Core as per recent discussion with Trey *Add note about ideal package structure (more modular, logical groupings) *Add note about ideal file structure (recent proposal by Mike Smoot about plugin reorganization) *Where should optional libraries go? *Encapsulate application-external data structures rather than extend *No bio semantics in core