Forums

This email outlines a proposal for a sets or collections in SBML.
I have attached previous proposals for arrays and model composition
as they are used as a basis for this outline proposal.

Aim
-----
To enable the use of collections of SBML components where the components
in a collection
do not form a sequence and where the components of a set are created and
destroyed during simulation.

Use case model
-----------------------
This proposal is aimed at supporting models containing a dynamic
collection of subsystems, e.g. a growing tissue, where

a) the subsystems (e.g. cells) themselves are complex
b) the subsystems are created and destroyed dynamically. This is
distinct from the creation and destruction of individual
chemical entities (molecules).
c) dynamic global constraints on subsystems are limited or non existent
i.e.local interaction is always more significant
d) although locality is typically going to be distance based: what
constitutes locality is arbitrary
e) the internals of subsystems are implicitly local to each subsystem -
the model assumes that
the internals of subsystems are held together .

Although these models are complex the detailed geometric behavior is not
modeled if at all e.g. the precise shape of cell
membranes are not modeled: for example a cell is simply a collection of
pools of species located at a given point in space. This
simplification enables the simulation of a relatively large number of
subsystems.

I believe that this reflects a large class of potential biological
models.

In the rest of this document the term object refers to a dynamically
created component that can be a member of a set.

Object Orientation - Justification of Approach
--------------------------------------------------------------------

The approach taken by this proposal is object oriented - sets 'only'
contain instances of submodels (see model composition proposal)
Set members are referenced by the state of their properties. The rest
of this section justifies
this approach.

The unique identity of objects is only supplied by the simulation
environment in a form that enables the evaluation of equality of object
identity
i.e. conceptually similar to built-in object identity in OO programming
environments.
Why? Given that the collections are not ordered it is not obvious what
identity an object can have
that is meaningful across a range of model types. The most robust
candidate approach might be based on object
linage but that assumes that dynamically created object always have a
mother and are not spontaneously created.
Maintaining complex object identity may place an overhead on the
simulation environment that is not required in most modeling
scenarios.

Within a model we only need to refer to objects when we wish to create
links between those objects or destroy those
objects. In most scenarios the links between between objects and object
lifetimes depend on dynamically varying
properties not on their identities e.g. the distance between objects and
p53 concentration internal to an object
respectively.

Objects are best represented as instances of submodels
a) objects are referenced by the state of their properties - SBML
components like species have
only a limited set of properties whereas a modeler can create any
number of components
within an instance each of which can be considered a property
b) instances provide a tidy way to represent the implicit localization
of subsystems.

Objects must be inserted into a set on creation (otherwise you don't
have a handle
on the object). Perhaps there may be a default set.

Set Membership
-----------------------

There are potentially a number of different approaches to organizing
object set membership.
The following are some possible schemes:

a) there is only one set per submodel type e.g. if we have a
Mitochondria submodel
then there is only one set for all Mitochondria instances. Objects
can't change
set membership

b) an object can only be a member of one set (an object can only be
inserted into
a set on creation).

c) an object can be a member of more than one set and can be removed or
inserted
into a set independently of creation and destruction

In all cases destruction removes the object from the set(s).

In the rest of this proposal we assume (b) since its not obvious that
(c) is required

Set Declaration
----------------------

A set declaration in its simplest form just declares an empty set
containing objects of a given type
(instances of the same submodel).

for example:

<listOfSets>
<set id="foo" submodel="cell.xml"/>
</listOfSets>

The submodel attribute will use the same mechanism for referencing
submodels
as instance declarations (see model composition proposal).

More complex declarations allow the definition of an initial membership
in a form
similar to array declarations. For example:

<listOfSets>
<set id="foo" submodel="cell.xml">
<listOfDimensions>
<dimension id="x">
<lowerLimit>
<m:math>
<cn>0</cn>
</m:math>
</lowerLimit>
<upperLimit>
<m:math>
<cn>0</cn>
</m:math>
</upperLimit>
</dimension>
</listOfDimensions>
</set>
</listOfSets>

The dimension symbols are only in scope within following dimension
elements within the
same set element and within InitialAssignmentRules (see array proposal)
that refer to the
given set. In the case of the initialAssignmentRule the set behaves
identically to an array
however in all other contexts behaves as a set i.e..e. its not possible
to refer to specific
members of a set by their indices because the indices don't exist at
simulation time.

A ListOfSets element is a top-level subelement of model.

Limited Object Identity
--------------------------------

An object can occur in a math <ci> element outside a csymbol element.
The resulting value simply reflects the identity of the object. No
assumptions
as to the relative values of these values should be made.

Referencing Objects
-----------------------------

How do we refer to objects? We do this performing a kind of query on the
simulation state.
This is achieved by the "forall" element. In its simplest case this
declares a symbol which ranges
over the contents of a set and declares events, rules and reactions that
occur for each symbol. The symbol is
only in scope within the 'forall' element.

for example

<listOfForAlls>
<forall>
<listOfMembers>
<member id="x" set="foo"/>
<listOfMembers>
<listOfReactions>
<reaction id="r">
<listOfReactants>
<speciesReference>
<speciesLink object="x">
<objectRef="s"/>
</speciesLink>
</speciesReference>
<listOfProducts>
<speciesReference id="s1"/>
</listOfProducts>
</reaction>
</listOfReactions>
</forall>
<listOfForAlls>

where 's' is a species within the 'cell.xml' submodel and
's1' is a species at the top level of the model.

this fragment means:

for all members x of foo there exists a reaction x.s -> s1

We can restrict the set of objects that the events, reaction and rules
(the body) apply to
through the use of a 'where' element which contains a Boolean
expression.
The body applies only for those members for which the where element
returns a true
result. For example:

<forall>
<listOfMembers>
<member id="x" set="foo"/>
<listOfMembers>
<where>
<m:math>
<m:apply>
<m:gt/>
<m:apply>
<csymbol encoding="SBML"
definitionURL="http://www.sbml.org/symbols/instanceselector">.
</csymbol>
<ci>x</ci>
<ci>s/ci>
</m.apply>
<m:cn> 10 </m:cn>
</m:apply>
</m:math>
</where>
<listOfReactions>
<reaction id="r">
<listOfReactants>
<speciesReference>
<speciesLink object="x">
<objectRef="s"/>
</speciesLink>
</speciesReference>
</listOfReactants>
<listOfProducts>
<speciesReference id="s1"/>
</listOfProducts>
</reaction>
</listOfReactions>
</forall>

this fragment means:

for all members x of foo there exists a reaction x.s -> s1 when x.s > 10

The forall element is designed to be used for defining the relationship
between
objects and their external environment. Ideally reactions etc that are
internal
to a model are defined within a submodel definition and not a forall
element.

To facilitate the definition of reactions between objects
we can declare more than one member symbols in a forall element.
E.g.:

<forall>
<listOfMembers>
<member id="x" set="foo"/>
<member id="y" set="foo2"/>
<listOfMembers>
...
</forall>

The rest of the forall element applies to all combinations of the
members listed
in the listOfMembers. So in the previous example if foo contains two
objects
and foo2 contains 3 objects then the forall element applies to the 6
different pairs
of members from the 2 sets foo and foo2.

We can apply the forall element to all pairs of members of the same set
e.g:


<forall>
<listOfMembers>
<member id="x" set="foo"/>
<member id="y" set="foo"/>
<listOfMembers>
...
</forall>

In this simple form one combination of x and y values will
refer to the same object. We can avoid this simply by comparing x and y
(specifically comparing the identities of x and y):

<forall>
<listOfMembers>
<member id="x" set="foo"/>
<member id="y" set="foo"/>
<listOfMembers>
<where>
<m:math>
<m:apply>
<m:neq/>
<m:ci>x</m:ci>
<m:ci>y</m:ci>
</m:apply>
</m:math>
</where>
...
</forall>

Hopefully you can see that forall elements can be used define
relationships
between objects.

Object Construction/Destruction on Event
------------------------------------------------------------

The event structure is extended to include two new subelements:
'listOfBirths' and 'listOfDeaths' containing 'birth' and 'death'
elements
(need better names: Constructions and Destructions??). These
indicate that an object is created and destroyed when the event is
executed.

In the simplest case, by default, the death element refers to
instances of the immediate enclosing submodel ('this' in OO terms)

for example:

<event>
<trigger>
<m:math>
<m:apply>
<m:gt>
<m:ci>p53</m:ci>
<m:cn>100</m:cn>
</m:apply>
</m:math>
</trigger>
<listOfDeaths>
<death/>
</listOfDeaths>
</event>

The death element can also be used to destroy objects that are in scope
using
the "object" attribute, for example:

<death object="x"/>

In the simplest case the birth element creates a new object in the same
set as the containing instance ('this' in OO terms) for example:

<event>
<trigger>
<m:math>
<m:apply>
<m:gt>
<m:ci>size</m:ci>
<m:cn>1000</m:cn>
</m:apply>
</m:math>
</trigger>
<listOfBirths>
<birth/>
</listOfBirths>
</event>

The birth element optionally assigns a symbol to the new object using
the id
attribute for example:

<birth id="x"/>

This symbol is only in scope in the following event assignment list.

For the general case the birth element has a 'set' attribute which
specifies the set
that the new object is inserted into, for example:

<birth id="x" set="foo"/>

Linking or Overloading sets
---------------------------------------

The link mechanism described in the model composition proposal
can be applied to sets so that a set in a submodel can become
the same as set in another submodel.

Possible Enhancement: Inheritance and Heterogeneous Sets
------------------------------------------------------------------------
--------------

One of the possible limitations of the above approach is that sets can't
be heterogeneous.
One approach to might be to enhance the model composition proposal to
include
support for type inheritance and then allow set members to be anything
derived from a base type.

yours

Andrew Finney
+44 (0)1453 827833
from US - 011 44 1453 827833
University of Hertfordshire, UK

	Attachment: arrays.pdf (Size: 172.12KB, Downloaded 626 time(s))
	Attachment: model-composition.pdf (Size: 152.44KB, Downloaded 614 time(s))

[Updated on: 01 Oct '03 16:09] by Moderator