Forums

Hello All,

I have been quiet on this thread which does not mean that I do not
care :) You all know my background is physics and therefore for me
all values have units and all units in formulas must be consistent to
make any sense.

However the current situation in SBML is that parameters have the
default unit "undefined" (not that this a unit ;). In addition any
numbers appearing in MathML also have the unit "undefined. The first
issue can be easily overcome by a modeler by specifying the correct
units for any parameter. This way one can also convert between grams and
mole if the model requires it within any mathematical formula by
introducing a conversion parameter.

The second is a far greater problem. Basically, any expression using a
number can not be verified to have correct units. To overcome this any
number used in an expression must be defined as a parameter with the
unit dimensionless and this parameter must be used instead.

The above means it is currently possible to define models in SBML,
which have consistent units and these can also be verified. But to
define such a model is extremely cumbersome and lets face is it nobody
is doing it.

This means if we want that units MUST match we need to make things
easier in SBML. The first thing would be to require that parameters
have the default units dimensionless and that numbers are also
dimensionless. In addition the unit "undefined" must be removed.

If we do all this, MUST match is clearly the right way to go. This would
mean that we can not use all models as they currently appear in
publication instead they need to be curated so that the units
match. This means introducing parameters with the value 1 and the
proper units wherever needed. This is what the authors did without
thinking about it anyway ;)

But of course this vote is not about getting rid of the unit
"undefined". It is about what can we do in the current situation. We
can use MUST match or we can use SHOULD match. SBML as it stands now is
clearly geared towards SHOULD as its unit system is as closed to broken
as it gets. Let me consider the two expressions where A and B have
inconsistent units

a) 1 = A/B
b) A = B.

The first one can not be verified to have correct units and a warning
is given. It is not flagged as an error and therefore the SBML
is valid. The second is easily verified to have incorrect units and
therefore if we go with MUST is invalid SBML. On the other hand if we go
with SHOULD a warning will be given and the result is again valid SBML.

Since both expressions say the same the result should be the same,
i.e., in the current context a SHOULD match leads to a more consistent
interpretation of the mathematical expressions in SBML.

I know this was long but I hope you are still reading :)

Thanks,
Stefan


On Sun, 16 Dec 2007 14:36:24 -0800
Frank Bergmann <fbergman@u.washington.edu> wrote:

> >
>
> Hello Sven and all
>
> > I really do not see the need to be able to specify inconsistent
> > units. Having a model with inconsistent units would say: "I have a
> > model which gives the right results numerically. However, I do not
> > want to get the units right, please don´t rely on them." For this
> > case, I think, one could use unspecified or dimensionless units,
> > without the need to relax the requirements of the sbml
> > specification.
> >
>
> prefering strict units my self, and agreeing wholeheartedly with
> what you said above, there is another side to this. No one would come
> along with a mindset of "I do not want to get the units right,
> please don´t rely on them.". Rather the issue is one of model
> exchangeability between software tools. Until now we could pretty
> much exchange SBML models freely between tools, even though the units
> might have been inconsistent. With libSBML giving us the ability to
> flag these inconsistencies as warnings, that was fine as well. Now
> however, if every inconsistency is treated as Error (as the spec
> prescribes), the problem will be that we loose a whole lot of
> exchangeability, between 'strict' tools and more forgiving ones.
>
> Modelers that have been using tools for years, with kinetic formulas
> that were "modellingly correct" albeit inconsistent unit-wise, would
> be hard pressed to understand, why they couldn't exchange their
> models like they did before.
>
> Going forward, and working on model-modularity ourselves, I think
> the right step to take is to make it known to the community at large
> that starting from a specific SBML level/version, units will be
> interpreted by the tools as 'strict', and will be rejected otherwise.
> This would allow tools to gracefully treat SBML files of prior
> versions as 'conceptual' models in case of unit-inconsistencies, but
> i guess that would be a 'tool issue' :).
>
> best
> Frank
> ____________________________________________________________
> 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.


--
Stefan Hoops, Ph.D.
Senior Project Associate
Virginia Bioinformatics Institute - 0477
Virginia Tech
Bioinformatics Facility I
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.