In the description of the 'stoichiometry' attribute, the spec reads:
"The stoichiometry attribute is of type double and should contain values greater than zero (0)"
However, while there is a validation error for the first bit (21114), there is no validation warning (that I could find) that covers the second bit ('it should be greater than zero'). We should add one!
EDIT: The consensus was to not add a validation rule, and instead to remove the "should contain values of greater than zero" line.
I agree with the proposed change and that it should be done.
I am accepting this issue as valid.
I agree that this is a valid issue. However, I'm not sure this can be checked statically in all cases. What if the stoichiometry is not constant?
If the stoichiometry is non-constant, then yes, it can be changed in a variety of ways. But happily, the spec doesn't address that situation, and merely indicates that the attribute itself should only be positive.
But perhaps we should say something about variable stoichiometries as well? My thought was that if you want a variable stoichiometry, maybe you're one of those people who might also want a negative stoichiometry. But I have no experience with that either way, and would personally be content with a warning against non-positive values for the attribute itself.
We have a similar problem with delay in events. Namely, it is required to be non-negative, but this can only be validated at run time when the delay is not a constant. So, if we want to require a positive stoichiometry even in the dynamic case, I think this would be ok. I do not know though why someone even wants dynamically changing stoichiometries, so I suppose it is possible they may want negative ones. We need input on this, I guess.
I am "one of those people". I think this kind of rules are overspecifications. They correspond to opinions, and are at best guidelines. We have reversible reactions and a kineticLaw can become negative, which is effectively equivalent (reactants and products are produced and consummed). The definition of stoichiometric coefficients or numbers is positive if creation, negative if consumption. And chemical kinetics is largely based on the use of stoichiometric matrices that have positive and negative elements. The mistake was probably to create "reactant" and "product" in the first place (I realise now that this should be added to my issue 8 for the future of SBML). And of course there is the issue of varying stoichiometries (I think SBML users never used them because software do not support them. But as the models become more realistic, one will need to bend chemical kinetics more and more to make it fit with the cellular context, that is everything but an aqueous solution infinitely diluted and homogenously stirred).
As a fix I would be in favour of not adding a validation rule. And in a future version to remove the mention to positive stoichiometries.
I agree there is a discrepancy in the validation rules regarding stoichiometries.
I'm not an expert in biochemical models, but I feel an affinity to Nicolas' argument about removing restrictions in SBML that are rooted in specific viewpoints about valid models. So, I favor not adding a validation rule, and in L3v2, removing the mention of positive stoichiometry values.
I would also vote to not impose the restriction and remove mention of positive stoichiometry.
Although I'm still not sure what negative (or variable) stoichiometry mean, but I'm ok to leave out the validation rule. I assume we are still ok requiring event delays to be non-negative. Just read an article today that said time travel to the past is impossible :-).
I'm accepting this issue as valid.
As compared to the other editors, I'm less then happy with negative or zero stoichiometries. That sort of thing perhaps has its place when assigning to species reference ids, but not to the constants specified. If i wanted to specify a negative stoichiometry on a reactant, then i would write it as product in the first place. If I wanted to encode a zero stoichiometry for a reactant, i would leave it out of the reaction in the first place.
I would propose to move this validation warning (as it reads should) to the best practice section.
Point of order: assigning to lucian, when he is not an editor, is questionable :)
Making it a warning seems reasonable.
Good point about the assignment to Lucian. I will change it.
+1
On 14/09/13 15:51, Sarah Keating wrote:
--
Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT
Tel: +441223496433 Mob:+447833147074 n.lenovere@gmail.com
orcid.org//0000-0002-6309-7327 http://lenoverelab.org/perso/lenov/
Skype:n.lenovere twitter:@lenovere http://nlenov.wordpress.com/
Related
SBML Specifications:
#230Changing this back to 'open', since no consensus yet. The options are:
1) Remove the wording from the main text
2) Leave the wording in the main text, add a validation warning.
3) No change.
In addition, we could discuss this in a new 'best practices' section, regardless of which option you choose, above.
I think I still lean towards requiring > 0 with a validation warning, but it is not a strong feeling.
At the SBML Editors' meeting in Paris during COMBINE 2013, the decision was not to impose the restriction, and simply making it best-practice issue. I am moving forward with closing this and calling it accepted.
Diff:
Adding L2v4 to this, which has the same issue.
Fixed in SVN for both L2v5 and L3v2, and will be part of the forthcoming release of those specifications.