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: Nicolas Le n. <le...@eb...> - 2010-06-17 22:05:34
|
But that would require a complete change of SED-ML. I do not see how that is an "extension". That said, I am not against the element version. On 17/06/10 19:37, Frank Bergmann wrote: >> However, I couldn't find an example for such a possible extension... >> does anyone have one? >> Any characteristics/attributes one might want to assign to a particular >> change type in the future? >> > > Sure sure ... here is one ... suppose one day SED-ML is extended to include > non XML-languages ... such as antimony ... in that case one could easily > introduce a change construct that references antimony elements other than by > XPath expression. > > Cheers > Frank > >> That would make the decision for classes easier :-) Dagmar >> >> >> Frank Bergmann wrote: >>>>> I'm still missing the most important one ... the fix to the >>>>> ChangeXML >>>>> >>> ... >>> >>>>> implementing adding of elements by having to replace an existing >>>>> model element with itself and another one is just plain wrong! It >>>>> would be >>>>> >>> great >>> >>>>> to have it separated out into: >>>>> >>>>> AddXML >>>>> ChangeXML >>>>> RemoveXML >>>>> >>>>> Or at least have an operation flag on the ChangeXML element! >>>>> >>>>> >>>> I was not sure if there was an agreement here for having an "operation" >>>> attribute >>>> defining the type of change as one of add, delete, replace? >>>> >>>> >>> >>> Well .. there was an agreement, that this is needed. So far we have: >>> >>> - favoring attribute: Nicolas >>> - slight preference for element: Richard, Frank (though I suppose if >>> no one else can live with the elements then we would not loose much >>> sleep in not getting them) >>> - undecided: the rest >>> >>> Cheers >>> Frank >>> >>> >>>> 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 >>>> >>> >>> >>> ---------------------------------------------------------------------- >>> -------- 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 >>> >> >> >> > ---------------------------------------------------------------------------- > -- >> 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 > > > ------------------------------------------------------------------------------ > 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: Dagmar W. <dag...@un...> - 2010-06-17 18:41:42
|
We can be fast :-) If there are any problems with that solution we can still adapt/change things back - the spec is not yet released and we're all just trying to build the SED-ML as good as possible. There might not be an urgent need for having a detailed language description right now, but I thought we agreed on that we wanted it at least for the future. It was easy to put, a list of URNs didn't do much harm. And really: it is optional, so for people not wanting to use it, that's not a problem at all. Regarding NeuoML, yes, it seems that they do version/level differently to SBML. As said: If the solution as it is now is not what you (or anybody else) had in mind, please let me know and we can start the discussion again. Cheerio, Dagmar Frank Bergmann wrote: >> everybody has been very quiet on this, >> so I have changed the XSD for the "language" attribute to be optional and >> having the default value "urn:sedml:language:xml". >> > > I can't believe this made it in there that fast. There is really no need for > having this at this stage. There is no advantage to having it (other than > placing more work on the implementers). > > >> I also put the list of language URNs for SED-ML (which I proposed in the >> excel file) on the SED-ML web site on http://www.biomodels.net/sed- >> ml/#sedmlLanguage >> > > I still think this is way more complicated than it needs to be. While I > might be able to understand that for example major level changes are > differentiated, I would not go as far as listing everything else. I'm not > familiar with NeuroML but it seems odd that the level and version > information are switched around. Is that intentional? > > Cheers > Frank > > > ------------------------------------------------------------------------------ > 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-17 18:38:48
|
> However, I couldn't find an example for such a possible extension... > does anyone have one? > Any characteristics/attributes one might want to assign to a particular > change type in the future? > Sure sure ... here is one ... suppose one day SED-ML is extended to include non XML-languages ... such as antimony ... in that case one could easily introduce a change construct that references antimony elements other than by XPath expression. Cheers Frank > That would make the decision for classes easier :-) Dagmar > > > Frank Bergmann wrote: > >>> I'm still missing the most important one ... the fix to the > >>> ChangeXML > >>> > > ... > > > >>> implementing adding of elements by having to replace an existing > >>> model element with itself and another one is just plain wrong! It > >>> would be > >>> > > great > > > >>> to have it separated out into: > >>> > >>> AddXML > >>> ChangeXML > >>> RemoveXML > >>> > >>> Or at least have an operation flag on the ChangeXML element! > >>> > >>> > >> I was not sure if there was an agreement here for having an "operation" > >> attribute > >> defining the type of change as one of add, delete, replace? > >> > >> > > > > Well .. there was an agreement, that this is needed. So far we have: > > > > - favoring attribute: Nicolas > > - slight preference for element: Richard, Frank (though I suppose if > > no one else can live with the elements then we would not loose much > > sleep in not getting them) > > - undecided: the rest > > > > Cheers > > Frank > > > > > >> 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 > >> > > > > > > ---------------------------------------------------------------------- > > -------- 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 > > > > > ---------------------------------------------------------------------------- -- > 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: Dagmar W. <dag...@un...> - 2010-06-17 18:35:30
|
Sure, there was agreement that it was needed. But not how to model it in SED-ML :-) I have to say I am a bit torn. I personally think the attribute version is nicer, but Richard made a point saying that having separate classes will be better extensible in the future. However, I couldn't find an example for such a possible extension... does anyone have one? Any characteristics/attributes one might want to assign to a particular change type in the future? That would make the decision for classes easier :-) Dagmar Frank Bergmann wrote: >>> I'm still missing the most important one ... the fix to the ChangeXML >>> > ... > >>> implementing adding of elements by having to replace an existing model >>> element with itself and another one is just plain wrong! It would be >>> > great > >>> to have it separated out into: >>> >>> AddXML >>> ChangeXML >>> RemoveXML >>> >>> Or at least have an operation flag on the ChangeXML element! >>> >>> >> I was not sure if there was an agreement here for having an "operation" >> attribute >> defining the type of change as one of add, delete, replace? >> >> > > Well .. there was an agreement, that this is needed. So far we have: > > - favoring attribute: Nicolas > - slight preference for element: Richard, Frank (though I suppose if no one > else can live with the elements then we would not loose much sleep in not > getting them) > - undecided: the rest > > Cheers > Frank > > >> 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 >> > > > ------------------------------------------------------------------------------ > 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-17 18:09:13
|
> everybody has been very quiet on this, > so I have changed the XSD for the "language" attribute to be optional and > having the default value "urn:sedml:language:xml". I can't believe this made it in there that fast. There is really no need for having this at this stage. There is no advantage to having it (other than placing more work on the implementers). > > I also put the list of language URNs for SED-ML (which I proposed in the > excel file) on the SED-ML web site on http://www.biomodels.net/sed- > ml/#sedmlLanguage I still think this is way more complicated than it needs to be. While I might be able to understand that for example major level changes are differentiated, I would not go as far as listing everything else. I'm not familiar with NeuroML but it seems odd that the level and version information are switched around. Is that intentional? Cheers Frank |
|
From: Frank B. <fbergman@u.washington.edu> - 2010-06-17 18:00:08
|
> > I'm still missing the most important one ... the fix to the ChangeXML ... > > implementing adding of elements by having to replace an existing model > > element with itself and another one is just plain wrong! It would be great > > to have it separated out into: > > > > AddXML > > ChangeXML > > RemoveXML > > > > Or at least have an operation flag on the ChangeXML element! > > > > I was not sure if there was an agreement here for having an "operation" > attribute > defining the type of change as one of add, delete, replace? > Well .. there was an agreement, that this is needed. So far we have: - favoring attribute: Nicolas - slight preference for element: Richard, Frank (though I suppose if no one else can live with the elements then we would not loose much sleep in not getting them) - undecided: the rest Cheers Frank > 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 B. <fbergman@u.washington.edu> - 2010-06-17 17:33:53
|
> 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.
Are you sure that integers would not have worked for you?
Cheers
Frank
Caveats
=======
The definition of this datatype defines no restrictions whatsoever on the
size of numbers permissible under this datatype. Unless your form processing
is prepared to deal with a number thousands of digits long (or even longer),
you should use a restriction on the allowed upper and lower limits, and
number of digits past the decimal point, as shown here:
<xs:simpleType name="restrictedInteger">
<xs:restriction base="xs:decimal">
<xs:maxExclusive value="1000000"/>
<xs:minInclusive value="-1000000"/>
<xs:fractionDigits value='2'/>
</xs:restriction>
</xs:simpleType>
Examples
=========
3.14
-12345678901234567890123456789012345
0.318309886
From: http://xformsinstitute.com/essentials/browse/re46.php
|
|
From: Frank B. <fbergman@u.washington.edu> - 2010-06-17 17:32:08
|
> I added optional names on Curve, Surface, DataSet classes. > I also added a label attribute on DataSet. > > Right now the Algorithm is mandatory as a sub-class of Simulation. Let me > know if you think it shouldn't. > I don't mind it being mandatory, though for l1v1 it does not matter all that much. Best Frank |
|
From: Dagmar W. <dag...@un...> - 2010-06-16 10:28:15
|
Hello, everybody has been very quiet on this, so I have changed the XSD for the "language" attribute to be optional and having the default value "urn:sedml:language:xml". I also put the list of language URNs for SED-ML (which I proposed in the excel file) on the SED-ML web site on http://www.biomodels.net/sed-ml/#sedmlLanguage Any comments are welcome, as always. Dagmar PS: I am aware that urn:sedml:language:xml is missing in the table on the web site, it will be added there soon. Dagmar Waltemath wrote: > So, would the following solution for language suit everybody? > > > 1) we make the language attribute optional in the specification. If it > is not given, it basically says "xml" and it is up to the tool to > identify the model format. Also, if you do not care about providing the > model format, you just don't define the language. > > 2) if we want to specify the language, we could have a sub-domain like > mechanism, as Nicolas suggested, by having different urns for: > > urn:sedml:sbml > urn:sedml:sbml.level1 > urn:sedml:sbml.level2.version2.release2 > > and similarly > > urn:sedml:cellml > urn:sedml:cellml.1_1 (this would correspond to 1.1, but it seems we > cannot have the dot here anyways in the urn, if I got things right) > > That will allow us to define the language on different granularities. > > Does that sound ok? > Dagmar > > > > Nicolas Le novère wrote: > >> On 08/06/10 19:06, Lucian Smith wrote: >> > 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? >> >> How do-you know if you can parse the language if you do not know which >> language you are talking about. I believe there may be the impression >> floating around that all languages are like SBML, with all the info in the >> header. This is not always the case (even CellML has only a namespace, not >> a schemaLocation). But even in that situation, in order to read that >> information, you need the definition of the language (you need to know what >> are the attributes "level" and "version") >> >> > 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.) >> >> That would be true if we were not using the controlled symbols. >> >> > 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? >> >> We can either define xml, or use it as the default. >> >> > * 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 >> >> >> >> > > > ------------------------------------------------------------------------------ > 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: Dagmar W. <dag...@un...> - 2010-06-12 21:08:33
|
Hej all, I added optional names on Curve, Surface, DataSet classes. I also added a label attribute on DataSet. Right now the Algorithm is mandatory as a sub-class of Simulation. Let me know if you think it shouldn't. (r 152) Not much left on the list of issues. Dagmar |
|
From: Dagmar W. <dag...@un...> - 2010-06-12 16:51:48
|
Hej Frank and all. Frank Bergmann wrote: > Thanks for following up on this ... here some comments: > >> - 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. >> >> > > Ok .. this is a bigger change than I wanted it to be! I was fine with > agreeing to have algorithm be an element, so that we could have it annotated > later on with all the properties that we would want to set on it. But a list > of algorithms really? Why do we need that? Would these be mutually > exclusive? Or what should we do if we list: > > Forward Euler, > Runge Kutta, > CVODE, > Gillespie > > This no longer allows me to distinguish whether I should carry out a > discrete or continuous simulation. (Or this is actually a specification of a > certain hybrid algorithm. But even then, that algorithm should have its own > description! And again only one algorithm would need to be referenced ) > Convinced. I changed it back to having only one algorithm per simulation, so <uniformTimeCourse [..]> <algorithm kisaoID="KiSAO:000000064" /> </uniformTimeCourse> (revision 150 if someone wants to check) > I'm still missing the most important one ... the fix to the ChangeXML ... > implementing adding of elements by having to replace an existing model > element with itself and another one is just plain wrong! It would be great > to have it separated out into: > > AddXML > ChangeXML > RemoveXML > > Or at least have an operation flag on the ChangeXML element! > I was not sure if there was an agreement here for having an "operation" attribute defining the type of change as one of add, delete, replace? Dagmar |
|
From: Richard A. <ra...@st...> - 2010-06-09 15:50:21
|
Marginally prefer different elements as gives more scope for future enhancements, and agree XPath should be parent element. Richard > On 09/06/10 16:43, Frank Bergmann wrote: >>> >>> OK, let's go for typing then: addition, deletion and replacement. >> >> Great lets finalize this: do you prefer a flag as in: >> >> <changeXML operation="" [..] /> > > yes > >> Or different elements? >> >> <addXML [..] >> <deleteXML [..] >> <changeXML [..] > > no > >> We should probably also be a bit more precise on the meaning of addition ... >> I suggest, that the xpath target should be the parent element on which to >> add the new xml as a child. Do you agree? > > yes > > -- > 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 > > -- 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-06-09 15:48:39
|
On 09/06/10 16:43, Frank Bergmann wrote: >> >> OK, let's go for typing then: addition, deletion and replacement. > > Great lets finalize this: do you prefer a flag as in: > > <changeXML operation="" [..] /> yes > Or different elements? > > <addXML [..] > <deleteXML [..] > <changeXML [..] no > We should probably also be a bit more precise on the meaning of addition ... > I suggest, that the xpath target should be the parent element on which to > add the new xml as a child. Do you agree? yes -- 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-09 15:44:25
|
> > OK, let's go for typing then: addition, deletion and replacement. Great lets finalize this: do you prefer a flag as in: <changeXML operation="" [..] /> Or different elements? <addXML [..] <deleteXML [..] <changeXML [..] We should probably also be a bit more precise on the meaning of addition ... I suggest, that the xpath target should be the parent element on which to add the new xml as a child. Do you agree? Best Frank > > > -- > 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...(NO > T 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: Dagmar W. <dag...@un...> - 2010-06-09 08:43:59
|
So, would the following solution for language suit everybody? 1) we make the language attribute optional in the specification. If it is not given, it basically says "xml" and it is up to the tool to identify the model format. Also, if you do not care about providing the model format, you just don't define the language. 2) if we want to specify the language, we could have a sub-domain like mechanism, as Nicolas suggested, by having different urns for: urn:sedml:sbml urn:sedml:sbml.level1 urn:sedml:sbml.level2.version2.release2 and similarly urn:sedml:cellml urn:sedml:cellml.1_1 (this would correspond to 1.1, but it seems we cannot have the dot here anyways in the urn, if I got things right) That will allow us to define the language on different granularities. Does that sound ok? Dagmar Nicolas Le novère wrote: > On 08/06/10 19:06, Lucian Smith wrote: > > 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? > > How do-you know if you can parse the language if you do not know which > language you are talking about. I believe there may be the impression > floating around that all languages are like SBML, with all the info in the > header. This is not always the case (even CellML has only a namespace, not > a schemaLocation). But even in that situation, in order to read that > information, you need the definition of the language (you need to know what > are the attributes "level" and "version") > > > 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.) > > That would be true if we were not using the controlled symbols. > > > 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? > > We can either define xml, or use it as the default. > > > * 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: Nicolas Le n. <le...@eb...> - 2010-06-09 08:32:36
|
On 09/06/10 08:52, Lucian Smith wrote: > * Nicolas Le novère<le...@eb...> [2010-06-09 08:44] writes: >> On 08/06/10 19:07, Frank Bergmann wrote: >> >>> I'm still missing the most important one ... the fix to the ChangeXML ... >>> implementing adding of elements by having to replace an existing model >>> element with itself and another one is just plain wrong! >> >> It is not a "fix", and replacing the containing element is not "plain >> wrong". It is just verbose. But we are talking of computers here. verbosity >> is not the main concern. Unambiguity is. We may want to separate the >> semantics of the XPath for addition and removal. But not doing so does not >> break SED-ML. > > I would say that semantically, the current method of adding a new element > to a file is indeed wrong, because you must replace the element just > before it with itself plus a new element. That is not what we do. We replace: <x> <y /> </x> by <x> <y /> <z /> </x> > What if you wanted to add an > AssignmentRule to a model that had no AssignmentRules? You replace the > RateRules with the exact same set of RateRules, plus a new set of > AssignmentRules? That's just weird. Adding 'add' is a clear semantic > fix. Yes. It is not weird. It is verbose. To bring you some ammunitions, it gets REALLY verbose if you do not have rules at all, because then you would have to replace the model element ... OK, let's go for typing then: addition, deletion and replacement. -- 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: Nicolas Le n. <le...@eb...> - 2010-06-09 08:18:08
|
Actually I was wrong, we should not do that. Names are optional. And we do not want to put mandatory names just on dataGenerators, because in the future, we will most probably have intermediate generator used to produce complex data. We need a mandatory attribute. On 09/06/10 08:37, Nicolas Le novère wrote: > On 08/06/10 19:07, Frank Bergmann wrote: >> Thanks for following up on this ... here some comments: >> >>> - included a *label *attribute in each the curve, surface and dataset >>> elements (optional) >> >> I'm still not sure why we had to have a label attribute. What is the added >> advantage of using it? Why could we not just use the name property of the >> data generator? > > We could. But we must put it explicitely in the spec then. There must be an > identification of the 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: Lucian S. <lp...@sp...> - 2010-06-09 07:52:49
|
* Nicolas Le novère <le...@eb...> [2010-06-09 08:44] writes: > On 08/06/10 19:07, Frank Bergmann wrote: > > > I'm still missing the most important one ... the fix to the ChangeXML ... > > implementing adding of elements by having to replace an existing model > > element with itself and another one is just plain wrong! > > It is not a "fix", and replacing the containing element is not "plain > wrong". It is just verbose. But we are talking of computers here. verbosity > is not the main concern. Unambiguity is. We may want to separate the > semantics of the XPath for addition and removal. But not doing so does not > break SED-ML. I would say that semantically, the current method of adding a new element to a file is indeed wrong, because you must replace the element just before it with itself plus a new element. What if you wanted to add an AssignmentRule to a model that had no AssignmentRules? You replace the RateRules with the exact same set of RateRules, plus a new set of AssignmentRules? That's just weird. Adding 'add' is a clear semantic fix. -Lucian |
|
From: Nicolas Le n. <le...@eb...> - 2010-06-09 07:43:45
|
On 08/06/10 19:07, Frank Bergmann wrote: > I'm still missing the most important one ... the fix to the ChangeXML ... > implementing adding of elements by having to replace an existing model > element with itself and another one is just plain wrong! It is not a "fix", and replacing the containing element is not "plain wrong". It is just verbose. But we are talking of computers here. verbosity is not the main concern. Unambiguity is. We may want to separate the semantics of the XPath for addition and removal. But not doing so does not break SED-ML. > It would be great > to have it separated out into: > AddXML > ChangeXML > RemoveXML > > Or at least have an operation flag on the ChangeXML element! I would put a flag then, please. -- 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: Nicolas Le n. <le...@eb...> - 2010-06-09 07:40:17
|
I agree. We only want one algorithm per simulation. On 08/06/10 19:07, Frank Bergmann wrote: >> - 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. >> > > Ok .. this is a bigger change than I wanted it to be! I was fine with > agreeing to have algorithm be an element, so that we could have it annotated > later on with all the properties that we would want to set on it. But a list > of algorithms really? Why do we need that? Would these be mutually > exclusive? Or what should we do if we list: > > Forward Euler, > Runge Kutta, > CVODE, > Gillespie > > This no longer allows me to distinguish whether I should carry out a > discrete or continuous simulation. (Or this is actually a specification of a > certain hybrid algorithm. But even then, that algorithm should have its own > description! And again only one algorithm would need to be referenced ) -- 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: Nicolas Le n. <le...@eb...> - 2010-06-09 07:38:00
|
On 08/06/10 19:07, Frank Bergmann wrote: > Thanks for following up on this ... here some comments: > >> - included a *label *attribute in each the curve, surface and dataset >> elements (optional) > > I'm still not sure why we had to have a label attribute. What is the added > advantage of using it? Why could we not just use the name property of the > data generator? We could. But we must put it explicitely in the spec then. There must be an identification of the 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: Nicolas Le n. <le...@eb...> - 2010-06-09 07:33:22
|
On 08/06/10 19:06, Lucian Smith wrote: > 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? How do-you know if you can parse the language if you do not know which language you are talking about. I believe there may be the impression floating around that all languages are like SBML, with all the info in the header. This is not always the case (even CellML has only a namespace, not a schemaLocation). But even in that situation, in order to read that information, you need the definition of the language (you need to know what are the attributes "level" and "version") > 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.) That would be true if we were not using the controlled symbols. > 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? We can either define xml, or use it as the default. > * 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 -- 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 21:36:08
|
> So say for SBML, level 3 has 'localParameter' elements in kinetic laws which > are I believe new in level 3. > If I have a SEDML file that has some changeXML elements to apply to a > model in level 2 version 4, which change the values of parameters in a > kinetic law, the XPath expression to apply the change will have to be > different depending on whether the retrieved model is level 2v4 or level 3. > In this case, the SEDML file is tied to a particular SBML version (unless we > introduce into SEDML some concept of alternative changeXML elements for > different model versions). > I think this is pretty much an issue on how you implement the changeXML bit. I could very well envision being able to successfully apply a changeXML term that applies to a l2v4 model to an l2v3 model or such. As soon as you resolved the first model you know its level and version, you also know thanks to the changeXML namespaces your target namespace, and conversion routines between those levels and versions exist. So I think this might be an implementation detail ... so I would argue it is not strictly necessary ... Best Frank > > Cheers > Richard > > > > 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:dagmar.waltemath@uni- > rostock.de] > >>>>> 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 > > > > > > > > ---------------------------------------------------------------------- > > -------- 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 > > > > > > > > -- > 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. > > > > ---------------------------------------------------------------------------- -- > 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: Richard A. <ra...@st...> - 2010-06-08 20:12:39
|
So say for SBML, level 3 has 'localParameter' elements in kinetic laws which are I believe new in level 3. If I have a SEDML file that has some changeXML elements to apply to a model in level 2 version 4, which change the values of parameters in a kinetic law, the XPath expression to apply the change will have to be different depending on whether the retrieved model is level 2v4 or level 3. In this case, the SEDML file is tied to a particular SBML version (unless we introduce into SEDML some concept of alternative changeXML elements for different model versions). So if we're not in control of the model (e.g., we're accessing it from a remote repository), then it seems we have to have some idea of what version of a model the SEDML file applies to. Cheers Richard > 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 > > -- 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: Frank B. <fbergman@u.washington.edu> - 2010-06-08 18:12:32
|
Thanks for following up on this ... here some comments: > - included a *label *attribute in each the curve, surface and dataset > elements (optional) I'm still not sure why we had to have a label attribute. What is the added advantage of using it? Why could we not just use the name property of the data generator? > - 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. > Ok .. this is a bigger change than I wanted it to be! I was fine with agreeing to have algorithm be an element, so that we could have it annotated later on with all the properties that we would want to set on it. But a list of algorithms really? Why do we need that? Would these be mutually exclusive? Or what should we do if we list: Forward Euler, Runge Kutta, CVODE, Gillespie This no longer allows me to distinguish whether I should carry out a discrete or continuous simulation. (Or this is actually a specification of a certain hybrid algorithm. But even then, that algorithm should have its own description! And again only one algorithm would need to be referenced ) > 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 :-) > I'm still missing the most important one ... the fix to the ChangeXML ... implementing adding of elements by having to replace an existing model element with itself and another one is just plain wrong! It would be great to have it separated out into: AddXML ChangeXML RemoveXML Or at least have an operation flag on the ChangeXML element! Cheers Frank > Best, > 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 |
14 messages has been excluded from this view by a project administrator.
