SBML.org — the global portal for all things SBML

Multistate and Multicomponent Species Proposal old


Revision as of 16:28, 26 March 2009

Contents

Proposal title

Multistate/Multicomponent Species

Proposal authors

Nicolas Le Novère
European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge CB10 1SD, UK
Email: lenov at ebi.ac.uk

Anika Oellrich
European Bioinformatics Institute
Wellcome Trust Genome Campus
Hinxton, Cambridge CB10 1SD, UK
Email: anika at ebi.ac.uk

Proposal tracking number

sourceforge.net/tracker2/?func=detail&aid=2430531&group_id=71971&atid=894711 SBML issue tracking system].//sourceforge.net/tracker2/?func=detail&aid=2430531&group_id=71971&atid=894711 SBML issue tracking system].

Version information

Version number and date of public release

Version X released on DD Month YYYY.

URL for this version of the proposal

sbml.org/Community/Wiki/SBML_Level_3_Proposals/Multistate_Multicomponent_Species_%28Le_Novere_and_Oellrich_2007%29 http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/]//sbml.org/Community/Wiki/SBML_Level_3_Proposals/Multistate_Multicomponent_Species_%28Le_Novere_and_Oellrich_2007%29 http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/] sbml.org/Community/Wiki/SBML_Level_3_Proposals/Multistate_Multicomponent_Species_%28Le_Novere_and_Oellrich_2007%29 http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/]//sbml.org/Community/Wiki/SBML_Level_3_Proposals/Multistate_Multicomponent_Species_%28Le_Novere_and_Oellrich_2007%29 Multistate_Multicomponent_Species_%28Le_Novere_and_Oellrich_2007%29]

URL for the previous version of this proposal

Introduction and motivation

This package is addressing two different though related problems:

  • the representation of entities that can exist under different states affecting their behaviours (multistates). Those entities carry state features, and the possibly large number of state features, each able to take different values, may result in a combinatorial explosion for the number of alternative states taken by the entities.
  • the creation and behaviour of complexes made up of different components (= multi-components). The rules of assembly may lead to an unbounded list of species, with the number of components and their topology impossible to precise before the simulation.

Background

Problems with current SBML approaches

As a simple example, let's take a species (a receptor) with only one feature, the pore, that can adopt different values, closed, opened and desensitized. In addition to this single state feature, the receptor has one binding site anchor.

Schematic receptor example

Taking into account the different values for the state feature plus the status of the binding site (bound or not), this receptor can exist under six different states:

free, closed
free, open
free, desensitized
anchored, closed
anchored, open
anchored, desensitized

(assuming that one can considered all the entities binding to the anchor as identical when it comes to receptor state).

With the "regular" SBML, any reaction involving the receptor, such as binding to a ligand, will have to be written six times. Some of the state features and/or bonds may not affect the binding of the ligand, but the reactions have to be enumerated nevertheless, if we want to keep track of all the populations.

Writing all the possibilities can be in the best case just exhausting and in the worst case plainly impossible in case of combinatorial explosion. If an entity possesses 4 bivalued features and 2 trivalued features, the number of possible state is 24x32.

A dodecamer of CaMKII with 5 different characteristics taking two values (e.g. activity, binding to calmodulin and to ATP, phosphorylations in 286 and 306) exhibits 60 state features and consequently a billion of billion possible states. Writing a model using such a multistate multi-component species requires a way to describe only the relevant states of this species rather than all the possible ones.

To explain this situation further have a look at the following reaction:

Reaction alternating rates example

In this example, we have an entity carrying seven state features, shown as a vector. There is a base rate for setting the fourth state feature (changing the value from "0" to "1"). This base rate needs to be corrected as it is influenced by the first state feature being set/unset. Since none of the other state features influence the setting of the fourth flag, the modeler should not be forced to describe the 128 states and 64 possible reactions, but only the influence of the value of the first state feature.

Another problem addressed by the multi package is the unbounded list of multi-component species. Let's imagine a situation where we would like to model the growth of microtubules from dimers of tubulin. We cannot possibly enumerate all the possible microtubules of different lengths. Furthermore, the length of a microtubule does not affect the rate with which a new dimer of tubulin is incorporated. The only thing we need to encode is the binding between a tubulin dimer incorporated in a microtubule and a free tubulin dimer.

microtubule growth

In the schema above, the star represent a generic bond, where we know the binding site is occupied, but we do not care about the binding partner (it can be a tubulin dimer or a microtubule containing 100 tubulin dimers).

Proposed syntax and semantics

The proposal for extending SBML to carry the information for multistate multi-component species relies on the extension of the following core SBML elements:

  • Species
  • SimpleSpeciesReference
  • Reaction

In addition, the multistate multi-component package requires the creation of new elements:

  • SpeciesType
  • Selector
  • ReactionRule

In the UML diagram below, the elements and attributes of the package multi are drawn in red, while the elements and attributes belonging to SBML core are drawn in black. Not all of the latter are drawn, but only the ones needed to "plug" the package multi. Please consult the specification of the core for a deeper understanding of SBML at large.

SpeciesType

The element SpeciesType, which was part of SBML Level 2 specification, will be shifted to the multi extension with SBML Level 3. The element carries the basic attributes which it had before but is also extended for the needs of the extension.

Apart from an ID, a name, and several annotations, one can define furthermore StateFeatures, PossibleValues and BindingSites. The following UML diagram shows how the structure of the SpeciesType looks like.

Definition of classes SpeciesType, StateFeature, PossibleValue, and BindingSite, as well as the container classes ListOfStateFeatures, ListOfPossibleValues and ListOfBindingSites.
Definition of classes SpeciesType, StateFeature, PossibleValue, and BindingSite, as well as the container classes ListOfStateFeatures, ListOfPossibleValues and ListOfBindingSites.

A SpeciesType can carry any number of StateFeatures which are characteristic attributes specific for this type of species. After discussions between all to this extension contributing parties, it has been decided, that a StateFeature is NOT the same as a BindingSite. The reason for that decision is that a BindingSite can carry attributes specific to itself which is not necessary for a StateFeature.

Each StateFeature also requires the definition of PossibleValues which will be used within an Selectors to define the state of an entity which i.e. could then be used as a condition for a Reaction. A StateFeature is not obligatory a boolean property, but can take any number of possible values.

To show the usage of StateFeatures the above given example of the receptor pore shall be used. In this example, the StateFeature is the pore with the PossibleValues being open, closed and desensitized. The SBML code would then look like

<speciesType id="speciesType_1" name="example species Type 1">
  <l3m:listOfStateFeatures>
    <l3m:stateFeature id="pore">
      <l3m:listOfPossibleValues>
        <l3m:possibleValue id="open" />
        <l3m:possibleValue id="closed" />
        <l3m:possibleValue id="desensitized" />
      </l3m:listOfPossibleValues>
    </l3m:stateFeature>
  </l3m:listOfStateFeatures>
</speciesType>

In addition to A given BindingSite can be present several times on a speciesType, and this number can be variable. This does not mean one can create or destroy bindingSites during a simulation. But that different instances of this speciesType (as selected by a Selector, see below) can have a different number of a given bindingSite. The attributes minOccur and <maxOccur> define the minimal and maximal amount of

<speciesType id="speciesType_1" name="example species Type">
  <l3m:listOfStateFeatures>
    <l3m:stateFeature id="stateFeature_1">
      <l3m:listOfPossibleValues>
        <l3m:possibleValue id="possibleValue_1" />
        <l3m:possibleValue id="possibleValue_2" />
        <l3m:possibleValue id="possibleValue_3" />
      </l3m:listOfPossibleValues>
    </l3m:stateFeature>
  </l3m:listOfStateFeatures>
  <l3m:listOfBindingSites>
    <l3m:bindingSite id="bindingSite_1" name="example binding site 1" />
  </l3m:listOfBindingSites>
</speciesType>

Selector

A selector is a mask describing rules to build an entity, made of different components, carrying StateFeatures and displaying BindingSites involved in bonds or not. The selector when applied to a pool of entities, permit to filter it, and to obtain a further more refined entity pool. A selector can be reused in various places of a model, to restrict the application of a procedure to a certain set of topologies and states. Selectors can be used in Species, where they allow the refinement of initial conditions, for instance to specify the initial distribution of different states and topologies. They can also be used in Reaction to decide if a this reaction happens, or to modulate its velocity.

Principle idea selector

The above selector accepts everything containing a blue crystal, but rejects the red face and the isolated green crystal.

Definition of classes Selector, Bond, and BindingSiteReference, as well as the container classes ListOfSpeciesTypeState, ListOfBounds and ListOfUnboundBindingSites. The class SpeciesTypeState, in blue, is described below.
Definition of classes Selector, Bond, and BindingSiteReference, as well as the container classes ListOfSpeciesTypeState, ListOfBounds and ListOfUnboundBindingSites. The class SpeciesTypeState, in blue, is described below.

A selector defines the list of components composing the mask, the speciesTypeStates, with the various relevant StateFeatures. A speciesTypeState can contain other speciesTypeStates, that have to be also declared in the selector.

Definition of classes SpeciesTypeState, StateFeatureInstance, StateFeatureValue, and ContainedSpeciesType, as well as the container classes ListOfStateFeatureInstance, ListOfStateFeatureValues and ListOfContainedSpeciesType.
Definition of classes SpeciesTypeState, StateFeatureInstance, StateFeatureValue, and ContainedSpeciesType, as well as the container classes ListOfStateFeatureInstance, ListOfStateFeatureValues and ListOfContainedSpeciesType.

A speciesTypeState describes and ensemble of states a speciesType can be into in order to fulfill the requirements of the selector. Those states are defined by the values of the different stateFeatures carried by the speciesType, the list of speciesTypeStates it "contains", and their topology.

In addition to the components, the selector describes the bonds as well as the unboundBindingSites. Therefore a bindingSite can be described in four different contexts:

  • In a declared explicit bond, with another specific interactor (represented by a bond linking two entities in the example graphs).
  • In a declared bond without another specific interactor, meaning any interactor (represented by a "*" in the example graphs).
  • Declared as explicitly unbound (represented by a bond with a dangling end in the example graphs).
  • Undeclared, meaning that one does not care if it is bound or not (represented by a "?" in the example graphs).
Structure of the selector

The boolean attributes connex and saturated precises the topology of a multimeric assembly of the same component (same speciesTypeState, that is same speciesType with the same values allowed for their stateFeatures) within a containing speciesTypeState. One can then declare the component only once, and each of the bond type or unbound binding site only once. Note that in the case of "top-level" multimers, that is not contained in another speciesTypeState, all the monomers have to be enumerated. That is, one has to create several speciesTypeStates corresponding to the same speciesType with the same stateFeature values, and one has to enumerate all the bonds. (Of course one can also use this procedure with the contained species type states).

Here are examples of the difference possibilities:

Connexity and saturation
<selector id="selector_1">
  <l3m:listOfSpeciesTypeStates>
    <l3m:speciesTypeState id="speciesTypeState_1" speciesType="speciesType_1">
      <l3m:listOfStateFeatureInstances>
        <l3m:stateFeatureInstance stateFeature="stateFeature_1">
          <l3m:listOfStateFeatureValues>
            <l3m:stateFeatureValue possibleValue="possibleValue_1" />
            <l3m:stateFeatureValue possibleValue="possibleValue_2" />
          </l3m:listOfStateFeatureValues>
        </l3m:stateFeatureInstance>
      </l3m:listOfStateFeatureInstances>
    </l3m:speciesTypeState>
    <l3m:speciesTypeState id="speciesTypeState_2" speciesType="speciesType_2">
      <l3m:listOfContainedSpeciesTypes>
        <l3m:containedSpeciesType speciesTypeState="speciesTypeState_1" 
                                  minOccur="4" maxOccur="4" 
                                  connex="true" saturated="true" />
      </l3m:listOfContainedSpeciesTypes>
    </l3m:speciesTypeState>
  </l3m:listOfSpeciesTypeStates>
  <listOfBonds>
    <l3m:bond prohibited="false">
      <l3m:bindingSiteReference speciesTypeState="speciesTypeState_1" bindingSite="bindingSite_1" />
      <l3m:bindingSiteReference speciesTypeState="speciesTypeState_2" bindingSite="bindingSite_4" />
    </l3m:bond>
  </l3m:listOfBonds>
  <l3m:listOfUnboundBindingSites>
    <l3m:bindingSiteReference speciesTypeState="speciesTypeState_1" bindingSite="bindingSite_1" />
  </l3m:listOfUnboundBindingSites>
</selector>

Species

With the introduction of multistate multi-component SpeciesTypes, the possibility of defining initial states for Species is needed. We can apply Selectors to the element Species in order to restrict the initial states and partnerships the species are in.

Definition of classes InitialSpeciesInstance, as well as the container classes ListOfInitialSpeciesInstances. The referenced class Selector in blue, is described above.
Definition of classes InitialSpeciesInstance, as well as the container classes ListOfInitialSpeciesInstances. The referenced class Selector in blue, is described above.
<species id="species_1" speciesType="speciesType_1" compartment="compartment_1" initialAmount="1000" >
  <l3m:listOfInitialSpeciesInstances>
    <l3m:initialSpeciesInstance id="initialSpeciesInstance_1" initialProportion="0.9" selector="selector_1" />          
    <l3m:initialSpeciesInstance id="initialSpeciesInstance_2" initialProportion="0.1" selector="selector_2" />
  </l3m:listOfInitialSpeciesInstances>
</species>

Note that a species is located in a given compartment. However, this species can be selected with a selector using several speciesType. Another species, located in another compartment, could be selected by a different "part" of the same selector. This provides a mechanism to build multi-compartment entities.

Reaction

Selector
Selector
<reaction id="reaction_1">
  <listOfReactants>
    <speciesReference species="speciesType_1" stoichiometry="1">
      <l3m:listOfSpeciesTypeRestrictions>
        <l3m:speciesTypeRestriction id="speciesTypeRestriction_1" selector="selector_1" />
      </l3m:listOfSpeciesTypeRestrictions>
    </speciesReference>
  </listOfReactants>
  <listOfProducts>
    <speciesReference species="speciesType_1" stoichiometry="1">
      <l3m:listOfSpeciesTypeRestrictions>
        <l3m:speciesTypeRestriction id="speciesTypeRestriction_2" selector="selector_4" />
      </l3m:listOfSpeciesTypeRestrictions>
    </speciesReference>
  </listOfProducts>
  <kineticLaw>
    <!-- No reaction if multi package is not supported -->
    <math xmlns="http://www.w3.org/1998/Math/MathML">
      <cn>0</cn>
    </math>
  </kineticLaw>
  <l3m:listOfReactionRules>
    <l3m:reactionRule id="reactionRule_1">
      <l3m:listOfConditions>
        <l3m:condition speciesTypeRestriction="speciesTypeRestriction_1" />
      </l3m:listOfConditions>
      <l3m:listOfResults>
        <l3m:result speciesTypeRestriction="speciesTypeRestriction_2" />
      </l3m:listOfResults>            
      <kineticLaw>
        <math xmlns="http://www.w3.org/1998/Math/MathML">
          <apply>
            <times />
            <ci>kon</ci>
            <ci>speciesTypeRestriction_1</ci>
          </apply>
        </math>
        <listOfParameters>
          <parameter id="kon" value="1" />
        </listOfParameters>
      </kineticLaw>
    </l3m:reactionRule>
  </l3m:listOfReactionRules>
</reaction>

Package dependencies

The package as proposed here does not depend on any other SBML Level 3 packages.

Use-cases and examples

We provide walk-through of a complete example on a separate page. It contains SBML files, diagrams, and comments to explain the encoding and usage of this proposed package in SBML.

Prototype implementations

Translation to SBML Level 2

Unresolved issues

References

Appendix



Please use our issue tracking system for any questions or suggestions about this website.