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' :).
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,