Menu
▾
▴
sbml-distrib — The SBML L3 Distributions and Ranges package discussion list
You can subscribe to this list here.
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2012 |
Jan
(17) |
Feb
(17) |
Mar
(30) |
Apr
(11) |
May
(5) |
Jun
|
Jul
|
Aug
(20) |
Sep
(12) |
Oct
|
Nov
(14) |
Dec
(18) |
| 2013 |
Jan
|
Feb
(3) |
Mar
(110) |
Apr
(34) |
May
(43) |
Jun
(2) |
Jul
(21) |
Aug
(2) |
Sep
(2) |
Oct
|
Nov
(1) |
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(7) |
Apr
(4) |
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(54) |
Jun
(6) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
(7) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
| 2019 |
Jan
(4) |
Feb
(15) |
Mar
(46) |
Apr
(8) |
May
|
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(32) |
Apr
(21) |
May
(8) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2021 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Lucian S. <luc...@gm...> - 2025-04-09 19:38:31
|
Hey, everyone! T.J. Sego, Rahuman Sheriff, and I are running a breakout session at HARMONY with the goal of creating an SBML Level 3 Package proposal that would allow SDE models to be stored in SBML, and solved using SED-ML. It's an open question whether this package should be added to the existing 'distrib' package or whether it should be its own thing, and there are other issues to be worked through and discussed as well. We would appreciate your presence, whether in person or online! The time will be: 14:00 - 17:30, CEST (Leuven, Belgium time) If you're at HARMONY, the location is the 'Function Room', and if you want to join online, use: https://ufl.zoom.us/j/91967283829 Thank you! -Lucian Smith |
|
From: Lucian S. <luc...@gm...> - 2021-10-14 00:13:41
|
At COMBINE today, Matthias brought up the question of how to include multivariate distributions in his modeling. He wasn't sure whether it belonged in SBML itself (with distrib v2 or the like) or if it belonged in SED-ML or somewhere else, and I'm also not sure about the answer to that question. It does at least seem to me that if it's OK to put univariate distributions in SBML as initial assignments/event assignments, it should be possible to put multivariate distributions in there, too. However, it's much more fun to think about *how* you would do it in SBML if you wanted, so here's a brief proposal for how I think it should work. So: Multivariate distributions return short vectors. In MathML where they occur, this divides the math into short vectors of the same size, on an element-by-element basis. In other words, if 'multidist2norms(a, b, c, d)' returns [x, y], then '3 + multidist2norms(a, b, c, d)' should return [3+x, 3+y]. We allow this sort of nonsense in exactly two places: the MathML of an InitialAssignment, and the MathML of an EventAssignment. When it occurs, we require a new distrib attribute on those elements: 'distrib:symbolList' for InitialAsignment, and 'distrib:variableList' for EventAssignment. That list must be a comma-separated list of SBML SId's of the same length as the short vector. The results, then are assigned to each element of the SId vector. Something like this: <initialAssignment symbol="a" distrib:symbolList="a, b"> <math xmlns="http://www.w3.org/1998/Math/MathML"> <apply> <csymbol encoding="text" definitionURL=" http://www.sbml.org/sbml/symbols/distrib/multinormal"> multinormal </csymbol> [arguments] </apply> </math> </initialAssignment> (The 'symbol' has to remain because it's required in SBML Core, but it would be ignored in this case in favor of symbolList. I could imagine a validation rule that it had to equal the first value in the list.) The only issue then would be whether we can actually define this with a limited set of csymbols and a regular argument list. It may be that we need an actual matrix as one of the arguments, or it may be that we can get away with splitting the matrix into a list of scalar values one after the other in the argument list. We do already allow different-length argument lists to mean different things, so maybe that'll work? In the end, if a request for a draw from a multivariate distribution can be expressed in MathML *somehow*, I think this is how I would incorporate that into SBML. -Lucian |
|
From: Lucian S. <luc...@gm...> - 2020-05-28 20:46:40
|
One other thing: I've put the SBML grant on as a funding source; does anyone else have a funding source to acknowledge? -Lucian On Thu, May 28, 2020 at 8:46 AM Lucian Smith <luc...@gm...> wrote: > Hey, I figured out how to get the actual PDF. It's now attached. > > I've done some capitalization fixes, too: > [image: image.png] > > I'll add in your email address! > > -Lucian > > On Thu, May 28, 2020 at 3:29 AM Matthias König via sbml-distrib < > sbm...@li...> wrote: > >> Hi Lucian, any chance to get access to the proof? Please just use >> kon...@go... as email. >> >> Best Matthias >> >> On Thu, May 28, 2020, 11:20 Maciek Jacek Swat <mac...@gm...> >> wrote: >> >>> hi Lucian, >>> I don't have orcid. >>> Best, MACIEJ >>> >>> On Thu, 28 May 2020 at 00:21, Chris Myers <my...@ec...> wrote: >>> >>>> Actually, do you mind sending a screenshot of the Title/Authors, so I >>>> can update my CV. >>>> >>>> Thanks, >>>> Chris >>>> >>>> > On May 27, 2020, at 5:19 PM, Chris Myers <my...@ec...> wrote: >>>> > >>>> > Hi, >>>> > >>>> > I did not see it, but I trust you :-) >>>> > >>>> > Thanks, >>>> > Chris >>>> > >>>> >> On May 27, 2020, at 4:18 PM, Lucian Smith <luc...@gm...> >>>> wrote: >>>> >> >>>> >> Hey, everyone--I just got the proof for the JIB publication of the >>>> SBML Distrib package. I've added everyone's orcid (except I don't have >>>> Maceij's--Maceij, do you have your orcid?), and capitalized 'Systems >>>> Biology Markup Language', which they used instead of just 'SBML', which is >>>> fair. >>>> >> >>>> >> I was told that the co-authors also have access to it, and that they >>>> should transmit any corrections to me. The main thing I can see is that >>>> I'm the only email address in the system; if anyone wants their email >>>> address added, I can do that. >>>> >> >>>> >> Thanks again, everyone! >>>> >> >>>> >> -Lucian >>>> >> _______________________________________________ >>>> >> sbml-distrib mailing list >>>> >> sbm...@li... >>>> >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > sbml-distrib mailing list >>>> > sbm...@li... >>>> > https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>>> >>>> >>>> >>>> _______________________________________________ >>>> sbml-distrib mailing list >>>> sbm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>>> >>> _______________________________________________ >>> sbml-distrib mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>> >> _______________________________________________ >> sbml-distrib mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >> > |
|
From: Lucian S. <luc...@gm...> - 2020-05-28 15:47:03
|
Hey, I figured out how to get the actual PDF. It's now attached. I've done some capitalization fixes, too: [image: image.png] I'll add in your email address! -Lucian On Thu, May 28, 2020 at 3:29 AM Matthias König via sbml-distrib < sbm...@li...> wrote: > Hi Lucian, any chance to get access to the proof? Please just use > kon...@go... as email. > > Best Matthias > > On Thu, May 28, 2020, 11:20 Maciek Jacek Swat <mac...@gm...> > wrote: > >> hi Lucian, >> I don't have orcid. >> Best, MACIEJ >> >> On Thu, 28 May 2020 at 00:21, Chris Myers <my...@ec...> wrote: >> >>> Actually, do you mind sending a screenshot of the Title/Authors, so I >>> can update my CV. >>> >>> Thanks, >>> Chris >>> >>> > On May 27, 2020, at 5:19 PM, Chris Myers <my...@ec...> wrote: >>> > >>> > Hi, >>> > >>> > I did not see it, but I trust you :-) >>> > >>> > Thanks, >>> > Chris >>> > >>> >> On May 27, 2020, at 4:18 PM, Lucian Smith <luc...@gm...> >>> wrote: >>> >> >>> >> Hey, everyone--I just got the proof for the JIB publication of the >>> SBML Distrib package. I've added everyone's orcid (except I don't have >>> Maceij's--Maceij, do you have your orcid?), and capitalized 'Systems >>> Biology Markup Language', which they used instead of just 'SBML', which is >>> fair. >>> >> >>> >> I was told that the co-authors also have access to it, and that they >>> should transmit any corrections to me. The main thing I can see is that >>> I'm the only email address in the system; if anyone wants their email >>> address added, I can do that. >>> >> >>> >> Thanks again, everyone! >>> >> >>> >> -Lucian >>> >> _______________________________________________ >>> >> sbml-distrib mailing list >>> >> sbm...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>> > >>> > >>> > >>> > _______________________________________________ >>> > sbml-distrib mailing list >>> > sbm...@li... >>> > https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>> >>> >>> >>> _______________________________________________ >>> sbml-distrib mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>> >> _______________________________________________ >> sbml-distrib mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >> > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > |
|
From: Maciek J. S. <mac...@gm...> - 2020-05-28 10:54:38
|
Forgot to add the email address, please use this one mac...@gm... On Thu, 28 May 2020 at 11:28, Matthias König via sbml-distrib < sbm...@li...> wrote: > Hi Lucian, any chance to get access to the proof? Please just use > kon...@go... as email. > > Best Matthias > > On Thu, May 28, 2020, 11:20 Maciek Jacek Swat <mac...@gm...> > wrote: > >> hi Lucian, >> I don't have orcid. >> Best, MACIEJ >> >> On Thu, 28 May 2020 at 00:21, Chris Myers <my...@ec...> wrote: >> >>> Actually, do you mind sending a screenshot of the Title/Authors, so I >>> can update my CV. >>> >>> Thanks, >>> Chris >>> >>> > On May 27, 2020, at 5:19 PM, Chris Myers <my...@ec...> wrote: >>> > >>> > Hi, >>> > >>> > I did not see it, but I trust you :-) >>> > >>> > Thanks, >>> > Chris >>> > >>> >> On May 27, 2020, at 4:18 PM, Lucian Smith <luc...@gm...> >>> wrote: >>> >> >>> >> Hey, everyone--I just got the proof for the JIB publication of the >>> SBML Distrib package. I've added everyone's orcid (except I don't have >>> Maceij's--Maceij, do you have your orcid?), and capitalized 'Systems >>> Biology Markup Language', which they used instead of just 'SBML', which is >>> fair. >>> >> >>> >> I was told that the co-authors also have access to it, and that they >>> should transmit any corrections to me. The main thing I can see is that >>> I'm the only email address in the system; if anyone wants their email >>> address added, I can do that. >>> >> >>> >> Thanks again, everyone! >>> >> >>> >> -Lucian >>> >> _______________________________________________ >>> >> sbml-distrib mailing list >>> >> sbm...@li... >>> >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>> > >>> > >>> > >>> > _______________________________________________ >>> > sbml-distrib mailing list >>> > sbm...@li... >>> > https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>> >>> >>> >>> _______________________________________________ >>> sbml-distrib mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>> >> _______________________________________________ >> sbml-distrib mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >> > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > |
|
From: Matthias K. <kon...@go...> - 2020-05-28 10:28:29
|
Hi Lucian, any chance to get access to the proof? Please just use kon...@go... as email. Best Matthias On Thu, May 28, 2020, 11:20 Maciek Jacek Swat <mac...@gm...> wrote: > hi Lucian, > I don't have orcid. > Best, MACIEJ > > On Thu, 28 May 2020 at 00:21, Chris Myers <my...@ec...> wrote: > >> Actually, do you mind sending a screenshot of the Title/Authors, so I can >> update my CV. >> >> Thanks, >> Chris >> >> > On May 27, 2020, at 5:19 PM, Chris Myers <my...@ec...> wrote: >> > >> > Hi, >> > >> > I did not see it, but I trust you :-) >> > >> > Thanks, >> > Chris >> > >> >> On May 27, 2020, at 4:18 PM, Lucian Smith <luc...@gm...> >> wrote: >> >> >> >> Hey, everyone--I just got the proof for the JIB publication of the >> SBML Distrib package. I've added everyone's orcid (except I don't have >> Maceij's--Maceij, do you have your orcid?), and capitalized 'Systems >> Biology Markup Language', which they used instead of just 'SBML', which is >> fair. >> >> >> >> I was told that the co-authors also have access to it, and that they >> should transmit any corrections to me. The main thing I can see is that >> I'm the only email address in the system; if anyone wants their email >> address added, I can do that. >> >> >> >> Thanks again, everyone! >> >> >> >> -Lucian >> >> _______________________________________________ >> >> sbml-distrib mailing list >> >> sbm...@li... >> >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >> > >> > >> > >> > _______________________________________________ >> > sbml-distrib mailing list >> > sbm...@li... >> > https://lists.sourceforge.net/lists/listinfo/sbml-distrib >> >> >> >> _______________________________________________ >> sbml-distrib mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >> > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > |
|
From: Maciek J. S. <mac...@gm...> - 2020-05-28 09:20:35
|
hi Lucian, I don't have orcid. Best, MACIEJ On Thu, 28 May 2020 at 00:21, Chris Myers <my...@ec...> wrote: > Actually, do you mind sending a screenshot of the Title/Authors, so I can > update my CV. > > Thanks, > Chris > > > On May 27, 2020, at 5:19 PM, Chris Myers <my...@ec...> wrote: > > > > Hi, > > > > I did not see it, but I trust you :-) > > > > Thanks, > > Chris > > > >> On May 27, 2020, at 4:18 PM, Lucian Smith <luc...@gm...> > wrote: > >> > >> Hey, everyone--I just got the proof for the JIB publication of the SBML > Distrib package. I've added everyone's orcid (except I don't have > Maceij's--Maceij, do you have your orcid?), and capitalized 'Systems > Biology Markup Language', which they used instead of just 'SBML', which is > fair. > >> > >> I was told that the co-authors also have access to it, and that they > should transmit any corrections to me. The main thing I can see is that > I'm the only email address in the system; if anyone wants their email > address added, I can do that. > >> > >> Thanks again, everyone! > >> > >> -Lucian > >> _______________________________________________ > >> sbml-distrib mailing list > >> sbm...@li... > >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib > > > > > > > > _______________________________________________ > > sbml-distrib mailing list > > sbm...@li... > > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > > > > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > |
|
From: Chris M. <my...@ec...> - 2020-05-27 23:21:18
|
Actually, do you mind sending a screenshot of the Title/Authors, so I can update my CV. Thanks, Chris > On May 27, 2020, at 5:19 PM, Chris Myers <my...@ec...> wrote: > > Hi, > > I did not see it, but I trust you :-) > > Thanks, > Chris > >> On May 27, 2020, at 4:18 PM, Lucian Smith <luc...@gm...> wrote: >> >> Hey, everyone--I just got the proof for the JIB publication of the SBML Distrib package. I've added everyone's orcid (except I don't have Maceij's--Maceij, do you have your orcid?), and capitalized 'Systems Biology Markup Language', which they used instead of just 'SBML', which is fair. >> >> I was told that the co-authors also have access to it, and that they should transmit any corrections to me. The main thing I can see is that I'm the only email address in the system; if anyone wants their email address added, I can do that. >> >> Thanks again, everyone! >> >> -Lucian >> _______________________________________________ >> sbml-distrib mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib > > > > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib |
|
From: Chris M. <my...@ec...> - 2020-05-27 23:19:45
|
Hi, I did not see it, but I trust you :-) Thanks, Chris > On May 27, 2020, at 4:18 PM, Lucian Smith <luc...@gm...> wrote: > > Hey, everyone--I just got the proof for the JIB publication of the SBML Distrib package. I've added everyone's orcid (except I don't have Maceij's--Maceij, do you have your orcid?), and capitalized 'Systems Biology Markup Language', which they used instead of just 'SBML', which is fair. > > I was told that the co-authors also have access to it, and that they should transmit any corrections to me. The main thing I can see is that I'm the only email address in the system; if anyone wants their email address added, I can do that. > > Thanks again, everyone! > > -Lucian > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib |
|
From: Lucian S. <luc...@gm...> - 2020-05-27 22:19:17
|
Hey, everyone--I just got the proof for the JIB publication of the SBML Distrib package. I've added everyone's orcid (except I don't have Maceij's--Maceij, do you have your orcid?), and capitalized 'Systems Biology Markup Language', which they used instead of just 'SBML', which is fair. I was told that the co-authors also have access to it, and that they should transmit any corrections to me. The main thing I can see is that I'm the only email address in the system; if anyone wants their email address added, I can do that. Thanks again, everyone! -Lucian |
|
From: Chris M. <my...@ec...> - 2020-04-30 16:02:51
|
standards might be good to add too and maybe systems biology and modeling Chris > On Apr 30, 2020, at 9:53 AM, Matthias König via sbml-distrib <sbm...@li...> wrote: > > Keywords: distribution, uncertainty, SBML, package > > Best Matthias > > On Thu, Apr 30, 2020, 15:32 Lucian Smith <luc...@gm... <mailto:luc...@gm...>> wrote: > JIB wants 3-5 keywords for the distrib spec. Any suggestions? > > https://docs.google.com/document/d/15M0_2_DBet2zE-hNVE2wreguA9Hl2cDqXy5J3OP8ii0/edit?usp=sharing <https://docs.google.com/document/d/15M0_2_DBet2zE-hNVE2wreguA9Hl2cDqXy5J3OP8ii0/edit?usp=sharing> > > -Lucian > > ---------- Forwarded message --------- > From: Journal of Integrative Bioinformatics (JIB) <onb...@ma... <mailto:onb...@ma...>> > Date: Thu, Apr 30, 2020 at 1:57 AM > Subject: Journal of Integrative Bioinformatics > To: <lp...@uw... <mailto:lp...@uw...>> > > > 30-Apr-2020 > > JIB.2020.0018.R1 - SBML Level 3 Package: Distributions, Version 1, Release 1 > > Dear Dr. Smith: > > Please supply 3-5 keywords for your manuscript via e-mail at your earliest convenience. > > Thank you! > > Kind regards > Ms. Alexandra Hinz > Journal of Integrative Bioinformatics > > For news highlights from this journal and other publications, see our new service Science Discoveries at http://sciencediscoveries.degruyter.com/ <http://sciencediscoveries.degruyter.com/> > _______________________________________________ > sbml-distrib mailing list > sbm...@li... <mailto:sbm...@li...> > https://lists.sourceforge.net/lists/listinfo/sbml-distrib <https://lists.sourceforge.net/lists/listinfo/sbml-distrib> > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib |
|
From: Matthias K. <kon...@go...> - 2020-04-30 15:53:50
|
Keywords: distribution, uncertainty, SBML, package Best Matthias On Thu, Apr 30, 2020, 15:32 Lucian Smith <luc...@gm...> wrote: > JIB wants 3-5 keywords for the distrib spec. Any suggestions? > > > https://docs.google.com/document/d/15M0_2_DBet2zE-hNVE2wreguA9Hl2cDqXy5J3OP8ii0/edit?usp=sharing > > -Lucian > > ---------- Forwarded message --------- > From: Journal of Integrative Bioinformatics (JIB) < > onb...@ma...> > Date: Thu, Apr 30, 2020 at 1:57 AM > Subject: Journal of Integrative Bioinformatics > To: <lp...@uw...> > > > 30-Apr-2020 > > JIB.2020.0018.R1 - SBML Level 3 Package: Distributions, Version 1, > Release 1 > > Dear Dr. Smith: > > Please supply 3-5 keywords for your manuscript via e-mail at your earliest > convenience. > > Thank you! > > Kind regards > Ms. Alexandra Hinz > Journal of Integrative Bioinformatics > > For news highlights from this journal and other publications, see our new > service Science Discoveries at http://sciencediscoveries.degruyter.com/ > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > |
|
From: Lucian S. <luc...@gm...> - 2020-04-30 13:32:25
|
JIB wants 3-5 keywords for the distrib spec. Any suggestions? https://docs.google.com/document/d/15M0_2_DBet2zE-hNVE2wreguA9Hl2cDqXy5J3OP8ii0/edit?usp=sharing -Lucian ---------- Forwarded message --------- From: Journal of Integrative Bioinformatics (JIB) < onb...@ma...> Date: Thu, Apr 30, 2020 at 1:57 AM Subject: Journal of Integrative Bioinformatics To: <lp...@uw...> 30-Apr-2020 JIB.2020.0018.R1 - SBML Level 3 Package: Distributions, Version 1, Release 1 Dear Dr. Smith: Please supply 3-5 keywords for your manuscript via e-mail at your earliest convenience. Thank you! Kind regards Ms. Alexandra Hinz Journal of Integrative Bioinformatics For news highlights from this journal and other publications, see our new service Science Discoveries at http://sciencediscoveries.degruyter.com/ |
|
From: Chris M. <my...@ec...> - 2020-04-21 00:21:28
|
Excellent! This one has sure been a long time coming :-) Thanks for staying on it. Chris > On Apr 20, 2020, at 2:33 PM, Maciek Jacek Swat <mac...@gm...> wrote: > > Great stuff indeed! Thanks for your hard work!! > > On Mon, 20 Apr 2020 at 21:29, Michael Hucka <mh...@li... <mailto:mh...@li...>> wrote: > Congratulations! Wooooooo! > > On 20 Apr 2020, at 9:27, Lucian Smith wrote: > > > The 'Distrib' specification was accepted in JIB. A couple changes went in, > > but nothing major (extra comma in author's list, and 'DRAFT' removed from > > background of title page). Thanks again, everyone! > > > > -Lucian > > > > ---------- Forwarded message --------- > > From: Journal of Integrative Bioinformatics (JIB) < > > onb...@ma... <mailto:onb...@ma...>> > > Date: Thu, Apr 16, 2020 at 7:41 PM > > Subject: JIB.2020.0018.R1 - Decision Accept > > To: <lp...@uw... <mailto:lp...@uw...>> > > > > > > 17-Apr-2020 > > > > Dear Dr. Smith: > > > > I would like to thank you for submitting your manuscript entitled "SBML > > Level 3 Package: Distributions, Version 1, Release 1" to Journal of > > Integrative Bioinformatics (JIB). Your manuscript has been reviewed, and it > > is a pleasure to accept it for publication in JIB. > > > > The JIB production office will contact you for proofreading in the near > > future. Your article will be published ahead of print as soon as possible, > > and in the printed edition at a later time. > > > > Thank you for your fine contribution. On behalf of the Editors of Journal > > of Integrative Bioinformatics we look forward to your continued > > contributions to the Journal. > > > > Kind regards > > Prof. Falk Schreiber > > Editor in Chief, Journal of Integrative Bioinformatics > > > > > > For news highlights from this journal and other publications, see our new > > service Science Discoveries at http://sciencediscoveries.degruyter.com/ <http://sciencediscoveries.degruyter.com/> > > _______________________________________________ > > sbml-distrib mailing list > > sbm...@li... <mailto:sbm...@li...> > > https://lists.sourceforge.net/lists/listinfo/sbml-distrib <https://lists.sourceforge.net/lists/listinfo/sbml-distrib> > > > _______________________________________________ > sbml-distrib mailing list > sbm...@li... <mailto:sbm...@li...> > https://lists.sourceforge.net/lists/listinfo/sbml-distrib <https://lists.sourceforge.net/lists/listinfo/sbml-distrib> > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib |
|
From: Maciek J. S. <mac...@gm...> - 2020-04-20 20:33:51
|
Great stuff indeed! Thanks for your hard work!! On Mon, 20 Apr 2020 at 21:29, Michael Hucka <mh...@li...> wrote: > Congratulations! Wooooooo! > > On 20 Apr 2020, at 9:27, Lucian Smith wrote: > > > The 'Distrib' specification was accepted in JIB. A couple changes went > in, > > but nothing major (extra comma in author's list, and 'DRAFT' removed from > > background of title page). Thanks again, everyone! > > > > -Lucian > > > > ---------- Forwarded message --------- > > From: Journal of Integrative Bioinformatics (JIB) < > > onb...@ma...> > > Date: Thu, Apr 16, 2020 at 7:41 PM > > Subject: JIB.2020.0018.R1 - Decision Accept > > To: <lp...@uw...> > > > > > > 17-Apr-2020 > > > > Dear Dr. Smith: > > > > I would like to thank you for submitting your manuscript entitled "SBML > > Level 3 Package: Distributions, Version 1, Release 1" to Journal of > > Integrative Bioinformatics (JIB). Your manuscript has been reviewed, and > it > > is a pleasure to accept it for publication in JIB. > > > > The JIB production office will contact you for proofreading in the near > > future. Your article will be published ahead of print as soon as > possible, > > and in the printed edition at a later time. > > > > Thank you for your fine contribution. On behalf of the Editors of Journal > > of Integrative Bioinformatics we look forward to your continued > > contributions to the Journal. > > > > Kind regards > > Prof. Falk Schreiber > > Editor in Chief, Journal of Integrative Bioinformatics > > > > > > For news highlights from this journal and other publications, see our new > > service Science Discoveries at http://sciencediscoveries.degruyter.com/ > > _______________________________________________ > > sbml-distrib mailing list > > sbm...@li... > > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > > > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > |
|
From: Michael H. <mh...@li...> - 2020-04-20 20:29:38
|
Congratulations! Wooooooo! On 20 Apr 2020, at 9:27, Lucian Smith wrote: > The 'Distrib' specification was accepted in JIB. A couple changes went in, > but nothing major (extra comma in author's list, and 'DRAFT' removed from > background of title page). Thanks again, everyone! > > -Lucian > > ---------- Forwarded message --------- > From: Journal of Integrative Bioinformatics (JIB) < > onb...@ma...> > Date: Thu, Apr 16, 2020 at 7:41 PM > Subject: JIB.2020.0018.R1 - Decision Accept > To: <lp...@uw...> > > > 17-Apr-2020 > > Dear Dr. Smith: > > I would like to thank you for submitting your manuscript entitled "SBML > Level 3 Package: Distributions, Version 1, Release 1" to Journal of > Integrative Bioinformatics (JIB). Your manuscript has been reviewed, and it > is a pleasure to accept it for publication in JIB. > > The JIB production office will contact you for proofreading in the near > future. Your article will be published ahead of print as soon as possible, > and in the printed edition at a later time. > > Thank you for your fine contribution. On behalf of the Editors of Journal > of Integrative Bioinformatics we look forward to your continued > contributions to the Journal. > > Kind regards > Prof. Falk Schreiber > Editor in Chief, Journal of Integrative Bioinformatics > > > For news highlights from this journal and other publications, see our new > service Science Discoveries at http://sciencediscoveries.degruyter.com/ > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib |
|
From: Lucian S. <luc...@gm...> - 2020-04-20 16:27:31
|
The 'Distrib' specification was accepted in JIB. A couple changes went in, but nothing major (extra comma in author's list, and 'DRAFT' removed from background of title page). Thanks again, everyone! -Lucian ---------- Forwarded message --------- From: Journal of Integrative Bioinformatics (JIB) < onb...@ma...> Date: Thu, Apr 16, 2020 at 7:41 PM Subject: JIB.2020.0018.R1 - Decision Accept To: <lp...@uw...> 17-Apr-2020 Dear Dr. Smith: I would like to thank you for submitting your manuscript entitled "SBML Level 3 Package: Distributions, Version 1, Release 1" to Journal of Integrative Bioinformatics (JIB). Your manuscript has been reviewed, and it is a pleasure to accept it for publication in JIB. The JIB production office will contact you for proofreading in the near future. Your article will be published ahead of print as soon as possible, and in the printed edition at a later time. Thank you for your fine contribution. On behalf of the Editors of Journal of Integrative Bioinformatics we look forward to your continued contributions to the Journal. Kind regards Prof. Falk Schreiber Editor in Chief, Journal of Integrative Bioinformatics For news highlights from this journal and other publications, see our new service Science Discoveries at http://sciencediscoveries.degruyter.com/ |
|
From: Frank T. B. <fbe...@ca...> - 2020-04-06 13:20:08
|
Just to chime in ... i'm happy with the distrib spec as it is right now. While I agree that the ExternalParameter construct is problematic, I don't think it needs to hold the release. If we start now changing the specification again, we will be tinkering with it for months to come. So I'd rather get it out as it is now. Cheers Frank On Sun, Apr 5, 2020 at 12:16 PM Matthias König via sbml-distrib < sbm...@li...> wrote: > Hi Lucian et al, > > Conversely, is there really no way to encode a value and units as >> annotations? >> > > There is not clear and easy way in the form of RDF annotations. The > problems are mainly: 1. what unit annotation to use; 2. how to encode > numerical values; 3. how to combine the information in combined > annotations. Nobody is doing this, will not be exchangeable and too > complicated. > A second solution could be the new fbc-3 key-value pairs (but > unfortunately these don't have units! as I just am realizing while writing > this). One could store quantities, i.e. (magnitude, units) pairs as values > which could work and would be easy to parse and understand. But currently > there is no support in libsbml, so not useable at the moment. > It would not be too difficult to come up with a custom annotation block to > store such information, but this will not be exchangeable with other tools. > > I think the complicated use cases with complex externalParameters with > multiple ExternalParameter children will not occur a lot, but it allows to > encode even complex use cases. > I am very happy with keeping things like they are right now which allows > to do the common things very easily, but has the full power to handle > complex Uncertainty cases. Example given one could encode custom > histograms/density functions from data using a set of ExternalParameters > encoding the bins of the histogram (which would be the use case Brett > mentioned). > > I'm a little skeptical that replacing a single definitionURL string is >> worse than adding a whole RDF bag. But I'm not a huge annotation user; >> maybe it's easier to deal with than it seems? >> > > RDF is the devil, but what do you expect of the child of XML and a triple > store ;/. Much worse to deal with the RDF then a simple definitionURL. > It is much more difficult to deal with annotations then anybody makes you > believe (if we talk RDF annotations). Custom annotations are much simpler > to deal with, but nobody else will understand your information. > > It it is between getting rid of the ExternalParameter construct or keeping > it I am in clear favour of keeping it in the form it is! > > Best Matthias > > > > On Fri, Apr 3, 2020 at 7:27 PM Lucian Smith <luc...@gm...> > wrote: > >> The purpose of the nested external parameters was so that you could >> encode things like 'the zeta distribution, with a shape parameter of 2.37. >> The shape parameter is part of the zeta distribution, so it makes the most >> sense to make it a child. >> >> If that's not something people care about encoding, we can drop it with >> everything else, but that was the goal. >> >> There are more complicated scenarios, too, like 'a distribution that's a >> weighted combination of two normal distributions', which, to encode, need >> nesting even more. That would be more easily encoded as: >> >> * A weighted combination of distributions >> * Normal distribution #1 >> * mean = 5 >> * stdev = 1.2 >> * weight = 0.75 >> * Normal distribution #2 >> * mean = -2 >> * stdev = 3 >> * weight = 0.25 >> >> I'm a little skeptical that replacing a single definitionURL string is >> worse than adding a whole RDF bag. But I'm not a huge annotation user; >> maybe it's easier to deal with than it seems? >> >> Conversely, is there really no way to encode a value and units as >> annotations? >> >> -Lucian >> >> On Fri, Apr 3, 2020 at 2:00 AM Matthias König via sbml-distrib < >> sbm...@li...> wrote: >> >>> Hi all, >>> I am okay with getting rid of the definitionURL which is basically an >>> annotation and should be an annotation. >>> But we need a generic uncertainty parameter which allows to encode the >>> value and units in a standard way. I would propose to get rid of the >>> definitionURL and instead clearly state that the meaning of the >>> externalParameter type UncertParameter or UncertSpan should be specified >>> based on annotations. >>> This would: >>> 1. make it easy to store values and units and parse them with libsbml >>> instead of replicating the functionality for an annotation which would have >>> the same xml structure (i.e. one would get and encode the values and spans >>> the same like the core spans and parameters) >>> 2. clearly separate annotations from the XML (which is what was the >>> problem in the current externalParameter which mixes annotations in the >>> definitionURL) >>> 3. we could get rid of the listOfUfUncerParameters on UncertParameter >>> which is confusing and overkill. This would simplify things for the >>> uncertainties. >>> >>> I.e. the example on page 24 should be something like the following, with >>> possible additional information like the 0.99 value encoded in annotations. >>> <parameter id="p1" value="3.42" constant="true"> >>> <distrib:listOfUncertainties> >>> <distrib:uncertainty> >>> <distrib:uncertSpan type="externalParameter" lowerValue="3.19" >>> upperValue="3.83"> >>> <annotation> >>> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/> >>> <rdf:Description rdf:about="#meta_ext"> >>> <bqbiol:is> >>> <rdf:Bag> >>> <rdf:li rdf:resource="http://dist.org/CI"/> >>> ... >>> </rdf:Bag> >>> </bqbiol:is> >>> </rdf:Description> >>> </rdf:RDF> >>> </annotation> >>> >>> </distrib:uncertSpan> >>> </distrib:uncertainty> >>> </distrib:listOfUncertainties> >>> </parameter> >>> >>> So I am strongly for >>> - dropping "definitionURL" and use annotations instead >>> - dropping the listOfUncertParameters on UncertParameter. Such >>> information should be moved to annotation if necessary. >>> - keeping type "externalParameter" for UncertSpan and UncertParameter to >>> easily encode values and ranges of undefined types with their meaning >>> specified based on annotations >>> >>> Best Matthias >>> >>> >>> On Thu, Apr 2, 2020 at 10:59 PM Lucian Smith <luc...@gm...> >>> wrote: >>> >>>> So, both of the uninvolved-in-writing-the-spec SBML editors (Rahuman >>>> and Brett) suggested that the place for arbitrary annotations is really in >>>> classic annotation blocks. As such, they didn't see a huge benefit of >>>> having the ExternalParameter objects, suggesting that those be simply >>>> dropped from distrib entirely, leaving people who want to encode that >>>> information to encode them as normal annotations instead. >>>> >>>> The idea definitely has merit: what do the rest of you think? >>>> >>>> (Neither editor said this was a blocking issue for distrib acceptance, >>>> but that it should be thought about for future versions. Though if there's >>>> rapid consensus on the issue, it might be feasible to get this in as a >>>> last-minute edit? Probably not, though.) >>>> >>>> -Lucian >>>> _______________________________________________ >>>> sbml-distrib mailing list >>>> sbm...@li... >>>> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>>> >>> >>> >>> -- >>> Matthias König, PhD. >>> Junior Group Leader LiSyM - Systems Medicine of the Liver >>> Humboldt Universität zu Berlin, Institute of Biology, Institute for >>> Theoretical Biology >>> https://livermetabolism.com >>> kon...@go... >>> https://twitter.com/konigmatt >>> https://github.com/matthiaskoenig >>> Tel: +49 30 2093 98435 >>> _______________________________________________ >>> sbml-distrib mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>> >> _______________________________________________ >> sbml-distrib mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >> > > > -- > Matthias König, PhD. > Junior Group Leader LiSyM - Systems Medicine of the Liver > Humboldt Universität zu Berlin, Institute of Biology, Institute for > Theoretical Biology > https://livermetabolism.com > kon...@go... > https://twitter.com/konigmatt > https://github.com/matthiaskoenig > Tel: +49 30 2093 98435 > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > |
|
From: Michael H. <mh...@li...> - 2020-04-05 21:16:31
|
Hi Matthias, This is great! I wanted to address a past request (about a million years ago) and add sbmlutils to the list of converters on sbml.org. I'm working on the new sbml.org and have a new converters page, and was wondering if there is a publication to cite for sbmlutils. If there is one, can you let me know what it is? MH On 26 Mar 2020, at 17:20, 'Matthias König' via sbml-editors wrote: > Dear all, > I just made a release for sbmlutils with the distrib features > https://github.com/matthiaskoenig/sbmlutils > https://github.com/matthiaskoenig/sbmlutils/releases/tag/v0.3.9 > > sbmlutils allows to create SBML models with distrib and uncertainty > information. > Usage examples and documentation of how to use distrib with sbmlutils > can > be found here > https://sbmlutils.readthedocs.io/en/latest/notebooks/sbml_distrib.html# > This also includes the specification examples. > > Best Matthias > > On Thu, Mar 26, 2020 at 11:21 PM Lucian Smith > <luc...@gm...> > wrote: > >> The 'Distributions' package working group is happy to submit a >> release >> candidate of the 'Distributions' package for your approval! >> >> >> https://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/distrib/sbml-level-3-distrib-package-proposal.pdf >> >> >> A letter describing how this package complies with the principles >> required >> for all SBML packages is available at >> >> >> https://docs.google.com/document/d/1LGtJ6OOSCEALWPLWGGCGHYqeFv_BIZzc1ReDw0x1sos/edit >> >> >> We typically give you at least two weeks to read, approve, and >> solicit >> external opinions on these specs, but *if* it is possible, it would >> be nice >> to get this finalized in time for the upcoming JIB issue. The >> 'somewhat >> flexible' deadline for that is April 1st. >> >> Again, if this timeline turns out to be impossible, that's perfectly >> fine: we'll release it whenever everything finishes, and include it >> in >> next year's JIB instead. >> >> Thank you all! >> >> -Lucian Smith, for the 'distrib' package working group. >> >> -- >> You received this message because you are subscribed to the Google >> Groups >> "sbml-editors" group. >> To unsubscribe from this group and stop receiving emails from it, >> send an >> email to sbm...@go.... >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/sbml-editors/CAHLmBr2X96xy8x2rTjQBvzXx9V51_rhM_mpPg7Koad-UaGhmzQ%40mail.gmail.com >> <https://groups.google.com/d/msgid/sbml-editors/CAHLmBr2X96xy8x2rTjQBvzXx9V51_rhM_mpPg7Koad-UaGhmzQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > > > -- > Matthias König, PhD. > Junior Group Leader LiSyM - Systems Medicine of the Liver > Humboldt Universität zu Berlin, Institute of Biology, Institute for > Theoretical Biology > https://livermetabolism.com > kon...@go... > https://twitter.com/konigmatt > https://github.com/matthiaskoenig > Tel: +49 30 2093 98435 > > -- > You received this message because you are subscribed to the Google > Groups "sbml-editors" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to sbm...@go.... > To view this discussion on the web visit > https://groups.google.com/d/msgid/sbml-editors/CAEUx3ETx90Ob7am9M%3Dd7kTTEp7pLkBLd2zygiiZuMdxTcGDh9A%40mail.gmail.com. |
|
From: Matthias K. <kon...@go...> - 2020-04-05 10:16:30
|
Hi Lucian et al, Conversely, is there really no way to encode a value and units as > annotations? > There is not clear and easy way in the form of RDF annotations. The problems are mainly: 1. what unit annotation to use; 2. how to encode numerical values; 3. how to combine the information in combined annotations. Nobody is doing this, will not be exchangeable and too complicated. A second solution could be the new fbc-3 key-value pairs (but unfortunately these don't have units! as I just am realizing while writing this). One could store quantities, i.e. (magnitude, units) pairs as values which could work and would be easy to parse and understand. But currently there is no support in libsbml, so not useable at the moment. It would not be too difficult to come up with a custom annotation block to store such information, but this will not be exchangeable with other tools. I think the complicated use cases with complex externalParameters with multiple ExternalParameter children will not occur a lot, but it allows to encode even complex use cases. I am very happy with keeping things like they are right now which allows to do the common things very easily, but has the full power to handle complex Uncertainty cases. Example given one could encode custom histograms/density functions from data using a set of ExternalParameters encoding the bins of the histogram (which would be the use case Brett mentioned). I'm a little skeptical that replacing a single definitionURL string is > worse than adding a whole RDF bag. But I'm not a huge annotation user; > maybe it's easier to deal with than it seems? > RDF is the devil, but what do you expect of the child of XML and a triple store ;/. Much worse to deal with the RDF then a simple definitionURL. It is much more difficult to deal with annotations then anybody makes you believe (if we talk RDF annotations). Custom annotations are much simpler to deal with, but nobody else will understand your information. It it is between getting rid of the ExternalParameter construct or keeping it I am in clear favour of keeping it in the form it is! Best Matthias On Fri, Apr 3, 2020 at 7:27 PM Lucian Smith <luc...@gm...> wrote: > The purpose of the nested external parameters was so that you could encode > things like 'the zeta distribution, with a shape parameter of 2.37. The > shape parameter is part of the zeta distribution, so it makes the most > sense to make it a child. > > If that's not something people care about encoding, we can drop it with > everything else, but that was the goal. > > There are more complicated scenarios, too, like 'a distribution that's a > weighted combination of two normal distributions', which, to encode, need > nesting even more. That would be more easily encoded as: > > * A weighted combination of distributions > * Normal distribution #1 > * mean = 5 > * stdev = 1.2 > * weight = 0.75 > * Normal distribution #2 > * mean = -2 > * stdev = 3 > * weight = 0.25 > > I'm a little skeptical that replacing a single definitionURL string is > worse than adding a whole RDF bag. But I'm not a huge annotation user; > maybe it's easier to deal with than it seems? > > Conversely, is there really no way to encode a value and units as > annotations? > > -Lucian > > On Fri, Apr 3, 2020 at 2:00 AM Matthias König via sbml-distrib < > sbm...@li...> wrote: > >> Hi all, >> I am okay with getting rid of the definitionURL which is basically an >> annotation and should be an annotation. >> But we need a generic uncertainty parameter which allows to encode the >> value and units in a standard way. I would propose to get rid of the >> definitionURL and instead clearly state that the meaning of the >> externalParameter type UncertParameter or UncertSpan should be specified >> based on annotations. >> This would: >> 1. make it easy to store values and units and parse them with libsbml >> instead of replicating the functionality for an annotation which would have >> the same xml structure (i.e. one would get and encode the values and spans >> the same like the core spans and parameters) >> 2. clearly separate annotations from the XML (which is what was the >> problem in the current externalParameter which mixes annotations in the >> definitionURL) >> 3. we could get rid of the listOfUfUncerParameters on UncertParameter >> which is confusing and overkill. This would simplify things for the >> uncertainties. >> >> I.e. the example on page 24 should be something like the following, with >> possible additional information like the 0.99 value encoded in annotations. >> <parameter id="p1" value="3.42" constant="true"> >> <distrib:listOfUncertainties> >> <distrib:uncertainty> >> <distrib:uncertSpan type="externalParameter" lowerValue="3.19" >> upperValue="3.83"> >> <annotation> >> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/> >> <rdf:Description rdf:about="#meta_ext"> >> <bqbiol:is> >> <rdf:Bag> >> <rdf:li rdf:resource="http://dist.org/CI"/> >> ... >> </rdf:Bag> >> </bqbiol:is> >> </rdf:Description> >> </rdf:RDF> >> </annotation> >> >> </distrib:uncertSpan> >> </distrib:uncertainty> >> </distrib:listOfUncertainties> >> </parameter> >> >> So I am strongly for >> - dropping "definitionURL" and use annotations instead >> - dropping the listOfUncertParameters on UncertParameter. Such >> information should be moved to annotation if necessary. >> - keeping type "externalParameter" for UncertSpan and UncertParameter to >> easily encode values and ranges of undefined types with their meaning >> specified based on annotations >> >> Best Matthias >> >> >> On Thu, Apr 2, 2020 at 10:59 PM Lucian Smith <luc...@gm...> >> wrote: >> >>> So, both of the uninvolved-in-writing-the-spec SBML editors (Rahuman and >>> Brett) suggested that the place for arbitrary annotations is really in >>> classic annotation blocks. As such, they didn't see a huge benefit of >>> having the ExternalParameter objects, suggesting that those be simply >>> dropped from distrib entirely, leaving people who want to encode that >>> information to encode them as normal annotations instead. >>> >>> The idea definitely has merit: what do the rest of you think? >>> >>> (Neither editor said this was a blocking issue for distrib acceptance, >>> but that it should be thought about for future versions. Though if there's >>> rapid consensus on the issue, it might be feasible to get this in as a >>> last-minute edit? Probably not, though.) >>> >>> -Lucian >>> _______________________________________________ >>> sbml-distrib mailing list >>> sbm...@li... >>> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >>> >> >> >> -- >> Matthias König, PhD. >> Junior Group Leader LiSyM - Systems Medicine of the Liver >> Humboldt Universität zu Berlin, Institute of Biology, Institute for >> Theoretical Biology >> https://livermetabolism.com >> kon...@go... >> https://twitter.com/konigmatt >> https://github.com/matthiaskoenig >> Tel: +49 30 2093 98435 >> _______________________________________________ >> sbml-distrib mailing list >> sbm...@li... >> https://lists.sourceforge.net/lists/listinfo/sbml-distrib >> > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib > -- Matthias König, PhD. Junior Group Leader LiSyM - Systems Medicine of the Liver Humboldt Universität zu Berlin, Institute of Biology, Institute for Theoretical Biology https://livermetabolism.com kon...@go... https://twitter.com/konigmatt https://github.com/matthiaskoenig Tel: +49 30 2093 98435 |
|
From: Lucian S. <luc...@gm...> - 2020-04-03 17:27:44
|
The purpose of the nested external parameters was so that you could encode
things like 'the zeta distribution, with a shape parameter of 2.37. The
shape parameter is part of the zeta distribution, so it makes the most
sense to make it a child.
If that's not something people care about encoding, we can drop it with
everything else, but that was the goal.
There are more complicated scenarios, too, like 'a distribution that's a
weighted combination of two normal distributions', which, to encode, need
nesting even more. That would be more easily encoded as:
* A weighted combination of distributions
* Normal distribution #1
* mean = 5
* stdev = 1.2
* weight = 0.75
* Normal distribution #2
* mean = -2
* stdev = 3
* weight = 0.25
I'm a little skeptical that replacing a single definitionURL string is
worse than adding a whole RDF bag. But I'm not a huge annotation user;
maybe it's easier to deal with than it seems?
Conversely, is there really no way to encode a value and units as
annotations?
-Lucian
On Fri, Apr 3, 2020 at 2:00 AM Matthias König via sbml-distrib <
sbm...@li...> wrote:
> Hi all,
> I am okay with getting rid of the definitionURL which is basically an
> annotation and should be an annotation.
> But we need a generic uncertainty parameter which allows to encode the
> value and units in a standard way. I would propose to get rid of the
> definitionURL and instead clearly state that the meaning of the
> externalParameter type UncertParameter or UncertSpan should be specified
> based on annotations.
> This would:
> 1. make it easy to store values and units and parse them with libsbml
> instead of replicating the functionality for an annotation which would have
> the same xml structure (i.e. one would get and encode the values and spans
> the same like the core spans and parameters)
> 2. clearly separate annotations from the XML (which is what was the
> problem in the current externalParameter which mixes annotations in the
> definitionURL)
> 3. we could get rid of the listOfUfUncerParameters on UncertParameter
> which is confusing and overkill. This would simplify things for the
> uncertainties.
>
> I.e. the example on page 24 should be something like the following, with
> possible additional information like the 0.99 value encoded in annotations.
> <parameter id="p1" value="3.42" constant="true">
> <distrib:listOfUncertainties>
> <distrib:uncertainty>
> <distrib:uncertSpan type="externalParameter" lowerValue="3.19"
> upperValue="3.83">
> <annotation>
> <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/>
> <rdf:Description rdf:about="#meta_ext">
> <bqbiol:is>
> <rdf:Bag>
> <rdf:li rdf:resource="http://dist.org/CI"/>
> ...
> </rdf:Bag>
> </bqbiol:is>
> </rdf:Description>
> </rdf:RDF>
> </annotation>
>
> </distrib:uncertSpan>
> </distrib:uncertainty>
> </distrib:listOfUncertainties>
> </parameter>
>
> So I am strongly for
> - dropping "definitionURL" and use annotations instead
> - dropping the listOfUncertParameters on UncertParameter. Such information
> should be moved to annotation if necessary.
> - keeping type "externalParameter" for UncertSpan and UncertParameter to
> easily encode values and ranges of undefined types with their meaning
> specified based on annotations
>
> Best Matthias
>
>
> On Thu, Apr 2, 2020 at 10:59 PM Lucian Smith <luc...@gm...>
> wrote:
>
>> So, both of the uninvolved-in-writing-the-spec SBML editors (Rahuman and
>> Brett) suggested that the place for arbitrary annotations is really in
>> classic annotation blocks. As such, they didn't see a huge benefit of
>> having the ExternalParameter objects, suggesting that those be simply
>> dropped from distrib entirely, leaving people who want to encode that
>> information to encode them as normal annotations instead.
>>
>> The idea definitely has merit: what do the rest of you think?
>>
>> (Neither editor said this was a blocking issue for distrib acceptance,
>> but that it should be thought about for future versions. Though if there's
>> rapid consensus on the issue, it might be feasible to get this in as a
>> last-minute edit? Probably not, though.)
>>
>> -Lucian
>> _______________________________________________
>> sbml-distrib mailing list
>> sbm...@li...
>> https://lists.sourceforge.net/lists/listinfo/sbml-distrib
>>
>
>
> --
> Matthias König, PhD.
> Junior Group Leader LiSyM - Systems Medicine of the Liver
> Humboldt Universität zu Berlin, Institute of Biology, Institute for
> Theoretical Biology
> https://livermetabolism.com
> kon...@go...
> https://twitter.com/konigmatt
> https://github.com/matthiaskoenig
> Tel: +49 30 2093 98435
> _______________________________________________
> sbml-distrib mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-distrib
>
|
|
From: Matthias K. <kon...@go...> - 2020-04-03 09:00:01
|
Hi all,
I am okay with getting rid of the definitionURL which is basically an
annotation and should be an annotation.
But we need a generic uncertainty parameter which allows to encode the
value and units in a standard way. I would propose to get rid of the
definitionURL and instead clearly state that the meaning of the
externalParameter type UncertParameter or UncertSpan should be specified
based on annotations.
This would:
1. make it easy to store values and units and parse them with libsbml
instead of replicating the functionality for an annotation which would have
the same xml structure (i.e. one would get and encode the values and spans
the same like the core spans and parameters)
2. clearly separate annotations from the XML (which is what was the problem
in the current externalParameter which mixes annotations in the
definitionURL)
3. we could get rid of the listOfUfUncerParameters on UncertParameter which
is confusing and overkill. This would simplify things for the uncertainties.
I.e. the example on page 24 should be something like the following, with
possible additional information like the 0.99 value encoded in annotations.
<parameter id="p1" value="3.42" constant="true">
<distrib:listOfUncertainties>
<distrib:uncertainty>
<distrib:uncertSpan type="externalParameter" lowerValue="3.19"
upperValue="3.83">
<annotation>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"/>
<rdf:Description rdf:about="#meta_ext">
<bqbiol:is>
<rdf:Bag>
<rdf:li rdf:resource="http://dist.org/CI"/>
...
</rdf:Bag>
</bqbiol:is>
</rdf:Description>
</rdf:RDF>
</annotation>
</distrib:uncertSpan>
</distrib:uncertainty>
</distrib:listOfUncertainties>
</parameter>
So I am strongly for
- dropping "definitionURL" and use annotations instead
- dropping the listOfUncertParameters on UncertParameter. Such information
should be moved to annotation if necessary.
- keeping type "externalParameter" for UncertSpan and UncertParameter to
easily encode values and ranges of undefined types with their meaning
specified based on annotations
Best Matthias
On Thu, Apr 2, 2020 at 10:59 PM Lucian Smith <luc...@gm...>
wrote:
> So, both of the uninvolved-in-writing-the-spec SBML editors (Rahuman and
> Brett) suggested that the place for arbitrary annotations is really in
> classic annotation blocks. As such, they didn't see a huge benefit of
> having the ExternalParameter objects, suggesting that those be simply
> dropped from distrib entirely, leaving people who want to encode that
> information to encode them as normal annotations instead.
>
> The idea definitely has merit: what do the rest of you think?
>
> (Neither editor said this was a blocking issue for distrib acceptance, but
> that it should be thought about for future versions. Though if there's
> rapid consensus on the issue, it might be feasible to get this in as a
> last-minute edit? Probably not, though.)
>
> -Lucian
> _______________________________________________
> sbml-distrib mailing list
> sbm...@li...
> https://lists.sourceforge.net/lists/listinfo/sbml-distrib
>
--
Matthias König, PhD.
Junior Group Leader LiSyM - Systems Medicine of the Liver
Humboldt Universität zu Berlin, Institute of Biology, Institute for
Theoretical Biology
https://livermetabolism.com
kon...@go...
https://twitter.com/konigmatt
https://github.com/matthiaskoenig
Tel: +49 30 2093 98435
|
|
From: Chris M. <my...@ec...> - 2020-04-02 23:31:16
|
"I could imagine coordinating with the Arrays package to make this happen:” Yep, you owe me arrays in Antimony now that I did distrib :-) Cheers, Chris > On Apr 2, 2020, at 3:17 PM, Lucian Smith <luc...@gm...> wrote: > > Thank you both so much! I've addressed the points I could in the text; the final version is now at > > http://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/distrib/sbml-level-3-distrib-package-proposal.pdf?format=raw <http://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/distrib/sbml-level-3-distrib-package-proposal.pdf?format=raw> > > To reply to your specific points: > > On Wed, Apr 1, 2020 at 5:02 PM Rahuman Sheriff <sh...@eb... <mailto:sh...@eb...>> wrote: > * One of the authors of the specification is affiliated to a private company. Should there be a conflict of interest statement ? You remember the MSB discussion. I don’t know if it applies for the format specification too ? > > I don't think we need to worry for specs themselves, but I'll check on the JIB submission, where there might be. (Although 'Eight Pillars Ltd' is Stuart's name for himself as an independent consultant.) > > * I share the same opinion as Bertt, it would have been better to keep the "external definitions” which cannot be simulated, encoded as annotations. > Hopefully you can consider this for the future release, so that all annotations can be handled by combine-annot tools. > > This is an idea I hadn't considered before--I'll bring it up with the list! > > * With increasing single-cell omics research / data, it might become useful to draw a value from a probability distribution of expression of a protein across single cell population for modelling. I hope you will consider to include sampling from probability density function for the next release. > > Do you mean an experimentally-defined probability density function? That does indeed sound useful. I could imagine coordinating with the Arrays package to make this happen: you define an array with the nth percentile for each index, then pick an index at random using a uniform. I don't know if that'll be the best moving forward, but finding something definitely seems worth it. > > * The definitionURL (e.g. http://www.sbml.org/sbml/symbols/distrib/normal <http://www.sbml.org/sbml/symbols/distrib/normal>) are resolved to an empty page with just value. I suppose this is the common practise. Would have been nice if cross-linked to the right ontology term. > > This is a good point--I'll work with Mike in the upcoming weeks to get pages up at those sites (like we already have for the other core csymbols). (Since sbml.org <http://sbml.org/> itself is undergoing a site redesign, this may have to wait until after that happens, but it's on the list.) > > * In the section 3.9, the extended SBase class, it would be useful to show an example the usage of distrib along with the qual Package. > > Putting in a qual example is a good idea: I've added one to the 'Interactions with other packages' section (the new 4.4 bit). > > * Are the http://dist.org/something <http://dist.org/something> used as place holders or are there plans to create them ? > > There were no plans to create them; they were supposed to be obviously-nonfunctional URLs. I've adjusted the text slightly in those sections to make this clearer. > > * This is not an issue at all; the entire document is in US english, except few words (e.g. acknowledgement ) which are in British english. > > Good catch! I've fixed this one, and am happy to fix others. This is probably a function of Stuart starting the document and me finishing it ;-) > > Also, from Brett: > Non-resolving URL's for annotation, while technically correct, in the age of identifiers.org <http://identifiers.org/> these are not exactly helpful > I agree--I'll contact the probonto people and see if they can update their system so that this works. > The Uncertainty or uncertParameter description should clearly state that it is purely an annotation and can not affect the model's numerical results (as discussed earlier in this thread) and can be ignored for simulation purposes. Another option would be to treat the whole DistribBase as any other annotation. > I've added the following paragraph to the 'Uncertainty' class definition: > > ------- > [...Each \Uncertainty child must be a unique set of statistical measures.] > > These statistical measures do not numerically affect simulation of the model. They are, in essence, a controlled annotation format specifically designed for this sort of information. Tools may use this information as they wish, just as they can with other annotation information. > ----- > > Again, sorry for the slow response. > > Oh my goodness; you've been much quicker than I feel I would have been able to be, under the circumstances. Huge thanks again to both you and Brett. > > -Lucian > _______________________________________________ > sbml-distrib mailing list > sbm...@li... > https://lists.sourceforge.net/lists/listinfo/sbml-distrib |
|
From: Lucian S. <luc...@gm...> - 2020-04-02 21:17:57
|
Thank you both so much! I've addressed the points I could in the text; the final version is now at http://sourceforge.net/p/sbml/code/HEAD/tree/trunk/specifications/sbml-level-3/version-1/distrib/sbml-level-3-distrib-package-proposal.pdf?format=raw To reply to your specific points: On Wed, Apr 1, 2020 at 5:02 PM Rahuman Sheriff <sh...@eb...> wrote: > * One of the authors of the specification is affiliated to a private > company. Should there be a conflict of interest statement ? You remember > the MSB discussion. I don’t know if it applies for the format specification > too ? > I don't think we need to worry for specs themselves, but I'll check on the JIB submission, where there might be. (Although 'Eight Pillars Ltd' is Stuart's name for himself as an independent consultant.) > * I share the same opinion as Bertt, it would have been better to keep the > "external definitions” which cannot be simulated, encoded as annotations. > Hopefully you can consider this for the future release, so that all > annotations can be handled by combine-annot tools. > This is an idea I hadn't considered before--I'll bring it up with the list! > * With increasing single-cell omics research / data, it might become > useful to draw a value from a probability distribution of expression of a > protein across single cell population for modelling. I hope you will > consider to include sampling from probability density function for the next > release. > Do you mean an experimentally-defined probability density function? That does indeed sound useful. I could imagine coordinating with the Arrays package to make this happen: you define an array with the nth percentile for each index, then pick an index at random using a uniform. I don't know if that'll be the best moving forward, but finding something definitely seems worth it. > * The definitionURL (e.g. http://www.sbml.org/sbml/symbols/distrib/normal) > are resolved to an empty page with just value. I suppose this is the common > practise. Would have been nice if cross-linked to the right ontology term. > This is a good point--I'll work with Mike in the upcoming weeks to get pages up at those sites (like we already have for the other core csymbols). (Since sbml.org itself is undergoing a site redesign, this may have to wait until after that happens, but it's on the list.) > * In the section 3.9, the extended SBase class, it would be useful to show > an example the usage of distrib along with the qual Package. > Putting in a qual example is a good idea: I've added one to the 'Interactions with other packages' section (the new 4.4 bit). > * Are the http://dist.org/something used as place holders or are there > plans to create them ? > There were no plans to create them; they were supposed to be obviously-nonfunctional URLs. I've adjusted the text slightly in those sections to make this clearer. > * This is not an issue at all; the entire document is in US english, > except few words (e.g. acknowledgement ) which are in British english. > Good catch! I've fixed this one, and am happy to fix others. This is probably a function of Stuart starting the document and me finishing it ;-) Also, from Brett: - Non-resolving URL's for annotation, while technically correct, in the age of identifiers.org these are not exactly helpful I agree--I'll contact the probonto people and see if they can update their system so that this works. - The Uncertainty or uncertParameter description should clearly state that it is purely an annotation and can not affect the model's numerical results (as discussed earlier in this thread) and can be ignored for simulation purposes. Another option would be to treat the whole DistribBase as any other annotation. I've added the following paragraph to the 'Uncertainty' class definition: ------- [...Each \Uncertainty child must be a unique set of statistical measures.] These statistical measures do not numerically affect simulation of the model. They are, in essence, a controlled annotation format specifically designed for this sort of information. Tools may use this information as they wish, just as they can with other annotation information. ----- Again, sorry for the slow response. > Oh my goodness; you've been much quicker than I feel I would have been able to be, under the circumstances. Huge thanks again to both you and Brett. -Lucian |
|
From: Lucian S. <luc...@gm...> - 2020-04-02 20:59:27
|
So, both of the uninvolved-in-writing-the-spec SBML editors (Rahuman and Brett) suggested that the place for arbitrary annotations is really in classic annotation blocks. As such, they didn't see a huge benefit of having the ExternalParameter objects, suggesting that those be simply dropped from distrib entirely, leaving people who want to encode that information to encode them as normal annotations instead. The idea definitely has merit: what do the rest of you think? (Neither editor said this was a blocking issue for distrib acceptance, but that it should be thought about for future versions. Though if there's rapid consensus on the issue, it might be feasible to get this in as a last-minute edit? Probably not, though.) -Lucian |
2 messages has been excluded from this view by a project administrator.
