The topic of this vote was:
Should consistency of units be required?
Thank you all for your participation in the SBML electronic
vote on this issue. The voting on this topic is closed.
For reference, the call for votes can be found at this URL:
This survey brought 20 unique votes. The results were
distributed as follows:
Case of "must": prefer requiring unit consistency: 4
Case of "should": prefer recommending consistency: 15
No opinion: 1
Total votes: 20
A large number of people included comments with their survey
responses. The following are the comments, in no particular
order, and with author names withheld for anonymity:
Comment How the person voted
"The authors should be responsible "should"
for their models and SBML should
"For any XML document there is "should"
'well-formed' (xml syntax) and
'valid' (schema syntax). SBML also
has 'validation rules' (document
semantics via libSBML) and 'MIRIAM'
(overall quality standards for the
encoded model via curators). For
purely practical reasons, unit
consistency is a model
"This was the most interesting "should"
discussion of recent times!"
"Unit checking should be a service "should"
offered to modellers and reviewers
by SBML-associated software
(e.g. libSBML). It is the
responsibility of the modeller to
get their models right. Placing the
responsibility somewhere else is
asking for trouble."
"After the recent Phair thread, "should"
I'll be surprised at any 'MUST'
"Consistent units CAN NOT be used "should"
for a model where biomass is on one
side of the equation. (35 uMole
Amino acid + 50 uMole glucose + 10
uMole NH4OH = 1 g biomass)."
"Choosing the "SHOULD" option still "should"
allows the toolmakers to check for
unit consistency. If a particular
application requires consistent
units, the tool in question can
check for it and return an error if
there is inconsistency. If the
'MUST' option is selected, there is
a risk that some tools will support
unit checking (and therefore 'real'
SBML), while others will not.
Furthermore, if the 'MUST' option
is selected, I suspect it would
encourage some modelers to just
remove units from their models all
together in order to more rapidly
satisfy the requirement. Without
the consistency requirement, the
units might still be useful for
output display, etc. Finally, I'm
not aware of whether the
specification covers this, but how
does SBML treat quantities such as
the logarithm of a unit? For
example, if I have a species 'A',
and a parameter 'logA', which is
defined as 'logA' = log(A) (by
assignment), will it be possible to
satisfy the unit consistency
constraint? Or would one have to
define the rule as 'logA' =
"I could go either way on this "no opinion"
vote. Perhaps a gray scale metric
of model validity would be better,
e.g. call the Ferreira model valid
but label it with a warning about
"Since we have units they must be "must"
correct otherwise it is an
error. As you pointed out,
incorrect units can always be made
correct if you multiply by 1."
"In my opinion ... even models, "should"
that don't have units defined can
exhibit rather interesting
behavior. By restricting ourself
to allow only for models with
consistently defined I think we
might loose a substantial part of
the SBML user base. That is not to
say, that if units are defined, and
they clash, this should be flagged
as an error. This means however
also, that there should be no
default units on
compartments/species ... The model
you mention above seems to define
exactly one unit to be used in the
model (i.e. hour). Oh ... and let
us not forget all the models that
are .. "modellingly correct", as it
were ... I think we have to keep
them around, so as not to alienate
"I think it's stupid that A = B "should"
would be considered true even if
the units weren't compatible, but
if we can't represent some
published models as a result, then
we don't seem to have much choice."
Thank you again for taking the time to respond to the survey
and for the very interesting discussions that took place on
Mike (on behalf of the SBML Editors)
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,