sbml-flux — The SBML L3 Flux Balance Constraints package discussion list

Re: [sbml-flux] SBML FBC Session at COMBINE2022

[Thomas P. <th...@th...>]

Hi,

Brett and myself are on the Zoom room, and wondering where everyone is.

Best

Thomas

On 06/10/2022 15:41, Matthias König via sbml-flux wrote:
> Hi all,
>
> we have a SBML FBC session tomorrow at COMBINE2022 at 11.00 CEST.
> For more information see:
> https://combine-org.github.io/events/
>
> The session will be hybrid. For online participation in the session 
> use the following link:
>
> Topic: COMBINE 2022 SBML FBC Session
> Time: Oct 7, 2022 11:00 AM Amsterdam, Berlin, Rome, Stockholm, Vienna
>
> Join Zoom Meeting
> https://hu-berlin.zoom.us/j/69251681814?pwd=dHYyaUJvd01QbEhrWU8yblZxcTQxUT09
>
> Meeting ID: 692 5168 1814
> Password: 333716
>
> Best Matthias
>
>
> -- 
> Matthias König, PhD.
> Junior Group Leader Systems Medicine of the Liver Lab
> Humboldt-Universität zu Berlin,
> Institute of Biology, Institute for Theoretical Biology
> Philippstraße 13, Haus 20, 10115 Berlin
> Tel: +49 30 2093 98435
> https://livermetabolism.com
> kon...@go...
> https://twitter.com/konigmatt <https://twitter.com/konigmatt>
> https://github.com/matthiaskoenig <https://github.com/matthiaskoenig>
>
>
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux

[sbml-flux] the SBML Flux Balance Constraints Version 3 release candidate

[Olivier, B.G. (Brett) <b.g...@vu...>]

Dear all

Now available for preview and discussion at the COMBINE session: the SBML Flux Balance Constraints Version 3 release candidate. The specification now includes the definition of user-defined constraints, KeyValue pair annotations and expanded objective function and chemical formula definitions

https://github.com/sbmlteam/sbml-specifications/blob/develop/sbml-level-3/version-1/fbc/spec/sbml-fbc-version-3-rc1.pdf

Best regards
Brett


--

Brett G. Olivier PhD
Vrije Universiteit Amsterdam
Orcid: 0000-0002-5293-5321<http://orcid.org/0000-0002-5293-5321>

[sbml-flux] SBML FBC Session at COMBINE2022

[Matthias K. <kon...@go...>]

Hi all,

we have a SBML FBC session tomorrow at COMBINE2022 at 11.00 CEST.
For more information see:
https://combine-org.github.io/events/

The session will be hybrid. For online participation in the session use the
following link:

Topic: COMBINE 2022 SBML FBC Session
Time: Oct 7, 2022 11:00 AM Amsterdam, Berlin, Rome, Stockholm, Vienna

Join Zoom Meeting
https://hu-berlin.zoom.us/j/69251681814?pwd=dHYyaUJvd01QbEhrWU8yblZxcTQxUT09

Meeting ID: 692 5168 1814
Password: 333716

Best Matthias


-- 
Matthias König, PhD.
Junior Group Leader Systems Medicine of the Liver Lab
Humboldt-Universität zu Berlin,
Institute of Biology, Institute for Theoretical Biology
Philippstraße 13, Haus 20, 10115 Berlin
Tel: +49 30 2093 98435
https://livermetabolism.com
kon...@go...
https://twitter.com/konigmatt
https://github.com/matthiaskoenig

Re: [sbml-flux] Invitation to contribute to the community standard to promote reproducibility of constraint-based models - FROG analysis

[Ronan M.T. F. <ron...@gm...>]

Hi Andreas et al,

since 2013, when Recon2 was published, we have provided a means for
authors to post the code to reproduce the results in their paper
within a separate folder of this repo:
https://github.com/opencobra/COBRA.papers
It is a repository open to everyone.

Also, a couple of questions:

1) has anyone checked that the results of the frog report provided by
the 3 implementations of the FROG test suite agree with eachother?

2) some COBRA computations approximate NP-hard problems and are not
going to give the exact same result each time as they are by-necessity
approximations. How is this situation dealt with?

Regards,

Ronan

On Sat, 26 Mar 2022 at 16:41, Andreas Dräger
<and...@un...> wrote:
>
> Dear colleagues,
>
> I am inviting you to contribute to our initiative to improve the reproducibility of constraints-based models (CBMs) in the community. A recent study (Tiwari et al. 2021, Mol Sys Bio) has shown that about half of the published kinetic models could not be reproduced using the information provided in the manuscript. Currently, it is not possible to assess whether constraint-based models, including Genome-Scale metabolic models (GEM), are reproducible because these models often have multiple solutions, and the numerical values are not always enumerated in the published manuscripts. Therefore, one cannot ascertain whether a publicly shared CBM is the same model used in the manuscript. To tackle the reproducibility crisis, through a community effort, we have developed FROG analysis to generate a collection of numerically reproducible standardized reference datasets (aka FROG report) in a structured schema that can be used to assess the reproducibility of CBMs. We have developed a collection of tools to autogenerate FROG reports. BioModels will start curating CBMs using the FROG framework and MEMOTE test suite. To allow retrospective curation of previously published models, we propose that the model authors submit a miniFROG report and an autogenerated FROG report. The miniFROG report is a manually created data table in a standardized schema that lists at least a couple of results described in the manuscript and compares them against the model results from the FROG report. More details can be found at https://www.ebi.ac.uk/biomodels/curation/fbc.
>
> We are preparing a manuscript to summarize our effort, which we aim to submit shortly after HARMONY2022. As a vital member of the constraint-based modeling community, we invite you to assess the FROG analysis and tools and contribute to the manuscript by submitting your constraint-based models and FROG reports to BioModels. A BioModels curator will attempt to reproduce and curate your model to increase its impact. To contribute to the manuscript, please use the form below
> https://forms.gle/eiwD2vgU5dsa8s5p7
>
> To stay connected with us and join our hands-on training sessions please fill out the form below https://forms.gle/XwrQbWguWzESgJfj6
>
> For any questions, feel free to email me or bio...@eb... with the keyword ‘FROG’ in the subject line.
>
> We are looking forward to hearing from you.
>
> On behalf of the FBC curation standards working group, COMBINE,
> with best regards
>
> Dr. Andreas Draeger
> Assistant Professor
> ---
> University of Tübingen
> Institute for Bioinformatics and Medical Informatics (IBMI)
> Computational Systems Biology of Infections and Antimicrobial-Resistant Pathogens
> Sand 14 · Office #C108 · 72076 Tübingen · Germany
> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
> Web: http://systems-biology.info · Twitter: @dr_drae
> YouTube: https://www.youtube.com/c/systemsbiology
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux



-- 
--
Mr. Ronan MT Fleming B.V.M.S. Dip. Math. Ph.D.
----------------------------------------------------------------------------
Associate Professor,
School of Medicine,
National University of Ireland, Galway.
&
Assistant Professor,
Division of Systems Biomedicine and Pharmacology,
Leiden Academic Centre for Drug Research,
Faculty of Science,
Leiden University.
https://www.universiteitleiden.nl/en/staffmembers/ronan-fleming
&
H2020 Project Coordinator,
Systems Medicine of Mitochondrial Parkinson’s Disease,
http://sysmedpd.eu
----------------------------------------------------------------------------
Peer-reviewed publications: https://goo.gl/FZPG23
Mobile:  +353 852 109 806
Skype: ronan.fleming
----------------------------------------------------------------------------
(This message is confidential and may contain privileged information.
It is intended for the named recipient only. If you receive it in
error please notify me and permanently delete the original message and
any copies.)

[sbml-flux] Invitation to contribute to the community standard to promote reproducibility of constraint-based models - FROG analysis

[Andreas D. <and...@un...>]

Dear colleagues,

I am inviting you to contribute to our initiative to improve the reproducibility of constraints-based models (CBMs) in the community. A recent study (Tiwari et al. 2021, Mol Sys Bio) has shown that about half of the published kinetic models could not be reproduced using the information provided in the manuscript. Currently, it is not possible to assess whether constraint-based models, including Genome-Scale metabolic models (GEM), are reproducible because these models often have multiple solutions, and the numerical values are not always enumerated in the published manuscripts. Therefore, one cannot ascertain whether a publicly shared CBM is the same model used in the manuscript. To tackle the reproducibility crisis, through a community effort, we have developed FROG analysis to generate a collection of numerically reproducible standardized reference datasets (aka FROG report) in a structured schema that can be used to assess the reproducibility of CBMs. We have developed a collection of tools to autogenerate FROG reports. BioModels will start curating CBMs using the FROG framework and MEMOTE test suite. To allow retrospective curation of previously published models, we propose that the model authors submit a miniFROG report and an autogenerated FROG report. The miniFROG report is a manually created data table in a standardized schema that lists at least a couple of results described in the manuscript and compares them against the model results from the FROG report. More details can be found at https://www.ebi.ac.uk/biomodels/curation/fbc.

We are preparing a manuscript to summarize our effort, which we aim to submit shortly after HARMONY2022. As a vital member of the constraint-based modeling community, we invite you to assess the FROG analysis and tools and contribute to the manuscript by submitting your constraint-based models and FROG reports to BioModels. A BioModels curator will attempt to reproduce and curate your model to increase its impact. To contribute to the manuscript, please use the form below
https://forms.gle/eiwD2vgU5dsa8s5p7

To stay connected with us and join our hands-on training sessions please fill out the form below https://forms.gle/XwrQbWguWzESgJfj6

For any questions, feel free to email me or bio...@eb... with the keyword ‘FROG’ in the subject line.

We are looking forward to hearing from you.

On behalf of the FBC curation standards working group, COMBINE,
with best regards

Dr. Andreas Draeger
Assistant Professor
---
University of Tübingen
Institute for Bioinformatics and Medical Informatics (IBMI)
Computational Systems Biology of Infections and Antimicrobial-Resistant Pathogens
Sand 14 · Office #C108 · 72076 Tübingen · Germany
Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
Web: http://systems-biology.info · Twitter: @dr_drae
YouTube: https://www.youtube.com/c/systemsbiology

Re: [sbml-flux] Question regarding the FBC v3 element name: UserConstraint

[Wolfram L. <wol...@gm...>]

Hi Brett,

I'm not part of the FBC working group, but I would like to say anyway that
I'm strongly in favor of the second option, with UserDefinedConstraint etc.

I hope you're doing well, in these strange times.

All the best,
Wolf

[sbml-flux] Question regarding the FBC v3 element name: UserConstraint

[Brett G. O. <b.g...@vu...>]

Dear FBC working group

At the HARMONY meeting (EBI in March) an issue was raised regarding the 
naming of one of the elements, the "UserConstraint".

Breifly, the UserConstraint is used to encode non-stoichiometric, user 
defined, constraints - that is constraints that are not linear ODE's, as 
defined in the stoichiometrically coupled reaction network**.

The problem is that "UserConstraint" is a possibly vague, mildly 
ambiguous term when used in the following set of element names:

  * ListOfUserConstraints
  * UserConstraint
  * ListOfUserConstraintComponents
  * UserConstraintComponent

An initial proposal is to rename this component "UserDefinedConstraint" 
which would result in following element set:

  * ListOfUserDefinedConstraints
  * UserDefinedConstraint
  * ListOfUserDefinedConstraintComponents
  * UserDefinedConstraintComponent

Alternative proposals welcome, however, for practical reasons it would 
be good to have a decision - by consensus or vote - by 25 May.

Thanks in advance and best regards.
Brett

** Please see the v3 proposal 
(https://sourceforge.net/p/sbml/code/26312/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/main.pdf?format=raw) 
section 4.4 page 22 for more details.

-- 
Dr. Brett G. Olivier | Data Steward AIMMS Institute & Faculty of Science
AIMMS, Vrije Universiteit Amsterdam | Tel: +31 20 59 87248
Room 01W09, O|2 Building, De Boelelaan 1108, NL-1081HZ Amsterdam, The Netherlands
ORCID: http://orcid.org/0000-0002-5293-5321

Re: [sbml-flux] Current draft specification of FBC version 3

[Andreas D. <and...@un...>]

Thanks to all!

> Am 06.05.2020 um 10:18 schrieb Olivier, B.G. via sbml-flux <sbm...@li...>:
> 
> Hi Andreas
> 
> Besides the documents Frank mentioned, I've been updating the spec on SourceForge. 
> 
> The latest version is always available here:  
> 
> https://sourceforge.net/p/sbml/code/26312/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/main.pdf?format=raw
> 
> Best regards
> Brett
> 
> --
> Dr. Brett G. Olivier | Data Steward AIMMS Institute & Faculty of Science
> AIMMS, Vrije Universiteit Amsterdam | Tel: +31 20 59 87248
> Room 01W09, O|2 Building, De Boelelaan 1108, NL-1081HZ Amsterdam, The Netherlands 
> ORCID: http://orcid.org/0000-0002-5293-5321
> 
>> -----Original Message-----
>> From: Frank Bergmann <fbe...@ca...>
>> Sent: Wednesday, 6 May 2020 09:25
>> To: The SBML L3 Flux Balance Constraints package discussion list <sbml-
>> fl...@li...>
>> Subject: [Spam] Re: [sbml-flux] Current draft specification of FBC version 3
>> 
>> Hello Andreas,
>> 
>> I am not sure there is a draft spec yet, what we have so far is:
>> 
>> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml
>> -level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf
>> 
>> at HARMONY we discussed, this document
>> 
>> https://docs.google.com/document/d/1ploBO3DgEzDaNK_F5Kv1t2FAxPjYzO
>> urVJbZT9XTr34/edit
>> 
>> best
>> Frank
>> 
>>> -----Original Message-----
>>> From: Andreas Dräger <and...@un...>
>>> Sent: Tuesday, May 5, 2020 7:00 PM
>>> To: sbm...@li...
>>> Subject: [sbml-flux] Current draft specification of FBC version 3
>>> 
>>> Dear all,
>>> 
>>> Could anybody please provide the current draft for the new FBC
>>> specification version 3? Thanks a lot!
>>> 
>>> With best regards
>>> 
>>> Dr. Andreas Draeger
>>> Assistant Professor
>>> ---
>>> University of Tübingen
>>> Institute for Bioinformatics and Medical Informatics (IBMI)
>>> Computational Systems Biology of Infection and Antimicrobial-Resistant
>>> Pathogens Sand 14 · Office #C108 · 72076 Tübingen · Germany
>>> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
>>> Web: http://systems-biology.info · Twitter: @dr_drae
>>> YouTube: https://www.youtube.com/c/systemsbiology
>> 
>> 
>> _______________________________________________
>> sbml-flux mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-flux
> 
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux

With best regards

Dr. Andreas Draeger
Assistant Professor
---
University of Tübingen
Institute for Bioinformatics and Medical Informatics (IBMI)
Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
Sand 14 · Office #C108 · 72076 Tübingen · Germany
Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
Web: http://systems-biology.info · Twitter: @dr_drae
YouTube: https://www.youtube.com/c/systemsbiology

Re: [sbml-flux] Current draft specification of FBC version 3

[Olivier, B.G. <b.g...@vu...>]

Hi Andreas

Besides the documents Frank mentioned, I've been updating the spec on SourceForge. 

The latest version is always available here:  

https://sourceforge.net/p/sbml/code/26312/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/main.pdf?format=raw

Best regards
Brett

--
Dr. Brett G. Olivier | Data Steward AIMMS Institute & Faculty of Science
AIMMS, Vrije Universiteit Amsterdam | Tel: +31 20 59 87248
Room 01W09, O|2 Building, De Boelelaan 1108, NL-1081HZ Amsterdam, The Netherlands 
ORCID: http://orcid.org/0000-0002-5293-5321

> -----Original Message-----
> From: Frank Bergmann <fbe...@ca...>
> Sent: Wednesday, 6 May 2020 09:25
> To: The SBML L3 Flux Balance Constraints package discussion list <sbml-
> fl...@li...>
> Subject: [Spam] Re: [sbml-flux] Current draft specification of FBC version 3
> 
> Hello Andreas,
> 
> I am not sure there is a draft spec yet, what we have so far is:
> 
> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml
> -level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf
> 
> at HARMONY we discussed, this document
> 
> https://docs.google.com/document/d/1ploBO3DgEzDaNK_F5Kv1t2FAxPjYzO
> urVJbZT9XTr34/edit
> 
> best
> Frank
> 
> > -----Original Message-----
> > From: Andreas Dräger <and...@un...>
> > Sent: Tuesday, May 5, 2020 7:00 PM
> > To: sbm...@li...
> > Subject: [sbml-flux] Current draft specification of FBC version 3
> >
> > Dear all,
> >
> > Could anybody please provide the current draft for the new FBC
> > specification version 3? Thanks a lot!
> >
> > With best regards
> >
> > Dr. Andreas Draeger
> > Assistant Professor
> > ---
> > University of Tübingen
> > Institute for Bioinformatics and Medical Informatics (IBMI)
> > Computational Systems Biology of Infection and Antimicrobial-Resistant
> > Pathogens Sand 14 · Office #C108 · 72076 Tübingen · Germany
> > Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
> > Web: http://systems-biology.info · Twitter: @dr_drae
> > YouTube: https://www.youtube.com/c/systemsbiology
> 
> 
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux

Re: [sbml-flux] Current draft specification of FBC version 3

[Frank B. <fbe...@ca...>]

Hello Andreas, 

I am not sure there is a draft spec yet, what we have so far is: 

https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf

at HARMONY we discussed, this document

https://docs.google.com/document/d/1ploBO3DgEzDaNK_F5Kv1t2FAxPjYzOurVJbZT9XTr34/edit

best
Frank

> -----Original Message-----
> From: Andreas Dräger <and...@un...>
> Sent: Tuesday, May 5, 2020 7:00 PM
> To: sbm...@li...
> Subject: [sbml-flux] Current draft specification of FBC version 3
> 
> Dear all,
> 
> Could anybody please provide the current draft for the new FBC specification
> version 3? Thanks a lot!
> 
> With best regards
> 
> Dr. Andreas Draeger
> Assistant Professor
> ---
> University of Tübingen
> Institute for Bioinformatics and Medical Informatics (IBMI) Computational
> Systems Biology of Infection and Antimicrobial-Resistant Pathogens Sand 14 ·
> Office #C108 · 72076 Tübingen · Germany
> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
> Web: http://systems-biology.info · Twitter: @dr_drae
> YouTube: https://www.youtube.com/c/systemsbiology

[sbml-flux] Current draft specification of FBC version 3

[Andreas D. <and...@un...>]

Dear all,

Could anybody please provide the current draft for the new FBC specification version 3? Thanks a lot!

With best regards

Dr. Andreas Draeger
Assistant Professor
---
University of Tübingen
Institute for Bioinformatics and Medical Informatics (IBMI)
Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
Sand 14 · Office #C108 · 72076 Tübingen · Germany
Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
Web: http://systems-biology.info · Twitter: @dr_drae
YouTube: https://www.youtube.com/c/systemsbiology

Re: [sbml-flux] FBC version 3 proposal (new document)

[Olivier, B.G. <b.g...@vu...>]

Hi Andreas

I think this is just a case cross threading of conversations. AFAIK the revised case you mention (non-SBase inherited annotations) was the favoured option. 

So no new  change and it seems like we are starting to form a consensus on non-SBase derived annotations, cool!

Best
Brett

-- 
Brett G. Olivier PhD | Research Data Steward
AIMMS, Vrije Universiteit Amsterdam | Tel: +31 20 59 87248
Room 01W09, O|2 Building, De Boelelaan 1108, NL-1081HZ Amsterdam, The Netherlands
http://teusinkbruggemanlab.nl/brett-olivier/

-----Original Message-----
From: Andreas Dräger <and...@un...> 
Sent: 09 July 2019 13:20
To: The SBML L3 Flux Balance Constraints package discussion list <sbm...@li...>
Subject: [Spam] Re: [sbml-flux] FBC version 3 proposal (new document)

Dear all,

The initially proposed specification indicates in Fig. 10 on page 19 that the proposal is to let both, key-value pairs and the list of those, extend SBase. Since including such instances of SBase in the annotation could bring with it more complex nested annotations and nested notes, hence potentially leading to relatively complex data structures, my original question was: Why is this anticipated?

From Brett's earlier e-mail (from March 5th, 2019), my understanding was that this idea has already been dropped.

The alternative suggestion to introduce an abstract FBCBase only makes sense when sticking with the idea to have them as subclasses of SBase, which seems not to be the plan. Did I miss anything, is it now planned to return to the original idea?

Cheers
Andreas


> Am 09.07.2019 um 10:55 schrieb Matthias König via sbml-flux <sbm...@li...>:
> 
> Hi all,
> I agree with Brett here:
> - I see the ListOfKeyValuePairs as some advanced structured annotation, so in my opinion this should not be an SBase extension.
> 
> I wanted to ask if there is by any chance already support in the libsbml develop branch for the ListOfKeyValuePairs (and the other proposed fbc-v3 features)?
> Especially the ListOfKeyValuePairs I would like to use.
> 
> Best Matthias
> 
> On Mon, Jul 8, 2019 at 11:06 PM Brett G. Olivier via sbml-flux <sbm...@li...> wrote:
> Hi Andreas
> 
> On 06-Mar-19 9:04 AM, Andreas Dräger wrote:
>> Alternatively, you could also define an abstract FBCBase object that has a ListOfKeyValuePairs. Then, every object defined in the FBC specification could inherit from FBCBase and therefore be automatically equipped with that list. In this way, the key-value pairs and their list could continue to be derived from SBase, they could be attached to any FBC object, and it wouldn't be necessary to move them to the annotation block. It seems to me this would simplify the implementation and solve some of the problems.
>> 
> An interesting idea, while this makes a lot of sense from an implementation point of view it has some disadvantageous from an interoperability perspective. Some of the advantages of using non-SBase derived objects as a separate annotation:
> 
> 	• They can, in principle, be used as an annotation on any SBase derived object, not only FBC.
> 	• They are immediately usable in any FBC version, even though they are specified in V3.
> Looking forward to discussing this and other issues at the COMBINE breakout. 
> 
> Cheers,
> b.
> 
> 
> 
>> Cheers
>> Andreas
>> 
>> 
>> 
>>> Am 05.03.2019 um 22:40 schrieb Brett G. Olivier via sbml-flux 
>>> <sbm...@li...>
>>> :
>>> 
>>> Dear Andreas
>>> 
>>> Thanks for your comments, both here and in the PDF, they are much appreciated. For now, a quick comment on the KeyValuePair annotation.
>>> 
>>> On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
>>> 
>>>> Dear package working group,
>>>> 
>>>> Thanks to all contributors of the new specification draft, Brett in particular, for putting this together. It is great to see this new development including several promising new features and improvements. I have a few remarks that we can, hopefully, discuss in person during HARMONY soon.
>>>> 
>>>> Fig 10:
>>>> 
>>>> When viewing this image, it is first not clear where the list of key-value pairs is going to be placed in the model because in contrast to all other lists, there is no "has" relationship type arrow. Only the inheritance relationship to SBase is indicated. Later in the text this becomes clearer. Maybe a comment in the caption could help saying that this list goes to the annotation. It is generally interesting that this list goes to the annotation, because it is an SBase and therefore may have an annotation and notes subelement itself. Is this intended? It essentially implies a nesting of annotations and list objects. Is there any specific reason why this is not simply a subelement of the extended model?
>>>> 
>>>> 
>>> Good catch, indeed this element has moved around in the model and the UML and text has not caught up. The current idea is that the KeyValuePair and associated list is *not* an SBase derived element but should have the same "standardised format" status as the SBML RDF annotation. 
>>> 
>>> Doing it this way, not only has the advantage of not having to extend SBase (and open up a whole bunch of potential implementation issues) but also avoids the the annotation nesting problem you highlight. My feeling is such annotation nesting needs to be avoided and the KeyValuePair should be an annotation element that has the attributes:
>>> 
>>> id: SId {use="optional"}
>>> name: string {use="optional"}
>>> key: string
>>> value: string {use="optional"}
>>> uri: uri {use="optional"}
>>> 
>>> While on this point, I have a general question: does the KeyValuePair need a <notes> element analogous to SBML notes element?
>>> 
>>> notes: xmlns: string {
>>> "http://www.w3.org/1999/xhtml"
>>> }
>>> 
>>> Does that make things clearer? If this works, I will update the proposal appropriately.
>>> 
>>> Best regards
>>> Brett
>>> 
>>> 
>>>>> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux 
>>>>> <sbm...@li...>
>>>>> 
>>>>> :
>>>>> 
>>>>> Dear Matthias and members of the FBC working group
>>>>> 
>>>>> The extensions and modifications contained in this document are proposed as version 3 of the Flux Balance Constraints package. This proposal is been formulated through open discussions on this list and intense discussion during HARMONY 2018.
>>>>> 
>>>>> The proposed Flux Balance Constraints package version 3:
>>>>> 
>>>>> 	• extends the definition of the FluxObjective allowing both linear and quadratic variables
>>>>> 	• extends the definition of the chemicalFormula
>>>>> 	• extends the definition of charge to allow it to be a double
>>>>> 	• adds an element that allows the definition of a non-stoichiometric UserConstraints 
>>>>> 	• adds a definition for a generic KeyValuePair annotation.
>>>>> The proposed changes have been summarized as a standalone PDF:
>>>>> 
>>>>> 
>>>>> 
>>>>> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications
>>>>> /sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?f
>>>>> ormat=raw
>>>>> 
>>>>> 
>>>>> 
>>>>> All comments and welcome: including are these topics relevant to FBC, do the proposed solutions solve known current model encoding problems, are there tools that provide support for (or would be able to support) the extended functionality proposed here?
>>>>> 
>>>>> Sent on behalf of all the participants in the ongoing discussion.
>>>>> 
>>>>> Best regards
>>>>> Brett
>>>>> 
>>>>> 
>>>>> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> @all It would be great if we could finish the L3 fbc package. 
>>>>>> There aren't too many proposed changes, but they will solve a multitude of issues occurring in the constrainted-based modelling community. The proposed UserConstraints and KeyValuePairs are both very versatile and useful additions and it would be great if we could use these in fbc models.
>>>>>> Bret, Thomas, Lucian, me and others discussed a lot during HARMONY to find a solution which could work for everyone (and found an agreement which would work for the people at HARMONY). But we need input/feedback from the community to get this moving.
>>>>>> Please take half an hour of your time to read over the few pages 
>>>>>> and provide your feedback
>>>>>> 
>>>>>> 
>>>>> --
>>>>> 
>>>>> Brett G. Olivier PhD
>>>>> 
>>>>> Systems Bioinformatics, Amsterdam Institute for Molecules, 
>>>>> Medicines and Systems, Vrije Universiteit Amsterdam, The 
>>>>> Netherlands Modeling of Biological Processes, BioQUANT/COS, 
>>>>> Heidelberg University, Germany
>>>>> 
>>>>> 
>>>> With best regards
>>>> 
>>>> Dr. Andreas Draeger
>>>> 
>>>> 
>>> --
>>> Brett G. Olivier
>>> 
>> With best regards
>> 
>> Dr. Andreas Draeger
>> Assistant Professor
>> ---
>> University of Tübingen
>> Center for Bioinformatics Tübingen (ZBIT) Computational Systems 
>> Biology of Infection and Antimicrobial-Resistant Pathogens Sand 14 · 
>> Office #C320 · 72076 Tübingen · Germany
>> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
>> Web: 
>> http://draeger-lab.org
>>  · Twitter: @dr_drae
>> YouTube: 
>> https://www.youtube.com/c/systemsbiology
>> 
>> 
>> 
> --
> Brett G. Olivier PhD
> 
> Data Steward (O2|1W09) (
> b.g...@vu...
> )
> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines 
> and Systems, Vrije Universiteit Amsterdam, The Netherlands
> 
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux
> 
> 
> --
> Matthias König, PhD.
> Junior Group Leader LiSyM - Systems Medicine of the Liver Humboldt 
> Universität zu Berlin, Institute of Biology, Institute for Theoretical Biology
>   https://livermetabolism.com
> kon...@go...
> https://twitter.com/konigmatt
> https://github.com/matthiaskoenig
> Tel: +49 30 2093 98435
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux

With best regards

Dr. Andreas Draeger
Assistant Professor
---
University of Tübingen
Institute for Biomedical Informatics (IBMI) Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens Sand 14 · Office #C320 · 72076 Tübingen · Germany
Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
Web: http://systems-biology.info · Twitter: @dr_drae
YouTube: https://www.youtube.com/c/systemsbiology

Re: [sbml-flux] FBC version 3 proposal (new document)

[Andreas D. <and...@un...>]

Dear all,

The initially proposed specification indicates in Fig. 10 on page 19 that the proposal is to let both, key-value pairs and the list of those, extend SBase. Since including such instances of SBase in the annotation could bring with it more complex nested annotations and nested notes, hence potentially leading to relatively complex data structures, my original question was: Why is this anticipated?

From Brett's earlier e-mail (from March 5th, 2019), my understanding was that this idea has already been dropped.

The alternative suggestion to introduce an abstract FBCBase only makes sense when sticking with the idea to have them as subclasses of SBase, which seems not to be the plan. Did I miss anything, is it now planned to return to the original idea?

Cheers
Andreas


> Am 09.07.2019 um 10:55 schrieb Matthias König via sbml-flux <sbm...@li...>:
> 
> Hi all, 
> I agree with Brett here:
> - I see the ListOfKeyValuePairs as some advanced structured annotation, so in my opinion this should not be an SBase extension.
> 
> I wanted to ask if there is by any chance already support in the libsbml develop branch for the ListOfKeyValuePairs (and the other proposed fbc-v3 features)?
> Especially the ListOfKeyValuePairs I would like to use.
> 
> Best Matthias
> 
> On Mon, Jul 8, 2019 at 11:06 PM Brett G. Olivier via sbml-flux <sbm...@li...> wrote:
> Hi Andreas
> 
> On 06-Mar-19 9:04 AM, Andreas Dräger wrote:
>> Alternatively, you could also define an abstract FBCBase object that has a ListOfKeyValuePairs. Then, every object defined in the FBC specification could inherit from FBCBase and therefore be automatically equipped with that list. In this way, the key-value pairs and their list could continue to be derived from SBase, they could be attached to any FBC object, and it wouldn't be necessary to move them to the annotation block. It seems to me this would simplify the implementation and solve some of the problems.
>> 
> An interesting idea, while this makes a lot of sense from an implementation point of view it has some disadvantageous from an interoperability perspective. Some of the advantages of using non-SBase derived objects as a separate annotation:
> 
> 	• They can, in principle, be used as an annotation on any SBase derived object, not only FBC.
> 	• They are immediately usable in any FBC version, even though they are specified in V3.
> Looking forward to discussing this and other issues at the COMBINE breakout. 
> 
> Cheers,
> b.
> 
> 
> 
>> Cheers
>> Andreas
>> 
>> 
>> 
>>> Am 05.03.2019 um 22:40 schrieb Brett G. Olivier via sbml-flux <sbm...@li...>
>>> :
>>> 
>>> Dear Andreas
>>> 
>>> Thanks for your comments, both here and in the PDF, they are much appreciated. For now, a quick comment on the KeyValuePair annotation.
>>> 
>>> On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
>>> 
>>>> Dear package working group,
>>>> 
>>>> Thanks to all contributors of the new specification draft, Brett in particular, for putting this together. It is great to see this new development including several promising new features and improvements. I have a few remarks that we can, hopefully, discuss in person during HARMONY soon.
>>>> 
>>>> Fig 10:
>>>> 
>>>> When viewing this image, it is first not clear where the list of key-value pairs is going to be placed in the model because in contrast to all other lists, there is no "has" relationship type arrow. Only the inheritance relationship to SBase is indicated. Later in the text this becomes clearer. Maybe a comment in the caption could help saying that this list goes to the annotation. It is generally interesting that this list goes to the annotation, because it is an SBase and therefore may have an annotation and notes subelement itself. Is this intended? It essentially implies a nesting of annotations and list objects. Is there any specific reason why this is not simply a subelement of the extended model?
>>>> 
>>>> 
>>> Good catch, indeed this element has moved around in the model and the UML and text has not caught up. The current idea is that the KeyValuePair and associated list is *not* an SBase derived element but should have the same "standardised format" status as the SBML RDF annotation. 
>>> 
>>> Doing it this way, not only has the advantage of not having to extend SBase (and open up a whole bunch of potential implementation issues) but also avoids the the annotation nesting problem you highlight. My feeling is such annotation nesting needs to be avoided and the KeyValuePair should be an annotation element that has the attributes:
>>> 
>>> id: SId {use="optional"}
>>> name: string {use="optional"}
>>> key: string
>>> value: string {use="optional"}
>>> uri: uri {use="optional"}
>>> 
>>> While on this point, I have a general question: does the KeyValuePair need a <notes> element analogous to SBML notes element?
>>> 
>>> notes: xmlns: string {
>>> "http://www.w3.org/1999/xhtml"
>>> }
>>> 
>>> Does that make things clearer? If this works, I will update the proposal appropriately.
>>> 
>>> Best regards
>>> Brett
>>> 
>>> 
>>>>> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux <sbm...@li...>
>>>>> 
>>>>> :
>>>>> 
>>>>> Dear Matthias and members of the FBC working group
>>>>> 
>>>>> The extensions and modifications contained in this document are proposed as version 3 of the Flux Balance Constraints package. This proposal is been formulated through open discussions on this list and intense discussion during HARMONY 2018.
>>>>> 
>>>>> The proposed Flux Balance Constraints package version 3:
>>>>> 
>>>>> 	• extends the definition of the FluxObjective allowing both linear and quadratic variables
>>>>> 	• extends the definition of the chemicalFormula
>>>>> 	• extends the definition of charge to allow it to be a double
>>>>> 	• adds an element that allows the definition of a non-stoichiometric UserConstraints 
>>>>> 	• adds a definition for a generic KeyValuePair annotation.
>>>>> The proposed changes have been summarized as a standalone PDF:
>>>>> 
>>>>> 
>>>>> 
>>>>> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
>>>>> 
>>>>> 
>>>>> 
>>>>> All comments and welcome: including are these topics relevant to FBC, do the proposed solutions solve known current model encoding problems, are there tools that provide support for (or would be able to support) the extended functionality proposed here?
>>>>> 
>>>>> Sent on behalf of all the participants in the ongoing discussion.
>>>>> 
>>>>> Best regards
>>>>> Brett
>>>>> 
>>>>> 
>>>>> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> @all It would be great if we could finish the L3 fbc package. 
>>>>>> There aren't too many proposed changes, but they will solve a multitude of issues occurring in the constrainted-based modelling community. The proposed UserConstraints and KeyValuePairs are both very versatile and useful additions and it would be great if we could use these in fbc models.
>>>>>> Bret, Thomas, Lucian, me and others discussed a lot during HARMONY to find a solution which could work for everyone (and found an agreement which would work for the people at HARMONY). But we need input/feedback from the community to get this moving.
>>>>>> Please take half an hour of your time to read over the few pages and provide your feedback
>>>>>> 
>>>>>> 
>>>>> --
>>>>> 
>>>>> Brett G. Olivier PhD
>>>>> 
>>>>> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
>>>>> Modeling of Biological Processes, BioQUANT/COS, Heidelberg University, Germany
>>>>> 
>>>>> 
>>>> With best regards
>>>> 
>>>> Dr. Andreas Draeger
>>>> 
>>>> 
>>> -- 
>>> Brett G. Olivier
>>> 
>> With best regards
>> 
>> Dr. Andreas Draeger
>> Assistant Professor
>> ---
>> University of Tübingen
>> Center for Bioinformatics Tübingen (ZBIT)
>> Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
>> Sand 14 · Office #C320 · 72076 Tübingen · Germany
>> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
>> Web: 
>> http://draeger-lab.org
>>  · Twitter: @dr_drae
>> YouTube: 
>> https://www.youtube.com/c/systemsbiology
>> 
>> 
>> 
> -- 
> Brett G. Olivier PhD
> 
> Data Steward (O2|1W09) (
> b.g...@vu...
> )
> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
> 
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux
> 
> 
> -- 
> Matthias König, PhD.
> Junior Group Leader LiSyM - Systems Medicine of the Liver
> Humboldt Universität zu Berlin, Institute of Biology, Institute for Theoretical Biology
>   https://livermetabolism.com
> kon...@go...
> https://twitter.com/konigmatt
> https://github.com/matthiaskoenig
> Tel: +49 30 2093 98435
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux

With best regards

Dr. Andreas Draeger
Assistant Professor
---
University of Tübingen
Institute for Biomedical Informatics (IBMI)
Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
Sand 14 · Office #C320 · 72076 Tübingen · Germany
Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
Web: http://systems-biology.info · Twitter: @dr_drae
YouTube: https://www.youtube.com/c/systemsbiology

Re: [sbml-flux] FBC version 3 proposal (new document)

[Matthias K. <kon...@go...>]

Hi all,
I agree with Brett here:
- I see the ListOfKeyValuePairs as some advanced structured annotation, so
in my opinion this should not be an SBase extension.

I wanted to ask if there is by any chance already support in the libsbml
develop branch for the ListOfKeyValuePairs (and the other proposed fbc-v3
features)?
Especially the ListOfKeyValuePairs I would like to use.

Best Matthias

On Mon, Jul 8, 2019 at 11:06 PM Brett G. Olivier via sbml-flux <
sbm...@li...> wrote:

> Hi Andreas
>
> On 06-Mar-19 9:04 AM, Andreas Dräger wrote:
>
> Alternatively, you could also define an abstract FBCBase object that has a ListOfKeyValuePairs. Then, every object defined in the FBC specification could inherit from FBCBase and therefore be automatically equipped with that list. In this way, the key-value pairs and their list could continue to be derived from SBase, they could be attached to any FBC object, and it wouldn't be necessary to move them to the annotation block. It seems to me this would simplify the implementation and solve some of the problems.
>
> An interesting idea, while this makes a lot of sense from an
> implementation point of view it has some disadvantageous from an
> interoperability perspective. Some of the advantages of using non-SBase
> derived objects as a separate annotation:
>
>    - They can, in principle, be used as an annotation on any SBase
>    derived object, not only FBC.
>    - They are immediately usable in any FBC version, even though they are
>    specified in V3.
>
> Looking forward to discussing this and other issues at the COMBINE
> breakout.
>
> Cheers,
> b.
>
>
> Cheers
> Andreas
>
>
>
> Am 05.03.2019 um 22:40 schrieb Brett G. Olivier via sbml-flux <sbm...@li...> <sbm...@li...>:
>
> Dear Andreas
>
> Thanks for your comments, both here and in the PDF, they are much appreciated. For now, a quick comment on the KeyValuePair annotation.
>
> On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
>
> Dear package working group,
>
> Thanks to all contributors of the new specification draft, Brett in particular, for putting this together. It is great to see this new development including several promising new features and improvements. I have a few remarks that we can, hopefully, discuss in person during HARMONY soon.
>
> Fig 10:
>
> When viewing this image, it is first not clear where the list of key-value pairs is going to be placed in the model because in contrast to all other lists, there is no "has" relationship type arrow. Only the inheritance relationship to SBase is indicated. Later in the text this becomes clearer. Maybe a comment in the caption could help saying that this list goes to the annotation. It is generally interesting that this list goes to the annotation, because it is an SBase and therefore may have an annotation and notes subelement itself. Is this intended? It essentially implies a nesting of annotations and list objects. Is there any specific reason why this is not simply a subelement of the extended model?
>
>
> Good catch, indeed this element has moved around in the model and the UML and text has not caught up. The current idea is that the KeyValuePair and associated list is *not* an SBase derived element but should have the same "standardised format" status as the SBML RDF annotation.
>
> Doing it this way, not only has the advantage of not having to extend SBase (and open up a whole bunch of potential implementation issues) but also avoids the the annotation nesting problem you highlight. My feeling is such annotation nesting needs to be avoided and the KeyValuePair should be an annotation element that has the attributes:
>
> id: SId {use="optional"}
> name: string {use="optional"}
> key: string
> value: string {use="optional"}
> uri: uri {use="optional"}
>
> While on this point, I have a general question: does the KeyValuePair need a <notes> element analogous to SBML notes element?
>
> notes: xmlns: string {"http://www.w3.org/1999/xhtml" <http://www.w3.org/1999/xhtml>}
>
> Does that make things clearer? If this works, I will update the proposal appropriately.
>
> Best regards
> Brett
>
>
> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux <sbm...@li...> <sbm...@li...>
> :
>
> Dear Matthias and members of the FBC working group
>
> The extensions and modifications contained in this document are proposed as version 3 of the Flux Balance Constraints package. This proposal is been formulated through open discussions on this list and intense discussion during HARMONY 2018.
>
> The proposed Flux Balance Constraints package version 3:
>
> 	• extends the definition of the FluxObjective allowing both linear and quadratic variables
> 	• extends the definition of the chemicalFormula
> 	• extends the definition of charge to allow it to be a double
> 	• adds an element that allows the definition of a non-stoichiometric UserConstraints
> 	• adds a definition for a generic KeyValuePair annotation.
> The proposed changes have been summarized as a standalone PDF:
>
> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
>
>
> All comments and welcome: including are these topics relevant to FBC, do the proposed solutions solve known current model encoding problems, are there tools that provide support for (or would be able to support) the extended functionality proposed here?
>
> Sent on behalf of all the participants in the ongoing discussion.
>
> Best regards
> Brett
>
>
> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
>
>
>
> @all It would be great if we could finish the L3 fbc package.
> There aren't too many proposed changes, but they will solve a multitude of issues occurring in the constrainted-based modelling community. The proposed UserConstraints and KeyValuePairs are both very versatile and useful additions and it would be great if we could use these in fbc models.
> Bret, Thomas, Lucian, me and others discussed a lot during HARMONY to find a solution which could work for everyone (and found an agreement which would work for the people at HARMONY). But we need input/feedback from the community to get this moving.
> Please take half an hour of your time to read over the few pages and provide your feedback
>
>
> --
>
> Brett G. Olivier PhD
>
> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
> Modeling of Biological Processes, BioQUANT/COS, Heidelberg University, Germany
>
>
> With best regards
>
> Dr. Andreas Draeger
>
>
> --
> Brett G. Olivier
>
> With best regards
>
> Dr. Andreas Draeger
> Assistant Professor
> ---
> University of Tübingen
> Center for Bioinformatics Tübingen (ZBIT)
> Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
> Sand 14 · Office #C320 · 72076 Tübingen · Germany
> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
> Web: http://draeger-lab.org · Twitter: @dr_drae
> YouTube: https://www.youtube.com/c/systemsbiology
>
> --
> Brett G. Olivier PhD
>
> Data Steward (O2|1W09) (b.g...@vu...)
> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
>
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux
>


-- 
Matthias König, PhD.
Junior Group Leader LiSyM - Systems Medicine of the Liver
Humboldt Universität zu Berlin, Institute of Biology, Institute for
Theoretical Biology
  https://livermetabolism.com
kon...@go...
https://twitter.com/konigmatt
https://github.com/matthiaskoenig
Tel: +49 30 2093 98435

Re: [sbml-flux] FBC version 3 proposal (new document)

[Brett G. O. <b.g...@vu...>]

Hi Andreas

On 06-Mar-19 9:04 AM, Andreas Dräger wrote:
> Alternatively, you could also define an abstract FBCBase object that has a ListOfKeyValuePairs. Then, every object defined in the FBC specification could inherit from FBCBase and therefore be automatically equipped with that list. In this way, the key-value pairs and their list could continue to be derived from SBase, they could be attached to any FBC object, and it wouldn't be necessary to move them to the annotation block. It seems to me this would simplify the implementation and solve some of the problems.

An interesting idea, while this makes a lot of sense from an 
implementation point of view it has some disadvantageous from an 
interoperability perspective. Some of the advantages of using non-SBase 
derived objects as a separate annotation:

  * They can, in principle, be used as an annotation on any SBase
    derived object, not only FBC.
  * They are immediately usable in any FBC version, even though they are
    specified in V3.

Looking forward to discussing this and other issues at the COMBINE 
breakout.

Cheers,
b.


> Cheers
> Andreas
>
>
>> Am 05.03.2019 um 22:40 schrieb Brett G. Olivier via sbml-flux <sbm...@li...>:
>>
>> Dear Andreas
>>
>> Thanks for your comments, both here and in the PDF, they are much appreciated. For now, a quick comment on the KeyValuePair annotation.
>>
>> On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
>>> Dear package working group,
>>>
>>> Thanks to all contributors of the new specification draft, Brett in particular, for putting this together. It is great to see this new development including several promising new features and improvements. I have a few remarks that we can, hopefully, discuss in person during HARMONY soon.
>>>
>>> Fig 10:
>>>
>>> When viewing this image, it is first not clear where the list of key-value pairs is going to be placed in the model because in contrast to all other lists, there is no "has" relationship type arrow. Only the inheritance relationship to SBase is indicated. Later in the text this becomes clearer. Maybe a comment in the caption could help saying that this list goes to the annotation. It is generally interesting that this list goes to the annotation, because it is an SBase and therefore may have an annotation and notes subelement itself. Is this intended? It essentially implies a nesting of annotations and list objects. Is there any specific reason why this is not simply a subelement of the extended model?
>>>
>> Good catch, indeed this element has moved around in the model and the UML and text has not caught up. The current idea is that the KeyValuePair and associated list is *not* an SBase derived element but should have the same "standardised format" status as the SBML RDF annotation.
>>
>> Doing it this way, not only has the advantage of not having to extend SBase (and open up a whole bunch of potential implementation issues) but also avoids the the annotation nesting problem you highlight. My feeling is such annotation nesting needs to be avoided and the KeyValuePair should be an annotation element that has the attributes:
>>
>> id: SId {use="optional"}
>> name: string {use="optional"}
>> key: string
>> value: string {use="optional"}
>> uri: uri {use="optional"}
>>
>> While on this point, I have a general question: does the KeyValuePair need a <notes> element analogous to SBML notes element?
>>
>> notes: xmlns: string {"http://www.w3.org/1999/xhtml"}
>>
>> Does that make things clearer? If this works, I will update the proposal appropriately.
>>
>> Best regards
>> Brett
>>
>>>> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux <sbm...@li...>
>>>> :
>>>>
>>>> Dear Matthias and members of the FBC working group
>>>>
>>>> The extensions and modifications contained in this document are proposed as version 3 of the Flux Balance Constraints package. This proposal is been formulated through open discussions on this list and intense discussion during HARMONY 2018.
>>>>
>>>> The proposed Flux Balance Constraints package version 3:
>>>>
>>>> 	• extends the definition of the FluxObjective allowing both linear and quadratic variables
>>>> 	• extends the definition of the chemicalFormula
>>>> 	• extends the definition of charge to allow it to be a double
>>>> 	• adds an element that allows the definition of a non-stoichiometric UserConstraints
>>>> 	• adds a definition for a generic KeyValuePair annotation.
>>>> The proposed changes have been summarized as a standalone PDF:
>>>>
>>>>
>>>> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
>>>>
>>>>
>>>> All comments and welcome: including are these topics relevant to FBC, do the proposed solutions solve known current model encoding problems, are there tools that provide support for (or would be able to support) the extended functionality proposed here?
>>>>
>>>> Sent on behalf of all the participants in the ongoing discussion.
>>>>
>>>> Best regards
>>>> Brett
>>>>
>>>>
>>>> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
>>>>
>>>>
>>>>> @all It would be great if we could finish the L3 fbc package.
>>>>> There aren't too many proposed changes, but they will solve a multitude of issues occurring in the constrainted-based modelling community. The proposed UserConstraints and KeyValuePairs are both very versatile and useful additions and it would be great if we could use these in fbc models.
>>>>> Bret, Thomas, Lucian, me and others discussed a lot during HARMONY to find a solution which could work for everyone (and found an agreement which would work for the people at HARMONY). But we need input/feedback from the community to get this moving.
>>>>> Please take half an hour of your time to read over the few pages and provide your feedback
>>>>>
>>>> --
>>>>
>>>> Brett G. Olivier PhD
>>>>
>>>> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
>>>> Modeling of Biological Processes, BioQUANT/COS, Heidelberg University, Germany
>>>>
>>> With best regards
>>>
>>> Dr. Andreas Draeger
>>>
>> -- 
>> Brett G. Olivier
> With best regards
>
> Dr. Andreas Draeger
> Assistant Professor
> ---
> University of Tübingen
> Center for Bioinformatics Tübingen (ZBIT)
> Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
> Sand 14 · Office #C320 · 72076 Tübingen · Germany
> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
> Web: http://draeger-lab.org · Twitter: @dr_drae
> YouTube: https://www.youtube.com/c/systemsbiology
>
-- 
Brett G. Olivier PhD

Data Steward (O2|1W09) (b.g...@vu...)
Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands

Re: [sbml-flux] [sbml-discuss] Storing gene expression values in SBML

[Andreas D. <and...@un...>]

Dear Miguel and Robert,

Thanks for starting this discussion; context-specific models are becoming an essential topic and improved support for their standardized development is therefore indispensable.

I am adding the FBC mailing list to the list of recipients of this e-mail because the geneProduct information and so-called gene-protein-reaction (GPR) rules are defined in this extension package for SBML rather than in the core. From my perspective, it makes sense to continue discussing this issue on the more specific mailing list.

As I understand it, you would like to add gene expression data to the model and thus create an array of structurally identically models that differ only in the expression levels of specific gene products. Please note that maintenance of such an array of nearly identical models can be complicated in the long term because changes and updates to specific processes need to be synchronized across many or even all models. It is, therefore, probably better to have just one general model (or just a hand full of them) that is put into context when evaluated with respect to given data.

A few projects to encode numerical values with relevance to biology have been launched, such as the Systems Biology Result Markup Language (SBRML) and NuML (Numerical values Markup Language). Maybe somebody on this list can give an update on the current state of SBRML or NuML?

An idea could be to link numbers in these formats (e.g., NuML or SBRML, or similar) to the SBML file and wrap them all in a COMBINE archive together with a SED-ML file that specifies how to run the simulation. In this way, the SBML file could continue to be restricted to the actual model, separate from specific measurement or evaluation details, i.e., we would have a general model that becomes context-specific when evaluated with respect to the data files, rather than having an array of context-specific model variants.

For first tests, however, a quick solution could be to define a custom annotation for the geneProduct objects in the FBC package that you could parse out and write additional numerical values there. This approach would require some implementation work and possibly a change in how you run the simulation. Besides, it would not be compatible with other tools. However, this could perhaps lead to the development of an extended standard, for instance, in the form of a new package for gene expression values or similar.

Cheers
Andreas


> Am 23.06.2019 um 01:26 schrieb Robert Phair <rp...@in...>:
> 
> If we limit our discussion to enzymatically catalyzed reactions and transport processes mediated by integral membrane proteins, and if we assume those enzymes and transporters are, themselves, species in your CSM that act as modifiers of the target reaction, then the gene expression data (transcripts per million, say) could be stored in the initial value attribute for the species. You will also have, I suppose, some mapping from this TPM value to the abundance of the corresponding protein, enzyme or transporter. This mapping could be included in the kinetic law for the corresponding reaction by partitioning the Vmax into its component parts, protein abundance and turnover number. Obviously this involves many assumptions, but everyone recognizes that quantifying large numbers of mRNAs is far easier than quantifying the corresponding proteins and their post-translational modifications.
> 
> Regards,
> Robert D Phair PhD  |  Chief Science Officer  |  Integrative Bioinformatics Inc
> Mountain View, CA, USA
> www.integrativebioinformatics.com
> 
> ProcessDB: Mechanistic modeling for systems biology
> 
> 
> On Sat, Jun 22, 2019 at 2:36 PM Miguel Ponce de Leon <mig...@gm...> wrote:
> Hi everyone,
> 
> I've been working in constraint-based metabolic modeling for a while and more recently I've started to work with context-specific models (CSM) as well with model-extraction methods, to study cancer metabolism.
> 
> In order to extract a CSM from a references model such as Recon2.2 or Recon3D an omic data set, in general gene expression, is used to identity active reactions. This mapping step is performed using the so called gene-protein-reaction (GPR) rules. Finally an optimization procedure, commonly referred as the model-extraction method (e.g. GIMME, INIT; FASCORE; CORDA) is used to extract a submodel which contains those reaction identified as active as well some other reaction needed to fill gaps. Recently, we have found that in virtually all available model-extraction methods the GPRs are not contextualized in the produced model, which means that when the model is stored part of the context is lost (see for further details: https://www.biorxiv.org/content/10.1101/593277v1.abstract). Moreover, the genes' expression used to reconstruct the CSM are generally not provided, which prevent other users to know which genes were treated as expressed and which were considered as not expressed. Altogether, this flaw affect the predictive capabilities of the CSMs, especially in the case of performing in-silico gene knockouts.
> 
> My collaborators and I have been working on this issue and come to the idea that the sbml standard could support the storage of these information, that is to say that when a CSM is generated the gene expression values are also stored in the sbml file; in the same way that reactions has an attribute to store flux, or metabolites to store a concentration it would be very useful to have a gene attribute to store expression value (e.g. TPM, FPMK) to provide a user of such model the needed information to perform correct simulations.
> 
> I do not know if the current SBML standard support such capability. If the answer is affirmative, we would like to know the correct way to store gene expression in an SBML. If the storage of gene expression is currently not supported by the SBML standard we would like to bring this possibility into the future releases.
> 
> Best regards,
> Miguel Ponce-de-Leon
> Life Science Department - Barcelona Supercomputing Center

With best regards

Dr. Andreas Draeger
Assistant Professor
---
University of Tübingen
Institute for Biomedical Informatics (IBMI)
Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
Sand 14 · Office #C320 · 72076 Tübingen · Germany
Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
Web: http://systems-biology.info · Twitter: @dr_drae
YouTube: https://www.youtube.com/c/systemsbiology

[sbml-flux] Introductory Email for Project ModelPolisher.

[Kaustubh T. <kau...@gm...>]

Dear all,

I am Kaustubh Trivedi, a student at Indian Institute of Technology,
Roorkee, India (IITR) pursuing Bachelors in Computer Science and
Engineering, who recently completed the second year.

I have recently been selected as a student in GSoC 2019 under the open
source organization National Resource for Network Biology
<https://nrnb.org/> (NRNB). I will be working on the project - "Extending
ModelPolisher to a universal annotation tool
<https://summerofcode.withgoogle.com/projects/#5081704266465280>" under my
mentors, Thomas Jakob Zajac, Dr. Matthias König, and Jun.-Prof. Dr. Andreas
Dräger.

ModelPolisher is a model annotation tool which uses the BiGG Models
Knowledgebase. My project aims towards extending ModelPolisher annotation
capabilities for models lacking BiGG IDs, producing separate glossary files
and embedding them in COMBINE archive, containerization of ModelPolisher,
and updating ModelPolisher to software development standards.

I hope I would have been able to give a basic introduction to the project.
I will try to keep the community updated through blogs. Further, feel free
to contact me in case of any queries or concerns.

Weekly blog posts: https://kt-gsoc19.blogspot.com
LinkedIn: https://www.linkedin.com/in/kaustubh-trivedi/

Project on GitHub: https://github.com/draeger-lab/ModelPolisher/

With best regards,
Kaustubh Trivedi
IIT ROORKEE CSE
(ktr...@cs...)

Re: [sbml-flux] FBC version 3 proposal (new document)

[Brett G. O. <b.g...@vu...>]

On 07-Mar-19 10:20 AM, Nicolas Rodriguez wrote:
> On 07/03/2019 08:41, Matthias König via sbml-flux wrote:
>> Hi all,
>> I just stumbled across the following for strict models in the spec:
>> - A ReactionlowerFluxBoundattribute may not point to a Parameter with 
>> a value of “INF”
>> - A ReactionupperFluxBoundattribute may not point to a Parameter with 
>> a value of “-INF”
>>
>> Why is this in the specification? This enforces to set arbitrary 
>> upper and lower bounds on unrestricted reactions, which is just 
>> incorrect.
>> A reaction with -INF <= v <= INF is completely valid (and is a 
>> completely valid LP problem). Forcing arbitrary reaction bounds on 
>> model reactions is in my opinion very bad, and alters the possible 
>> solution space.
>
>
> From my understanding, [-INF, INF] is not forbidden but things like 
> [0, -INF], [-INF, -INF] or [INF, 0].
>
Yes, NIcolas is correct it was decided that that allowing these values 
would allow inconsistent bounds, for example what could a double value 
of X or Y be in:

  * INF <= X
  * Y <= -INF

The restrictions you mentioned were put in place precisely to avoid 
inconsistent values being used in FluxBounds.

>>
>> Can we remove this restriction for fbc-v3 strict models, which 
>> creates more problems than it solves?
>> The whole idea of the strict tag was to enforce a valid LP problem. 
>> Having [-INF, INF] bounds creates a valid LP problem so I personally 
>> don't understand this rule at all. As I understand it the [-Inf, Inf] 
>> should not add any constraint on the fluxes, so basically all solvers 
>> will support it, i.e. the following should happen when generating the 
>> LP problem
>>
>>   * for |[lb <= v <= ub]| the constraint |lb <= v <= ub| should be added
>>   * for |[lb <= v <= INF]| the constraint |lb <= v| should be added
>>   * for |[-INF <= v <= ub]| the constraint |v <= ub| should be added
>>   * for |[-INF <= v <= INF]| no constraint is added
>>
>> Nowhere is there support for INF, -INF in solvers required.

Incorrect, I know that CPLEX uses +-INF (I use it explicitly as such) 
and would be surprised if Gurobi didn't as well. I don't see the need 
for any change.

Best regards
Brett


>>
>> I suggest we remove the following strict rules from fbc-v3 which 
>> don't provide any value, but on the contrary create may problems by 
>> adding arbitrary (unbiological) constraints to fbc models
>> - A ReactionlowerFluxBoundattribute may not point to a Parameter with 
>> a value of “INF”
>> - A ReactionupperFluxBoundattribute may not point to a Parameter with 
>> a value of “-INF”
>>
>> Best Matthias
>>
>> On Wed, Mar 6, 2019 at 9:04 AM Andreas Dräger 
>> <and...@un... 
>> <mailto:and...@un...>> wrote:
>>
>>     Hi Brett,
>>
>>     Alternatively, you could also define an abstract FBCBase object
>>     that has a ListOfKeyValuePairs. Then, every object defined in the
>>     FBC specification could inherit from FBCBase and therefore be
>>     automatically equipped with that list. In this way, the key-value
>>     pairs and their list could continue to be derived from SBase,
>>     they could be attached to any FBC object, and it wouldn't be
>>     necessary to move them to the annotation block. It seems to me
>>     this would simplify the implementation and solve some of the
>>     problems.
>>
>>     Cheers
>>     Andreas
>>
>>
>>     > Am 05.03.2019 um 22:40 schrieb Brett G. Olivier via sbml-flux
>>     <sbm...@li...
>>     <mailto:sbm...@li...>>:
>>     >
>>     > Dear Andreas
>>     >
>>     > Thanks for your comments, both here and in the PDF, they are
>>     much appreciated. For now, a quick comment on the KeyValuePair
>>     annotation.
>>     >
>>     > On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
>>     >> Dear package working group,
>>     >>
>>     >> Thanks to all contributors of the new specification draft,
>>     Brett in particular, for putting this together. It is great to
>>     see this new development including several promising new features
>>     and improvements. I have a few remarks that we can, hopefully,
>>     discuss in person during HARMONY soon.
>>     >>
>>     >> Fig 10:
>>     >>
>>     >> When viewing this image, it is first not clear where the list
>>     of key-value pairs is going to be placed in the model because in
>>     contrast to all other lists, there is no "has" relationship type
>>     arrow. Only the inheritance relationship to SBase is indicated.
>>     Later in the text this becomes clearer. Maybe a comment in the
>>     caption could help saying that this list goes to the annotation.
>>     It is generally interesting that this list goes to the
>>     annotation, because it is an SBase and therefore may have an
>>     annotation and notes subelement itself. Is this intended? It
>>     essentially implies a nesting of annotations and list objects. Is
>>     there any specific reason why this is not simply a subelement of
>>     the extended model?
>>     >>
>>     > Good catch, indeed this element has moved around in the model
>>     and the UML and text has not caught up. The current idea is that
>>     the KeyValuePair and associated list is *not* an SBase derived
>>     element but should have the same "standardised format" status as
>>     the SBML RDF annotation.
>>     >
>>     > Doing it this way, not only has the advantage of not having to
>>     extend SBase (and open up a whole bunch of potential
>>     implementation issues) but also avoids the the annotation nesting
>>     problem you highlight. My feeling is such annotation nesting
>>     needs to be avoided and the KeyValuePair should be an annotation
>>     element that has the attributes:
>>     >
>>     > id: SId {use="optional"}
>>     > name: string {use="optional"}
>>     > key: string
>>     > value: string {use="optional"}
>>     > uri: uri {use="optional"}
>>     >
>>     > While on this point, I have a general question: does the
>>     KeyValuePair need a <notes> element analogous to SBML notes element?
>>     >
>>     > notes: xmlns: string {"http://www.w3.org/1999/xhtml"}
>>     >
>>     > Does that make things clearer? If this works, I will update the
>>     proposal appropriately.
>>     >
>>     > Best regards
>>     > Brett
>>     >
>>     >>> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux
>>     <sbm...@li...
>>     <mailto:sbm...@li...>>
>>     >>> :
>>     >>>
>>     >>> Dear Matthias and members of the FBC working group
>>     >>>
>>     >>> The extensions and modifications contained in this document
>>     are proposed as version 3 of the Flux Balance Constraints
>>     package. This proposal is been formulated through open
>>     discussions on this list and intense discussion during HARMONY 2018.
>>     >>>
>>     >>> The proposed Flux Balance Constraints package version 3:
>>     >>>
>>     >>>     • extends the definition of the FluxObjective allowing
>>     both linear and quadratic variables
>>     >>>     • extends the definition of the chemicalFormula
>>     >>>     • extends the definition of charge to allow it to be a double
>>     >>>     • adds an element that allows the definition of a
>>     non-stoichiometric UserConstraints
>>     >>>     • adds a definition for a generic KeyValuePair annotation.
>>     >>> The proposed changes have been summarized as a standalone PDF:
>>     >>>
>>     >>>
>>     >>>
>>     https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
>>     >>>
>>     >>>
>>     >>> All comments and welcome: including are these topics relevant
>>     to FBC, do the proposed solutions solve known current model
>>     encoding problems, are there tools that provide support for (or
>>     would be able to support) the extended functionality proposed here?
>>     >>>
>>     >>> Sent on behalf of all the participants in the ongoing discussion.
>>     >>>
>>     >>> Best regards
>>     >>> Brett
>>     >>>
>>     >>>
>>     >>> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
>>     >>>
>>     >>>
>>     >>>> @all It would be great if we could finish the L3 fbc package.
>>     >>>> There aren't too many proposed changes, but they will solve
>>     a multitude of issues occurring in the constrainted-based
>>     modelling community. The proposed UserConstraints and
>>     KeyValuePairs are both very versatile and useful additions and it
>>     would be great if we could use these in fbc models.
>>     >>>> Bret, Thomas, Lucian, me and others discussed a lot during
>>     HARMONY to find a solution which could work for everyone (and
>>     found an agreement which would work for the people at HARMONY).
>>     But we need input/feedback from the community to get this moving.
>>     >>>> Please take half an hour of your time to read over the few
>>     pages and provide your feedback
>>     >>>>
>>     >>> --
>>     >>>
>>     >>> Brett G. Olivier PhD
>>     >>>
>>     >>> Systems Bioinformatics, Amsterdam Institute for Molecules,
>>     Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
>>     >>> Modeling of Biological Processes, BioQUANT/COS, Heidelberg
>>     University, Germany
>>     >>>
>>     >> With best regards
>>     >>
>>     >> Dr. Andreas Draeger
>>     >>
>>     > --
>>     > Brett G. Olivier
>>
>>     With best regards
>>
>>     Dr. Andreas Draeger
>>     Assistant Professor
>>     ---
>>     University of Tübingen
>>     Center for Bioinformatics Tübingen (ZBIT)
>>     Computational Systems Biology of Infection and
>>     Antimicrobial-Resistant Pathogens
>>     Sand 14 · Office #C320 · 72076 Tübingen · Germany
>>     Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
>>     Web: http://draeger-lab.org · Twitter: @dr_drae
>>     YouTube: https://www.youtube.com/c/systemsbiology
>>
>>     _______________________________________________
>>     sbml-flux mailing list
>>     sbm...@li...
>>     <mailto:sbm...@li...>
>>     https://lists.sourceforge.net/lists/listinfo/sbml-flux
>>
>>
>>
>> -- 
>> Matthias König, PhD.
>> Junior Group Leader LiSyM - Systems Medicine of the Liver
>> Humboldt Universität zu Berlin, Institute of Biology, Institute for 
>> Theoretical Biology
>> https://livermetabolism.com
>> kon...@go... <mailto:kon...@go...>
>> https://twitter.com/konigmatt
>> https://github.com/matthiaskoenig
>> Tel: +49 30 2093 98435
>>
>>
>> _______________________________________________
>> sbml-flux mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-flux

-- 
Brett G. Olivier PhD

Data Steward (O2|1W09) (b.g...@vu...)
Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands

Research Associate
Modeling of Biological Processes, BioQUANT/COS, Heidelberg University, Germany

Re: [sbml-flux] FBC version 3 proposal (new document)

[Matthias K. <kon...@go...>]

Thanks. That makes sense. Got lost in the -INF and INF somewhere.
Nothing to do here. Everything solved.
Best M


On Thu, Mar 7, 2019 at 10:21 AM Nicolas Rodriguez <rod...@eb...>
wrote:

>
> On 07/03/2019 08:41, Matthias König via sbml-flux wrote:
>
> Hi all,
> I just stumbled across the following for strict models in the spec:
> - A ReactionlowerFluxBoundattribute may not point to a Parameter with a
> value of “INF”
> - A ReactionupperFluxBoundattribute may not point to a Parameter with a
> value of “-INF”
>
> Why is this in the specification? This enforces to set arbitrary upper and
> lower bounds on unrestricted reactions, which is just incorrect.
> A reaction with -INF <= v <= INF is completely valid (and is a completely
> valid LP problem). Forcing arbitrary reaction bounds on model reactions is
> in my opinion very bad, and alters the possible solution space.
>
>
> From my understanding, [-INF, INF] is not forbidden but things like [0,
> -INF], [-INF, -INF] or [INF, 0].
>
>
>
> Can we remove this restriction for fbc-v3 strict models, which creates
> more problems than it solves?
> The whole idea of the strict tag was to enforce a valid LP problem. Having
> [-INF, INF] bounds creates a valid LP problem so I personally don't
> understand this rule at all. As I understand it the [-Inf, Inf] should not
> add any constraint on the fluxes, so basically all solvers will support it,
> i.e. the following should happen when generating the LP problem
>
>    - for [lb <= v <= ub] the constraint lb <= v <= ub should be added
>    - for [lb <= v <= INF] the constraint lb <= v should be added
>    - for [-INF <= v <= ub] the constraint v <= ub should be added
>    - for [-INF <= v <= INF] no constraint is added
>
> Nowhere is there support for INF, -INF in solvers required.
>
> I suggest we remove the following strict rules from fbc-v3 which don't
> provide any value, but on the contrary create may problems by adding
> arbitrary (unbiological) constraints to fbc models
> - A ReactionlowerFluxBoundattribute may not point to a Parameter with a
> value of “INF”
> - A ReactionupperFluxBoundattribute may not point to a Parameter with a
> value of “-INF”
>
> Best Matthias
>
> On Wed, Mar 6, 2019 at 9:04 AM Andreas Dräger <
> and...@un...> wrote:
>
>> Hi Brett,
>>
>> Alternatively, you could also define an abstract FBCBase object that has
>> a ListOfKeyValuePairs. Then, every object defined in the FBC specification
>> could inherit from FBCBase and therefore be automatically equipped with
>> that list. In this way, the key-value pairs and their list could continue
>> to be derived from SBase, they could be attached to any FBC object, and it
>> wouldn't be necessary to move them to the annotation block. It seems to me
>> this would simplify the implementation and solve some of the problems.
>>
>> Cheers
>> Andreas
>>
>>
>> > Am 05.03.2019 um 22:40 schrieb Brett G. Olivier via sbml-flux <
>> sbm...@li...>:
>> >
>> > Dear Andreas
>> >
>> > Thanks for your comments, both here and in the PDF, they are much
>> appreciated. For now, a quick comment on the KeyValuePair annotation.
>> >
>> > On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
>> >> Dear package working group,
>> >>
>> >> Thanks to all contributors of the new specification draft, Brett in
>> particular, for putting this together. It is great to see this new
>> development including several promising new features and improvements. I
>> have a few remarks that we can, hopefully, discuss in person during HARMONY
>> soon.
>> >>
>> >> Fig 10:
>> >>
>> >> When viewing this image, it is first not clear where the list of
>> key-value pairs is going to be placed in the model because in contrast to
>> all other lists, there is no "has" relationship type arrow. Only the
>> inheritance relationship to SBase is indicated. Later in the text this
>> becomes clearer. Maybe a comment in the caption could help saying that this
>> list goes to the annotation. It is generally interesting that this list
>> goes to the annotation, because it is an SBase and therefore may have an
>> annotation and notes subelement itself. Is this intended? It essentially
>> implies a nesting of annotations and list objects. Is there any specific
>> reason why this is not simply a subelement of the extended model?
>> >>
>> > Good catch, indeed this element has moved around in the model and the
>> UML and text has not caught up. The current idea is that the KeyValuePair
>> and associated list is *not* an SBase derived element but should have the
>> same "standardised format" status as the SBML RDF annotation.
>> >
>> > Doing it this way, not only has the advantage of not having to extend
>> SBase (and open up a whole bunch of potential implementation issues) but
>> also avoids the the annotation nesting problem you highlight. My feeling is
>> such annotation nesting needs to be avoided and the KeyValuePair should be
>> an annotation element that has the attributes:
>> >
>> > id: SId {use="optional"}
>> > name: string {use="optional"}
>> > key: string
>> > value: string {use="optional"}
>> > uri: uri {use="optional"}
>> >
>> > While on this point, I have a general question: does the KeyValuePair
>> need a <notes> element analogous to SBML notes element?
>> >
>> > notes: xmlns: string {"http://www.w3.org/1999/xhtml"}
>> >
>> > Does that make things clearer? If this works, I will update the
>> proposal appropriately.
>> >
>> > Best regards
>> > Brett
>> >
>> >>> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux <
>> sbm...@li...>
>> >>> :
>> >>>
>> >>> Dear Matthias and members of the FBC working group
>> >>>
>> >>> The extensions and modifications contained in this document are
>> proposed as version 3 of the Flux Balance Constraints package. This
>> proposal is been formulated through open discussions on this list and
>> intense discussion during HARMONY 2018.
>> >>>
>> >>> The proposed Flux Balance Constraints package version 3:
>> >>>
>> >>>     • extends the definition of the FluxObjective allowing both
>> linear and quadratic variables
>> >>>     • extends the definition of the chemicalFormula
>> >>>     • extends the definition of charge to allow it to be a double
>> >>>     • adds an element that allows the definition of a
>> non-stoichiometric UserConstraints
>> >>>     • adds a definition for a generic KeyValuePair annotation.
>> >>> The proposed changes have been summarized as a standalone PDF:
>> >>>
>> >>>
>> >>>
>> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
>> >>>
>> >>>
>> >>> All comments and welcome: including are these topics relevant to FBC,
>> do the proposed solutions solve known current model encoding problems, are
>> there tools that provide support for (or would be able to support) the
>> extended functionality proposed here?
>> >>>
>> >>> Sent on behalf of all the participants in the ongoing discussion.
>> >>>
>> >>> Best regards
>> >>> Brett
>> >>>
>> >>>
>> >>> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
>> >>>
>> >>>
>> >>>> @all It would be great if we could finish the L3 fbc package.
>> >>>> There aren't too many proposed changes, but they will solve a
>> multitude of issues occurring in the constrainted-based modelling
>> community. The proposed UserConstraints and KeyValuePairs are both very
>> versatile and useful additions and it would be great if we could use these
>> in fbc models.
>> >>>> Bret, Thomas, Lucian, me and others discussed a lot during HARMONY
>> to find a solution which could work for everyone (and found an agreement
>> which would work for the people at HARMONY). But we need input/feedback
>> from the community to get this moving.
>> >>>> Please take half an hour of your time to read over the few pages and
>> provide your feedback
>> >>>>
>> >>> --
>> >>>
>> >>> Brett G. Olivier PhD
>> >>>
>> >>> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines
>> and Systems, Vrije Universiteit Amsterdam, The Netherlands
>> >>> Modeling of Biological Processes, BioQUANT/COS, Heidelberg
>> University, Germany
>> >>>
>> >> With best regards
>> >>
>> >> Dr. Andreas Draeger
>> >>
>> > --
>> > Brett G. Olivier
>>
>> With best regards
>>
>> Dr. Andreas Draeger
>> Assistant Professor
>> ---
>> University of Tübingen
>> Center for Bioinformatics Tübingen (ZBIT)
>> Computational Systems Biology of Infection and Antimicrobial-Resistant
>> Pathogens
>> Sand 14 · Office #C320 · 72076 Tübingen · Germany
>> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
>> Web: http://draeger-lab.org · Twitter: @dr_drae
>> YouTube: https://www.youtube.com/c/systemsbiology
>>
>> _______________________________________________
>> sbml-flux mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-flux
>>
>
>
> --
> Matthias König, PhD.
> Junior Group Leader LiSyM - Systems Medicine of the Liver
> Humboldt Universität zu Berlin, Institute of Biology, Institute for
> Theoretical Biology
>   https://livermetabolism.com
> kon...@go...
> https://twitter.com/konigmatt
> https://github.com/matthiaskoenig
> Tel: +49 30 2093 98435
>
>
> _______________________________________________
> sbml-flux mailing lis...@li...://lists.sourceforge.net/lists/listinfo/sbml-flux
>
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux
>


-- 
Matthias König, PhD.
Junior Group Leader LiSyM - Systems Medicine of the Liver
Humboldt Universität zu Berlin, Institute of Biology, Institute for
Theoretical Biology
  https://livermetabolism.com
kon...@go...
https://twitter.com/konigmatt
https://github.com/matthiaskoenig
Tel: +49 30 2093 98435

Re: [sbml-flux] FBC version 3 proposal (new document)

[Nicolas R. <rod...@eb...>]

On 07/03/2019 08:41, Matthias König via sbml-flux wrote:
> Hi all,
> I just stumbled across the following for strict models in the spec:
> - A ReactionlowerFluxBoundattribute may not point to a Parameter with 
> a value of “INF”
> - A ReactionupperFluxBoundattribute may not point to a Parameter with 
> a value of “-INF”
>
> Why is this in the specification? This enforces to set arbitrary upper 
> and lower bounds on unrestricted reactions, which is just incorrect.
> A reaction with -INF <= v <= INF is completely valid (and is a 
> completely valid LP problem). Forcing arbitrary reaction bounds on 
> model reactions is in my opinion very bad, and alters the possible 
> solution space.


 From my understanding, [-INF, INF] is not forbidden but things like [0, 
-INF], [-INF, -INF] or [INF, 0].


>
> Can we remove this restriction for fbc-v3 strict models, which creates 
> more problems than it solves?
> The whole idea of the strict tag was to enforce a valid LP problem. 
> Having [-INF, INF] bounds creates a valid LP problem so I personally 
> don't understand this rule at all. As I understand it the [-Inf, Inf] 
> should not add any constraint on the fluxes, so basically all solvers 
> will support it, i.e. the following should happen when generating the 
> LP problem
>
>   * for |[lb <= v <= ub]| the constraint |lb <= v <= ub| should be added
>   * for |[lb <= v <= INF]| the constraint |lb <= v| should be added
>   * for |[-INF <= v <= ub]| the constraint |v <= ub| should be added
>   * for |[-INF <= v <= INF]| no constraint is added
>
> Nowhere is there support for INF, -INF in solvers required.
>
> I suggest we remove the following strict rules from fbc-v3 which don't 
> provide any value, but on the contrary create may problems by adding 
> arbitrary (unbiological) constraints to fbc models
> - A ReactionlowerFluxBoundattribute may not point to a Parameter with 
> a value of “INF”
> - A ReactionupperFluxBoundattribute may not point to a Parameter with 
> a value of “-INF”
>
> Best Matthias
>
> On Wed, Mar 6, 2019 at 9:04 AM Andreas Dräger 
> <and...@un... 
> <mailto:and...@un...>> wrote:
>
>     Hi Brett,
>
>     Alternatively, you could also define an abstract FBCBase object
>     that has a ListOfKeyValuePairs. Then, every object defined in the
>     FBC specification could inherit from FBCBase and therefore be
>     automatically equipped with that list. In this way, the key-value
>     pairs and their list could continue to be derived from SBase, they
>     could be attached to any FBC object, and it wouldn't be necessary
>     to move them to the annotation block. It seems to me this would
>     simplify the implementation and solve some of the problems.
>
>     Cheers
>     Andreas
>
>
>     > Am 05.03.2019 um 22:40 schrieb Brett G. Olivier via sbml-flux
>     <sbm...@li...
>     <mailto:sbm...@li...>>:
>     >
>     > Dear Andreas
>     >
>     > Thanks for your comments, both here and in the PDF, they are
>     much appreciated. For now, a quick comment on the KeyValuePair
>     annotation.
>     >
>     > On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
>     >> Dear package working group,
>     >>
>     >> Thanks to all contributors of the new specification draft,
>     Brett in particular, for putting this together. It is great to see
>     this new development including several promising new features and
>     improvements. I have a few remarks that we can, hopefully, discuss
>     in person during HARMONY soon.
>     >>
>     >> Fig 10:
>     >>
>     >> When viewing this image, it is first not clear where the list
>     of key-value pairs is going to be placed in the model because in
>     contrast to all other lists, there is no "has" relationship type
>     arrow. Only the inheritance relationship to SBase is indicated.
>     Later in the text this becomes clearer. Maybe a comment in the
>     caption could help saying that this list goes to the annotation.
>     It is generally interesting that this list goes to the annotation,
>     because it is an SBase and therefore may have an annotation and
>     notes subelement itself. Is this intended? It essentially implies
>     a nesting of annotations and list objects. Is there any specific
>     reason why this is not simply a subelement of the extended model?
>     >>
>     > Good catch, indeed this element has moved around in the model
>     and the UML and text has not caught up. The current idea is that
>     the KeyValuePair and associated list is *not* an SBase derived
>     element but should have the same "standardised format" status as
>     the SBML RDF annotation.
>     >
>     > Doing it this way, not only has the advantage of not having to
>     extend SBase (and open up a whole bunch of potential
>     implementation issues) but also avoids the the annotation nesting
>     problem you highlight. My feeling is such annotation nesting needs
>     to be avoided and the KeyValuePair should be an annotation element
>     that has the attributes:
>     >
>     > id: SId {use="optional"}
>     > name: string {use="optional"}
>     > key: string
>     > value: string {use="optional"}
>     > uri: uri {use="optional"}
>     >
>     > While on this point, I have a general question: does the
>     KeyValuePair need a <notes> element analogous to SBML notes element?
>     >
>     > notes: xmlns: string {"http://www.w3.org/1999/xhtml"}
>     >
>     > Does that make things clearer? If this works, I will update the
>     proposal appropriately.
>     >
>     > Best regards
>     > Brett
>     >
>     >>> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux
>     <sbm...@li...
>     <mailto:sbm...@li...>>
>     >>> :
>     >>>
>     >>> Dear Matthias and members of the FBC working group
>     >>>
>     >>> The extensions and modifications contained in this document
>     are proposed as version 3 of the Flux Balance Constraints package.
>     This proposal is been formulated through open discussions on this
>     list and intense discussion during HARMONY 2018.
>     >>>
>     >>> The proposed Flux Balance Constraints package version 3:
>     >>>
>     >>>     • extends the definition of the FluxObjective allowing
>     both linear and quadratic variables
>     >>>     • extends the definition of the chemicalFormula
>     >>>     • extends the definition of charge to allow it to be a double
>     >>>     • adds an element that allows the definition of a
>     non-stoichiometric UserConstraints
>     >>>     • adds a definition for a generic KeyValuePair annotation.
>     >>> The proposed changes have been summarized as a standalone PDF:
>     >>>
>     >>>
>     >>>
>     https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
>     >>>
>     >>>
>     >>> All comments and welcome: including are these topics relevant
>     to FBC, do the proposed solutions solve known current model
>     encoding problems, are there tools that provide support for (or
>     would be able to support) the extended functionality proposed here?
>     >>>
>     >>> Sent on behalf of all the participants in the ongoing discussion.
>     >>>
>     >>> Best regards
>     >>> Brett
>     >>>
>     >>>
>     >>> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
>     >>>
>     >>>
>     >>>> @all It would be great if we could finish the L3 fbc package.
>     >>>> There aren't too many proposed changes, but they will solve a
>     multitude of issues occurring in the constrainted-based modelling
>     community. The proposed UserConstraints and KeyValuePairs are both
>     very versatile and useful additions and it would be great if we
>     could use these in fbc models.
>     >>>> Bret, Thomas, Lucian, me and others discussed a lot during
>     HARMONY to find a solution which could work for everyone (and
>     found an agreement which would work for the people at HARMONY).
>     But we need input/feedback from the community to get this moving.
>     >>>> Please take half an hour of your time to read over the few
>     pages and provide your feedback
>     >>>>
>     >>> --
>     >>>
>     >>> Brett G. Olivier PhD
>     >>>
>     >>> Systems Bioinformatics, Amsterdam Institute for Molecules,
>     Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
>     >>> Modeling of Biological Processes, BioQUANT/COS, Heidelberg
>     University, Germany
>     >>>
>     >> With best regards
>     >>
>     >> Dr. Andreas Draeger
>     >>
>     > --
>     > Brett G. Olivier
>
>     With best regards
>
>     Dr. Andreas Draeger
>     Assistant Professor
>     ---
>     University of Tübingen
>     Center for Bioinformatics Tübingen (ZBIT)
>     Computational Systems Biology of Infection and
>     Antimicrobial-Resistant Pathogens
>     Sand 14 · Office #C320 · 72076 Tübingen · Germany
>     Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
>     Web: http://draeger-lab.org · Twitter: @dr_drae
>     YouTube: https://www.youtube.com/c/systemsbiology
>
>     _______________________________________________
>     sbml-flux mailing list
>     sbm...@li...
>     <mailto:sbm...@li...>
>     https://lists.sourceforge.net/lists/listinfo/sbml-flux
>
>
>
> -- 
> Matthias König, PhD.
> Junior Group Leader LiSyM - Systems Medicine of the Liver
> Humboldt Universität zu Berlin, Institute of Biology, Institute for 
> Theoretical Biology
> https://livermetabolism.com
> kon...@go... <mailto:kon...@go...>
> https://twitter.com/konigmatt
> https://github.com/matthiaskoenig
> Tel: +49 30 2093 98435
>
>
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux

Re: [sbml-flux] FBC version 3 proposal (new document)

[Matthias K. <kon...@go...>]

Hi all,
I just stumbled across the following for strict models in the spec:
- A ReactionlowerFluxBoundattribute may not point to a Parameter with a
value of “INF”
- A ReactionupperFluxBoundattribute may not point to a Parameter with a
value of “-INF”

Why is this in the specification? This enforces to set arbitrary upper and
lower bounds on unrestricted reactions, which is just incorrect.
A reaction with -INF <= v <= INF is completely valid (and is a completely
valid LP problem). Forcing arbitrary reaction bounds on model reactions is
in my opinion very bad, and alters the possible solution space.

Can we remove this restriction for fbc-v3 strict models, which creates more
problems than it solves?
The whole idea of the strict tag was to enforce a valid LP problem. Having
[-INF, INF] bounds creates a valid LP problem so I personally don't
understand this rule at all. As I understand it the [-Inf, Inf] should not
add any constraint on the fluxes, so basically all solvers will support it,
i.e. the following should happen when generating the LP problem

   - for [lb <= v <= ub] the constraint lb <= v <= ub should be added
   - for [lb <= v <= INF] the constraint lb <= v should be added
   - for [-INF <= v <= ub] the constraint v <= ub should be added
   - for [-INF <= v <= INF] no constraint is added

Nowhere is there support for INF, -INF in solvers required.

I suggest we remove the following strict rules from fbc-v3 which don't
provide any value, but on the contrary create may problems by adding
arbitrary (unbiological) constraints to fbc models
- A ReactionlowerFluxBoundattribute may not point to a Parameter with a
value of “INF”
- A ReactionupperFluxBoundattribute may not point to a Parameter with a
value of “-INF”

Best Matthias

On Wed, Mar 6, 2019 at 9:04 AM Andreas Dräger <
and...@un...> wrote:

> Hi Brett,
>
> Alternatively, you could also define an abstract FBCBase object that has a
> ListOfKeyValuePairs. Then, every object defined in the FBC specification
> could inherit from FBCBase and therefore be automatically equipped with
> that list. In this way, the key-value pairs and their list could continue
> to be derived from SBase, they could be attached to any FBC object, and it
> wouldn't be necessary to move them to the annotation block. It seems to me
> this would simplify the implementation and solve some of the problems.
>
> Cheers
> Andreas
>
>
> > Am 05.03.2019 um 22:40 schrieb Brett G. Olivier via sbml-flux <
> sbm...@li...>:
> >
> > Dear Andreas
> >
> > Thanks for your comments, both here and in the PDF, they are much
> appreciated. For now, a quick comment on the KeyValuePair annotation.
> >
> > On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
> >> Dear package working group,
> >>
> >> Thanks to all contributors of the new specification draft, Brett in
> particular, for putting this together. It is great to see this new
> development including several promising new features and improvements. I
> have a few remarks that we can, hopefully, discuss in person during HARMONY
> soon.
> >>
> >> Fig 10:
> >>
> >> When viewing this image, it is first not clear where the list of
> key-value pairs is going to be placed in the model because in contrast to
> all other lists, there is no "has" relationship type arrow. Only the
> inheritance relationship to SBase is indicated. Later in the text this
> becomes clearer. Maybe a comment in the caption could help saying that this
> list goes to the annotation. It is generally interesting that this list
> goes to the annotation, because it is an SBase and therefore may have an
> annotation and notes subelement itself. Is this intended? It essentially
> implies a nesting of annotations and list objects. Is there any specific
> reason why this is not simply a subelement of the extended model?
> >>
> > Good catch, indeed this element has moved around in the model and the
> UML and text has not caught up. The current idea is that the KeyValuePair
> and associated list is *not* an SBase derived element but should have the
> same "standardised format" status as the SBML RDF annotation.
> >
> > Doing it this way, not only has the advantage of not having to extend
> SBase (and open up a whole bunch of potential implementation issues) but
> also avoids the the annotation nesting problem you highlight. My feeling is
> such annotation nesting needs to be avoided and the KeyValuePair should be
> an annotation element that has the attributes:
> >
> > id: SId {use="optional"}
> > name: string {use="optional"}
> > key: string
> > value: string {use="optional"}
> > uri: uri {use="optional"}
> >
> > While on this point, I have a general question: does the KeyValuePair
> need a <notes> element analogous to SBML notes element?
> >
> > notes: xmlns: string {"http://www.w3.org/1999/xhtml"}
> >
> > Does that make things clearer? If this works, I will update the proposal
> appropriately.
> >
> > Best regards
> > Brett
> >
> >>> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux <
> sbm...@li...>
> >>> :
> >>>
> >>> Dear Matthias and members of the FBC working group
> >>>
> >>> The extensions and modifications contained in this document are
> proposed as version 3 of the Flux Balance Constraints package. This
> proposal is been formulated through open discussions on this list and
> intense discussion during HARMONY 2018.
> >>>
> >>> The proposed Flux Balance Constraints package version 3:
> >>>
> >>>     • extends the definition of the FluxObjective allowing both linear
> and quadratic variables
> >>>     • extends the definition of the chemicalFormula
> >>>     • extends the definition of charge to allow it to be a double
> >>>     • adds an element that allows the definition of a
> non-stoichiometric UserConstraints
> >>>     • adds a definition for a generic KeyValuePair annotation.
> >>> The proposed changes have been summarized as a standalone PDF:
> >>>
> >>>
> >>>
> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
> >>>
> >>>
> >>> All comments and welcome: including are these topics relevant to FBC,
> do the proposed solutions solve known current model encoding problems, are
> there tools that provide support for (or would be able to support) the
> extended functionality proposed here?
> >>>
> >>> Sent on behalf of all the participants in the ongoing discussion.
> >>>
> >>> Best regards
> >>> Brett
> >>>
> >>>
> >>> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
> >>>
> >>>
> >>>> @all It would be great if we could finish the L3 fbc package.
> >>>> There aren't too many proposed changes, but they will solve a
> multitude of issues occurring in the constrainted-based modelling
> community. The proposed UserConstraints and KeyValuePairs are both very
> versatile and useful additions and it would be great if we could use these
> in fbc models.
> >>>> Bret, Thomas, Lucian, me and others discussed a lot during HARMONY to
> find a solution which could work for everyone (and found an agreement which
> would work for the people at HARMONY). But we need input/feedback from the
> community to get this moving.
> >>>> Please take half an hour of your time to read over the few pages and
> provide your feedback
> >>>>
> >>> --
> >>>
> >>> Brett G. Olivier PhD
> >>>
> >>> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines
> and Systems, Vrije Universiteit Amsterdam, The Netherlands
> >>> Modeling of Biological Processes, BioQUANT/COS, Heidelberg University,
> Germany
> >>>
> >> With best regards
> >>
> >> Dr. Andreas Draeger
> >>
> > --
> > Brett G. Olivier
>
> With best regards
>
> Dr. Andreas Draeger
> Assistant Professor
> ---
> University of Tübingen
> Center for Bioinformatics Tübingen (ZBIT)
> Computational Systems Biology of Infection and Antimicrobial-Resistant
> Pathogens
> Sand 14 · Office #C320 · 72076 Tübingen · Germany
> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
> Web: http://draeger-lab.org · Twitter: @dr_drae
> YouTube: https://www.youtube.com/c/systemsbiology
>
> _______________________________________________
> sbml-flux mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-flux
>


-- 
Matthias König, PhD.
Junior Group Leader LiSyM - Systems Medicine of the Liver
Humboldt Universität zu Berlin, Institute of Biology, Institute for
Theoretical Biology
  https://livermetabolism.com
kon...@go...
https://twitter.com/konigmatt
https://github.com/matthiaskoenig
Tel: +49 30 2093 98435

Re: [sbml-flux] FBC version 3 proposal (new document)

[Andreas D. <and...@un...>]

Hi Brett,

Alternatively, you could also define an abstract FBCBase object that has a ListOfKeyValuePairs. Then, every object defined in the FBC specification could inherit from FBCBase and therefore be automatically equipped with that list. In this way, the key-value pairs and their list could continue to be derived from SBase, they could be attached to any FBC object, and it wouldn't be necessary to move them to the annotation block. It seems to me this would simplify the implementation and solve some of the problems.

Cheers
Andreas


> Am 05.03.2019 um 22:40 schrieb Brett G. Olivier via sbml-flux <sbm...@li...>:
> 
> Dear Andreas
> 
> Thanks for your comments, both here and in the PDF, they are much appreciated. For now, a quick comment on the KeyValuePair annotation.
> 
> On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
>> Dear package working group,
>> 
>> Thanks to all contributors of the new specification draft, Brett in particular, for putting this together. It is great to see this new development including several promising new features and improvements. I have a few remarks that we can, hopefully, discuss in person during HARMONY soon.
>> 
>> Fig 10:
>> 
>> When viewing this image, it is first not clear where the list of key-value pairs is going to be placed in the model because in contrast to all other lists, there is no "has" relationship type arrow. Only the inheritance relationship to SBase is indicated. Later in the text this becomes clearer. Maybe a comment in the caption could help saying that this list goes to the annotation. It is generally interesting that this list goes to the annotation, because it is an SBase and therefore may have an annotation and notes subelement itself. Is this intended? It essentially implies a nesting of annotations and list objects. Is there any specific reason why this is not simply a subelement of the extended model?
>> 
> Good catch, indeed this element has moved around in the model and the UML and text has not caught up. The current idea is that the KeyValuePair and associated list is *not* an SBase derived element but should have the same "standardised format" status as the SBML RDF annotation. 
> 
> Doing it this way, not only has the advantage of not having to extend SBase (and open up a whole bunch of potential implementation issues) but also avoids the the annotation nesting problem you highlight. My feeling is such annotation nesting needs to be avoided and the KeyValuePair should be an annotation element that has the attributes:
> 
> id: SId {use="optional"}
> name: string {use="optional"}
> key: string
> value: string {use="optional"}
> uri: uri {use="optional"}
> 
> While on this point, I have a general question: does the KeyValuePair need a <notes> element analogous to SBML notes element?
> 
> notes: xmlns: string {"http://www.w3.org/1999/xhtml"}
> 
> Does that make things clearer? If this works, I will update the proposal appropriately.
> 
> Best regards
> Brett
> 
>>> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux <sbm...@li...>
>>> :
>>> 
>>> Dear Matthias and members of the FBC working group
>>> 
>>> The extensions and modifications contained in this document are proposed as version 3 of the Flux Balance Constraints package. This proposal is been formulated through open discussions on this list and intense discussion during HARMONY 2018.
>>> 
>>> The proposed Flux Balance Constraints package version 3:
>>> 
>>> 	• extends the definition of the FluxObjective allowing both linear and quadratic variables
>>> 	• extends the definition of the chemicalFormula
>>> 	• extends the definition of charge to allow it to be a double
>>> 	• adds an element that allows the definition of a non-stoichiometric UserConstraints 
>>> 	• adds a definition for a generic KeyValuePair annotation.
>>> The proposed changes have been summarized as a standalone PDF:
>>> 
>>> 
>>> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
>>> 
>>> 
>>> All comments and welcome: including are these topics relevant to FBC, do the proposed solutions solve known current model encoding problems, are there tools that provide support for (or would be able to support) the extended functionality proposed here?
>>> 
>>> Sent on behalf of all the participants in the ongoing discussion.
>>> 
>>> Best regards
>>> Brett
>>> 
>>> 
>>> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
>>> 
>>> 
>>>> @all It would be great if we could finish the L3 fbc package. 
>>>> There aren't too many proposed changes, but they will solve a multitude of issues occurring in the constrainted-based modelling community. The proposed UserConstraints and KeyValuePairs are both very versatile and useful additions and it would be great if we could use these in fbc models.
>>>> Bret, Thomas, Lucian, me and others discussed a lot during HARMONY to find a solution which could work for everyone (and found an agreement which would work for the people at HARMONY). But we need input/feedback from the community to get this moving.
>>>> Please take half an hour of your time to read over the few pages and provide your feedback
>>>> 
>>> --
>>> 
>>> Brett G. Olivier PhD
>>> 
>>> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
>>> Modeling of Biological Processes, BioQUANT/COS, Heidelberg University, Germany
>>> 
>> With best regards
>> 
>> Dr. Andreas Draeger
>> 
> -- 
> Brett G. Olivier

With best regards

Dr. Andreas Draeger
Assistant Professor
---
University of Tübingen
Center for Bioinformatics Tübingen (ZBIT)
Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
Sand 14 · Office #C320 · 72076 Tübingen · Germany
Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
Web: http://draeger-lab.org · Twitter: @dr_drae
YouTube: https://www.youtube.com/c/systemsbiology

Re: [sbml-flux] FBC version 3 proposal (new document)

[Brett G. O. <b.g...@vu...>]

Dear Andreas

Thanks for your comments, both here and in the PDF, they are much 
appreciated. For now, a quick comment on the KeyValuePair annotation.

On 05-Mar-19 5:41 PM, Andreas Dräger wrote:
> Dear package working group,
>
> Thanks to all contributors of the new specification draft, Brett in particular, for putting this together. It is great to see this new development including several promising new features and improvements. I have a few remarks that we can, hopefully, discuss in person during HARMONY soon.
>
> Fig 10:
>
> When viewing this image, it is first not clear where the list of key-value pairs is going to be placed in the model because in contrast to all other lists, there is no "has" relationship type arrow. Only the inheritance relationship to SBase is indicated. Later in the text this becomes clearer. Maybe a comment in the caption could help saying that this list goes to the annotation. It is generally interesting that this list goes to the annotation, because it is an SBase and therefore may have an annotation and notes subelement itself. Is this intended? It essentially implies a nesting of annotations and list objects. Is there any specific reason why this is not simply a subelement of the extended model?

Good catch, indeed this element has moved around in the model and the 
UML and text has not caught up. The current idea is that the 
KeyValuePair and associated list is *not* an SBase derived element but 
should have the same "standardised format" status as the SBML RDF 
annotation.

Doing it this way, not only has the advantage of not having to extend 
SBase (and open up a whole bunch of potential implementation issues) but 
also avoids the the annotation nesting problem you highlight. My feeling 
is such annotation nesting needs to be avoided and the KeyValuePair 
should be an annotation element that has the attributes:

id: SId {use="optional"}
name: string {use="optional"}
key: string
value: string {use="optional"}
uri: uri {use="optional"}

While on this point, I have a general question: does the KeyValuePair 
need a <notes> element analogous to SBML notes element?

notes: xmlns: string {"http://www.w3.org/1999/xhtml"}

Does that make things clearer? If this works, I will update the proposal 
appropriately.

Best regards
Brett

>> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux <sbm...@li...>:
>>
>> Dear Matthias and members of the FBC working group
>>
>> The extensions and modifications contained in this document are proposed as version 3 of the Flux Balance Constraints package. This proposal is been formulated through open discussions on this list and intense discussion during HARMONY 2018.
>>
>> The proposed Flux Balance Constraints package version 3:
>>
>> 	• extends the definition of the FluxObjective allowing both linear and quadratic variables
>> 	• extends the definition of the chemicalFormula
>> 	• extends the definition of charge to allow it to be a double
>> 	• adds an element that allows the definition of a non-stoichiometric UserConstraints
>> 	• adds a definition for a generic KeyValuePair annotation.
>> The proposed changes have been summarized as a standalone PDF:
>>
>> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
>>
>> All comments and welcome: including are these topics relevant to FBC, do the proposed solutions solve known current model encoding problems, are there tools that provide support for (or would be able to support) the extended functionality proposed here?
>>
>> Sent on behalf of all the participants in the ongoing discussion.
>>
>> Best regards
>> Brett
>>
>>
>> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
>>
>>> @all It would be great if we could finish the L3 fbc package.
>>> There aren't too many proposed changes, but they will solve a multitude of issues occurring in the constrainted-based modelling community. The proposed UserConstraints and KeyValuePairs are both very versatile and useful additions and it would be great if we could use these in fbc models.
>>> Bret, Thomas, Lucian, me and others discussed a lot during HARMONY to find a solution which could work for everyone (and found an agreement which would work for the people at HARMONY). But we need input/feedback from the community to get this moving.
>>> Please take half an hour of your time to read over the few pages and provide your feedback
>> --
>>
>> Brett G. Olivier PhD
>>
>> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
>> Modeling of Biological Processes, BioQUANT/COS, Heidelberg University, Germany
> With best regards
>
> Dr. Andreas Draeger
> Assistant Professor
> ---
> University of Tübingen
> Center for Bioinformatics Tübingen (ZBIT)
> Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
> Sand 14 · Office #C320 · 72076 Tübingen · Germany
> Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
> Web: http://draeger-lab.org · Twitter: @dr_drae
> YouTube: https://www.youtube.com/c/systemsbiology
>
-- 
Brett G. Olivier
  

Re: [sbml-flux] FBC version 3 proposal (new document)

[Andreas D. <and...@un...>]

Dear package working group,

Thanks to all contributors of the new specification draft, Brett in particular, for putting this together. It is great to see this new development including several promising new features and improvements. I have a few remarks that we can, hopefully, discuss in person during HARMONY soon.

Fig 10:

When viewing this image, it is first not clear where the list of key-value pairs is going to be placed in the model because in contrast to all other lists, there is no "has" relationship type arrow. Only the inheritance relationship to SBase is indicated. Later in the text this becomes clearer. Maybe a comment in the caption could help saying that this list goes to the annotation. It is generally interesting that this list goes to the annotation, because it is an SBase and therefore may have an annotation and notes subelement itself. Is this intended? It essentially implies a nesting of annotations and list objects. Is there any specific reason why this is not simply a subelement of the extended model?

Minor: The extended species definition could be shifted down in the UML diagram. There seems to be enough space on the top right and it would be more intuitive for beholders if the outgoing arrow could be pointing up instead of down.

Section 4.2:

When the updated charge attribute is introduced an explanation is given "in terms of electrons," which I think, should better be "electron counts" to more clearly discriminate the integer nature of these objects from the double-valued charge attribute.

Smaller typos:
For the sake of reducing traffic through this list, I am sending separately an annotated PDF directly to Brett, which highlights some smaller typos for easier correction.

I hope these comments are helpful for this discussion.

Best wishes
Andreas



> Am 05.02.2019 um 14:52 schrieb Brett G. Olivier via sbml-flux <sbm...@li...>:
> 
> Dear Matthias and members of the FBC working group
> 
> The extensions and modifications contained in this document are proposed as version 3 of the Flux Balance Constraints package. This proposal is been formulated through open discussions on this list and intense discussion during HARMONY 2018.
> 
> The proposed Flux Balance Constraints package version 3:
> 
> 	• extends the definition of the FluxObjective allowing both linear and quadratic variables
> 	• extends the definition of the chemicalFormula
> 	• extends the definition of charge to allow it to be a double
> 	• adds an element that allows the definition of a non-stoichiometric UserConstraints 
> 	• adds a definition for a generic KeyValuePair annotation.
> The proposed changes have been summarized as a standalone PDF:
> 
> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw
> 
> All comments and welcome: including are these topics relevant to FBC, do the proposed solutions solve known current model encoding problems, are there tools that provide support for (or would be able to support) the extended functionality proposed here?
> 
> Sent on behalf of all the participants in the ongoing discussion.
> 
> Best regards
> Brett
> 
> 
> On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:
> 
>> @all It would be great if we could finish the L3 fbc package. 
>> There aren't too many proposed changes, but they will solve a multitude of issues occurring in the constrainted-based modelling community. The proposed UserConstraints and KeyValuePairs are both very versatile and useful additions and it would be great if we could use these in fbc models.
>> Bret, Thomas, Lucian, me and others discussed a lot during HARMONY to find a solution which could work for everyone (and found an agreement which would work for the people at HARMONY). But we need input/feedback from the community to get this moving.
>> Please take half an hour of your time to read over the few pages and provide your feedback
> 
> --
> 
> Brett G. Olivier PhD
> 
> Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines and Systems, Vrije Universiteit Amsterdam, The Netherlands
> Modeling of Biological Processes, BioQUANT/COS, Heidelberg University, Germany

With best regards

Dr. Andreas Draeger
Assistant Professor
---
University of Tübingen
Center for Bioinformatics Tübingen (ZBIT)
Computational Systems Biology of Infection and Antimicrobial-Resistant Pathogens
Sand 14 · Office #C320 · 72076 Tübingen · Germany
Phone: +49-7071-29-70459 · Fax: +49-7071-29-5152
Web: http://draeger-lab.org · Twitter: @dr_drae
YouTube: https://www.youtube.com/c/systemsbiology

[sbml-flux] Fwd: FBC version 3 proposal (new document)

[Ronan M.T. F. <ron...@gm...>]

Dear COBRA Toolbox users,

consider to review and comment on version 3 of the Flux Balance Constraints
package. We all need standards, which improve in proportion to user input.

Regards,

Ronan

---------- Forwarded message ---------
From: Brett G. Olivier via sbml-flux <sbm...@li...>
Date: Tue, 5 Feb 2019 at 14:06
Subject: [sbml-flux] FBC version 3 proposal (new document)
To: The SBML L3 Flux Balance Constraints package discussion list <
sbm...@li...>
Cc: Brett G. Olivier <b.g...@vu...>


Dear Matthias and members of the FBC working group

The extensions and modifications contained in this document are proposed as
version 3 of the Flux Balance Constraints package. This proposal is been
formulated through open discussions on this list and intense discussion
during HARMONY 2018.

The proposed Flux Balance Constraints package version 3:

   - extends the definition of the *FluxObjective* allowing both linear and
   quadratic variables
   - extends the definition of the *chemicalFormula*
   - extends the definition of *charge* to allow it to be a double
   - adds an element that allows the definition of a non-stoichiometric
   *UserConstraints*
   - adds a definition for a generic *KeyValuePair* annotation.

The proposed changes have been summarized as a standalone PDF:

https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/fbc/spec/harmony2018-proposal-fbc-v3.pdf?format=raw

All comments and welcome: including are these topics relevant to FBC, do
the proposed solutions solve known current model encoding problems, are
there tools that provide support for (or would be able to support) the
extended functionality proposed here?

Sent on behalf of all the participants in the ongoing discussion.

Best regards
Brett


On 03-Jan-19 6:22 PM, Matthias König via sbml-flux wrote:

@all It would be great if we could finish the L3 fbc package.
There aren't too many proposed changes, but they will solve a multitude of
issues occurring in the constrainted-based modelling community. The
proposed UserConstraints and KeyValuePairs are both very versatile and
useful additions and it would be great if we could use these in fbc models.
Bret, Thomas, Lucian, me and others discussed a lot during HARMONY to find
a solution which could work for everyone (and found an agreement which
would work for the people at HARMONY). But we need input/feedback from the
community to get this moving.
Please take half an hour of your time to read over the few pages and
provide your feedback


--

Brett G. Olivier PhD

Systems Bioinformatics, Amsterdam Institute for Molecules, Medicines
and Systems, Vrije Universiteit Amsterdam, The Netherlands
Modeling of Biological Processes, BioQUANT/COS, Heidelberg University, Germany


_______________________________________________
sbml-flux mailing list
sbm...@li...
https://lists.sourceforge.net/lists/listinfo/sbml-flux


-- 
--
Mr. Ronan MT Fleming B.V.M.S. Dip. Math. Ph.D.
----------------------------------------------------------------------------
Assistant Professor,
Division of Systems Biomedicine and Pharmacology,
Leiden Academic Centre for Drug Research,
Faculty of Science,
Leiden University.
https://www.universiteitleiden.nl/en/staffmembers/ronan-fleming
&
H2020 Project Coordinator
Systems Medicine of Mitochondrial Parkinson’s Disease
http://sysmedpd.eu
----------------------------------------------------------------------------
Mobile:  +353 873 413 072
Skype: ronan.fleming
----------------------------------------------------------------------------
(This message is confidential and may contain privileged information. It is
intended for the named recipient only. If you receive it in error please
notify me and permanently delete the original message and any copies.)