Hello Nicolas, All,
On Wed, Sep 9, 2009 at 8:14 AM, Nicolas Le novère<email@example.com> 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
> 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.
Oliver Ruebenacker, Computational Cell Biologist
BioPAX Integration at Virtual Cell (http://vcell.org/biopax)
Center for Cell Analysis and Modeling
To manage your sbml-discuss list subscription, visit
For a web interface to the sbml-discuss mailing list, visit
For questions or feedback about the sbml-discuss list,