Forums

Dear Brett and Frank,

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:

* 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)?

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

* 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)

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

* 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?

* 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.

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

--
kieran smallbone
kieran.smallbone@manchester.ac.uk
http://u003f.com/

manchester centre for integrative systems biology
manchester interdisciplinary biocentre
131 princess street
manchester m1 7dn. uk
____________________________________________________________
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

On 21/03/11 16:27, Francois Le Fevre wrote:

> * sbo:term
> o I would like to see the introduction of sboterm specific to
> fba like fba:biomass, in order to tag the flux that is
> relevant to biomass

SBO is a user-driven effort. By all means, submit all your suggestions for
SBO terms to the tracker:
https://sourceforge.net/tracker/?group_id=174625&atid=871591

> * gene association
> o Personally, I think that gene association is protein
> association: we are speaking on who is acting as a enzyme to
> catalyse the reaction? The term gene association comes from
> Palsson group, but I would rather use protein association.

Yes indeed. That is something I have been trying to advocate to them ever
since I talked to Adam Feist in Boston ICSB in 2005. I understand the
rational behind the shortcut: Those models are often validated or used in
conjunction with mutants. And the most FBA models are still done in
organisms without alternative splicing, editing etc. But when it comes to
encode knowledge, we should not use shortcuts. The package description
says: "While the genes themselves can be defined as an SBML species". Yes,
if one really wants to represent the gene, not the protein coded by it. The
gene can always be related to the protein using a controlled annotation and
the bqbio:encodedBy qualifier.

But when it comes to SBML element naming, I would avoid biological concepts
at all cost! We already suffer so much from the terms "reaction" "reactant"
and "product", we should not do it again. No "gene association", and no
"protein association", please. An "association" and the nature of the
things we are talking about emerges from their controlled annotation.

> o Moreover (but it is independent from the first point) Why we
> do not use the mechanism of protein complex formation: we
> encode a reaction that form a protein complex from
> polypeptide; then the protein is involved as a catalyst in
> the reaction.
>
> Thanks for the comment.
>> 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
>>
>>
>
>


--
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

____________________________________________________________
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

Hello All,

1.

_*listOfModifiers*_

* for me, if you add multiple modifiers, then they are isozymes,
* if you want to define a AND relationship, then you have to
define before a species of type complex/species
* so here at CEA/Genoscope, we do exactly the same as in
Manchester :-)_*
*_
2.

_*sbo:term*_

* I agree that
o an objectif function is not always a production of biomass
o an objectif function may consist if numerous reactions
with different coefficients
* But
o when doing some FBA or other analyses it is
_*mandatory*_ to know the default objective functionS
that represent the biomass flux
o you can have several objective functionS that
represent the biomass flux, for instance, for the wild
type strain, for a specific growth condition
o but you need to be able when loading the model in fba
platforms ( such as cycsim
http://www.genoscope.cns.fr/cycsim/ ) to tag the
vector fluxes that represent the biomass flux, to run
analysis like "is my bacteria able to growth under
this medium condition"
* That's why I wanted to introduce it.
* But I do not have very big claim to justify this introduction.
* It is a knwoledge to know/modelize the biomass, that is why
we need perhaps a way to keep this knowledge inside the sbml ?

Bye

Francois

> Hi all,
>
> Just my two pence worth.
>
> * sbo:term
> o I would like to see the introduction of sboterm specific to
> fba like fba:biomass, in order to tag the flux that is
> relevant to biomass
>
> I don't like this suggestion for a couple of reasons. The first is that using the term "biomass" assumes that the objective function will always be production of biomass. This is not always the case. The second is that, in principle at least, we can only apply one SBO term to a reaction (or whatever), thus preventing us from tagging a reaction as both SBO:BIOCHEMICAL_REACTION and SBO:BIOMASS. The third is that the objective function may consist of numerous reactions, with different coefficients. To take Frank and Brett's example...
>
> <objective id="obj3" type="maximize">
> <listOfFluxes>
> <fluxObjective reaction="J2" coefficient="1" />
> <fluxObjective reaction="J3" coefficient="1" />
> </listOfFluxes>
> </objective>
>
> ...therefore tagging a reaction with an SBO term is insufficient as we'd still have to specify the coefficient.
>
> In summary, I really like Frank and Brett's method of specifying objective functions (and flux bounds).
>
> However, I'm less keen on the GENE_ASSOCIATION suggestion. (Sorry, Brett). SBML already has a means of specifying these relationships, in terms of modifiers:
>
> <reaction>
> <listOfReactants>
> ...A
> </listOfReactants>
> <listOfProducts>
> ...B
> </listOfProducts>
> <listOfModifiers>
> <modifierSpeciesReference species="E"/>
> </listOfModifiers>
>
> ...and as Nicolas has said, gene ids can be associated with the species E in the usual way.
>
> What I like about this approach is that it is consistent with kinetic modelling, so even if we don't specify a kineticLaw in constraint based models (which would use E), specifying enzymes (genes) in such a way would facilitate mapping between constraint-based models and kinetic models. And the line between these models are becoming increasingly blurred.
>
> I think Brett is correctly concerned about specifying multiple reactions for isoenzymes, in which the reactants and products are the same:
>
> <reaction id="X">
> <listOfReactants>
> ...A
> </listOfReactants>
> <listOfProducts>
> ...B
> </listOfProducts>
> <listOfModifiers>
> <modifierSpeciesReference species="E1"/>
> </listOfModifiers>
>
> <reaction id="Y">
> <listOfReactants>
> ...A
> </listOfReactants>
> <listOfProducts>
> ...B
> </listOfProducts>
> <listOfModifiers>
> <modifierSpeciesReference species="E2"/>
> </listOfModifiers>
>
> We in Manchester specify a single reaction but add both enzymes as modifiers...
>
> <reaction id="Z">
> <listOfReactants>
> ...A
> </listOfReactants>
> <listOfProducts>
> ...B
> </listOfProducts>
> <listOfModifiers>
> <modifierSpeciesReference species="E1"/>
> <modifierSpeciesReference species="E2"/>
> </listOfModifiers>
>
> ...but this causes its own problems. Is this an OR or an AND? Are these alternatives or do E1 and E2 form a complex?
>
> We think this is an OR. Whether users of our models do is another matter - its entirely implicit.
>
> Any suggestions?
>
> Neil.
>
> Neil Swainston
> Experimental Officer
>
> Manchester Centre for Integrative Systems Biology
> Manchester Interdisciplinary Biocentre
> University of Manchester
> Manchester M1 7DN
> United Kingdom
>
> On 21 Mar 2011, at 18:06, Nicolas Le Novère wrote:
>
>
>> On 21/03/11 16:27, Francois Le Fevre wrote:
>>
>>
>>> * sbo:term
>>> o I would like to see the introduction of sboterm specific to
>>> fba like fba:biomass, in order to tag the flux that is
>>> relevant to biomass
>>>
>> SBO is a user-driven effort. By all means, submit all your suggestions for
>> SBO terms to the tracker:
>> https://sourceforge.net/tracker/?group_id=174625&atid=871591
>>
>>
>>> * gene association
>>> o Personally, I think that gene association is protein
>>> association: we are speaking on who is acting as a enzyme to
>>> catalyse the reaction? The term gene association comes from
>>> Palsson group, but I would rather use protein association.
>>>
>> Yes indeed. That is something I have been trying to advocate to them ever
>> since I talked to Adam Feist in Boston ICSB in 2005. I understand the
>> rational behind the shortcut: Those models are often validated or used in
>> conjunction with mutants. And the most FBA models are still done in
>> organisms without alternative splicing, editing etc. But when it comes to
>> encode knowledge, we should not use shortcuts. The package description
>> says: "While the genes themselves can be defined as an SBML species". Yes,
>> if one really wants to represent the gene, not the protein coded by it. The
>> gene can always be related to the protein using a controlled annotation and
>> the bqbio:encodedBy qualifier.
>>
>> But when it comes to SBML element naming, I would avoid biological concepts
>> at all cost! We already suffer so much from the terms "reaction" "reactant"
>> and "product", we should not do it again. No "gene association", and no
>> "protein association", please. An "association" and the nature of the
>> things we are talking about emerges from their controlled annotation.
>>
>>
>>> o Moreover (but it is independent from the first point) Why we
>>> do not use the mechanism of protein complex formation: we
>>> encode a reaction that form a protein complex from
>>> polypeptide; then the protein is involved as a catalyst in
>>> the reaction.
>>>
>>> Thanks for the comment.
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>>
>>
>> --
>> Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
>> Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
>> Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
>> http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/
>>
>> ____________________________________________________________
>> 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
>>
> ____________________________________________________________
> 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
>


--
--
*Francois LE FEVRE*
Ingenieur
Email: flefevre@genoscope.cns.fr <mailto:flefevre@genoscope.cns.fr>
Tel: 33 (0)1 60 87 45 83

Fax: 33 (0)1 60 87 25 14


*Laboratoire d'Analyses Bioinformatiques pour la Génomique et le
Métabolisme -- LABGeM --
CEA / DSV / FAR / IG / Genoscope
(French Atomic Energy Commission)
*
Website: http://www.genoscope.cns.fr/agc/
Mail: 2 rue Gaston Cremieux,, CP 5706 91057 Evry, France
____________________________________________________________
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

On 22/03/11 12:50, Francois Le Fevre wrote:
> Hello All,
>
> 1.
>
> _*listOfModifiers*_
>
> * for me, if you add multiple modifiers, then they are isozymes,
> * if you want to define a AND relationship, then you have to
> define before a species of type complex/species
> * so here at CEA/Genoscope, we do exactly the same as in
> Manchester :-)_*
> *_

I believe both Manchester and Genoscope are wrong then, except if the FBA
package changes the semantics of the core.

The "modifier" element is born out of the necessity of having all species
symbols used in kineticLaw defined. In kcat*E*S/(Km+S), kcat and Km are
parameters (local or global), S is a reactant. What about E? Later this was
extended to encoding all influences, even if there were no kineticLaws
(e.g. stoichiometric maps).

Representing isozymes in SBGN would require an OR. No doubt about that. You
can have only ONE catalyst per process. The rational when it comes to SBML
is that if you declare two modifiers, they are two pools. Isoenzyme are
part of the same pool as far as the reaction is concerned.

I believe the proper way would be to use a "group". The members of the
group would be the isoenzymes. Of course, that would require to disentangle
the semantic of the "group". We need an attribute "type" on the group, with
the values "class" or "pool".

--
Nicolas LE NOVERE, Computational Systems Neurobiology, EMBL-EBI, WTGC,
Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,
Skype:n.lenovere, AIM:nlenovere, twitter:@lenovere
http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/

____________________________________________________________
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

On Mon, 2011-03-21 at 17:06 +0000, Nicolas Le Novère wrote:
> On 21/03/11 16:27, Francois Le Fevre wrote:
>
> > * sbo:term
> > o I would like to see the introduction of sboterm specific to
> > fba like fba:biomass, in order to tag the flux that is
> > relevant to biomass
>
> SBO is a user-driven effort. By all means, submit all your suggestions for
> SBO terms to the tracker:
> https://sourceforge.net/tracker/?group_id=174625&atid=871591
>
> > * gene association
> > o Personally, I think that gene association is protein
> > association: we are speaking on who is acting as a enzyme to
> > catalyse the reaction? The term gene association comes from
> > Palsson group, but I would rather use protein association.
>
> Yes indeed. That is something I have been trying to advocate to them ever
> since I talked to Adam Feist in Boston ICSB in 2005. I understand the
> rational behind the shortcut: Those models are often validated or used in
> conjunction with mutants. And the most FBA models are still done in
> organisms without alternative splicing, editing etc. But when it comes to
> encode knowledge, we should not use shortcuts. The package description
> says: "While the genes themselves can be defined as an SBML species". Yes,
> if one really wants to represent the gene, not the protein coded by it. The
> gene can always be related to the protein using a controlled annotation and
> the bqbio:encodedBy qualifier.

Thanks, good point, gene should in fact be "gene product encodedBy" I'll try to make this clearer.

> But when it comes to SBML element naming, I would avoid biological concepts
> at all cost! We already suffer so much from the terms "reaction" "reactant"
> and "product", we should not do it again. No "gene association", and no
> "protein association", please. An "association" and the nature of the
> things we are talking about emerges from their controlled annotation.

The key problem here (and why I started this path at all) was that I
couldn't find a satisfactory way to represent logical relations between
any model entities, which, in this case it happened to be "genes
representing peptides".

From this discussion it appears there might be a use for an
"Entity_Association" concept beyond the L3FBA package and perhaps it
should move somewhere else?

>
> > o Moreover (but it is independent from the first point) Why we
> > do not use the mechanism of protein complex formation: we
> > encode a reaction that form a protein complex from
> > polypeptide; then the protein is involved as a catalyst in
> > the reaction.
> >
> > Thanks for the comment.
> >> 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

Life Sciences
Centrum voor Wiskunde en Informatica (CWI), Amsterdam

Dept. Molecular Cell Physiology
VU University Amsterdam


____________________________________________________________
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

Hi all,

On reflection I agree with Pedro, which is always a sensible thing to do given that he's my boss.

I think that we need to consider how FBA and genome-scale modelling will evolve.

In Manchester, we're looking at incorporating experimental data into constraint based modelling. Consider a reaction with two isoenzymes. If we had rate constants or proteomics data, we could choose to alter the flux bounds for each reaction if we specify each separately. One fine day in future, we may have genome-scale gene regulatory networks that we may wish to integrate with metabolic models. We just don't know, so in my mind its better to specify the reactions more fully from the off.

The downsides are file-size bloat, and also that we may have to write slightly more sophisticated parsers to collapse such reaction sets into one when the need arises. But neither of these represent huge problems.

Cheers,

Neil.

On 22 Mar 2011, at 16:31, Pedro Mendes <pedro.mendes@manchester.ac.uk> wrote:

> Regarding multiple isoenzymes for the same reaction, I prefer to code these as
> separate reactions that just happen to have the same substrates and products
> (ie are formally the same), except that they have different enzymes. This
> works for both cases of when the enzyme is represented as an explicit species
> (modifier), or when the enzyme is hardcoded in the rate law. In fact this
> approach is the only one that works for the latter case...
>
> Of course I am referring to kinetic models where there is a rate law. But I
> think the same could be done with structural models alone.
>
> BTW, I think we have done this in the past in Manchester (for sure it has been
> always done like this in my office)
>
> Pedro
> --
> Pedro Mendes
> Chair in Computational Systems Biology
> School of Computer Science
> Manchester Centre for Integrative Systems Biology
> University of Manchester
>
> Manchester Interdisciplinary Biocentre
> 131 Princess Street
> Manchester, M1 7DN, U.K.
> ____________________________________________________________
> 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
____________________________________________________________
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

On Wed, 2011-03-23 at 11:12 -0400, Stefan Hoops wrote:

Hi Stefan, thanks for your comments.

> 1) fba:listOfObjectives
> This is in my opinion not SBML material it obviously describes what to
> do with the model. Unless SBML changes its doctrine about describing the
> model and not the analysis, this part should be removed from the
> extension. I nevertheless think that this information should be
> captured. It falls under the umbrella of MIASE and should therefore be
> encoded in SED-ML.

While this is true, pragmatically, might the following work:
- a long term solution that uses an expanded SED-ML and
- in the medium term continue using the current proposal as an
L2/L3 annotation.
Of course to enable adoption, it would be nice if such an annotation was
supported by libSBML (like layout). Would such a suggestion also suffer
from doctrinal issues?

> 2) fba:listOfGeneAssociations
> This is annotation and should be handled independently from this package
> in a general form (e.g. the annotation package)
> 3) fba:chemicalEquation
> This is also annotation and should be handled independently from this
> package in a general form (e.g. the annotation package)

No problem here. As mentioned, these things (including charge) overlap
with Annotation.

> This leaves only 1 new edition which is fba:listOfFluxBounds about which
> I have some question.
> Why are we not using MathML to describe the bounds?

As these bounds are only ever simple (in)equalities the feeling was you
don't really need the whole of MathML to describe them. If I'm not
mistaken isn't there also a problem referring to Reactions that don't
contain a KineticLaw in MathML?

> Why do we distinguish between less/lessEqual and
> greater/greaterEqual?
> The last distinction will make the implementation much harder as it
> requires any analysis tool to do algebraic operations since numerically
> comparison will not suffice.

The problem with strict inequalities was raised by Kieran and should
indeed be looked into. That being said, most optimization tools seem to
quite happily deal with the distinction.

> Thanks,
> Stefan
>
>

--
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

As an end user of community-curated metabolic reconstructions (and the COBRA toolbox), I would benefit from additional discussion of an issue raised in your proposal - existing annotation methods.

In particular, what is the best way to add additional annotation to such reconstructions? Are there any aspects of such annotation that are unique to Constraint Based models?

Models I've used would benefit from much more annotation - for example, literature references for each species and reaction, or a history of their review and addition to reconstructions (ie, who looked at it, when, and why was it added?).

As computational approaches to evaluating constraint based models advance (or regulatory networks are developed for use with metabolic networks), it seems likely that there will be increasing demand for other forms of annotation.

As you've noted in your proposal, the existing COBRA approach is to create a unique SBML dialect that depends on specific entities in the <notes> element. COBRA will need significant code revision to deal with different approaches to annotation. Or, it will require a translator from standard SBML to COBRA-SBML. Now that COBRA is on sourceforge, creating and disseminating such software may be more feasible, if there is interest.

It seems that a fork between SBML and COBRA-SBML has already happened. It would be great if COBRA and SBML3 could get back on the same page. Perhaps this extension can facilitate that?

Hi Ben,

You're absolutely right to point out the overlap between existing annotations, the Constraint Based models extension, and the approach used by the COBRA Toolbox.

We've recently released a proposal for extending the use of annotations in Level 3:

http://precedings.nature.com/documents/5610/version/1

This extension should cover some of the things that you mentioned (for example, the provenance of who updated what when and why). It's also clear that some things (such as metabolite charge and formula) may be better specified as an annotation rather than dealt with separately in the Constraint Based models extension. Brett and Frank are familiar with the Annotation proposal (in fact, Frank contributed to its development), so between us we should come up with a sensible solution that reduces overlap in each of the proposed packages.

A more difficult question is integration with COBRA. In my experience, the COBRA guys are not necessarily that forthcoming regarding developing and contributing to standardisation efforts. Although, to be fair, I see that a member of the COBRA team will be attending the Harmony meeting in a few weeks, which would be an ideal place to discuss (and rectify) this divergence of formats. Even if the COBRA guys were not that forthcoming, as you suggested, writing a parser to convert from SBML3 <--> COBRA wouldn't be too much of a job - all of the necessary fields are present in Frank and Brett's proposal.

Cheers,

Neil.

Neil Swainston
Experimental Officer

Manchester Centre for Integrative Systems Biology
Manchester Interdisciplinary Biocentre
University of Manchester
Manchester M1 7DN
United Kingdom

On 4 Apr 2011, at 16:51, Ben Heavner wrote:

>
> As an end user of community-curated metabolic reconstructions (and the COBRA toolbox), I would benefit from additional discussion of an issue raised in your proposal - existing annotation methods.
>
> In particular, what is the best way to add additional annotation to such reconstructions? Are there any aspects of such annotation that are unique to Constraint Based models?
>
> Models I've used would benefit from much more annotation - for example, literature references for each species and reaction, or a history of their review and addition to reconstructions (ie, who looked at it, when, and why was it added?).
>
> As computational approaches to evaluating constraint based models advance (or regulatory networks are developed for use with metabolic networks), it seems likely that there will be increasing demand for other forms of annotation.
>
> As you've noted in your proposal, the existing COBRA approach is to create a unique SBML dialect that depends on specific entities in the <notes> element. COBRA will need significant code revision to deal with different approaches to annotation. Or, it will require a translator from standard SBML to COBRA-SBML. Now that COBRA is on sourceforge, creating and disseminating such software may be more feasible, if there is interest.
>
> It seems that a fork between SBML and COBRA-SBML has already happened. It would be great if COBRA and SBML3 could get back on the same page. Perhaps this extension can facilitate that?
> ____________________________________________________________
> 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

____________________________________________________________
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

Hi Neil,

I think that your point gets to the heart of my issue as an end user:

>
> One thing you might want to consider is using the cobra tag or cbm tag instead of fba; fba's only a part of constraints-based modeling.

That is great feedback. The tag has been chosen as 'fbc' for Flux Balance Constraints. The 'balance' is indicating that there is the option of balancing equations. I hope that will work ...

best
Frank

> ____________________________________________________________
> 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

____________________________________________________________
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