Forums

On Mon, 2011-03-21 at 10:43 +0000, kieran wrote:
> This looks great. I'd like to release the yeast network
> (http://yeast.sf.net/) using the L3 extension rather than Cobra
> dialect right away, but don't want to lose my user base. To that end I
> have a few questions:

Thanks, your comments are much appreciated.

> * You mention there is a command-line converter Cobra to Flux
> Constraints. Is this publicly available, and does it work in the other
> direction (Flux Constraints to Cobra)?

It needs to be updated for the new proposal and currently only does
COBRA --> SBML3FBA. I think Frank is working on something that should
make it easier to do this.

> * Are you / the Cobra folks planning to write a parser for direct import
> of your models to Cobra?

Currently we don't have plans to write a parser for COBRA but this is an
excellent idea.

> * If there is no bound defined for a flux, it is unbounded -Inf < J <
> Inf. If J is marked reversible="false", should we assume 0 <= J? (I
> think this is the assumption made in Cobra right now)

Yes, if the bounds are undefined then that is what I assume as well.

> * You mention that (e.g.) a ChEBI annotation could conflict with
> fba:chemicalEquation. The same annotation could conflict with fba:charge.

In principle yes. There also a possibility that these can be dealt with
in the Annotation proposal. Currently, the L2 attribute charge is used
in this way so we took the pragmatic route. Can chEBI represent these
two properties at different pH's for all the compounds in genome scale
models ... ?

> * I'm interpreting "obj3" as "maximise 1.J2 + 1.J3" - is that correct?
> So should the other two objectives be interpreted as the same ("maximise
> 1.J2" and "minimise -1.J2"), or does the presence of a "minimise" mean
> its coefficients should be negated?

Yes this is correct undefined coefficients are assumed to be +1 and the
maximise/minimise attribute is independent of the coefficient signs so
any combination is possible. I'll update the example to make this
clearer.

> * I'm a bit worried about the introduction of strict inequalities
> ("less" and "greater"). Such problems won't generally have a solution
> (e.g. minimise x, subject to x > 0), and I think they should be steered
> clear of.

Interesting point. My initial feeling is that I'd like to keep things as
general as possible. This could, however, be coupled with a best
practice statement: " ... don't use strict inequalities unless you know
what you are doing ..." etc

Cheers
Brett

> Cheers,
> Kieran
>
>
> On 18/03/2011 14:59, Brett G. Olivier wrote:
> > Dear SBML Community
> >
> > We are pleased to announce that version 2 of the SBML L3 extension
> > for describing Constraint Based models has been reformulated and is
> > now available as a package proposal on sbml.org:
> >
> > http://sbml.org/Community/Wiki/SBML_Level_3_Proposals/Flux_Constraints
> >
> >In a nutshell: "The Flux Constraints package is a proposed SBML
> > Level 3 extension that allows the definition of constraint based
> > (a.k.a steady state, flux balance analysis or FBA) models".
> >
> > We are now interested in hearing your thoughts and comments.
> >
> > Best regards Brett Olivier& Frank Bergmann
>

--
Dr Brett G. Olivier
Researcher in Computational Systems Biology

Dept. Molecular Cell Physiology
VU University Amsterdam
Email: brett.olivier[AT]falw[dot]vu[dot]nl
Tel: +31 (0)20 592 4265

____________________________________________________________
To manage your sbml-discuss list subscription, visit
https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss

For a web interface to the sbml-discuss mailing list, visit
http://sbml.org/Forums/

For questions or feedback about the sbml-discuss list,
contact sbml-team@caltech.edu