In a discussion about the FBA package, Brett Olivier commented, "Personally it is not clear to me how the conclusion on lines 2-3 on Page 58 of the SBML L3V1 specification was reached and how it could be implemented ;-)"
The line in question states:
"Constraints may be used as input to non-dynamical analysis, for instance by expressing flux constraints for flux balance analysis."
And indeed, it seems as if Constraints are the wrong tool for that job (and is why the FBC package defines its own 'FluxBounds' which are otherwise similar to Constraints).
In light of that, should we simply remove that line from the specification?
I agree with the proposed change and that it should be done.
I agree with the proposed change and that it should be done.
I am accepting this issue as valid.
I agree with the proposed change and that it should be done.
Just out of curiosity, did anyone come accross a software using the constraint element?
I agree with the proposed change and that it should be done.
I can tell you that JSim uses constraints, but that those constraints are not quite used in the same way as in SBML. In JSim, they are used to choose between multiple solutions to algebraic rules:
0 = x^2 - 4;
x > 0
has the single solution, 'x=2'.
The translation algorithm uses Constraints to store this information--though of course it is a slight abuse of the construct, there is nowhere else to keep that information.
iBioSIm uses constraints all the time. We use them as a way to specify a property of interest. Then, we can do things like run 100 stochastic runs and see what percent of the runs are terminated by the constraint being violated.
Diff:
Fixed in SVN for L3v2, and will be part of the forthcoming release of that specification.