SBML.org — the global portal for all things SBML

Proposed package for multistate multicomponent entities

Authors: Nicolas Le Novère and Anika Oellrich

Contents

Introduction

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.

Specific examples to illustrate the need for this package

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).

Proposal

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

  • SpeciesType
  • Species
  • SimpleSpeciesReference
  • Reaction

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

  • Selector
  • ReactionRule

SpeciesType

The element SpeciesType of the core is extended to carry the description of the StateFeatures of an entity, all the PossibleValues they can possibly take, but also the BindingSites and their possible interacting partners (Interactor).

SpeciesType

A StateFeatures is not obligatory a boolean property, but can take any number of possible values.

A given bindingSite can be present several times on a speciesType, and this number can be variable. The attributes minOccur and <maxOccur> define the minimal and maximal amount of binding sites. An entity cannot be saturated (see below) until minOccur of this specific bindingSite are occupied, and cannot have more than minOccur of this specific bindingSite occupied.

For a given binding site, if no interactor is declared with an attribute possible="true", the bindingSite can bind to any other bindingSite, except those declared as interactors with the attribute possible="false". This behaviour is disabled as soon as an interactor is declared with the attribute possible="true". In that case, all unspecified interactors are assumed to be unable to bind.

<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:listOfInteractors>
        <l3m:interactor speciesType="speciesType_2" bindingSite="bindingSite_4" possible="true" />
        <l3m:interactor speciesType="speciesType_3" bindingSite="bindingSite_3" possible="false" />
      </l3m:listOfInteractors>
    </l3m:bindingSite>
  </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
Selector

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.

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
SpeciesTypeState

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.

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>
      <l3m:bindingSiteReference speciesTypeState="speciesTypeState_1" bindingSite="bindingSite_1" />
      <l3m:bindingSiteReference speciesTypeState="speciesTypeState_2" bindingSite="bindingSite_4" />
    </l3m:bond>
  </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.

Species
<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>

Complete examples for the multistate multi-component proposal

This sections contains some SBML files with comments and pictures to explain the encoding/usage of the package in SBML.

Walk through a complete example.

Retrieved from "http://sbml.org/Community/Wiki/Proposed_package_for_multistate_multicomponent_entities"

This page was last modified 09:45, 7 October 2008.



Please use our issue tracking system for any questions or suggestions about this website. This page was last modified 09:45, 7 October 2008.