Menu
▾
▴
sed-ml-discuss — Migrating to google groups: https://groups.google.com/d/forum/sed-ml-discuss
This list is closed, nobody may subscribe to it.
| 2008 |
Jan
(1) |
Feb
(35) |
Mar
(41) |
Apr
(4) |
May
(19) |
Jun
(26) |
Jul
(3) |
Aug
(2) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(3) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2009 |
Jan
(49) |
Feb
(15) |
Mar
(17) |
Apr
(7) |
May
(26) |
Jun
(1) |
Jul
(5) |
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(1) |
Mar
(29) |
Apr
(4) |
May
(31) |
Jun
(46) |
Jul
|
Aug
(5) |
Sep
(3) |
Oct
(2) |
Nov
(15) |
Dec
|
| 2011 |
Jan
(8) |
Feb
(1) |
Mar
(6) |
Apr
(10) |
May
(17) |
Jun
(23) |
Jul
(5) |
Aug
(3) |
Sep
(28) |
Oct
(41) |
Nov
(20) |
Dec
(1) |
| 2012 |
Jan
(20) |
Feb
(15) |
Mar
(1) |
Apr
(1) |
May
(8) |
Jun
(3) |
Jul
(9) |
Aug
(10) |
Sep
(1) |
Oct
(2) |
Nov
(5) |
Dec
(8) |
| 2013 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
(16) |
May
(13) |
Jun
(6) |
Jul
(1) |
Aug
(2) |
Sep
(3) |
Oct
(2) |
Nov
(6) |
Dec
(2) |
| 2014 |
Jan
(4) |
Feb
(5) |
Mar
(15) |
Apr
(16) |
May
|
Jun
(6) |
Jul
(3) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
(13) |
Dec
(8) |
| 2015 |
Jan
(7) |
Feb
|
Mar
(3) |
Apr
|
May
(6) |
Jun
(24) |
Jul
(3) |
Aug
(10) |
Sep
(36) |
Oct
(3) |
Nov
|
Dec
(39) |
| 2016 |
Jan
(9) |
Feb
(38) |
Mar
(25) |
Apr
(3) |
May
(12) |
Jun
(5) |
Jul
(40) |
Aug
(13) |
Sep
(4) |
Oct
|
Nov
|
Dec
(2) |
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
(29) |
Jun
(26) |
Jul
(12) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
|
From: Lucian S. <lp...@sp...> - 2010-06-08 18:06:33
|
Why would SED-ML provide a link to a schema? Doesn't it assume that you already know how to parse (and even simulate!) a file of the particular language? If you want to make sure you're linking to a particular version of a file, I think you want a checksum, not a level description. (Actually, since SEDML only deals with files at the XML level, it doesn't even need the language bit, except as a hint to the SEDML interpreter. The file itself should tell whoever tries to parse it what language it is.) Actually, that brings up an interesting point: can we add the language 'xml' to the list, for when we want to punt and let the simulator decide whether it knows how to parse/simulate a model? -Lucian * Nicolas Le novère <le...@eb...> [2010-06-08 18:36] writes: > The need is that different versions/levels can have different > elements/symbols/way of doing things. If we provide links to schemas, we > must differentiate between alternatives. Would-you always point to the > latest SBML definition, like L3V1, even if the file is an L2V4? > > On 08/06/10 18:26, Frank Bergmann wrote: > > I still don't see the need, but if others do that is fine with me. Why would > > I reject a model, just because now the resource is pointing to an SBML Level > > 3 document, when the SED-ML document was expecting an l2v4 one? > > > > Cheers > > Frank > > > >> -----Original Message----- > >> From: Nicolas Le novère [mailto:le...@eb...] > >> Sent: Tuesday, June 08, 2010 10:23 AM > >> To: sed...@li... > >> Subject: Re: [SED-ML-discuss] sed-ml language > >> > >> What about a system providing info for the ones who want it but allow for > >> fuzziness: > >> > >> urn:sedml:language:cellml:version-1.1 > >> urn:sedml:language:neuroml:version-1.8 > >> urn:sedml:language:sbml:level-2-version-4 > >> > >> ? > >> > >> On 08/06/10 18:11, Frank T. Bergmann wrote: > >>> Hello Dagmar, > >>> > >>> this is an interesting idea. However, I would prefer not to bring in > >>> the level / version of the model into SED-ML. For example, no matter > >>> what SBML model you are pointing to many software packages will be able > >> to support it. > >>> Moreover when you point at a model for example with a BioModel URN > >>> your version number can change under your hand. So how about we > >> simplify it to: > >>> > >>> urn:sedml:language:cellml > >>> urn:sedml:language:neuroml > >>> urn:sedml:language:sbml > >>> urn:sedml:language:vcml > >>> > >>> from then on we could easily get level and version information from > >>> the actual source file. > >>> > >>> Thanks > >>> Frank > >>> > >>>> -----Original Message----- > >>>> From: Dagmar Waltemath [mailto:dag...@un...] > >>>> Sent: Tuesday, June 08, 2010 9:28 AM > >>>> To: sed...@li... > >>>> Subject: [SED-ML-discuss] sed-ml language > >>>> > >>>> Hello... > >>>> > >>>> I was looking at the language references. > >>>> We decided to store the language of each model we use in the SED-ML > >>>> file. And we want to use a common urn scheme for that: > >>>> urn:sedml:language:X. > >>>> > >>>> We will have to specify the X for each language that we know thinks > >>>> about using SED-ML, so far I have CellML, NeuroML, SBML and VCML. > >>>> Same for the different versions of those languages. > >>>> > >>>> The information will be provided online. The idea is to provide > >>>> information on the language/version name, as well as a reference to > >>>> the according specification and format definition, and to the > >>>> citation that explains the format, if those things are existing. > >>>> > >>>> I attach a table with a number of languages and versions, and the > >>>> above mentioned information. > >>>> It would be great if you could > >>>> > >>>> 1) correct and complete the table > >>>> 2) let me know if you are aware of further languages/versions we > >>>> should include. > >>>> > >>>> Thanks. > >>>> Dagmar > >>> > >>> > >>> ---------------------------------------------------------------------- > >>> -------- ThinkGeek and WIRED's GeekDad team up for the Ultimate > >>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental > >>> unit. See the prize list and enter to win: > >>> http://p.sf.net/sfu/thinkgeek-promo > >>> _______________________________________________ > >>> SED-ML-discuss mailing list > >>> SED...@li... > >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > >> > >> > >> -- > >> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome- > >> Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, > >> Tel:+441223494521 > >> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(N > >> OT email) http://www.ebi.ac.uk/~lenov/, > >> http://www.ebi.ac.uk/compneur/, @lenovere > >> > >> > >> > >> > > ---------------------------------------------------------------------------- > > -- > >> ThinkGeek and WIRED's GeekDad team up for the Ultimate > >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > >> lucky parental unit. See the prize list and enter to win: > >> http://p.sf.net/sfu/thinkgeek-promo > >> _______________________________________________ > >> SED-ML-discuss mailing list > >> SED...@li... > >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > -- > Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust > Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 > Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email) > http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere > > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Frank B. <fbergman@u.washington.edu> - 2010-06-08 17:50:09
|
Preferably, I would like to keep the level / version stuff out of SED-ML at all ... it is such a pain to do things like ChangeXML in the first place ... having to potentially translate it to different levels/ versions seems daunting. Thats why when I use the feature, I will use the archive format to ensure its the right combo, and no one updates the model under my hand ... Still the symbols we can use are specified within the urn:sedml:symbol scheme, right? (Presumably on some accessible format somewhere akin to how we deal with the MIRIAM scheme right now). So I think this definition should be independent of level and versions of the model ... at least for now I don't see a reason I would want to define a symbol for one level / version combination that I would not like to use in another. Frank > -----Original Message----- > From: Nicolas Le novère [mailto:le...@eb...] > Sent: Tuesday, June 08, 2010 10:33 AM > To: Frank Bergmann > Cc: sed...@li... > Subject: Re: [SED-ML-discuss] sed-ml language > > The need is that different versions/levels can have different > elements/symbols/way of doing things. If we provide links to schemas, we > must differentiate between alternatives. Would-you always point to the > latest SBML definition, like L3V1, even if the file is an L2V4? > > On 08/06/10 18:26, Frank Bergmann wrote: > > I still don't see the need, but if others do that is fine with me. Why > > would I reject a model, just because now the resource is pointing to > > an SBML Level > > 3 document, when the SED-ML document was expecting an l2v4 one? > > > > Cheers > > Frank > > > >> -----Original Message----- > >> From: Nicolas Le novère [mailto:le...@eb...] > >> Sent: Tuesday, June 08, 2010 10:23 AM > >> To: sed...@li... > >> Subject: Re: [SED-ML-discuss] sed-ml language > >> > >> What about a system providing info for the ones who want it but allow > >> for > >> fuzziness: > >> > >> urn:sedml:language:cellml:version-1.1 > >> urn:sedml:language:neuroml:version-1.8 > >> urn:sedml:language:sbml:level-2-version-4 > >> > >> ? > >> > >> On 08/06/10 18:11, Frank T. Bergmann wrote: > >>> Hello Dagmar, > >>> > >>> this is an interesting idea. However, I would prefer not to bring in > >>> the level / version of the model into SED-ML. For example, no matter > >>> what SBML model you are pointing to many software packages will be > >>> able > >> to support it. > >>> Moreover when you point at a model for example with a BioModel URN > >>> your version number can change under your hand. So how about we > >> simplify it to: > >>> > >>> urn:sedml:language:cellml > >>> urn:sedml:language:neuroml > >>> urn:sedml:language:sbml > >>> urn:sedml:language:vcml > >>> > >>> from then on we could easily get level and version information from > >>> the actual source file. > >>> > >>> Thanks > >>> Frank > >>> > >>>> -----Original Message----- > >>>> From: Dagmar Waltemath [mailto:dag...@un...] > >>>> Sent: Tuesday, June 08, 2010 9:28 AM > >>>> To: sed...@li... > >>>> Subject: [SED-ML-discuss] sed-ml language > >>>> > >>>> Hello... > >>>> > >>>> I was looking at the language references. > >>>> We decided to store the language of each model we use in the SED-ML > >>>> file. And we want to use a common urn scheme for that: > >>>> urn:sedml:language:X. > >>>> > >>>> We will have to specify the X for each language that we know > >>>> thinks about using SED-ML, so far I have CellML, NeuroML, SBML and > VCML. > >>>> Same for the different versions of those languages. > >>>> > >>>> The information will be provided online. The idea is to provide > >>>> information on the language/version name, as well as a reference to > >>>> the according specification and format definition, and to the > >>>> citation that explains the format, if those things are existing. > >>>> > >>>> I attach a table with a number of languages and versions, and the > >>>> above mentioned information. > >>>> It would be great if you could > >>>> > >>>> 1) correct and complete the table > >>>> 2) let me know if you are aware of further languages/versions we > >>>> should include. > >>>> > >>>> Thanks. > >>>> Dagmar > >>> > >>> > >>> -------------------------------------------------------------------- > >>> -- > >>> -------- ThinkGeek and WIRED's GeekDad team up for the Ultimate > >>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky > >>> parental unit. See the prize list and enter to win: > >>> http://p.sf.net/sfu/thinkgeek-promo > >>> _______________________________________________ > >>> SED-ML-discuss mailing list > >>> SED...@li... > >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > >> > >> > >> -- > >> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome- > >> Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, > >> Tel:+441223494521 > >> > Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(N > >> OT email) http://www.ebi.ac.uk/~lenov/, > >> http://www.ebi.ac.uk/compneur/, @lenovere > >> > >> > >> > >> > > ---------------------------------------------------------------------- > > ------ > > -- > >> ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad > >> Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. > >> See the prize list and enter to win: > >> http://p.sf.net/sfu/thinkgeek-promo > >> _______________________________________________ > >> SED-ML-discuss mailing list > >> SED...@li... > >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > > > -- > Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome- > Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, > Tel:+441223494521 > Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(N > OT email) http://www.ebi.ac.uk/~lenov/, > http://www.ebi.ac.uk/compneur/, @lenovere > |
|
From: Nicolas Le n. <le...@eb...> - 2010-06-08 17:32:57
|
The need is that different versions/levels can have different elements/symbols/way of doing things. If we provide links to schemas, we must differentiate between alternatives. Would-you always point to the latest SBML definition, like L3V1, even if the file is an L2V4? On 08/06/10 18:26, Frank Bergmann wrote: > I still don't see the need, but if others do that is fine with me. Why would > I reject a model, just because now the resource is pointing to an SBML Level > 3 document, when the SED-ML document was expecting an l2v4 one? > > Cheers > Frank > >> -----Original Message----- >> From: Nicolas Le novère [mailto:le...@eb...] >> Sent: Tuesday, June 08, 2010 10:23 AM >> To: sed...@li... >> Subject: Re: [SED-ML-discuss] sed-ml language >> >> What about a system providing info for the ones who want it but allow for >> fuzziness: >> >> urn:sedml:language:cellml:version-1.1 >> urn:sedml:language:neuroml:version-1.8 >> urn:sedml:language:sbml:level-2-version-4 >> >> ? >> >> On 08/06/10 18:11, Frank T. Bergmann wrote: >>> Hello Dagmar, >>> >>> this is an interesting idea. However, I would prefer not to bring in >>> the level / version of the model into SED-ML. For example, no matter >>> what SBML model you are pointing to many software packages will be able >> to support it. >>> Moreover when you point at a model for example with a BioModel URN >>> your version number can change under your hand. So how about we >> simplify it to: >>> >>> urn:sedml:language:cellml >>> urn:sedml:language:neuroml >>> urn:sedml:language:sbml >>> urn:sedml:language:vcml >>> >>> from then on we could easily get level and version information from >>> the actual source file. >>> >>> Thanks >>> Frank >>> >>>> -----Original Message----- >>>> From: Dagmar Waltemath [mailto:dag...@un...] >>>> Sent: Tuesday, June 08, 2010 9:28 AM >>>> To: sed...@li... >>>> Subject: [SED-ML-discuss] sed-ml language >>>> >>>> Hello... >>>> >>>> I was looking at the language references. >>>> We decided to store the language of each model we use in the SED-ML >>>> file. And we want to use a common urn scheme for that: >>>> urn:sedml:language:X. >>>> >>>> We will have to specify the X for each language that we know thinks >>>> about using SED-ML, so far I have CellML, NeuroML, SBML and VCML. >>>> Same for the different versions of those languages. >>>> >>>> The information will be provided online. The idea is to provide >>>> information on the language/version name, as well as a reference to >>>> the according specification and format definition, and to the >>>> citation that explains the format, if those things are existing. >>>> >>>> I attach a table with a number of languages and versions, and the >>>> above mentioned information. >>>> It would be great if you could >>>> >>>> 1) correct and complete the table >>>> 2) let me know if you are aware of further languages/versions we >>>> should include. >>>> >>>> Thanks. >>>> Dagmar >>> >>> >>> ---------------------------------------------------------------------- >>> -------- ThinkGeek and WIRED's GeekDad team up for the Ultimate >>> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental >>> unit. See the prize list and enter to win: >>> http://p.sf.net/sfu/thinkgeek-promo >>> _______________________________________________ >>> SED-ML-discuss mailing list >>> SED...@li... >>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >> >> >> -- >> Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome- >> Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, >> Tel:+441223494521 >> Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(N >> OT email) http://www.ebi.ac.uk/~lenov/, >> http://www.ebi.ac.uk/compneur/, @lenovere >> >> >> >> > ---------------------------------------------------------------------------- > -- >> ThinkGeek and WIRED's GeekDad team up for the Ultimate >> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the >> lucky parental unit. See the prize list and enter to win: >> http://p.sf.net/sfu/thinkgeek-promo >> _______________________________________________ >> SED-ML-discuss mailing list >> SED...@li... >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email) http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere |
|
From: Frank B. <fbergman@u.washington.edu> - 2010-06-08 17:28:16
|
I still don't see the need, but if others do that is fine with me. Why would I reject a model, just because now the resource is pointing to an SBML Level 3 document, when the SED-ML document was expecting an l2v4 one? Cheers Frank > -----Original Message----- > From: Nicolas Le novère [mailto:le...@eb...] > Sent: Tuesday, June 08, 2010 10:23 AM > To: sed...@li... > Subject: Re: [SED-ML-discuss] sed-ml language > > What about a system providing info for the ones who want it but allow for > fuzziness: > > urn:sedml:language:cellml:version-1.1 > urn:sedml:language:neuroml:version-1.8 > urn:sedml:language:sbml:level-2-version-4 > > ? > > On 08/06/10 18:11, Frank T. Bergmann wrote: > > Hello Dagmar, > > > > this is an interesting idea. However, I would prefer not to bring in > > the level / version of the model into SED-ML. For example, no matter > > what SBML model you are pointing to many software packages will be able > to support it. > > Moreover when you point at a model for example with a BioModel URN > > your version number can change under your hand. So how about we > simplify it to: > > > > urn:sedml:language:cellml > > urn:sedml:language:neuroml > > urn:sedml:language:sbml > > urn:sedml:language:vcml > > > > from then on we could easily get level and version information from > > the actual source file. > > > > Thanks > > Frank > > > >> -----Original Message----- > >> From: Dagmar Waltemath [mailto:dag...@un...] > >> Sent: Tuesday, June 08, 2010 9:28 AM > >> To: sed...@li... > >> Subject: [SED-ML-discuss] sed-ml language > >> > >> Hello... > >> > >> I was looking at the language references. > >> We decided to store the language of each model we use in the SED-ML > >> file. And we want to use a common urn scheme for that: > >> urn:sedml:language:X. > >> > >> We will have to specify the X for each language that we know thinks > >> about using SED-ML, so far I have CellML, NeuroML, SBML and VCML. > >> Same for the different versions of those languages. > >> > >> The information will be provided online. The idea is to provide > >> information on the language/version name, as well as a reference to > >> the according specification and format definition, and to the > >> citation that explains the format, if those things are existing. > >> > >> I attach a table with a number of languages and versions, and the > >> above mentioned information. > >> It would be great if you could > >> > >> 1) correct and complete the table > >> 2) let me know if you are aware of further languages/versions we > >> should include. > >> > >> Thanks. > >> Dagmar > > > > > > ---------------------------------------------------------------------- > > -------- ThinkGeek and WIRED's GeekDad team up for the Ultimate > > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental > > unit. See the prize list and enter to win: > > http://p.sf.net/sfu/thinkgeek-promo > > _______________________________________________ > > SED-ML-discuss mailing list > > SED...@li... > > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > > > -- > Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome- > Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, > Tel:+441223494521 > Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(N > OT email) http://www.ebi.ac.uk/~lenov/, > http://www.ebi.ac.uk/compneur/, @lenovere > > > > ---------------------------------------------------------------------------- -- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Nicolas Le n. <le...@eb...> - 2010-06-08 17:22:46
|
What about a system providing info for the ones who want it but allow for fuzziness: urn:sedml:language:cellml:version-1.1 urn:sedml:language:neuroml:version-1.8 urn:sedml:language:sbml:level-2-version-4 ? On 08/06/10 18:11, Frank T. Bergmann wrote: > Hello Dagmar, > > this is an interesting idea. However, I would prefer not to bring in the > level / version of the model into SED-ML. For example, no matter what SBML > model you are pointing to many software packages will be able to support it. > Moreover when you point at a model for example with a BioModel URN your > version number can change under your hand. So how about we simplify it to: > > urn:sedml:language:cellml > urn:sedml:language:neuroml > urn:sedml:language:sbml > urn:sedml:language:vcml > > from then on we could easily get level and version information from the > actual source file. > > Thanks > Frank > >> -----Original Message----- >> From: Dagmar Waltemath [mailto:dag...@un...] >> Sent: Tuesday, June 08, 2010 9:28 AM >> To: sed...@li... >> Subject: [SED-ML-discuss] sed-ml language >> >> Hello... >> >> I was looking at the language references. >> We decided to store the language of each model we use in the SED-ML >> file. And we want to use a common urn scheme for that: >> urn:sedml:language:X. >> >> We will have to specify the X for each language that we know thinks >> about using SED-ML, so far I have CellML, NeuroML, SBML and VCML. Same >> for the different versions of those languages. >> >> The information will be provided online. The idea is to provide >> information on the language/version name, as well as a reference to the >> according specification and format definition, and to the citation that >> explains the format, if those things are existing. >> >> I attach a table with a number of languages and versions, and the above >> mentioned information. >> It would be great if you could >> >> 1) correct and complete the table >> 2) let me know if you are aware of further languages/versions we should >> include. >> >> Thanks. >> Dagmar > > > ------------------------------------------------------------------------------ > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email) http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere |
|
From: Frank T. B. <fbergman@u.washington.edu> - 2010-06-08 17:17:40
|
Hello again ... > -----Original Message----- > From: Dagmar Waltemath [mailto:dag...@un...] > > Connected to that I do have 2 questions: > > 1) My notes from Seattle say that we were in favour of a urn scheme > like > > <variable symbol="urn:sedml:symbol:time" [..] /> for time. > > I could not remember what the reason was not to use simple reserved > names, e.g. reserving the string "time" for the notion of time (if used > with the symbol attribute)? > > <variable symbol="time" [..] /> > in the end what the string is does not matter much, however it seemed at the time that the URN scheme was preferred ... but careful, try not to bind the definition for 'time' to a specific sbml level and version ... thanks > > > 2) Second question I'd have is which symbols, apart from time, would > you > like to use in SED-ML L1V1? > for l1v1 i think that was supposed to be it. best Frank > Cheers, > Dagmar > > > ----------------------------------------------------------------------- > ------- > ThinkGeek and WIRED's GeekDad team up for the Ultimate > GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the > lucky parental unit. See the prize list and enter to win: > http://p.sf.net/sfu/thinkgeek-promo > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss |
|
From: Frank T. B. <fbergman@u.washington.edu> - 2010-06-08 17:11:59
|
Hello Dagmar, this is an interesting idea. However, I would prefer not to bring in the level / version of the model into SED-ML. For example, no matter what SBML model you are pointing to many software packages will be able to support it. Moreover when you point at a model for example with a BioModel URN your version number can change under your hand. So how about we simplify it to: urn:sedml:language:cellml urn:sedml:language:neuroml urn:sedml:language:sbml urn:sedml:language:vcml from then on we could easily get level and version information from the actual source file. Thanks Frank > -----Original Message----- > From: Dagmar Waltemath [mailto:dag...@un...] > Sent: Tuesday, June 08, 2010 9:28 AM > To: sed...@li... > Subject: [SED-ML-discuss] sed-ml language > > Hello... > > I was looking at the language references. > We decided to store the language of each model we use in the SED-ML > file. And we want to use a common urn scheme for that: > urn:sedml:language:X. > > We will have to specify the X for each language that we know thinks > about using SED-ML, so far I have CellML, NeuroML, SBML and VCML. Same > for the different versions of those languages. > > The information will be provided online. The idea is to provide > information on the language/version name, as well as a reference to the > according specification and format definition, and to the citation that > explains the format, if those things are existing. > > I attach a table with a number of languages and versions, and the above > mentioned information. > It would be great if you could > > 1) correct and complete the table > 2) let me know if you are aware of further languages/versions we should > include. > > Thanks. > Dagmar |
|
From: Dagmar W. <dag...@un...> - 2010-06-08 16:27:54
|
Hello... I was looking at the language references. We decided to store the language of each model we use in the SED-ML file. And we want to use a common urn scheme for that: urn:sedml:language:X. We will have to specify the X for each language that we know thinks about using SED-ML, so far I have CellML, NeuroML, SBML and VCML. Same for the different versions of those languages. The information will be provided online. The idea is to provide information on the language/version name, as well as a reference to the according specification and format definition, and to the citation that explains the format, if those things are existing. I attach a table with a number of languages and versions, and the above mentioned information. It would be great if you could 1) correct and complete the table 2) let me know if you are aware of further languages/versions we should include. Thanks. Dagmar |
|
From: Dagmar W. <dag...@un...> - 2010-06-08 16:04:36
|
Hello, I was wondering how to implement the symbols, i.e. implicit variables, we'll define for SED-ML L1V1. We said that we'd have a symbol instead of a target if defining an implicit variable that cannot be addressed explicitly in the defined models by an XPath expression. As an example of symbol we took time. Connected to that I do have 2 questions: 1) My notes from Seattle say that we were in favour of a urn scheme like <variable symbol="urn:sedml:symbol:time" [..] /> for time. I could not remember what the reason was not to use simple reserved names, e.g. reserving the string "time" for the notion of time (if used with the symbol attribute)? <variable symbol="time" [..] /> In both cases we would have an online resource where we say what time "means", e.g. by linking to the definition of time in the different languages we support (if they explicitly specify time). For example: time sbml L2 VX http://sbml.org/Documents/Specifications/XML_Schemas/symbols/time 2) Second question I'd have is which symbols, apart from time, would you like to use in SED-ML L1V1? Cheers, Dagmar |
|
From: Dagmar W. <dag...@un...> - 2010-06-07 16:05:45
|
Hello, I have - included a *label *attribute in each the curve, surface and dataset elements (optional) - turned the *algorithm* attribute into an element, as was discussed in Seattle, nested in a *listOfAlgorithms*. So now, one would write something like that: <uniformTimeCourse [..]> <listOfAlgorithms> <algorithm kisaoID="KiSAO:000000064" /> </listOfAlgorithms> </uniformTimeCourse> to define timecourse simulation that uses a particular algorithm. You can add 0 to many algorithms. The schema is updated as revision 147, and so is the spec. As far as I know, I have now incorporated all changes discussed in Seattle, plus the ones we had on the list that concerned L1V1. Let me know if you are missing something, otherwise we could start the clean-up process and hopefully fix bugs in the spec draft to finalise it :-) Best, Dagmar |
|
From: Dagmar W. <dag...@un...> - 2010-06-07 10:03:10
|
Hej, updates are the following older changes I think I didn't mention before (r143): - changed *type* attribute to *language* attribute, now of type *xs:anyURI* - changed* ChangeMath* to* ComputeChange * changes in the last revision(r 146)* *- added *symbol *attribute on the Variable class - added *maxOccurs="unbounded"* for listOfParameters and listOfVariables (spotted by Richard) Dagmar |
|
From: Lakshminarayana,Anuradha <an...@uc...> - 2010-06-04 17:41:51
|
Hello SEDML enthusiasts, A pre-Alpha version of jLibSEDML Java library for SEDML is now available on sourceforge : https://sourceforge.net/projects/jlibsedml/ jLibSEDML facilitates SEDML support for applications to: - read, validate, edit, and write out SEDML documents - execute tasks and produce outputs (using VCell, Copasi) as specified in SEDML documents More details on the code organization, usage and functionality, dependencies, limitations can be found at: http://ntcnp.org/twiki/bin/view/VCell/JlibSEDML The library is by no means complete. Hopefully it provides a starting point for further development. Comments, suggestions, questions are welcome. Thanks, ~Anuradha. |
|
From: Jonathan C. <jon...@co...> - 2010-06-01 08:17:21
|
David Nickerson wrote: > Having said that, in my experience a simple text-based diff of > simulation data is rarely sufficient to determine if the results are > "correct". I'd like to strongly emphasise this point. We've found with regression tests of our simulation software that a plain diff of numerical results is mostly useless - even for results produced by the same software! You need to do a diff within a specified tolerance. > And once you go beyond a simple text-based diff, as Nicolas > points out, there is very little extra effort to work out what is what > using the label. Any required ordering for specific applications can > then be specified by the application based on the label. After all, > there is nothing wrong with labeling your data references "1", "2", > "3".... :) Best wishes, Jonathan |
|
From: David N. <dav...@gm...> - 2010-05-31 19:43:36
|
> Reading this I have to say that dataSet is actually a quite misleading > name. Was there a reason not to call it "column", which seems to be the > more obvious choice to me right now? And if not, sorry Frank, should we > rename it, or is everybody satisfied with dataSat? Would column be too > restrictive? > I am just asking as there seemed to be confusion about what we mean by > "dataSet". > > I saw nobody being against the label attribute on dataSet. If there are > no objections, I will add it to the SED-ML schema. It will be optional. > And I would suggest to also add it on curves and surfaces then? It seems > to be the same problem there. If you want to address particular columns > in a table, you might want to address particular curves in a plot?! if we think it might be used for referencing/addressing then it should probably be an id rather than a label, although maybe in SBML there is no difference? I think column as a name for this element seems to be putting too much description of the actual output format into the markup language. There is nothing in the spec that states a report is a collection of columns of text data, is there? using columns or another format just seems like a tool problem to me. dataSet seems ok, at least I'm not seeing any obvious problems with the name :) Cheers, Andre. |
|
From: Dagmar W. <dag...@un...> - 2010-05-31 19:00:46
|
Comment inside. Nicolas Le novère wrote: > On 28/05/10 09:09, Dagmar Waltemath wrote: > > >> I agree... the only question I have is what do you mean by "labelling >> the vectors"? >> Could you give an example? >> > > <listOfDatasets> > <dataReference label="time" >dataGenerator1</dataReference> > <dataReference label="X" >dataGenerator2</dataReference> > </listOfDatasets> > > [btw listing 33 page 38 is wrong. Either we create an attribute > "dataGeneratorReference or we put the id as text] > Jepp, your are right that the listing in the spec is actually quite wrong. I'll update it now. Coming back to your example and according to the current UML schema we'd have the below code, if I am not mistaken -- assuming we'll go for the additional label element on the dataSet: <listOfOutputs> <report id="1"> <listOfDataSets> <dataSet label="time" dataReference="dataGen1" /> <dataSet label="X" dataReference="dataGen2" /> [..] </listOfDataSets> </report> </listOfOutputs> Reading this I have to say that dataSet is actually a quite misleading name. Was there a reason not to call it "column", which seems to be the more obvious choice to me right now? And if not, sorry Frank, should we rename it, or is everybody satisfied with dataSat? Would column be too restrictive? I am just asking as there seemed to be confusion about what we mean by "dataSet". I saw nobody being against the label attribute on dataSet. If there are no objections, I will add it to the SED-ML schema. It will be optional. And I would suggest to also add it on curves and surfaces then? It seems to be the same problem there. If you want to address particular columns in a table, you might want to address particular curves in a plot?! Last but not least, I do agree completely with Davids comment: ordering, color and shape of curves should stay in annotations/notes. Those are imho - to borrow an SBML saying - tool problems :-) Best, Dagmar > The way the tool uses this label, how it labels the vector, is none of our > business. > > >> Cheers, >> Dagmar >> >> >> Nicolas Le novère wrote: >> >>> On 27/05/10 21:00, Frank T. Bergmann wrote: >>> >>> >>> >>>> All I wanted was to produce reports that can be exchanged with other groups! >>>> For this there is not enough information there. If that is outside the scope >>>> of SED-ML so be it. >>>> >>>> >>> Actually, I really believe it is outside the scope of SED-ML. And I also >>> believe this discussion is an example of many similar discussions that are >>> currently holding up the release. >>> >>> SED-ML is not for exchanging reports, but for exchanging *recipes* on how >>> to produce reports. By that, I mean that different tools should understand >>> SED-ML the same way. If SED-ML says which variables to export, the tools >>> should export the same variables. If SED-ML does not say anything about the >>> font or the color, then we do not care about those. The tools can produce >>> the same font or different font. >>> >>> Therefore, it is up to us to precise what we cover in SED-ML. But there is >>> arguably not a threshold below which there is not enough information to >>> interpret the report. Because SED-ML is not about the reports themselves. >>> >>> Now, producing reports that cannot be interpreted is not tremendously >>> useful. Currently, we only precise what to export and it is true that >>> without labelling the report vectors or ordering them, they are useless. I >>> am deeply against ordering, particularly for things like reports, so I >>> would favor labelling of vectors. >>> >>> >>> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> SED-ML-discuss mailing list >> SED...@li... >> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss >> > > > |
|
From: David N. <dav...@gm...> - 2010-05-31 02:30:33
|
> The other issue here is that any implementation must provide the output in > *some* order, and if you don't tell it what order you want, it will pick > something, and there will be, generally no reason to pick one order over > another (this is not true of the other things you've compared order to, > like font and color). Why not tell it what you want, so it can give it to > you? Why explicitly deny it that information? While it makes sense for the SBML test suite to describe the way simulation results are stored in order for testing, isn't that a feature of the test suite? For example, can't the test suite simply state that when reports are generated with the data ordered alphabetically by label you can compare them against the "correct" original data. Having said that, in my experience a simple text-based diff of simulation data is rarely sufficient to determine if the results are "correct". And once you go beyond a simple text-based diff, as Nicolas points out, there is very little extra effort to work out what is what using the label. Any required ordering for specific applications can then be specified by the application based on the label. After all, there is nothing wrong with labeling your data references "1", "2", "3".... :) Cheers, Andre. |
|
From: Lucian S. <lp...@sp...> - 2010-05-28 22:34:27
|
* Nicolas Le novère <le...@eb...> [2010-05-28 22:35] writes: > On 28/05/10 16:40, Lucian Smith wrote: > > > I can understand this sentiment, and I can see that font, color, etc., are > > indeed somewhat beyond the scope of the intent of SEDML. However, I do > > think that one huge role of SEDML is to allow people to reproduce > > simulation experiments so that they can be compared with the original. > > Maybe. But I am sorry, for ANY tool developed in ANY language, finding that: Apology accepted. > > And if you are producing text files, if you have the same order of > > columns, you make it 1000 times easier to comapre than if you don't. > > Not 1000 times easier. If you do a diff maybe, but then, it is not just the > order, it is the type of spaces, of carriage returns etc. If you have to > parse the files, it is marginally, if at all easier ... providing you have > the label. Yes, for doing diffs. If you can't diff, you have to parse, and that is what is 1000x harder. Diff is basically built in to the OS, so the effort involved is basically nil. Parsing the files means you have to program, or at least muck about in Excel. Part of the benefit of SEDML is that a user should be able to reproduce published figures in a paper without having to know how to program anything themselves. If they could compare the results with the original results without knowing how to program, that would be even better. > > But since one of the primary early clients of SEDML is the > > SBML test suite, > > With all due respect to the test suite, this is the first time I hear that. > Until now, the main actual users are SBW, JWS Online and VCell. There is > also an expressed interest of OpenCell, SBToolbox2 and BioModels DB. The test suite is a different type of client than the simulators--it is a source of exchangeable SEDML files. The other main source of exchangeable SEDML files that I can think of is Biomodels--you all do a lot of work to reproduce the figures in the papers you curate, and with SEDML, that effort can now be stored and shared. Apart from those two sources, you then get to individual labs who might start publishing the SEDML files along with their papers, but that will only come with time. All that to say that since the test suite relies on order (Chris was complaining about this at the hackathon, and one proposed solution was actually 'use SEDML to produce the reports, and then they'll be in the right order!') and since non-programmers checking things out from their home computers would (I believe) benefit from having order, I think there should be a way to provide that information. I am fine (if a little sceptical) about it not being in core, but surely nobody would object to providing this in some sort of annotation? The other issue here is that any implementation must provide the output in *some* order, and if you don't tell it what order you want, it will pick something, and there will be, generally no reason to pick one order over another (this is not true of the other things you've compared order to, like font and color). Why not tell it what you want, so it can give it to you? Why explicitly deny it that information? -Lucian |
|
From: Nicolas Le n. <le...@eb...> - 2010-05-28 21:34:53
|
On 28/05/10 16:40, Lucian Smith wrote: > I can understand this sentiment, and I can see that font, color, etc., are > indeed somewhat beyond the scope of the intent of SEDML. However, I do > think that one huge role of SEDML is to allow people to reproduce > simulation experiments so that they can be compared with the original. Maybe. But I am sorry, for ANY tool developed in ANY language, finding that: X Y Z 1 2 3 2 3 4 3 4 5 4 5 6 and X Z Y 1 3 2 2 4 3 3 5 4 4 6 5 Are identical is abysmally trivial > And if you are producing text files, if you have the same order of > columns, you make it 1000 times easier to comapre than if you don't. Not 1000 times easier. If you do a diff maybe, but then, it is not just the order, it is the type of spaces, of carriage returns etc. If you have to parse the files, it is marginally, if at all easier ... providing you have the label. > But since one of the primary early clients of SEDML is the > SBML test suite, With all due respect to the test suite, this is the first time I hear that. Until now, the main actual users are SBW, JWS Online and VCell. There is also an expressed interest of OpenCell, SBToolbox2 and BioModels DB. -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email) http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere |
|
From: Dagmar W. <dag...@un...> - 2010-05-28 16:04:43
|
Hello, I have updated the XML Schema and the draft specification on SF by adding the "level" attribute to the "sedML" element in the schema, and by changing the type of "level" and "version" from xs:integer to xs:decimal. Let me know if there are any problems with those changes. Sorry for the inconvenience, Dagmar |
|
From: Lucian S. <lp...@sp...> - 2010-05-28 15:40:32
|
* Nicolas Le novère <le...@eb...> [2010-05-28 08:56] writes: > On 27/05/10 21:00, Frank T. Bergmann wrote: > > > All I wanted was to produce reports that can be exchanged with other groups! > > For this there is not enough information there. If that is outside the scope > > of SED-ML so be it. > > Actually, I really believe it is outside the scope of SED-ML. And I also > believe this discussion is an example of many similar discussions that are > currently holding up the release. > > SED-ML is not for exchanging reports, but for exchanging *recipes* on how > to produce reports. By that, I mean that different tools should understand > SED-ML the same way. If SED-ML says which variables to export, the tools > should export the same variables. If SED-ML does not say anything about the > font or the color, then we do not care about those. The tools can produce > the same font or different font. > > Therefore, it is up to us to precise what we cover in SED-ML. But there is > arguably not a threshold below which there is not enough information to > interpret the report. Because SED-ML is not about the reports themselves. > > Now, producing reports that cannot be interpreted is not tremendously > useful. Currently, we only precise what to export and it is true that > without labelling the report vectors or ordering them, they are useless. I > am deeply against ordering, particularly for things like reports, so I > would favor labelling of vectors. I can understand this sentiment, and I can see that font, color, etc., are indeed somewhat beyond the scope of the intent of SEDML. However, I do think that one huge role of SEDML is to allow people to reproduce simulation experiments so that they can be compared with the original. And if you are producing text files, if you have the same order of columns, you make it 1000 times easier to comapre than if you don't. This is what the SBML Test Suite needs in order to do automatic comparisons of simulator output against a standard. I don't see a better place to put the column-ordering information than the SEDML file. I'll definitely agree that this information should not be *required*, and that it may be best suited to living in an annotation somewhere. But since one of the primary early clients of SEDML is the SBML test suite, it seems reasonable to provide a standard way of giving them that information, so that simulators can use it to produce output that can be automatically compared to standard output. -Lucian |
|
From: Richard A. <ra...@st...> - 2010-05-28 09:09:22
|
Hi Dagmar,
Having spent some time playing around trying to implement some of
these operations, I'm strongly in favour of Frank's suggestion as
1) An operation is made explicit to a single target XPath . Possibly
we could have multiple model XML elements to add/remove in a single
changeXML element if all the model XML elements were rooted in the
same parent defined by XPath. E.g., suppose you want to add 2
parameter definitions to an SBML model. Rather than
<addXML target="//sbml:sbml/sbml:model/sbml:listOfParameters">
<newXML>
<parameter metaid=\"metaid_0000022\" id=\"beta22\" name=\"Ratio of
protein to mRNA decay rates\" value=\"0.2\"/>
</newXML>
</addXML>
<addXML target="//sbml:sbml/sbml:model/sbml:listOfParameters">
<newXML>
<parameter metaid=\"metaid_0000233\" id=\"beta233\" name=\"Ratio of
protein to mRNA decay rates\" value=\"0.4\"/>
</newXML>
</addXML>
they could be combined. E.g.,
<addXML target="//sbml:sbml/sbml:model/sbml:listOfParameters">
<newXML>
<parameter metaid=\"metaid_0000022\" id=\"beta22\" name=\"Ratio of
protein to mRNA decay rates\" value=\"0.2\"/>
<parameter metaid=\"metaid_0000233\" id=\"beta233\" name=\"Ratio of
protein to mRNA decay rates\" value=\"0.4\"/>
</newXML>
</addXML>
2) I prefer Frank's second suggestion of subelements for XML
operations rather than attributes - additional operations could be
added in future without altering the base class changeXML.
Cheers
Richard
> Hej Frank,
>
> thanks for the recommendation.
>
> I cannot see any disadvantages with your suggestion,
> but I was wondering what the others think about it?
>
> Should we have an additional "operation" attribute on the changeXML
> element that will specify HOW we change the thingy addressed by the
> XPath expression? Fixed values suggested were "delete", "update" and "add".
>
> Any opinions?
> Dagmar
>
>
>
> Frank Bergmann wrote:
>> Hello all,
>>
>> I know at the Hackathon we were briefly talking about ChangeXML, and that it
>> should be included in SEDML Level 1 Version 1. So I finally had a detailed
>> look at the construct and tried to map out what implications it would have.
>> Currently we have one construct:
>>
>> <changeXML target="<xpath expression to model variable>" newXML="<some
>> really long unvalidatable string here that might or might not be XML>" />
>>
>> I assume this to be a typo. If I remember it correctly from our discussions
>> this really should look like this:
>>
>> <changeXML target="<xpath expression to model variable>">
>> <newXML>
>> <some new xml here, validatable with target namespace and bells and
>> whistles>
>> </newXML>
>> </changeXML>
>>
>> Ok ... this basically would work ... so the next important thing to ask, is
>> what would we like to do with this. Basically three things:
>>
>> - adding new elements (i.e.: a degradation reaction to an existing species)
>> - replacing an element by something else (i.e.: a lumped reaction by its
>> individual steps)
>> - deleting elements (i.e.: removing a reaction step)
>>
>> Previously we discussed, that we could delete elements by replacing a target
>> with an empty newXML block. If we look at the draft specification we find an
>> example, that shows that we could add a parameter to a model, by replacing
>> one parameter with itself and another one:
>>
>> 1 <model [..]>
>> 2 <listOfChanges>
>> 3 <changeXML target="/sbml:sbml/sbml:model/sbml:listOfParameters
>> 4 /sbml:parameter[@id='V_mT ']"
>> 5 newXML="<parameter metaid="metaid_0000010" id="V_mT" value="0.7">
>> 6 <parameter metaid="metaid_0000050" id="V_mT_2" value="4.6">" />
>> 7 </listOfChanges>
>> 8 </model>
>>
>> I would very much prefer to keep the individual operations separate, either
>> by introducing an additional attribute 'operation' on the changeXML element:
>>
>>
>> 1 <model [..]>
>> 2 <listOfChanges>
>> 3 <changeXML target="/sbml:sbml/sbml:model/sbml:listOfParameters"
>> 4 operation="add">
>> 5 <newXML>
>> 6 <parameter xmlns="<sbmlnshere>" metaid="metaid_0000050" id="V_mT_2"
>> value="4.6">
>> 7 </newXML>
>> 8 </listOfChanges>
>> 9 </model>
>>
>> The advantage here is that it is much easier to apply changes from one model
>> to another, without artificially having to replace existing elements by
>> itself + whatever one wants to add in the first place.
>>
>> Similarly:
>>
>> <changeXML
>> target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='V_mT
>> ']"
>> operation="delete"/>
>>
>> would delete an element ... and so on ... alternatively if someone would
>> really be against the additional attribute, we could introduce differently
>> named elements like:
>>
>> <addXML target="<xpath>"><newXML> <stuff here/> </newXml> </addXML>
>> <removeXML target="xpath"/>
>>
>> And changeXML would remain as is ...
>>
>>
>> Let the floor be open for comments :)
>>
>> Cheers
>> Frank
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> SED-ML-discuss mailing list
>> SED...@li...
>> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> SED-ML-discuss mailing list
> SED...@li...
> https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss
>
>
--
Dr Richard Adams
Software Development Team Leader,
Centre For Systems Biology Edinburgh
University of Edinburgh
Tel: 0131 650 8285
email : ric...@ed...
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
|
|
From: Nicolas Le n. <le...@eb...> - 2010-05-28 08:23:31
|
On 28/05/10 09:09, Dagmar Waltemath wrote: > I agree... the only question I have is what do you mean by "labelling > the vectors"? > Could you give an example? <listOfDatasets> <dataReference label="time" >dataGenerator1</dataReference> <dataReference label="X" >dataGenerator2</dataReference> </listOfDatasets> [btw listing 33 page 38 is wrong. Either we create an attribute "dataGeneratorReference or we put the id as text] The way the tool uses this label, how it labels the vector, is none of our business. > > Cheers, > Dagmar > > > Nicolas Le novère wrote: >> On 27/05/10 21:00, Frank T. Bergmann wrote: >> >> >>> All I wanted was to produce reports that can be exchanged with other groups! >>> For this there is not enough information there. If that is outside the scope >>> of SED-ML so be it. >>> >> >> Actually, I really believe it is outside the scope of SED-ML. And I also >> believe this discussion is an example of many similar discussions that are >> currently holding up the release. >> >> SED-ML is not for exchanging reports, but for exchanging *recipes* on how >> to produce reports. By that, I mean that different tools should understand >> SED-ML the same way. If SED-ML says which variables to export, the tools >> should export the same variables. If SED-ML does not say anything about the >> font or the color, then we do not care about those. The tools can produce >> the same font or different font. >> >> Therefore, it is up to us to precise what we cover in SED-ML. But there is >> arguably not a threshold below which there is not enough information to >> interpret the report. Because SED-ML is not about the reports themselves. >> >> Now, producing reports that cannot be interpreted is not tremendously >> useful. Currently, we only precise what to export and it is true that >> without labelling the report vectors or ordering them, they are useless. I >> am deeply against ordering, particularly for things like reports, so I >> would favor labelling of vectors. >> >> > > > ------------------------------------------------------------------------------ > > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email) http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere |
|
From: Dagmar W. <dag...@un...> - 2010-05-28 08:09:38
|
Nicolas, I agree... the only question I have is what do you mean by "labelling the vectors"? Could you give an example? Cheers, Dagmar Nicolas Le novère wrote: > On 27/05/10 21:00, Frank T. Bergmann wrote: > > >> All I wanted was to produce reports that can be exchanged with other groups! >> For this there is not enough information there. If that is outside the scope >> of SED-ML so be it. >> > > Actually, I really believe it is outside the scope of SED-ML. And I also > believe this discussion is an example of many similar discussions that are > currently holding up the release. > > SED-ML is not for exchanging reports, but for exchanging *recipes* on how > to produce reports. By that, I mean that different tools should understand > SED-ML the same way. If SED-ML says which variables to export, the tools > should export the same variables. If SED-ML does not say anything about the > font or the color, then we do not care about those. The tools can produce > the same font or different font. > > Therefore, it is up to us to precise what we cover in SED-ML. But there is > arguably not a threshold below which there is not enough information to > interpret the report. Because SED-ML is not about the reports themselves. > > Now, producing reports that cannot be interpreted is not tremendously > useful. Currently, we only precise what to export and it is true that > without labelling the report vectors or ordering them, they are useless. I > am deeply against ordering, particularly for things like reports, so I > would favor labelling of vectors. > > |
|
From: Nicolas Le n. <le...@eb...> - 2010-05-28 07:55:31
|
On 27/05/10 21:00, Frank T. Bergmann wrote: > All I wanted was to produce reports that can be exchanged with other groups! > For this there is not enough information there. If that is outside the scope > of SED-ML so be it. Actually, I really believe it is outside the scope of SED-ML. And I also believe this discussion is an example of many similar discussions that are currently holding up the release. SED-ML is not for exchanging reports, but for exchanging *recipes* on how to produce reports. By that, I mean that different tools should understand SED-ML the same way. If SED-ML says which variables to export, the tools should export the same variables. If SED-ML does not say anything about the font or the color, then we do not care about those. The tools can produce the same font or different font. Therefore, it is up to us to precise what we cover in SED-ML. But there is arguably not a threshold below which there is not enough information to interpret the report. Because SED-ML is not about the reports themselves. Now, producing reports that cannot be interpreted is not tremendously useful. Currently, we only precise what to export and it is true that without labelling the report vectors or ordering them, they are useless. I am deeply against ordering, particularly for things like reports, so I would favor labelling of vectors. -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton CB101SD UK, Mob:+447833147074, Tel:+441223494521 Fax:468,Skype:n.lenovere,AIM:nlenovere,MSN:nle...@ho...(NOT email) http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/, @lenovere |
|
From: Dagmar W. <dag...@un...> - 2010-05-28 06:50:57
|
Hej Frank, thanks for the recommendation. I cannot see any disadvantages with your suggestion, but I was wondering what the others think about it? Should we have an additional "operation" attribute on the changeXML element that will specify HOW we change the thingy addressed by the XPath expression? Fixed values suggested were "delete", "update" and "add". Any opinions? Dagmar Frank Bergmann wrote: > Hello all, > > I know at the Hackathon we were briefly talking about ChangeXML, and that it > should be included in SEDML Level 1 Version 1. So I finally had a detailed > look at the construct and tried to map out what implications it would have. > Currently we have one construct: > > <changeXML target="<xpath expression to model variable>" newXML="<some > really long unvalidatable string here that might or might not be XML>" /> > > I assume this to be a typo. If I remember it correctly from our discussions > this really should look like this: > > <changeXML target="<xpath expression to model variable>"> > <newXML> > <some new xml here, validatable with target namespace and bells and > whistles> > </newXML> > </changeXML> > > Ok ... this basically would work ... so the next important thing to ask, is > what would we like to do with this. Basically three things: > > - adding new elements (i.e.: a degradation reaction to an existing species) > - replacing an element by something else (i.e.: a lumped reaction by its > individual steps) > - deleting elements (i.e.: removing a reaction step) > > Previously we discussed, that we could delete elements by replacing a target > with an empty newXML block. If we look at the draft specification we find an > example, that shows that we could add a parameter to a model, by replacing > one parameter with itself and another one: > > 1 <model [..]> > 2 <listOfChanges> > 3 <changeXML target="/sbml:sbml/sbml:model/sbml:listOfParameters > 4 /sbml:parameter[@id='V_mT ']" > 5 newXML="<parameter metaid="metaid_0000010" id="V_mT" value="0.7"> > 6 <parameter metaid="metaid_0000050" id="V_mT_2" value="4.6">" /> > 7 </listOfChanges> > 8 </model> > > I would very much prefer to keep the individual operations separate, either > by introducing an additional attribute 'operation' on the changeXML element: > > > 1 <model [..]> > 2 <listOfChanges> > 3 <changeXML target="/sbml:sbml/sbml:model/sbml:listOfParameters" > 4 operation="add"> > 5 <newXML> > 6 <parameter xmlns="<sbmlnshere>" metaid="metaid_0000050" id="V_mT_2" > value="4.6"> > 7 </newXML> > 8 </listOfChanges> > 9 </model> > > The advantage here is that it is much easier to apply changes from one model > to another, without artificially having to replace existing elements by > itself + whatever one wants to add in the first place. > > Similarly: > > <changeXML > target="/sbml:sbml/sbml:model/sbml:listOfParameters/sbml:parameter[@id='V_mT > ']" > operation="delete"/> > > would delete an element ... and so on ... alternatively if someone would > really be against the additional attribute, we could introduce differently > named elements like: > > <addXML target="<xpath>"><newXML> <stuff here/> </newXml> </addXML> > <removeXML target="xpath"/> > > And changeXML would remain as is ... > > > Let the floor be open for comments :) > > Cheers > Frank > > > > > ------------------------------------------------------------------------------ > > _______________________________________________ > SED-ML-discuss mailing list > SED...@li... > https://lists.sourceforge.net/lists/listinfo/sed-ml-discuss > |
14 messages has been excluded from this view by a project administrator.
