Forums

I can think of one way that this proposal could affect simulation.
Namely, with the entity concept, one could plot the total amount of
some entity which may be useful. One could also use the total amount
in rate laws and equations by referring to the entity id. Currently,
this can be done by creating an artificial total species and using an
assignment rule, but the entity idea seems a bit cleaner to me.

The problem I see though is what I'm often interested in is not how
many molecules of a species are in all compartments but rather how
many molecules are in all forms. For example, the total amount of CI
is the number of monomers, plus two times the number of dimers, plus
all the various bound CI molecules. This is not captured by the
entity concept. Rather you would need a notion of the composition of
a species in which you indicate the number of molecules in a species.
Also, if the molecule is a heterodimer or some other complex, you may
want to associate multiple molecules with the species. This idea of a
composition would solve Robert's problem, I believe, as well as my
own. It also would add semantical meaning in that total numbers of
molecules could be reported by a simulator.

I'm not sure though how strongly I would push to have such a concept
in the core. I would not argue against it, since it is useful. If
this idea is absorbed into the groups package, then I would like to
see it modified to accept a number which can be interpreted as the
number molecules in a complex as described above.

Cheers,

Chris

On Sep 8, 2009, at 10:12 AM, Nicolas Le novère wrote:

> Oliver Ruebenacker wrote:
>>>> As far as I can see, any argument you wage against species type or
>>>> entity could just as well be used against having compartment as an
>>>> attribute.
>>> Of course not. A compartment is an essential component of a
>>> species. And
>>> its identifier carries a precise semantics that is translated in
>>> mathematical expressions by the values of its size.
>>
>> If size was the only issue, you could have that more easily and more
>> flexibly by adding a size attribute to the species. Compartments
>> would
>> be an unjustified overkill.
>
> No, no, no. We are talking about quantitative models here. 1) you
> need a
> symbol for representing the compartment in equations and 2) you need
> to
> enforce consistency so that the compartment of all the relevant
> species is
> maintained at the same value.
>
> SBML is not BioPAX and vice-versa (otherwise we would not need two
> languages). In BioPAX, one is interested in the conceptual
> relationships
> between entities. This is why compartment was, in L2, an attribute
> of a
> physicalEntityParticipant. In SBML, the purpose is to encode models
> with
> rules describing the evolution of the model.
>
>>>> Also, can you please explain how you would unambiguously annotate
>>>> that two species refer to the same phospho-state of a protein? Or
>>>> the
>>>> same mutant? Or the same dimer?
>>> But that has nothing to do with the current debate. A free-form
>>> identifier
>>> will not address that. If you want to do that with no annotations,
>>> you can
>>> create a group, e.g. "MAPK-122P", and attach to it an element
>>> notes where
>>> you describe in human readable terms what it is.
>>
>> Of course it has to do with the current debate. You brought up
>> annotations as an argument against species types
>
> No, I did not. I say that if you need to describe precisely biological
> knowledge that does not affect the interpretation of the model, you
> must
> use annotation.
>
> The debate is (or should be) on how to group species in a larger set
> that
> one can identify. The proposal of Robert was to use another label such
> "phosphorylated_mapk", that would cover all the phosphorylated MAPK,
> whether in the cytoplasm or the nucleus. This is different to encode
> in a
> computationally usable framework the fact that this "species type"
> represent the set of all proteins in the cell that have the same
> nucleotide
> sequence and are phosphorylated.
>
>> All we want is being able to say that two species within the same
>> model are the same entity. You can do that perfectly with species
>> types, even if they are called jack and jill.
>
> And you already can with the name. And you will be able with the
> groups.
>
>>> THAT SAID, SpeciesType is not going to disappear. It is a core
>>> part of the
>>> multi package.
>>
>> We need to have entities in the SBML Core, not some package, because
>> entities are essential to the semantics of SBML. As essential as
>> compartments.
>
> No, it is not. If you load an SBML file in a simulator, any
> simulator, with
> or without specieTypes, and click run, you get exactly the same
> curves. If
> you suppress the compartments, you cannot reconstruct the ODEs.
>
> --
> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-
> Trust
> Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:
> +441223494521
> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nlenovere@hotmail.com(NOT
> email)
> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>
>
> ____________________________________________________________
> To manage your sbml-discuss list subscription, visit
> https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss
>
> For a web interface to the sbml-discuss mailing list, visit
> http://sbml.org/Forums/
>
> For questions or feedback about the sbml-discuss list,
> contact sbml-team@caltech.edu

____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu