Forums

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