|
Yes, units really are tricky! I don't have a strong view on what
to do about them (yet!), but I always think its helps clarify
things to think about my favourite rate law:
X(X-1)/2
Here it is assumed that X has units of "item". Then the "1" also
has units of "item", but the "2" is dimensionless. This
difference really matters if you decide to convert units to
(say) moles, as then the "1" needs converting (to become the
reciprocal of avogadros constant), but the 2 remains unchanged.
It would obviously be highly desirable for any unit
checking/conversion capability in SBML/libSBML to be able to
cope with such issues... However, it would be a bit messy to
have to define a "one" and a "two" externally with appropriate
units just to be able to construct this rate law...
Regards,
Darren
--- Michael Hucka <mhucka@caltech.edu> wrote:
> The SBML editors had an off-line discussion which we
> realized needs to be put on sbml-discuss. It concerns an
> issue that Sarah Keating ran into while implementing unit
> validation in libSBML.
>
> The issue is how the units of pure numbers in MathML should
> be treated. Here's an example, in the case of the 'delay'
> field on Events:
>
> <delay>
> <math xmlns="http://www.w3.org/1998/Math/MathML">
> <cn> 1 </cn>
> </math>
> </delay>
>
> Note the literal "1". What units, if any, should be
> assumed for the number?
>
> One option is to treat literal numbers as always being
> without units. This is a valid viewpoint, but it leads to
> more model validation failures. Although modelers should
> define parameters (which can have defined units) for a lot
> of the cases where they often write numbers directly, the
> practical reality is that many people won't think of doing
> that.
>
> A second option is to take the units to be whatever units
> are defined as the default for the field in question, or if
> there is an associated field definining the units, then
> whatever that field says the units are. (For instance,
> there is a 'timeUnits' field on Events that could apply in
> this example.) The logic behind this idea is that even
> though the user didn't specify the units explicitly, a
> reasonable interpretation of their intention is that the
> units are meant to be whatever the defaults are. In other
> words, the modeler didn't mean "1" without units, they meant
> "1 in the units of time" for this example.
>
> Sounds reasonable? But it gets more complicated. Imagine
> now something like
>
> <math xmlns="http://www.w3.org/1998/Math/MathML">
> <apply>
> <plus/>
> <ci> S </ci>
> <cn> 2 </cn>
> </apply>
> </math>
>
> For the purpose of this second example, the "S" can be
> anything (e.g., a species identifier) and the context can be
> anything, not just the Events example above.
>
> The question is, what should be assumed for the units of "2"?
>
> If we follow the same guideline, i.e., that the literal
> number has whatever units are appropriate for the situation,
> then it creates validation problems. First, it implies a
> unit validator must deduce the expected units somehow, and
> this may sometimes be impossible due to ambiguities in a
> given situation. Second, Stefan Hoops pointed out it opens
> a hole in validation: it effectively means that numbers in
> MathML are assumed to always have the appropriate units, so
> unit checking becomes worthless.
>
> To cope with this, we are tentatively thinking of using the
> following set of guidelines:
>
> 1) If the number is the only thing contained inside a <math>
> (such as the original example involving a delay on
> Events), assume that the units of the number are the
> units defined for that field (so, timeUnits for delays).
>
> 2) In all other cases, assume pure numbers have no units.
>
> This handles the first case, and also addresses the second
> case. (In the second case, there would be a unit validation
> failure because the "2" would not have units and therefore
> the overall expression could not have consistent units.)
>
> The downside is that this "rule" is defined with an
> exception.
>
> What do the rest of you SBMLers think?
>
> Whatever is decided, the next SBML specification will have
> to spell out the guidelines precisely.
>
> 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.
>
--
Darren Wilkinson
email: darrenjwilkinson@btinternet.com
home www: http://www.darrenjwilkinson.btinternet.co.uk/
work www: http://www.staff.ncl.ac.uk/d.j.wilkinson/
____________________________________________________________
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.
|