Forums

Hi Robert,

Robert Phair wrote:

> While we had invested significant time and resources coding to the L2
> spec and making use of SpeciesType, we acknowledge that our use of
> SpeciesType was basically a hack. Nevertheless, I believe the purpose
> for which we adopted SpeciesType is important and universal and I would
> like to propose a simple addition to the L3 core specification that will
> meet this important and universal need.

I believe most people agree with that position, that is the need to
identify the species of the "same type". And the grouping package proposed
by Mike is meant to address your need. A very important difference with
SpeciesType is that we will be able to build several inheritances.

>> but
>> having built mathematical models of biological systems for more than
>> 40 years, the SBML object Species is named and used in a way that
>> hides its true ontological character

I beg to disagree. I have not build models for 40 years, but the SBML
species is the core unit of any dynamic model. It is defined as the set of
all objects that are indistinguishable as far as the model is concerned.
This is the variable one describes the evolution of and for which one
reconstructs an ODE. Model of calcium signalling do not have a variable
called calcium, but a calcium in cytosol, calcium in ER etc.

>> and furthermore makes it
>> impossible to write an algorithm that extracts from a ListOfSpecies
>> the fundamental entities that define each Species.

If we are talking of automated extraction here, one should use controlled
annotations. Many groups developed algorithms to use those annotations,
such as SAINT, SemanticSBML, libAnnotationSBML etc. It is trivial to
extract all "ATP" from all compartments if they are annotated with the same
PubChem/ChEBI/KEGG entry.

> Here are some of the Species definitions from Alicia Smith�??s justly
> famous model of Ran transport. These were copied from BioModels.net
> Model 164.
>
> <listOfSpecies> + <species metaid="metaid_0000034" id="Carrier_Cytosol"
> name="Carrier_Cytosol" compartment="Cytosol"
> initialConcentration="11.8952664327711" spatialSizeUnits="litre"> +

> A species is defined by an entity-Compartment pair.

But this is redundant right? This could be rewritten as

id Carrier_Cytosol
name Carrier
compartment Cytosol

id Carrier_Nucleus
name Carrier
compartment Nucleus

And here you go. You have your "entity" Carrier.

> I assert that this is currently impossible without annotations, and that
> it is so fundamental a concept that it should be possible in the L3
> Core.

I am not sure to understand. It is possible in L3 Core with annotations.
And without controlled annotations, any such effort is moot. How do-you
know that:

ATP
adenosine 5'-(tetrahydrogen triphosphate)
Adenosine 5'-triphosphate
Adenosine triphosphate
H4atp
ZKHQWZAMYRWXGA-FJYXAIENDD
Nc1ncnc2n(cnc12)[C@@H]1O[C>@H](COP(O)(=O)OP(O)(=O)OP(O)(O)=O)[C@@H](O)[C@H]1O

are the same.

Remember, SBML is an exchange format. We are not talking about using it for
your sole purpose. If this is the case, do whatever you want, event your
own variation of SBML. This does not concern this list.

> You can easily extract the Compartment. Why not the entity?

I would be tempted to say you can, from the name, if you have a consistent
naming scheme.

> There are no rules on the syntax of either that
> would, in the general case, permit a program to extract the identity of
> the entity (e.g. molecule or molecular complex) from the species id or
> the species name.

Exactly. This is why one should use annotations for that.

> The frequently heard proposal that entity information should be encoded
> in annotations suffers from multiple weaknesses, most of which were
> cited at the Forum

Which ones were cited at the forum?????

2. MIRIAM
> annotations rely on the presence, in some web resource, of exactly the
> molecule(s) you want to reference �?? including its post-translational
> modifications or its �??active�?? or �??inactive�?? state.

Of course not. Only if you want to do something with the annotations. But
if you just want to identify the species with an algorithm, which seems to
be your goal, you can just call "ATP" CHEBI:15422. And that's it. You do
not need any web resource.

> Most such
> annotations terminate at isVersionOf and simply fail to distinguish
> among related molecules.

This is just simply untrue. Not "most such annotations".

I am sorry, but I fail to see how a non-regulated "label" is better. How is
naming a species "Human-MAPK-P" better than two controlled annotations, one
to Uniprot and one to PSI-MOD?

3. Research work frequently involves molecules
> that are not yet in any database. SBML should support work on the
> cutting edge as well as it supports work on textbook pathways.

I simply never encounter the case where I could not annotate a specific
species. The only cases that are not annotated in BioModels DB is when the
species is completely generic ("shiff base"). And I am not sure any other
scheme would solve that. PubChem contains several millions compounds, and
UniProt contains all proteins. Do-you have a specific example?

> A Species is �??Entity in Compartment,�?? not just Entity. By saying
> that Species maps to material entity we are perpetuating the
> misconception that Species really does identify a molecule or a
> molecular complex.

I am sorry Robert but it is YOUR opinion that it is a misconception. For
MANY people an entity pool IS the type of molecule. This is definitively
the case for modelers. But even for biochemists, the location is sometimes
part of the identity. If only because different compartments have different
pH, and therefore the molecules have different protonation states.

> Indeed, I suspect that many people read Species and
> think chemical species.

Who? Who are those many people you are talking about. This is an arbitrary
statement, that is based on your apparent opinion that nobody else think
clearly. I personally rarely, if ever, met someone who made the mistake
(assuming that we are talking about your "ideal" chemical species, which
composition would not depends on the location) (I did in the BioPAX
community, but their aim is different).

> If you work with models that have only one compartment, you never
> encounter this difficulty because your Species name can be the name of
> the molecule/entity with no ambiguity. But as soon as you want to put
> the same molecule in multiple Compartments, the uniqueness requirement
> of Species id forces you to add some version of _Nucleus to your Species
> id.

But you are not forced to do that on names. And such a multi-compartment
model will be used by software able to use compartments would display them,
and there would not be any confusion.

> <ListOfEntities> <entity id=�??Arf1�?? name=ARF1_HUMAN �?� other
> attributes? /> <entity id=�??BFA�?? name=Brefeldin A />
> </ListOfEntities>
>
> and insert an new required attribute in the Species element:
>
> <species id=�??Arf1_Golgi�?? name=�??ARF1_HUMAN in Golgi�??
> compartment=�??Golgi�?? entity=�??Arf1�?? initialAmount=�??1e5�??
> boundaryCondition=�??false�?? constant=�??false />

But ... 1) this is completely redundant and 2) that information does not
give you any exchangeable information on the so-called "entity".

> A program reading an SBML file should not be left to guess the identity
> of the entity referred to in a Species element.

First of all, most programs reading an SBML do not need to know that
information. They are simulators. And for a simulator, it is sufficient to
have X in a compartment and Y in another, with transport in between. No
need to require an explanation that X and Y are the same (whatever the same
means).

But if those program need that: Either you just want to link the species,
and then you can use the groups, or you want to know something about the
biochemical identity of the species and you use annotations.

I am sorry, but your proposed attribute is redundant and uncontrolled. It
carried no semantic at all IMHO.

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

Hello Nicolas, All,

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.

According to SBO, an entity is defined by its structure. You wrote
that, it says. No word about location.

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?

Take care
Oliver

On Mon, Sep 7, 2009 at 12:35 PM, Nicolas Le novère<lenov@ebi.ac.uk> wrote:
> Hi Robert,
>
> Robert Phair wrote:
>
>> While we had invested significant time and resources coding to the L2
>> spec and making use of SpeciesType, we acknowledge that our use of
>> SpeciesType was basically a hack. Nevertheless, I believe the purpose
>> for which we adopted SpeciesType is important and universal and I would
>> like to propose a simple addition to the L3 core specification that will
>> meet this important and universal need.
>
> I believe most people agree with that position, that is the need to
> identify the species of the "same type". And the grouping package proposed
> by Mike is meant to address your need. A very important difference with
> SpeciesType is that we will be able to build several inheritances.
>
>  >> but
>>> having built mathematical models of biological systems for more than
>>> 40 years, the SBML object Species is named and used in a way that
>>> hides its true ontological character
>
> I beg to disagree. I have not build models for 40 years, but the SBML
> species is the core unit of any dynamic model. It is defined as the set of
> all objects that are indistinguishable as far as the model is concerned.
> This is the variable one describes the evolution of and for which one
> reconstructs an ODE. Model of calcium signalling do not have a variable
> called calcium, but a calcium in cytosol, calcium in ER etc.
>
>>> and furthermore makes it
>>> impossible to write an algorithm that extracts from a ListOfSpecies
>>> the fundamental entities that define each Species.
>
> If we are talking of automated extraction here, one should use controlled
> annotations. Many groups developed algorithms to use those annotations,
> such as SAINT, SemanticSBML, libAnnotationSBML etc. It is trivial to
> extract all "ATP" from all compartments if they are annotated with the same
> PubChem/ChEBI/KEGG entry.
>
>> Here are some of the Species definitions from Alicia Smithâ??s justly
>> famous model of Ran transport. These were copied from BioModels.net
>> Model 164.
>>
>> <listOfSpecies> + <species metaid="metaid_0000034" id="Carrier_Cytosol"
>> name="Carrier_Cytosol" compartment="Cytosol"
>> initialConcentration="11.8952664327711" spatialSizeUnits="litre"> +
>
>> A species is defined by an entity-Compartment pair.
>
> But this is redundant right? This could be rewritten as
>
> id Carrier_Cytosol
> name Carrier
> compartment Cytosol
>
> id Carrier_Nucleus
> name Carrier
> compartment Nucleus
>
> And here you go. You have your "entity" Carrier.
>
>> I assert that this is currently impossible without annotations, and that
>> it is so fundamental a concept that it should be possible in the L3
>> Core.
>
> I am not sure to understand. It is possible in L3 Core with annotations.
> And without controlled annotations, any such effort is moot. How do-you
> know that:
>
> ATP
> adenosine 5'-(tetrahydrogen triphosphate)
> Adenosine 5'-triphosphate
> Adenosine triphosphate
> H4atp
> ZKHQWZAMYRWXGA-FJYXAIENDD
> Nc1ncnc2n(cnc12)[C@@H]1O[C>@H](COP(O)(=O)OP(O)(=O)OP(O)(O)=O)[C@@H](O)[C@H]1O
>
> are the same.
>
> Remember, SBML is an exchange format. We are not talking about using it for
> your sole purpose. If this is the case, do whatever you want, event your
> own variation of SBML. This does not concern this list.
>
>> You can easily extract the Compartment. Why not the entity?
>
> I would be tempted to say you can, from the name, if you have a consistent
> naming scheme.
>
>> There are no rules on the syntax of either that
>> would, in the general case, permit a program to extract the identity of
>> the entity (e.g. molecule or molecular complex) from the species id or
>> the species name.
>
> Exactly. This is why one should use annotations for that.
>
>> The frequently heard proposal that entity information should be encoded
>> in annotations suffers from multiple weaknesses, most of which were
>> cited at the Forum
>
> Which ones were cited at the forum?????
>
> 2.      MIRIAM
>> annotations rely on the presence, in some web resource, of exactly the
>> molecule(s) you want to reference â?? including its post-translational
>> modifications or its â??activeâ?? or â??inactiveâ?? state.
>
> Of course not. Only if you want to do something with the annotations. But
> if you just want to identify the species with an algorithm, which seems to
> be your goal, you can just call "ATP" CHEBI:15422. And that's it. You do
> not need any web resource.
>
>> Most such
>> annotations terminate at isVersionOf and simply fail to distinguish
>> among related molecules.
>
> This is just simply untrue. Not "most such annotations".
>
> I am sorry, but I fail to see how a non-regulated "label" is better. How is
> naming a species "Human-MAPK-P" better than two controlled annotations, one
> to Uniprot and one to PSI-MOD?
>
> 3.      Research work frequently involves molecules
>> that are not yet in any database. SBML should support work on the
>> cutting edge as well as it supports work on textbook pathways.
>
> I simply never encounter the case where I could not annotate a specific
> species. The only cases that are not annotated in BioModels DB is when the
> species is completely generic ("shiff base"). And I am not sure any other
> scheme would solve that. PubChem contains several millions compounds, and
> UniProt contains all proteins. Do-you have a specific example?
>
>> A Species is â??Entity in Compartment,â?? not just Entity. By saying
>> that Species maps to material entity we are perpetuating the
>> misconception that Species really does identify a molecule or a
>> molecular complex.
>
> I am sorry Robert but it is YOUR opinion that it is a misconception. For
> MANY people an entity pool IS the type of molecule. This is definitively
> the case for modelers. But even for biochemists, the location is sometimes
> part of the identity. If only because different compartments have different
> pH, and therefore the molecules have different protonation states.
>
>> Indeed, I suspect that many people read Species and
>> think chemical species.
>
> Who? Who are those many people you are talking about. This is an arbitrary
> statement, that is based on your apparent opinion that nobody else think
> clearly. I personally rarely, if ever, met someone who made the mistake
> (assuming that we are talking about your "ideal" chemical species, which
> composition would not depends on the location) (I did in the BioPAX
> community, but their aim is different).
>
>> If you work with models that have only one compartment, you never
>> encounter this difficulty because your Species name can be the name of
>> the molecule/entity with no ambiguity. But as soon as you want to put
>> the same molecule in multiple Compartments, the uniqueness requirement
>> of Species id forces you to add some version of _Nucleus to your Species
>> id.
>
> But you are not forced to do that on names. And such a multi-compartment
> model will be used by software able to use compartments would display them,
> and there would not be any confusion.
>
>> <ListOfEntities> <entity id=â??Arf1â?? name=ARF1_HUMAN â?Š other
>> attributes? /> <entity id=â??BFAâ?? name=Brefeldin A />
>> </ListOfEntities>
>>
>> and insert an new required attribute in the Species element:
>>
>> <species id=â??Arf1_Golgiâ?? name=â??ARF1_HUMAN in Golgiâ??
>> compartment=â??Golgiâ?? entity=â??Arf1â?? initialAmount=â??1e5â??
>> boundaryCondition=â??falseâ?? constant=â??false />
>
> But ... 1) this is completely redundant and 2) that information does not
> give you any exchangeable information on the so-called "entity".
>
>> A program reading an SBML file should not be left to guess the identity
>> of the entity referred to in a Species element.
>
> First of all, most programs reading an SBML do not need to know that
> information. They are simulators. And for a simulator, it is sufficient to
> have X in a compartment and Y in another, with transport in between. No
> need to require an explanation that X and Y are the same (whatever the same
> means).
>
> But if those program need that: Either you just want to link the species,
> and then you can use the groups, or you want to know something about the
> biochemical identity of the species and you use annotations.
>
> I am sorry, but your proposed attribute is redundant and uncontrolled. It
> carried no semantic at all IMHO.
>
> --
> 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
>



--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
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

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

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

Controlled annotations currently have a limited semantics. At the moment
we can only say that a species is a version of a protein, and that a
species is phosphorylated. We actually know how we could say it is a
phosphorylated version of a protein. This requires to put an id on an
annotation. It was refused for L2V4 and postponed to L3, but finally did
not make it to the core.

But again, this is not the current issue. The current issue is to tag
several species as being versions of the same class of species. This is
perfectly achieved with the groups.

THAT SAID, SpeciesType is not going to disappear. It is a core part of the
multi package.


--
Nicolas LE NOVERE, Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223494521, Fax: +44(0)1223494468, Mob: +44(0)7833147074
http://www.ebi.ac.uk/~lenov, AIM:nlenovere, MSN:nlenovere@hotmail.com

____________________________________________________________
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

Hello All,

I like to make a couple of general comments as their seems to be some
confusion.

1) SBML is (as Nicolas stated repeatedly) about modeling.
2) A compartment is not just a container holding species it has a
simulation values (its size) by itself.
3) A species is as Nicolas said a pool of indistinguishable object

The above lead to the decision a very very long time back that the
primary modeling objects of SBML are the compartments and species. This
is a fact and cannot be changed without major impact and I really do not
think that anyone wants to do that.

The above does not mean that I disregard the desire to identify species
of being of a particular "kind", whatever this means. SBML provides in
L2 the speciesType to achieve this. Similarly I recognize one might want
to speciefy the "kind" of compartments, parameters, and reactions. To
achieve this uniformally, we (the editors) proposed a while ago to
remove the compartment and species type in L3 and replace it with a more
general mechanism.

Mike has made a first attempt in proposing a solution which allows
grouping and would have welldefined semantics. There might be some minor
issues with it and therfore I would appreciate that this discussion be
focused on how Mike's proposal can be improved/modified to address the
annotation needs Robert and Oliver address.

While we are not having the grouping mechanism in place in L3 yet. I
like to point out that there exist already a perfectly valid way to
annotate the biological information needed, i.e., that a particular
species is some gene, protein or molecule. This is the MIRIAM
compliant annotation. This may be cumbersome but until a general
grouping mechanism is defined I think it suffices.

Thanks,
Stefan


--
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax: (540) 231-2606
Email: shoops@vbi.vt.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

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

Hello, Nicolas, All,

On Mon, Sep 7, 2009 at 3:45 PM, Nicolas Le nov�re<lenov@ebi.ac.uk> wrote:
> Oliver Ruebenacker wrote:
>
>> � I am working on bridging SBML with BioPAX, where there is no
>> explicit species, but a species is always implied by a combination of
>> a location and an entity.
>
> Well, it is actually not completely true. This is the other way round.
> There is no species in BioPAX Level 2, only SpeciesTypes
> (PhysicalEntities). And then there are speciesReferences
> (PhysicalEntityParticipants). Species can be infered from both.

I said "is implied" and you say "can be infered". I am not sure what
is the difference between those two.

> There are already several BioPAX-SBML convertors. No problem there.

I thought you had agreed earlier that conversion is always lossy?

> Yes, that is true. But as I said in former answers there are already at
> least three ways of doing so.

ATP is a misleadingly example, because it is a small molecule with a
well-defined chemical structure. We would not have annotations if all
we worried about was identifying small molecules. Why don't you show
us how annotations work for typical bio-molecule with variations, such
as:

- variant sequences (variants and mutations)
- post-translational modifications (e.g. phosphorylations)
- different ways to form complexes (e.g. actin with varying monomers)

I agree that species types don't reliably identify across models.
But at least, they identify within one model, which is already worth a
lot, is achieved by simple standardized means and is in no way
accomplished like that with annotations.

Take care
Oliver

--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
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

Hello Oliver,

On Tue, 08 Sep 2009 11:48:24 -0400
Oliver Ruebenacker <curoli@gmail.com> wrote:

> Hello Stefan, All,
>
> I don't know what confusion you are talking about or why you think
> you need to state the obvious, that SBML is about modelling. I also
> don't understand why you repeat Nicolas' argument that compartments
> are special because they have a number associated with it, while
> ignoring my response to that. I am sure we can add some number to
> entities as well.
>

You have several species in the same compartment thus having a
compartment entity facilitates normalization. Your alternative would
require manual synchronization of the compartment size for all species
in the same compartment.

> It surprises me that, after even Nicolas conceded the weakness of
> MIRIAM annotations, you still insist they are perfect and only
> "cumbersome". If you think that, then please provide examples how to
> annotate variant sequences, post-translational modifications and
> different complex formations.

I did not say at all that the way MIRIAM annoation is implemented in
SBML is good. In fact I am one of the harshes critics. However any
grouping mechanism will require the group to be annotated with MIRIAM
information to identify the group in a MIRIAM complian way. We all know
that names are not an option. Thus MIRIAM annotation will be part of the
final solution. Improving the capabilities of providing MIRIAM compliant
annotation is another problem.

>
> If a species is a pool of indistinguishable things, it is only
> natural that two species that contain the same indistinguishable
> things have a unique relationship and therefore require a unique way
> of being grouped.

The above is a logically wrong statement. How can two indistinguishable
things be distinguishable. It seems that my attempt to remove confusion
was not sufficient though you claim that there is no need for this ;)

Thanks,
Stefan


--
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility II
Blacksburg, Va 24061, USA

Phone: (540) 231-1799
Fax: (540) 231-2606
Email: shoops@vbi.vt.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

Hello Nicolas, All,

On Tue, Sep 8, 2009 at 12:12 PM, Nicolas Le nov�re<lenov@ebi.ac.uk> wrote:
> Oliver Ruebenacker wrote:
>> � 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.

Just plug in the same value everywhere where the same value is
needed. That's easy. Optionally, use a parameter.

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

Rest assured that I know the difference between SBML and BioPAX. I
published papers on this precise issue.

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

That's the same.

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

How is it different?

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

No you can not do it with names, because there is no standard for
it. If you want to propose to add such a standard to L3 Core, go
ahead. We want something in Core, and we want it existing. Groups are
neither.

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

It's trivial to redesign SBML to make compartments obsolete.
Compartment size is just a little number that can be easily moved
somewhere else. You can justify compartments on philosophical grounds,
or argue with traditions, but you can not defend them based on
mathematical necessity.

Take care
Oliver

--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
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

Hello Ion, All,

On Tue, Sep 8, 2009 at 12:21 PM, Moraru,Ion<Moraru@neuron.uchc.edu> wrote:
>>THAT SAID, SpeciesType is not going to disappear. It is a core
>>part of the multi package.
>
> I would like to emphasize Nicolas' statement above. �It seems lost on
> many of the folks waging this current war of words.

I saw that, but I think species type (or entity) should be in the
core (not the core of a package).

Take care
Oliver

--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
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

Hello Nicolas, All,

On Tue, Sep 8, 2009 at 12:30 PM, Nicolas Le nov�re<lenov@ebi.ac.uk> wrote:
> Oliver Ruebenacker wrote:
>> � It surprises me that, after even Nicolas conceded the weakness of
>> MIRIAM annotations, you still insist they are perfect and only
>> "cumbersome".
>
> I never "conceded" that those annotations could not be used to identified
> species of the same "kind". I merely pointed out that they had a limited
> expressibility.

No you can not identify species, if it involves variants,
modifications and different complex formations.

>> � If a species is a pool of indistinguishable things, it is only
>> natural that two species that contain the same indistinguishable
>> things have a unique relationship and therefore require a unique way
>> of being grouped. Trying to use the same grouping scheme for
>> distinguishable and indistinguishable things does not make sense.
>
> But ... this is exactly what we do not do. Species are grouping
> indistinguishable things. Groups are grouping sets of distinguishable things.

The species are distinguishable, the objects in it are indistinguishable.

Take care
Oliver

--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
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

Chris J. Myers wrote:
> 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.

I do not see why this is "artificial", but I actually agree this is a good
idea. And the group fits that perfectly.

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

Exactly! Thanks for pointing that. If I have four species MAPKK, MAPKKP,
MAPK, MAPKP, I want to be able to say "all the MAPK proteins", "all the
phosphorylated proteins", "all the kinases"

group kinases: MAKP, MAPKP, MAPKK, MAPKKP
group MAPK: MAPK, MAPKP
group phosphorylated: MAPKP, MAPKKP

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

Yes, I would very much like that too actually.



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

curoli> If size was the only issue, you could have that
curoli> more easily and more flexibly by adding a size
curoli> attribute to the species. Compartments would be an
curoli> unjustified overkill. Eliminating them would avoid
curoli> uncontrolled labels, so according to your logic
curoli> should be a good thing.
curoli>
curoli> So I still don't see how compartments are more
curoli> essential than species types. If you want to be
curoli> consistent, you should either have both or
curoli> neither. I'm in favour of having both. I don't
curoli> understand how some one can be in favour of having
curoli> one of them.

I'm sorry, but IMNO these statements about compartments are:

(1) Just plain wrong. Compartments are more than just size.
They are *structural elements* of a model, they carry
dimensions and units (not just size), and they have
semantic meaning. To call them "overkill" and
nonessential, and propose instead that they can be
simply replaced by a numerical attribute on a species or
a regular parameter reveals serious misunderstandings
about the needs of compartmental modeling.

(2) Irrelevant to the original point that Robert Phair was
discussing, which concerned species and species types.

Let's go back to resolving Robert's issue.

MH

____________________________________________________________
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

Here's an attempt at a summary of the debate so far.

I agree with Nicolas and Stefan that Species and Compartments are the natural terms in which to write models. We also agree that a Species is a pool of indistinguishable entities or items or molecules or molecular complexes.

I agree with Mike and Nicolas and Stefan and many other posters to this topic, that the concept of Groups is going to be extremely useful and I look forward to a draft spec.

But I still cannot see why we should be satisfied with a Core spec that lists all the pools of indistinguishable entities and tells us exactly where they are located but provides no required attribute that reveals what those indistinguishable entities ARE. My reading of Jim's post suggests he too thinks adding such an attribute would be valuable.

There are only two required attributes for Species: id and compartment. Most of us are happy with the compartment attribute, and I agree with Nicolas and Mike and others that compartment BELONGS in the species object and has multiple essential features, not just size. This leaves id to do the rest of the essential work of defining a species.

Some of the posters to this topic think any unique value for species id completes the work of of defining a species. This is the status quo.

The rest of us think the work isn't done until a software tool can tell us the identity of the indistinguishable entities represented by the species. So let's look at the status quo in more detail.

The species id attribute can have any syntax permitted by the SId data type. There is no requirement that the id attribute conveys the identity of the indistinguishable entities, but nearly everyone tries to do so. Consequently, in current best practice the typical species id is something like moleculeName_postTranslationalModification_compartmentAbbrev
or
moleculeName_bindingPartnerName_compartmentAbbrev.

Parenthetically, Nicolas' suggestion that we use the species name attribute to specify the indistinguishable entity is essentially equivalent to the proposal being debated. The trouble is that the name attribute is the name of the species, not the name of the indistinguishable entities. For this reason, using the name attribute is a hack just like using SpeciesType was a hack. Consequently, the proposal is to add a new attribute specifically designed to to the job some of us think is required.

When the optional species name attribute is used, a similar text string is usually used as its value. But again, there are no required semantics. And indeed, there should NOT BE any required semantics for the values assigned to tags. Software should not be in the business of parsing the attribute values.

A species id could be simply S12378. This would be valid SBML. It would generate solvable differential equations and we would then know the time course of S12378 in cytosol, say. But we would not know that S12378 is myosin light chain kinase phosphorylated on serines 834 and 851 in cytosol.

It seems to me that the frequency with which SBML modelers use the species id to attempt to specify the identity of the indistinguishable entities is telling us that everyone wants to know what the indistinguishable entities ARE. Shouldn't it be possible to write an algorithm that processes a core-based SBML file and displays a list of the molecules/entities that, according to the modeler, appear in this model?

Nicolas is correct that the proposed entity attribute is uncontrolled and cannot be cross-referenced to a public database. But neither are the values being assigned to species id which is currently how we are forced to encode the identity of the indistinguishable entities.

Adding a required entity attribute to species would allow software to determine what currently can only be determined by a clever and informed human reader. The proposed required species entity attribute is a simple, straightforward modification of the L3 core spec that solves this problem. SBML encodes models very well; we just want to know - models of WHAT. This is not a revolution. It is a tiny, but extremely useful change.

Whether MIRIAM annotations are sufficient is another important part of the debate. But this post is already too long.

Hello,

As far as I am concerned, I'm trying to resolve the issue by trying
to establish what should be part of the core. It is a pity how quickly
some assume those who disagree must be confused, ignorant or
frivolous.

I agree, compartment size comes with a unit, too, like any other
parameter (so it's not just a number, my bad). From a purely
mathematical view, the dimensions of a compartment are only important
if you want to have units set automatically. No doubt, a very
convenient feature, but not a necessary one. If I remember correctly,
not every one can use this feature, because some models are based on
amounts and others on concentrations, and some may be mixed. Also, as
some like to point out, a species does not need to be a chemical, it
can also be cells in a Petri dish, and then size and dimensionality
probably don't work the same way. So you could argue that compartments
don't need to be in the core, but providing them in a package is
sufficient.

What I would like to see is some objective standard what is
essential and should be in the core. And I don't think it is a
sufficient argument that we decided that long time ago and if you
don't know that you must be [censored].

It is not a good idea to base software on current user requirements
alone, because those change. We don't know what kind of models people
write in a year or two or three.

Maybe modellers will use molecular weights to do diffusion. Or
charge to do electro-chemistry. Or electronegativity for
redox-reactions. Or tendency to accept or donate a proton. Or
half-life of nuclear decay. Or parameters on free energy, or
absorption and emission.

Where can these values be attached to, if not to entities? There may
not be much use for entities now, but that can change any time, and it
is possible that in a few years, entities will be considered more
essential than compartments.

In any case, while user requirements change, physical reality does
not. Entities are a physical reality we can rely on to make sense even
many years later, when we roll out maybe SBML Level 12, which may
otherwise look nothing like SBML today.

Take care
Oliver

On Wed, Sep 9, 2009 at 1:54 AM, Michael Hucka<mhucka@caltech.edu> wrote:
> �curoli> If size was the only issue, you could have that
> �curoli> more easily and more flexibly by adding a size
> �curoli> attribute to the species. Compartments would be an
> �curoli> unjustified overkill. Eliminating them would avoid
> �curoli> uncontrolled labels, so according to your logic
> �curoli> should be a good thing.
> �curoli>
> �curoli> So I still don't see how compartments are more
> �curoli> essential than species types. If you want to be
> �curoli> consistent, you should either have both or
> �curoli> neither. I'm in favour of having both. I don't
> �curoli> understand how some one can be in favour of having
> �curoli> one of them.
>
> I'm sorry, but IMNO these statements about compartments are:
>
> (1) Just plain wrong. �Compartments are more than just size.
> � �They are *structural elements* of a model, they carry
> � �dimensions and units (not just size), and they have
> � �semantic meaning. �To call them "overkill" and
> � �nonessential, and propose instead that they can be
> � �simply replaced by a numerical attribute on a species or
> � �a regular parameter reveals serious misunderstandings
> � �about the needs of compartmental modeling.
>
> (2) Irrelevant to the original point that Robert Phair was
> � �discussing, which concerned species and species types.
>
> Let's go back to resolving Robert's issue.
>
> MH
>
> ____________________________________________________________
> 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
>



--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
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

Robert Phair wrote:

> But I still cannot see why we should be satisfied with a Core spec that
> lists all the pools of indistinguishable entities and tells us exactly
> where they are located but provides no required attribute that reveals
> what those indistinguishable entities ARE.

Because we do not agree on what we mean by ARE. This is clear to you
because you use SBML for a very specific purpose, and you can have a clear
biochemical definition of identity. But you cannot extend that to all
usages of SBML.

> The species id attribute can have any syntax permitted by the SId data
> type. There is no requirement that the id attribute conveys the identity
> of the indistinguishable entities, but nearly everyone tries to do so.

That is not true. Some people are. Some are not.

> Consequently, in current best practice the typical species id is
> something like
> moleculeName_postTranslationalModification_compartmentAbbrev or
> moleculeName_bindingPartnerName_compartmentAbbrev.

I am sorry, but which "best practise" are you talking about?

> Parenthetically, Nicolas' suggestion that we use the species name
> attribute to specify the indistinguishable entity is essentially
> equivalent to the proposal being debated. The trouble is that the name
> attribute is the name of the species, not the name of the
> indistinguishable entities. For this reason, using the name attribute is
> a hack just like using SpeciesType was a hack.

I agree. Name is a hack. SpeciesType was not, if the purpose was to
identify the type of members of a species. However, I believe the group is
a semantically much better solution. All the members of a species are
member of the group the species belongs to. Simple set theory.

> Consequently, the
> proposal is to add a new attribute specifically designed to to the job
> some of us think is required.

Nothing should be required in SBML that does not change the way we resolve
the mathematics. It may be useful, but not required. Furthermore, in many
cases, we just cannot tell what "are" the species. They are just convenient
variables for a model.

> A species id could be simply S12378. This would be valid SBML. It would
> generate solvable differential equations and we would then know the time
> course of S12378 in cytosol, say. But we would not know that S12378 is
> myosin light chain kinase phosphorylated on serines 834 and 851 in
> cytosol.

But that is the whole point. I do not believe anyone know how to say that.
And I am sorry, but if you write:

entity="myosin light chain kinase phosphorylated on serines 834 and 851"

That does not tell me anything. I do not know what organism, what isoform
you are using. What is the numbering scheme you are using (think about
protein with signal peptide etc.). This is just a random label.

> It seems to me that the frequency with which SBML modelers use the
> species id to attempt to specify the identity of the indistinguishable
> entities is telling us that everyone wants to know what the
> indistinguishable entities ARE.

No, it does not. First of all, this is not that frequent. Second, when it
is the case, it is most often not because of the modeler's wish, but
because this is the easiest way for the software to write a unique
identifier. We are talking about SBML, not the software generating SBML. I
do not want to forbid people to have such entity description in their
software. They can perfectly have a given molecular type ATP, present in
cytosol and in nucleus. Then when they write the SBML file, they generate
the ids. The reverse will be possible with groups.

> Nicolas is correct that the proposed entity attribute is uncontrolled
> and cannot be cross-referenced to a public database. But neither are the
> values being assigned to species id which is currently how we are forced
> to encode the identity of the indistinguishable entities.

So? If none have this advantage, what is the point?

> Adding a required entity attribute to species would allow software to
> determine what currently can only be determined by a clever and informed
> human reader.

No, it would not. It would just says that species X and species Y are made
up of instances that are all of type "abc_def_ghi". This "abc_def_ghi"
would still require a clever and informed human reader. And even this
person could not do it properly for the reasons exposed above.

> The proposed required species entity attribute is a
> simple, straightforward modification of the L3 core spec that solves
> this problem.

Which is already completely solved by groups, and way better (multiple
groups, types of other things etc.) So the real debate should be are groups
part of the core or not.

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

Hello Nicolas, All,

On Wed, Sep 9, 2009 at 8:14 AM, Nicolas Le nov�re<lenov@ebi.ac.uk> wrote:
> Robert Phair wrote:
>> But I still cannot see why we should be satisfied with a Core spec that
>> lists all the pools of indistinguishable entities and tells us exactly
>> where they are located but provides no required attribute that reveals
>> what those indistinguishable entities ARE.
>
> Because we do not agree on what we mean by ARE. This is clear to you
> because you use SBML for a very specific purpose, and you can have a clear
> biochemical definition of identity. But you cannot extend that to all
> usages of SBML.

We know enough: we know these entities are located somewhere,
indistinguishable, measurable and contributing to some species. So we
can always take those entities and relocate them, and if they
contribute then to another species, then and only then that other
species is of the same species type (or entity). This holds for any
usage of SBML, regardless of whether those entities are chemicals,
cells in a Petri dish or cars in a parking garage. And it always seems
to be a piece of essential information.

>> The species id attribute can have any syntax permitted by the SId data
>> type. There is no requirement that the id attribute conveys the identity
>> of the indistinguishable entities, but nearly everyone tries to do so.
>
> That is not true. Some people are. Some are not.

Would you not consider it bad practice if some one made no attempt
to convey it somehow? And what to do if MIRIAM annotations are not
sufficient? What would you consider best practice?

> I agree. Name is a hack. SpeciesType was not, if the purpose was to
> identify the type of members of a species. However, I believe the group is
> a semantically much better solution. All the members of a species are
> member of the group the species belongs to. Simple set theory.

Putting things in a set is easy. The hard part is giving meaning to
the group and specify why these things are in the same group. What
attributes of a group are possible, likely or required? How would we
know a group corresponds to an entity?

> Nothing should be required in SBML that does not change the way we resolve
> the mathematics. It may be useful, but not required. Furthermore, in many
> cases, we just cannot tell what "are" the species. They are just convenient
> �variables for a model.

I think it is perfectly legitimate to make something required if it
improves maintenance and limits no one.

> And I am sorry, but if you write:
>
> entity="myosin light chain kinase phosphorylated on serines 834 and 851"
>
> That does not tell me anything. I do not know what organism, what isoform
> you are using. What is the numbering scheme you are using (think about
> protein with signal peptide etc.). This is just a random label.

Maybe not machine-processable. But random? We do understand what
that means, and it tells us more than MIRIAM annotations can express
(except for the organism).

>> Adding a required entity attribute to species would allow software to
>> determine what currently can only be determined by a clever and informed
>> human reader.
>
> No, it would not. It would just says that species X and species Y are made
> up of instances that are all of type "abc_def_ghi". This �"abc_def_ghi"
> would still require a clever and informed human reader. And even this
> person could not do it properly for the reasons exposed above.

You showed that it is not a perfect way. But you have not shown a
better alternative.

> Which is already completely solved by groups, and way better (multiple
> groups, types of other things etc.) So the real debate should be are groups
> part of the core or not.

We don't even have a draft for groups yet. You are asking us to give
up an established feature without knowing how the alternative will
work or when it will come.

Take care
Oliver

--
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
http://www.oliver.curiousworld.org
____________________________________________________________
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

PM> My personal feeling is that the sematics of what is
PM> the chemical nature of a pool is sufficiently
PM> important and central to biochemical networks that it
PM> should be part of the core semantics of SBML itself

But, the purpose of species type (and indeed a group in the
current draft groups proposal) is merely to associate an
additional identifier with each species object. This
identifier (the identifier of the type) does not itself
carry semantics. The semantics can only be associated with
the type by virtue of connections that the type object might
have to other resources. Maybe you have this in mind, but
I'm not sure from the statement above.

MH

____________________________________________________________
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

Mike,

> But, the purpose of species type (and indeed a group in the
> current draft groups proposal) is merely to associate an
> additional identifier with each species object.

What Robert mentioned earlier is that what we call "species" should be
called "pool" because it is a specific subset of a chemical species in a
model. What we now call species type is actually what the chemical species
is. Our current practice is to add all unique chemical species as species
types and annotate these with the appropriate MIRIAM rdf that points to the
authoritative database entry for that chemical species. After this, we can
infer that some "species" is also of that composition (because it is tagged
with that species type).

> This identifier (the identifier of the type) does not itself
> carry semantics.

Indeed, but it can be added with <annotation> and at that point it allows us
to find out which "species" are of this chemical nature. (BTW this same
mechanism could be used to group cell types too, etc. as long as the
<annotation> is to the appropriate URN). Also, an SBO term can be added to
indicate that this is a "simple molecule" (another problematic label, but I
won't go there), or a protein, or a cell type (if/when we create the
appropriate SBO term for that), etc. etc.

> The semantics can only be associated with the type by virtue of connections
that the type object migh have to other resources.

The connections created by speciesType (or groups) are important as they carry
the semantic meaning that these entities all have something in common. The
something in common is what is pointed by the MIRIAM annotation on the
speciesType/group level.

I am not prescribing this use to everyone; but I am proposing that this is a
mechanism that allows us to unequivocally indentify things with their correct
semantics (through MIRIAM), and then indicate which other entities are
special cases of them. This may not be ideal or elegant, but it works right
now with SBML L2 and it will stop working with L3core.


--
Prof. Pedro Mendes
EPSRC Chair in Computational Systems Biology
University of Manchester

School of Computer Science
Manchester Centre for Integrative Systems Biology
131 Princess St., Manchester, M1 7DN, UK

http://www.comp-sys-bio.org
http://www.mcisb.org
____________________________________________________________
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

This is why I suggest adding a number to the group association. So
you could have a group CIt with species CI and CI2. CI would be
associated with group CIt with value 1 and CI2 would be associated
with group CIt with value 2.

Chris

Sent from my iPod

On Sep 9, 2009, at 1:13 PM, "Michael Hucka" <mhucka@caltech.edu> wrote:

> myers> I'm not sure though how strongly I would push to
> myers> have such a concept in the core. I would not argue
> myers> against it, since it is useful. If this idea is
> myers> absorbed into the groups package, then I would like
> myers> to see it modified to accept a number which can be
> myers> interpreted as the number molecules in a complex as
> myers> described above.
>
> Hi Chris,
>
> Although this is an attractive idea, there is a significant
> problem in coming up with a universal way of counting the
> entities (or summing the amounts of all the species). Your
> example didn't involve a simple sum of X = A + B + C ...,
> but multipliers (X = A + 2B ...), which means there must be
> a scheme for people to express exactly how they want things
> counted up. That in turn means arbitrary formulas. Where
> would such formulas go, and how would it differ from using
> parameters and assignment rules today? (I'm not being
> dismissive here, just trying to think the ideas through.)
>
> MH
>
> ____________________________________________________________
> 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

Hi All--

Hi--

Michael B's ideas recall a thought I had while Mike H was presenting the
Group package last week. If we were to allow group IDs in the reaction
definition (as reactants or products and in the kineticLaws), this could
address many of the problems in re-defining reactions in multiple
compartments (thus overlapping with Arrays), because we could re-use the
same kineticLaw for all reactions involving the group elements. It also
makes contact with the discussion on generics, though leaving open the
problem of providing an appropriate mapping from generic reactants to
generic products. In fact, it seems it might cause more problems than it
solves, from which we might take the lesson: keep the Groups very
simple, superficial, and vanilla, lest they come back and bite us in the
behind.

Best--
--Eric

________________________________

From: sbml-discuss-bounces@caltech.edu
[mailto:sbml-discuss-bounces@caltech.edu] On Behalf Of Blinov,Michael
Sent: Wednesday, September 09, 2009 8:34 PM
To: SBML Discussion List
Subject: RE: [sbml-discuss] Proposed addition to L3 core


Adding a number to the group association will duplicate multistate
multicomponent extension and still may require explanation. Totals of
entities can be easily computed through functions over members of
groups. If more information is required (like number of phosphogroups in
home- and hetero-dimers), the only proper solution would be to use
multi-state multi-component extension. I believe groups in the core are
necessary as supplement to functions and rules. I hope that people
requesting speciesTypes can be satisfied with groups. And, because
groups are not used in simulations, extra burden on software tools will
be minimal.

Michael
______________________________________
Michael Blinov
Assistant Professor
Center for Cell Analysis and Modeling
University of Connecticut Health Center
http://www.ccam.uchc.edu/mblinov/ <http://www.ccam.uchc.edu/mblinov/>

________________________________

From: sbml-discuss-bounces@caltech.edu on behalf of Chris J. Myers
Sent: Wed 9/9/2009 6:30 PM
To: SBML Discussion List
Cc: SBML Discussion List
Subject: Re: [sbml-discuss] Proposed addition to L3 core



This is why I suggest adding a number to the group association. So
you could have a group CIt with species CI and CI2. CI would be
associated with group CIt with value 1 and CI2 would be associated
with group CIt with value 2.

Chris

Sent from my iPod

On Sep 9, 2009, at 1:13 PM, "Michael Hucka" <mhucka@caltech.edu> wrote:

> myers> I'm not sure though how strongly I would push to
> myers> have such a concept in the core. I would not argue
> myers> against it, since it is useful. If this idea is
> myers> absorbed into the groups package, then I would like
> myers> to see it modified to accept a number which can be
> myers> interpreted as the number molecules in a complex as
> myers> described above.
>
> Hi Chris,
>
> Although this is an attractive idea, there is a significant
> problem in coming up with a universal way of counting the
> entities (or summing the amounts of all the species). Your
> example didn't involve a simple sum of X = A + B + C ...,
> but multipliers (X = A + 2B ...), which means there must be
> a scheme for people to express exactly how they want things
> counted up. That in turn means arbitrary formulas. Where
> would such formulas go, and how would it differ from using
> parameters and assignment rules today? (I'm not being
> dismissive here, just trying to think the ideas through.)
>
> MH
>
> ____________________________________________________________
> 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


Notice: This e-mail message, together with any attachments, contains
information of Merck & Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates (which may be known
outside the United States as Merck Frosst, Merck Sharp & Dohme or
MSD and in Japan, as Banyu - direct contact information for affiliates is
available at http://www.merck.com/contact/contacts.html) that may be
confidential, proprietary copyrighted and/or legally privileged. It is
intended solely for the use of the individual or entity named on this
message. If you are not the intended recipient, and have received this
message in error, please notify us immediately by reply e-mail and
then delete it from your system.
____________________________________________________________
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