Differences between revisions 1 and 4 (spanning 3 versions)
Revision 1 as of 2007-10-24 19:29:42
Size: 4725
Editor: AlexPico
Comment:
Revision 4 as of 2007-10-25 00:58:19
Size: 5324
Editor: AlexPico
Comment:
Deletions are marked like this. Additions are marked like this.
Line 9: Line 9:
While it is important that the semantics in the core of Cytoscape remain domain-agnostic, we also recognize the need to support use cases and plugins that are very domain-specific. We propose the concept of Cytoscape Themes to provide plugin developers and users with flavors of Cytoscape designed with specific research domains in mind. By providing a few basic overlays and defined standards we can greatly facilitate plugin development and improve user experience. While it is important that the semantics in the core of Cytoscape remain domain-agnostic, we also recognize the need to support use cases and plugins that are very domain-specific. We propose the concept of Cytoscape Themes to provide plugin developers and users with flavors of the Cytoscape model designed with specific research domains in mind. By providing a few basic overlays and defined standards we can greatly facilitate plugin development and improve user experience.
Line 12: Line 12:
 * Overlay domain-specific syntax onto the data model (a.k.a [http://en.wikipedia.org/wiki/Syntactic_sugar syntactic sugar]), while maintaining the agnostic core model.
 * Define annotation standards per domain to facilitate the mapping of external data sources to a standard set of attributes
 * Make changes to the view to reveal the appropriate semantics to the user in the form of menus, panels, labels, etc.

Overlaying domain-specific syntax onto the data model will clarify the model and help direct plugin developers who are implementing domain-specific functionality (e.g., microarray analysis). The effect of the “sweetened” syntax should trickle down to the end user by making it easier to load and map datasets and interpret domain-specific visualizations.
 * Overlay domain-specific syntax onto the data model (a.k.a [http://en.wikipedia.org/wiki/Syntactic_sugar syntactic sugar]), while maintaining the agnostic core model. Overlaying domain-specific syntax onto the data model will clarify the model and help direct plugin developers who are implementing domain-specific functionality (e.g., microarray analysis).
 * Define annotation standards per domain to facilitate the mapping of external data sources to a standard set of attributes.
This will allow all plugin developers within a particular domain to take advantage of commonly shared attributes, knowing where to map data to and where to find data.
 * Make changes to the view to reveal the appropriate semantics to the user in the form of interfaces, menus, panels, labels, etc. Thus, the benefits
of the “sweetened” syntax should trickle down to the end user by making it easier to load and map datasets and interpret domain-specific visualizations.
Line 23: Line 21:
 1. Biological Pathways: semantics could be extracted directly from BioPAX. This would support pathway analysis of microarray or proteomics data for example.
 
Line 25: Line 25:
Once the core Cytoscape code has been re-layered and and API is settled, we can develop a set of modular plugins to define a given theme (see genomics example below). These plugins, and their respective APIs, can be used by developers and, in turn, be bundled with their plugins to facilitate installation and use by the end-user (see [:CytoscapePluginBundles: CytoscapePluginBundles RFC]). Once the core Cytoscape code has been re-layered and the API is settled, we can develop a set of modular plugins to define a given theme (see basic biological example below). These plugins, and their respective APIs, can be used by developers and, in turn, be bundled with analysis plugins to facilitate installation and use by the end-user (see [:CytoscapePluginBundles: CytoscapePluginBundles RFC]).
Line 43: Line 43:
Variations on the these functions could be mixed, matched and bundled to support various domain-specific tasks. http://www.best4c.cn/Best4cUserFiles/20071025/16345_1193273416802.jpg

Variations on the these plugins could be mixed, matched and bundled to support various domain-specific tasks.
Line 54: Line 56:
 1. '''Milestone 1: …'''
  1. Task 1: ...
  1. Task 2: ...
 1. '''Milestone 2: …'''
Line 61: Line 58:
This project will depend on Cytoscape re-layering and API refactoring. It can serve as a requirement for the refactoring.
Line 63: Line 61:
~-''Link to other related RFCs''-~  * [:CytoscapeLayerRefactor:CytoscapeLayerRefactor RFC 46]
 * [:PluginRefactor:PluginRefactoring RFC 47]
 * [:CytoscapePluginBundles: CytoscapePluginBundles RFC 48]

RFC Name : Cytoscape Themes

Editor(s): Alex Pico| Date: October 24 2007

Status: Under Construction

TableOfContents([2])

Proposal

While it is important that the semantics in the core of Cytoscape remain domain-agnostic, we also recognize the need to support use cases and plugins that are very domain-specific. We propose the concept of Cytoscape Themes to provide plugin developers and users with flavors of the Cytoscape model designed with specific research domains in mind. By providing a few basic overlays and defined standards we can greatly facilitate plugin development and improve user experience.

This proposal touches on a number of areas including domain-specific semantics, data integration and user interfaces. We propose to do the following:

  • Overlay domain-specific syntax onto the data model (a.k.a [http://en.wikipedia.org/wiki/Syntactic_sugar syntactic sugar]), while maintaining the agnostic core model. Overlaying domain-specific syntax onto the data model will clarify the model and help direct plugin developers who are implementing domain-specific functionality (e.g., microarray analysis).

  • Define annotation standards per domain to facilitate the mapping of external data sources to a standard set of attributes. This will allow all plugin developers within a particular domain to take advantage of commonly shared attributes, knowing where to map data to and where to find data.
  • Make changes to the view to reveal the appropriate semantics to the user in the form of interfaces, menus, panels, labels, etc. Thus, the benefits of the “sweetened” syntax should trickle down to the end user by making it easier to load and map datasets and interpret domain-specific visualizations.

The first step, however, is to re-layer the core Cytoscape code and settle the API (see [:CytoscapeLayerRefactor:RFC 46] and [:PluginRefactor:RFC 47]). We should keep Cytoscape Themes in mind as one of many motivations for performing these crucial tasks.

Use Cases

Provide examples of how the products of this project will be used.

  1. Biological Pathways: semantics could be extracted directly from BioPAX. This would support pathway analysis of microarray or proteomics data for example.

Implementation Plan

Once the core Cytoscape code has been re-layered and the API is settled, we can develop a set of modular plugins to define a given theme (see basic biological example below). These plugins, and their respective APIs, can be used by developers and, in turn, be bundled with analysis plugins to facilitate installation and use by the end-user (see [:CytoscapePluginBundles: CytoscapePluginBundles RFC]).

The following plugins would, together, support the basic biological semantics for pathway analysis of microarray data, for example.

  • 1.Overlay basic biological syntax onto the core data model. Here are a few examples:
    • ‘Gene’ extends ‘CyNode

    • ‘Protein’ extends ‘CyNode

    • ‘Paralogs’ extends ‘CyGroup

    • ‘Complex’ extends ‘CyGroup

  • Define annotation standards. For example, ID mapping from various data sources:

http://www.best4c.cn/Best4cUserFiles/20071025/16345_1193273416802.jpg

Variations on the these plugins could be mixed, matched and bundled to support various domain-specific tasks.

Project Management

Project Timeline

Provide a timeline for implementation. Insert a graphic if you can. Try this free online tool for making project timelines -> [http://www.helpuplan.com/index.asp Help-u-Plan] (create a new chart; modify; right-click to save gif; then attach to this page)

Tasks and Milestones

Outline the major milestones and tasks involved in implementation.

Project Dependencies

Outline and projects that depend on this project, link to relevant RFC's and note at what point dependent projects could be started. This project will depend on Cytoscape re-layering and API refactoring. It can serve as a requirement for the refactoring.

Issues

List any issues, conflict, or dependencies raised by this proposal

Comments

  • Add comment here…

How to Comment

Edit the page and add your comments under the provided header. By adding your ideas to the Wiki directly, we can more easily organize everyone's ideas, and keep clear records. Be sure to include today's date and your name for each comment. Try to keep your comments as concrete and constructive as possible. For example, if you find a part of the RFC makes no sense, please say so, but don't stop there. Take the extra step and propose alternatives.

CytoscapeThemes (last edited 2009-02-12 01:04:01 by localhost)

Funding for Cytoscape is provided by a federal grant from the U.S. National Institute of General Medical Sciences (NIGMS) of the Na tional Institutes of Health (NIH) under award number GM070743-01. Corporate funding is provided through a contract from Unilever PLC.

MoinMoin Appliance - Powered by TurnKey Linux