RFC Name : Cytoscape Themes |
Editor(s): Alex Pico| Date: October 24 2007 |
Status: Open for comment |
<<TableOfContents: execution failed [Argument "maxdepth" must be an integer value, not "[2]"] (see also the log)>>
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 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 RFC 46 and 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.
- 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 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:
- Define annotation standards. For example, ID mapping from various data sources:
database name (standardized like http://www.geneontology.org/cgi-bin/xrefs.cgi)
- identifier
- symbol
- full name
- aliases
- genomic location
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 -> 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
This project will depend on Cytoscape re-layering and API refactoring. It can serve as a requirement for the refactoring.
Related RFCs
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.