Forums

On 12/07/12 19:40, Chris J. Myers wrote:
> My preference would likely be (2), in the distrib package. I don't
> think the argument against it is significant over (3) as if you make a
> new package than you would need to understand that one.

No we would not. We really do not need any distribution in that case. What
we are covering is the case where the results are reported as:

x +- y

or

[a, b]

a is the lower value and b is the upper value. Sometimes this means
mean-stdev and mean+stdev. Sometimes those are the lower and upper measured
values. That does not mean it represent a truncated distribution.

Yes, in the physical world behind, there is a distribution, and those
measurements are sampled from this distribution. But including
distributions in the SBML when talking about mean, stdev etc. is a bit of
an overkill. We do not need it.

> I think a
> nice way to do this would be to introduce an "unknown" distribution
> with four parameters in the same way we discussed introducing other
> distributions. This could then take four parameters, those you list.

I do not understand fully how it would work, within the context of the
current distrib package. But I will try out. This is an enormous overkill
though. We will have to write down an initialAssignment that points to a
distribution, find a way to define a distribution with the four parameters,
handle the return values etc.

We already discussed that in HARMONY, and the feeling at the time was that
the "first moment", "second moment" approach was not necessary.

When I mentioned solution 2), I was referring to attributes
distrib:mean
distrib:stdev
distrib:lower
distrib:upper

as discussed in May

>
> Chris
>
> On Jul 12, 2012, at 9:32 AM, Nicolas Le Novère wrote:
>
>> Hello,
>>
>> The wish has been expressed for a long time to be able to encode
>> uncertain
>> values in SBML models. One particular need is for population models,
>> and
>> this will be cater for by the "distrib" package. This package will
>> allow to
>> define and sample from "distributions" of values, either using
>> mathematical
>> functions, or list of numbers. There is another situation, where we
>> just
>> want to store uncertain values. For instance because this is how it
>> was
>> reported in the literature and we use SBML as a mean to store
>> knowledge
>> about biochemical pathways. Or because we want to use the SBML file
>> as an
>> intermediate in a workflow, the final values being determine at a
>> later
>> stage.
>>
>> We need to be able to encode at lease 4 information:
>>
>> * the arithmetic mean
>> * the standard deviation
>> * a lower value
>> * an upper value
>>
>> This information of course is mostly a form of annotation. If you do
>> not
>> know the distribution of the value, you cannot do much in terms of
>> mathematical interpretation of the model. And if the distribution is
>> available, then the distrib package should be used. So the role of the
>> corresponding structures would be rather like the "reversible"
>> attribute on
>> the reaction element.
>>
>> After playing with the idea of using regular distributions in the
>> distrib
>> package, with things like "first moment" for the mean and "second
>> moment"
>> for the stddev, it seems - after discussions at HARMONY2012 - that the
>> easiest way would rather to just add three optional attributes to any
>> element carrying a value (the value being identical to the mean if the
>> attribute stdev is defined).
>>
>> The big question is the package to which those attribute should
>> belong to:
>> 1) core (remember those are optional attributes)?
>> 2) distrib?
>> 3) another package? (at some point it was suggested to develop a stat
>> package, for instance to extend the MathML).
>>
>> All solutions have their appeal, and all solutions have their
>> drawbacks.
>>
>> 1) is harder to implement due to the stiffness of the core, and the
>> perception that the burden will be high on all shoulders.
>> 2) will tie the attributes to distrib, and therefore they will only be
>> accessible to tools understanding distrib.
>> 3) will force the creation of a new package, with all the management
>> hassle, but would make easier future independent evolutions (i.e.
>> adding
>> median).
>>
>> Opinions? Ideas?
>>
>> --
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> lenov@ebi.ac.uk, Skype:n.lenovere, twitter:@lenovere
>> 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
>


--
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
lenov@ebi.ac.uk, Skype:n.lenovere, twitter:@lenovere
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