Menu
▾
▴
Re: [sbml-flux] FBC version 3 proposal (new document)
|
From: Matthias K. <kon...@go...> - 2019-07-09 09:22:11
|
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
|
