Forums

Hello Nicolas, All,

On Tue, Sep 8, 2009 at 3:15 AM, Nicolas Le Novere<lenov@ebi.ac.uk> 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. Eliminating them would avoid uncontrolled
labels, so according to your logic should be a good thing.

So I still don't see how compartments are more essential than
species types. If you want to be consistent, you should either have
both or neither. I'm in favour of having both. I don't understand how
some one can be in favour of having one of them.

>>   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, so we need to be
clear what that means. Especially, we need to understand that when
annotations end with "version of", that's not because annotators were
lazy, but because that's all you can do. You may dispute that that
affects "most", but how about "practically all models concerning cell
signalling"? Would you agree to that?

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. In this regard, entities
are just like compartments.

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

Even if you fix annotations, that does not solve the problem that a
species is not an entity.

It may be tempting to think that if annotations take care of
semantics, we can remove semantics from SBML. That's a fallacy,
because you can only add semantics where there already is semantics.
If you add a ChEBI or UniProt id to a species, we only know what that
means because we all understand that a species is not an entity, but
an entity pool at a location. If it was an entity, we would have to
conclude that a species in model A may be equivalent to a species in
model B, if they have the same ChEBI or UniProt id. But since we know
it is not an entity, but an entity pool at a location, we know that
the compartment also needs to be the same.

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

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.

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