SBML Discussion Lists RDF feed

Re: Updated SBML Test Suite cases (v.3.0.0)

Dominic John — 2013-05-20T15:24:14-00:00

Can anyone tell us if and when JDesigner may be picking up the latest SBML please. Some of the new features in SBML will make the effort of moving physiological models much easier between applications so is of interest to us and our customers. Thanks, Dominic -----Original Message----- From: <a href="mailto:sbml-discuss-bounces@caltech.edu" target="_blank">sbml-discuss-bounces@caltech.edu</a> [mailto:<a href="mailto:sbml-discuss-bounces@caltech.edu]" target="_blank">sbml-discuss-bounces@caltech.edu]</a> On Behalf Of Michael Hucka Sent: Friday, May 17, 2013 2:53 PM To: SBML Discussion List Subject: [sbml-discuss] Updated SBML Test Suite cases (v.3.0.0) Dear SBML community, We are pleased to announce that a new archive of SBML Test Suite test cases is now available for downloading from <a href="https://sourceforge.net/projects/sbml/files/test-suite/3.0.0beta/cases-archive" target="_blank">https://sourceforge.net/projects/sbml/files/test-suite/3.0.0beta/cases-archive</a> as well as from the SVN repository for the SBML project. This update has only a few changes, listed below. The version number bump to 3.0.0 is to coincide with the release of the new SBML Test Runner. (See the separate announcement about the Test Runner.) * Changes to SBML test cases: - Removed invalid model 00173-sbml-l1v2.xml (it used functions not allowed in l1 infix). - Added compartment to 951 and 954 l1 models, for validity. - Reordered components of 1027, 1028, and 1029 l2v1 models, for validity. - Fixed validity of model 1141 (incorrect 'const' flag). - Model 1141's settings file claimed it wanted a compartment's 'concentration'. This was removed. - Various tags added and removed where appropriate, because they were incorrect. A few InitialValue tags; a few BoundaryCondition tags, a few missing MultiCompartment tags for comp models; a few incorrect comp:SubmodelOutput tags; a few tags for deleted components of comp models, on the theory that correct interpetation of the model doesn't depend on anything that was deleted. - Model descriptions written for a few models where "{Write general description of why you have created the model here.}" was still there. Fixed. - Added pre-l3v1 versions of n-ary MathML tests to the .m files (the actual SBML had been there before). More information about the SBML Test Suite in general, as well as links to online facilities, are available at <a href="http://sbml.org/Software/SBML_Test_Suite" target="_blank">http://sbml.org/Software/SBML_Test_Suite</a> Best regards, The SBML Team. ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Announcing the SBML Test Runner, version 3.0.0 beta

Mike Hucka — 2013-05-17T22:04:43-00:00

Dear SBML community, We are pleased to announce the availability of a new, standalone, SBML Test Runner for the SBML Test Suite. This application lets you run SBML-compatible software through every test case in the SBML Test Suite, evaluate the results, and visualize them on your computer. The SBML Test Runner is available from <a href="https://sourceforge.net/projects/sbml/files/test-suite/3.0.0beta/test-runner" target="_blank">https://sourceforge.net/projects/sbml/files/test-suite/3.0.0beta/test-runner</a> This is a ground-up rewrite of the SBML Test Runner and supersedes all past versions. It is written in Java using the SWT graphical user interface widgets, and is packaged as a regular executable application for Mac OS X, Windows and Linux operating systems. It incorporates the SBML Test Suite test cases (so, you do not need to download the test cases separately if you download the Test Runner). It is possible that this beta-test version of the SBML Test Runner still contains bugs that will manifest themselves in different user environments. Please report any problems you encounter to <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> (and please make sure to describe your operating system and the situation that led to the problem). Best regards, Michael Hucka and Frank Bergmann and the rest of the SBML Team. ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Updated SBML Test Suite cases (v.3.0.0)

Mike Hucka — 2013-05-17T21:52:32-00:00

Dear SBML community, We are pleased to announce that a new archive of SBML Test Suite test cases is now available for downloading from <a href="https://sourceforge.net/projects/sbml/files/test-suite/3.0.0beta/cases-archive" target="_blank">https://sourceforge.net/projects/sbml/files/test-suite/3.0.0beta/cases-archive</a> as well as from the SVN repository for the SBML project. This update has only a few changes, listed below. The version number bump to 3.0.0 is to coincide with the release of the new SBML Test Runner. (See the separate announcement about the Test Runner.) * Changes to SBML test cases: - Removed invalid model 00173-sbml-l1v2.xml (it used functions not allowed in l1 infix). - Added compartment to 951 and 954 l1 models, for validity. - Reordered components of 1027, 1028, and 1029 l2v1 models, for validity. - Fixed validity of model 1141 (incorrect 'const' flag). - Model 1141's settings file claimed it wanted a compartment's 'concentration'. This was removed. - Various tags added and removed where appropriate, because they were incorrect. A few InitialValue tags; a few BoundaryCondition tags, a few missing MultiCompartment tags for comp models; a few incorrect comp:SubmodelOutput tags; a few tags for deleted components of comp models, on the theory that correct interpetation of the model doesn't depend on anything that was deleted. - Model descriptions written for a few models where "{Write general description of why you have created the model here.}" was still there. Fixed. - Added pre-l3v1 versions of n-ary MathML tests to the .m files (the actual SBML had been there before). More information about the SBML Test Suite in general, as well as links to online facilities, are available at <a href="http://sbml.org/Software/SBML_Test_Suite" target="_blank">http://sbml.org/Software/SBML_Test_Suite</a> Best regards, The SBML Team. ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Version 1 of the Qualitative Models package for SBML L3

Mike Hucka — 2013-05-17T18:16:17-00:00

This is a momentous day. Congratulations to the authors who have persevered for so long, in the face of controversy and challenges, to achieve this! MH On Fri, 17 May 2013 11:05:27 +0100, Sarah Keating wrote: > Dear SBML community, > > We are pleased to announce the availability of the final Version 1 > specification for Qualitative Models in SBML Level 3. You can find the > document at its resolvable URI > > <a href="http://identifiers.org/combine.specifications/sbml.level-3.version-1.qual.version-1.release-1" target="_blank">http://identifiers.org/combine.specifications/sbml.level-3.version-1.qual.version-1.release-1</a> > > The Qualitative Models ('qual') specification activity page is > > <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Qualitative_Models_%28qual%29" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Qualitative_Models_%28qual%29</a> > > Please report any errors, issues or questions either to the Package > Working Group for 'qual' (<a href="mailto:sbml-qual@lists.sourceforge.net" target="_blank">sbml-qual@lists.sourceforge.net</a>) or to the > authors directly. > > The authors thank all of the people who have contributed to the > development of the 'qual' package and its specification over the years. > > Sarah > (on behalf of all the authors: Claudine Chaouiya, Sarah M. Keating, > Duncan Berenguier, Aurélien Naldi, Denis Thieffry, Martijn P. van Iersel > and Tomá¹ Helikar) > > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Version 1 of the Qualitative Models package for SBML L3

Lucian Smith — 2013-05-17T14:00:05-00:00

Congratulations! It looks great, and represents a ton of work on a lot of people's parts. -Lucian * Sarah Keating <<a href="mailto:skeating@caltech.edu" target="_blank">skeating@caltech.edu</a>> [2013-05-17 11:04] writes: > Dear SBML community, > > We are pleased to announce the availability of the final Version 1 > specification for Qualitative Models in SBML Level 3. You can find the > document at its resolvable URI > > <a href="http://identifiers.org/combine.specifications/sbml.level-3.version-1.qual.version-1.release-1" target="_blank">http://identifiers.org/combine.specifications/sbml.level-3.version-1.qual.version-1.release-1</a> > > The Qualitative Models ('qual') specification activity page is > > <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Qualitative_Models_%28qual%29" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Qualitative_Models_%28qual%29</a> > > Please report any errors, issues or questions either to the Package > Working Group for 'qual' (<a href="mailto:sbml-qual@lists.sourceforge.net" target="_blank">sbml-qual@lists.sourceforge.net</a>) or to the > authors directly. > > The authors thank all of the people who have contributed to the > development of the 'qual' package and its specification over the years. > > Sarah > (on behalf of all the authors: Claudine Chaouiya, Sarah M. Keating, > Duncan Berenguier, Aurélien Naldi, Denis Thieffry, Martijn P. van Iersel > and Tomá? Helikar) > > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Version 1 of the Qualitative Models package for SBML L3

Sarah Keating — 2013-05-17T10:02:24-00:00

Dear SBML community, We are pleased to announce the availability of the final Version 1 specification for Qualitative Models in SBML Level 3. You can find the document at its resolvable URI <a href="http://identifiers.org/combine.specifications/sbml.level-3.version-1.qual.version-1.release-1" target="_blank">http://identifiers.org/combine.specifications/sbml.level-3.version-1.qual.version-1.release-1</a> The Qualitative Models ('qual') specification activity page is <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Qualitative_Models_%28qual%29" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Qualitative_Models_%28qual%29</a> Please report any errors, issues or questions either to the Package Working Group for 'qual' (<a href="mailto:sbml-qual@lists.sourceforge.net" target="_blank">sbml-qual@lists.sourceforge.net</a>) or to the authors directly. The authors thank all of the people who have contributed to the development of the 'qual' package and its specification over the years. Sarah (on behalf of all the authors: Claudine Chaouiya, Sarah M. Keating, Duncan Berenguier, Aurélien Naldi, Denis Thieffry, Martijn P. van Iersel and Tomáš Helikar) ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Evidence of SBML impact beyond Academia?

Maria Schilstra — 2013-05-15T13:44:10-00:00

Hi Mike, You touch on something that is subject to much speculation around the UK: what counts as evidence for impact? We have an impact supremo at UH (recruited for REF purposes) who feels that it would be best if SBML had already demonstrably stood at the basis of several novel drugs that have already saved lives - but obviously we cannot, and probably never will be able to make such a claim. The feedback from the mock reviewers was rather summary and rather prosaic (unfortunately I don't have a copy, as it is all very secretive), but appeared to have beeen based on a visit to sbml.org. All I have to (and can) do, is give the names of companies outside academia that demonstrably support SBML, preferably by mentioning it on their website. With all the replies that my initial post have generated, I have more than enough to get on with without making any far-fetched claims. Again, many thanks to everybody who has contributed to this post! Maria

Re: Evidence of SBML impact beyond Academia?

Maria Schilstra — 2013-05-15T13:20:24-00:00

Hi Mike, That is a very good point - and I had already incorporated it <img src="images/smiley_icons/icon_smile.gif" border=0 alt="Smile">. I have fleshed it out in my new version, and also provided the link to the page on the sbml.org site. Many thanks, Maria

Re: Evidence of SBML impact beyond Academia?

Maria Schilstra — 2013-05-15T13:13:30-00:00

Thank you very much for your extensive reply, and for the endorsement of SBML. I have integrated some of it in my impact case study. If the Powers That Be here at the University of Hertfordshire would like me to provide more evidence, I may get back to you. Maria

Re: Evidence of SBML impact beyond Academia?

Maria Schilstra — 2013-05-15T13:08:22-00:00

Thanks for that, Nicolas. I couldn't find evidence for the Merck-Serono involvement (was it part of a project with academic partners that has now finished?), but Bayer's PK-sim/MoBi mentions SBML, and that is enough. Maria

Re: Evidence of SBML impact beyond Academia?

Maria Schilstra — 2013-05-15T13:03:40-00:00

Thanks Chris, that is indeed a good one, and I will make more of it in my revised version.

Re: Evidence of SBML impact beyond Academia?

Mike Hucka — 2013-05-14T02:31:09-00:00

On Fri, 10 May 2013 08:05:31 -0700 (PDT), Maria Schilstra wrote: > on the basis of what we have written so far, our mock reviewers weren't > convinced that SBML has had much impact outside the academic world. > > So therefore: does anyone have any ideas or suggestions where I may > look for evidence of impact beyond Academia? Incidentally, without seeing what you wrote so far or knowing anything about what you included in your case study, it is difficult to guess at why your mock reviewers weren't "convinced". Were any of the suggestions in the responses so far things that you did not mention in your case study? Do you have any guidance about what would count as evidence of impact? MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Evidence of SBML impact beyond Academia?

Mike Hucka — 2013-05-14T02:24:22-00:00

Hi Maria, Another point to make is that a number of journals accept supplementary data in SBML format (see <a href="http://goo.gl/fW2L3" target="_blank">http://goo.gl/fW2L3</a>). This has at least two implications. First, it means the journals think it's worthwhile to do this, and they're surely not doing it just for the sake of academics. Second, since publications are not read *only* by academics, the availability of research results in SBML format must have impact to commercial research too. (Unfortunately, it doesn't seem like there's a way to quantify just how much impact...) MH On Fri, 10 May 2013 08:05:31 -0700 (PDT), Maria Schilstra wrote: > > Dear all, > > Does anyone have hard evidence (publications, websites, company or > organisation names) that SBML is being used outside Academia? > > As some of you may know, universities in the UK have an important > assessment of their research coming up soon, called the REF or > "Research Excellence Framework". As a part of the REF submission, > universities have to provide evidence that research carried out > between 1993 and 2013 at the units that are submitted to this process > has impacted on "the economy, society, culture, public policy or > services, health, the environment or quality of life, beyond > Academia". SBML has part of its roots in the University of > Hertfordshire (Hamid Bolouri, Andrew Finney, Sarah Keating, and Jo > Matthews all worked here for a while), and therefore it was decided > that we should enter an "impact case study" about SBML. However, on > the basis of what we have written so far, our mock reviewers weren't > convinced that SBML has had much impact outside the academic world. > > So therefore: does anyone have any ideas or suggestions where I may > look for evidence of impact beyond Academia? > > Many thanks, > > Maria > > Dr Maria Schilstra > School of Computer Science > University of Hertfordshire > Hatfield, UK > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

libSBML user survey & prize drawing

Sarah Keating — 2013-05-13T11:16:00-00:00

To libSBML-users We would like to gather opinions on some questions related to libSBML, ranging from 'how we organize the code' to 'specific functionality of certain functions'. We would be very grateful if you could spend a couple of minutes answering some questions. Everyone who fills out the survey will be entered into a drawing for a $20 Amazon voucher. We appreciate that some questions are very specific to a particular aspect of libSBML that you may not use or be familiar with, so the survey is designed to allow you to skip entire sections that you may not wish or feel able to answer. You can answer anonymously, but to be entered into the prize drawing, we will need your name and contact email. <a href="http://www.surveymonkey.com/s/RZ85DGR" target="_blank">http://www.surveymonkey.com/s/RZ85DGR</a> We would be grateful for any answers you feel able to give :-) . Thank you, The SBML Team ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Evidence of SBML impact beyond Academia?

Robert Phair — 2013-05-10T17:08:53-00:00

Maria, Our small company, Integrative Bioinformatics Inc (IBI), has invested heavily in SBML. Our ProcessDB software imports many (but not yet all) components of SBML-encoded models. This has been valuable to our consulting practice because it accelerates our ability to come up to speed with new clients. The ability to quickly and accurately import the state of the art model, often from BioModels.net, allows us to get to work immediately on the current tough problem. I would argue, however, that our investment in SBML is primarily about the future. In our view, there is absolutely no way to imagine a future for biological research that doesn't involve large-scale mechanistic modeling. Disease modeling is also a growing specialty in pharmaceutical R&D. IBI recently won its first pharmaceutical contract having had only academic clients for the first dozen years of being in business. Reviewers should be reminded that to promote diffusion of SBML innovation into industry we are obliged to sell the concept of modeling before the existence of SBML is seen as critical. This is because the thought-leaders in pharmaceutical research and development are biologists, not modelers. I've been watching the diffusion of biological modeling innovation for more than 40 years. The complexity of biology is bringing more and more biologists into mechanistic kinetic modeling. But we are, as everyone knows, in a very difficult funding climate. Reviewers become conservative in times like these. They act like stock market analysts obsessed with profit in the next quarter. Modeling absolutely needs an interchange standard. SBML may not be that final standard 10 or 20 years from now. But SBML and CellML will be the heart and soul of whatever standard emerges. Our small company is solidly behind SBML. We promote SBML whenever the opportunity arises. The core SBML team has done and is doing an amazing job. I'm also constantly in awe of the huge voluntary commitment made to SBML by so many smart software developers. These people are keenly aware that careers are placed at risk by investing time and energy in standards. But they do it because they have vision. They see themselves, as Jacob Bronowski said, on the steps to the future. Robert Robert D Phair PhD | Chief Science Officer | Integrative Bioinformatics Inc Mountain View, CA www.integrativebioinformatics.com ProcessDB: Modeling for Biological Discovery On Fri, May 10, 2013 at 8:05 AM, Maria Schilstra < <a href="mailto:m.j.1.schilstra@herts.ac.uk" target="_blank">m.j.1.schilstra@herts.ac.uk</a>> wrote: > > Dear all, > > Does anyone have hard evidence (publications, websites, company or > organisation names) that SBML is being used outside Academia? > > As some of you may know, universities in the UK have an important > assessment of their research coming up soon, called the REF or "Research > Excellence Framework". As a part of the REF submission, universities have > to provide evidence that research carried out between 1993 and 2013 at the > units that are submitted to this process has impacted on "the economy, > society, culture, public policy or services, health, the environment or > quality of life, beyond Academia". SBML has part of its roots in the > University of Hertfordshire (Hamid Bolouri, Andrew Finney, Sarah Keating, > and Jo Matthews all worked here for a while), and therefore it was decided > that we should enter an "impact case study" about SBML. However, on the > basis of what we have written so far, our mock reviewers weren't convinced > that SBML has had much impact outside the academic world. > > So therefore: does anyone have any ideas or suggestions where I may look > for evidence of impact beyond Academia? > > Many thanks, > > Maria > > Dr Maria Schilstra > School of Computer Science > University of Hertfordshire > Hatfield, UK > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Evidence of SBML impact beyond Academia?

Nicolas Le Novere[1] — 2013-05-10T15:43:40-00:00

A few pharma are using SBML. Merk-Serono has a group integrating biomedical data using SBML and SBGN. Bayer's software PK-Sim/Mobi has SBML support. On 10/05/13 16:05, Maria Schilstra wrote: > > Dear all, > > Does anyone have hard evidence (publications, websites, company or organisation names) that SBML is being used outside Academia? > > As some of you may know, universities in the UK have an important assessment of their research coming up soon, called the REF or "Research Excellence Framework". As a part of the REF submission, universities have to provide evidence that research carried out between 1993 and 2013 at the units that are submitted to this process has impacted on "the economy, society, culture, public policy or services, health, the environment or quality of life, beyond Academia". SBML has part of its roots in the University of Hertfordshire (Hamid Bolouri, Andrew Finney, Sarah Keating, and Jo Matthews all worked here for a while), and therefore it was decided that we should enter an "impact case study" about SBML. However, on the basis of what we have written so far, our mock reviewers weren't convinced that SBML has had much impact outside the academic world. > > So therefore: does anyone have any ideas or suggestions where I may look for evidence of impact beyond Academia? > > Many thanks, > > Maria > > Dr Maria Schilstra > School of Computer Science > University of Hertfordshire > Hatfield, UK > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Mob:+447833147074 <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a> orcid.org//0000-0002-6309-7327 <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> Skype:n.lenovere twitter:@lenovere <a href="http://nlenov.wordpress.com/" target="_blank">http://nlenov.wordpress.com/</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Evidence of SBML impact beyond Academia?

myers — 2013-05-10T15:28:00-00:00

One thing to consider is there are commercial software that use SBML including Mathwork's SimBiology and Wolfram's SystemModeller. Chris On May 10, 2013, at 9:05 AM, Maria Schilstra <<a href="mailto:m.j.1.schilstra@herts.ac.uk" target="_blank">m.j.1.schilstra@herts.ac.uk</a>> wrote: > > Dear all, > > Does anyone have hard evidence (publications, websites, company or organisation names) that SBML is being used outside Academia? > > As some of you may know, universities in the UK have an important assessment of their research coming up soon, called the REF or "Research Excellence Framework". As a part of the REF submission, universities have to provide evidence that research carried out between 1993 and 2013 at the units that are submitted to this process has impacted on "the economy, society, culture, public policy or services, health, the environment or quality of life, beyond Academia". SBML has part of its roots in the University of Hertfordshire (Hamid Bolouri, Andrew Finney, Sarah Keating, and Jo Matthews all worked here for a while), and therefore it was decided that we should enter an "impact case study" about SBML. However, on the basis of what we have written so far, our mock reviewers weren't convinced that SBML has had much impact outside the academic world. > > So therefore: does anyone have any ideas or suggestions where I may look for evidence of impact beyond Academia? > > Many thanks, > > Maria > > Dr Maria Schilstra > School of Computer Science > University of Hertfordshire > Hatfield, UK > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Evidence of SBML impact beyond Academia?

Maria Schilstra — 2013-05-10T10:04:01-00:00

Dear all, Does anyone have hard evidence (publications, websites, company or organisation names) that SBML is being used outside Academia? As some of you may know, universities in the UK have an important assessment of their research coming up soon, called the REF or "Research Excellence Framework". As a part of the REF submission, universities have to provide evidence that research carried out between 1993 and 2013 at the units that are submitted to this process has impacted on "the economy, society, culture, public policy or services, health, the environment or quality of life, beyond Academia". SBML has part of its roots in the University of Hertfordshire (Hamid Bolouri, Andrew Finney, Sarah Keating, and Jo Matthews all worked here for a while), and therefore it was decided that we should enter an "impact case study" about SBML. However, on the basis of what we have written so far, our mock reviewers weren't convinced that SBML has had much impact outside the academic world. So therefore: does anyone have any ideas or suggestions where I may look for evidence of impact beyond Academia? Many thanks, Maria Dr Maria Schilstra School of Computer Science University of Hertfordshire Hatfield, UK

SBML Packages update

Lucian Smith — 2013-04-29T18:31:51-00:00

Hey, everyone! In these weeks leading up to HARMONY, we've been seeing a lot of activity in the various package working groups email lists, to the point where there are now several specifications that are on the verge of being finalized. This is a short note to let you know what's going on in those groups, and another invitation to join the mailing lists yourselves, if you're at all interested in the functionality those packages provide. Every group would be particularly interested in your feedback if you're interested in implementing support for one or more of them. URLs are provided for each, from which you can get to the latest specification document and a link to the package working group mailing list. ==== The Qualitative Models package ==== <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/qual" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/qual</a> The qualitative models specification is nearly finalized! After a flurry of discussion about the specification and how it relates in particular to Petri Net modeling, a release candidate has been sent to the SBML Editors for approval, and sbml-discuss has been formally asked for any input before the editors make their final decision. Also, a qual model has already been published! ==== The Multistate Multicomponent package ==== <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/multi" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/multi</a> Fengkai Zhang and his group presented a brand-new version of this package last year at COMBINE, and has been at work since then to update and improve it, with input from the package working group. Several labs doing multistate modeling have expressed interest in supporting this package, and a breakout group is planned for HARMONY to discuss the package and possible extentions to it. ==== The Layout package ==== <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/layout" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/layout</a> The layout package has existed as a set of SBML Level 2 annotations for many years, but now, a formal specification for the package for Level 3 has been released for comment, that extends some of the constructs to be more generic, to allow the layout of all SBML constructs, not just reactions and species. A new version should be available for HARMONY. ==== The Distributions package ==== <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/distrib" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/distrib</a> After releasing an updated version of the specification in January, Stuart Moodie suggested some substantive changes on his blog, which ultimately resulted in several changes being accepted by the group, and one change in particular being voted on. (The vote is ongoing--feel free to contribute your opinion at <a href="https://docs.google.com/forms/d/1RacLmuXSGbsgsMunylbR4SRM4ZOxX9dgcQ2-abKZAi8/viewform" target="_blank">https://docs.google.com/forms/d/1RacLmuXSGbsgsMunylbR4SRM4ZOxX9dgcQ2-abKZAi8/viewform</a> ) The UncertML community has also been participating in the discussion, as some of the proposed changes would require a corresponding change in UncertML itself. These changes are currently being incorporated into the latest specification, which will be available in time for HARMONY. ==== The Groups package ==== <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/groups" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/groups</a> Recent extentions to this package now allow it to fully replace the old 'SpeciesType' class from SBML Level 2, both semantically and in terms of validation, in addition to providing a way to arbitrarily group elements. Otherwise, it remains a very simple package, that may in the future be able to be upgraded to a 'sets' package. ==== The Required Elements package ==== <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/req" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/req</a> Renewed discussion of this package has led to a new specification, released just today, which contains much more discussion about how particular required packages may interact with this, as well. The question remains: does anyone need this package? How helpful is it? Further discussion will likely happen at HARMONY. ==== The Arrays package ==== <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/arrays</a> Chris Myers is keeping this package alive, and has produced the beginnings of a draft specification based on the old one by Bruce Shapiro, updated to reflect current L3v1 sensibilities. Further input is welcomed! --------- Special thanks to all community members who have helped work on and/or comment on these packages--your effort and input is greatly appreciated, and is in fact vital to the continual usefulness of SBML in an evolving field. -Lucian Smith ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Other journals that accept SBML format?

Mike Hucka — 2013-04-27T19:38:37-00:00

Periodically I like to ask people if they know of any additional journals whose author guidelines explicitly mention acceptance of SBML files and/or deposition in BioModels Database. Our current list is at <a href="http://sbml.org/Documents/Publications_known_to_accept_submissions_in_SBML_format" target="_blank">http://sbml.org/Documents/Publications_known_to_accept_submissions_in_SBML_format</a> but there are probably others. So, if you know of one that's not listed, would you please contact me or <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> to let us know? Thanks, MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Release candidate of the Qualitative Model package (Qual)

Nicolas Le Novere[1] — 2013-04-27T10:30:32-00:00

Dear Members of the SBML community, As part of the process of developing and accepting SBML L3 packages the PWG are required to submit a 'release candidate' specification; together with information relating to two pieces of software that implement the specification; for approval by the SBMLEditors. The Qualitative Model package group (Qual) has now submitted this information which is publicly available here: <a href="http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Qualitative_Models_%28qual%29" target="_blank">http://sbml.org/Documents/Specifications/SBML_Level_3/Packages/Qualitative_Models_%28qual%29</a> The SBMLEditors (excluding those that may be authors of the Qual spec) will now consider the spec and the implementations and determine whether they meet the "Criteria for approval" as outlined in the SBML Development process. (<a href="http://sbml.org/Documents/SBML_Development_Process_for_SBML_Level_3" target="_blank">http://sbml.org/Documents/SBML_Development_Process_for_SBML_Level_3</a>). At this point we are opening the floor to comments from all members of the SBML community who have not been particularly involved with the development of comp. Thank you Nicolas on behalf of the SBMLEditors ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

A survey about SBGN

Stuart Moodie — 2013-04-25T17:49:42-00:00

Hi All, I know many of you draw the pathways that you model and some of you even store your diagrams in SBML. So I hope you will forgive the intrusion and find this relevant. As you will see from the email below, we are trying to reach out beyond the sbgn-discuss list and find out who the users of SBGN are. We want to know how SBGN is used and how it can be improved. The challenge with this type of survey is finding your users, so please help us by filling in the survey via the link below and by passing on the survey link to your colleagues. <a href="https://www.surveymonkey.com/s/96ZFGCV" target="_blank">https://www.surveymonkey.com/s/96ZFGCV</a> Best wishes, Stuart Moodie (on behalf of the SBGN Editors). Begin forwarded message: > From: Stuart Moodie <<a href="mailto:moodie@ebi.ac.uk" target="_blank">moodie@ebi.ac.uk</a>> > Subject: [sbgn-discuss] A survey about SBGN > Date: 19 April 2013 14:11:29 GMT+01:00 > To: SBGN Discussion List <<a href="mailto:sbgn-discuss@caltech.edu" target="_blank">sbgn-discuss@caltech.edu</a>> > Reply-To: SBGN Discussion List <<a href="mailto:sbgn-discuss@caltech.edu" target="_blank">sbgn-discuss@caltech.edu</a>> > > Dear Colleagues, > > The SBGN Editors have developed a survey about SBGN. Our aim is to gauge the levels of SBGN usage: what it is used for, what languages are used and to generally get feedback on what users like, don't like, or think can be improved. The feedback from this survey will help the community shape the future development of SBGN. > > We would like the survey to reach as wide as range of life scientists as possible, so after you complete the survey can you help by spreading the word to your colleagues and collaborators? We have created a form email (<a href="http://www.sbgn.org/SBGN_Survey#Form_Email" target="_blank">http://www.sbgn.org/SBGN_Survey#Form_Email</a>) that you may wish to use when contacting them. Your help is important and appreciated. > > The survey should only take approximately 10 minutes to complete and can be found by following this link: > > <a href="https://www.surveymonkey.com/s/96ZFGCV" target="_blank">https://www.surveymonkey.com/s/96ZFGCV</a> > > Best wishes, > > > Stuart Moodie (on behalf of the SBGN Editors). > ____________________________________________________________ > To manage your sbgn-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbgn-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbgn-discuss</a> > > For questions or feedback about the sbgn-discuss list, > contact <a href="mailto:sbgn-editors@lists.sourceforge.net" target="_blank">sbgn-editors@lists.sourceforge.net</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Release of SBMLsimulatior 1.1

Andreas Dräger — 2013-04-25T13:30:29-00:00

Dear all, We are pleased to announce the release of SBMLsimulator 1.1, a front end for the recently also released Systems Biology Simulation Core Library. SBMLsimulator can be used as a web start version or by downloading the executable JAR file from <a href="http://www.cogsys.cs.uni-tuebingen.de/software/SBMLsimulator/." target="_blank">http://www.cogsys.cs.uni-tuebingen.de/software/SBMLsimulator/.</a> When using SBMLsimulator locally, it is possible to estimate unknown quantities within the SBML models using a large variety of heuristic optimization procedures from the EvA2 framework. For questions, bug reports or suggestions, please contact Roland Keller (<a href="mailto:roland.keller@uni-tuebingen.de" target="_blank">roland.keller@uni-tuebingen.de</a>). Best regards The SBMLsimulator team -- Dr. Andreas Dräger University of Tuebingen Center for Bioinformatics Tuebingen (ZBIT) Sand 1 72076 Tübingen Germany Phone: +49-7071-29-78982 Fax: +49-7071-29-5091 ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Release of the Systems Biology Simulation Core Library 1.3

Andreas Dräger — 2013-04-19T14:35:34-00:00

We are pleased to announce the release of the Systems Biology SimulationCore Library 1.3, which provides an efficient and exhaustive Java implementation of methods to interpret the content of models encoded in the Systems Biology Markup Language (SBML) and its numerical solution. See the project's homepage at <a href="http://simulation-core.sourceforge.net" target="_blank">http://simulation-core.sourceforge.net</a> You can download binaries, source code, and documentation from <a href="https://sourceforge.net/projects/simulation-core/files/Releases/Version%201.3/" target="_blank">https://sourceforge.net/projects/simulation-core/files/Releases/Version%201.3/</a> Find the API documentation including source code examples here: <a href="http://simulation-core.sourceforge.net/version_1.3/" target="_blank">http://simulation-core.sourceforge.net/version_1.3/</a> Contact: <a href="mailto:simulation-core-development@lists.sourceforge.net" target="_blank">simulation-core-development@lists.sourceforge.net</a> Simulation Core NEWS -- History of user-visible changes ============================================ Version 1.3 (2013-04-19) ============================================ * New features: - The violation of SBML constraints can now be treated using specialized listeners. In this way it has become much easier to customize what should happen in case of unsatisfied constraints during the simulation. - The csymbol delay can now be interpreted with arbitrary expressions. * Bug fixes: - Models with fast reactions are now simulated more precisely. - Some inefficiencies in the simulation routine have been removed. ============================================ Best regards The Systems Biology Simulation Core Library team. -- Dr. Andreas Drï¿½ger University of Tuebingen Center for Bioinformatics Tuebingen (ZBIT) Sand 1 72076 Tï¿½bingen Germany Phone: +49-7071-29-78982 Fax: +49-7071-29-5091 ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Andreas Dräger — 2013-04-08T11:35:26-00:00

Am 4/2/13 5:20 PM, schrieb Nicolas Le Novere: > On 02/04/13 16:00, Chris J. Myers wrote: >> Maybe we could locate >> some of these people and invite them to Harmony or COMBINE to get their >> input. I know that Mike is trying to get Karr to an upcoming meeting. >> Any others we should try to talk with? > Indeed. We are about to launch invitations for COMBINE 2013 (Curie > Institute, Paris, 17-20 Sept 2013), so if you have suggestions, timing is > absolutely perfect :-) Dear all, There is something, I would like to add to this entire discussion. From my perspective, it would be of high importance to also use the COMBINE meetings to bring more people together in order to share code in open source efforts. This could, for instance, include advertising that people join already existing projects, or to launch new such projects. Particularly, with respect to the rule that at least two tools must implement certain aspects of a new package proposal, it would in many cases also be helpful to split the functionality into smaller pieces that could, for instance, be done by specialized libraries. A current example would be the implementation of more MathML constructs. Other examples are solver libraries for SBML etc. On the mailing list of the JSBML project we thought about participating in the "Google Summer of Code". This would give us the great opportunity to achieve three goals at the same time: 1) receive a funding for interesting projects, 2) attract computer science students from many countries, who share their work in open source projects, and 3) increase the visibility of our software projects. We had the idea that we could try to make COMBINE an umbrella organization for the next "Google Summer of Code" in 2014. This would give us enough time to prepare such a proposal, form working groups, and think about how we could share code more effectively. IMHO sharing code in smaller libraries becomes increasingly necessary as the complexity of our standards raises. Fortunately, many such efforts are already existing. So, we have already a very good ground to start from. I would even go one step further and encourage people to share more parts of existing software in form of smaller libraries that could be useful for others in more complex situations. Cheers Andreas -- Dr. Andreas Dräger University of Tuebingen Center for Bioinformatics Tuebingen (ZBIT) Sand 1 72076 Tübingen Germany Phone: +49-7071-29-78982 Fax: +49-7071-29-5091 ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Nicolas Le Novere[1] — 2013-04-02T15:20:01-00:00

On 02/04/13 16:00, Chris J. Myers wrote: > Maybe we could locate > some of these people and invite them to Harmony or COMBINE to get their > input. I know that Mike is trying to get Karr to an upcoming meeting. > Any others we should try to talk with? Indeed. We are about to launch invitations for COMBINE 2013 (Curie Institute, Paris, 17-20 Sept 2013), so if you have suggestions, timing is absolutely perfect :-) -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

BioUML workbench v 0.9.4 was released

Fedor Kolpakov — 2013-04-02T15:02:56-00:00

We are pleased to announce the a release of BioUML workbench 0.9.4 (beta). New features and main changes in this version: Integration with Biostore (<a href="http://www.bio-store.org" target="_blank">http://www.bio-store.org</a>) for control of access rights and downloading. Please see presentation "Biostore and collaborative research" by Tagir Valeev on International workshop "From virtual cell to virtual human and virtual patient", Novosibirsk, Russia, June 24, 2012 for more details: <a href="http://www.biouml.org/vc/agenda.shtml" target="_blank">http://www.biouml.org/vc/agenda.shtml</a> BioUML web version (freely available at <a href="http://ie.biouml.org/bioumlweb" target="_blank">http://ie.biouml.org/bioumlweb</a>): Collaborative work on diagram (like Google documents) (see also presentation "Biostore and collaborative research") UI improvements: - automatic suggestions in search pane - automatic opening of uploaded files - select several elements to remove in repository tree Genome browser improvements - gene structure can be shown in a table cell BioUML core: History of diagram editing (like CVS or SVN) (see also presentation "Biostore and collaborative research") Simulation engine - stochastic modeling, following solvers were implemented: - Gillespie (Gillespie, D.T. 1977) - Gibson-Bruck (Gibson, J. Bruck 2000) - Max Time step (Puchalka, J., Kierzek, A.M. 2004) - Tau-leaping (Yang, C. et al. 2006) - Discrete Stochastic Models Test Suite (DSMTS) was passed succesfully - agent based modelling - new agent with ability to produce descendants. Is used to simulate cell population behaviour. SBML support: - bug fixing - flux balance constraint models support (using org.apache.common.math3) - all non composite tests from test-suite 2.3.2 (2013-02-04) passed. Visual modelling - composite diagrams improvements - MathDiagramType - new diagram type for describing physial procsses. Automatically generates dependencies between equations. Model analysis - model reduction - MCA (Metabolic Control Analysis, alpha version) Analyses: - convert table: ability to use column for ID - filter table: ability to select top N or bottom N entries User interface improvements - perspectives - allows to group and filter UI components for specific user's tasks - tree table component - drag & drop for annotations Genome browser improvements - better navigation (chromosome switch, position input box, drag-and-scroll, zoom selection, mouse wheel support, etc.) - improved sites information tab - BAM tracks support - gene structure can be shown in a table cell (only web) - improved and new styles for genes structure visualization Improved support of DAS protocol - support for 1.53 and 1.6 - support for non positional features - interactions - ontologies Integration with JMOL for visualization of 3D structures BioUML server Galaxy support new section "Galaxy" in analyses tab allows to use all methods from Galaxy platform. To support BioUML community we have launched - BioUML forum - <a href="http://forum.biouml.org" target="_blank">http://forum.biouml.org</a> - BioUML wiki - <a href="http://wiki.biouml.org" target="_blank">http://wiki.biouml.org</a> Please use it if you have some problems, questions or ideas. Fedor Kolpakov on behalf BioUML team P.S. You may also to take a look on presentations (PDF or video from YouTube) about BioUML platform that were done during International workshop "From virtual cell to virtual human and virtual patient", Novosibirsk, Russia, June 24, 2012: <a href="http://www.biouml.org/vc/agenda.shtml" target="_blank">http://www.biouml.org/vc/agenda.shtml</a>

Re: [SED-ML-discuss] People, we need a reboot.

myers — 2013-04-02T15:00:16-00:00

I think there are certain people that are always going to prefer the flexibility of using their own programming language to build their simulations of their models. However, the hope is that the libsbml library bindings would encourage them to still use SBML for their models. Some people such as the whole-cell model folks are still not doing that, why is this? Is it that SBML is unable to represent something they want or is it they just find it simpler to build their model in code rather than one of our model editors. I suspect that it is a combination of both. For the whole-cell modelers, they did not have some features they needed like FBC and comp. Maybe we could locate some of these people and invite them to Harmony or COMBINE to get their input. I know that Mike is trying to get Karr to an upcoming meeting. Any others we should try to talk with? Chris On Apr 1, 2013, at 9:07 PM, Herbert M Sauro <<a href="mailto:hsauro@u.washington.edu" target="_blank">hsauro@u.washington.edu</a>> wrote: > Indeed the theory sounds good, I just don't know how users will react to it. In the end it will depend on the quality of the tools that get developed around sed-ml and how well sed-ml talks nicely with systems people already use, eg matlab and python. If users perceive any loss of productively or flexibility I don't think they will use sed-ml. > > Herbert > > Sent from my iPad > > On Apr 1, 2013, at 7:32 PM, Michael Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> wrote: > >> On Mon, 01 Apr 2013 15:09:11 -0700, hsauro wrote: >>> I am not sure about using SEDML in this way, we have very good scripting >>> languages that can be used to ties module together. >> >> But but but ... the whole point of using SED-ML is that it's separate from the implementation and the specific language, and thus allows any of a number of software tools to work with it. Not only does such abstraction allow software developers to use any programming or scripting language to implement it; it allows the description themselves to be stored in databases, versioned, annotated, linked, etc. -- indeed, the benefits are the same as the benefits of using an abstract model exchange format like SBML. >> >> MH >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

b.g.olivier — 2013-04-02T09:22:54-00:00

On 02/04/13 04:19, Michael Hucka wrote: > On Mon, 1 Apr 2013 22:57:09 +0100, Lucian Smith wrote: >>> One of issues which interested me (if I remember correctly) is the use >>> of a dynamic FBA approach for one module where one effectively embeds an >>> FBA model in an ODE. Just out of interest, could you do this sort of >>> thing with "comp" (or other package) where for example you might have a >>> function which contains the output of an entire FBC model [...]? >> [...] >> >> At present, comp allows you to to decompose a model, but doesn't allow you >> to decompose an analysis in this way. A lot of the machinery that *would* >> let you do such a thing is there, though. I bet if there was a tool that >> allowed you to perform the analysis, it wouldn't be too hard to figure out >> from that what new information needed to be stored in the sbml file. > Yeah, I agree. I'm sure you have in mind the use of annotations (possibly SBO, though new terms may be needed) to indicate the intended interpretations of different submodels? > > Actually, Brett, your Python-based software can handle both ODE and FBC models, can't it? That makes it relatively unique. Maybe if it were also extended to handle 'comp' and read the annotations, you might be the first to achieve this. Nice discussion, they started as one but evolved into two separate packages ODE & CBM. Recently I've started looking at these hybrid approaches for my modelling and am now considering how to re-integrate the functionality. There is CBM software that does dynamic FBA (e.g. COBRA) but, as far as I am aware, in a very problem specific way. So yes, I will be working towards a more general framework for doing this sort of thing, at the moment it's more a problem of mapping the biology to the modelling. That being said, implementing support for the above strategy is a possibility even if it starts as a restricted use case. If I may I just add some personal observations (warning OT and obvious to cs people): * software written in the same language (in my case Python) doesn't mean its functionality can be easily combined even when written by the same person (this I discovered the hard way), * for hybrid modelling, software needs to be based on an open architecture, such that it can be used in ways it wasn't designed for, * as our knowledge of the complex interactions in biology increase so do the models and modelling methodologies needed to describe them. To my mind this implies that there can never be any "all encompassing" modelling methodology or "one software to rule them all." However, the above has lead me to the following question (beyond using a single language as a glue): Is it possible to define "application" level protocols such that we can use SED-ML, Python or whatever as "transport" which will allow future software to not only share "data" (SBML/CellML/?ML models) but modelling functionality as well (ODE, CBM, rule, etc.)? This may sound like idealistic science fiction, but isn't it cool that with the state of SBML and other modelling formats one can already start thinking about this type of question and, at the same time, provide real modelling solutions. Brett > MH > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> -- Brett G. Olivier PhD Researcher in Computational Systems Biology Systems Bioinformatics VU University Amsterdam Amsterdam, The Netherlands Email: b.g.olivier[AT]vu[dot]nl Tel (office) +31 20 5987248 ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

hsauro — 2013-04-02T03:22:05-00:00

PS Don't get me wrong, I'm interested in SED-ML. I am trying to think of ways of how to best integrate SED-ML in to our software. As you know we have both script based and visual based simulators, trying to figure out how best to do it is difficult. Don't have a solution yet. Herbert On 4/1/2013 7:37 PM, Michael Hucka wrote: > On Mon, 01 Apr 2013 15:55:25 -0700, hsauro wrote: >> But isn't the suggestion to use SED-ML >> with it limited capability to describe potentially complex interactions >> between modules the very thing that would alienate modelers? They would >> have yet another thing to learn > I think it was said elsewhere in this discussion thread, but to reiterate: modelers aren't expected to have to learn SED-ML, any more than they're expected to have to learn SBML or CellML or any other *ML directly. Software does that for them. (However, limited capabilities may alienate the software developers :-).) > >> I still wasn't able to get any good reason how adding the whole >> of MathML to SBML would benefit users. > It's true, it seemed the conversation was trending away from using the *whole* of MathML, towards identifying a larger subset of MathML than what SBML uses currently. However, I think it seems clear that modelers and software would benefit from having *some* additional constructs added, to enable SBML to encode more directly some models that it can't currently. > > MH > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> -- Herbert M. Sauro, PhD Associate Professor Department of Bioengineering University of Washington William H. Foege Building Box 355061, Seattle, WA 98195-5061 206.685.2119 (tel), 206.685.3300 (shared fax) <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> New Text Book: Enzyme Kinetics for Systems Biology Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Herbert M Sauro — 2013-04-02T03:06:41-00:00

Indeed the theory sounds good, I just don't know how users will react to it. In the end it will depend on the quality of the tools that get developed around sed-ml and how well sed-ml talks nicely with systems people already use, eg matlab and python. If users perceive any loss of productively or flexibility I don't think they will use sed-ml. Herbert Sent from my iPad On Apr 1, 2013, at 7:32 PM, Michael Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> wrote: > On Mon, 01 Apr 2013 15:09:11 -0700, hsauro wrote: >> I am not sure about using SEDML in this way, we have very good scripting >> languages that can be used to ties module together. > > But but but ... the whole point of using SED-ML is that it's separate from the implementation and the specific language, and thus allows any of a number of software tools to work with it. Not only does such abstraction allow software developers to use any programming or scripting language to implement it; it allows the description themselves to be stored in databases, versioned, annotated, linked, etc. -- indeed, the benefits are the same as the benefits of using an abstract model exchange format like SBML. > > MH > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Mike Hucka — 2013-04-02T02:52:15-00:00

On Tue, 2 Apr 2013 02:25:02 +0100, Lucian Smith wrote: > If SED-ML is going to lure people away from python, it will have to > provide something compelling. Traditionally, that's exchangeability and > semantics. But you can't expect modelers to give up much (if anything) > for these somewhat esoteric benefits. Which means that it would need a > robust set of semantics that covered all of what they currently use python > for. Which is certainly unknown to me, but sounds like an interesting > research effort. IIRC, there have been some efforts to develop more powerful abstractions. I believe Andrew Miller has done some work in that area; there are probably others too. Outside of systems biology, one would probably look at something like Modelica. You're right that it does seem like an interesting research topic. It's the sort of thing that I imagine "true" computer scientists should be interested in (as opposed to more applied computer science types, like many of us talking about it). MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Mike Hucka — 2013-04-02T02:37:53-00:00

On Mon, 01 Apr 2013 15:55:25 -0700, hsauro wrote: > But isn't the suggestion to use SED-ML > with it limited capability to describe potentially complex interactions > between modules the very thing that would alienate modelers? They would > have yet another thing to learn I think it was said elsewhere in this discussion thread, but to reiterate: modelers aren't expected to have to learn SED-ML, any more than they're expected to have to learn SBML or CellML or any other *ML directly. Software does that for them. (However, limited capabilities may alienate the software developers :-).) > I still wasn't able to get any good reason how adding the whole > of MathML to SBML would benefit users. It's true, it seemed the conversation was trending away from using the *whole* of MathML, towards identifying a larger subset of MathML than what SBML uses currently. However, I think it seems clear that modelers and software would benefit from having *some* additional constructs added, to enable SBML to encode more directly some models that it can't currently. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Mike Hucka — 2013-04-02T02:32:27-00:00

On Mon, 01 Apr 2013 15:09:11 -0700, hsauro wrote: > I am not sure about using SEDML in this way, we have very good scripting > languages that can be used to ties module together. But but but ... the whole point of using SED-ML is that it's separate from the implementation and the specific language, and thus allows any of a number of software tools to work with it. Not only does such abstraction allow software developers to use any programming or scripting language to implement it; it allows the description themselves to be stored in databases, versioned, annotated, linked, etc. -- indeed, the benefits are the same as the benefits of using an abstract model exchange format like SBML. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Mike Hucka — 2013-04-02T02:19:19-00:00

On Mon, 1 Apr 2013 22:57:09 +0100, Lucian Smith wrote: >> One of issues which interested me (if I remember correctly) is the use >> of a dynamic FBA approach for one module where one effectively embeds an >> FBA model in an ODE. Just out of interest, could you do this sort of >> thing with "comp" (or other package) where for example you might have a >> function which contains the output of an entire FBC model [...]? > > [...] > > At present, comp allows you to to decompose a model, but doesn't allow you > to decompose an analysis in this way. A lot of the machinery that *would* > let you do such a thing is there, though. I bet if there was a tool that > allowed you to perform the analysis, it wouldn't be too hard to figure out > from that what new information needed to be stored in the sbml file. Yeah, I agree. I'm sure you have in mind the use of annotations (possibly SBO, though new terms may be needed) to indicate the intended interpretations of different submodels? Actually, Brett, your Python-based software can handle both ODE and FBC models, can't it? That makes it relatively unique. Maybe if it were also extended to handle 'comp' and read the annotations, you might be the first to achieve this. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Herbert M Sauro — 2013-04-02T01:36:23-00:00

You're probably right, a limited subset of python. A similar subset should be available for other scripting languages such as R, matlab, etc. The ultimate purpose of standards is to increase productivity and if a proposed standard, say Xml, reduces productivity then it will less likely be used. Herbert Sent from my iPad On Apr 1, 2013, at 6:25 PM, Lucian Smith <<a href="mailto:lpsmith@spod-central.org" target="_blank">lpsmith@spod-central.org</a>> wrote: > Well, going from *arbitrary* Python code to SED-ML is obviously doomed, > just like going from arbitrary Matlab to SBML is doomed, but to use the > same analogy, you could use a subset of Python and annotate it to go to > sedml again. > > If SED-ML is going to lure people away from python, it will have to > provide something compelling. Traditionally, that's exchangeability and > semantics. But you can't expect modelers to give up much (if anything) > for these somewhat esoteric benefits. Which means that it would need a > robust set of semantics that covered all of what they currently use python > for. Which is certainly unknown to me, but sounds like an interesting > research effort. > > -Lucian > > * Herbert M Sauro <<a href="mailto:hsauro@u.washington.edu" target="_blank">hsauro@u.washington.edu</a>> [2013-04-02 01:28] writes: >> >> Lucian >> >> We could indeed go from sbml+sedml to matlab. I wish there was someway to go from a procedural language, eg python or R to sedml. Any one got ideas on how to do that? I suppose one could devise a set of methods in the scripting language that map to the various constructs in sedml but then the user isn't exactly using the script language to its full extent. Eg they can't use the for loop they are familiar with instead they must use the sedml compatible sedmlforlopp() method. >> >> The fact that this isn't obvious is already setting us up to be not so friendly to users. One would say of course, "the tools will hide all this from the user!", true, but perhaps we could make life easier for tool makers. It would be great if there was an easy mapping both ways between sedml and a procedural language. Eg I get an sedml file from someone, I convert it to python, simulation runs beautifully, however I modify the python, add a loop here a test there and now I want it converted it back to see-ml, not easy. It's things like this that make life difficult for developers, which in turn can result in substandard applications due to the extra effort, which in turn puts off users, which in turn reduces interest in sbml etc. >> >> I can imagine a worse scenario, someone wires together a set of modules using python, because it is convenient and the current crop of tools are up to wiring modules using sed-ml. How will they convert that to sedml? If I were wiring up a set of submodels I would much rather use a scripting language that I was familiar with than use a tool that might or might not be that great, and might disappear in a years time because a grant failed to materialize. >> >> I as said before, focus on the user, how do we make their life simpler and more *productive*, that in turn translates how do we make the developers life easier (libsbml is a great example of this). >> >> Herbert >> >> Sent from my iPad >> >> On Apr 1, 2013, at 4:23 PM, Lucian Smith <<a href="mailto:lpsmith@spod-central.org" target="_blank">lpsmith@spod-central.org</a>> wrote: >> >>> Well, it all comes back to the tools. As Chris mentioned, there is no >>> tool that currently could handle a model like the whole-cell model, which >>> makes debating what format that tool should use to exchange that model >>> with a different nonexistent tool a little moot. But if we posit a future >>> where that tool exists, I think it's not terribly unreasonable to guess >>> that it might be able to store some of the information it needs to store >>> as SED-ML. Yes, it should hide that from its users; they don't need to >>> learn SED-ML any more than they need to learn SBML. But when the tools >>> start exchanging models like these, it might make the most sense to use >>> SED-ML to do it (at least partly). >>> >>> At the very least, I could envision a translator that took an SBML file >>> (or files) plus some SED-ML and translated that to MATLAB. >>> >>> -Lucian >>> >>> * hsauro <<a href="mailto:hsauro@u.washington.edu" target="_blank">hsauro@u.washington.edu</a>> [2013-04-01 23:58] writes: >>>> I've been listening to this very interesting thread with a lot of good >>>> comments from a lot of people. But isn't the suggestion to use SED-ML >>>> with it limited capability to describe potentially complex interactions >>>> between modules the very thing that would alienate modelers? They would >>>> have yet another thing to learn, more inferior in capabilities compared >>>> to something like Python (from their point of view) and with much more >>>> limited support from tools. Other than the ability to include annotation >>>> what other benefit is there to users to employ SED-ML as the glue? One >>>> could conceivably add annotation to Python via (CS people close your >>>> eyes) comments. I can see SED-ML as means to describe simulation >>>> experiments but as a means to coordinate a large set of modules I am not >>>> so sure. >>>> >>>> I feel the push-back we are seeing with SBML and associated standards is >>>> that we don't think enough about the end user. I know that because I >>>> have to work around certain things in SBML to keep users happy. A recent >>>> example is the great MathML debate. After the debate finished I still >>>> wasn't able to get any good reason how adding the whole of MathML to >>>> SBML would benefit users. That should be the first criterion. SBML was >>>> born out of a need by users not developers or computer scientists. I >>>> think the community should go back to its roots, find problems that need >>>> a solution rather than devise solutions looking for a problem. William >>>> Hlavacek listed a number of user problems that need solving, now if >>>> adding MathML to SBML can help solve these problems then that is why the >>>> rest of MathML should be added. The only other reason to do something >>>> like adding the whole of MathML to SBML is for research purposes, ie to >>>> explore the possibility of such a change but not for production code >>>> until a problem arises where the need is genuine. >>>> >>>> Herbert >>>> >>>> On 4/1/2013 3:27 PM, Nicolas Le Novere wrote: >>>>> Hi Herbert, >>>>> >>>>> On 01/04/13 23:09, hsauro wrote: >>>>>> I am not sure about using SEDML in this way, we have very good scripting >>>>>> languages that can be used to ties module together. >>>>> And we have very good scripting languages to encode the models themselves. >>>>> Those do not replace SBML though, for many reasons, all of them being >>>>> applicable to simulation descriptions. >>>>> >>>>>> This is what >>>>>> compucell3d does, makes it very easy to modify module interactions. The >>>>>> one thing that concerns me however (also with compucell3d) is how does >>>>>> one decide on the correct time step between running modules? We are so >>>>>> careful with setting the right step size for a purely ODE model (Just >>>>>> see the amount of care is taken to get events right in simulations) but >>>>>> when it comes to very course grained models all that care goes out the >>>>>> window. Do people test the model with different time steps to see if the >>>>>> solution converges? I haven't read the Cell paper in detail but is this >>>>>> what they did to confirm that the simulation converged to a solution? >>>>>> >>>>>> Herbert >>>>>> >>>>>> On 4/1/2013 2:55 PM, Moraru,Ion wrote: >>>>>>> Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... >>>>>>> >>>>>>> Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... >>>>>>> >>>>>>> Ion >>>>>>> >>>>>>> Sent from my iPad >>>>>>> >>>>>>> On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: >>>>>>> >>>>>>>>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. >>>>>>>>> >>>>>>>> I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to es > > se >>> >>> nt >>>> i >>>>> >>>>> a >>>>>> l >>>>>>> ly >>>>>>>> "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. >>>>>>>> >>>>>>>> Chris >>>>>>>> >>>>>>>> ____________________________________________________________ >>>>>>>> To manage your sbml-discuss list subscription, visit >>>>>>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>>>>>>> >>>>>>>> For a web interface to the sbml-discuss mailing list, visit >>>>>>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>>>>>>> >>>>>>>> For questions or feedback about the sbml-discuss list, >>>>>>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >>>>>>> ____________________________________________________________ >>>>>>> To manage your sbml-discuss list subscription, visit >>>>>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>>>>>> >>>>>>> For a web interface to the sbml-discuss mailing list, visit >>>>>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>>>>>> >>>>>>> For questions or feedback about the sbml-discuss list, >>>>>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> Herbert M. Sauro, PhD >>>> Associate Professor >>>> Department of Bioengineering >>>> >>>> University of Washington >>>> William H. Foege Building >>>> Box 355061, Seattle, WA 98195-5061 >>>> 206.685.2119 (tel), 206.685.3300 (shared fax) >>>> >>>> <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> >>>> New Text Book: Enzyme Kinetics for Systems Biology >>>> Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> >>>> >>>> >>>> ____________________________________________________________ >>>> To manage your sbml-discuss list subscription, visit >>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>>> >>>> For a web interface to the sbml-discuss mailing list, visit >>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>>> >>>> For questions or feedback about the sbml-discuss list, >>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >>> ____________________________________________________________ >>> To manage your sbml-discuss list subscription, visit >>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>> >>> For a web interface to the sbml-discuss mailing list, visit >>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>> >>> For questions or feedback about the sbml-discuss list, >>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Lucian Smith — 2013-04-02T01:25:02-00:00

Well, going from *arbitrary* Python code to SED-ML is obviously doomed, just like going from arbitrary Matlab to SBML is doomed, but to use the same analogy, you could use a subset of Python and annotate it to go to sedml again. If SED-ML is going to lure people away from python, it will have to provide something compelling. Traditionally, that's exchangeability and semantics. But you can't expect modelers to give up much (if anything) for these somewhat esoteric benefits. Which means that it would need a robust set of semantics that covered all of what they currently use python for. Which is certainly unknown to me, but sounds like an interesting research effort. -Lucian * Herbert M Sauro <<a href="mailto:hsauro@u.washington.edu" target="_blank">hsauro@u.washington.edu</a>> [2013-04-02 01:28] writes: > > Lucian > > We could indeed go from sbml+sedml to matlab. I wish there was someway to go from a procedural language, eg python or R to sedml. Any one got ideas on how to do that? I suppose one could devise a set of methods in the scripting language that map to the various constructs in sedml but then the user isn't exactly using the script language to its full extent. Eg they can't use the for loop they are familiar with instead they must use the sedml compatible sedmlforlopp() method. > > The fact that this isn't obvious is already setting us up to be not so friendly to users. One would say of course, "the tools will hide all this from the user!", true, but perhaps we could make life easier for tool makers. It would be great if there was an easy mapping both ways between sedml and a procedural language. Eg I get an sedml file from someone, I convert it to python, simulation runs beautifully, however I modify the python, add a loop here a test there and now I want it converted it back to see-ml, not easy. It's things like this that make life difficult for developers, which in turn can result in substandard applications due to the extra effort, which in turn puts off users, which in turn reduces interest in sbml etc. > > I can imagine a worse scenario, someone wires together a set of modules using python, because it is convenient and the current crop of tools are up to wiring modules using sed-ml. How will they convert that to sedml? If I were wiring up a set of submodels I would much rather use a scripting language that I was familiar with than use a tool that might or might not be that great, and might disappear in a years time because a grant failed to materialize. > > I as said before, focus on the user, how do we make their life simpler and more *productive*, that in turn translates how do we make the developers life easier (libsbml is a great example of this). > > Herbert > > Sent from my iPad > > On Apr 1, 2013, at 4:23 PM, Lucian Smith <<a href="mailto:lpsmith@spod-central.org" target="_blank">lpsmith@spod-central.org</a>> wrote: > > > Well, it all comes back to the tools. As Chris mentioned, there is no > > tool that currently could handle a model like the whole-cell model, which > > makes debating what format that tool should use to exchange that model > > with a different nonexistent tool a little moot. But if we posit a future > > where that tool exists, I think it's not terribly unreasonable to guess > > that it might be able to store some of the information it needs to store > > as SED-ML. Yes, it should hide that from its users; they don't need to > > learn SED-ML any more than they need to learn SBML. But when the tools > > start exchanging models like these, it might make the most sense to use > > SED-ML to do it (at least partly). > > > > At the very least, I could envision a translator that took an SBML file > > (or files) plus some SED-ML and translated that to MATLAB. > > > > -Lucian > > > > * hsauro <<a href="mailto:hsauro@u.washington.edu" target="_blank">hsauro@u.washington.edu</a>> [2013-04-01 23:58] writes: > >> I've been listening to this very interesting thread with a lot of good > >> comments from a lot of people. But isn't the suggestion to use SED-ML > >> with it limited capability to describe potentially complex interactions > >> between modules the very thing that would alienate modelers? They would > >> have yet another thing to learn, more inferior in capabilities compared > >> to something like Python (from their point of view) and with much more > >> limited support from tools. Other than the ability to include annotation > >> what other benefit is there to users to employ SED-ML as the glue? One > >> could conceivably add annotation to Python via (CS people close your > >> eyes) comments. I can see SED-ML as means to describe simulation > >> experiments but as a means to coordinate a large set of modules I am not > >> so sure. > >> > >> I feel the push-back we are seeing with SBML and associated standards is > >> that we don't think enough about the end user. I know that because I > >> have to work around certain things in SBML to keep users happy. A recent > >> example is the great MathML debate. After the debate finished I still > >> wasn't able to get any good reason how adding the whole of MathML to > >> SBML would benefit users. That should be the first criterion. SBML was > >> born out of a need by users not developers or computer scientists. I > >> think the community should go back to its roots, find problems that need > >> a solution rather than devise solutions looking for a problem. William > >> Hlavacek listed a number of user problems that need solving, now if > >> adding MathML to SBML can help solve these problems then that is why the > >> rest of MathML should be added. The only other reason to do something > >> like adding the whole of MathML to SBML is for research purposes, ie to > >> explore the possibility of such a change but not for production code > >> until a problem arises where the need is genuine. > >> > >> Herbert > >> > >> On 4/1/2013 3:27 PM, Nicolas Le Novere wrote: > >>> Hi Herbert, > >>> > >>> On 01/04/13 23:09, hsauro wrote: > >>>> I am not sure about using SEDML in this way, we have very good scripting > >>>> languages that can be used to ties module together. > >>> And we have very good scripting languages to encode the models themselves. > >>> Those do not replace SBML though, for many reasons, all of them being > >>> applicable to simulation descriptions. > >>> > >>>> This is what > >>>> compucell3d does, makes it very easy to modify module interactions. The > >>>> one thing that concerns me however (also with compucell3d) is how does > >>>> one decide on the correct time step between running modules? We are so > >>>> careful with setting the right step size for a purely ODE model (Just > >>>> see the amount of care is taken to get events right in simulations) but > >>>> when it comes to very course grained models all that care goes out the > >>>> window. Do people test the model with different time steps to see if the > >>>> solution converges? I haven't read the Cell paper in detail but is this > >>>> what they did to confirm that the simulation converged to a solution? > >>>> > >>>> Herbert > >>>> > >>>> On 4/1/2013 2:55 PM, Moraru,Ion wrote: > >>>>> Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... > >>>>> > >>>>> Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... > >>>>> > >>>>> Ion > >>>>> > >>>>> Sent from my iPad > >>>>> > >>>>> On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: > >>>>> > >>>>>>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. > >>>>>>> > >>>>>> I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to es se > > > > nt > >> i > >>> > >>> a > >>>> l > >>>>> ly > >>>>>> "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. > >>>>>> > >>>>>> Chris > >>>>>> > >>>>>> ____________________________________________________________ > >>>>>> To manage your sbml-discuss list subscription, visit > >>>>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > >>>>>> > >>>>>> For a web interface to the sbml-discuss mailing list, visit > >>>>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > >>>>>> > >>>>>> For questions or feedback about the sbml-discuss list, > >>>>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > >>>>> ____________________________________________________________ > >>>>> To manage your sbml-discuss list subscription, visit > >>>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > >>>>> > >>>>> For a web interface to the sbml-discuss mailing list, visit > >>>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > >>>>> > >>>>> For questions or feedback about the sbml-discuss list, > >>>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > >>>> > >>> > >> > >> > >> -- > >> Herbert M. Sauro, PhD > >> Associate Professor > >> Department of Bioengineering > >> > >> University of Washington > >> William H. Foege Building > >> Box 355061, Seattle, WA 98195-5061 > >> 206.685.2119 (tel), 206.685.3300 (shared fax) > >> > >> <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> > >> New Text Book: Enzyme Kinetics for Systems Biology > >> Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> > >> > >> > >> ____________________________________________________________ > >> To manage your sbml-discuss list subscription, visit > >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > >> > >> For a web interface to the sbml-discuss mailing list, visit > >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > >> > >> For questions or feedback about the sbml-discuss list, > >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > > ____________________________________________________________ > > To manage your sbml-discuss list subscription, visit > > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > > > For a web interface to the sbml-discuss mailing list, visit > > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > > > For questions or feedback about the sbml-discuss list, > > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Herbert M Sauro — 2013-04-02T00:24:25-00:00

Lucian We could indeed go from sbml+sedml to matlab. I wish there was someway to go from a procedural language, eg python or R to sedml. Any one got ideas on how to do that? I suppose one could devise a set of methods in the scripting language that map to the various constructs in sedml but then the user isn't exactly using the script language to its full extent. Eg they can't use the for loop they are familiar with instead they must use the sedml compatible sedmlforlopp() method. The fact that this isn't obvious is already setting us up to be not so friendly to users. One would say of course, "the tools will hide all this from the user!", true, but perhaps we could make life easier for tool makers. It would be great if there was an easy mapping both ways between sedml and a procedural language. Eg I get an sedml file from someone, I convert it to python, simulation runs beautifully, however I modify the python, add a loop here a test there and now I want it converted it back to see-ml, not easy. It's things like this that make life difficult for developers, which in turn can result in substandard applications due to the extra effort, which in turn puts off users, which in turn reduces interest in sbml etc. I can imagine a worse scenario, someone wires together a set of modules using python, because it is convenient and the current crop of tools are up to wiring modules using sed-ml. How will they convert that to sedml? If I were wiring up a set of submodels I would much rather use a scripting language that I was familiar with than use a tool that might or might not be that great, and might disappear in a years time because a grant failed to materialize. I as said before, focus on the user, how do we make their life simpler and more *productive*, that in turn translates how do we make the developers life easier (libsbml is a great example of this). Herbert Sent from my iPad On Apr 1, 2013, at 4:23 PM, Lucian Smith <<a href="mailto:lpsmith@spod-central.org" target="_blank">lpsmith@spod-central.org</a>> wrote: > Well, it all comes back to the tools. As Chris mentioned, there is no > tool that currently could handle a model like the whole-cell model, which > makes debating what format that tool should use to exchange that model > with a different nonexistent tool a little moot. But if we posit a future > where that tool exists, I think it's not terribly unreasonable to guess > that it might be able to store some of the information it needs to store > as SED-ML. Yes, it should hide that from its users; they don't need to > learn SED-ML any more than they need to learn SBML. But when the tools > start exchanging models like these, it might make the most sense to use > SED-ML to do it (at least partly). > > At the very least, I could envision a translator that took an SBML file > (or files) plus some SED-ML and translated that to MATLAB. > > -Lucian > > * hsauro <<a href="mailto:hsauro@u.washington.edu" target="_blank">hsauro@u.washington.edu</a>> [2013-04-01 23:58] writes: >> I've been listening to this very interesting thread with a lot of good >> comments from a lot of people. But isn't the suggestion to use SED-ML >> with it limited capability to describe potentially complex interactions >> between modules the very thing that would alienate modelers? They would >> have yet another thing to learn, more inferior in capabilities compared >> to something like Python (from their point of view) and with much more >> limited support from tools. Other than the ability to include annotation >> what other benefit is there to users to employ SED-ML as the glue? One >> could conceivably add annotation to Python via (CS people close your >> eyes) comments. I can see SED-ML as means to describe simulation >> experiments but as a means to coordinate a large set of modules I am not >> so sure. >> >> I feel the push-back we are seeing with SBML and associated standards is >> that we don't think enough about the end user. I know that because I >> have to work around certain things in SBML to keep users happy. A recent >> example is the great MathML debate. After the debate finished I still >> wasn't able to get any good reason how adding the whole of MathML to >> SBML would benefit users. That should be the first criterion. SBML was >> born out of a need by users not developers or computer scientists. I >> think the community should go back to its roots, find problems that need >> a solution rather than devise solutions looking for a problem. William >> Hlavacek listed a number of user problems that need solving, now if >> adding MathML to SBML can help solve these problems then that is why the >> rest of MathML should be added. The only other reason to do something >> like adding the whole of MathML to SBML is for research purposes, ie to >> explore the possibility of such a change but not for production code >> until a problem arises where the need is genuine. >> >> Herbert >> >> On 4/1/2013 3:27 PM, Nicolas Le Novere wrote: >>> Hi Herbert, >>> >>> On 01/04/13 23:09, hsauro wrote: >>>> I am not sure about using SEDML in this way, we have very good scripting >>>> languages that can be used to ties module together. >>> And we have very good scripting languages to encode the models themselves. >>> Those do not replace SBML though, for many reasons, all of them being >>> applicable to simulation descriptions. >>> >>>> This is what >>>> compucell3d does, makes it very easy to modify module interactions. The >>>> one thing that concerns me however (also with compucell3d) is how does >>>> one decide on the correct time step between running modules? We are so >>>> careful with setting the right step size for a purely ODE model (Just >>>> see the amount of care is taken to get events right in simulations) but >>>> when it comes to very course grained models all that care goes out the >>>> window. Do people test the model with different time steps to see if the >>>> solution converges? I haven't read the Cell paper in detail but is this >>>> what they did to confirm that the simulation converged to a solution? >>>> >>>> Herbert >>>> >>>> On 4/1/2013 2:55 PM, Moraru,Ion wrote: >>>>> Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... >>>>> >>>>> Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... >>>>> >>>>> Ion >>>>> >>>>> Sent from my iPad >>>>> >>>>> On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: >>>>> >>>>>>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. >>>>>>> >>>>>> I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to esse > > nt >> i >>> >>> a >>>> l >>>>> ly >>>>>> "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. >>>>>> >>>>>> Chris >>>>>> >>>>>> ____________________________________________________________ >>>>>> To manage your sbml-discuss list subscription, visit >>>>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>>>>> >>>>>> For a web interface to the sbml-discuss mailing list, visit >>>>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>>>>> >>>>>> For questions or feedback about the sbml-discuss list, >>>>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >>>>> ____________________________________________________________ >>>>> To manage your sbml-discuss list subscription, visit >>>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>>>> >>>>> For a web interface to the sbml-discuss mailing list, visit >>>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>>>> >>>>> For questions or feedback about the sbml-discuss list, >>>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >>>> >>> >> >> >> -- >> Herbert M. Sauro, PhD >> Associate Professor >> Department of Bioengineering >> >> University of Washington >> William H. Foege Building >> Box 355061, Seattle, WA 98195-5061 >> 206.685.2119 (tel), 206.685.3300 (shared fax) >> >> <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> >> New Text Book: Enzyme Kinetics for Systems Biology >> Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> >> >> >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

myers — 2013-04-02T00:11:08-00:00

Right, this is exactly what I was going to say. While we possibly can stitch the simulations together with SED-ML, we keep missing the point which is there does not exist a tool which is capable of building up a simulation in this way. I think we are still a bit fixated on the exchange format when it is not a matter if it can be encoded, but it is a matter of will people encode it. The only way they will do this is if there exists software that makes this easy for them. In some sense, this was the goal of the BioSpice project though it never did quite achieve this for various reasons, many non-technical (maybe too many cooks in the kitchen). Though I think a more software-centric endeavor that sees the standards as a means and not an ends may be the right approach going forward. Chris On Apr 1, 2013, at 5:23 PM, Lucian Smith <<a href="mailto:lpsmith@spod-central.org" target="_blank">lpsmith@spod-central.org</a>> wrote: > Well, it all comes back to the tools. As Chris mentioned, there is no > tool that currently could handle a model like the whole-cell model, which > makes debating what format that tool should use to exchange that model > with a different nonexistent tool a little moot. But if we posit a future > where that tool exists, I think it's not terribly unreasonable to guess > that it might be able to store some of the information it needs to store > as SED-ML. Yes, it should hide that from its users; they don't need to > learn SED-ML any more than they need to learn SBML. But when the tools > start exchanging models like these, it might make the most sense to use > SED-ML to do it (at least partly). > > At the very least, I could envision a translator that took an SBML file > (or files) plus some SED-ML and translated that to MATLAB. > > -Lucian > > * hsauro <<a href="mailto:hsauro@u.washington.edu" target="_blank">hsauro@u.washington.edu</a>> [2013-04-01 23:58] writes: >> I've been listening to this very interesting thread with a lot of good >> comments from a lot of people. But isn't the suggestion to use SED-ML >> with it limited capability to describe potentially complex interactions >> between modules the very thing that would alienate modelers? They would >> have yet another thing to learn, more inferior in capabilities compared >> to something like Python (from their point of view) and with much more >> limited support from tools. Other than the ability to include annotation >> what other benefit is there to users to employ SED-ML as the glue? One >> could conceivably add annotation to Python via (CS people close your >> eyes) comments. I can see SED-ML as means to describe simulation >> experiments but as a means to coordinate a large set of modules I am not >> so sure. >> >> I feel the push-back we are seeing with SBML and associated standards is >> that we don't think enough about the end user. I know that because I >> have to work around certain things in SBML to keep users happy. A recent >> example is the great MathML debate. After the debate finished I still >> wasn't able to get any good reason how adding the whole of MathML to >> SBML would benefit users. That should be the first criterion. SBML was >> born out of a need by users not developers or computer scientists. I >> think the community should go back to its roots, find problems that need >> a solution rather than devise solutions looking for a problem. William >> Hlavacek listed a number of user problems that need solving, now if >> adding MathML to SBML can help solve these problems then that is why the >> rest of MathML should be added. The only other reason to do something >> like adding the whole of MathML to SBML is for research purposes, ie to >> explore the possibility of such a change but not for production code >> until a problem arises where the need is genuine. >> >> Herbert >> >> On 4/1/2013 3:27 PM, Nicolas Le Novere wrote: >>> Hi Herbert, >>> >>> On 01/04/13 23:09, hsauro wrote: >>>> I am not sure about using SEDML in this way, we have very good scripting >>>> languages that can be used to ties module together. >>> And we have very good scripting languages to encode the models themselves. >>> Those do not replace SBML though, for many reasons, all of them being >>> applicable to simulation descriptions. >>> >>>> This is what >>>> compucell3d does, makes it very easy to modify module interactions. The >>>> one thing that concerns me however (also with compucell3d) is how does >>>> one decide on the correct time step between running modules? We are so >>>> careful with setting the right step size for a purely ODE model (Just >>>> see the amount of care is taken to get events right in simulations) but >>>> when it comes to very course grained models all that care goes out the >>>> window. Do people test the model with different time steps to see if the >>>> solution converges? I haven't read the Cell paper in detail but is this >>>> what they did to confirm that the simulation converged to a solution? >>>> >>>> Herbert >>>> >>>> On 4/1/2013 2:55 PM, Moraru,Ion wrote: >>>>> Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... >>>>> >>>>> Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... >>>>> >>>>> Ion >>>>> >>>>> Sent from my iPad >>>>> >>>>> On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: >>>>> >>>>>>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. >>>>>>> >>>>>> I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to esse > nt >> i >>> >>> a >>>> l >>>>> ly >>>>>> "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. >>>>>> >>>>>> Chris >>>>>> >>>>>> ____________________________________________________________ >>>>>> To manage your sbml-discuss list subscription, visit >>>>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>>>>> >>>>>> For a web interface to the sbml-discuss mailing list, visit >>>>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>>>>> >>>>>> For questions or feedback about the sbml-discuss list, >>>>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >>>>> ____________________________________________________________ >>>>> To manage your sbml-discuss list subscription, visit >>>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>>>> >>>>> For a web interface to the sbml-discuss mailing list, visit >>>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>>>> >>>>> For questions or feedback about the sbml-discuss list, >>>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >>>> >>> >> >> >> -- >> Herbert M. Sauro, PhD >> Associate Professor >> Department of Bioengineering >> >> University of Washington >> William H. Foege Building >> Box 355061, Seattle, WA 98195-5061 >> 206.685.2119 (tel), 206.685.3300 (shared fax) >> >> <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> >> New Text Book: Enzyme Kinetics for Systems Biology >> Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> >> >> >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

myers — 2013-04-01T23:58:57-00:00

> Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... > I actually tried to do that in my class this semester. Three students are attempted to encode part of the model as their class project. We'll see how it goes and can report on it at Harmony. > Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... > That is indeed one interesting approach. Chris ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Lucian Smith — 2013-04-01T23:23:17-00:00

Well, it all comes back to the tools. As Chris mentioned, there is no tool that currently could handle a model like the whole-cell model, which makes debating what format that tool should use to exchange that model with a different nonexistent tool a little moot. But if we posit a future where that tool exists, I think it's not terribly unreasonable to guess that it might be able to store some of the information it needs to store as SED-ML. Yes, it should hide that from its users; they don't need to learn SED-ML any more than they need to learn SBML. But when the tools start exchanging models like these, it might make the most sense to use SED-ML to do it (at least partly). At the very least, I could envision a translator that took an SBML file (or files) plus some SED-ML and translated that to MATLAB. -Lucian * hsauro <<a href="mailto:hsauro@u.washington.edu" target="_blank">hsauro@u.washington.edu</a>> [2013-04-01 23:58] writes: > I've been listening to this very interesting thread with a lot of good > comments from a lot of people. But isn't the suggestion to use SED-ML > with it limited capability to describe potentially complex interactions > between modules the very thing that would alienate modelers? They would > have yet another thing to learn, more inferior in capabilities compared > to something like Python (from their point of view) and with much more > limited support from tools. Other than the ability to include annotation > what other benefit is there to users to employ SED-ML as the glue? One > could conceivably add annotation to Python via (CS people close your > eyes) comments. I can see SED-ML as means to describe simulation > experiments but as a means to coordinate a large set of modules I am not > so sure. > > I feel the push-back we are seeing with SBML and associated standards is > that we don't think enough about the end user. I know that because I > have to work around certain things in SBML to keep users happy. A recent > example is the great MathML debate. After the debate finished I still > wasn't able to get any good reason how adding the whole of MathML to > SBML would benefit users. That should be the first criterion. SBML was > born out of a need by users not developers or computer scientists. I > think the community should go back to its roots, find problems that need > a solution rather than devise solutions looking for a problem. William > Hlavacek listed a number of user problems that need solving, now if > adding MathML to SBML can help solve these problems then that is why the > rest of MathML should be added. The only other reason to do something > like adding the whole of MathML to SBML is for research purposes, ie to > explore the possibility of such a change but not for production code > until a problem arises where the need is genuine. > > Herbert > > On 4/1/2013 3:27 PM, Nicolas Le Novere wrote: > > Hi Herbert, > > > > On 01/04/13 23:09, hsauro wrote: > >> I am not sure about using SEDML in this way, we have very good scripting > >> languages that can be used to ties module together. > > And we have very good scripting languages to encode the models themselves. > > Those do not replace SBML though, for many reasons, all of them being > > applicable to simulation descriptions. > > > >> This is what > >> compucell3d does, makes it very easy to modify module interactions. The > >> one thing that concerns me however (also with compucell3d) is how does > >> one decide on the correct time step between running modules? We are so > >> careful with setting the right step size for a purely ODE model (Just > >> see the amount of care is taken to get events right in simulations) but > >> when it comes to very course grained models all that care goes out the > >> window. Do people test the model with different time steps to see if the > >> solution converges? I haven't read the Cell paper in detail but is this > >> what they did to confirm that the simulation converged to a solution? > >> > >> Herbert > >> > >> On 4/1/2013 2:55 PM, Moraru,Ion wrote: > >>> Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... > >>> > >>> Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... > >>> > >>> Ion > >>> > >>> Sent from my iPad > >>> > >>> On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: > >>> > >>>>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. > >>>>> > >>>> I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to esse nt > i > > > > a > >> l > >>> ly > >>>> "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. > >>>> > >>>> Chris > >>>> > >>>> ____________________________________________________________ > >>>> To manage your sbml-discuss list subscription, visit > >>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > >>>> > >>>> For a web interface to the sbml-discuss mailing list, visit > >>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > >>>> > >>>> For questions or feedback about the sbml-discuss list, > >>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > >>> ____________________________________________________________ > >>> To manage your sbml-discuss list subscription, visit > >>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > >>> > >>> For a web interface to the sbml-discuss mailing list, visit > >>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > >>> > >>> For questions or feedback about the sbml-discuss list, > >>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > >> > > > > > -- > Herbert M. Sauro, PhD > Associate Professor > Department of Bioengineering > > University of Washington > William H. Foege Building > Box 355061, Seattle, WA 98195-5061 > 206.685.2119 (tel), 206.685.3300 (shared fax) > > <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> > New Text Book: Enzyme Kinetics for Systems Biology > Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> > > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

hsauro — 2013-04-01T22:55:25-00:00

I've been listening to this very interesting thread with a lot of good comments from a lot of people. But isn't the suggestion to use SED-ML with it limited capability to describe potentially complex interactions between modules the very thing that would alienate modelers? They would have yet another thing to learn, more inferior in capabilities compared to something like Python (from their point of view) and with much more limited support from tools. Other than the ability to include annotation what other benefit is there to users to employ SED-ML as the glue? One could conceivably add annotation to Python via (CS people close your eyes) comments. I can see SED-ML as means to describe simulation experiments but as a means to coordinate a large set of modules I am not so sure. I feel the push-back we are seeing with SBML and associated standards is that we don't think enough about the end user. I know that because I have to work around certain things in SBML to keep users happy. A recent example is the great MathML debate. After the debate finished I still wasn't able to get any good reason how adding the whole of MathML to SBML would benefit users. That should be the first criterion. SBML was born out of a need by users not developers or computer scientists. I think the community should go back to its roots, find problems that need a solution rather than devise solutions looking for a problem. William Hlavacek listed a number of user problems that need solving, now if adding MathML to SBML can help solve these problems then that is why the rest of MathML should be added. The only other reason to do something like adding the whole of MathML to SBML is for research purposes, ie to explore the possibility of such a change but not for production code until a problem arises where the need is genuine. Herbert On 4/1/2013 3:27 PM, Nicolas Le Novere wrote: > Hi Herbert, > > On 01/04/13 23:09, hsauro wrote: >> I am not sure about using SEDML in this way, we have very good scripting >> languages that can be used to ties module together. > And we have very good scripting languages to encode the models themselves. > Those do not replace SBML though, for many reasons, all of them being > applicable to simulation descriptions. > >> This is what >> compucell3d does, makes it very easy to modify module interactions. The >> one thing that concerns me however (also with compucell3d) is how does >> one decide on the correct time step between running modules? We are so >> careful with setting the right step size for a purely ODE model (Just >> see the amount of care is taken to get events right in simulations) but >> when it comes to very course grained models all that care goes out the >> window. Do people test the model with different time steps to see if the >> solution converges? I haven't read the Cell paper in detail but is this >> what they did to confirm that the simulation converged to a solution? >> >> Herbert >> >> On 4/1/2013 2:55 PM, Moraru,Ion wrote: >>> Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... >>> >>> Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... >>> >>> Ion >>> >>> Sent from my iPad >>> >>> On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: >>> >>>>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. >>>>> >>>> I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to essent i > > a >> l >>> ly >>>> "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. >>>> >>>> Chris >>>> >>>> ____________________________________________________________ >>>> To manage your sbml-discuss list subscription, visit >>>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>>> >>>> For a web interface to the sbml-discuss mailing list, visit >>>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>>> >>>> For questions or feedback about the sbml-discuss list, >>>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >>> ____________________________________________________________ >>> To manage your sbml-discuss list subscription, visit >>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>> >>> For a web interface to the sbml-discuss mailing list, visit >>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>> >>> For questions or feedback about the sbml-discuss list, >>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >> > -- Herbert M. Sauro, PhD Associate Professor Department of Bioengineering University of Washington William H. Foege Building Box 355061, Seattle, WA 98195-5061 206.685.2119 (tel), 206.685.3300 (shared fax) <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> New Text Book: Enzyme Kinetics for Systems Biology Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Nicolas Le Novere[1] — 2013-04-01T22:27:24-00:00

Hi Herbert, On 01/04/13 23:09, hsauro wrote: > I am not sure about using SEDML in this way, we have very good scripting > languages that can be used to ties module together. And we have very good scripting languages to encode the models themselves. Those do not replace SBML though, for many reasons, all of them being applicable to simulation descriptions. > This is what > compucell3d does, makes it very easy to modify module interactions. The > one thing that concerns me however (also with compucell3d) is how does > one decide on the correct time step between running modules? We are so > careful with setting the right step size for a purely ODE model (Just > see the amount of care is taken to get events right in simulations) but > when it comes to very course grained models all that care goes out the > window. Do people test the model with different time steps to see if the > solution converges? I haven't read the Cell paper in detail but is this > what they did to confirm that the simulation converged to a solution? > > Herbert > > On 4/1/2013 2:55 PM, Moraru,Ion wrote: >> Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... >> >> Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... >> >> Ion >> >> Sent from my iPad >> >> On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: >> >>>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. >>>> >>> I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to essenti a > l >> >> ly >>> "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. >>> >>> Chris >>> >>> ____________________________________________________________ >>> To manage your sbml-discuss list subscription, visit >>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>> >>> For a web interface to the sbml-discuss mailing list, visit >>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>> >>> For questions or feedback about the sbml-discuss list, >>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > > -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Nicolas Le Novere[1] — 2013-04-01T22:22:17-00:00

On 01/04/13 23:09, hsauro wrote: > I am not sure about using SEDML in this way, we have very good scripting > languages that can be used to ties module together. And we have very good scripting languages to encode the models themselves. Those do not replace SBML though, for many reasons, all of them being applicable to simulation descriptions. > This is what > compucell3d does, makes it very easy to modify module interactions. The > one thing that concerns me however (also with compucell3d) is how does > one decide on the correct time step between running modules? We are so > careful with setting the right step size for a purely ODE model (Just > see the amount of care is taken to get events right in simulations) but > when it comes to very course grained models all that care goes out the > window. Do people test the model with different time steps to see if the > solution converges? I haven't read the Cell paper in detail but is this > what they did to confirm that the simulation converged to a solution? > > Herbert > > On 4/1/2013 2:55 PM, Moraru,Ion wrote: >> Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... >> >> Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... >> >> Ion >> >> Sent from my iPad >> >> On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: >> >>>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. >>>> >>> I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to essenti a > l >> >> ly >>> "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. >>> >>> Chris >>> >>> ____________________________________________________________ >>> To manage your sbml-discuss list subscription, visit >>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>> >>> For a web interface to the sbml-discuss mailing list, visit >>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>> >>> For questions or feedback about the sbml-discuss list, >>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > > -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

hsauro — 2013-04-01T22:09:11-00:00

I am not sure about using SEDML in this way, we have very good scripting languages that can be used to ties module together. This is what compucell3d does, makes it very easy to modify module interactions. The one thing that concerns me however (also with compucell3d) is how does one decide on the correct time step between running modules? We are so careful with setting the right step size for a purely ODE model (Just see the amount of care is taken to get events right in simulations) but when it comes to very course grained models all that care goes out the window. Do people test the model with different time steps to see if the solution converges? I haven't read the Cell paper in detail but is this what they did to confirm that the simulation converged to a solution? Herbert On 4/1/2013 2:55 PM, Moraru,Ion wrote: > Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... > > Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... > > Ion > > Sent from my iPad > > On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: > >>> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. >>> >> I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to essentia l > > ly >> "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. >> >> Chris >> >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> -- Herbert M. Sauro, PhD Associate Professor Department of Bioengineering University of Washington William H. Foege Building Box 355061, Seattle, WA 98195-5061 206.685.2119 (tel), 206.685.3300 (shared fax) <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> New Text Book: Enzyme Kinetics for Systems Biology Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Lucian Smith — 2013-04-01T21:57:09-00:00

* Brett G. Olivier <<a href="mailto:b.g.olivier@vu.nl" target="_blank">b.g.olivier@vu.nl</a>> [2013-04-01 22:36] writes: > > On 2013/04/01 09:54 PM, Chris J. Myers wrote: > >> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. > >> > > I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to essenti al > ly > > "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. > > One of issues which interested me (if I remember correctly) is the use > of a dynamic FBA approach for one module where one effectively embeds an > FBA model in an ODE. Just out of interest, could you do this sort of > thing with "comp" (or other package) where for example you might have a > function which contains the output of an entire FBC model ( which has > been parameterised by that function)? This is also something which would > become increasingly relevant in multi-species ecosystem modelling? I don't believe that comp and fbc will give you this out of the box, but it'll get you some of the way there. It *might* be possible to do this with a combination of comp and fbc and sedml, since you can tell sedml 'take the output of this experiment and use it as input for this other experiment'. (This would, of course, require that sedml be extended to allow fbc in the first place.) At present, comp allows you to to decompose a model, but doesn't allow you to decompose an analysis in this way. A lot of the machinery that *would* let you do such a thing is there, though. I bet if there was a tool that allowed you to perform the analysis, it wouldn't be too hard to figure out from that what new information needed to be stored in the sbml file. -Lucian ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: [SED-ML-discuss] People, we need a reboot.

Ion — 2013-04-01T21:55:45-00:00

Just having each of the modules available in SBML format would have been (would be) useful to many. I thought about having some of my sysbio grad students do it in the fall, but too much work... Interestingly enough, the connection between the modules (and thus the whole model), which all run independently for a second before cross-updating variables, could actually be specified in SED-ML using the repeated task proposal - if the modules themselves would be in SBML... Ion Sent from my iPad On Apr 1, 2013, at 3:54 PM, "Chris J. Myers" <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> wrote: >> >> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. >> > I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to essential ly > "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. > > Chris > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

b.g.olivier — 2013-04-01T21:31:12-00:00

On 2013/04/01 09:54 PM, Chris J. Myers wrote: >> Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. >> > I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to essential ly > "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. One of issues which interested me (if I remember correctly) is the use of a dynamic FBA approach for one module where one effectively embeds an FBA model in an ODE. Just out of interest, could you do this sort of thing with "comp" (or other package) where for example you might have a function which contains the output of an entire FBC model ( which has been parameterised by that function)? This is also something which would become increasingly relevant in multi-species ecosystem modelling? > > Chris > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> -- Dr Brett G. Olivier Researcher in Computational Systems Biology Dept. Molecular Cell Physiology VU University Amsterdam Email: b.g.olivier[AT]vu[dot]nl Tel: +31 (0)20 592 4265 ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

myers — 2013-04-01T19:54:17-00:00

> > Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. > I can comment a bit on this one. There are several issues which made it difficult for them to use SBML. First, their model is actually composed of many different types of models for each cellular process. There was no good way to hook together models in SBML, but I think this has largely been addressed with the recently finalized comp package. Second, one type of modeling used was flux balance which was not well supported within standard SBML. This issue has also been addressed with the recently finalized fbc package. I feel reasonably confident that one could encode their model within SBML, but here is the rub, it could not be analyzed by any tool that I'm aware of. This, as I mentioned before, is the critical issue which is people are not choosing to not code their models in SBML, they are simply unable to find a tool that allows them to code their models that supports SBML. In this case, they must resort to a general tool like MATLAB that allows them to essentially "program" their model. So, I think that one thing that is important going forward is to (a) develop tools that allow hybrid modeling and analysis such as used in the whole-cell model and/or (b) develop means of connecting analysis tools that support the different types of analysis. I think if either of these existed, then we would have an easy time convincing people to use this as they would have the added benefit of an exchangeable model. Chris ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Ben Heavner — 2013-04-01T18:02:39-00:00

p.s. Other opportunities arise from come from curation of network reconstructions, whether algorithmic such as the model SEED (<a href="http://seed-viewer.theseed.org/seedviewer.cgi?page=ModelView" target="_blank">http://seed-viewer.theseed.org/seedviewer.cgi?page=ModelView</a> ), or via collaborative efforts such as the human metabolic network (<a href="http://humanmetabolism.org/" target="_blank">http://humanmetabolism.org/</a>) or the yeast metabolic network (<a href="http://yeast.sf.net" target="_blank">http://yeast.sf.net</a>) And in general, the sharing of regulator networks seems to be a fairly open problem.

Re: People, we need a reboot.

Ben Heavner — 2013-04-01T17:43:41-00:00

As a model developer and user, I think Chris raises a really essential point that provides a great way to frame the discussion as we consider future directions for SBML: let's look at what model developers are doing now, and why they aren't using SBML in some cases. So, what's going on that isn't being passed around in SBML? From the constraint based approach, certainly the COBRA Toolbox is widely used. It currently requires custom notes annotations due to limitations with SBML when the software was developed, and a lack of updates to better support newer standards. (The details of the custom notes fields and other naming peculiarities are described in DOI:10.1038/nprot.2007.99 and supplement S1 to DOI:10.1038/nprot.2011.308). Daniel Hyduke is a primary developer the COBRA Toolbox, and I think he's planning to go to COMBINE. Among other things, he's currently working on writing a python version of the COBRA Toolbox, so being able to pass models between MATLAB and python is pretty important. Looking forward, there is clear interest in the constraint-based modeling community in 1) integrating more mechanistic detail with the constraint based approach (such as in DOI:10.1038/ncomms1928); 2) to developing methods for integrating gene regulatory networks with constraint based networks such as Sriram Chandrasekaran's work on PROM (DOI: 10.1038/ncomms1928, and the recent review by Blazier and Papin at DOI:10.3389/fphys.2012.00299); and 3) generating novel sets of constraints on achievable fluxes derived from thermodynamic calculations or novel data sets. At the moment, the first approach is most amenable to SBML than the latter models. Extending SBML to support the third seems like it shouldn't be too hard, though it's unclear what issues will arise. I know that the Pathway Tools folks at SRI are ramping up their support for SBML. It would be great to be able to import a COBRA-generated SBML file to build a pathway database in pathway tools, and to export a pathway database to an SBML file with minimal loss of data (including reversion histories, notes, etc.) I think Peter Karp is also planning to come to Combine, so there's great opportunity to learn about how SBML could work better for that work, too. Another key modeling approach, of course, is the statistical inference of regulatory networks, such as the EGRIN-like approaches developed in the Baliga lab here at the Institute for Systems Biology - <a href="http://baliga.systemsbiology.net/drupal/content/egrin." target="_blank">http://baliga.systemsbiology.net/drupal/content/egrin.</a> Sam Danziger is probably the best ISB postdoc contact for learning more about that. Further, the Covert group is currently working on another whole-cell model, presumably using their same MATLAB-based software. There's opportunity to get input from them, too. I think it is of paramount importance to consider how SBML can continue to evolve to support these existing research directions. If the tools aren't easy, researchers will keep doing things like passing around matlab .mat files. - Ben <table border="0" align="center" width="90%" cellpadding="3" cellspacing="1"><tr><td class="SmallText">myers wrote on 31 Mar '13 13:10</td></tr><tr><td class="quote"> when we consider the future of SBML, we have to look at why modelers are not using tools which support SBML (not why they are not using SBML). A good case in point is the Karr et al whole-cell model. Mike and I have had some discussion with them, and they do see the benefits of having their model encoded in SBML though they also were unable to find a tool that allowed them to construct their model in the way they wanted that supported SBML. For this reason, they ended up hand crafting it in matlab (probably the tool that most modelers resort to when they cannot use our tools). So, I would argue that when a modeling effort does not use SBML that this is not due to the fact that SBML is not up to the task but rather our tools are not up to it. Therefore, we should look at the reasons why, update our tools to support those efforts, and then, if necessary, advocate enhancements to SBML so we can exchange models. Despite the slow pace of these enhancements (which can be frustrating), I still feel pretty positive about the state of SBML. I don't think we need to be discouraged by disagreements and discussions, they are all part of the process. </td></tr></table>

Re: People, we need a reboot.

Ion — 2013-04-01T01:44:21-00:00

So many great points in Bob Phair's discourse. Quoting my favorite one: > So the SBML re-boot does not, in my view, require that we support > statistical systems biology. They simply have a fundamentally different > mindset from a modeler's mindset. And while a lot of people will make a > lot > of money in statistical systems biology, they will, I think, not solve > diseases without help from mechanistic modeling. > Exactly. If SBML will help bring to life mechanistic modeling in the -omics world, it will be a wildly successful "reboot". For all parties. Ion ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Bill Hlavacek — 2013-04-01T01:30:46-00:00

FYI - there are good meetings that serve the community interested in modeling (modelers, theorists and quantitative experimentalists), such as the Annual q-bio Conference: <a href="http://q-bio.org/wiki/The_q-bio_Summer_School_and_Conference" target="_blank">http://q-bio.org/wiki/The_q-bio_Summer_School_and_Conference</a> The q-bio Conference and the affiliated summer school are supported by grants from NIH/NIGMS, so I think/hope they are here to stay. Instead of trying to sell modeling to communities that attend meetings where modeling is hardly discussed, why not support the q-bio and other similar conferences and the communities that have emerged around these conferences? If you're a modeler, the q-bio is a great place to meet an experimentalist interested in collaborating, and vice versa. --Bill On 3/31/13 6:57 PM, "Robert Phair" <<a href="mailto:rphair@integrativebioinformatics.com" target="_blank">rphair@integrativebioinformatics.com</a>> wrote: >Fellow SBML folks: > >This thread, in my view, is focused on the wrong problem. > >It's easy to imagine that the 'real' scientists doing systems biology are >ignoring SBML. I suspect they think we are not even DOING systems biology. >I've watched and been a part of the biological modeling community for 45 >years, beginning long before the "systems biology" trademark was invented. >Many of you antedate this term too. Hiroaki's genius was to link dynamic >modeling to the rising star of systems biology. We have all benefited from >this brilliant association, and someday I hope someone will tell me how he >did it. > >But this association has a dark or shadow side. It has drawn us away from >our biological roots, and the vast majority of 'real' systems biologists >don't even care that we exist. Just as Nicolas says. To me, it's obvious >that systems biology is a house divided. High throughput, -omics, and >statistics on one side, mechanistic modeling on the other. No one here >will >need to be reminded that the -omics folks hold the high ground. They >consume the lion's share of the funding and the press in systems biology. >This is the shadow result of linking biological modeling to high >throughput >biotech under the rubric of systems biology. > >Sometime in the 1990s, Ruedi Aebersold (definitely a 'real' systems >biologist) invited me to share the keynote stage with Lee Hood at a >systems >biology meeting in Seattle. I was stunned, but when Ruedi said he wanted >me >to cover the modeling side of systems biology while Lee covered the -omics >side, there was no way I was going to refuse. I remember this like it was >yesterday. Two things stand out. With absolutely no pre-meeting >discussion, >Lee Hood and I had essentially identical first slides - both were versions >of Karl Popper's scientific hypothesis testing paradigm. My talk was on an >experiment/modeling project I did in collaboration with the >Lippincott-Schwartz lab at the NIH - a project that was eventually >published in *Cell*. But the questions from the audience were hostile. One >said bluntly that our work was not systems biology. > >So it does not surprise me that Nicolas and Hiroaki felt snubbed at a >Nobel-organized systems biology meeting. Nor do I think it matters. > >It does not matter because our real goal, in my view, is to serve >biologists, not systems biologists. > >It's easy to conclude that high throughput and -omics and GWAS and >dendrograms and personalized medicine and all manner of statistical models >are still where the future lies. It's certainly where the money and >prestige currently reside. But from my perspective the -omics side of >systems biology is best seen as a source of new (and often totally >unexpected) hypotheses - hypotheses that must then be tested by >mechanistic >experimental biology coupled with mechanistic modeling. The >little-discussed fact is that most statistical systems biology projects >have failed to live up to expectations. In the corporate world, where you >need far more than a paper in Science or Nature to count yourself a >success, one pharmaceutical company after another has shuttered its >statistical systems biology operations. > >For this and other reasons, the 'real' systems biologists who might snub >SBML at a Nobel SB symposium, would themselves be snubbed by the 'real' >biologists who are winning Nobel prizes and leading all the world's >scientific societies organized around experimental biology. > >But those experimental biologists are faced with a fundamentally >insurmountable problem. They have no tools to handle complexity. All of us >know that the tools of dynamic mechanistic modeling can help. Some of us >even think mechanistic modeling is essential if your goal is to solve >complex diseases like heart disease, diabetes, obesity, mental illness, >cancer, immune disorders, and stroke. > >So the SBML re-boot does not, in my view, require that we support >statistical systems biology. They simply have a fundamentally different >mindset from a modeler's mindset. And while a lot of people will make a >lot >of money in statistical systems biology, they will, I think, not solve >diseases without help from mechanistic modeling. > >One of the best things about CellML is their role in the IUPS >international >"physiome" project. They have a clear focus on cardiovascular physiology >and pathophysiology, and they have tight ties with the American >Physiological Society (APS). But given the historical antipathy, within >the >APS, to Arthur Guyton's modeling convictions, it's possible that CellML is >as much an "outsider" in the APS as Nicolas felt at the Nobel systems >biology symposium. > >I think we have an opportunity to forge an incredibly powerful alliance >with several other scientific societies. Given our historical connection >to >metabolism, one of those societies should be the American Society for >Biochemistry and Molecular Biology (ASBMB). Nicolas is right about many >things, but he is wrong about central metabolism being "done." *Cell >Metabolism* is filled with articles that weekly shed fundamentally new >light on all the things we we thought we knew from biochemistry. The two >other societies that SBML people have solid connections with are the >American Society for Cell Biology (ASCB) and the Society for Neuroscience >(SFN). These are both incredible scientific organizations. Their members >are the people who need our help and the people we want to serve. Some of >you will have other societies in mind. I don't know where the power lies >in >European or Asian biology, but the SBML community must know. > >There is a lot more to be said about this, particularly about how we forge >a team that includes our colleagues in places like CellML and BioPax. But >those are not the subject of this thread. Moreover, you may be thinking >that model interchange standards are a long way from experimental biology >and none of those societies will listen to advocates of something so >arcane >as SBML. > >What you will find as we approach these societies is that it is the very >concept of modeling that we still need to sell. SBML will then be easy to >sell because biology will never realize the full power of modeling unless >all the modeling that's done in the world can be exchanged and combined to >understand complexity and improve quality of life. > >It will not be an easy sell. The best experimental biologists in the world >have good reason to believe they are making progress without modeling. >Many >are math averse. But they are beginning to see how daunting complexity can >be. There are, for example, hundreds of finished gene-knockout experiments >gathering dust in laboratory notebooks, unpublished because the >experimenters simply do not understand the results. > >Mechanistic modeling is the key. SBML assures that the key will work for >everyone. > >Bob > >Robert D Phair PhD | Chief Science Officer | Integrative >Bioinformatics >Inc >Mountain View, CA >www.integrativebioinformatics.com > >ProcessDB: Modeling for Biological Discovery > > >On Sun, Mar 31, 2013 at 2:00 PM, Moraru,Ion <<a href="mailto:moraru@panda.uchc.edu" target="_blank">moraru@panda.uchc.edu</a>> wrote: > >> Excellent! I wholeheartedly agree, and I sincerely would like to see >>the >> shock therapy succeed. I would like to add just one specific detail: I >> believe that if SBML will not be relevant for the fledgling, but rapidly >> expanding large-scale modeling efforts in personalized medicine and >> -omics-based therapeutics, there is little hope. I had considered >>asking >> Edison Liu to give a keynote talk at HARMONY in May, but then I >> reconsidered, as I saw that the connection really isn't there (yet). >> Perhaps I should re-reconsider, although the few brave souls >>participating >> and keeping things moving probably do not need more stimulus... >> >> Ion >> >> > -----Original Message----- >> > From: <a href="mailto:sbml-discuss-bounces@caltech.edu" target="_blank">sbml-discuss-bounces@caltech.edu</a> [mailto:sbml-discuss- >> > <a href="mailto:bounces@caltech.edu]" target="_blank">bounces@caltech.edu]</a> On Behalf Of Nicolas Le Novere >> > Sent: Sunday, March 31, 2013 2:54 PM >> > To: SBML Discussion List >> > Subject: Re: [sbml-discuss] People, we need a reboot. >> > >> > Hello all, >> > >> > Since Mike mentioned my message, I repost it here, only modified to >> > make it >> > less SBML editors centric. >> > >> > I did actually express myself on the subject of SBML adequacy to >> > modeling >> > in systems biology before. During several years, I expressed myself >> > privately, mostly to Mike, because I wanted to try to improve the >> > situation >> > quietly and internally. At COMBINE 2011 I came public >> > (slide: >> > <a href="http://co.mbine.org/events/COMBINE_2011/agenda?q=system/files/2011-09-" target="_blank">http://co.mbine.org/events/COMBINE_2011/agenda?q=system/files/2011-09-</a> >> > 05-combine-lenovere-future-of-sbml.pdf) >> > (video: >> > <a href="http://co.mbine.org/sites/combine/files/2011-09-05-combine-" target="_blank">http://co.mbine.org/sites/combine/files/2011-09-05-combine-</a> >> > lenovere.mov) >> > >> > Later I started a discussion with the SBML editors. Some traces of >>that >> > can >> > be found at: >> > <a href="http://sbml.org/Discussions/SBML_Future" target="_blank">http://sbml.org/Discussions/SBML_Future</a> >> > >> > The following mail was meant to be a sort of provocative electroshock. >> > Therefore, some part of it are pretty blunt, even by my standard. I >> > realize >> > that the it may antagonize some of you. I hope you will realize it is >> > not >> > meant as an attack on your scientific and technical achievements or >>the >> > value of your support to SBML, and that the antagonism energy will >> > result >> > in useful discussions. >> > >> > First I would like to present how I see the situation (SBML situation >> > in >> > the scientific research landscape is critical), then some explanations >> > (we >> > are completely cut from our own community, and the attitude push away >> > anyone wanting to help), and finally possible ways forward. >> > >> > Note that I have personal stakes in SBML. I devoted a very important >> > part >> > of my time, energy and money to SBML and related projects. Since 2004, >> > most >> > of my group budget (EMBL internal fund) was injected in standard >> > development instead of research. I sort of neglected the research part >> > of >> > my group and jeopardized my scientific career in the process. So, in >> > addition to my intimate conviction that interoperability and data >> > exchange >> > and re-use is crucial for scientific research, I have a pretty big >> > interest >> > in standards (and SBML at the forefront) being something important, >> > recognized and successful. And at the moment this is not the case. >> > >> > What is the situation? The simple fact is that nowadays SBML is >> > inadequate >> > and irrelevant for research in *biology* (I will not disentangle >> > irrelevance and inadequacy below). Most people developing models in >> > biology >> > never heard of it, and even less use it. But it is a bit worse than >> > that. >> > SBML has also become irrelevant for research in *systems biology*. A >> > specific subset of systems biology research, dealing with the modeling >> > of >> > metabolic networks, sometimes uses SBML (but see the paper published >> > Hubner >> > et al in 2011 <a href="http://identifiers.org/pubmed/21707921." target="_blank">http://identifiers.org/pubmed/21707921.</a> Even for this >> > perfect >> > target community, sets of ODEs, generally written in MatLab, and now >>in >> > R, >> > are the norm). This community used to be important in what would >>become >> > systems biology, and was the major part of the funding group of SBML >> > (some >> > of the funding groups were already not able to use SBML to encode >>their >> > models though, but hoped this would come eventually, and it kind of >>did >> > in >> > some cases). This is not the case anymore. Central metabolism is done. >> > Some >> > tuning is needed here and there, but mostly this is not front page >> > science >> > anymore (there are exceptions, such as the recent Recon2 work. But the >> > challenges there were the size and the accuracy of the reconstruction, >> > not >> > the modeling per se). >> > >> > People working on signaling pathways do not mainly use kinetic >> > simulations >> > of process description models (although some do, and with success). >> > They >> > need to describe exploding signaling pathways, influence diagrams >> > generated >> > by phenotypic matrices or gene expression data etc. (for an example, >> > see >> > the recent article of Peter Sorger that started the current >> > discussion). >> > The mathematical modelers on the other hand - arguably the primary >> > initial >> > target of SBML - are now doing models at a different level, in term of >> > size >> > and complexity of models. This complexity covers the number and >> > diversity >> > of approaches used, the multi-scale aspects, or the statistical and >> > probabilistic treatments (see for examples the Mycoplasma work of Karr >> > et >> > al, or the multiscale models developed by the virtual liver network). >> > >> > From 2003 until 2007, SBML boosted the field (of computational >>systems >> > biology), and aspects like controlled annotations created new needs >> > that >> > further made SBML filling a niche. It was clear that the use of SBML >>at >> > the >> > core was the reason BioModels Database grew so fast (the resource >> > itself >> > being initially conceived as a professional version of the SBML >> > repository). From 2007/8 the situation reversed. SBML started to keep >> > BioModels back (I am not complaining. I am using BioModels Db as a >> > proxy >> > for SBML importance). It became more and more frequent that people >> > contacted us to submit models, and we had to turn them down because >> > unable >> > to accept them. >> > >> > In June 2009, I attended a Nobel symposium on Systems Biology. Note >> > that I >> > was an observer, as was Kitano. The speakers were the "real" >>scientists >> > in >> > the domain, Lee Hood, Mike Snyder, Stanislas Leibler, Luis Serrano >>etc. >> > We >> > are talking labs of 30+ people, H-index above 50, chairs in multiple >> > universities etc. (I know you must frown or shudder at the mention of >> > those >> > criteria, but this is part of the issue I think. Systems biologists we >> > should be getting support from are in a different dimension than us in >> > terms of science. We seem to have built a little delusion around >> > ourselves >> > about that. I still remember when some members of the community wanted >> > to >> > publish press releases because SBML reached 500 citations with ISI. >> > That >> > was a bit embarrassing). Anyway, I spent a few days there, and tried >>to >> > discuss SBML with those scientists. Less than a dozen speakers even >> > heard >> > about it. And they mostly dismissed it with a shrug (there were >> > exceptions, >> > e.g. Berhnard Palsson). >> > >> > Since then, the situation has become steadily worse. The SBML >>community >> > represents a shrinking part of the computational systems biology one, >> > and >> > some of our former supporters left us. The last nail in the coffin for >> > me >> > came when I read a comment from a reviewer asking why the community >> > needed >> > SBML since there was BioPAX. I had heard the opposite comment a few >> > times, >> > but that one never! And before you get all flustered and start your >> > cries >> > of outrage about the differences between BioPAX and SBML (my initial >> > reaction), stop. Nothing you can say matters the least. It will all be >> > little technicalities, completely lost on an audience not made of SBML >> > specialists. Nothing that could not be fixed in half a month with some >> > copy/paste. The fact is that SBML at the moment is mostly used in a >> > scientifically significant manner for encoding pathways. The >> > mathematical >> > modeling part, as important as it is, has become anecdotal. >> > >> > So how comes we ended in that situation? 2000, the cream of systems >> > biology >> > nucleate around the ERATO Kitano team to launch what remains the only >> > successful community standard in biology. 2012, we can barely get 50 >> > people >> > to meet at the annual meeting, most of the attendees being paid or >> > supported by the coordinators. There are a variety of reasons, but I >> > believe they can be clustered in two topics: the lack of interaction >> > with >> > who we are supposed to serve, and the attitude we have towards >>everyone >> > else. I believe the absence of evolution of SBML, which is the reason >> > of >> > its current alleged inadequacy, is actually a symptom, not a cause. >>(It >> > must be clear that I consider myself as part of the problem. This >> > entire >> > mail is not a "guys you screwed up" but "guys we screwed up"). >> > >> > In 2000, the group of modelers gathered by the ERATO team represented >> > some >> > of the top groups in the field of modeling in systems biology. Sure, >> > they >> > were also tool developers, but at that time, it was kind of >>synonymous. >> > The >> > current structure of SBML was inherited (with many modifications, but >> > not >> > fundamental ones) from a format developed by specialists of metabolic >> > modeling (see <a href="http://en.wikipedia.org/wiki/SBML" target="_blank">http://en.wikipedia.org/wiki/SBML</a>). That presented three >> > interests. The first was that SBML was able to encode the models >> > developed >> > by the scientists, the second was that developers were able to spread >> > the >> > word on SBML in the right circles. And third, SBML had legitimacy. The >> > latter is crucial. People use what they helped to develop. If that was >> > not >> > the case, there would not have been a SBML in the first place. Joining >> > the >> > Modelica effort would have been far more sensible. I'll come back to >> > this >> > point when discussing solutions. Anyway, the SBML creators came from >> > groups >> > publishing in Nature/Science/PNAS, giving keynotes in computational >> > biology >> > conferences etc. (including >> > the then nascent ICSB). Today, the "top" (I will not elaborate on what >> > I >> > mean by top. It is beside the point) modelers out there, the >>equivalent >> > of >> > our group in 2000, are working on integration of OMICs data with >> > pathways, >> > virtual cells, virtual organs, multicellular tissues etc. They are >> > still >> > publishing in the same journals and giving keynotes though. We know >> > where >> > to find them, but we do not link enough. >> > >> > The second cause of our current problems is the attitude we adopt when >> > facing anyone who is not from the inner circle. This is not new, and >> > sometimes unconscious. The first attitude is pedantic posing. In 2007, >> > coming back from the SBML hackathon in Newcastle, one of my students >> > told >> > me how miserable a time she had there, because of the impossibility to >> > understand or participate to the discussions we had, some of them in >> > breakout rooms without advance warning, or in bars at night etc. She >> > felt >> > completely excluded. Since then, we have become more and more >> > technical, >> > pedant and irrelevant. I won the gold medal with the "dangling >> > references". >> > We make no efforts to link with uninitiated people, and then complain >> > that >> > they do not understand us. Technical difficulty is the light version >>of >> > it. >> > The heavy one is when we interact for instance with people who ask >> > "what is >> > the difference between CellML and SBML", and the answer is some polite >> > form >> > of "if you don't know you are too idiot to talk to me", or with people >> > mentioning (OK, complaining) that SBML does not support X or Y, and we >> > answer either "why don't you develop a package" or "actually if you >> > tweak >> > Z, you can encode something that would be equivalent of X". Rather >>than >> > welcoming outside people and extending our community to include them, >> > we >> > push them away or try to force "them" to become "us", which demands so >> > much >> > effort (see first attitude), that it is not worth it for them. I went >> > through all these attitudes with the partners of DDMoRe and I learned >>a >> > lot. The consequences are multiple, some are a decrease of attendance >> > to >> > the meetings, no candidates for elections, and also bad mouthing about >> > SBML >> > etc. >> > >> > Anyway, whatever the causes, SBML is largely ignored by "modeling" >>that >> > matters, and its mention brings blank stares, condescending smiles or >> > bitter remark according to the audience. This is a situation that >> > cannot be >> > solved by bending our current rules or "making efforts". We are way >> > past >> > that. The fact that some of us do not realize it is precisely part of >> > the >> > problem. We are so far disconnected from what should be our community >> > that >> > we do not realize they do not like us. The choice we face is either a >> > shock >> > treatment, that can succeed or let us crippled, or continue what we >>are >> > currently doing, which is taking morphine to make our disappearance >> > less >> > painful. Here are three things we could do very quickly to shake >>things >> > a >> > bit. I am sure there are plenty of others. And the more brainstorming >> > the >> > better. "Storm" is a word I would love to associate to SBML, rather >> > than >> > mild breeze ... So please, go wild. >> > >> > >> > [ >> > my initial message contained the following proposal: >> > >> > "Create a SAB >> > ============ >> > >> > Scientific advisory boards can be seen as an unnecessary burden, but >> > they >> > are useful on several plans: SABs bring people from the "outside", who >> > are >> > not directly involved with our SBML work and can bring fresh ideas. We >> > can >> > put in SAB VIPs, who could not be editors because of time limitation, >> > but >> > have an overview of the field, know where the money is etc. SAB >>members >> > would become aware of SBML and SBML evolution, and would spread this >> > knowledge. Finally, SAB members are not involved in the practical >> > development of the language, and are not tied by political, >> > psychological >> > or emotional issues. Therefore they could detect dysfunctions and >> > advise. >> > People I am thinking of are along the lines of >> > Doug Kell, Berhnard Palsson, Dirk Drasdo, Peter Sorger, Michael >> > Elowitz, >> > Gary Bader etc. (names are just indications). " >> > >> > I am very happy that we now have an SAB, and that it comprises Doug >> > Kell >> > and Dirk Drasdo. It is also interesting that I put Peter there :-) >> > ] >> > >> > Official working groups, formed and led by relevant scientists >> > ============================================================== >> > >> > We need to bring back the scientists who really develop models to >> > answer >> > biological questions. Qual works because it is developed by scientists >> > actually developing qualitative models and relevant tools. They >>develop >> > the >> > qual package and therefore are using it. We should extend this >> > practice. To >> > reach a community not covered by SBML, we need to make this community >> > develops its own structure, the way it wishes too. It is no good to >> > tell >> > them "extend what exists, contribute". Formats, terminologies and >>tools >> > never worked that way. We wish they would, but they do not. People do >> > not >> > feel involved if they are not in charge, and they do not get reward. >>So >> > the >> > reaction is "format X supports most of what we do, but does not >>support >> > feature Y, let's develop our own format Z, that will cover all we do". >> > We >> > should make easier for Z to be part of SBML (package when it comes to >> > L3). >> > For qualitative models, there is now a small community called >>Colomoto, >> > and >> > part of its activity is to develop qual and tools to support qual. We >> > should identify a handful of people for spatial modeling (the spatial >> > package is great, but it will only be supported if other tool >> > developers/modelers feel involved), for tissue/multi-cellular >>modeling, >> > for >> > statistical models etc. >> > >> > Large survey on modeling systems biology and physiology >> > ======================================================= >> > >> > Launch a communication effort, in the form of a survey gathering >>needs, >> > practices and experiences in modeling biological systems. The stated >> > objective would be to pave the way to the next generation format. We >> > would >> > try to spread the survey as much as possible, by targeting social >> > networks, >> > mailing-lists, but also private e-mails. The analysis of the survey >> > would >> > lead to a publication that we would target as high as possible. This >>is >> > the >> > kind of thing Nature Biotech would potentially accept. >> > >> > What else? >> > >> > >> > >> > On 30/03/13 21:02, Michael Hucka wrote: >> > > Hi Peter, >> > > >> > > Thank you for joining sbml-discuss and writing your recent message. >> > The PySB paper, your comments as well as those of Bob Phair, Bill >> > Hlavacek and others, juxtaposed with the recent discussion about >>MathML >> > subsets on this list, have served to demonstrate how badly change is >> > needed here. >> > > >> > > Last August, Nicolas Le Novère started a discussion on the internal >> > SBML Editors' list about the state of SBML and the community around >>it. >> > It was a follow-up to a public discussion he started at the COMBINE >> > meeting last year. I hope Nicolas will restate his message, because >>as >> > brutal as his words were, there is now no question in mind that he's >> > right. His basic point was this: while a decade ago, SBML may have >> > been an instrumental enabler of modeling in systems biology, today it >> > is not adequately serving modelers because the landscape of research >> > has shifted and SBML has not kept up; worse, the core SBML community >> > has frankly become insular, hidebound and focused on technicalities >> > rather than on supporting what modelers want. >> > > >> > > To some people on this list, these words will come as a surprise, >>and >> > I hope that Nicolas will follow up with a longer explanation based on >> > his experiences over the past decade. But really, a little bit of >> > reflection should be enough to realize there's a problem. It took us >>a >> > decade to implement modularity in SBML. SBML still hasn't >>standardized >> > support for rule-based models, to say nothing of multicellular models, >> > or spatial models. And where are our users -- the modelers? How many >> > of them are involved in this conversation? 5? 10? (Yes, some of you >> > are here -- thank you -- but the point is, there's not enough of you.) >> > > >> > > I don't mean to be rude to the rest of you, or to spread blame; I'm >> > one of the worst offenders, and as the person ostensibly in the best >> > position to steer SBML's evolution, I surely deserve the most blame >>for >> > the current rut. Please, everyone, let's skip the standard flurry of >> > defensive messages and cries of outrage, and focus on how we will turn >> > things around. >> > > >> > > There are modeling applications that SBML (even the bits of SBML >> > still on the drawing board) handles poorly at best. To understand >> > what's needed, we need the involvement of scientists who are actually >> > using and developing those techniques, like Peter and others. We need >> > to bring back the people we've pushed away too. How do we get them >> > engaged? And how do we keep them engaged? (It won't be by arguing >> > about MathML subsets.) That's the first problem we have to solve. In >> > solving it, we have to keep in mind what Bob Phair wrote: "Newcomers >> > have to be convinced that our only goal is creation of a standard that >> > a larger and larger community of systems biologists and experimental >> > biologists can embrace." >> > > >> > > We need their help to design a new generation of SBML. We have a >> > dozen years of experience getting things to this point; we can use >>that >> > knowledge to craft a better format that encompasses more needs, in a >> > more flexible and extensible manner, with modern features such as >> > better integration with semantic web technologies. We have libraries >> > whose APIs can hide the actual format, to smooth the transition for >> > software and protect the investment of developers who have spent >> > tremendous resources supporting SBML over the years. We're well- >> > positioned for that challenge. >> > > >> > > But if we don't regain our users and reboot the conversation, it >> > won't matter. >> > > >> > > MH >> > > ____________________________________________________________ >> > > To manage your sbml-discuss list subscription, visit >> > > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> > > >> > > For a web interface to the sbml-discuss mailing list, visit >> > > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> > > >> > > For questions or feedback about the sbml-discuss list, >> > > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >> > > >> > >> > >> > -- >> > Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 >> > 3AT >> > Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 >> > twitter:@lenovere >> > Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 >> > <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> >> > >> > ____________________________________________________________ >> > To manage your sbml-discuss list subscription, visit >> > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> > >> > For a web interface to the sbml-discuss mailing list, visit >> > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> > >> > For questions or feedback about the sbml-discuss list, >> > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >> >____________________________________________________________ >To manage your sbml-discuss list subscription, visit ><a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > >For a web interface to the sbml-discuss mailing list, visit ><a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > >For questions or feedback about the sbml-discuss list, >contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Robert Phair — 2013-04-01T00:57:42-00:00

Fellow SBML folks: This thread, in my view, is focused on the wrong problem. It's easy to imagine that the 'real' scientists doing systems biology are ignoring SBML. I suspect they think we are not even DOING systems biology. I've watched and been a part of the biological modeling community for 45 years, beginning long before the "systems biology" trademark was invented. Many of you antedate this term too. Hiroaki's genius was to link dynamic modeling to the rising star of systems biology. We have all benefited from this brilliant association, and someday I hope someone will tell me how he did it. But this association has a dark or shadow side. It has drawn us away from our biological roots, and the vast majority of 'real' systems biologists don't even care that we exist. Just as Nicolas says. To me, it's obvious that systems biology is a house divided. High throughput, -omics, and statistics on one side, mechanistic modeling on the other. No one here will need to be reminded that the -omics folks hold the high ground. They consume the lion's share of the funding and the press in systems biology. This is the shadow result of linking biological modeling to high throughput biotech under the rubric of systems biology. Sometime in the 1990s, Ruedi Aebersold (definitely a 'real' systems biologist) invited me to share the keynote stage with Lee Hood at a systems biology meeting in Seattle. I was stunned, but when Ruedi said he wanted me to cover the modeling side of systems biology while Lee covered the -omics side, there was no way I was going to refuse. I remember this like it was yesterday. Two things stand out. With absolutely no pre-meeting discussion, Lee Hood and I had essentially identical first slides - both were versions of Karl Popper's scientific hypothesis testing paradigm. My talk was on an experiment/modeling project I did in collaboration with the Lippincott-Schwartz lab at the NIH - a project that was eventually published in *Cell*. But the questions from the audience were hostile. One said bluntly that our work was not systems biology. So it does not surprise me that Nicolas and Hiroaki felt snubbed at a Nobel-organized systems biology meeting. Nor do I think it matters. It does not matter because our real goal, in my view, is to serve biologists, not systems biologists. It's easy to conclude that high throughput and -omics and GWAS and dendrograms and personalized medicine and all manner of statistical models are still where the future lies. It's certainly where the money and prestige currently reside. But from my perspective the -omics side of systems biology is best seen as a source of new (and often totally unexpected) hypotheses - hypotheses that must then be tested by mechanistic experimental biology coupled with mechanistic modeling. The little-discussed fact is that most statistical systems biology projects have failed to live up to expectations. In the corporate world, where you need far more than a paper in Science or Nature to count yourself a success, one pharmaceutical company after another has shuttered its statistical systems biology operations. For this and other reasons, the 'real' systems biologists who might snub SBML at a Nobel SB symposium, would themselves be snubbed by the 'real' biologists who are winning Nobel prizes and leading all the world's scientific societies organized around experimental biology. But those experimental biologists are faced with a fundamentally insurmountable problem. They have no tools to handle complexity. All of us know that the tools of dynamic mechanistic modeling can help. Some of us even think mechanistic modeling is essential if your goal is to solve complex diseases like heart disease, diabetes, obesity, mental illness, cancer, immune disorders, and stroke. So the SBML re-boot does not, in my view, require that we support statistical systems biology. They simply have a fundamentally different mindset from a modeler's mindset. And while a lot of people will make a lot of money in statistical systems biology, they will, I think, not solve diseases without help from mechanistic modeling. One of the best things about CellML is their role in the IUPS international "physiome" project. They have a clear focus on cardiovascular physiology and pathophysiology, and they have tight ties with the American Physiological Society (APS). But given the historical antipathy, within the APS, to Arthur Guyton's modeling convictions, it's possible that CellML is as much an "outsider" in the APS as Nicolas felt at the Nobel systems biology symposium. I think we have an opportunity to forge an incredibly powerful alliance with several other scientific societies. Given our historical connection to metabolism, one of those societies should be the American Society for Biochemistry and Molecular Biology (ASBMB). Nicolas is right about many things, but he is wrong about central metabolism being "done." *Cell Metabolism* is filled with articles that weekly shed fundamentally new light on all the things we we thought we knew from biochemistry. The two other societies that SBML people have solid connections with are the American Society for Cell Biology (ASCB) and the Society for Neuroscience (SFN). These are both incredible scientific organizations. Their members are the people who need our help and the people we want to serve. Some of you will have other societies in mind. I don't know where the power lies in European or Asian biology, but the SBML community must know. There is a lot more to be said about this, particularly about how we forge a team that includes our colleagues in places like CellML and BioPax. But those are not the subject of this thread. Moreover, you may be thinking that model interchange standards are a long way from experimental biology and none of those societies will listen to advocates of something so arcane as SBML. What you will find as we approach these societies is that it is the very concept of modeling that we still need to sell. SBML will then be easy to sell because biology will never realize the full power of modeling unless all the modeling that's done in the world can be exchanged and combined to understand complexity and improve quality of life. It will not be an easy sell. The best experimental biologists in the world have good reason to believe they are making progress without modeling. Many are math averse. But they are beginning to see how daunting complexity can be. There are, for example, hundreds of finished gene-knockout experiments gathering dust in laboratory notebooks, unpublished because the experimenters simply do not understand the results. Mechanistic modeling is the key. SBML assures that the key will work for everyone. Bob Robert D Phair PhD | Chief Science Officer | Integrative Bioinformatics Inc Mountain View, CA www.integrativebioinformatics.com ProcessDB: Modeling for Biological Discovery On Sun, Mar 31, 2013 at 2:00 PM, Moraru,Ion <<a href="mailto:moraru@panda.uchc.edu" target="_blank">moraru@panda.uchc.edu</a>> wrote: > Excellent! I wholeheartedly agree, and I sincerely would like to see the > shock therapy succeed. I would like to add just one specific detail: I > believe that if SBML will not be relevant for the fledgling, but rapidly > expanding large-scale modeling efforts in personalized medicine and > -omics-based therapeutics, there is little hope. I had considered asking > Edison Liu to give a keynote talk at HARMONY in May, but then I > reconsidered, as I saw that the connection really isn't there (yet). > Perhaps I should re-reconsider, although the few brave souls participating > and keeping things moving probably do not need more stimulus... > > Ion > > > -----Original Message----- > > From: <a href="mailto:sbml-discuss-bounces@caltech.edu" target="_blank">sbml-discuss-bounces@caltech.edu</a> [mailto:sbml-discuss- > > <a href="mailto:bounces@caltech.edu]" target="_blank">bounces@caltech.edu]</a> On Behalf Of Nicolas Le Novere > > Sent: Sunday, March 31, 2013 2:54 PM > > To: SBML Discussion List > > Subject: Re: [sbml-discuss] People, we need a reboot. > > > > Hello all, > > > > Since Mike mentioned my message, I repost it here, only modified to > > make it > > less SBML editors centric. > > > > I did actually express myself on the subject of SBML adequacy to > > modeling > > in systems biology before. During several years, I expressed myself > > privately, mostly to Mike, because I wanted to try to improve the > > situation > > quietly and internally. At COMBINE 2011 I came public > > (slide: > > <a href="http://co.mbine.org/events/COMBINE_2011/agenda?q=system/files/2011-09-" target="_blank">http://co.mbine.org/events/COMBINE_2011/agenda?q=system/files/2011-09-</a> > > 05-combine-lenovere-future-of-sbml.pdf) > > (video: > > <a href="http://co.mbine.org/sites/combine/files/2011-09-05-combine-" target="_blank">http://co.mbine.org/sites/combine/files/2011-09-05-combine-</a> > > lenovere.mov) > > > > Later I started a discussion with the SBML editors. Some traces of that > > can > > be found at: > > <a href="http://sbml.org/Discussions/SBML_Future" target="_blank">http://sbml.org/Discussions/SBML_Future</a> > > > > The following mail was meant to be a sort of provocative electroshock. > > Therefore, some part of it are pretty blunt, even by my standard. I > > realize > > that the it may antagonize some of you. I hope you will realize it is > > not > > meant as an attack on your scientific and technical achievements or the > > value of your support to SBML, and that the antagonism energy will > > result > > in useful discussions. > > > > First I would like to present how I see the situation (SBML situation > > in > > the scientific research landscape is critical), then some explanations > > (we > > are completely cut from our own community, and the attitude push away > > anyone wanting to help), and finally possible ways forward. > > > > Note that I have personal stakes in SBML. I devoted a very important > > part > > of my time, energy and money to SBML and related projects. Since 2004, > > most > > of my group budget (EMBL internal fund) was injected in standard > > development instead of research. I sort of neglected the research part > > of > > my group and jeopardized my scientific career in the process. So, in > > addition to my intimate conviction that interoperability and data > > exchange > > and re-use is crucial for scientific research, I have a pretty big > > interest > > in standards (and SBML at the forefront) being something important, > > recognized and successful. And at the moment this is not the case. > > > > What is the situation? The simple fact is that nowadays SBML is > > inadequate > > and irrelevant for research in *biology* (I will not disentangle > > irrelevance and inadequacy below). Most people developing models in > > biology > > never heard of it, and even less use it. But it is a bit worse than > > that. > > SBML has also become irrelevant for research in *systems biology*. A > > specific subset of systems biology research, dealing with the modeling > > of > > metabolic networks, sometimes uses SBML (but see the paper published > > Hubner > > et al in 2011 <a href="http://identifiers.org/pubmed/21707921." target="_blank">http://identifiers.org/pubmed/21707921.</a> Even for this > > perfect > > target community, sets of ODEs, generally written in MatLab, and now in > > R, > > are the norm). This community used to be important in what would become > > systems biology, and was the major part of the funding group of SBML > > (some > > of the funding groups were already not able to use SBML to encode their > > models though, but hoped this would come eventually, and it kind of did > > in > > some cases). This is not the case anymore. Central metabolism is done. > > Some > > tuning is needed here and there, but mostly this is not front page > > science > > anymore (there are exceptions, such as the recent Recon2 work. But the > > challenges there were the size and the accuracy of the reconstruction, > > not > > the modeling per se). > > > > People working on signaling pathways do not mainly use kinetic > > simulations > > of process description models (although some do, and with success). > > They > > need to describe exploding signaling pathways, influence diagrams > > generated > > by phenotypic matrices or gene expression data etc. (for an example, > > see > > the recent article of Peter Sorger that started the current > > discussion). > > The mathematical modelers on the other hand - arguably the primary > > initial > > target of SBML - are now doing models at a different level, in term of > > size > > and complexity of models. This complexity covers the number and > > diversity > > of approaches used, the multi-scale aspects, or the statistical and > > probabilistic treatments (see for examples the Mycoplasma work of Karr > > et > > al, or the multiscale models developed by the virtual liver network). > > > > From 2003 until 2007, SBML boosted the field (of computational systems > > biology), and aspects like controlled annotations created new needs > > that > > further made SBML filling a niche. It was clear that the use of SBML at > > the > > core was the reason BioModels Database grew so fast (the resource > > itself > > being initially conceived as a professional version of the SBML > > repository). From 2007/8 the situation reversed. SBML started to keep > > BioModels back (I am not complaining. I am using BioModels Db as a > > proxy > > for SBML importance). It became more and more frequent that people > > contacted us to submit models, and we had to turn them down because > > unable > > to accept them. > > > > In June 2009, I attended a Nobel symposium on Systems Biology. Note > > that I > > was an observer, as was Kitano. The speakers were the "real" scientists > > in > > the domain, Lee Hood, Mike Snyder, Stanislas Leibler, Luis Serrano etc. > > We > > are talking labs of 30+ people, H-index above 50, chairs in multiple > > universities etc. (I know you must frown or shudder at the mention of > > those > > criteria, but this is part of the issue I think. Systems biologists we > > should be getting support from are in a different dimension than us in > > terms of science. We seem to have built a little delusion around > > ourselves > > about that. I still remember when some members of the community wanted > > to > > publish press releases because SBML reached 500 citations with ISI. > > That > > was a bit embarrassing). Anyway, I spent a few days there, and tried to > > discuss SBML with those scientists. Less than a dozen speakers even > > heard > > about it. And they mostly dismissed it with a shrug (there were > > exceptions, > > e.g. Berhnard Palsson). > > > > Since then, the situation has become steadily worse. The SBML community > > represents a shrinking part of the computational systems biology one, > > and > > some of our former supporters left us. The last nail in the coffin for > > me > > came when I read a comment from a reviewer asking why the community > > needed > > SBML since there was BioPAX. I had heard the opposite comment a few > > times, > > but that one never! And before you get all flustered and start your > > cries > > of outrage about the differences between BioPAX and SBML (my initial > > reaction), stop. Nothing you can say matters the least. It will all be > > little technicalities, completely lost on an audience not made of SBML > > specialists. Nothing that could not be fixed in half a month with some > > copy/paste. The fact is that SBML at the moment is mostly used in a > > scientifically significant manner for encoding pathways. The > > mathematical > > modeling part, as important as it is, has become anecdotal. > > > > So how comes we ended in that situation? 2000, the cream of systems > > biology > > nucleate around the ERATO Kitano team to launch what remains the only > > successful community standard in biology. 2012, we can barely get 50 > > people > > to meet at the annual meeting, most of the attendees being paid or > > supported by the coordinators. There are a variety of reasons, but I > > believe they can be clustered in two topics: the lack of interaction > > with > > who we are supposed to serve, and the attitude we have towards everyone > > else. I believe the absence of evolution of SBML, which is the reason > > of > > its current alleged inadequacy, is actually a symptom, not a cause. (It > > must be clear that I consider myself as part of the problem. This > > entire > > mail is not a "guys you screwed up" but "guys we screwed up"). > > > > In 2000, the group of modelers gathered by the ERATO team represented > > some > > of the top groups in the field of modeling in systems biology. Sure, > > they > > were also tool developers, but at that time, it was kind of synonymous. > > The > > current structure of SBML was inherited (with many modifications, but > > not > > fundamental ones) from a format developed by specialists of metabolic > > modeling (see <a href="http://en.wikipedia.org/wiki/SBML" target="_blank">http://en.wikipedia.org/wiki/SBML</a>). That presented three > > interests. The first was that SBML was able to encode the models > > developed > > by the scientists, the second was that developers were able to spread > > the > > word on SBML in the right circles. And third, SBML had legitimacy. The > > latter is crucial. People use what they helped to develop. If that was > > not > > the case, there would not have been a SBML in the first place. Joining > > the > > Modelica effort would have been far more sensible. I'll come back to > > this > > point when discussing solutions. Anyway, the SBML creators came from > > groups > > publishing in Nature/Science/PNAS, giving keynotes in computational > > biology > > conferences etc. (including > > the then nascent ICSB). Today, the "top" (I will not elaborate on what > > I > > mean by top. It is beside the point) modelers out there, the equivalent > > of > > our group in 2000, are working on integration of OMICs data with > > pathways, > > virtual cells, virtual organs, multicellular tissues etc. They are > > still > > publishing in the same journals and giving keynotes though. We know > > where > > to find them, but we do not link enough. > > > > The second cause of our current problems is the attitude we adopt when > > facing anyone who is not from the inner circle. This is not new, and > > sometimes unconscious. The first attitude is pedantic posing. In 2007, > > coming back from the SBML hackathon in Newcastle, one of my students > > told > > me how miserable a time she had there, because of the impossibility to > > understand or participate to the discussions we had, some of them in > > breakout rooms without advance warning, or in bars at night etc. She > > felt > > completely excluded. Since then, we have become more and more > > technical, > > pedant and irrelevant. I won the gold medal with the "dangling > > references". > > We make no efforts to link with uninitiated people, and then complain > > that > > they do not understand us. Technical difficulty is the light version of > > it. > > The heavy one is when we interact for instance with people who ask > > "what is > > the difference between CellML and SBML", and the answer is some polite > > form > > of "if you don't know you are too idiot to talk to me", or with people > > mentioning (OK, complaining) that SBML does not support X or Y, and we > > answer either "why don't you develop a package" or "actually if you > > tweak > > Z, you can encode something that would be equivalent of X". Rather than > > welcoming outside people and extending our community to include them, > > we > > push them away or try to force "them" to become "us", which demands so > > much > > effort (see first attitude), that it is not worth it for them. I went > > through all these attitudes with the partners of DDMoRe and I learned a > > lot. The consequences are multiple, some are a decrease of attendance > > to > > the meetings, no candidates for elections, and also bad mouthing about > > SBML > > etc. > > > > Anyway, whatever the causes, SBML is largely ignored by "modeling" that > > matters, and its mention brings blank stares, condescending smiles or > > bitter remark according to the audience. This is a situation that > > cannot be > > solved by bending our current rules or "making efforts". We are way > > past > > that. The fact that some of us do not realize it is precisely part of > > the > > problem. We are so far disconnected from what should be our community > > that > > we do not realize they do not like us. The choice we face is either a > > shock > > treatment, that can succeed or let us crippled, or continue what we are > > currently doing, which is taking morphine to make our disappearance > > less > > painful. Here are three things we could do very quickly to shake things > > a > > bit. I am sure there are plenty of others. And the more brainstorming > > the > > better. "Storm" is a word I would love to associate to SBML, rather > > than > > mild breeze ... So please, go wild. > > > > > > [ > > my initial message contained the following proposal: > > > > "Create a SAB > > ============ > > > > Scientific advisory boards can be seen as an unnecessary burden, but > > they > > are useful on several plans: SABs bring people from the "outside", who > > are > > not directly involved with our SBML work and can bring fresh ideas. We > > can > > put in SAB VIPs, who could not be editors because of time limitation, > > but > > have an overview of the field, know where the money is etc. SAB members > > would become aware of SBML and SBML evolution, and would spread this > > knowledge. Finally, SAB members are not involved in the practical > > development of the language, and are not tied by political, > > psychological > > or emotional issues. Therefore they could detect dysfunctions and > > advise. > > People I am thinking of are along the lines of > > Doug Kell, Berhnard Palsson, Dirk Drasdo, Peter Sorger, Michael > > Elowitz, > > Gary Bader etc. (names are just indications). " > > > > I am very happy that we now have an SAB, and that it comprises Doug > > Kell > > and Dirk Drasdo. It is also interesting that I put Peter there :-) > > ] > > > > Official working groups, formed and led by relevant scientists > > ============================================================== > > > > We need to bring back the scientists who really develop models to > > answer > > biological questions. Qual works because it is developed by scientists > > actually developing qualitative models and relevant tools. They develop > > the > > qual package and therefore are using it. We should extend this > > practice. To > > reach a community not covered by SBML, we need to make this community > > develops its own structure, the way it wishes too. It is no good to > > tell > > them "extend what exists, contribute". Formats, terminologies and tools > > never worked that way. We wish they would, but they do not. People do > > not > > feel involved if they are not in charge, and they do not get reward. So > > the > > reaction is "format X supports most of what we do, but does not support > > feature Y, let's develop our own format Z, that will cover all we do". > > We > > should make easier for Z to be part of SBML (package when it comes to > > L3). > > For qualitative models, there is now a small community called Colomoto, > > and > > part of its activity is to develop qual and tools to support qual. We > > should identify a handful of people for spatial modeling (the spatial > > package is great, but it will only be supported if other tool > > developers/modelers feel involved), for tissue/multi-cellular modeling, > > for > > statistical models etc. > > > > Large survey on modeling systems biology and physiology > > ======================================================= > > > > Launch a communication effort, in the form of a survey gathering needs, > > practices and experiences in modeling biological systems. The stated > > objective would be to pave the way to the next generation format. We > > would > > try to spread the survey as much as possible, by targeting social > > networks, > > mailing-lists, but also private e-mails. The analysis of the survey > > would > > lead to a publication that we would target as high as possible. This is > > the > > kind of thing Nature Biotech would potentially accept. > > > > What else? > > > > > > > > On 30/03/13 21:02, Michael Hucka wrote: > > > Hi Peter, > > > > > > Thank you for joining sbml-discuss and writing your recent message. > > The PySB paper, your comments as well as those of Bob Phair, Bill > > Hlavacek and others, juxtaposed with the recent discussion about MathML > > subsets on this list, have served to demonstrate how badly change is > > needed here. > > > > > > Last August, Nicolas Le NovÃ¨re started a discussion on the internal > > SBML Editors' list about the state of SBML and the community around it. > > It was a follow-up to a public discussion he started at the COMBINE > > meeting last year. I hope Nicolas will restate his message, because as > > brutal as his words were, there is now no question in mind that he's > > right. His basic point was this: while a decade ago, SBML may have > > been an instrumental enabler of modeling in systems biology, today it > > is not adequately serving modelers because the landscape of research > > has shifted and SBML has not kept up; worse, the core SBML community > > has frankly become insular, hidebound and focused on technicalities > > rather than on supporting what modelers want. > > > > > > To some people on this list, these words will come as a surprise, and > > I hope that Nicolas will follow up with a longer explanation based on > > his experiences over the past decade. But really, a little bit of > > reflection should be enough to realize there's a problem. It took us a > > decade to implement modularity in SBML. SBML still hasn't standardized > > support for rule-based models, to say nothing of multicellular models, > > or spatial models. And where are our users -- the modelers? How many > > of them are involved in this conversation? 5? 10? (Yes, some of you > > are here -- thank you -- but the point is, there's not enough of you.) > > > > > > I don't mean to be rude to the rest of you, or to spread blame; I'm > > one of the worst offenders, and as the person ostensibly in the best > > position to steer SBML's evolution, I surely deserve the most blame for > > the current rut. Please, everyone, let's skip the standard flurry of > > defensive messages and cries of outrage, and focus on how we will turn > > things around. > > > > > > There are modeling applications that SBML (even the bits of SBML > > still on the drawing board) handles poorly at best. To understand > > what's needed, we need the involvement of scientists who are actually > > using and developing those techniques, like Peter and others. We need > > to bring back the people we've pushed away too. How do we get them > > engaged? And how do we keep them engaged? (It won't be by arguing > > about MathML subsets.) That's the first problem we have to solve. In > > solving it, we have to keep in mind what Bob Phair wrote: "Newcomers > > have to be convinced that our only goal is creation of a standard that > > a larger and larger community of systems biologists and experimental > > biologists can embrace." > > > > > > We need their help to design a new generation of SBML. We have a > > dozen years of experience getting things to this point; we can use that > > knowledge to craft a better format that encompasses more needs, in a > > more flexible and extensible manner, with modern features such as > > better integration with semantic web technologies. We have libraries > > whose APIs can hide the actual format, to smooth the transition for > > software and protect the investment of developers who have spent > > tremendous resources supporting SBML over the years. We're well- > > positioned for that challenge. > > > > > > But if we don't regain our users and reboot the conversation, it > > won't matter. > > > > > > MH > > > ____________________________________________________________ > > > To manage your sbml-discuss list subscription, visit > > > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > > > > > For a web interface to the sbml-discuss mailing list, visit > > > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > > > > > For questions or feedback about the sbml-discuss list, > > > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > > > > > > > > > -- > > Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 > > 3AT > > Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 > > twitter:@lenovere > > Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 > > <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> > > > > ____________________________________________________________ > > To manage your sbml-discuss list subscription, visit > > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > > > For a web interface to the sbml-discuss mailing list, visit > > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > > > For questions or feedback about the sbml-discuss list, > > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Ion — 2013-03-31T21:00:42-00:00

Excellent! I wholeheartedly agree, and I sincerely would like to see the shock therapy succeed. I would like to add just one specific detail: I believe that if SBML will not be relevant for the fledgling, but rapidly expanding large-scale modeling efforts in personalized medicine and -omics-based therapeutics, there is little hope. I had considered asking Edison Liu to give a keynote talk at HARMONY in May, but then I reconsidered, as I saw that the connection really isn't there (yet). Perhaps I should re-reconsider, although the few brave souls participating and keeping things moving probably do not need more stimulus... Ion > -----Original Message----- > From: <a href="mailto:sbml-discuss-bounces@caltech.edu" target="_blank">sbml-discuss-bounces@caltech.edu</a> [mailto:sbml-discuss- > <a href="mailto:bounces@caltech.edu]" target="_blank">bounces@caltech.edu]</a> On Behalf Of Nicolas Le Novere > Sent: Sunday, March 31, 2013 2:54 PM > To: SBML Discussion List > Subject: Re: [sbml-discuss] People, we need a reboot. > > Hello all, > > Since Mike mentioned my message, I repost it here, only modified to > make it > less SBML editors centric. > > I did actually express myself on the subject of SBML adequacy to > modeling > in systems biology before. During several years, I expressed myself > privately, mostly to Mike, because I wanted to try to improve the > situation > quietly and internally. At COMBINE 2011 I came public > (slide: > <a href="http://co.mbine.org/events/COMBINE_2011/agenda?q=system/files/2011-09-" target="_blank">http://co.mbine.org/events/COMBINE_2011/agenda?q=system/files/2011-09-</a> > 05-combine-lenovere-future-of-sbml.pdf) > (video: > <a href="http://co.mbine.org/sites/combine/files/2011-09-05-combine-" target="_blank">http://co.mbine.org/sites/combine/files/2011-09-05-combine-</a> > lenovere.mov) > > Later I started a discussion with the SBML editors. Some traces of that > can > be found at: > <a href="http://sbml.org/Discussions/SBML_Future" target="_blank">http://sbml.org/Discussions/SBML_Future</a> > > The following mail was meant to be a sort of provocative electroshock. > Therefore, some part of it are pretty blunt, even by my standard. I > realize > that the it may antagonize some of you. I hope you will realize it is > not > meant as an attack on your scientific and technical achievements or the > value of your support to SBML, and that the antagonism energy will > result > in useful discussions. > > First I would like to present how I see the situation (SBML situation > in > the scientific research landscape is critical), then some explanations > (we > are completely cut from our own community, and the attitude push away > anyone wanting to help), and finally possible ways forward. > > Note that I have personal stakes in SBML. I devoted a very important > part > of my time, energy and money to SBML and related projects. Since 2004, > most > of my group budget (EMBL internal fund) was injected in standard > development instead of research. I sort of neglected the research part > of > my group and jeopardized my scientific career in the process. So, in > addition to my intimate conviction that interoperability and data > exchange > and re-use is crucial for scientific research, I have a pretty big > interest > in standards (and SBML at the forefront) being something important, > recognized and successful. And at the moment this is not the case. > > What is the situation? The simple fact is that nowadays SBML is > inadequate > and irrelevant for research in *biology* (I will not disentangle > irrelevance and inadequacy below). Most people developing models in > biology > never heard of it, and even less use it. But it is a bit worse than > that. > SBML has also become irrelevant for research in *systems biology*. A > specific subset of systems biology research, dealing with the modeling > of > metabolic networks, sometimes uses SBML (but see the paper published > Hubner > et al in 2011 <a href="http://identifiers.org/pubmed/21707921." target="_blank">http://identifiers.org/pubmed/21707921.</a> Even for this > perfect > target community, sets of ODEs, generally written in MatLab, and now in > R, > are the norm). This community used to be important in what would become > systems biology, and was the major part of the funding group of SBML > (some > of the funding groups were already not able to use SBML to encode their > models though, but hoped this would come eventually, and it kind of did > in > some cases). This is not the case anymore. Central metabolism is done. > Some > tuning is needed here and there, but mostly this is not front page > science > anymore (there are exceptions, such as the recent Recon2 work. But the > challenges there were the size and the accuracy of the reconstruction, > not > the modeling per se). > > People working on signaling pathways do not mainly use kinetic > simulations > of process description models (although some do, and with success). > They > need to describe exploding signaling pathways, influence diagrams > generated > by phenotypic matrices or gene expression data etc. (for an example, > see > the recent article of Peter Sorger that started the current > discussion). > The mathematical modelers on the other hand - arguably the primary > initial > target of SBML - are now doing models at a different level, in term of > size > and complexity of models. This complexity covers the number and > diversity > of approaches used, the multi-scale aspects, or the statistical and > probabilistic treatments (see for examples the Mycoplasma work of Karr > et > al, or the multiscale models developed by the virtual liver network). > > From 2003 until 2007, SBML boosted the field (of computational systems > biology), and aspects like controlled annotations created new needs > that > further made SBML filling a niche. It was clear that the use of SBML at > the > core was the reason BioModels Database grew so fast (the resource > itself > being initially conceived as a professional version of the SBML > repository). From 2007/8 the situation reversed. SBML started to keep > BioModels back (I am not complaining. I am using BioModels Db as a > proxy > for SBML importance). It became more and more frequent that people > contacted us to submit models, and we had to turn them down because > unable > to accept them. > > In June 2009, I attended a Nobel symposium on Systems Biology. Note > that I > was an observer, as was Kitano. The speakers were the "real" scientists > in > the domain, Lee Hood, Mike Snyder, Stanislas Leibler, Luis Serrano etc. > We > are talking labs of 30+ people, H-index above 50, chairs in multiple > universities etc. (I know you must frown or shudder at the mention of > those > criteria, but this is part of the issue I think. Systems biologists we > should be getting support from are in a different dimension than us in > terms of science. We seem to have built a little delusion around > ourselves > about that. I still remember when some members of the community wanted > to > publish press releases because SBML reached 500 citations with ISI. > That > was a bit embarrassing). Anyway, I spent a few days there, and tried to > discuss SBML with those scientists. Less than a dozen speakers even > heard > about it. And they mostly dismissed it with a shrug (there were > exceptions, > e.g. Berhnard Palsson). > > Since then, the situation has become steadily worse. The SBML community > represents a shrinking part of the computational systems biology one, > and > some of our former supporters left us. The last nail in the coffin for > me > came when I read a comment from a reviewer asking why the community > needed > SBML since there was BioPAX. I had heard the opposite comment a few > times, > but that one never! And before you get all flustered and start your > cries > of outrage about the differences between BioPAX and SBML (my initial > reaction), stop. Nothing you can say matters the least. It will all be > little technicalities, completely lost on an audience not made of SBML > specialists. Nothing that could not be fixed in half a month with some > copy/paste. The fact is that SBML at the moment is mostly used in a > scientifically significant manner for encoding pathways. The > mathematical > modeling part, as important as it is, has become anecdotal. > > So how comes we ended in that situation? 2000, the cream of systems > biology > nucleate around the ERATO Kitano team to launch what remains the only > successful community standard in biology. 2012, we can barely get 50 > people > to meet at the annual meeting, most of the attendees being paid or > supported by the coordinators. There are a variety of reasons, but I > believe they can be clustered in two topics: the lack of interaction > with > who we are supposed to serve, and the attitude we have towards everyone > else. I believe the absence of evolution of SBML, which is the reason > of > its current alleged inadequacy, is actually a symptom, not a cause. (It > must be clear that I consider myself as part of the problem. This > entire > mail is not a "guys you screwed up" but "guys we screwed up"). > > In 2000, the group of modelers gathered by the ERATO team represented > some > of the top groups in the field of modeling in systems biology. Sure, > they > were also tool developers, but at that time, it was kind of synonymous. > The > current structure of SBML was inherited (with many modifications, but > not > fundamental ones) from a format developed by specialists of metabolic > modeling (see <a href="http://en.wikipedia.org/wiki/SBML" target="_blank">http://en.wikipedia.org/wiki/SBML</a>). That presented three > interests. The first was that SBML was able to encode the models > developed > by the scientists, the second was that developers were able to spread > the > word on SBML in the right circles. And third, SBML had legitimacy. The > latter is crucial. People use what they helped to develop. If that was > not > the case, there would not have been a SBML in the first place. Joining > the > Modelica effort would have been far more sensible. I'll come back to > this > point when discussing solutions. Anyway, the SBML creators came from > groups > publishing in Nature/Science/PNAS, giving keynotes in computational > biology > conferences etc. (including > the then nascent ICSB). Today, the "top" (I will not elaborate on what > I > mean by top. It is beside the point) modelers out there, the equivalent > of > our group in 2000, are working on integration of OMICs data with > pathways, > virtual cells, virtual organs, multicellular tissues etc. They are > still > publishing in the same journals and giving keynotes though. We know > where > to find them, but we do not link enough. > > The second cause of our current problems is the attitude we adopt when > facing anyone who is not from the inner circle. This is not new, and > sometimes unconscious. The first attitude is pedantic posing. In 2007, > coming back from the SBML hackathon in Newcastle, one of my students > told > me how miserable a time she had there, because of the impossibility to > understand or participate to the discussions we had, some of them in > breakout rooms without advance warning, or in bars at night etc. She > felt > completely excluded. Since then, we have become more and more > technical, > pedant and irrelevant. I won the gold medal with the "dangling > references". > We make no efforts to link with uninitiated people, and then complain > that > they do not understand us. Technical difficulty is the light version of > it. > The heavy one is when we interact for instance with people who ask > "what is > the difference between CellML and SBML", and the answer is some polite > form > of "if you don't know you are too idiot to talk to me", or with people > mentioning (OK, complaining) that SBML does not support X or Y, and we > answer either "why don't you develop a package" or "actually if you > tweak > Z, you can encode something that would be equivalent of X". Rather than > welcoming outside people and extending our community to include them, > we > push them away or try to force "them" to become "us", which demands so > much > effort (see first attitude), that it is not worth it for them. I went > through all these attitudes with the partners of DDMoRe and I learned a > lot. The consequences are multiple, some are a decrease of attendance > to > the meetings, no candidates for elections, and also bad mouthing about > SBML > etc. > > Anyway, whatever the causes, SBML is largely ignored by "modeling" that > matters, and its mention brings blank stares, condescending smiles or > bitter remark according to the audience. This is a situation that > cannot be > solved by bending our current rules or "making efforts". We are way > past > that. The fact that some of us do not realize it is precisely part of > the > problem. We are so far disconnected from what should be our community > that > we do not realize they do not like us. The choice we face is either a > shock > treatment, that can succeed or let us crippled, or continue what we are > currently doing, which is taking morphine to make our disappearance > less > painful. Here are three things we could do very quickly to shake things > a > bit. I am sure there are plenty of others. And the more brainstorming > the > better. "Storm" is a word I would love to associate to SBML, rather > than > mild breeze ... So please, go wild. > > > [ > my initial message contained the following proposal: > > "Create a SAB > ============ > > Scientific advisory boards can be seen as an unnecessary burden, but > they > are useful on several plans: SABs bring people from the "outside", who > are > not directly involved with our SBML work and can bring fresh ideas. We > can > put in SAB VIPs, who could not be editors because of time limitation, > but > have an overview of the field, know where the money is etc. SAB members > would become aware of SBML and SBML evolution, and would spread this > knowledge. Finally, SAB members are not involved in the practical > development of the language, and are not tied by political, > psychological > or emotional issues. Therefore they could detect dysfunctions and > advise. > People I am thinking of are along the lines of > Doug Kell, Berhnard Palsson, Dirk Drasdo, Peter Sorger, Michael > Elowitz, > Gary Bader etc. (names are just indications). " > > I am very happy that we now have an SAB, and that it comprises Doug > Kell > and Dirk Drasdo. It is also interesting that I put Peter there :-) > ] > > Official working groups, formed and led by relevant scientists > ============================================================== > > We need to bring back the scientists who really develop models to > answer > biological questions. Qual works because it is developed by scientists > actually developing qualitative models and relevant tools. They develop > the > qual package and therefore are using it. We should extend this > practice. To > reach a community not covered by SBML, we need to make this community > develops its own structure, the way it wishes too. It is no good to > tell > them "extend what exists, contribute". Formats, terminologies and tools > never worked that way. We wish they would, but they do not. People do > not > feel involved if they are not in charge, and they do not get reward. So > the > reaction is "format X supports most of what we do, but does not support > feature Y, let's develop our own format Z, that will cover all we do". > We > should make easier for Z to be part of SBML (package when it comes to > L3). > For qualitative models, there is now a small community called Colomoto, > and > part of its activity is to develop qual and tools to support qual. We > should identify a handful of people for spatial modeling (the spatial > package is great, but it will only be supported if other tool > developers/modelers feel involved), for tissue/multi-cellular modeling, > for > statistical models etc. > > Large survey on modeling systems biology and physiology > ======================================================= > > Launch a communication effort, in the form of a survey gathering needs, > practices and experiences in modeling biological systems. The stated > objective would be to pave the way to the next generation format. We > would > try to spread the survey as much as possible, by targeting social > networks, > mailing-lists, but also private e-mails. The analysis of the survey > would > lead to a publication that we would target as high as possible. This is > the > kind of thing Nature Biotech would potentially accept. > > What else? > > > > On 30/03/13 21:02, Michael Hucka wrote: > > Hi Peter, > > > > Thank you for joining sbml-discuss and writing your recent message. > The PySB paper, your comments as well as those of Bob Phair, Bill > Hlavacek and others, juxtaposed with the recent discussion about MathML > subsets on this list, have served to demonstrate how badly change is > needed here. > > > > Last August, Nicolas Le Novère started a discussion on the internal > SBML Editors' list about the state of SBML and the community around it. > It was a follow-up to a public discussion he started at the COMBINE > meeting last year. I hope Nicolas will restate his message, because as > brutal as his words were, there is now no question in mind that he's > right. His basic point was this: while a decade ago, SBML may have > been an instrumental enabler of modeling in systems biology, today it > is not adequately serving modelers because the landscape of research > has shifted and SBML has not kept up; worse, the core SBML community > has frankly become insular, hidebound and focused on technicalities > rather than on supporting what modelers want. > > > > To some people on this list, these words will come as a surprise, and > I hope that Nicolas will follow up with a longer explanation based on > his experiences over the past decade. But really, a little bit of > reflection should be enough to realize there's a problem. It took us a > decade to implement modularity in SBML. SBML still hasn't standardized > support for rule-based models, to say nothing of multicellular models, > or spatial models. And where are our users -- the modelers? How many > of them are involved in this conversation? 5? 10? (Yes, some of you > are here -- thank you -- but the point is, there's not enough of you.) > > > > I don't mean to be rude to the rest of you, or to spread blame; I'm > one of the worst offenders, and as the person ostensibly in the best > position to steer SBML's evolution, I surely deserve the most blame for > the current rut. Please, everyone, let's skip the standard flurry of > defensive messages and cries of outrage, and focus on how we will turn > things around. > > > > There are modeling applications that SBML (even the bits of SBML > still on the drawing board) handles poorly at best. To understand > what's needed, we need the involvement of scientists who are actually > using and developing those techniques, like Peter and others. We need > to bring back the people we've pushed away too. How do we get them > engaged? And how do we keep them engaged? (It won't be by arguing > about MathML subsets.) That's the first problem we have to solve. In > solving it, we have to keep in mind what Bob Phair wrote: "Newcomers > have to be convinced that our only goal is creation of a standard that > a larger and larger community of systems biologists and experimental > biologists can embrace." > > > > We need their help to design a new generation of SBML. We have a > dozen years of experience getting things to this point; we can use that > knowledge to craft a better format that encompasses more needs, in a > more flexible and extensible manner, with modern features such as > better integration with semantic web technologies. We have libraries > whose APIs can hide the actual format, to smooth the transition for > software and protect the investment of developers who have spent > tremendous resources supporting SBML over the years. We're well- > positioned for that challenge. > > > > But if we don't regain our users and reboot the conversation, it > won't matter. > > > > MH > > ____________________________________________________________ > > To manage your sbml-discuss list subscription, visit > > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > > > For a web interface to the sbml-discuss mailing list, visit > > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > > > For questions or feedback about the sbml-discuss list, > > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > > > > > -- > Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 > 3AT > Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 > twitter:@lenovere > Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 > <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Nicolas Le Novere[1] — 2013-03-31T18:53:39-00:00

Hello all, Since Mike mentioned my message, I repost it here, only modified to make it less SBML editors centric. I did actually express myself on the subject of SBML adequacy to modeling in systems biology before. During several years, I expressed myself privately, mostly to Mike, because I wanted to try to improve the situation quietly and internally. At COMBINE 2011 I came public (slide: <a href="http://co.mbine.org/events/COMBINE_2011/agenda?q=system/files/2011-09-05-combine-lenovere-future-of-sbml.pdf" target="_blank">http://co.mbine.org/events/COMBINE_2011/agenda?q=system/files/2011-09-05-combine-lenovere-future-of-sbml.pdf</a>) (video: <a href="http://co.mbine.org/sites/combine/files/2011-09-05-combine-lenovere.mov" target="_blank">http://co.mbine.org/sites/combine/files/2011-09-05-combine-lenovere.mov</a>) Later I started a discussion with the SBML editors. Some traces of that can be found at: <a href="http://sbml.org/Discussions/SBML_Future" target="_blank">http://sbml.org/Discussions/SBML_Future</a> The following mail was meant to be a sort of provocative electroshock. Therefore, some part of it are pretty blunt, even by my standard. I realize that the it may antagonize some of you. I hope you will realize it is not meant as an attack on your scientific and technical achievements or the value of your support to SBML, and that the antagonism energy will result in useful discussions. First I would like to present how I see the situation (SBML situation in the scientific research landscape is critical), then some explanations (we are completely cut from our own community, and the attitude push away anyone wanting to help), and finally possible ways forward. Note that I have personal stakes in SBML. I devoted a very important part of my time, energy and money to SBML and related projects. Since 2004, most of my group budget (EMBL internal fund) was injected in standard development instead of research. I sort of neglected the research part of my group and jeopardized my scientific career in the process. So, in addition to my intimate conviction that interoperability and data exchange and re-use is crucial for scientific research, I have a pretty big interest in standards (and SBML at the forefront) being something important, recognized and successful. And at the moment this is not the case. What is the situation? The simple fact is that nowadays SBML is inadequate and irrelevant for research in *biology* (I will not disentangle irrelevance and inadequacy below). Most people developing models in biology never heard of it, and even less use it. But it is a bit worse than that. SBML has also become irrelevant for research in *systems biology*. A specific subset of systems biology research, dealing with the modeling of metabolic networks, sometimes uses SBML (but see the paper published Hubner et al in 2011 <a href="http://identifiers.org/pubmed/21707921." target="_blank">http://identifiers.org/pubmed/21707921.</a> Even for this perfect target community, sets of ODEs, generally written in MatLab, and now in R, are the norm). This community used to be important in what would become systems biology, and was the major part of the funding group of SBML (some of the funding groups were already not able to use SBML to encode their models though, but hoped this would come eventually, and it kind of did in some cases). This is not the case anymore. Central metabolism is done. Some tuning is needed here and there, but mostly this is not front page science anymore (there are exceptions, such as the recent Recon2 work. But the challenges there were the size and the accuracy of the reconstruction, not the modeling per se). People working on signaling pathways do not mainly use kinetic simulations of process description models (although some do, and with success). They need to describe exploding signaling pathways, influence diagrams generated by phenotypic matrices or gene expression data etc. (for an example, see the recent article of Peter Sorger that started the current discussion). The mathematical modelers on the other hand - arguably the primary initial target of SBML - are now doing models at a different level, in term of size and complexity of models. This complexity covers the number and diversity of approaches used, the multi-scale aspects, or the statistical and probabilistic treatments (see for examples the Mycoplasma work of Karr et al, or the multiscale models developed by the virtual liver network). From 2003 until 2007, SBML boosted the field (of computational systems biology), and aspects like controlled annotations created new needs that further made SBML filling a niche. It was clear that the use of SBML at the core was the reason BioModels Database grew so fast (the resource itself being initially conceived as a professional version of the SBML repository). From 2007/8 the situation reversed. SBML started to keep BioModels back (I am not complaining. I am using BioModels Db as a proxy for SBML importance). It became more and more frequent that people contacted us to submit models, and we had to turn them down because unable to accept them. In June 2009, I attended a Nobel symposium on Systems Biology. Note that I was an observer, as was Kitano. The speakers were the "real" scientists in the domain, Lee Hood, Mike Snyder, Stanislas Leibler, Luis Serrano etc. We are talking labs of 30+ people, H-index above 50, chairs in multiple universities etc. (I know you must frown or shudder at the mention of those criteria, but this is part of the issue I think. Systems biologists we should be getting support from are in a different dimension than us in terms of science. We seem to have built a little delusion around ourselves about that. I still remember when some members of the community wanted to publish press releases because SBML reached 500 citations with ISI. That was a bit embarrassing). Anyway, I spent a few days there, and tried to discuss SBML with those scientists. Less than a dozen speakers even heard about it. And they mostly dismissed it with a shrug (there were exceptions, e.g. Berhnard Palsson). Since then, the situation has become steadily worse. The SBML community represents a shrinking part of the computational systems biology one, and some of our former supporters left us. The last nail in the coffin for me came when I read a comment from a reviewer asking why the community needed SBML since there was BioPAX. I had heard the opposite comment a few times, but that one never! And before you get all flustered and start your cries of outrage about the differences between BioPAX and SBML (my initial reaction), stop. Nothing you can say matters the least. It will all be little technicalities, completely lost on an audience not made of SBML specialists. Nothing that could not be fixed in half a month with some copy/paste. The fact is that SBML at the moment is mostly used in a scientifically significant manner for encoding pathways. The mathematical modeling part, as important as it is, has become anecdotal. So how comes we ended in that situation? 2000, the cream of systems biology nucleate around the ERATO Kitano team to launch what remains the only successful community standard in biology. 2012, we can barely get 50 people to meet at the annual meeting, most of the attendees being paid or supported by the coordinators. There are a variety of reasons, but I believe they can be clustered in two topics: the lack of interaction with who we are supposed to serve, and the attitude we have towards everyone else. I believe the absence of evolution of SBML, which is the reason of its current alleged inadequacy, is actually a symptom, not a cause. (It must be clear that I consider myself as part of the problem. This entire mail is not a "guys you screwed up" but "guys we screwed up"). In 2000, the group of modelers gathered by the ERATO team represented some of the top groups in the field of modeling in systems biology. Sure, they were also tool developers, but at that time, it was kind of synonymous. The current structure of SBML was inherited (with many modifications, but not fundamental ones) from a format developed by specialists of metabolic modeling (see <a href="http://en.wikipedia.org/wiki/SBML" target="_blank">http://en.wikipedia.org/wiki/SBML</a>). That presented three interests. The first was that SBML was able to encode the models developed by the scientists, the second was that developers were able to spread the word on SBML in the right circles. And third, SBML had legitimacy. The latter is crucial. People use what they helped to develop. If that was not the case, there would not have been a SBML in the first place. Joining the Modelica effort would have been far more sensible. I'll come back to this point when discussing solutions. Anyway, the SBML creators came from groups publishing in Nature/Science/PNAS, giving keynotes in computational biology conferences etc. (including the then nascent ICSB). Today, the "top" (I will not elaborate on what I mean by top. It is beside the point) modelers out there, the equivalent of our group in 2000, are working on integration of OMICs data with pathways, virtual cells, virtual organs, multicellular tissues etc. They are still publishing in the same journals and giving keynotes though. We know where to find them, but we do not link enough. The second cause of our current problems is the attitude we adopt when facing anyone who is not from the inner circle. This is not new, and sometimes unconscious. The first attitude is pedantic posing. In 2007, coming back from the SBML hackathon in Newcastle, one of my students told me how miserable a time she had there, because of the impossibility to understand or participate to the discussions we had, some of them in breakout rooms without advance warning, or in bars at night etc. She felt completely excluded. Since then, we have become more and more technical, pedant and irrelevant. I won the gold medal with the "dangling references". We make no efforts to link with uninitiated people, and then complain that they do not understand us. Technical difficulty is the light version of it. The heavy one is when we interact for instance with people who ask "what is the difference between CellML and SBML", and the answer is some polite form of "if you don't know you are too idiot to talk to me", or with people mentioning (OK, complaining) that SBML does not support X or Y, and we answer either "why don't you develop a package" or "actually if you tweak Z, you can encode something that would be equivalent of X". Rather than welcoming outside people and extending our community to include them, we push them away or try to force "them" to become "us", which demands so much effort (see first attitude), that it is not worth it for them. I went through all these attitudes with the partners of DDMoRe and I learned a lot. The consequences are multiple, some are a decrease of attendance to the meetings, no candidates for elections, and also bad mouthing about SBML etc. Anyway, whatever the causes, SBML is largely ignored by "modeling" that matters, and its mention brings blank stares, condescending smiles or bitter remark according to the audience. This is a situation that cannot be solved by bending our current rules or "making efforts". We are way past that. The fact that some of us do not realize it is precisely part of the problem. We are so far disconnected from what should be our community that we do not realize they do not like us. The choice we face is either a shock treatment, that can succeed or let us crippled, or continue what we are currently doing, which is taking morphine to make our disappearance less painful. Here are three things we could do very quickly to shake things a bit. I am sure there are plenty of others. And the more brainstorming the better. "Storm" is a word I would love to associate to SBML, rather than mild breeze ... So please, go wild. [ my initial message contained the following proposal: "Create a SAB ============ Scientific advisory boards can be seen as an unnecessary burden, but they are useful on several plans: SABs bring people from the "outside", who are not directly involved with our SBML work and can bring fresh ideas. We can put in SAB VIPs, who could not be editors because of time limitation, but have an overview of the field, know where the money is etc. SAB members would become aware of SBML and SBML evolution, and would spread this knowledge. Finally, SAB members are not involved in the practical development of the language, and are not tied by political, psychological or emotional issues. Therefore they could detect dysfunctions and advise. People I am thinking of are along the lines of Doug Kell, Berhnard Palsson, Dirk Drasdo, Peter Sorger, Michael Elowitz, Gary Bader etc. (names are just indications). " I am very happy that we now have an SAB, and that it comprises Doug Kell and Dirk Drasdo. It is also interesting that I put Peter there :-) ] Official working groups, formed and led by relevant scientists ============================================================== We need to bring back the scientists who really develop models to answer biological questions. Qual works because it is developed by scientists actually developing qualitative models and relevant tools. They develop the qual package and therefore are using it. We should extend this practice. To reach a community not covered by SBML, we need to make this community develops its own structure, the way it wishes too. It is no good to tell them "extend what exists, contribute". Formats, terminologies and tools never worked that way. We wish they would, but they do not. People do not feel involved if they are not in charge, and they do not get reward. So the reaction is "format X supports most of what we do, but does not support feature Y, let's develop our own format Z, that will cover all we do". We should make easier for Z to be part of SBML (package when it comes to L3). For qualitative models, there is now a small community called Colomoto, and part of its activity is to develop qual and tools to support qual. We should identify a handful of people for spatial modeling (the spatial package is great, but it will only be supported if other tool developers/modelers feel involved), for tissue/multi-cellular modeling, for statistical models etc. Large survey on modeling systems biology and physiology ======================================================= Launch a communication effort, in the form of a survey gathering needs, practices and experiences in modeling biological systems. The stated objective would be to pave the way to the next generation format. We would try to spread the survey as much as possible, by targeting social networks, mailing-lists, but also private e-mails. The analysis of the survey would lead to a publication that we would target as high as possible. This is the kind of thing Nature Biotech would potentially accept. What else? On 30/03/13 21:02, Michael Hucka wrote: > Hi Peter, > > Thank you for joining sbml-discuss and writing your recent message. The PySB paper, your comments as well as those of Bob Phair, Bill Hlavacek and others, juxtaposed with the recent discussion about MathML subsets on this list, have served to demonstrate how badly change is needed here. > > Last August, Nicolas Le Novère started a discussion on the internal SBML Editors' list about the state of SBML and the community around it. It was a follow-up to a public discussion he started at the COMBINE meeting last year. I hope Nicolas will restate his message, because as brutal as his words were, there is now no question in mind that he's right. His basic point was this: while a decade ago, SBML may have been an instrumental enabler of modeling in systems biology, today it is not adequately serving modelers because the landscape of research has shifted and SBML has not kept up; worse, the core SBML community has frankly become insular, hidebound and focused on technicalities rather than on supporting what modelers want. > > To some people on this list, these words will come as a surprise, and I hope that Nicolas will follow up with a longer explanation based on his experiences over the past decade. But really, a little bit of reflection should be enough to realize there's a problem. It took us a decade to implement modularity in SBML. SBML still hasn't standardized support for rule-based models, to say nothing of multicellular models, or spatial models. And where are our users -- the modelers? How many of them are involved in this conversation? 5? 10? (Yes, some of you are here -- thank you -- but the point is, there's not enough of you.) > > I don't mean to be rude to the rest of you, or to spread blame; I'm one of the worst offenders, and as the person ostensibly in the best position to steer SBML's evolution, I surely deserve the most blame for the current rut. Please, everyone, let's skip the standard flurry of defensive messages and cries of outrage, and focus on how we will turn things around. > > There are modeling applications that SBML (even the bits of SBML still on the drawing board) handles poorly at best. To understand what's needed, we need the involvement of scientists who are actually using and developing those techniques, like Peter and others. We need to bring back the people we've pushed away too. How do we get them engaged? And how do we keep them engaged? (It won't be by arguing about MathML subsets.) That's the first problem we have to solve. In solving it, we have to keep in mind what Bob Phair wrote: "Newcomers have to be convinced that our only goal is creation of a standard that a larger and larger community of systems biologists and experimental biologists can embrace." > > We need their help to design a new generation of SBML. We have a dozen years of experience getting things to this point; we can use that knowledge to craft a better format that encompasses more needs, in a more flexible and extensible manner, with modern features such as better integration with semantic web technologies. We have libraries whose APIs can hide the actual format, to smooth the transition for software and protect the investment of developers who have spent tremendous resources supporting SBML over the years. We're well-positioned for that challenge. > > But if we don't regain our users and reboot the conversation, it won't matter. > > MH > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Mike Hucka — 2013-03-31T17:42:58-00:00

On Sun, 31 Mar 2013 11:10:25 -0600, Chris J. Myers wrote: > We should not find it surprising that modelers are not actively > involved in sbml-discuss discussions. They honestly don't care about > the issues in how tools store and exchange models. What they care > about is whether they have tools that support their needs. Yes indeed, I agree 100%, and that's the reason behind the proposal to start a different resource for those discussions. In addition, for SBML to continue being relevant, we have to become better aware of the directions in which research is going -- we need a way to accurately anticipate where people are headed. That was partly the goal behind the recent formation of a Scientific Advisory Board for SBML, to get their input, but I think providing a forum where discussions take place by modelers and researchers and developers is another way to do that. I mean, seriously, how is it possible that in the year 2013, the people who are using CellML, SBML, BNG, etc., or doing multicellular modeling with CompuCell3D, or other such things, don't have a single go-to place where they can discuss what they're doing, ask about modeling approaches and algorithms, etc.? (Or is there, and I've been so locked up in my own little world that I didn't notice?) MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Mike Hucka — 2013-03-31T17:12:03-00:00

On Sun, 31 Mar 2013 06:56:28 +0100, Lucian Smith wrote: > As far as the others, I don't see GPlus going anywhere any time soon > ('communities' or no), and wouldn't want to hitch SBML's wagon to a dying > format. I'm not sure it's a dying format, but I agree the capabilities are just not well-suited to what we want to do here. > I have no opinion between the other two, except to say that if the point > is to attract modelers to the new place, we should try to find out what > modelers are already using, and go from there. I'd love that, but how do we get that information? > I also don't think 'math' is important at all for the new place. Very few > people speak math (I certainly don't) and there's nothing like a good > equation to make people's eyes glaze over. But it's useful in some cases, especially if the discussion is about modeling techniques. > If we did go with AskBot, I *wouldn't* tweak it so it wasn't a > question/answer format, and make it 'discussions'. Discussions are best > in person and here in email. An AskBot forum is best for Q&A and > proposals/counter-proposals. Agreed. > I wonder if an SBML 'uservoice' suggestion pool/voting site would be > helpful, too. It might serve yet another function from sbml-discuss and > the proposed new forum. The format of uservoice is very reminiscent of StackOverflow/AskBot, and Discourse to some extent, actually. So we could get the voting/polling capabilities from those systems. (But I agree such a capability is useful *somehow*.) MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

myers — 2013-03-31T17:10:25-00:00

I think this is an excellent point. We should not find it surprising that modelers are not actively involved in sbml-discuss discussions. They honestly don't care about the issues in how tools store and exchange models. What they care about is whether they have tools that support their needs. So, when we consider the future of SBML, we have to look at why modelers are not using tools which support SBML (not why they are not using SBML). A good case in point is the Karr et al whole-cell model. Mike and I have had some discussion with them, and they do see the benefits of having their model encoded in SBML though they also were unable to find a tool that allowed them to construct their model in the way they wanted that supported SBML. For this reason, they ended up hand crafting it in matlab (probably the tool that most modelers resort to when they cannot use our tools). So, I would argue that when a modeling effort does not use SBML that this is not due to the fact tha t SBML is not up to the task but rather our tools are not up to it. Therefore, we should look at the reasons why, update our tools to support those efforts, and then, if necessary, advocate enhancements to SBML so we can exchange models. Despite the slow pace of these enhancements (which can be frustrating), I still feel pretty positive about the state of SBML. I don't think we need to be discouraged by disagreements and discussions, they are all part of the process. Cheers, Chris On Mar 31, 2013, at 3:40 AM, Thomas Ligon <<a href="mailto:thomassligon@hotmail.com" target="_blank">thomassligon@hotmail.com</a>> wrote: > These numbers confirm the understanding that is behind my previous remarks: Most modelers will be much closer to the tools they use than to the standards behind those tools. So, maybe this should be a 2-level process, with tool developers representing their respective user communities in the SBML community.For example, Pedro and Stefan might approach the SBML community with a statement like: "We have n users asking for feature X, and have developed a prototype of that feature, but storing the model in SBML would require an extension to SBML."In this discussion, I have been reluctant to make comments about specific aspects of SBML or MathML because I don't feel competent to do that. Having developed software, including XML access, is not enough. I am currently working on modeling and know what I want to have, but my understanding of the standards is too superficial for me to provide good input, at least for the moment. > > Tom Ligon(Dr. Thomas S. Ligon, LMU Munich) > > <a href="mailto:thomassligon@hotmail.com" target="_blank">thomassligon@hotmail.com</a> > > > >> Date: Sat, 30 Mar 2013 22:45:22 +0000 >> From: <a href="mailto:pedro.mendes@manchester.ac.uk" target="_blank">pedro.mendes@manchester.ac.uk</a> >> To: <a href="mailto:sbml-discuss@caltech.edu" target="_blank">sbml-discuss@caltech.edu</a> >> Subject: Re: [sbml-discuss] People, we need a reboot. >> >> Mike, all, >> >> On 03/30/2013 09:02 PM, Michael Hucka wrote: >> >>> But if we don't regain our users and reboot the conversation, it >>> won't matter. >> >> We have more than 1000 users registered in our COPASI forum and most >> have posted something there. I am sure other packages have at least >> similar numbers (CellDesigner, Cytoscape, Virtual Cell, etc). So let me >> assure you that there are *many* SBML users, and their number is >> increasing, not decreasing. >> >> Obviously, this does not mean that we should not reach out for more, and >> include other modelling scenarios. But let's not be so negative on this. >> >> Best >> Pedro >> >> -- >> Pedro Mendes >> Professor of Computational Systems Biology >> School of Computer Science >> Manchester Centre for Integrative Systems Biology >> University of Manchester >> >> Manchester Institute of Biotechnology >> 131 Princess Street >> Manchester, M1 7DN, U.K. >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Mike Hucka — 2013-03-31T17:01:49-00:00

I realize now that I didn't make it very clear what I had in mind as the purpose for this new forum/discussion system/whatever. The purpose would be to discuss modeling in systems biology more broadly than we have been doing on sbml-discuss. I'm not aware of a discussion site where modelers---not just developers of SBML software, but end users, students, researchers and others---can discuss all facets of modeling in biology. Right now, such questions are not appropriate for sbml-discuss, and while they would be appropriate for <a href="http://scicomp.stackexchange.com," target="_blank">http://scicomp.stackexchange.com,</a> that site is too general (IMHO) and not really meant as a discussion site. We want something focused on the domain of modeling in biology, and allow some discussion. The secret goal, I have to admit, is that people become more engaged in SBML and its evolution as a natural by-product of these discussions. But there's no reason why we can't provide the field with a more general discussion resource. We would keep sbml-discuss for issues of SBML itself. (After all, the discussions about MathML subsets have to happen *somewhere* :-).) MH On Sat, 30 Mar 2013 18:23:19 -0400, Michael Hucka wrote: > On the topic of getting involvement from more people: > > I think it's difficult to use mailing lists to have some of the > discussions we want to have, especially if we want to get a wider > audience. The online interface on sbml.org is old and crufty. We > could set up more modern discussion software. Should we? Or is it > doomed to failure, with people reverting to mail anyway? > > The following are alternative options that come to mind: > > 1. Discourse (<a href="http://www.discourse.org" target="_blank">http://www.discourse.org</a>) > 2. AskBot (<a href="http://askbot.org/en/questions/" target="_blank">http://askbot.org/en/questions/</a>) > 3. Google Plus Communities (<a href="https://plus.google.com/communities" target="_blank">https://plus.google.com/communities</a>) > 4. Google Groups > > Without getting into a long discussion about the pros and cons, I > would characterize some of the differences as follows: > > - Google Groups is basically email, with no built-in image and math > formatting. Familiar, but least powerful IMHO. > - Google Plus has poor formatting support and also no math, but > somewhat nicer interface > - Discourse is the most promising next-generation forum system; it > lacks math currently but it's likely to be added, and otherwise is > very powerful and easy > - AskBot is a question/answer site, with math and many other > features, and I think it could be repurposed to be a discussion site > (basically, we treat questions as discussion topics, and replies to > questions as the discussion). > > Personally, I would say Discourse or AskBot are the best bets. I'd > install one of them on our servers. > > What do people think? > > MH > P.S. There is some irony in using a mailing list to discuss whether > we stop using a mailing list :-). ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

thomassligon — 2013-03-31T09:40:29-00:00

These numbers confirm the understanding that is behind my previous remarks: Most modelers will be much closer to the tools they use than to the standards behind those tools. So, maybe this should be a 2-level process, with tool developers representing their respective user communities in the SBML community.For example, Pedro and Stefan might approach the SBML community with a statement like: "We have n users asking for feature X, and have developed a prototype of that feature, but storing the model in SBML would require an extension to SBML."In this discussion, I have been reluctant to make comments about specific aspects of SBML or MathML because I don't feel competent to do that. Having developed software, including XML access, is not enough. I am currently working on modeling and know what I want to have, but my understanding of the standards is too superficial for me to provide good input, at least for the moment. Tom Ligon(Dr. Thomas S. Ligon, LMU Munich) <a href="mailto:thomassligon@hotmail.com" target="_blank">thomassligon@hotmail.com</a> > Date: Sat, 30 Mar 2013 22:45:22 +0000 > From: <a href="mailto:pedro.mendes@manchester.ac.uk" target="_blank">pedro.mendes@manchester.ac.uk</a> > To: <a href="mailto:sbml-discuss@caltech.edu" target="_blank">sbml-discuss@caltech.edu</a> > Subject: Re: [sbml-discuss] People, we need a reboot. > > Mike, all, > > On 03/30/2013 09:02 PM, Michael Hucka wrote: > > > But if we don't regain our users and reboot the conversation, it > > won't matter. > > We have more than 1000 users registered in our COPASI forum and most > have posted something there. I am sure other packages have at least > similar numbers (CellDesigner, Cytoscape, Virtual Cell, etc). So let me > assure you that there are *many* SBML users, and their number is > increasing, not decreasing. > > Obviously, this does not mean that we should not reach out for more, and > include other modelling scenarios. But let's not be so negative on this. > > Best > Pedro > > -- > Pedro Mendes > Professor of Computational Systems Biology > School of Computer Science > Manchester Centre for Integrative Systems Biology > University of Manchester > > Manchester Institute of Biotechnology > 131 Princess Street > Manchester, M1 7DN, U.K. > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Lucian Smith — 2013-03-31T05:56:28-00:00

First of all, I think we obviously need a place to discuss subsets of MathML and similar minutae. That is a perfectly fine discussion to have, and benefits the community. If we want to have *other* discussions, and those discussions are quelled if they take place in the same place as the MathML/minutae discussions, it makes sense to have a new place for those. I do worry that there will be borderline discussions that might reasonably go in either place, and then we'll have arguments about where it should go, but we can jump off that bridge when we come to it. * Mike Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> [2013-03-30 22:24] writes: > > The following are alternative options that come to mind: > > 1. Discourse (<a href="http://www.discourse.org" target="_blank">http://www.discourse.org</a>) > 2. AskBot (<a href="http://askbot.org/en/questions/" target="_blank">http://askbot.org/en/questions/</a>) > 3. Google Plus Communities (<a href="https://plus.google.com/communities" target="_blank">https://plus.google.com/communities</a>) > 4. Google Groups > > Without getting into a long discussion about the pros and cons, I would characterize some of the differences as follows: > > - Google Groups is basically email, with no built-in image and math formatting. Familiar, but least powerful IMHO. > - Google Plus has poor formatting support and also no math, but somewhat nicer interface > - Discourse is the most promising next-generation forum system; it lacks math currently but it's likely to be added, and otherwise is very powerful and easy > - AskBot is a question/answer site, with math and many other features, and I think it could be repurposed to be a discussion site (basically, we treat questions as discussion topics, and replies to questions as the discussion). Google groups seems like an obviously bad choice, because it's just another mailing list. If we are adding a new thing, it should either be actually different, or actually the same. If you wanted to move sbml-discuss to google groups *and* make a new thing on google groups, that might be OK? As far as the others, I don't see GPlus going anywhere any time soon ('communities' or no), and wouldn't want to hitch SBML's wagon to a dying format. I have no opinion between the other two, except to say that if the point is to attract modelers to the new place, we should try to find out what modelers are already using, and go from there. I also don't think 'math' is important at all for the new place. Very few people speak math (I certainly don't) and there's nothing like a good equation to make people's eyes glaze over. If we did go with AskBot, I *wouldn't* tweak it so it wasn't a question/answer format, and make it 'discussions'. Discussions are best in person and here in email. An AskBot forum is best for Q&A and proposals/counter-proposals. I wonder if an SBML 'uservoice' suggestion pool/voting site would be helpful, too. It might serve yet another function from sbml-discuss and the proposed new forum. -Lucian ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Mike Hucka — 2013-03-30T22:58:21-00:00

On Sat, 30 Mar 2013 22:45:22 +0000, Pedro Mendes wrote: > We have more than 1000 users registered in our COPASI forum and most > have posted something there. I am sure other packages have at least > similar numbers (CellDesigner, Cytoscape, Virtual Cell, etc). So let me > assure you that there are *many* SBML users, and their number is > increasing, not decreasing. That's a large number, which is great! But ... are they discussing SBML per se, or COPASI? MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Pedro Mendes — 2013-03-30T22:45:22-00:00

Mike, all, On 03/30/2013 09:02 PM, Michael Hucka wrote: > But if we don't regain our users and reboot the conversation, it > won't matter. We have more than 1000 users registered in our COPASI forum and most have posted something there. I am sure other packages have at least similar numbers (CellDesigner, Cytoscape, Virtual Cell, etc). So let me assure you that there are *many* SBML users, and their number is increasing, not decreasing. Obviously, this does not mean that we should not reach out for more, and include other modelling scenarios. But let's not be so negative on this. Best Pedro -- Pedro Mendes Professor of Computational Systems Biology School of Computer Science Manchester Centre for Integrative Systems Biology University of Manchester Manchester Institute of Biotechnology 131 Princess Street Manchester, M1 7DN, U.K. ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: People, we need a reboot.

Mike Hucka — 2013-03-30T22:23:19-00:00

On the topic of getting involvement from more people: I think it's difficult to use mailing lists to have some of the discussions we want to have, especially if we want to get a wider audience. The online interface on sbml.org is old and crufty. We could set up more modern discussion software. Should we? Or is it doomed to failure, with people reverting to mail anyway? The following are alternative options that come to mind: 1. Discourse (<a href="http://www.discourse.org" target="_blank">http://www.discourse.org</a>) 2. AskBot (<a href="http://askbot.org/en/questions/" target="_blank">http://askbot.org/en/questions/</a>) 3. Google Plus Communities (<a href="https://plus.google.com/communities" target="_blank">https://plus.google.com/communities</a>) 4. Google Groups Without getting into a long discussion about the pros and cons, I would characterize some of the differences as follows: - Google Groups is basically email, with no built-in image and math formatting. Familiar, but least powerful IMHO. - Google Plus has poor formatting support and also no math, but somewhat nicer interface - Discourse is the most promising next-generation forum system; it lacks math currently but it's likely to be added, and otherwise is very powerful and easy - AskBot is a question/answer site, with math and many other features, and I think it could be repurposed to be a discussion site (basically, we treat questions as discussion topics, and replies to questions as the discussion). Personally, I would say Discourse or AskBot are the best bets. I'd install one of them on our servers. What do people think? MH P.S. There is some irony in using a mailing list to discuss whether we stop using a mailing list :-). ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

People, we need a reboot.

Mike Hucka — 2013-03-30T21:02:57-00:00

Hi Peter, Thank you for joining sbml-discuss and writing your recent message. The PySB paper, your comments as well as those of Bob Phair, Bill Hlavacek and others, juxtaposed with the recent discussion about MathML subsets on this list, have served to demonstrate how badly change is needed here. Last August, Nicolas Le Novère started a discussion on the internal SBML Editors' list about the state of SBML and the community around it. It was a follow-up to a public discussion he started at the COMBINE meeting last year. I hope Nicolas will restate his message, because as brutal as his words were, there is now no question in mind that he's right. His basic point was this: while a decade ago, SBML may have been an instrumental enabler of modeling in systems biology, today it is not adequately serving modelers because the landscape of research has shifted and SBML has not kept up; worse, the core SBML community has frankly become insular, hidebound and focused on technicalities rather than on supporting what modelers want. To some people on this list, these words will come as a surprise, and I hope that Nicolas will follow up with a longer explanation based on his experiences over the past decade. But really, a little bit of reflection should be enough to realize there's a problem. It took us a decade to implement modularity in SBML. SBML still hasn't standardized support for rule-based models, to say nothing of multicellular models, or spatial models. And where are our users -- the modelers? How many of them are involved in this conversation? 5? 10? (Yes, some of you are here -- thank you -- but the point is, there's not enough of you.) I don't mean to be rude to the rest of you, or to spread blame; I'm one of the worst offenders, and as the person ostensibly in the best position to steer SBML's evolution, I surely deserve the most blame for the current rut. Please, everyone, let's skip the standard flurry of defensive messages and cries of outrage, and focus on how we will turn things around. There are modeling applications that SBML (even the bits of SBML still on the drawing board) handles poorly at best. To understand what's needed, we need the involvement of scientists who are actually using and developing those techniques, like Peter and others. We need to bring back the people we've pushed away too. How do we get them engaged? And how do we keep them engaged? (It won't be by arguing about MathML subsets.) That's the first problem we have to solve. In solving it, we have to keep in mind what Bob Phair wrote: "Newcomers have to be convinced that our only goal is creation of a standard that a larger and larger community of systems biologists and experimental biologists can embrace." We need their help to design a new generation of SBML. We have a dozen years of experience getting things to this point; we can use that knowledge to craft a better format that encompasses more needs, in a more flexible and extensible manner, with modern features such as better integration with semantic web technologies. We have libraries whose APIs can hide the actual format, to smooth the transition for software and protect the investment of developers who have spent tremendous resources supporting SBML over the years. We're well-positioned for that challenge. But if we don't regain our users and reboot the conversation, it won't matter. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

fbergman — 2013-03-30T10:29:39-00:00

> May I ask how a tool can extend an external standard out of the annotation > element without making the model invalid and unexchangeable? How do- > you add a MathML element? > So far what people have been doing is to add their own functions as function definition objects that are then annotated with a custom annotation. Pretty much like in the first proposals for distrib. And that approach works just fine, as long as you have a function that maps real valued arguments back to a real value. But let's think about the specific case of SBO where you describe the Mass Action kinetic [1] using the product. Creating a function definition here will only work in very limiting cases. What is most troubling here is how the vector of all reactants is introduced. First the second argument is marked as reactant (using the SBO:10) and later on, when it is used in the math element, its ci tag receives a type vector. And that I believe is not compatible with how we have been using the MathML in SBML so far. Always for a ci element, there was a corresponding SId. So I probably would move the whole element into an annotation, for now. I definitely would tag the listOfReactants with an annotation to receive the id used in expressions. In my tools, I have been using a snippet similar to [2], where I do use keywords like PRODUCT_OF_SUBSTRATES that achieve the same for me, with less effort on the implementation side. And out of which I can generate the MathML that is needed when it is used in a model. Cheers Frank -------- [1] here the (obsolete) mathml used in SBO to write down the 3rd order mass action kinetics: k</ci></bvar> R</ci></bvar> k</ci> i </ci></bvar> 1 </cn></lowlimit> 3 </ci></uplimit> R</ci> i </ci> </apply> </apply> </apply> </lambda> </semantics> </math> [2] template used in SBW: </listOfParameters> </rateLaw> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Sarah Keating — 2013-03-30T10:27:11-00:00

On 29/03/2013 16:01, Stefan Hoops wrote: > Two editors have made their preference for the shift clear though Sarah > was very subtle. Chris on the other side is against it. I would like to > hear the opinion of the remaining two editors in addition to modelers. Interesting that you perceive that - I was clearly very careful in my choice of language. Actually I have been the most vocal of the editors AGAINST the inclusion of all MathML. But my arguments are libsbml-centric and therefore not necessarily the defining argument :-) The reason we need this discussion was because there is clearly an issue with the subset of MathML and it seemed essential to get some input from SBML users; both users who are involved in software and those who are not. The other reason for the discussion, which has unfortunately got lost in the MathML issue, is that the distrib package is anticipating using UncertML and are currently going through the issue of whether to use a subset or just allow all of it. Given the requirement that we have 2 softwares that implement support, some people are tending towards a subset; whilst a similar argument for including the whole standard has also been made - that restricting the use of a standard hampers modellers. Sarah ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Nicolas Le Novere[1] — 2013-03-30T09:58:58-00:00

Hello, May I ask how a tool can extend an external standard out of the annotation element without making the model invalid and unexchangeable? How do-you add a MathML element? Even in the annotation element, when COPASI team decided to use a more RDF compliant form for cross-references, they created a parallel annotation rather than extending the "controlled" one. The only solution I know for MathML would be just to plug the new element there, and not validate the file. On 30/03/13 00:09, hsauro wrote: > Agreed, sounds like a sensible approach. > > Herbert > > On 3/29/2013 1:39 PM, Thomas Ligon wrote: >> I previously expressed the opinion that it would be nice to open up SBML to full MathML and then let the tool developers decide what to implement, but now I see that a number of people have addressed some real risks in that. On the other hand, Stefan Hoops explained that it easy for a tool developer to add a private extension to SBML, develop the tool, and then submit the extension to the SBML community for review. That sounds to me like a very practical way to achieve the same goal, and it also ensures that the extension will be tested and implemented in at least one tool. As a matter fact, that is the procedure that I would have chosen myself, because I want to have a good basis for discussing an extension before starting a debate that I might not be able to finish. >> >> Tom Ligon(Dr. Thomas S. Ligon, LMU Munich) >> >> <a href="mailto:thomassligon@hotmail.com" target="_blank">thomassligon@hotmail.com</a> >> >> >> >> > Date: Fri, 29 Mar 2013 18:49:21 +0000 >>> From: <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a> >>> To: <a href="mailto:sbml-discuss@caltech.edu" target="_blank">sbml-discuss@caltech.edu</a> >>> Subject: Re: [sbml-discuss] Restricted use of third-party standards by SBML >>> >>> On 29/03/13 16:42, Chris J. Myers wrote: >>> >>>> I believe it is clear that Nicolas wants all of mathML. >>> No, or rather not only. I would love to see SBML grow up as a generic >>> standard, interoperable with the other standards developed by other >>> communities, and let the users decide what they want to use SBML for. >>> Because we are suppose to serve the community and not decide which model >>> they have to develop and how they have to use them. Even if that was in our >>> charter, we could not make it work. >>> >>> Just for the non-subscribers of all the SBML mailing-list, the reason >>> behind this post is not MathML but UncertML. I tried to include RDF and >>> XHTML as other examples, but MathML is a very big magnet because of the >>> related simulation issues. >>> >>> -- >>> Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT >>> Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere >>> Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 >>> <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> >>> >>> ____________________________________________________________ >>> To manage your sbml-discuss list subscription, visit >>> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >>> >>> For a web interface to the sbml-discuss mailing list, visit >>> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >>> >>> For questions or feedback about the sbml-discuss list, >>> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> >> >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > > -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

hsauro — 2013-03-30T00:09:56-00:00

Agreed, sounds like a sensible approach. Herbert On 3/29/2013 1:39 PM, Thomas Ligon wrote: > I previously expressed the opinion that it would be nice to open up SBML to full MathML and then let the tool developers decide what to implement, but now I see that a number of people have addressed some real risks in that. On the other hand, Stefan Hoops explained that it easy for a tool developer to add a private extension to SBML, develop the tool, and then submit the extension to the SBML community for review. That sounds to me like a very practical way to achieve the same goal, and it also ensures that the extension will be tested and implemented in at least one tool. As a matter fact, that is the procedure that I would have chosen myself, because I want to have a good basis for discussing an extension before starting a debate that I might not be able to finish. > > Tom Ligon(Dr. Thomas S. Ligon, LMU Munich) > > <a href="mailto:thomassligon@hotmail.com" target="_blank">thomassligon@hotmail.com</a> > > > > > Date: Fri, 29 Mar 2013 18:49:21 +0000 >> From: <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a> >> To: <a href="mailto:sbml-discuss@caltech.edu" target="_blank">sbml-discuss@caltech.edu</a> >> Subject: Re: [sbml-discuss] Restricted use of third-party standards by SBML >> >> On 29/03/13 16:42, Chris J. Myers wrote: >> >>> I believe it is clear that Nicolas wants all of mathML. >> No, or rather not only. I would love to see SBML grow up as a generic >> standard, interoperable with the other standards developed by other >> communities, and let the users decide what they want to use SBML for. >> Because we are suppose to serve the community and not decide which model >> they have to develop and how they have to use them. Even if that was in our >> charter, we could not make it work. >> >> Just for the non-subscribers of all the SBML mailing-list, the reason >> behind this post is not MathML but UncertML. I tried to include RDF and >> XHTML as other examples, but MathML is a very big magnet because of the >> related simulation issues. >> >> -- >> Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT >> Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere >> Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 >> <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> >> >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> -- Herbert M. Sauro, PhD Associate Professor Department of Bioengineering University of Washington William H. Foege Building Box 355061, Seattle, WA 98195-5061 206.685.2119 (tel), 206.685.3300 (shared fax) <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> New Text Book: Enzyme Kinetics for Systems Biology Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

thomassligon — 2013-03-29T20:39:37-00:00

I previously expressed the opinion that it would be nice to open up SBML to full MathML and then let the tool developers decide what to implement, but now I see that a number of people have addressed some real risks in that. On the other hand, Stefan Hoops explained that it easy for a tool developer to add a private extension to SBML, develop the tool, and then submit the extension to the SBML community for review. That sounds to me like a very practical way to achieve the same goal, and it also ensures that the extension will be tested and implemented in at least one tool. As a matter fact, that is the procedure that I would have chosen myself, because I want to have a good basis for discussing an extension before starting a debate that I might not be able to finish. Tom Ligon(Dr. Thomas S. Ligon, LMU Munich) <a href="mailto:thomassligon@hotmail.com" target="_blank">thomassligon@hotmail.com</a> > Date: Fri, 29 Mar 2013 18:49:21 +0000 > From: <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a> > To: <a href="mailto:sbml-discuss@caltech.edu" target="_blank">sbml-discuss@caltech.edu</a> > Subject: Re: [sbml-discuss] Restricted use of third-party standards by SBML > > On 29/03/13 16:42, Chris J. Myers wrote: > > > I believe it is clear that Nicolas wants all of mathML. > > No, or rather not only. I would love to see SBML grow up as a generic > standard, interoperable with the other standards developed by other > communities, and let the users decide what they want to use SBML for. > Because we are suppose to serve the community and not decide which model > they have to develop and how they have to use them. Even if that was in our > charter, we could not make it work. > > Just for the non-subscribers of all the SBML mailing-list, the reason > behind this post is not MathML but UncertML. I tried to include RDF and > XHTML as other examples, but MathML is a very big magnet because of the > related simulation issues. > > -- > Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT > Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere > Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 > <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Lucian Smith — 2013-03-29T18:58:02-00:00

* Chris J. Myers <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> [2013-03-29 18:32] writes: > On Mar 29, 2013, at 12:25 PM, Lucian Smith <<a href="mailto:lpsmith@spod-central.org" target="_blank">lpsmith@spod-central.org</a>> wrote: > > > * Chris J. Myers <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> [2013-03-29 18:21] writes: > >> > >> On Mar 29, 2013, at 11:33 AM, Michael Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> wrote: > >> > >>> On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: > >>>> So, in summary, I think there are a few things we can add to core > >>>> that would be useful (quotient, remainder, infinity, notanumber). > >>> > >>> Actually, infinity and notanumber are already there. > >>> > >> Oops, I think I missed those. Are there test cases that include these? If not, we should add them because I think I forgot to add them. Should be two lines of code though. > > > > They're there. You might not have noticed because in libsbml, they are > > translated to value nodes; the same AST type as '3.0'. > > Oh, in that case, we do support them. :-) That is good news. The only problem is I forgot to add them to our documentation. How does the infix parser treat them "nan" and "inf" or something else? The L3 infix-to-mathml accepts 'infinity' and 'inf' (with any capitalization) and translates those to , and 'notanumber' and 'nan' (with any capitalization), translating those to . (Internally, if you are working with ASTNodes directly, they are created as ASTNodes of type AST_REAL with values numeric_limits::infinity() and numeric_limits::quiet_NaN().) Unfortunately, there is not yet an L3 mathml-to-infix translator; the existing L1 mathml-to-infix translator translates them as "INF_" and "NaN_". Oh, er. I should have put those in as options to the l3 translator, too. I will do so now! (The L1 infix-to-mathml translator will also fail to translate 'INF_' and 'NaN_', so at least it's not lost functionality.) -Lucian ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Nicolas Le Novere[1] — 2013-03-29T18:49:21-00:00

On 29/03/13 16:42, Chris J. Myers wrote: > I believe it is clear that Nicolas wants all of mathML. No, or rather not only. I would love to see SBML grow up as a generic standard, interoperable with the other standards developed by other communities, and let the users decide what they want to use SBML for. Because we are suppose to serve the community and not decide which model they have to develop and how they have to use them. Even if that was in our charter, we could not make it work. Just for the non-subscribers of all the SBML mailing-list, the reason behind this post is not MathML but UncertML. I tried to include RDF and XHTML as other examples, but MathML is a very big magnet because of the related simulation issues. -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Nicolas Le Novere[1] — 2013-03-29T18:44:42-00:00

On 29/03/13 16:01, Stefan Hoops wrote: > I think this discussion though very helpful with respect to MathML is > missing the point. The question behind this discussion is whether SBML > does a paradigm shift from exchange format to encoding format where the > later tries to be all encompassing. I would add that exchange and re-use are two different, albeit related, issues. SBML is used in many cases to exchange models, although the tools exchanging them cannot re-use them to do the same things. In order to support the entire life cycle of the model, one needs plenty of tools > The question for MathML is whether these new concepts should be > preemptively added. The current topic only deal with *externally maintained standards*. I do not think we are saying any tool would be able to add *SBML* elements and attributes at will. The question is the restriction of the standards we *use* to a subset. (NB: As for the pre-emptive, we have requested the addition of sum, prod etc. in 2005. There are existing use-cases and software tools. So after 8 years of waiting, I came to the conclusion that asking for incremental increase of SBML is not going to be a robust path forward). -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

myers — 2013-03-29T18:28:35-00:00

On Mar 29, 2013, at 12:25 PM, Lucian Smith <<a href="mailto:lpsmith@spod-central.org" target="_blank">lpsmith@spod-central.org</a>> wrote: > * Chris J. Myers <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> [2013-03-29 18:21] writes: >> >> On Mar 29, 2013, at 11:33 AM, Michael Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> wrote: >> >>> On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: >>>> So, in summary, I think there are a few things we can add to core >>>> that would be useful (quotient, remainder, infinity, notanumber). >>> >>> Actually, infinity and notanumber are already there. >>> >> Oops, I think I missed those. Are there test cases that include these? If not, we should add them because I think I forgot to add them. Should be two lines of code though. > > They're there. You might not have noticed because in libsbml, they are > translated to value nodes; the same AST type as '3.0'. Oh, in that case, we do support them. :-) That is good news. The only problem is I forgot to add them to our documentation. How does the infix parser treat them "nan" and "inf" or something else? Chris ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Lucian Smith — 2013-03-29T18:25:22-00:00

* Chris J. Myers <<a href="mailto:myers@ece.utah.edu" target="_blank">myers@ece.utah.edu</a>> [2013-03-29 18:21] writes: > > On Mar 29, 2013, at 11:33 AM, Michael Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> wrote: > > > On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: > >> So, in summary, I think there are a few things we can add to core > >> that would be useful (quotient, remainder, infinity, notanumber). > > > > Actually, infinity and notanumber are already there. > > > Oops, I think I missed those. Are there test cases that include these? If not, we should add them because I think I forgot to add them. Should be two lines of code though. They're there. You might not have noticed because in libsbml, they are translated to value nodes; the same AST type as '3.0'. -Lucian ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

myers — 2013-03-29T18:16:23-00:00

On Mar 29, 2013, at 11:33 AM, Michael Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> wrote: > On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: >> So, in summary, I think there are a few things we can add to core >> that would be useful (quotient, remainder, infinity, notanumber). > > Actually, infinity and notanumber are already there. > Oops, I think I missed those. Are there test cases that include these? If not, we should add them because I think I forgot to add them. Should be two lines of code though. >> I think if can breakdown the rest into the following packages: >> >> 1) Arrays and sets >> 2) Calculus >> 3) Complex numbers > > Also, there are the statistics operators (mean, sdev, etc.) and the sequence and series operators (particularly sum and product). > Yes, these should be part of arrays package. A lot of operators only make sense if you can apply them to groups of things which means we either need arrays or sets likely to use them in a meaningful way. The arrays package already mentions adding sum and product to the subset, but I need to update it to also add mean, sdev, etc. Once we have an arrays (or sets) package, we likely won't be missing many operators from MathML. Chris ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

myers — 2013-03-29T18:09:40-00:00

Ok, a similar list is here which seems to be pretty much the same as 3.0. <a href="http://www.w3.org/TR/MathML2/chapter4.html#contm.elem" target="_blank">http://www.w3.org/TR/MathML2/chapter4.html#contm.elem</a> Chris On Mar 29, 2013, at 11:23 AM, Michael Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> wrote: > On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: >> Ok, I was curious what we actually are leaving out, so I checked it out: >> >> <a href="http://www.w3.org/TR/MathML3/chapter4.html" target="_blank">http://www.w3.org/TR/MathML3/chapter4.html</a> > > That's the wrong version of MathML :-). We're using 2.0, not 3.0. The correct spec is <a href="http://www.w3.org/TR/MathML2/." target="_blank">http://www.w3.org/TR/MathML2/.</a> > > MH > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

hsauro — 2013-03-29T17:57:17-00:00

I am curious what would be useful about complex numbers in a modeling exchange format? Perhaps expressing solutions to ODEs in complex format? I can see how it would be very useful in something like SEDML, where people might request eigenvalues. Herbert On 3/29/2013 10:33 AM, Michael Hucka wrote: > On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: >> So, in summary, I think there are a few things we can add to core >> that would be useful (quotient, remainder, infinity, notanumber). > Actually, infinity and notanumber are already there. > >> I think if can breakdown the rest into the following packages: >> >> 1) Arrays and sets >> 2) Calculus >> 3) Complex numbers > Also, there are the statistics operators (mean, sdev, etc.) and the sequence and series operators (particularly sum and product). > > MH > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> -- Herbert M. Sauro, PhD Associate Professor Department of Bioengineering University of Washington William H. Foege Building Box 355061, Seattle, WA 98195-5061 206.685.2119 (tel), 206.685.3300 (shared fax) <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> New Text Book: Enzyme Kinetics for Systems Biology Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Mike Hucka — 2013-03-29T17:35:23-00:00

On Fri, 29 Mar 2013 17:33:07 +0000, Lucian Smith wrote: > * Mike Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> [2013-03-29 17:29] writes: >> On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: >>> Ok, I was curious what we actually are leaving out, so I checked it out: >>> >>> <a href="http://www.w3.org/TR/MathML3/chapter4.html" target="_blank">http://www.w3.org/TR/MathML3/chapter4.html</a> >> >> That's the wrong version of MathML :-). We're using 2.0, not 3.0. >> The correct spec is <a href="http://www.w3.org/TR/MathML2/." target="_blank">http://www.w3.org/TR/MathML2/.</a> > > Well, moving to 3.0 is yet another option; Brett was looking at some > features of the 3.0 spec that seemed like they might be helpful. Yes, of course. I'm just trying to get us back on the same page first. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Lucian Smith — 2013-03-29T17:33:07-00:00

* Mike Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> [2013-03-29 17:29] writes: > On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: > > Ok, I was curious what we actually are leaving out, so I checked it out: > > > > <a href="http://www.w3.org/TR/MathML3/chapter4.html" target="_blank">http://www.w3.org/TR/MathML3/chapter4.html</a> > > That's the wrong version of MathML :-). We're using 2.0, not 3.0. The correct spec is <a href="http://www.w3.org/TR/MathML2/." target="_blank">http://www.w3.org/TR/MathML2/.</a> Well, moving to 3.0 is yet another option; Brett was looking at some features of the 3.0 spec that seemed like they might be helpful. -Lucian ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Mike Hucka — 2013-03-29T17:33:01-00:00

On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: > So, in summary, I think there are a few things we can add to core > that would be useful (quotient, remainder, infinity, notanumber). Actually, infinity and notanumber are already there. > I think if can breakdown the rest into the following packages: > > 1) Arrays and sets > 2) Calculus > 3) Complex numbers Also, there are the statistics operators (mean, sdev, etc.) and the sequence and series operators (particularly sum and product). MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Mike Hucka — 2013-03-29T17:23:28-00:00

On Fri, 29 Mar 2013 07:33:57 -0600, Chris J. Myers wrote: > Ok, I was curious what we actually are leaving out, so I checked it out: > > <a href="http://www.w3.org/TR/MathML3/chapter4.html" target="_blank">http://www.w3.org/TR/MathML3/chapter4.html</a> That's the wrong version of MathML :-). We're using 2.0, not 3.0. The correct spec is <a href="http://www.w3.org/TR/MathML2/." target="_blank">http://www.w3.org/TR/MathML2/.</a> MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

myers — 2013-03-29T16:42:21-00:00

> > Two editors have made their preference for the shift clear though Sarah > was very subtle. Chris on the other side is against it. I would like to > hear the opinion of the remaining two editors in addition to modelers. > I believe it is clear that Nicolas wants all of mathML. I'm not as sure about Sarah. Would be interesting to get her confirmation of this feeling. I'm also not sure that it is a black and white question. I'm against adding all of mathML to the core. However, I'm for adding new mathML using packages (this is a most for arrays). As Lucian pointed out, we can add all of mathML by having someone (Nicolas?) propose a new package that does exactly that. Now, it may be tricky to satisfy the two tools support constraint for this new package. However, it may be possible to work this out by making an argument that "support" for this package entails simply allowing one to load/add/edit/store this new content. Chris ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

fbergman — 2013-03-29T16:32:51-00:00

> > Two editors have made their preference for the shift clear though Sarah was > very subtle. Chris on the other side is against it. I would like to hear the > opinion of the remaining two editors in addition to modelers. > Hello all, When Sarah first started this post, the aim was to gauge the communities interest in how to approach other standards. But since you ask my opinion I feel we need to remain focused on the exchange of models. With Level 3 Packages and the open scheme that allow any third party annotation to be added, I feel there is no encoding problem. In the specific case of MathML I feel we have to be very careful in extending what is allowed to be used. When we do, we need to consider the side effects it will have. The particular problem I have with allowing all of MathML is that alone the question, of whether a particular piece of MathML is supported or not becomes quite hard to solve. I do realize that this makes it harder on the Package Working Groups to define the right subset to be used for the individual package. But I feel that effort is still far lower than that of tools implementing support for it. All the best Frank ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Stefan.Hoops — 2013-03-29T16:01:28-00:00

Hello All, I think this discussion though very helpful with respect to MathML is missing the point. The question behind this discussion is whether SBML does a paradigm shift from exchange format to encoding format where the later tries to be all encompassing. SBML has been designed as an exchange language between tools supporting Systems Biology. This has served the community (software developers and modelers) very well. This success of SBML lead to the fact that many new tools just use SBML as their only file format. Here is where the problem lies. New tools are suppose to do new things which of course can not be part of the standard yet. SBML Level 3 provides excellent means to add these new concepts not just through the package extension system. New attributes and elements can be added everywhere as long as the XML is well formatted and validates against the SBML L3 core schema. Thus new tools can easily add their novel concepts to an SBML document. The question for MathML is whether these new concepts should be preemptively added. This is in my opinion with respect to the Level 3 guidelines: <a href="http://sbml.org/Documents/SBML_Development_Process/SBML_Development_Process_for_SBML_Level_3" target="_blank">http://sbml.org/Documents/SBML_Development_Process/SBML_Development_Process_for_SBML_Level_3</a> not possible, since we have the requirement that we need 2 tools which each must support over 50% of content MathML. Additionally content MathML must be covered completely by any number of packages. Therefore the real discussion is whether we remove the software support requirement and move away from defining SBML as an exchange format to a general encoding format. Two editors have made their preference for the shift clear though Sarah was very subtle. Chris on the other side is against it. I would like to hear the opinion of the remaining two editors in addition to modelers. Thanks, Stefan On Thu, 28 Mar 2013 10:59:04 +0000 Sarah Keating <<a href="mailto:skeating@caltech.edu" target="_blank">skeating@caltech.edu</a>> wrote: > Thanks to everything for the very interesting discussion. > > Two of the point made are: > > 1. Restricting the MathML subset used by SBML means that modellers > cannot express their models. > > 2. Including all of MathML content in SBML means that a piece of > software is unlikely to support the whole standard; so someone > attempting a particular analysis of a given model might have to shop > around to find a software that supports a particular construct. > > It would be great to have some input from modellers who are not also > involved in software development**. Are you hampered by the > restricted MathML subset ? If you could encode your model in SBML, > would it be problematic if only one (or possible no) piece of > software supported the simulation/analysis of this model ? > > Sarah > > ** I'm not saying that people who replied are not modellers, nor > discounting their opinions; just noting that most of the people who > have expressed an opinion are connected to the development of various > softwares. > ____________________________________________________________ To > manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> -- Stefan Hoops, Ph.D. Senior Project Associate Virginia Bioinformatics Institute - 0477 Virginia Tech Bioinformatics Facility II Blacksburg, Va 24061, USA Phone: (540) 231-1799 Fax: (540) 231-2606 Email: <a href="mailto:shoops@vbi.vt.edu" target="_blank">shoops@vbi.vt.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

myers — 2013-03-29T15:27:52-00:00

> > * Do you think an L3v1 'all MathML' package would be useful? Perhaps, or as my last mail suggested, this could be handled with a few new functions in core, an arrays and sets package, a calculus package (if desired), and a complex package (if desired). I think that basically covers the gambit. > * Pick one of the following three options: > * I think SBML L3v2 should incorporate all of MathML even if the > proposed package did not exist. No. > * I think SBML L3v2 should incorporate all of MathML only if the > proposed package was implemented and found to be useful. No. > * I think SBML L3v2 should not incorporate all of MathML even if the > proposed package was implemented and found to be useful (i.e. you > think the benefits of that package are fully realized in the package > itself). Yes, even then I think it is better to separate the features into packages. In this way, a tool can be compliant with core plus specific packages. It is easy on users, so they know which tool supports their needs. This is a major concern of mine. We do now have many tools (contrary to Nicolas assessment) that support all of our mathML subset. We don't want to lose our current level of compliant tools. > * Would you be willing to help write such a package? Am already helping with the arrays and sets part. > * Would you be willing to implement support for such a package? I'm very interested in the arrays and sets package, and we will make our tool support that package. I'm not as sure about calculus or complex though. > * If SBML L3v2 only expanded the subset of MathML we support, what > constructs (if any) do you think are most needed: ________________ > quotient, remainder, nonanumber, infinity Maybe gcd and lcm, but I think they could be part of arrays and sets. Chris ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

myers — 2013-03-29T13:33:57-00:00

Ok, I was curious what we actually are leaving out, so I checked it out: <a href="http://www.w3.org/TR/MathML3/chapter4.html" target="_blank">http://www.w3.org/TR/MathML3/chapter4.html</a> 1) Functions and inverses - we only support lambda (for functions definitions) and piecewise. Not clear if any of the others are needed by us. 2) Arithmetic, algebra, logic - we support most of these. We should add quotient, remainder, and perhaps gcd and lcm. Others such as root, forall, exists, are pretty loaded. The rest deal with complex numbers, does anybody need those? 3) Relations - we support most of these. The exception are equivalent, approximately, and factor of. Not sure we need any of these. 4) Calculus and vector calculus - we do not support these. They would be difficult to do so, but they may be useful. They could perhaps be added by a package, if desired. 5) Theory of sets - we support none of these. I think they may perhaps be useful if we add sets, so they could be added by a "sets" package. 6) Sequences and series - we support none of these. I think these are ones that Nicolas would like to have. We really need arrays or sets to make full use of them though. 7) Elementary classical functions - we support all of these. 8) Statistics - we support none of these. These are things like mean, variance, etc. They may be useful if we add arrays or sets, perhaps. 9) Linear algebra - we support none of these, but they will be added by the arrays package. 10) Constant and symbol elements - only support exponentiale, true, false, and pi. Would like to add infinity and notanumber, and perhaps emptyset with a sets package. Not so sure about any of the others. So, in summary, I think there are a few things we can add to core that would be useful (quotient, remainder, infinity, notanumber). I think if can breakdown the rest into the following packages: 1) Arrays and sets 2) Calculus 3) Complex numbers We are already planning on arrays and sets package which I think will add a lot to the mathML subset. Many of the missing operators only make sense if we have arrays and sets. The question is whether people would like the calculus and complex parts as well? Cheers, Chris On Mar 28, 2013, at 5:14 PM, hsauro <<a href="mailto:hsauro@u.washington.edu" target="_blank">hsauro@u.washington.edu</a>> wrote: > I still haven't heard a good case for expanding SBML to more MathML > other than it can be done. What can't be done with current SBML that > modelers would really like to do? Personally I can't think of anything I > would need at the moment on the math side (other than arrays perhaps) > though of course others may needs additional math constructs. > > The one application I am involved in on the side is multicellular > models. But what restricts us here is not the lack of math but a > community agreed way to represent multicellular systems using a > *biological description* which could be converted by a tool into a math > representation. Given the huge variety of approaches in this area it > wouldn't make sense to have a fixed math representation which is how > CellML/FieldML might do it for example. One could perhaps imagine arrays > being handy in describing a multicellular model. > > Herbert > > On 3/28/2013 3:19 PM, Lucian Smith wrote: >> * Mike Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> [2013-03-28 21:04] writes: >>> On Thu, 28 Mar 2013 11:00:02 +0100, Andreas Dr?ger wrote: >>>> I think we have read many important concerns and opinions about this >>>> crucial topic. Maybe a community vote such as >>>> >>>> * Extend MathML subset at all? >>>> if yes, should it be done by >>>> * Declaring a separate package with the entire MathML >>>> * Step-wise extending the MathML package in subsequent SBML versions >>>> * Allowing the entire MathML content in SBML's core >>>> >>>> could help to figure out what should be done? >>> This is the best approach to reaching a community decision, IMHO, and fits with how major SBML decisions have been done in the past. >> A vote does seem reasonable, but I'd still be interested in more >> discussion before actually voting. >> >> To be clear, here is the current situation, as I understand it from >> discussions here at at previous SBML Editor meetings: >> >> * In SBML L3v1 core, the specification allows only a subset of MathML to >> be used. >> >> * The editors have agreed that a generous interpretation of that language >> would allow any package to extend that subset. The 'arrays and sets' >> package is planning to allow vector and matrix constructions, following >> this rule. It would therefore be possible to define an 'allMathML' >> package that extended the 'subset' to 'all of MathML'. Any two packages >> that wanted to extend the MathML subset to include the same new element >> (i.e. both 'allMathML' and 'arrays' adding the 'sum' element) could do so >> without conflict, as the semantic meaning of that element is defined by >> MathML, not SBML. >> >> So, that's the state of the core today; it would be relatively >> straightforward for someone to run with Chris's suggestion and create a >> package, with no change at all to the core. If someone did this, they >> could do so following the procedure at >> >> <a href="http://sbml.org/Documents/SBML_Development_Process/SBML_Development_Process_for_SBML_Level_3" target="_blank">http://sbml.org/Documents/SBML_Development_Process/SBML_Development_Process_for_SBML_Level_3</a> >> >> The first stage of which is 'write a proposal, and put it up for a vote'. >> The proposal does not need to be complicated! It need only describe how >> the proposed package would proceed, and how it would fulfil the >> architectural principles of Utility, Biological Orientation, Coherence, >> and Orthogonality. As stated on the above page: >> >> "There are no length requirements for a package proposal. The proposal >> should be long enough to allow the SBML community to assess and vote on >> the proposal as described below. Some packages may be simple enough that a >> few paragraphs suffice; others may need more detailed explanations. In all >> cases, authors of package proposals are advised to pay particular >> attention to giving clear explanations of (i) the needs that the proposed >> package is meant to address and (ii) the approach being proposed to >> address those needs." >> >> Now, if anyone was so inclined to do something like this, they may well >> want to have a straw poll from sbml-discuss beforehand, so they didn't >> waste too much effort on something people actively object to. But I would >> not want that straw poll to be binding. (Indeed, a more useful poll might >> be 'I would like to work on this; who's up for helping and/or would >> implement support for it once it was written?') >> >> >> So. The *next* question is, "What about SBML L3v2?" The current plan is >> to at *least* extend the MathML subset by adding in particular things. >> See, for example, <a href="http://sourceforge.net/p/sbml/sbml-specifications/229/" target="_blank">http://sourceforge.net/p/sbml/sbml-specifications/229/</a> >> >> So the question would be not whether to increase the subset at all (that >> has already been agreed to), but *how much* to increase it by: what >> particular constructs to add in, or whether to just say 'open the >> floodgates'. >> >> If we did a poll now, this is what I would ask: >> >> * Do you think an L3v1 'all MathML' package would be useful? >> * Pick one of the following three options: >> * I think SBML L3v2 should incorporate all of MathML even if the >> proposed package did not exist. >> * I think SBML L3v2 should incorporate all of MathML only if the >> proposed package was implemented and found to be useful. >> * I think SBML L3v2 should not incorporate all of MathML even if the >> proposed package was implemented and found to be useful (i.e. you >> think the benefits of that package are fully realized in the package >> itself). >> * Would you be willing to help write such a package? >> * Would you be willing to implement support for such a package? >> * If SBML L3v2 only expanded the subset of MathML we support, what >> constructs (if any) do you think are most needed: ________________ >> >> >> -------------- >> >> Above I tried to be objective; what follows is more my opinion. >> >> After having written out the above, it seems clear to me that the >> simplest, most straightforward way to go is for someone who cares enough >> to write up a package proposal, gather other supporters, and see if they >> can get through to getting two implementations of an 'allMathML' package. >> If this turned out to be incredibly easy, it would be a compelling >> argument for, in the future, folding that package into core. If it turned >> out to be hard, it would justify people's fears who didn't want it. >> Either way, the experiment would be performed, and the usefulness of the >> package would be less a matter of debate and more a matter of observation. >> >> The other issue is that if this package *couldn't* get enough support to >> follow through to two implementations of it, we would know that it was a >> good thing we didn't try to put it into l3v2, because acceptance of core >> also requires two implementations, which apparantly there was not >> community will for. >> >> So my current inclination is to push for someone who believes 'all of >> MathML' is the way to go to move forward on that idea as a package, and >> convince the rest of us through example. I, at least, would absolutely >> support such an effort. >> >> -Lucian >> ____________________________________________________________ >> To manage your sbml-discuss list subscription, visit >> <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> >> >> For a web interface to the sbml-discuss mailing list, visit >> <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> >> >> For questions or feedback about the sbml-discuss list, >> contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> > > > -- > Herbert M. Sauro, PhD > Associate Professor > Department of Bioengineering > > University of Washington > William H. Foege Building > Box 355061, Seattle, WA 98195-5061 > 206.685.2119 (tel), 206.685.3300 (shared fax) > > <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> > New Text Book: Enzyme Kinetics for Systems Biology > Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

hsauro — 2013-03-28T23:14:54-00:00

I still haven't heard a good case for expanding SBML to more MathML other than it can be done. What can't be done with current SBML that modelers would really like to do? Personally I can't think of anything I would need at the moment on the math side (other than arrays perhaps) though of course others may needs additional math constructs. The one application I am involved in on the side is multicellular models. But what restricts us here is not the lack of math but a community agreed way to represent multicellular systems using a *biological description* which could be converted by a tool into a math representation. Given the huge variety of approaches in this area it wouldn't make sense to have a fixed math representation which is how CellML/FieldML might do it for example. One could perhaps imagine arrays being handy in describing a multicellular model. Herbert On 3/28/2013 3:19 PM, Lucian Smith wrote: > * Mike Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> [2013-03-28 21:04] writes: >> On Thu, 28 Mar 2013 11:00:02 +0100, Andreas Dr?ger wrote: >>> I think we have read many important concerns and opinions about this >>> crucial topic. Maybe a community vote such as >>> >>> * Extend MathML subset at all? >>> if yes, should it be done by >>> * Declaring a separate package with the entire MathML >>> * Step-wise extending the MathML package in subsequent SBML versions >>> * Allowing the entire MathML content in SBML's core >>> >>> could help to figure out what should be done? >> This is the best approach to reaching a community decision, IMHO, and fits with how major SBML decisions have been done in the past. > A vote does seem reasonable, but I'd still be interested in more > discussion before actually voting. > > To be clear, here is the current situation, as I understand it from > discussions here at at previous SBML Editor meetings: > > * In SBML L3v1 core, the specification allows only a subset of MathML to > be used. > > * The editors have agreed that a generous interpretation of that language > would allow any package to extend that subset. The 'arrays and sets' > package is planning to allow vector and matrix constructions, following > this rule. It would therefore be possible to define an 'allMathML' > package that extended the 'subset' to 'all of MathML'. Any two packages > that wanted to extend the MathML subset to include the same new element > (i.e. both 'allMathML' and 'arrays' adding the 'sum' element) could do so > without conflict, as the semantic meaning of that element is defined by > MathML, not SBML. > > So, that's the state of the core today; it would be relatively > straightforward for someone to run with Chris's suggestion and create a > package, with no change at all to the core. If someone did this, they > could do so following the procedure at > > <a href="http://sbml.org/Documents/SBML_Development_Process/SBML_Development_Process_for_SBML_Level_3" target="_blank">http://sbml.org/Documents/SBML_Development_Process/SBML_Development_Process_for_SBML_Level_3</a> > > The first stage of which is 'write a proposal, and put it up for a vote'. > The proposal does not need to be complicated! It need only describe how > the proposed package would proceed, and how it would fulfil the > architectural principles of Utility, Biological Orientation, Coherence, > and Orthogonality. As stated on the above page: > > "There are no length requirements for a package proposal. The proposal > should be long enough to allow the SBML community to assess and vote on > the proposal as described below. Some packages may be simple enough that a > few paragraphs suffice; others may need more detailed explanations. In all > cases, authors of package proposals are advised to pay particular > attention to giving clear explanations of (i) the needs that the proposed > package is meant to address and (ii) the approach being proposed to > address those needs." > > Now, if anyone was so inclined to do something like this, they may well > want to have a straw poll from sbml-discuss beforehand, so they didn't > waste too much effort on something people actively object to. But I would > not want that straw poll to be binding. (Indeed, a more useful poll might > be 'I would like to work on this; who's up for helping and/or would > implement support for it once it was written?') > > > So. The *next* question is, "What about SBML L3v2?" The current plan is > to at *least* extend the MathML subset by adding in particular things. > See, for example, <a href="http://sourceforge.net/p/sbml/sbml-specifications/229/" target="_blank">http://sourceforge.net/p/sbml/sbml-specifications/229/</a> > > So the question would be not whether to increase the subset at all (that > has already been agreed to), but *how much* to increase it by: what > particular constructs to add in, or whether to just say 'open the > floodgates'. > > If we did a poll now, this is what I would ask: > > * Do you think an L3v1 'all MathML' package would be useful? > * Pick one of the following three options: > * I think SBML L3v2 should incorporate all of MathML even if the > proposed package did not exist. > * I think SBML L3v2 should incorporate all of MathML only if the > proposed package was implemented and found to be useful. > * I think SBML L3v2 should not incorporate all of MathML even if the > proposed package was implemented and found to be useful (i.e. you > think the benefits of that package are fully realized in the package > itself). > * Would you be willing to help write such a package? > * Would you be willing to implement support for such a package? > * If SBML L3v2 only expanded the subset of MathML we support, what > constructs (if any) do you think are most needed: ________________ > > > -------------- > > Above I tried to be objective; what follows is more my opinion. > > After having written out the above, it seems clear to me that the > simplest, most straightforward way to go is for someone who cares enough > to write up a package proposal, gather other supporters, and see if they > can get through to getting two implementations of an 'allMathML' package. > If this turned out to be incredibly easy, it would be a compelling > argument for, in the future, folding that package into core. If it turned > out to be hard, it would justify people's fears who didn't want it. > Either way, the experiment would be performed, and the usefulness of the > package would be less a matter of debate and more a matter of observation. > > The other issue is that if this package *couldn't* get enough support to > follow through to two implementations of it, we would know that it was a > good thing we didn't try to put it into l3v2, because acceptance of core > also requires two implementations, which apparantly there was not > community will for. > > So my current inclination is to push for someone who believes 'all of > MathML' is the way to go to move forward on that idea as a package, and > convince the rest of us through example. I, at least, would absolutely > support such an effort. > > -Lucian > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> -- Herbert M. Sauro, PhD Associate Professor Department of Bioengineering University of Washington William H. Foege Building Box 355061, Seattle, WA 98195-5061 206.685.2119 (tel), 206.685.3300 (shared fax) <a href="http://www.sys-bio.org" target="_blank">http://www.sys-bio.org</a>; <a href="http://blog.analogmachine.org" target="_blank">http://blog.analogmachine.org</a> New Text Book: Enzyme Kinetics for Systems Biology Order at Amazon: <a href="http://tinyurl.com/3w4b9al" target="_blank">http://tinyurl.com/3w4b9al</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Lucian Smith — 2013-03-28T22:19:05-00:00

* Mike Hucka <<a href="mailto:mhucka@caltech.edu" target="_blank">mhucka@caltech.edu</a>> [2013-03-28 21:04] writes: > On Thu, 28 Mar 2013 11:00:02 +0100, Andreas Dr?ger wrote: > > I think we have read many important concerns and opinions about this > > crucial topic. Maybe a community vote such as > > > > * Extend MathML subset at all? > > if yes, should it be done by > > * Declaring a separate package with the entire MathML > > * Step-wise extending the MathML package in subsequent SBML versions > > * Allowing the entire MathML content in SBML's core > > > > could help to figure out what should be done? > > This is the best approach to reaching a community decision, IMHO, and fits with how major SBML decisions have been done in the past. A vote does seem reasonable, but I'd still be interested in more discussion before actually voting. To be clear, here is the current situation, as I understand it from discussions here at at previous SBML Editor meetings: * In SBML L3v1 core, the specification allows only a subset of MathML to be used. * The editors have agreed that a generous interpretation of that language would allow any package to extend that subset. The 'arrays and sets' package is planning to allow vector and matrix constructions, following this rule. It would therefore be possible to define an 'allMathML' package that extended the 'subset' to 'all of MathML'. Any two packages that wanted to extend the MathML subset to include the same new element (i.e. both 'allMathML' and 'arrays' adding the 'sum' element) could do so without conflict, as the semantic meaning of that element is defined by MathML, not SBML. So, that's the state of the core today; it would be relatively straightforward for someone to run with Chris's suggestion and create a package, with no change at all to the core. If someone did this, they could do so following the procedure at <a href="http://sbml.org/Documents/SBML_Development_Process/SBML_Development_Process_for_SBML_Level_3" target="_blank">http://sbml.org/Documents/SBML_Development_Process/SBML_Development_Process_for_SBML_Level_3</a> The first stage of which is 'write a proposal, and put it up for a vote'. The proposal does not need to be complicated! It need only describe how the proposed package would proceed, and how it would fulfil the architectural principles of Utility, Biological Orientation, Coherence, and Orthogonality. As stated on the above page: "There are no length requirements for a package proposal. The proposal should be long enough to allow the SBML community to assess and vote on the proposal as described below. Some packages may be simple enough that a few paragraphs suffice; others may need more detailed explanations. In all cases, authors of package proposals are advised to pay particular attention to giving clear explanations of (i) the needs that the proposed package is meant to address and (ii) the approach being proposed to address those needs." Now, if anyone was so inclined to do something like this, they may well want to have a straw poll from sbml-discuss beforehand, so they didn't waste too much effort on something people actively object to. But I would not want that straw poll to be binding. (Indeed, a more useful poll might be 'I would like to work on this; who's up for helping and/or would implement support for it once it was written?') So. The *next* question is, "What about SBML L3v2?" The current plan is to at *least* extend the MathML subset by adding in particular things. See, for example, <a href="http://sourceforge.net/p/sbml/sbml-specifications/229/" target="_blank">http://sourceforge.net/p/sbml/sbml-specifications/229/</a> So the question would be not whether to increase the subset at all (that has already been agreed to), but *how much* to increase it by: what particular constructs to add in, or whether to just say 'open the floodgates'. If we did a poll now, this is what I would ask: * Do you think an L3v1 'all MathML' package would be useful? * Pick one of the following three options: * I think SBML L3v2 should incorporate all of MathML even if the proposed package did not exist. * I think SBML L3v2 should incorporate all of MathML only if the proposed package was implemented and found to be useful. * I think SBML L3v2 should not incorporate all of MathML even if the proposed package was implemented and found to be useful (i.e. you think the benefits of that package are fully realized in the package itself). * Would you be willing to help write such a package? * Would you be willing to implement support for such a package? * If SBML L3v2 only expanded the subset of MathML we support, what constructs (if any) do you think are most needed: ________________ -------------- Above I tried to be objective; what follows is more my opinion. After having written out the above, it seems clear to me that the simplest, most straightforward way to go is for someone who cares enough to write up a package proposal, gather other supporters, and see if they can get through to getting two implementations of an 'allMathML' package. If this turned out to be incredibly easy, it would be a compelling argument for, in the future, folding that package into core. If it turned out to be hard, it would justify people's fears who didn't want it. Either way, the experiment would be performed, and the usefulness of the package would be less a matter of debate and more a matter of observation. The other issue is that if this package *couldn't* get enough support to follow through to two implementations of it, we would know that it was a good thing we didn't try to put it into l3v2, because acceptance of core also requires two implementations, which apparantly there was not community will for. So my current inclination is to push for someone who believes 'all of MathML' is the way to go to move forward on that idea as a package, and convince the rest of us through example. I, at least, would absolutely support such an effort. -Lucian ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Mike Hucka — 2013-03-28T21:29:16-00:00

The use of a package to extend the set of allowed math constructs has potential, but I think it is likely to remain problematic if the entire set of content MathML 2.0 constructs are permitted, for reasons that Andrew Miller pointed out and Bruce Shapiro reinforced. I think no one would implement support for all of the constructs. Do people think it would be impossible to identify a subset of MathML that is nearly complete, but omits constructs that don't make sense ever including? For instance, 'diff', 'partialdiff', 'forall' and 'exists' would probably fall into the category of constructs that could be skipped. I think it would be bad to do step-wise incremental increases, for the reason Andreas Draeger pointed out: L3V1 (or a package) would have some constructs, L3V2 (or another package) would have other constructs, and tools would have to keep track of it all. I think it would be better to go for a one-shot increase in the subset. Whether it's done as a package or the core needs further evaluation. Yes, you can argue that if we do a subset, sooner or later someone's going to find that they need the missing constructs. But surely we can evaluate what's missing, and make a decision informed by the last dozen years of SBML and the knowledge of modeling people want to do today and the near future? In the worst case, 10 years from now we'll have to revisit it again. That doesn't seem bad, on balance. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Mike Hucka — 2013-03-28T21:02:57-00:00

On Tue, 26 Mar 2013 19:18:30 +0000, Nicolas Le Novere wrote: > This is the crux of the problem. If we want all the models to be backwards > compatible, or to be usable by older tools, we are basically restricting > ourselves to the kind of models that were supported then. This is the SBML > tautology. We incorporate feature X because SBML supporting tools use X. > And then X is supported. Which will bring more tools supporting SBML to > incorporate X. But if we never allow other tools to use SBML to encode new > facilities, whether new math, or Semantic Web facilities etc. We will be > stuck with X forever. > > IMHO, a better solution to optimally use the extensive SBML toolkit would > be to impose that tools claiming to support SBML always load the models, > but with the option of returning a "sorry, can't do it. Visit the SBML > software guide to find tools possibly supporting this feature". I agree with this. The current specifications do not stipulate the behavior software should exhibit if it encounters MathML constructs it does not encounter. It should do that, no matter what is chosen w.r.t. the MathML subset. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Mike Hucka — 2013-03-28T21:00:55-00:00

On Thu, 28 Mar 2013 11:00:02 +0100, Andreas Dräger wrote: > I think we have read many important concerns and opinions about this > crucial topic. Maybe a community vote such as > > * Extend MathML subset at all? > if yes, should it be done by > * Declaring a separate package with the entire MathML > * Step-wise extending the MathML package in subsequent SBML versions > * Allowing the entire MathML content in SBML's core > > could help to figure out what should be done? This is the best approach to reaching a community decision, IMHO, and fits with how major SBML decisions have been done in the past. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Mike Hucka — 2013-03-28T20:53:53-00:00

On Wed, 27 Mar 2013 07:42:49 +1300, Andrew Miller wrote: > The problem is when features interact in complicated ways; if f(g(x)) > has some special meaning that is harder to implement than f(x) and g(x), > then it is no good to say that tool A supports f(x), and tool B supports > g(x), and so therefore there is full coverage of the specification. This is a fair point. It has relevance in particular to Section 3.3.1 of the current SBML Development Process (<a href="http://goo.gl/n3WOM" target="_blank">http://goo.gl/n3WOM</a>) for Level 3 package development, where we state "Every feature in the package specification must be supported and manipulated by at least one of the two tools" (which, BTW, is not meant to be read as saying there must exist at least one tool that implements support for all features, but rather that there must be at least two tools that, between them, support for all the defined features of a package.) This choice of criteria was done to reduce the time and burden to finalize an L3 package specification, but it does have the problem that it can miss interactions. It was judged to be a reasonable compromise between risk and difficulty, but it bears keeping in mind that the problem exists. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Ben Heavner — 2013-03-28T20:09:13-00:00

I consider myself more of a model builder than software developer, but focus on constraint based models, not dynamic models. I am not hampered by the current subset of MathML that's supported by SBML. Like Dr. Ligon, I have had more trouble with other aspects of SBML - particularly 1) annotation; 2) the use of gene-protein reactions which are associated with reactions in current metabolic network reconstructions and model; and 3) the ability to describe constraints applied to reactions for non-kinetic reasons. In other words, the software I need to do my work are tools that rely on SBML to exchange information, but which rely on other techniques for calculating possible flux distributions across the biochemical networks I'm evaluating. I rely completely on the SBML Toolbox for translating between the MATLAB data structures I work with and the SBML files used to exchange models. Since my work doesn't rely on MathML, my primary concern is how changes to SBML might affect the SBML Toolbox - all of which may be only peripherally related to the ongoing conversation (and why I haven't chimed in until Sarah asked for non-developer perspectives). Keep up the good work! - Ben

Re: Restricted use of third-party standards by SBML

Nicolas Le Novere[1] — 2013-03-28T19:59:59-00:00

On 28/03/13 19:26, Michael Hucka wrote: > As you point out, many tools today are not simulators, so they do not > need to do the math at all. This is where we disagree. Math is not just for simulation. Being able to edit, represent, parse, and convert the math is all part of the modeling activity. Numerical simulation is of course important. But it only part of the M&S life cycle, and only for a (very important and very large) part of the systems biology activities. This is where the whole issue of "sum" and "vector" is. I never pretended that simulator would have to support "sum" in simulation context. Their use in SBO is upstream to the generation of the final, simulatable model. In pharmacometrics, it would also not be used in simulation situation after sampling. And finally, I know at least one example where people used a Taylor extension to convert models. All that is modeling. Modeling is not just "run a timecourse simulation from t=0 to t=100". And actually I think SBML already mostly nailed this part many years ago! -- Nicolas LE NOVERE, Babraham Institute, Babraham Campus Cambridge, CB22 3AT Tel: +441223496433 Fax: +441223496034 Mob:+447833147074 twitter:@lenovere Skype:n.lenovere, <a href="mailto:n.lenovere@gmail.com" target="_blank">n.lenovere@gmail.com</a>, orcid.org/0000-0001-2345-6789 <a href="http://lenoverelab.org/," target="_blank">http://lenoverelab.org/,</a> <a href="http://lenoverelab.org/perso/lenov/" target="_blank">http://lenoverelab.org/perso/lenov/</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

bshapiro — 2013-03-28T19:56:43-00:00

With all the back and forth on this topic my apologies if this duplicates another comment. While I would personally prefer to see the entire MathML in the core (I have never agreed with the limited set) I would think the main concern would be that this would possibly allow representations in SBML that were not actually intended by the group consensus, or might conflict with one of the existing extensions. For example, it would allow arrays, lists, and vectors into SBML through the "back-door" in a sense. I (personally) don't see this particular addition as a problem but I think what is needed is a detailed examination of all MathSBML features in light of the existing extensions to L3 to see if there are any potential conflicts, and then to enumerate those conflicts to see if any of them really matter. -- Bruce E Shapiro PhD Biological Network Modeling Center California Institute of Technology M/C 139-74, 1200 E California Blvd Pasadena, CA 91125 <a href="http://bnmc.caltech.edu" target="_blank">http://bnmc.caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

Mike Hucka — 2013-03-28T19:26:49-00:00

On Tue, 26 Mar 2013 17:50:43 +0000, Nicolas Le Novere wrote: > On 26/03/13 17:25, Lucian Smith wrote: >> As one point to counter Nicolas's allegations that simulators don't >> actually support the subset of MathML listed in the spec: the SBML Test >> Suite does indeed include examples of all of these functions, including >> 'ceil' and 'tanh'. > > No the test-suite does not have any test for tanh actually. All the other > trigonometric functions are used in models without differential equations > only with assignment rules (basically the function is passed to the > underlying programming language without any tool-specific processing). See > cases 957, 958, 959, generated by Antimony ;-) [Catching up after travels.] Irrespective of other arguments, I wanted to say that I think this is a misleading line of argument. First, as should be clear now, the missing test for tanh is an accident. As a rule, the test suite provides test cases that cover all the math constructs, and I believe we did a respectable job. (There are even test cases for piecewise.) In fact, I would argue that there is *so* much coverage in the suite today that even if one or a very few constructs are not tested, one can still gain a reasonable measure of confidence in a given tool's capabilities, based on the fact if the tool covers the cases that do exist, it is likely to also cover the missing tests. (Of course, we don't want to miss any, and we continue to add more cases.) Second, I don't know what significance should be assigned to "the function is passed to the underlying programming language without any tool-specific processing". No one's going to reimplement tanh or other functions if they can hand them off to a well-tested, off-the-shelf library. So what? In any case, IMHO, the absence of one test (or even a couple) in the test suite should not be taken as supporting an argument that *no* software tool supports the MathML subset currently defined in SBML. The recently-introduced SBML Test Suite database (<a href="http://sbml.org/Facilities/Database" target="_blank">http://sbml.org/Facilities/Database</a>), which admittedly does not have many entries today, *does* have more than one that pass all the tests. (There are actually more known tools that could be listed in the database, but results haven't been submitted by their authors. Hopefully they will in time.) Yes, the number of tools listed is small, but I think we should celebrate the coverage we do have, because it is concrete evidence of significant evolution in tools over the past few years. That said, however, I *do* agree with you where, in another message, you wrote: > the nice myth that all SBML > supporting tools are supporting the MathML subset of the core. It is indeed true that *not all* SBML-supporting tools (not even a majority) support the MathML subset of the core. As you point out, many tools today are not simulators, so they do not need to do the math at all. There are also other tools that could support all of the math, but do not yet; perhaps these will in time be helped by the availability of SBML libraries that do provide all of that functionality. MH ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

thomassligon — 2013-03-28T17:31:42-00:00

Here is a response from a user who is not a developer of modeling tools. I use some modeling tools, especially Copasi and SPiM, and I use SBML, mostly indirectly, but sometimes examine the file explicitly. I have lengthy experience in software development, but have not developed any modeling tools, and am not doing that now.Up to now, I have not encountered any limitation in the subset of MathML supported by SBML, but I have encountered limitations of SBML itself (that is a topic for a future discussion after I have a better basis for it). With that, my recommendation would be to allow the full, undiluted MathML standard in SBML and let the tool developers choose which subset they implement. That would put the burden of defining useful and feasible subsets of MathML on the MathML community. It would also put the decision about what to code in a tool in the hands of the people who are actually writing that code and are closest to knowing how easy or hard it is. The tool develo per also has the best understanding of the intended user community and scope of the tool. Then the SBML community could add value by producing recommendations, such asA tool focused on deterministic simulation of mass-action chemical reaction networks should support MathML subset xxx.A tool that includes complex kinetics (MM, Hill, ...) should support... Tom Ligon(Dr. Thomas Ligon, guest scientist at LMU, Uni Muenchen) <a href="mailto:thomassligon@hotmail.com" target="_blank">thomassligon@hotmail.com</a> > Date: Thu, 28 Mar 2013 14:51:04 +0000 > From: <a href="mailto:pedro.mendes@manchester.ac.uk" target="_blank">pedro.mendes@manchester.ac.uk</a> > To: <a href="mailto:sbml-discuss@caltech.edu" target="_blank">sbml-discuss@caltech.edu</a> > Subject: Re: [sbml-discuss] Restricted use of third-party standards by SBML > > Sarah touches an important point. So please let us hear from modellers > who are not developers. I hope we have some in the list (though I am > worried we do not!) > > Please state how you would use MathML in your models. > > I am quite interested to hear their opinion. > > Pedro > > On 03/28/2013 10:59 AM, Sarah Keating wrote: > > > > It would be great to have some input from modellers who are not also > > involved in software development**. > -- > Pedro Mendes > Professor of Computational Systems Biology > School of Computer Science > Manchester Centre for Integrative Systems Biology > University of Manchester > > Manchester Institute of Biotechnology > 131 Princess Street > Manchester, M1 7DN, U.K. > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>

Re: Restricted use of third-party standards by SBML

b.g.olivier — 2013-03-28T14:57:57-00:00

On 28/03/13 15:41, Chris J. Myers wrote: >> However, looking at the MathML 3 specification, instead of (only) a >> "fullMathML" package which is again a subset of mathematical functions >> why not go all the way and create a "strictMathML3" package (more >> information on Strict Content MathML here >> <a href="http://www.w3.org/TR/MathML3/chapter4.html#contm.strict" target="_blank">http://www.w3.org/TR/MathML3/chapter4.html#contm.strict</a>) or some >> mechanism for defining SBML MathML elements as either >> - belonging to the core subset or as >> - being Strict Content MathML3 >> in this way the model creator can choose their own aforementioned model >> priority. Another cool thing about Strict Content MathML is its use of >> Content Dictionaries (<a href="http://www.openmath.org/cd/index.html" target="_blank">http://www.openmath.org/cd/index.html</a>) which would >> really be making use of third party standards. >> > This is an interesting idea. My one concern though would be if the math used by the new package was no longer a superset of that allowed by our mathML subset then I think there may be some issues. Namely, it would be nice if one were say prototyping some ideas using the new math package which then get incorporated into a subset extension in a package that one could simply replace the new math package with the package that extends the subset with no other changes. Perhaps though you were proposing to use strictMathML3 even for the core subset? good point, I had in mind somehow specifying MathML in SBML core as either strict MathML or not ... but that probably leads to the same problems. b. > > Chris > > > ____________________________________________________________ > To manage your sbml-discuss list subscription, visit > <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> > > For a web interface to the sbml-discuss mailing list, visit > <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> > > For questions or feedback about the sbml-discuss list, > contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a> -- Brett G. Olivier PhD Researcher in Computational Systems Biology Systems Bioinformatics VU University Amsterdam Amsterdam, The Netherlands Email: b.g.olivier[AT]vu[dot]nl Tel (office) +31 20 5987248 ____________________________________________________________ To manage your sbml-discuss list subscription, visit <a href="https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss" target="_blank">https://utils.its.caltech.edu/mailman/listinfo/sbml-discuss</a> For a web interface to the sbml-discuss mailing list, visit <a href="http://sbml.org/Forums/" target="_blank">http://sbml.org/Forums/</a> For questions or feedback about the sbml-discuss list, contact <a href="mailto:sbml-team@caltech.edu" target="_blank">sbml-team@caltech.edu</a>