You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I read the specifications for FluxML and I have a very naive question: why didn't you choose to make an SBML package instead of creating a stand-alone file format? Did I miss something?
In the paper, you argue that:
"[...] the set of common features [between FluxML and SBML] is not that large."
another author already made a prototype using (and abusing) SBML's <notes> tag
If anyone would agree with 2/ which is indeed regarded as bad-practice in the SBML community, I guess the 1/ is more subject to interpretation, especially considering that SBML is precisely supposed to be a common ground for all software that deal with... well, systems biology. I was very surprised you didn't mentioned the SBML's packages there. SBML is designed to be enriched by packages, like the classic fbc package that add all the features needed for flux balance constraints and that you can find in every single genome-scale model out there.
So, with that in mind, I was wondering if there was some kind of technical issue that forced you to make you own file format; and if that's not the case, if you are considering creating an SBML package for metabolic flux analysis based on you great work on FluxML?
The text was updated successfully, but these errors were encountered:
thank you very much for your question. While it is true that SBML is a very powerful language, it is indeed lacking essential elements that are necessary for 13C MFA. These include, on the structural level, the atom transitions and, on a quantitative level, measurement information. For both, precise syntactical specifications are absolutely crucial. Also, the extremely useful paradigm of “configurations” does not exist in SBML. More about our reasoning is detailed in our paper
To get a better understanding of how small the common denominator between SBML and FluxML is, I suggest to take a FluxML Model with several configurations (e.g. the model from the Parallel Labeling Experiments section of th paper, right before the multiply_fml.py script is applied), convert it to SBML, convert it back to FluxML and compare with the original file.
So there was no technical issue with SBML, it is more about how reasonable it is to write an SBML package for 13C MFA. In conclusion we are not planning to create such an SBML package.
Hello FluxML dev team,
I read the specifications for FluxML and I have a very naive question: why didn't you choose to make an SBML package instead of creating a stand-alone file format? Did I miss something?
In the paper, you argue that:
<notes>
tagIf anyone would agree with 2/ which is indeed regarded as bad-practice in the SBML community, I guess the 1/ is more subject to interpretation, especially considering that SBML is precisely supposed to be a common ground for all software that deal with... well, systems biology. I was very surprised you didn't mentioned the SBML's packages there. SBML is designed to be enriched by packages, like the classic fbc package that add all the features needed for flux balance constraints and that you can find in every single genome-scale model out there.
So, with that in mind, I was wondering if there was some kind of technical issue that forced you to make you own file format; and if that's not the case, if you are considering creating an SBML package for metabolic flux analysis based on you great work on FluxML?
The text was updated successfully, but these errors were encountered: