Menu
▾
▴
#326 Clarify what is meant by UnitDefinition derived from a various units
closed
nobody
5
2017-12-06
2016-02-24
No
We have a number of validation rules that state things like:
The value of a Species object’s substanceUnits attribute should only be one of the following:
"substance”, “mole”, “item”, “gram”, “kilogram”, “dimensionless”, “avogadro” or the identifier of a UnitDefinition object derived from “mole” (with an exponent of “1”), “item” (with an
exponent of “1”), “gram” (with an exponent of “1”), “kilogram” (with an exponent of “1”),
“avogadro” (with an exponent of “1”) or “dimensionless”.
We need to clarify what a unitDefinition derived from these means ...
Currently libSBML assumes that the UnitDefinition must be derived directly from ONE of the units with possible scale/multiplier factors being added.
Now it could be that it was meant to imply that you could derive the unit from any combination of the specified units. So Andreas' unit of 'mole per gram(DW)' would be a perfectly valid unit for the substance of a Species since it is derived from mole and gram which are allowed.
We need to decide if the intended meaning of the rule (and text) is that a combination is allowed.
If so, this is a bug in libSBML that can be corrected immediately but I would suggest we need text in L3V2 or a new release of L3V1 to clarify this. We also need to revise the text of the rule because if you literally interpreting it 'mole per gram' is NOT allowed as in that case the exponent of gram would be -1 .
NOTE: This is not just an issue for substance units. We have similar rules for compartments of various spatialDimensions and the global model units.
Diff:
With the understanding that I do not have a vote, I would recommend against the more liberal interpretation of this statement. I believe that the warning message received from assigning a Species substanceUnit as 'milimoles per grams dry weight' is exactly performing its function: warning that units like these violate assumptions that SBML makes about the way you set up your model, and it indicates that there are pitfalls ahead if you persist in modeling your system in this way.
'milimoles per dry weight' is a concentration. It is not a substance. It is a measure of one thing as a subset of another, correlated but separate thing: the compartment. The proper way to create SBML models is to give Species units of substance, and not concentration. You can get away with it if your compartment size doesn't change, but it's a problem waiting to happen if you do so: once you hit a situation where the compartment size does change, your model no longer works.
Forcing people to turn off warnings or to turn off unit validation in this situation is, I feel, exactly the right thing to do. They can do their modeling in that mode, and by turning off unit validation, they are declaring that they know that they're violating one or more SBML assumptions, but are prepared to deal with the consequences. But the whole point of the warnings in the first place is to let people know, "Hey, you probably forgot something here, or are violating an assumption that SBML makes", and that's exactly what happened.
I don't know. People complain about SBML's strict rules and how it impedes their ability to model what they want, and here we are being strict again.
Strict and in this context wrong, as millimole per gram dry weight is not a concentration it is a yield. In chemistry concentration is defined as substance per space.
When dealing with growing cell cultures (the situation under discussion) cellular volume (or compartment size) is not equivalent to amount of biomass. Furthermore, it is perfectly normal for microbiologists to express amounts in terms of yields. Note yields need not be "per gram dry weight", they can also be expressed as "mmol per mole carbon" (c-mole), "mmol per mole glucose", ...
In my opinion redefining concepts such as concentration and volume to fit an encoding scheme is not the way to go. The only real question is: "Do we relax this restriction (at least on substance units) in core and make it available, as an errata, right now (my personal preference)? Or, do we introduce this through some other mechanism?
I assume libSBML and online validator could be updated, as easily, either way.
OK, so it's clear the situation is more complicated than I thought. I support any alternatives that the rest of you want. It sounds to me like Brett is right and the restrictions need to be relaxed, but based on the validation rule that Sarah posted, doing so will need validation rules to be reworded. Doing that implies a new version (which is fine, because we're already planning L3v2).
For L3v1, we can declare known errata items for each rule that needs changing, and listing the errata publicly in the usual place. Past procedure about errata has been that things like libSBML can implement the revised version.
The validation rule that Sarah posted is indeed more explicit and problematic than the other one I was looking at. I agree this needs to change.
With my apologies to Lucian, I may have been slightly reactionary in my previous email, especially the "not equivalent" being "not necessarily equivalent".
If I redefine the question as: "How do we express models in terms of yields and is this better achieved by redefinition of a compartment (Lucian's idea), substance (this one)" it turns out that the compartment route may, in the end, be more flexible for this purpose.
No apologies necessary--it's a weird situation, and definitely worth exploring different options. While I'm kind of enamored by my idea, and pleased that it seems to be workable, it may be too arcane/confusing for regular users of SBML, who would be better served by a simple relaxation of this rule. That would benefit people by allowing them to use whichever technique worked best for them, at the cost of pointing out fewer user errors. I don't have any good way of judging the relative value of those costs and benefits; maybe someone else does?
If we relax the rule about composite units, this should apply to both, substance and extent units. Otherwiese the problem cannot be solved.
This discussion has been moved to this Google Document, where we can better layout and discuss all arguments. Interested people, please feel free to request write access.
This is not specific to FBA. Drug amounts are very often expressed in mg per kg of body mass etc. This is an area where SBML should not intervene. SBML does not have to tell modellers what to do, but how to do it. I vote for relaxing.
I vote for relaxing, too.
The trend here seems to be towards relaxing the restriction. The question then becomes: how far do we relax things?
One option would be to say 'it is OK to express species amount units in terms of concentrations if all the units are amounts'. This will work if we're sure that the only 'valid' use of species amounts-that-are-concentrations are these sorts of 'bulk weights'. If new valid situations come up in the future, we can further relax the restrictions then (and they're only warnings in the first place).
A second option would be to say 'it is OK to express species amount units in terms of any combination of 'amount' units', which is slightly more permissive (it would allow 'mol/g^2', or 'mol * kg / mol^3', etc.)
A third option would be to drop the rule entirely, and let species amount units be anything. This would mirror the situation with compartments with no 'spatialDimensions' attribute, or with 'spatialDimensions' attributes other than 1, 2, or 3.
I am not sure what is meant with "species amount units in terms of concentrations if all the units are amounts".
From my perspective, it should be allowable to use combinations of units from the one class that can be assigned to elements, i.e., amount units to species (e.g., mmole/g) size units to compartments (e.g., l/cm^3) and so on.
This seems to be almost only a change in the libSBML validator.
What I meant by "species amount units in terms of concentrations" was 'any unit that can be expressed as 'amount per amount', with no exponents'. I believe all the examples that have come up so far are in this form.
I think it's kind of a stretch to say that the existing validation rules were meant from the get-go to mean 'as long as you're using amounts in any form, you're good to go'. The clear intent of the rule (if not, perhaps, the precise wording) is the same as libsbml has implemented validation. I would be OK relaxing this rule, but claiming, "Oh, that's what it's always meant" does not seem very accurate.
If you're wondering if we can get away with claiming that the new interpretation could apply to L3v1, and we only need some additional clarifying wording in L3v2, I could see that possibility (we did it with the MathML 'allowable subset', back in the day), but it's again clearly a reinterpretation, not the original intent.
I agree. If we are to relax/reinterpret this rule then I would tend to go the "species amount units in terms of concentration" route, especially, if this is to be hacked into L3V1.
The only thing I don't understand is how 'amount per amount', with no exponents' should be achieved. Does this stipulate that we should immitate amount per amount by using appropriate multipliers rather than exponents? I am not sure if this is always possible. Why should we ban exponents then? How would you, for instance, express millimole per gram without exponents?
@ Andreas: I think Lucian meant that we allow amount per amount (with the -1 exponent) but that we do not allow for things such as (amount)^3 per (amount)^2
Sorry for being unclear; this is indeed what I meant. mmol/g would be fine; mmol/g^2 would not.
I agree with relaxing the rule for L3V2.
If we go for a R2 of L3V1 then I think we could also relax it there - using the 'reinterpretation as a result of real life modelling needs' argument
Ok, I agree; let's put this in R2 of L3V1 and R1 of L3V2. We will see how long it will last until someone wants some unit over squared meters or similar... From my perspective, it is still the decision of the modeler if some concept makes sense. I wouln't vote against restricting exponents to ±1 (and 0) though, however, I think it isn't necessary.
Here is my summary of the opinion so far [EDITED to include Dagmar's opinion; below]:
This is everyone, so this will happen. Now we need to decide between the following two options on how to relax the rule:
We need all the other editors to pipe up here with opinions on what specific form of relaxation we go with here, and/or a request that we gather more information from somewhere (such as sbml-discuss) before making a final decision.
Last edit: Lucian Smith 2016-06-16
add me to: Relax the rule to any form of 'substance^n/substance^m'.
Done! Edited my summary post, above.
Sarah, did you edit this issue and somehow delete all the discussion about it? Or is this a new issue entirely? I'm searching and can't find the issue with our (long!) discussion about substance units.