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: Frank B. <fbergman@u.washington.edu> - 2009-01-30 18:04:16
|
> > I set up a Wiki page to collect all the open questions/issues for the > workshop day in April: > http://miase.wiki.sourceforge.net/OpenIssues > Remind me if I forget things, please. > Do you want us to contribute to it? Otherwise here my list of open issues: - storage format - what math is allowed in the math for datagenerators (or ChangeMath) - how to refer to the time symbol And then of course for later: - 'AnySimulation' - how to refer to measurement data - K I S A O and what it means for the specified Simulations - Cheers Frank > Have a nice weekend everybody, > Dagmar > > ----------------------------------------------------------------------- > ------- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Miase-discuss mailing list > Mia...@li... > https://lists.sourceforge.net/lists/listinfo/miase-discuss |
|
From: Frank B. <fbergman@u.washington.edu> - 2009-01-30 17:45:30
|
> they are optional - one of the references is for use of the variable > element in ChangeMath, the other one is for use of the variable element > in Task and DataGenerator... Except they are not both optional, they are mutual exclusive ... > ... or we could check whether we want to go back to using > modelReferences in the DataGenerator class instead of using the > taskReference - which I would prefer. As Nicolas was describing, (and I should have remembered from the discussions), the taskReference is vital for DataGenerators, so that we can refer to the transient values, with the model reference we would only record the initial value. So we will have to fork them ... but again, this can wait until concrete examples about ChangeMath have been put into play ... > > Dagmar > > ----------------------------------------------------------------------- > ------- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Miase-discuss mailing list > Mia...@li... > https://lists.sourceforge.net/lists/listinfo/miase-discuss |
|
From: Dagmar K. <da...@eb...> - 2009-01-30 16:15:23
|
Hej, changes are: 1) The <parameter> element is of type=xs:double (instead of xs:string) 2) Inheritance of curve attributes in the <surface> element in the XSD now corresponds to the UML. @Frank: Did you find more inconsistencies? I could only think of problems with the Output/Simulation/Change classes, but those do not appear in the Schema at all which is fine as they are abstract. Changes are in sed-ml-tmp.xsd on SF. On my todo list of things to fix there still is the variable/parameter issue and everything connected to it (optionality in the schema ...), as well as the annotation/ChangeXML type. I set up a Wiki page to collect all the open questions/issues for the workshop day in April: http://miase.wiki.sourceforge.net/OpenIssues Remind me if I forget things, please. Have a nice weekend everybody, Dagmar |
|
From: Dagmar K. <da...@eb...> - 2009-01-30 13:32:56
|
I put a note to discuss the changeAttribute type issue and the re-naming of modification types issue during the workshop. Dagmar Frank Bergmann wrote: >> ? The two variable glyphs carry the same attribute. But we nevertheless >> need to fork them. For parameter, we should rewrite the UML with only >> one glyph. >> >> > > (I counted taskReference / modelReference as attributes) > > >>>>> - changeAttribute: newValue should be of type xs:double >>>>> >>>> Not sure, could I - for example - change >>>> >>>> <listOfProducts> >>>> <speciesReference species="PZ"/> >>>> >>>> the species (XML) attribute "PZ" to some other species, e.g. to >>>> >> change >> >>>> the product in a reaction? Could that make sense? Or would we >>>> >> consider >> >>>> that as a completely different model then? >>>> >>> right ... you actually could do that ... this does worry me a bit ... >>> i'd much rather that people would swap out whole reactions than >>> >> fiddle >> >>> with products like that ... this seems like a sure way to create >>> >> invalid >> >>> models ... no xs:double here then :) >>> >> I am with Frank here. This worries me a little as well. And actually, I >> remember that at one time changeAttribute was not called >> changeAttribute but changeValue. It could only change a numerical >> value. Then it became changeAttribute, which is actually a bit >> confusing with changeXML as well. >> >> > > I've double checked my implementation, and indeed I did use string for > precisely the reason, that you might want to change some other attributes. > Here Xpath gives us all the freedom we want, or enough rope to hang > ourselves with. We could use it to set any attribute, like sbml Id, boundary > conditions, constant flags, relocate species and more. The problem with this > is that it might work fine for one model and cause lots of problems for > another model, partly because of for example default values in SBML (and I > know this is remedied by level 3). > > Lets create some examples first before changing the proposal, if we can come > up with a valid (and useful) case for keeping non-numerical values, then > perhaps it is worth keeping them. > > >> To remove the problem and tackle the other confusions, what about >> renaming the three "modification types": >> >> changeValue >> >> replaceXML >> >> computeValue >> >> > > Let us postpone renaming the types until we find more examples. > > Best > Frank > > > |
|
From: Dagmar K. <da...@eb...> - 2009-01-30 13:23:58
|
Frank Bergmann wrote: >> ? The two variable glyphs carry the same attribute. But we nevertheless >> need to fork them. For parameter, we should rewrite the UML with only >> one glyph. >> >> > > (I counted taskReference / modelReference as attributes) > OK, Frank is right here (talking about the XSD attributes). In the UML, the 2 classes "Variable" are identical, but in the Schema one global type for the Variable class was created. In the XSD, both the taskReference and the modelReference have to be added to the variable global type... which also answers the question why they are optional - one of the references is for use of the variable element in ChangeMath, the other one is for use of the variable element in Task and DataGenerator... ... which is why Nicolas probably is right saying that we have to fork them ... or we could check whether we want to go back to using modelReferences in the DataGenerator class instead of using the taskReference - which I would prefer. Dagmar |
|
From: Frank B. <fbergman@u.washington.edu> - 2009-01-29 20:03:44
|
Hello all, I know I have been nagging about examples recently. So I thought it only fair to contribute some as well: Examples: ========= sedMLBIOM21: - just like before, however now it also includes another data generator, that takes the difference of v1-v2 and adds 20 ... just to have some mathml EllowitzRepressilator.miase: - runs the repressilator and displays floating species Brusselator.miase: - runs the brusselator, displays time series and phase plot Lorenz.miase: - runs a model of the Lorenz attractor, and generates 4 plots. In order not to tax your mail too much, I won't attach screenshots but show you a screencast instead: http://screencast.com/t/XG9DDycH Prototype: ========== In order to test these Examples you are welcome to test a first web application, that will take a Sed-ML document with remote sources (i.e: sedMLBIOM21.xml) and execute it, or a .miase file, (as I dubbed the zip file including Sed-ML and all local sources). In order to help you create new *valid* examples you can also upload an SBML file, specify uniform-time course parameters, output species / parameters, and plot parameters. After that you will be able to download either Sed-ML, or .miase file, which you can then easily modify for more complicated examples. http://128.208.19.37/MIASETest/ The machine will not be always available, so please bear with me :) What is not in the prototype: ============================= - no ChangeXML / ChangeMath - no Reports (I just did not know where to put them) - no 3D plots - limited support for post processing in data generators (I'm not quite sure what Subset of math-ml is allowed here). - the prototype does not write any attributes on the sedML node (not sure whether the version attribute as it is now will survive). Known issues: ============= - Web Application does not give error messages, if you see an empty plot that is and indication that things went wrong - algorithm attribute on uniformTimeCourse will not be evaluated, the model will always simulated with roadRunner ... I'll add an option to set tolerances for the integrator soon - TIME: ... the exported time variable will be referred to as: <dataGenerator id="time1" name="time"> <listOfVariables> <variable id="time" taskReference="task1" target="time" /> </listOfVariables><math xmlns="http://www.w3.org/1998/Math/MathML"> <ci> time </ci> </math></dataGenerator> - XPATH: I will only support Xpath 1.0 for now, thus the queries should prefix the - .miase file: the .miase file generated could not be extracted by my mac without 7zip, Error message on OSX unzip is "need PK compat. v4.5 (can do v2.1)" p7zip works fine .miase file =========== As said before, for me it is of limited interest to always access remote sources, and embedding was taken off the table. On the other hand I don't want local sources get out of sync with the description. Thus my library sticks all local sources (and optionally all remote ones too) into a zipfile with name X.miase, inside that file it takes X.xml to be the Sed-ML description. If we could decide on this as the standard way to do it that would be fine with me, or we could decide on writing a manifest with the name of the Sed-ML file as well ... I'd be interested in resolving this :) So far from me, please let me know your comments. Best Frank P.S: If anyone is interested in the C# library to read MIASE files, or the sister-library to run them, let me know. |
|
From: Frank B. <fbergman@u.washington.edu> - 2009-01-29 18:34:17
|
> > ? The two variable glyphs carry the same attribute. But we nevertheless > need to fork them. For parameter, we should rewrite the UML with only > one glyph. > (I counted taskReference / modelReference as attributes) > >>> - changeAttribute: newValue should be of type xs:double > >> Not sure, could I - for example - change > >> > >> <listOfProducts> > >> <speciesReference species="PZ"/> > >> > >> the species (XML) attribute "PZ" to some other species, e.g. to > change > >> the product in a reaction? Could that make sense? Or would we > consider > >> that as a completely different model then? > > > > right ... you actually could do that ... this does worry me a bit ... > > i'd much rather that people would swap out whole reactions than > fiddle > > with products like that ... this seems like a sure way to create > invalid > > models ... no xs:double here then :) > > I am with Frank here. This worries me a little as well. And actually, I > remember that at one time changeAttribute was not called > changeAttribute but changeValue. It could only change a numerical > value. Then it became changeAttribute, which is actually a bit > confusing with changeXML as well. > I've double checked my implementation, and indeed I did use string for precisely the reason, that you might want to change some other attributes. Here Xpath gives us all the freedom we want, or enough rope to hang ourselves with. We could use it to set any attribute, like sbml Id, boundary conditions, constant flags, relocate species and more. The problem with this is that it might work fine for one model and cause lots of problems for another model, partly because of for example default values in SBML (and I know this is remedied by level 3). Lets create some examples first before changing the proposal, if we can come up with a valid (and useful) case for keeping non-numerical values, then perhaps it is worth keeping them. > To remove the problem and tackle the other confusions, what about > renaming the three "modification types": > > changeValue > > replaceXML > > computeValue > Let us postpone renaming the types until we find more examples. 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... > http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ > > ----------------------------------------------------------------------- > ------- > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Miase-discuss mailing list > Mia...@li... > https://lists.sourceforge.net/lists/listinfo/miase-discuss |
|
From: Dagmar K. <da...@eb...> - 2009-01-29 13:21:54
|
thanks, the paper link on the web page works now. dagmar @frank : this is rather off listm but i am "explicitly prohibited by sender's published policy " to send you e-mails. anything i can do against it ;) Frank Bergmann wrote: > Hello Dagmar, > > not sure whether you are taking care of biomodels.net/sed-ml ... but > the link to the paper was broken ... just thought to let you know > > best > Frank |
|
From: Richard A. <ra...@st...> - 2009-01-29 12:37:10
|
Just to say, from an implementation point of view, all schema changes proposed in 'tmp' schema (svn version 40) are fine, in terms of being able to generate classes, and example files are still valid against the proposed schema. Richard -- Dr Richard Adams Senior Software Developer, Computational Systems Biology Group, University of Edinburgh Tel: 0131 650 8281/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...> - 2009-01-29 08:35:37
|
Frank Bergmann wrote: >> As far as I know UML, two entities with identical names in a UML schema >> represent the same (identical) class. So, in the UML you find two >> "drawings" of parameter/variable classes, but in fact they correspond to >> one "physical" class as they carry identical class names. > > it just looked confusing as Variable at least seemed to have different > attributes ... but I'm certainly no expert using UML ... ? The two variable glyphs carry the same attribute. But we nevertheless need to fork them. For parameter, we should rewrite the UML with only one glyph. >>> - changeAttribute: newValue should be of type xs:double >> Not sure, could I - for example - change >> >> <listOfProducts> >> <speciesReference species="PZ"/> >> >> the species (XML) attribute "PZ" to some other species, e.g. to change >> the product in a reaction? Could that make sense? Or would we consider >> that as a completely different model then? > > right ... you actually could do that ... this does worry me a bit ... > i'd much rather that people would swap out whole reactions than fiddle > with products like that ... this seems like a sure way to create invalid > models ... no xs:double here then :) I am with Frank here. This worries me a little as well. And actually, I remember that at one time changeAttribute was not called changeAttribute but changeValue. It could only change a numerical value. Then it became changeAttribute, which is actually a bit confusing with changeXML as well. PLUS <foo> <value>1</value> </foo> and <foo value="1" /> are identical for some XML parsers .... To remove the problem and tackle the other confusions, what about renaming the three "modification types": changeValue replaceXML computeValue ? -- 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... http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ |
|
From: Nicolas Le N. <le...@eb...> - 2009-01-29 08:26:26
|
Frank Bergmann wrote: > - Variable & Parameter: > > - in the OM it does look like we have two separate variable and > parameter objects, after a look at the schema this is not the case. OM is right, schema is wrong. We could use the same parameter.But the variable classes are in fact different, not in their structure, but in their semantics. We seeked parsimony and elegance. But that translated in confusion. We probably need to change the name of variable classes :-( cf. below > - Of course to make variables work in the ChangeMath case, a variable > now can refer directly to a model, where before we would only refer to > variables based on a taskreference. I'm not exactly sure why we did it > that way. Because in the dataGenerator, the SED-ML variable points to the value of a model's variable *as simulated*. The variable used by changeMath is equivalent to COPASI's initial value while the variable used in dataGenerator is equivalent to COPASI's transient value. > However having these two (possibly different) ways to describe > where a variable comes from seems troublesome to me. If possible we want > to avoid tables in the specification telling people what to use when. I agree. -- 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... http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ |
|
From: Frank B. <fbergman@u.washington.edu> - 2009-01-29 08:13:45
|
> > As far as I know UML, two entities with identical names in a UML > schema > represent the same (identical) class. So, in the UML you find two > "drawings" of parameter/variable classes, but in fact they > correspond to > one "physical" class as they carry identical class names. it just looked confusing as Variable at least seemed to have different attributes ... but I'm certainly no expert using UML ... > > >> >> - Of course to make variables work in the ChangeMath case, a variable >> now can refer directly to a model, where before we would only refer >> to >> variables based on a taskreference. I'm not exactly sure why we did >> it >> that way. However having these two (possibly different) ways to >> describe where a variable comes from seems troublesome to me. If >> possible we want to avoid tables in the specification telling people >> what to use when. (Anyone not feeling pain, just look at the SBML >> specification and Table 5 or how to interpret constant / boundary >> condition). We still have time to sort things out ... or is this a >> non-issue, and it is an error to use modelReferences in variables for >> datagenerator, while using a taskreference is an error for variables >> in ChangeMath. If so they need to be renamed :) ... the schema >> currently lists both as optional, which does not do this situation >> justice :) >> - parameter value type should be xs:double rather than xs:string > > Yes, I think that's what you mentioned before. > I think everybody agreed on changing it to the XML Schema type > xs:double!? > If I don't get any complaints, I'll change it :-) > No skipping over the bigger question please :) > >> - for notes and annotations, which are currently strings, it might be >> nice to use more than simple strings. If I were to use annotations, >> I'd rather use a block of xml ... good news, mike has gone through >> the >> trouble before and the sbml schema has the needed specification: > > Yes, I remember I've had that discussion with Mike. > My idea was to keep the notes/annotations as unrestricted as possible. > But I am sure you're right ;-) the thing is ... the current version with just xs:string is much more restrictive than xsd:any ... > > >> >> <xsd:sequence> >> <xsd:element name="notes" minOccurs="0"> >> <xsd:complexType> >> <xsd:sequence> >> <xsd:any namespace="http://www.w3.org/1999/xhtml >> " >> processContents="skip" >> minOccurs="0" maxOccurs="unbounded"/> >> </xsd:sequence> >> </xsd:complexType> >> </xsd:element> >> <xsd:element name="annotation" minOccurs="0"> >> <xsd:complexType> >> <xsd:sequence> >> <xsd:any processContents="skip" >> minOccurs="0" maxOccurs="unbounded"/> >> </xsd:sequence> >> </xsd:complexType> >> </xsd:element> >> </xsd:sequence> >> >> - for ChangeXML a structure like "annotation" above should be >> used for newValue, rather than xs:string > > I agree. Any comments, otherwise I'd change the data type. thank you > > >> - changeAttribute: newValue should be of type xs:double > Not sure, could I - for example - change > > <listOfProducts> > <speciesReference species="PZ"/> > > the species (XML) attribute "PZ" to some other species, e.g. to change > the product in a reaction? Could that make sense? Or would we consider > that as a completely different model then? right ... you actually could do that ... this does worry me a bit ... i'd much rather that people would swap out whole reactions than fiddle with products like that ... this seems like a sure way to create invalid models ... no xs:double here then :) best Frank |
|
From: Dagmar K. <da...@eb...> - 2009-01-29 07:32:51
|
Hej Frank, We could indeed say we refer to a certain revision of the sedml schema for examples and test implementations, but that probably leads to more confusion than having 2 different files!? Maybe not for you, but for others. Especially when they compare the current versions of the UML/XMLS and PDF which might not always correspond to each other at all times. (At least I thought so.) I couldn't make up my mind between "tmp" and "current" and then thought that tmp was more representing the status of a schema containing not yet fixed changes (while sometimes you have to write them down for others to see whether changes make sense or not). I totally agree we should have an SBML-like structure for versions later on, but inho it would be an overkill for now. So lets move the discussion until we have at least a version 1 ;-) Cheers, Dagmar Frank Bergmann wrote: > Hello, > > here my thoughts on dealing with versioning. Currently, there exists > no official release, as that would hopefully be accompanied by a > comprehensive specification just like the SBML specifications. So I'm > not too keen on naming things sedml-tmp, or sedom-tmp. if it needs to > be anything a suffix as current sounds more promising. > > Until a release, SVN manages successfully to keep track of all > versions, and all revisions can be restored, so there is no need to > rename files. I can refer to: > > http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/documents/schema/sedml-version-0-release-1.xsd?revision=11 > > or > > http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/documents/schema/sedml-version-0-release-1.xsd?revision=23 > > > without problems. So for discussions all is well ... once we agree > versions should be kept and hopefully not modified. usually you find > repositories separated into trunk (current branch), tags and branches > (named versions), which allows to better keep track of current vs past > things. > > As soon as things become stable enough, why not keep them as in the > sbml repository where you find them in directories separated by levels > and versions i.e: > > specifications/sbml-level-2/version-4/schema > > so far my thoughts. > > cheers > Frank > > On Jan 28, 2009, at 7:46 AM, Dagmar Köhn wrote: > > >> Hej all, >> >> I have submitted a new version of the XML Schema on SF as "sedml- >> tmp.xsd". >> For further proposals for corrections of the schema I would suggest to >> use the sedml-tmp.xsd file only. We can then discuss the changes and >> once we agreed on them I can update the "stable" schema. >> >> The same should be done for the UML object model - I have added a >> sedom-tmp.uml/sedom-tmp.pdf file on SF for discussion of changes on >> the >> mailing list. >> >> The "stable" schema is the one called "sedml-version-0-release-1.xsd >> <http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/documents/schema/sedml-version-0-release-1.xsd?view=log >> >>> " >>> >> and it should correspond to the CMSB paper and the current UML model >> on >> SF [The schema does at the moment not correspond to the UML, but I >> work >> on fixing that!]. >> >> >> Any disagreements or better suggestions how to handle the different >> versions are very welcome. >> Please let me know. >> >> Dagmar >> >> ------------------------------------------------------------------------------ >> This SF.net email is sponsored by: >> SourcForge Community >> SourceForge wants to tell your story. >> http://p.sf.net/sfu/sf-spreadtheword >> _______________________________________________ >> Miase-discuss mailing list >> Mia...@li... >> https://lists.sourceforge.net/lists/listinfo/miase-discuss >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Miase-discuss mailing list > Mia...@li... > https://lists.sourceforge.net/lists/listinfo/miase-discuss > |
|
From: Dagmar K. <da...@eb...> - 2009-01-29 07:24:55
|
Hej Frank, thanks a lot for your comments! Some answers... Frank Bergmann wrote: > Apart from validation, i rarely look at schema files. For my purposes > looking at the PDFs of the OM is more productive. So first of all > thank you for keeping them in sync. There are however some issues that > need addressing: > > - Variable & Parameter: > > - in the OM it does look like we have two separate variable and > parameter objects, after a look at the schema this is not the case. As far as I know UML, two entities with identical names in a UML schema represent the same (identical) class. So, in the UML you find two "drawings" of parameter/variable classes, but in fact they correspond to one "physical" class as they carry identical class names. > > - Of course to make variables work in the ChangeMath case, a variable > now can refer directly to a model, where before we would only refer to > variables based on a taskreference. I'm not exactly sure why we did it > that way. However having these two (possibly different) ways to > describe where a variable comes from seems troublesome to me. If > possible we want to avoid tables in the specification telling people > what to use when. (Anyone not feeling pain, just look at the SBML > specification and Table 5 or how to interpret constant / boundary > condition). We still have time to sort things out ... or is this a > non-issue, and it is an error to use modelReferences in variables for > datagenerator, while using a taskreference is an error for variables > in ChangeMath. If so they need to be renamed :) ... the schema > currently lists both as optional, which does not do this situation > justice :) > - parameter value type should be xs:double rather than xs:string Yes, I think that's what you mentioned before. I think everybody agreed on changing it to the XML Schema type xs:double!? If I don't get any complaints, I'll change it :-) > > - Other things I've noted with the schema: > > - Inheritances differ in OM and schema, see for example curve and > surface. Have to check. > - for notes and annotations, which are currently strings, it might be > nice to use more than simple strings. If I were to use annotations, > I'd rather use a block of xml ... good news, mike has gone through the > trouble before and the sbml schema has the needed specification: Yes, I remember I've had that discussion with Mike. My idea was to keep the notes/annotations as unrestricted as possible. But I am sure you're right ;-) > > <xsd:sequence> > <xsd:element name="notes" minOccurs="0"> > <xsd:complexType> > <xsd:sequence> > <xsd:any namespace="http://www.w3.org/1999/xhtml" > processContents="skip" > minOccurs="0" maxOccurs="unbounded"/> > </xsd:sequence> > </xsd:complexType> > </xsd:element> > <xsd:element name="annotation" minOccurs="0"> > <xsd:complexType> > <xsd:sequence> > <xsd:any processContents="skip" > minOccurs="0" maxOccurs="unbounded"/> > </xsd:sequence> > </xsd:complexType> > </xsd:element> > </xsd:sequence> > > - for ChangeXML a structure like "annotation" above should be used for newValue, rather than xs:string I agree. Any comments, otherwise I'd change the data type. > - changeAttribute: newValue should be of type xs:double Not sure, could I - for example - change <listOfProducts> <speciesReference species="PZ"/> the species (XML) attribute "PZ" to some other species, e.g. to change the product in a reaction? Could that make sense? Or would we consider that as a completely different model then? > That's all i could find for now .... Thanks again! Dagmar > _______________________________________________ > Miase-discuss mailing list > Mia...@li... > https://lists.sourceforge.net/lists/listinfo/miase-discuss > |
|
From: Frank B. <fbergman@u.washington.edu> - 2009-01-29 04:40:38
|
Apart from validation, i rarely look at schema files. For my purposes
looking at the PDFs of the OM is more productive. So first of all
thank you for keeping them in sync. There are however some issues that
need addressing:
- Variable & Parameter:
- in the OM it does look like we have two separate variable and
parameter objects, after a look at the schema this is not the case.
- Of course to make variables work in the ChangeMath case, a variable
now can refer directly to a model, where before we would only refer to
variables based on a taskreference. I'm not exactly sure why we did it
that way. However having these two (possibly different) ways to
describe where a variable comes from seems troublesome to me. If
possible we want to avoid tables in the specification telling people
what to use when. (Anyone not feeling pain, just look at the SBML
specification and Table 5 or how to interpret constant / boundary
condition). We still have time to sort things out ... or is this a non-
issue, and it is an error to use modelReferences in variables for
datagenerator, while using a taskreference is an error for variables
in ChangeMath. If so they need to be renamed :) ... the schema
currently lists both as optional, which does not do this situation
justice :)
- parameter value type should be xs:double rather than xs:string
- Other things I've noted with the schema:
- Inheritances differ in OM and schema, see for example curve and
surface.
- for notes and annotations, which are currently strings, it might be
nice to use more than simple strings. If I were to use annotations,
I'd rather use a block of xml ... good news, mike has gone through the
trouble before and the sbml schema has the needed specification:
<xsd:sequence>
<xsd:element name="notes" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:any namespace="http://www.w3.org/1999/xhtml
"
processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="annotation" minOccurs="0">
<xsd:complexType>
<xsd:sequence>
<xsd:any processContents="skip"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:sequence>
- for ChangeXML a structure like "annotation" above should be used
for newValue, rather than xs:string
- changeAttribute: newValue should be of type xs:double
That's all i could find for now ....
cheers
Frank
On Jan 28, 2009, at 7:46 AM, Dagmar Köhn wrote:
> Hej Richard (and everybody),
>
> I have changed the XML schema so as notes/annotations are now
> applicable
> to all schema elements.
> All complex types are now extensions of the SED-Base type.
>
> /Dagmar
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by:
> SourcForge Community
> SourceForge wants to tell your story.
> http://p.sf.net/sfu/sf-spreadtheword
> _______________________________________________
> Miase-discuss mailing list
> Mia...@li...
> https://lists.sourceforge.net/lists/listinfo/miase-discuss
|
|
From: Frank B. <fbergman@u.washington.edu> - 2009-01-29 03:05:00
|
Hello, here my thoughts on dealing with versioning. Currently, there exists no official release, as that would hopefully be accompanied by a comprehensive specification just like the SBML specifications. So I'm not too keen on naming things sedml-tmp, or sedom-tmp. if it needs to be anything a suffix as current sounds more promising. Until a release, SVN manages successfully to keep track of all versions, and all revisions can be restored, so there is no need to rename files. I can refer to: http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/documents/schema/sedml-version-0-release-1.xsd?revision=11 or http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/documents/schema/sedml-version-0-release-1.xsd?revision=23 without problems. So for discussions all is well ... once we agree versions should be kept and hopefully not modified. usually you find repositories separated into trunk (current branch), tags and branches (named versions), which allows to better keep track of current vs past things. As soon as things become stable enough, why not keep them as in the sbml repository where you find them in directories separated by levels and versions i.e: specifications/sbml-level-2/version-4/schema so far my thoughts. cheers Frank On Jan 28, 2009, at 7:46 AM, Dagmar Köhn wrote: > Hej all, > > I have submitted a new version of the XML Schema on SF as "sedml- > tmp.xsd". > For further proposals for corrections of the schema I would suggest to > use the sedml-tmp.xsd file only. We can then discuss the changes and > once we agreed on them I can update the "stable" schema. > > The same should be done for the UML object model - I have added a > sedom-tmp.uml/sedom-tmp.pdf file on SF for discussion of changes on > the > mailing list. > > The "stable" schema is the one called "sedml-version-0-release-1.xsd > <http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/documents/schema/sedml-version-0-release-1.xsd?view=log > >" > and it should correspond to the CMSB paper and the current UML model > on > SF [The schema does at the moment not correspond to the UML, but I > work > on fixing that!]. > > > Any disagreements or better suggestions how to handle the different > versions are very welcome. > Please let me know. > > Dagmar > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: > SourcForge Community > SourceForge wants to tell your story. > http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ > Miase-discuss mailing list > Mia...@li... > https://lists.sourceforge.net/lists/listinfo/miase-discuss |
|
From: Dagmar K. <da...@eb...> - 2009-01-28 15:47:11
|
Hej Richard (and everybody), I have changed the XML schema so as notes/annotations are now applicable to all schema elements. All complex types are now extensions of the SED-Base type. /Dagmar |
|
From: Dagmar K. <da...@eb...> - 2009-01-28 15:46:58
|
Hej all, I have submitted a new version of the XML Schema on SF as "sedml-tmp.xsd". For further proposals for corrections of the schema I would suggest to use the sedml-tmp.xsd file only. We can then discuss the changes and once we agreed on them I can update the "stable" schema. The same should be done for the UML object model - I have added a sedom-tmp.uml/sedom-tmp.pdf file on SF for discussion of changes on the mailing list. The "stable" schema is the one called "sedml-version-0-release-1.xsd <http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/documents/schema/sedml-version-0-release-1.xsd?view=log>" and it should correspond to the CMSB paper and the current UML model on SF [The schema does at the moment not correspond to the UML, but I work on fixing that!]. Any disagreements or better suggestions how to handle the different versions are very welcome. Please let me know. Dagmar |
|
From: Nicolas Le n. <le...@eb...> - 2009-01-27 23:47:10
|
Frank Bergmann wrote: >> ChangeMath COMPUTES a change. For instance, you can compute the new >> value for an attribute of model A based on the value of an attribute >> of model B and an external parameter. Therefore the listOfVariables >> use an XPath. > > I remember a post about this from way back. I still don't quite > follow. An example here would really help. To me it seems like this is > an added complication we don't need. The complication was the reason why it was in white and not blue, and YES, I know everything is yellow in the last UML. > At the time of writing, the tool > writing the ChangeMath will have to know about model B and the > external parameter, hence this could be written as > <changeAttribute ... sparing the reader the complications, of sorting > out the math, resolving the model it belongs to (which again might be > in a model format, the reader does not understand) That removes one of the potential roles of SED-ML, which is the integration of different models, developed by different people. I understand what you say in the case of COPASI or RoadRunner exporting a SED-ML file. Now, imagine a large-scale project, similar in size to the metabolic network we published in August (33 authors, 2152 species, 1857 reactions), and some subgroups are in charge of the metabolism, some of the signalling. Phosphorylation in the signalling models depends on ATP, decided by the metabolic models. The consortium can write generic SED-ML files, that can be immune of changes in the initial concentration in ATP, set by the metabolic guys. But I agree with you. If you can use ChangeAttribute or ChangeXML, use them. But in the future there will be need of computing. Let's keep it "white" until we need it (which may come with parameter scans) -- 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... http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ |
|
From: Frank B. <fbergman@u.washington.edu> - 2009-01-27 22:54:19
|
> >> Other changes do require discussion, as I'm not quite sure what to >> do with >> them: >> >> Previously logX and logY were properties of a Plot2D, as facility of >> creating a log plot. In the current version those attributes are now >> properties of the *individual* curves of the plot. Is this really >> necessary? > > Yes, we found examples where curves with linear and log Y where > plotted together. >> Does it make sense to paint those together? And what is supposed to >> be on >> the axis, the logged values or the uhm not-logged ones? > > You have plenty of plots with several axis, for instance on the left > and on the right. > It just felt like this would make the live of everyone implementing the spec much harder :) Also the same effect could be easily achieved by separate plots overlaid. Remember the plot is not fully annotated, as we don't use axis labels. And so it might be hard on readers of such graphs as well. Could you link to some examples? Just to get a better picture. >> Or previously we had Parameter values defined as real-numbered >> values, now >> they are strings. > > I do not remember when this happened, and actually did not notice. I > find this odd and I agree we should discuss it. > In that case I'm all in favor of using real-numbered values as parameters :) >> Finally some of the classes that were previously under discussion, >> hence >> marked white are now no longer marked. > > It is just a coloring trick I believe. > > >> I.e: ChangeMath, here I'm not sure what the list of variables, or >> list of parameters would be? I thought this would be a special case >> of >> changeXML, where I just swap out one snippet of MathML by another >> one. But I >> would not know what to do with variables and parameters in that case. > > This is a big misunderstanding. ChangeXML is used to replace a piece > of the model by something else. One can replace the value of an > attribute, or an element etc. > that much seems clear > ChangeMath COMPUTES a change. For instance, you can compute the new > value for an attribute of model A based on the value of an attribute > of model B and an external parameter. Therefore the listOfVariables > use an XPath. I remember a post about this from way back. I still don't quite follow. An example here would really help. To me it seems like this is an added complication we don't need. At the time of writing, the tool writing the ChangeMath will have to know about model B and the external parameter, hence this could be written as <changeAttribute ... sparing the reader the complications, of sorting out the math, resolving the model it belongs to (which again might be in a model format, the reader does not understand) best Frank |
|
From: Nicolas Le n. <le...@eb...> - 2009-01-27 09:39:05
|
Just a precision: The changes mentioned by Frank are not due to a recent inconsistency between OM and schema. All those changes where already present in the SVN repository as far as 5 month ago. Until we have a formal specification (SBML-like) the authoritative public source should probably be the description given at CMSB: http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/documents/publications/Koehn-CMSB2008.pdf and the most recent version is (should be) at: http://miase.svn.sourceforge.net/viewvc/miase/sed-ml/documents/sed-om/ At the moment they are in sync. Cheers Dagmar Köhn wrote: > Dear all, > > concerning the mess with the OM and the XMLS. It is my fault that they > are not coherent, I didn't update the OM during the last time (although > it should have been compliant with the paper). As we are changing the > Schema back and forth, it felt a bit "useless" to do the same with the > OM, but I understand the big confusion now. > > We are currently trying to solve the problem by writing a UML2XMLS > converter that hopefully takes the OM in UML2 and produces updated > versions of the SED-ML XMLS. Hope to have that running until April so > that we can make changes more easily during the workshop. > > I'd suggest to make the post-workshop version of both SED-ML XMLS and > UML2 a first official one for people to securely refer to!? Until then, > as Nicolas said, the schema versions should be considered unstable > versions open for discussion. > > Dagmar > > > Nicolas Le Novere wrote: >> Frank Bergmann wrote: >> >> >>> I've had another look at the OM + example. As it turns out it has >>> changed in some places from what we initially discussed. If possible >>> I'd rather like to discuss changes on this list first, before they >>> get taken as granted. Some of the changes have been renaming of >>> attributes. Those are breaking changes for all of us with working >>> prototypes and deserve to be discussed: >>> >>> >> Frank, >> >> I am deeply sorry. This comes from the unfortunate fact that during >> half a year, the OM on Sourceforge was not updated. Those changes were >> largely discussed, sometimes on the list, sometimes on more restricted >> discussion. Most of them date back to the time of CCB in March 2008. >> They were all present in the report on SED-ML we made for CMSB08 last >> October (attached), that has been available since the summer for >> instance from the project webpage. >> >> The problem is that SED-ML is not yet stable, and therefore there is >> not a precise date that corresponds to a given version of the OM. That >> is indeed a big mess, and we will change that ASAP by setting a >> numbering system. >> >> >>> - i.e: XPath -> target, or listOfColumns -> listOfDataSets ... >>> >> Those where early changes. The XPath is the value of the attribute. >> Its meaning is a target. It would be like calling the attribute id >> "string". ListOfColumns implied a specific disposition in space rather >> than a type of information. >> >> >>> Other changes do require discussion, as I'm not quite sure what to >>> do with them: >>> >>> Previously logX and logY were properties of a Plot2D, as facility of >>> creating a log plot. In the current version those attributes are >>> now properties of the *individual* curves of the plot. Is this >>> really necessary? >>> >> Yes, we found examples where curves with linear and log Y where >> plotted together. >> >> >>> Does it make sense to paint those together? And what is supposed to >>> be on the axis, the logged values or the uhm not-logged ones? >>> >> You have plenty of plots with several axis, for instance on the left >> and on the right. >> >> >>> Or previously we had Parameter values defined as real-numbered >>> values, now they are strings. >>> >> I do not remember when this happened, and actually did not notice. I >> find this odd and I agree we should discuss it. >> >> >>> Finally some of the classes that were previously under discussion, >>> hence marked white are now no longer marked. >>> >> It is just a coloring trick I believe. >> >> >>> I.e: ChangeMath, here I'm not sure what the list of variables, or >>> list of parameters would be? I thought this would be a special case >>> of changeXML, where I just swap out one snippet of MathML by another >>> one. But I would not know what to do with variables and parameters >>> in that case. >>> >> This is a big misunderstanding. ChangeXML is used to replace a piece >> of the model by something else. One can replace the value of an >> attribute, or an element etc. >> >> ChangeMath COMPUTES a change. For instance, you can compute the new >> value for an attribute of model A based on the value of an attribute >> of model B and an external parameter. Therefore the listOfVariables >> use an XPath. >> >> > > > ------------------------------------------------------------------------------ > This SF.net email is sponsored by: SourcForge Community SourceForge > wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword > _______________________________________________ Miase-discuss mailing > list Mia...@li... > https://lists.sourceforge.net/lists/listinfo/miase-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... http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ |
|
From: Dagmar K. <da...@eb...> - 2009-01-27 08:51:28
|
Dear all, concerning the mess with the OM and the XMLS. It is my fault that they are not coherent, I didn't update the OM during the last time (although it should have been compliant with the paper). As we are changing the Schema back and forth, it felt a bit "useless" to do the same with the OM, but I understand the big confusion now. We are currently trying to solve the problem by writing a UML2XMLS converter that hopefully takes the OM in UML2 and produces updated versions of the SED-ML XMLS. Hope to have that running until April so that we can make changes more easily during the workshop. I'd suggest to make the post-workshop version of both SED-ML XMLS and UML2 a first official one for people to securely refer to!? Until then, as Nicolas said, the schema versions should be considered unstable versions open for discussion. Dagmar Nicolas Le Novere wrote: > Frank Bergmann wrote: > > >> I've had another look at the OM + example. As it turns out it has changed in >> some places from what we initially discussed. If possible I'd rather like to >> discuss changes on this list first, before they get taken as granted. Some >> of the changes have been renaming of attributes. Those are breaking changes >> for all of us with working prototypes and deserve to be discussed: >> >> > > Frank, > > I am deeply sorry. This comes from the unfortunate fact that during half a year, the OM on Sourceforge was not updated. Those changes were largely discussed, sometimes on the list, sometimes on more restricted discussion. Most of them date back to the time of CCB in March 2008. They were all present in the report on SED-ML we made for CMSB08 last October (attached), that has been available since the summer for instance from the project webpage. > > The problem is that SED-ML is not yet stable, and therefore there is not a precise date that corresponds to a given version of the OM. That is indeed a big mess, and we will change that ASAP by setting a numbering system. > > >> - i.e: XPath -> target, or listOfColumns -> listOfDataSets ... >> > > Those where early changes. The XPath is the value of the attribute. Its meaning is a target. It would be like calling the attribute id "string". ListOfColumns implied a specific disposition in space rather than a type of information. > > >> Other changes do require discussion, as I'm not quite sure what to do with >> them: >> >> Previously logX and logY were properties of a Plot2D, as facility of >> creating a log plot. In the current version those attributes are now >> properties of the *individual* curves of the plot. Is this really necessary? >> > > Yes, we found examples where curves with linear and log Y where plotted together. > > >> Does it make sense to paint those together? And what is supposed to be on >> the axis, the logged values or the uhm not-logged ones? >> > > You have plenty of plots with several axis, for instance on the left and on the right. > > >> Or previously we had Parameter values defined as real-numbered values, now >> they are strings. >> > > I do not remember when this happened, and actually did not notice. I find this odd and I agree we should discuss it. > > >> Finally some of the classes that were previously under discussion, hence >> marked white are now no longer marked. >> > > It is just a coloring trick I believe. > > >> I.e: ChangeMath, here I'm not sure what the list of variables, or >> list of parameters would be? I thought this would be a special case of >> changeXML, where I just swap out one snippet of MathML by another one. But I >> would not know what to do with variables and parameters in that case. >> > > This is a big misunderstanding. ChangeXML is used to replace a piece of the model by something else. One can replace the value of an attribute, or an element etc. > > ChangeMath COMPUTES a change. For instance, you can compute the new value for an attribute of model A based on the value of an attribute of model B and an external parameter. Therefore the listOfVariables use an XPath. > > |
|
From: Nicolas Le N. <le...@eb...> - 2009-01-27 08:26:50
|
And the attachment. Nicolas Le Novere wrote: > Frank Bergmann wrote: > >> I've had another look at the OM + example. As it turns out it has changed in >> some places from what we initially discussed. If possible I'd rather like to >> discuss changes on this list first, before they get taken as granted. Some >> of the changes have been renaming of attributes. Those are breaking changes >> for all of us with working prototypes and deserve to be discussed: >> > > Frank, > > I am deeply sorry. This comes from the unfortunate fact that during half a year, the OM on Sourceforge was not updated. Those changes were largely discussed, sometimes on the list, sometimes on more restricted discussion. Most of them date back to the time of CCB in March 2008. They were all present in the report on SED-ML we made for CMSB08 last October (attached), that has been available since the summer for instance from the project webpage. > > The problem is that SED-ML is not yet stable, and therefore there is not a precise date that corresponds to a given version of the OM. That is indeed a big mess, and we will change that ASAP by setting a numbering system. > >> - i.e: XPath -> target, or listOfColumns -> listOfDataSets ... > > Those where early changes. The XPath is the value of the attribute. Its meaning is a target. It would be like calling the attribute id "string". ListOfColumns implied a specific disposition in space rather than a type of information. > >> Other changes do require discussion, as I'm not quite sure what to do with >> them: >> >> Previously logX and logY were properties of a Plot2D, as facility of >> creating a log plot. In the current version those attributes are now >> properties of the *individual* curves of the plot. Is this really necessary? > > Yes, we found examples where curves with linear and log Y where plotted together. > >> Does it make sense to paint those together? And what is supposed to be on >> the axis, the logged values or the uhm not-logged ones? > > You have plenty of plots with several axis, for instance on the left and on the right. > >> Or previously we had Parameter values defined as real-numbered values, now >> they are strings. > > I do not remember when this happened, and actually did not notice. I find this odd and I agree we should discuss it. > >> Finally some of the classes that were previously under discussion, hence >> marked white are now no longer marked. > > It is just a coloring trick I believe. > >> I.e: ChangeMath, here I'm not sure what the list of variables, or >> list of parameters would be? I thought this would be a special case of >> changeXML, where I just swap out one snippet of MathML by another one. But I >> would not know what to do with variables and parameters in that case. > > This is a big misunderstanding. ChangeXML is used to replace a piece of the model by something else. One can replace the value of an attribute, or an element etc. > > ChangeMath COMPUTES a change. For instance, you can compute the new value for an attribute of model A based on the value of an attribute of model B and an external parameter. Therefore the listOfVariables use an XPath. > -- 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... http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ |
|
From: Nicolas Le N. <le...@eb...> - 2009-01-27 08:24:53
|
Frank Bergmann wrote: > I've had another look at the OM + example. As it turns out it has changed in > some places from what we initially discussed. If possible I'd rather like to > discuss changes on this list first, before they get taken as granted. Some > of the changes have been renaming of attributes. Those are breaking changes > for all of us with working prototypes and deserve to be discussed: > Frank, I am deeply sorry. This comes from the unfortunate fact that during half a year, the OM on Sourceforge was not updated. Those changes were largely discussed, sometimes on the list, sometimes on more restricted discussion. Most of them date back to the time of CCB in March 2008. They were all present in the report on SED-ML we made for CMSB08 last October (attached), that has been available since the summer for instance from the project webpage. The problem is that SED-ML is not yet stable, and therefore there is not a precise date that corresponds to a given version of the OM. That is indeed a big mess, and we will change that ASAP by setting a numbering system. > - i.e: XPath -> target, or listOfColumns -> listOfDataSets ... Those where early changes. The XPath is the value of the attribute. Its meaning is a target. It would be like calling the attribute id "string". ListOfColumns implied a specific disposition in space rather than a type of information. > Other changes do require discussion, as I'm not quite sure what to do with > them: > > Previously logX and logY were properties of a Plot2D, as facility of > creating a log plot. In the current version those attributes are now > properties of the *individual* curves of the plot. Is this really necessary? Yes, we found examples where curves with linear and log Y where plotted together. > Does it make sense to paint those together? And what is supposed to be on > the axis, the logged values or the uhm not-logged ones? You have plenty of plots with several axis, for instance on the left and on the right. > Or previously we had Parameter values defined as real-numbered values, now > they are strings. I do not remember when this happened, and actually did not notice. I find this odd and I agree we should discuss it. > Finally some of the classes that were previously under discussion, hence > marked white are now no longer marked. It is just a coloring trick I believe. > I.e: ChangeMath, here I'm not sure what the list of variables, or > list of parameters would be? I thought this would be a special case of > changeXML, where I just swap out one snippet of MathML by another one. But I > would not know what to do with variables and parameters in that case. This is a big misunderstanding. ChangeXML is used to replace a piece of the model by something else. One can replace the value of an attribute, or an element etc. ChangeMath COMPUTES a change. For instance, you can compute the new value for an attribute of model A based on the value of an attribute of model B and an external parameter. Therefore the listOfVariables use an XPath. -- 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... http://www.ebi.ac.uk/~lenov/, http://www.ebi.ac.uk/compneur/ |
|
From: Frank B. <fbergman@u.washington.edu> - 2009-01-27 00:01:42
|
Hello, I've had another look at the OM + example. As it turns out it has changed in some places from what we initially discussed. If possible I'd rather like to discuss changes on this list first, before they get taken as granted. Some of the changes have been renaming of attributes. Those are breaking changes for all of us with working prototypes and deserve to be discussed: - i.e: XPath -> target, or listOfColumns -> listOfDataSets ... Other changes do require discussion, as I'm not quite sure what to do with them: Previously logX and logY were properties of a Plot2D, as facility of creating a log plot. In the current version those attributes are now properties of the *individual* curves of the plot. Is this really necessary? Does it make sense to paint those together? And what is supposed to be on the axis, the logged values or the uhm not-logged ones? Or previously we had Parameter values defined as real-numbered values, now they are strings. Finally some of the classes that were previously under discussion, hence marked white are now no longer marked. I.e: ChangeMath, here I'm not sure what the list of variables, or list of parameters would be? I thought this would be a special case of changeXML, where I just swap out one snippet of MathML by another one. But I would not know what to do with variables and parameters in that case. Or 'AnySimulation' with a big list of simulation properties ... Please let me know, Best Frank |
14 messages has been excluded from this view by a project administrator.
