BioSpice

# Overview

Bio/Spice is a rather ambitious project to produce a *de facto* standard
for modeling biological systems. As such it will integrate databases of
biological information ranging from text to quantitative measurements to
edited pathway content; it will allow extensible modes for analyzing and
displaying this data; it will allow the building of models of cellular
processes at multiple levels of abstraction; it will allow the transport
of these models to various simulation and analysis kernels using a
standard model transport format; store and classify models and
simulation output with comparison to data; and act like a systems
biology laboratory notebook.

Obviously, we can't design all these aspects at once so the architecture
for the tool must be extremely modular, open and extensible. Wouldn't
hurt to be scalable as well though that's largely the job of each module
to maintain.

Philosophically, we are trying to build a tool much like SPICE used in
electrical circuit engineering
([NewburySpice.pdf](../NewburySpice.pdf)). The tool described in the
linked PDF file has close to the type of functionality we wish to
provide the biologist for studying their systems. However, we have the
problem that we do not have the same type of modularity, device physics
and simulation standards that the engineering industry has. We are in
early days so we will have to be flexible in allowing different model
abstractions, different parameterizations, and different ways of
relating our models to data. Thus data analysis is a much larger part of
this project than it is for other SPICE-like tools.

## Scope

Biological modeling occurs at many levels from subcellular, to
intercellular, to tissue to organ, to anatomical structure, to organism,
to populations. Our main focus will be on the subcellular through the
multicell simulation and design. For single-celled organisms this means
we will be going all the way up through population dynamics, but for
mammalian system we will be limited to something around "tissue". Our
initial focus will be on the cellular mechanics, transport, biochemistry
and genetics. We have the advantage here and we should push it. This is
also the time to leverage off genome projects, whole genome molecular
profiling and imaging so providing a central tool for integration of
this data into a model of cellular function is both timely and
necessary.

## Other Efforts and Alliances

There are a number of other efforts at varying levels of completion with
which we are both cooperating and competing. We have certain advantages
surround, I think, our expertise in physical chemistry and gene
expression especially and some good reputation for knowing the biology
pretty well. We also have a good reputation for openness which we should
keep. There is a good deal of communication among the following efforts:

  ---------------- ------------------------------------------------- ------------- ----------- --
  **Product**      Site                                              Short         Criticism   
                                                                     Description               

  **E-Cell**       http://www.ecell.org                                                        

  **Virtual Cell** http://www.nrcam.uchc.edu                                                   

  **Physiolabs**   http://www.entelos.com                                                      

  **Physiome**     http://www.physiome.com                                                     

  **Scamp**        http://members.tripod.co.uk/sauro/biotech.htm                               

  **Gepasi**       http://gepasi.dbs.aber.ac.uk/softw/Gepasi.html                              

  **Ultrasan**     http://www.crhc.uiuc.edu/UltraSAN/UltraSAN.html                             

  **InGenue**      http://www.snarkware.org/ingeneue/                                          

  **M-Cell**       http://www.mcell.cnl.salk.edu/                                              

  **Stella**       http://www.hps-inc.com/edu/stella/stella.htm                                

  **Genesis**      http://www.bbb.caltech.edu/GENESIS/genesis.html                             
  ---------------- ------------------------------------------------- ------------- ----------- --

In fact a more extensive list of tools may be found at
<http://bionome.sdsc.edu/html/signal.html> in the modeling resources
section. It will also be useful to check out the databases and standards
committees they cite.

## General Architecture

In the following sections I outline a basic architecture for biospice.
Roughly, the idea is a the build a highly modular, distributed data
analysis, display and simulation environment for use with biological
systems. A rough idea is given in the figure below:

![](media/image1.png){width="6.0777777777777775in"
height="3.5256944444444445in"}

One of the central goals of Bio/Spice will be an open architecture.
There will be a number of points at which it is open. In the kernel,
different simulation kernels should be easily hooked to the front-end.
Different model and data analysese should also be made available in
plug-in style. The same with different visualizations. We will have to
provide standard hooks to the specialized data, such as pathways, that
Bio/Spice will deal with.

A user script would run (whimsically) as follows. User has just
performed a set of gene chip experiments in which yeast has been drugged
with various hallucinogens. The yeast form shmoos in the form of what
they are dreaming about and change their gene expression to achieve this
change. The user starts a new experimental notebook in Bio/Spice. User
uploads images of different yeast cells under the different conditions
as well as affymetrix gene chips following a time-course of gene
expression for each drug. The data is keyed to drug and to the image.
Each gene on the chip is keyed to annotation in our database. The data,
now in the public data core of the database (but currently tagged as
private to this user and group), is added to his notebook. The user
requests that the gene chip data get normalized and scored based on the
"Churchill/Rosetta" algorithm. He the requests that it gets displayed in
an "Eisenogram". The results of these operations are displayed and
stored in his notebook. The user then requests Bio/Spice to display all
known drug response pathways and shmoo formation pathways with the
"normalized" chip data (and its Eisen cluster tag) displayed next to
each transcript. Bio/Spice displays this and after mucking about with
how the pathway is displayed the user decides that he doesn't want to
see the transcripts explicitly. He tells BioSpice to associate the
transcript data with their proteins instead and stop displaying
transcripts. Happy with the appearance now he saves this display to his
notebook. He is confused by a small subcircuit's expression pattern in
the early response pathway and decides to model it. He loads up his
pathway display. He decides to select only the piece he is confused
about plus so inputs and outputs. He transfers this selection into a new
"display", saves it to his notebook. Internally Bio/Spice keeps track of
where this piece fit in the larger network. He then queries the database
for kinetic, thermodynamics and concentration range information for
every species and reaction on his list. Of the 12 species and 16
reactions he only find a smattering of parameters and mechanisms. He
accepts these and then sets about finding data or making up stuff about
the rest. Data he finds he enters into the database. It is entered with
reference to the literature and the user. He then associates this
information with the proper objects in his model. The parameters and
mechanisms he makes up get stored in his local notebook. When Bio/Spice
tells him he has enough to hit "go" he does (after a bunch of set up and
boundary questions). The results get distributed to appropriate kernels
and the results get sent back to the database. He is automatically
notified that his simulation is done.

# Database

One of the goals of Bio/Spice is to systematize a good body of
biological information into a form appropriate for biological systems
analysis. This, of course, means that we will have to develop ontologies
for such biological information that allows us to cross scales, levels
of description and phenomena. Because we wish to get quantitative
information out of this we will also have to have "mathematical"
ontologies related different types of analyses together.

## Knowledge

The "knowledge-base" aspects of the Bio/Spice core involve storing
derived and edited information about biological systems. This includes
annotated sequences, molecular interactions, lists of organisms, pathway
designations, chemical process identification., mechanisms such as
Michaelis-Menten, reference lists, and comments. Examples of ontologies
for some of these things can be found in the following tables.

  ------------------ -------------------------------------------------------------------- --------- -- --
  **Report**         Site                                                                 Comment      

  **BioOntology      ftp://smi.stanford.edu/pub/bio-ontology/OntologyExchange.doc                      
  Group Report**                                                                                       

  **Otolingua**      http://saussure.irmkant.rm.cnr.it/onto/ON9.2a/molecular-biology/                  

  **Gene Ontology    http://www.geneontology.org/                                                      
  Consortium**                                                                                         

  **Multiple         http://igd.rz-berlin.mpg.de/\~www/oe/mbo.html                                     
  Ontologies**                                                                                         

  **Bioinformatics   http://bagel.cs.man.ac.uk/tambis/browse/tambis-applet.html                        
  Ontology**                                                                                           

  **BIND**           http://bioinformatics.oupjournals.org/cgi/reprint/16/5/465                        

  **ArrayXML**       <http://beamish.lbl.gov/>                                                         

  **MoreArray**      <http://www.cbil.upenn.edu/Ontology/Stoeckert_ontology.html>                      

  **Cabrio**         <http://www.cabri.org/CABRI/home/guidelines/catalogue/CPdata.html>                

  **BioWidgets**     http://bioinformatics.oupjournals.org/cgi/reprint/15/10/837.pdf                   

  **DDBJ DNA         http://bioinformatics.oupjournals.org/cgi/reprint/14/6/472.pdf                    
  Schema**                                                                                             

                                                                                                       
  ------------------ -------------------------------------------------------------------- --------- -- --

Not all these sites are entirely relevant but they will give some idea
about how other people have thought about things. One thing that will be
difficult is integrating the biological ontologies with the mathematical
ontologies we use for data analysis and simulation. The mathematical
ontologies might look a little like MathML but that is probably not the
greatest starting point.

For simulation I have been thinking about what sorts of relations we
would have. This includes: differential term, differential equation,
stochastic differential term, SDE, PDE, PDE term (laplace), algebraic
relation, random number, constant, discrete equation, discrete term,
lattice relation, etc. We should also think about formalizing a few
abstraction hierarchies: ODE's are and abstraction of Langevin Eqs are
an abstraction of master equations. Or Michaelis-Menten is an
abstraction of (three elementary reactions). Other abstractions won't be
so formal: 'binds' is an abstraction of reacts with, 'activates' is
also, but what about "catalyzes"? It would be nice to come up a list of
biological verbs and nouns of sufficient generality that, for example,
English could be parsed with it. With each abstraction is associated
some formal specification of the assumptions behind it.

One of our goals will be to get a bunch of the currently existing
knowledge bases into Bio/Spice format. The following knowledgebases are
a starting point:

  ------------------- -------------------------------------------------------------- -- -- --
  **Database**        Site                                                                 

  **Kegg**            <http://www.genome.ad.jp/kegg/>                                      

  **WIT**             <http://wit.mcs.anl.gov/WIT2/>                                       

  **BioCat/BioDeg**   <http://www.labmed.umn.edu/umbbd/index.html>                         

  **EcoCyc**          <http://ecocyc.pangeasystems.com/ecocyc/ecocyc.html>                 

  **Indigo**          <http://indigo.genetique.uvsq.fr/>                                   

  **BM Charts**       <http://www.expasy.ch/cgi-bin/search-biochem-index>                  

  **Enzyme**          <http://www.expasy.ch/enzyme/>                                       

  **Taxonomy**        <http://www.ncbi.nlm.nih.gov/Taxonomy/taxonomyhome.html>             

  **TRANSFAC**        <http://transfac.gbf.de/TRANSFAC/>                                   

  **Klotho            <http://www.ibc.wustl.edu/klotho/>                                   
  (compounds)**                                                                            

  **Chemical          <http://ntp-db.niehs.nih.gov/Main_Pages/pub-Structures.html>         
  Structures**                                                                             

  **GeneCards**       <http://www.dkfz-heidelberg.de/GeneCards/>                           

                                                                                           
  ------------------- -------------------------------------------------------------- -- -- --

There are many others as well. Tomer has collected a number of them and
we should be working to get these into our own schema. Further, we
should look into becoming mirror sites for tools like SRS
(<http://srs.ebi.ac.uk/srs5bin/cgi-bin/wgetz?-page+databanks>)

The important goal here is to place every reaction into its biological
context, allow the user to drill down from the highest level (a compound
or reaction name) to the lowest level (atomic structure). Each object
(compound and reaction) should be associated to physical properties
(pKa, isoelectric point, structure, chemical potential) or (mechanisms,
kinetics and thermodynamics).

## Data

There are a number of primary datatypes that we will wish to store in
the database. These include mechanisms (submodels), kinetic parameters,
thermodynamic parameters, mechanical parameters, gene expression chips
(affymetrix, microarray, nylon membrane), proteomic data, images, etc.

  ----------------- -------------------------------------------------------- -- -- -- -- -- --
                                                                                            

  **Stanford        http://genome-www4.stanford.edu/MicroArray/SMD/                         
  Microarray Data**                                                                         

  **Mouse           http://www.lecb.ncifcrf.gov/mae/maeIndex.html                           
  Microarrays**                                                                             

  **NCI**           http://nciarray.nci.nih.gov/                                            

  **Standford       http://quantgen.stanford.edu/                                           
  Drosophila**                                                                              

  **Tyrell Conway** http://www.biosci.ohio-state.edu/\~tconway/global.html                  

  **2Dgel           http://www.lecb.ncifcrf.gov/2dwgDB/                                     
  Metabase**                                                                                

  **Swiss-2D**      http://www.expasy.ch/ch2d/2d-index.html                                 

  **RCSB            <http://www.rcsb.org/pdb/>                                              
  (structure)**                                                                             

  **DPInteract**    <http://arep.med.harvard.edu/dpinteract/>                               

  **BIND**          <http://bioinfo.mshri.on.ca/BIND/BIND_prop/index.html>                  

  **DIP**           <http://dip.doe-mbi.ucla.edu/>                                          

  **AAINDEX**       <http://www.genome.ad.jp/dbget/aaindex.html>                            

                                                                                            
  ----------------- -------------------------------------------------------- -- -- -- -- -- --

There are a number of places to check out with all database and genomics
issues: NCBI, NHGRI
(<http://www.nhgri.nih.gov/DIR/LCG/15K/HTML/dbase.html>), Sanger Center,
Jackson Lab, EBI, etc. Schema for protein interactions can be found in
the BIND paper I sent around earlier or, for example, for INTERACT,
<http://bioinf.man.ac.uk/interactpr.htm>. It is important, for example,
that every gene on a gene chip be linked to the sequence in the
knowledgebase and to every transcript in the reaction pathways. I know
that the line between the knowledgebase and the database is
fuzzy---there doesn't need to be a crisp divide.

A number of sketches I did a long time ago about different relations can
be found in the following PowerPoint file. ([Data
Model.ppt](../Data%20Model.ppt))

One last thing about the "bases", every piece of data should be
associated with an accession number, an accession date and time, quality
control number (5 levels I think will suffice: Bot, Admin, User,
Generator, expert), and, if possible, number of times accessed, etc.

## Data Interchange

We need to design a set of XML standards that allow us to send data,
models and visualizations to the other modules of Bio/Spice as well as
third party tools. This will obviously require a number of different
specifications. We will have to think about how to embed all the data
types. Tarek's crack at the reaction network XML is a good start. But
there are already things I can think of for which it will not work or is
unnecessarily complicated.

## Distributed and Federated Data

We will not be able to, nor should we, database everything. One
important project will be to be able to connect to other biological
databases in a way transparent to the user. Thus middleware will have to
be written that connects these databases together and allows addition
and removal of databases at will (retaining information that is
currently being used locally to model!). One model of this is the SRS
database tools mentioned briefly above.

# G.U.I.

The graphical user interface is the central way a user will interact
with out framework.

## Model building

![](media/image2.jpeg){width="3.40625in" height="2.8569444444444443in"}

## Database entry and query

Our collaborators are producing data as varied as electrophysiological
results, cellular images, gene expression, enzyme kinetics, and protein
interactions. We should provide data entry templates for as many of
these as possible. For pathways and the like the graphical editor should
be the primary tool however a web-based interface should also be
possible. So we should develop a schema for data types (graphs, tuples,
images, and sets of these things, e.g.), experiment types (linked to
data types), and all of these should be linked to organism/strain/cell
type/developmental stage/location/reactions/etc. Our primary goals
should be expression data and pathway entry.

## Data and Simulation visualization

## 

# Data Analysis

## Sequence

## Structure

## Molecular profiling

Cluster analysis

## Experimental Design

# Model Analysis

## Sensitivity Analysis

## Time Scale Analysis

Singular perturbation

## Model Decomposition

## Bifurcation Theory

CONTENT

BIFPAK

## Filtering Signatures

## Automated Deletion/Overexpression

## Hypothesis Generation

# Simulation

The idea here is to allow the user to employ any damn kernel they want.
Impossible you say? I agree. But let's make it as general as possible.
In essence we need to be able to translate the XML sent by the GUI into
equations if requested. In fact, it may be that the XML directs that one
part of the file be made into Mathematica script and returned, and the
second part says integrate with Matlab and return, then using these
results, send the specification through specialize middleware that
parses the file for use with a distributed kernel system that uses one
kernel for one part of the system and a second kernel for another
wherein some interkernel communication is required.

## ODE/PDE/LE/ME/Algebraic/Qualitative