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: Michael H. <mh...@ca...> - 2008-02-27 21:42:39
|
It seems the CellML people are discussing some topics that are possibly relevant to MIASE too: http://www.cellml.org/specifications/metadata/graphs MH |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-20 11:39:01
|
All: I've added the latest from 2/19 to the CVS repository, including samples (4 files: diagram, pdf of diagram, miase xml, and sbml model). This is a group of related files, and contains a full test implementation. I've started version tagging on the repository, so people can figure out which version of which file go together. I've picked an (obviously non-imaginative...) arbitrary tagging string (build_xxx). This can be easily changed later. If you use version tags, you will see that "build_001" contains dia file 1.6, pdf file 1.5, miase file 1.1 and sbml file 1.1. Ion >-----Original Message----- >From: mia...@li... >[mailto:mia...@li...] On Behalf >Of Dagmar Koehn >Sent: Wednesday, February 20, 2008 2:07 PM >To: mia...@li... >Subject: Re: [Miase-discuss] Updated OM > >Michael Hucka wrote: >> Um, not meaning to be annoying, but could someone point me >to the most >> recent agreement on this? I'm just trying to catch up. It sounds >> like people's opinions on the OM are converging. >> > >The latest version on sourceforge was the one we started the >current discussion on (1.5) >http://miase.cvs.sourceforge.net/miase/miaseOM/miaseOM/ . >Then, as far as I got it, the latest suggestion is the one Ion >sent on the 19th of FEB, with a sample SBML file attached (it >should have come on the mailing list just now). > >I'll be at the EBI from Monday, dedicating most of my time to >MIASE (hopefully), I'll try to summarize the discussions and >changes between the sourceforge version and the suggestions >submitted until then and send a mail. >Hope that we can come to agree on things then :) > >/Dagmar > >-- >Dagmar Köhn, EMBL - European Bioinformatics Institute, >Computational Neurobiology Group, Hinxton, Cambridge, CB10 >1DS, UK, http://www.ebi.ac.uk/compneur-srv/, da...@eb..., >Tel: +441223494418 > > >--------------------------------------------------------------- >---------- >This SF.net email is sponsored by: Microsoft >Defy all challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >Miase-discuss mailing list >Mia...@li... >https://lists.sourceforge.net/lists/listinfo/miase-discuss > |
|
From: Dagmar K. <da...@eb...> - 2008-02-20 11:07:31
|
Michael Hucka wrote: > Um, not meaning to be annoying, but could someone point me > to the most recent agreement on this? I'm just trying to > catch up. It sounds like people's opinions on the OM are > converging. > The latest version on sourceforge was the one we started the current discussion on (1.5) http://miase.cvs.sourceforge.net/miase/miaseOM/miaseOM/ . Then, as far as I got it, the latest suggestion is the one Ion sent on the 19th of FEB, with a sample SBML file attached (it should have come on the mailing list just now). I'll be at the EBI from Monday, dedicating most of my time to MIASE (hopefully), I'll try to summarize the discussions and changes between the sourceforge version and the suggestions submitted until then and send a mail. Hope that we can come to agree on things then :) /Dagmar -- Dagmar Köhn, EMBL - European Bioinformatics Institute, Computational Neurobiology Group, Hinxton, Cambridge, CB10 1DS, UK, http://www.ebi.ac.uk/compneur-srv/, da...@eb..., Tel: +441223494418 |
|
From: Dagmar K. <dk...@in...> - 2008-02-20 10:54:44
|
Moraru,Ion wrote: > Arghhh!!! Again too big for the mail list - Dagmar, could you please increase the message limit from 40 KB to something more reasonable (like 100 KB)? > > Ok, I admit I am too slow catching up on your mails. Message size is extended now. Lets see how this works. Dagmar -- Dagmar Koehn,GRK dIEM oSiRiS, http://www.diemosiris.de Joachim-Jungius-Strasse 9, D-18059 Rostock, Germany Tel: 0049-381-4987440, dk...@in... |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-19 12:34:07
|
Attached is the SBML file of the simple model that the MIASE example file refers to. It wasn't included in the previous posting. >-----Original Message----- >From: mia...@li... >[mailto:mia...@li...] On Behalf >Of Moraru,Ion >Sent: Tuesday, February 19, 2008 9:33 AM >To: Frank Bergmann; Henning Schmidt >Cc: Sven Sahle; mia...@li... >Subject: Re: [Miase-discuss] Updated OM > >I agree it is a bit messy. But much of that is the SBML >language's fault... I would be happy for any simpler way to >identify and change parameters that don't have SId. > >The problem is that the situations from the example are >probably the most common ones. People would take a simulation >and rerun it with different "parameters" and put the combined >data on a figure. But often such "parameters" are not a >global parameter in SBML (i.e. with having a SId, and being >part of listOfParameters), but values used inside reactions >and for initial conditions, which we need to "fish out" int >the SBML file. Hence also the other proposed modification >classes that we discussed, that were not used in the example, >like initial assignments. > >As for the data output, I didn't mean to create a useless >expression like "times 1", it was as an example of possible >postprocessing... (e.g. scaling). Also, let's not forget that >it was deemed essential that postprocessing should be possible >to involve multiple variables coming from different tasks >(e.g. normalize results from one simulation against results >from another one). > >Ion > >________________________________ > >From: Frank Bergmann [mailto:fbergman@u.washington.edu] >Sent: Tue 2/19/2008 3:28 AM >To: Moraru,Ion; 'Henning Schmidt' >Cc: 'Sven Sahle'; mia...@li... >Subject: RE: [Miase-discuss] Updated OM > > > >Actually after having a look over this example, this is >getting a bit complicated. Another difference from what we >agreed upon in Okinawa would be the way you define the output. >Instead of a list of variables you look them up within the >"expression" tags of each data-vector. But things would still >work for me. > >I'm a bit more concerned by the new attribute: >changedAttributeReference="initialConcentration" this makes it >a bit harder to implement. I mean, this would mean that we add >next a FunctionDefinitionChange / CompartmentChange / >ConstaintChange ... this seems like a can of worms, that we >did not want to get into at the beginning. > >Btu this could still work ... > >Cheers >Frank > >P.S: > >But please write next time > ><math><ci>ca_cyt1</ci></math> > >Instead of ... > ><apply> > <times /> > <ci>ca_cyt1</ci> > <cn>1</cn> ></apply> > >In a first implementation the former is much easier to handle >than the latter > >> -----Original Message----- >> From: Moraru,Ion [mailto:Mo...@NE...] >> Sent: Monday, February 18, 2008 10:26 PM >> To: Frank Bergmann; Henning Schmidt >> Cc: Sven Sahle; mia...@li... >> Subject: RE: [Miase-discuss] Updated OM >> >> I just noticed that the XML file wasn't attached. Oh, well... Here >> it is. >> >> ________________________________ >> >> From: mia...@li... on behalf of >> Moraru,Ion >> Sent: Tue 2/19/2008 12:36 AM >> To: Frank Bergmann; Henning Schmidt >> Cc: Sven Sahle; mia...@li... >> Subject: Re: [Miase-discuss] Updated OM >> >> >> >> Arghhh!!! Again too big for the mail list - Dagmar, could you please >> increase the message limit from 40 KB to something more reasonable >> (like 100 KB)? >> >> Skipping the dia file so it will fit. Only miase xml and OM >pdf file. >> >> ________________________________ >> >> From: Moraru,Ion >> Sent: Tue 2/19/2008 12:34 AM >> To: Frank Bergmann; Henning Schmidt >> Cc: 'Boss'; 'Sven Sahle'; mia...@li... >> Subject: RE: [Miase-discuss] Updated OM >> >> >> OK, here's the latest, including the small adjustments mentioned >> before, and with attached example XML file implementation and SBML >> model. >> >> Brief overview: >> >> A simple SBML model of 3 species (ca, buffer, and bound ca) in a >> single compartment, with one reaction, mass action binding of ca to >> buffer, with specified Kd and on-rate, and derived off-rate. > Initial >> conc'ns specified for ca and buffer, zero for bound complex. A >> timecourse simulation will show how reaction reaches equilibrium. >> Time to equilibrium as well as final concentration of free calcium >> will depend on on rate, affinity, and initial concentrations. >> >> A simple MIASE file uses this model as a "baseline" >(unchanged) model, >> and specifies a modified model, where initial concentration >of calcium >> as well as the affinity of binding have been changed. It >specifies 2 >> tasks to run the original and the modified model for 10 >seconds with a >> uniform timecoruse output with 1000 timepoints. A single 2D >line plot >> is being specified, with 3 lines: total calcium over time from >> original model run, and free calcium over time, from both >original and >> modified model. >> >> I would like to create an example file for a more complex >"real-world" >> situation - e.g. choosing a particular curated BMDB model and >> describing one of its referenced figures from a publication. Please >> suggest some representative cases. >> >> Ion >> >> >> >> ________________________________ >> >> From: Frank Bergmann [mailto:fbergman@u.washington.edu] >> Sent: Mon 2/18/2008 12:18 PM >> To: Henning Schmidt >> Cc: Moraru,Ion; 'Boss'; 'Sven Sahle'; miase- >> di...@li... >> Subject: Re: [Miase-discuss] Updated OM >> >> >> Right ... though i think there could be an alternative, by >> sub-classing the "Column" or as Ion called them "DataVector" / >> "DataMatrix" to have source attribute. SImilar how we did it >already with the model element. >> I'm not sure that you would need the data actually at the >top level .. >> >> cheers >> Frank >> >> >> On Feb 18, 2008, at 7:22 AM, Henning Schmidt wrote: >> >> >> >> >> Hello, >> >> We talked in Okinawa shortly about the >possibility of >> adding references to measurement data into MIASE. >> >> These data could then also be used in the generation >> of the plots. How exactly such data will be represented in a formal >> >> way is not defined yet but under investigation. >> >> A side effect could be that it would be possible to >> define the simulation time points based on the time vector in >> >> measurements. >> >> A suggestion would be to add a top-level >> "listOfMeasurements" and keep it empty for further use. >> >> >> >> /Henning >> >> >> > > > > > > > >--------------------------------------------------------------- >---------- >This SF.net email is sponsored by: Microsoft Defy all >challenges. Microsoft(R) Visual Studio 2008. >http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ >_______________________________________________ >Miase-discuss mailing list >Mia...@li... >https://lists.sourceforge.net/lists/listinfo/miase-discuss > |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-19 06:31:54
|
I agree it is a bit messy. But much of that is the SBML language's fault... I would be happy for any simpler way to identify and change parameters that don't have SId. The problem is that the situations from the example are probably the most common ones. People would take a simulation and rerun it with different "parameters" and put the combined data on a figure. But often such "parameters" are not a global parameter in SBML (i.e. with having a SId, and being part of listOfParameters), but values used inside reactions and for initial conditions, which we need to "fish out" int the SBML file. Hence also the other proposed modification classes that we discussed, that were not used in the example, like initial assignments. As for the data output, I didn't mean to create a useless expression like "times 1", it was as an example of possible postprocessing... (e.g. scaling). Also, let's not forget that it was deemed essential that postprocessing should be possible to involve multiple variables coming from different tasks (e.g. normalize results from one simulation against results from another one). Ion ________________________________ From: Frank Bergmann [mailto:fbergman@u.washington.edu] Sent: Tue 2/19/2008 3:28 AM To: Moraru,Ion; 'Henning Schmidt' Cc: 'Sven Sahle'; mia...@li... Subject: RE: [Miase-discuss] Updated OM Actually after having a look over this example, this is getting a bit complicated. Another difference from what we agreed upon in Okinawa would be the way you define the output. Instead of a list of variables you look them up within the "expression" tags of each data-vector. But things would still work for me. I'm a bit more concerned by the new attribute: changedAttributeReference="initialConcentration" this makes it a bit harder to implement. I mean, this would mean that we add next a FunctionDefinitionChange / CompartmentChange / ConstaintChange ... this seems like a can of worms, that we did not want to get into at the beginning. Btu this could still work ... Cheers Frank P.S: But please write next time <math><ci>ca_cyt1</ci></math> Instead of ... <apply> <times /> <ci>ca_cyt1</ci> <cn>1</cn> </apply> In a first implementation the former is much easier to handle than the latter > -----Original Message----- > From: Moraru,Ion [mailto:Mo...@NE...] > Sent: Monday, February 18, 2008 10:26 PM > To: Frank Bergmann; Henning Schmidt > Cc: Sven Sahle; mia...@li... > Subject: RE: [Miase-discuss] Updated OM > > I just noticed that the XML file wasn't attached. Oh, well... Here it > is. > > ________________________________ > > From: mia...@li... on behalf of > Moraru,Ion > Sent: Tue 2/19/2008 12:36 AM > To: Frank Bergmann; Henning Schmidt > Cc: Sven Sahle; mia...@li... > Subject: Re: [Miase-discuss] Updated OM > > > > Arghhh!!! Again too big for the mail list - Dagmar, could you please > increase the message limit from 40 KB to something more reasonable > (like 100 KB)? > > Skipping the dia file so it will fit. Only miase xml and OM pdf file. > > ________________________________ > > From: Moraru,Ion > Sent: Tue 2/19/2008 12:34 AM > To: Frank Bergmann; Henning Schmidt > Cc: 'Boss'; 'Sven Sahle'; mia...@li... > Subject: RE: [Miase-discuss] Updated OM > > > OK, here's the latest, including the small adjustments mentioned > before, and with attached example XML file implementation and SBML > model. > > Brief overview: > > A simple SBML model of 3 species (ca, buffer, and bound ca) in a single > compartment, with one reaction, mass action binding of ca to buffer, > with specified Kd and on-rate, and derived off-rate. Initial conc'ns > specified for ca and buffer, zero for bound complex. A timecourse > simulation will show how reaction reaches equilibrium. Time to > equilibrium as well as final concentration of free calcium will depend > on on rate, affinity, and initial concentrations. > > A simple MIASE file uses this model as a "baseline" (unchanged) model, > and specifies a modified model, where initial concentration of calcium > as well as the affinity of binding have been changed. It specifies 2 > tasks to run the original and the modified model for 10 seconds with a > uniform timecoruse output with 1000 timepoints. A single 2D line plot > is being specified, with 3 lines: total calcium over time from original > model run, and free calcium over time, from both original and modified > model. > > I would like to create an example file for a more complex "real-world" > situation - e.g. choosing a particular curated BMDB model and > describing one of its referenced figures from a publication. Please > suggest some representative cases. > > Ion > > > > ________________________________ > > From: Frank Bergmann [mailto:fbergman@u.washington.edu] > Sent: Mon 2/18/2008 12:18 PM > To: Henning Schmidt > Cc: Moraru,Ion; 'Boss'; 'Sven Sahle'; miase- > di...@li... > Subject: Re: [Miase-discuss] Updated OM > > > Right ... though i think there could be an alternative, by sub-classing > the "Column" or as Ion called them "DataVector" / "DataMatrix" to have > source attribute. SImilar how we did it already with the model element. > I'm not sure that you would need the data actually at the top level .. > > cheers > Frank > > > On Feb 18, 2008, at 7:22 AM, Henning Schmidt wrote: > > > > > Hello, > > We talked in Okinawa shortly about the possibility of > adding references to measurement data into MIASE. > > These data could then also be used in the generation of > the plots. How exactly such data will be represented in a formal > > way is not defined yet but under investigation. > > A side effect could be that it would be possible to > define the simulation time points based on the time vector in > > measurements. > > A suggestion would be to add a top-level > "listOfMeasurements" and keep it empty for further use. > > > > /Henning > > > |
|
From: Frank B. <fbergman@u.washington.edu> - 2008-02-19 00:28:23
|
Actually after having a look over this example, this is getting a bit complicated. Another difference from what we agreed upon in Okinawa would be the way you define the output. Instead of a list of variables you look them up within the "expression" tags of each data-vector. But things would still work for me. I'm a bit more concerned by the new attribute: changedAttributeReference="initialConcentration" this makes it a bit harder to implement. I mean, this would mean that we add next a FunctionDefinitionChange / CompartmentChange / ConstaintChange ... this seems like a can of worms, that we did not want to get into at the beginning. Btu this could still work ... Cheers Frank P.S: But please write next time <math><ci>ca_cyt1</ci></math> Instead of ... <apply> <times /> <ci>ca_cyt1</ci> <cn>1</cn> </apply> In a first implementation the former is much easier to handle than the latter > -----Original Message----- > From: Moraru,Ion [mailto:Mo...@NE...] > Sent: Monday, February 18, 2008 10:26 PM > To: Frank Bergmann; Henning Schmidt > Cc: Sven Sahle; mia...@li... > Subject: RE: [Miase-discuss] Updated OM > > I just noticed that the XML file wasn't attached. Oh, well... Here it > is. > > ________________________________ > > From: mia...@li... on behalf of > Moraru,Ion > Sent: Tue 2/19/2008 12:36 AM > To: Frank Bergmann; Henning Schmidt > Cc: Sven Sahle; mia...@li... > Subject: Re: [Miase-discuss] Updated OM > > > > Arghhh!!! Again too big for the mail list - Dagmar, could you please > increase the message limit from 40 KB to something more reasonable > (like 100 KB)? > > Skipping the dia file so it will fit. Only miase xml and OM pdf file. > > ________________________________ > > From: Moraru,Ion > Sent: Tue 2/19/2008 12:34 AM > To: Frank Bergmann; Henning Schmidt > Cc: 'Boss'; 'Sven Sahle'; mia...@li... > Subject: RE: [Miase-discuss] Updated OM > > > OK, here's the latest, including the small adjustments mentioned > before, and with attached example XML file implementation and SBML > model. > > Brief overview: > > A simple SBML model of 3 species (ca, buffer, and bound ca) in a single > compartment, with one reaction, mass action binding of ca to buffer, > with specified Kd and on-rate, and derived off-rate. Initial conc'ns > specified for ca and buffer, zero for bound complex. A timecourse > simulation will show how reaction reaches equilibrium. Time to > equilibrium as well as final concentration of free calcium will depend > on on rate, affinity, and initial concentrations. > > A simple MIASE file uses this model as a "baseline" (unchanged) model, > and specifies a modified model, where initial concentration of calcium > as well as the affinity of binding have been changed. It specifies 2 > tasks to run the original and the modified model for 10 seconds with a > uniform timecoruse output with 1000 timepoints. A single 2D line plot > is being specified, with 3 lines: total calcium over time from original > model run, and free calcium over time, from both original and modified > model. > > I would like to create an example file for a more complex "real-world" > situation - e.g. choosing a particular curated BMDB model and > describing one of its referenced figures from a publication. Please > suggest some representative cases. > > Ion > > > > ________________________________ > > From: Frank Bergmann [mailto:fbergman@u.washington.edu] > Sent: Mon 2/18/2008 12:18 PM > To: Henning Schmidt > Cc: Moraru,Ion; 'Boss'; 'Sven Sahle'; miase- > di...@li... > Subject: Re: [Miase-discuss] Updated OM > > > Right ... though i think there could be an alternative, by sub-classing > the "Column" or as Ion called them "DataVector" / "DataMatrix" to have > source attribute. SImilar how we did it already with the model element. > I'm not sure that you would need the data actually at the top level .. > > cheers > Frank > > > On Feb 18, 2008, at 7:22 AM, Henning Schmidt wrote: > > > > > Hello, > > We talked in Okinawa shortly about the possibility of > adding references to measurement data into MIASE. > > These data could then also be used in the generation of > the plots. How exactly such data will be represented in a formal > > way is not defined yet but under investigation. > > A side effect could be that it would be possible to > define the simulation time points based on the time vector in > > measurements. > > A suggestion would be to add a top-level > "listOfMeasurements" and keep it empty for further use. > > > > /Henning > > > |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-18 22:25:45
|
I just noticed that the XML file wasn't attached. Oh, well... Here it is. ________________________________ From: mia...@li... on behalf of Moraru,Ion Sent: Tue 2/19/2008 12:36 AM To: Frank Bergmann; Henning Schmidt Cc: Sven Sahle; mia...@li... Subject: Re: [Miase-discuss] Updated OM Arghhh!!! Again too big for the mail list - Dagmar, could you please increase the message limit from 40 KB to something more reasonable (like 100 KB)? Skipping the dia file so it will fit. Only miase xml and OM pdf file. ________________________________ From: Moraru,Ion Sent: Tue 2/19/2008 12:34 AM To: Frank Bergmann; Henning Schmidt Cc: 'Boss'; 'Sven Sahle'; mia...@li... Subject: RE: [Miase-discuss] Updated OM OK, here's the latest, including the small adjustments mentioned before, and with attached example XML file implementation and SBML model. Brief overview: A simple SBML model of 3 species (ca, buffer, and bound ca) in a single compartment, with one reaction, mass action binding of ca to buffer, with specified Kd and on-rate, and derived off-rate. Initial conc'ns specified for ca and buffer, zero for bound complex. A timecourse simulation will show how reaction reaches equilibrium. Time to equilibrium as well as final concentration of free calcium will depend on on rate, affinity, and initial concentrations. A simple MIASE file uses this model as a "baseline" (unchanged) model, and specifies a modified model, where initial concentration of calcium as well as the affinity of binding have been changed. It specifies 2 tasks to run the original and the modified model for 10 seconds with a uniform timecoruse output with 1000 timepoints. A single 2D line plot is being specified, with 3 lines: total calcium over time from original model run, and free calcium over time, from both original and modified model. I would like to create an example file for a more complex "real-world" situation - e.g. choosing a particular curated BMDB model and describing one of its referenced figures from a publication. Please suggest some representative cases. Ion ________________________________ From: Frank Bergmann [mailto:fbergman@u.washington.edu] Sent: Mon 2/18/2008 12:18 PM To: Henning Schmidt Cc: Moraru,Ion; 'Boss'; 'Sven Sahle'; mia...@li... Subject: Re: [Miase-discuss] Updated OM Right ... though i think there could be an alternative, by sub-classing the "Column" or as Ion called them "DataVector" / "DataMatrix" to have source attribute. SImilar how we did it already with the model element. I'm not sure that you would need the data actually at the top level .. cheers Frank On Feb 18, 2008, at 7:22 AM, Henning Schmidt wrote: Hello, We talked in Okinawa shortly about the possibility of adding references to measurement data into MIASE. These data could then also be used in the generation of the plots. How exactly such data will be represented in a formal way is not defined yet but under investigation. A side effect could be that it would be possible to define the simulation time points based on the time vector in measurements. A suggestion would be to add a top-level "listOfMeasurements" and keep it empty for further use. /Henning |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-18 21:52:45
|
well, i have our own web dropbox available where i can put up to 50 gb... but it would be nice if we can just share these simple files over the maillist/sourceforge :) ________________________________ From: Michael Hucka [mailto:mh...@ca...] Sent: Tue 2/19/2008 12:43 AM To: Moraru,Ion Cc: Frank Bergmann; Henning Schmidt; Sven Sahle; mia...@li... Subject: Re: [Miase-discuss] Updated OM BTW, I have found drop.io very useful for putting up files quickly for other people to grab... MH >>>>> On 19 Feb 2008, "Moraru,Ion" <Mo...@NE...> wrote: Moraru> Arghhh!!! Again too big for the mail list - Moraru> Dagmar, could you please increase the message Moraru> limit from 40 KB to something more reasonable Moraru> (like 100 KB)? Moraru> Moraru> Skipping the dia file so it will fit. Only miase Moraru> xml and OM pdf file. |
|
From: Michael H. <mh...@ca...> - 2008-02-18 21:44:15
|
BTW, I have found drop.io very useful for putting up files quickly for other people to grab... MH >>>>> On 19 Feb 2008, "Moraru,Ion" <Mo...@NE...> wrote: Moraru> Arghhh!!! Again too big for the mail list - Moraru> Dagmar, could you please increase the message Moraru> limit from 40 KB to something more reasonable Moraru> (like 100 KB)? Moraru> Moraru> Skipping the dia file so it will fit. Only miase Moraru> xml and OM pdf file. |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-18 21:37:22
|
Arghhh!!! Again too big for the mail list - Dagmar, could you please increase the message limit from 40 KB to something more reasonable (like 100 KB)? Skipping the dia file so it will fit. Only miase xml and OM pdf file. ________________________________ From: Moraru,Ion Sent: Tue 2/19/2008 12:34 AM To: Frank Bergmann; Henning Schmidt Cc: 'Boss'; 'Sven Sahle'; mia...@li... Subject: RE: [Miase-discuss] Updated OM OK, here's the latest, including the small adjustments mentioned before, and with attached example XML file implementation and SBML model. Brief overview: A simple SBML model of 3 species (ca, buffer, and bound ca) in a single compartment, with one reaction, mass action binding of ca to buffer, with specified Kd and on-rate, and derived off-rate. Initial conc'ns specified for ca and buffer, zero for bound complex. A timecourse simulation will show how reaction reaches equilibrium. Time to equilibrium as well as final concentration of free calcium will depend on on rate, affinity, and initial concentrations. A simple MIASE file uses this model as a "baseline" (unchanged) model, and specifies a modified model, where initial concentration of calcium as well as the affinity of binding have been changed. It specifies 2 tasks to run the original and the modified model for 10 seconds with a uniform timecoruse output with 1000 timepoints. A single 2D line plot is being specified, with 3 lines: total calcium over time from original model run, and free calcium over time, from both original and modified model. I would like to create an example file for a more complex "real-world" situation - e.g. choosing a particular curated BMDB model and describing one of its referenced figures from a publication. Please suggest some representative cases. Ion ________________________________ From: Frank Bergmann [mailto:fbergman@u.washington.edu] Sent: Mon 2/18/2008 12:18 PM To: Henning Schmidt Cc: Moraru,Ion; 'Boss'; 'Sven Sahle'; mia...@li... Subject: Re: [Miase-discuss] Updated OM Right ... though i think there could be an alternative, by sub-classing the "Column" or as Ion called them "DataVector" / "DataMatrix" to have source attribute. SImilar how we did it already with the model element. I'm not sure that you would need the data actually at the top level .. cheers Frank On Feb 18, 2008, at 7:22 AM, Henning Schmidt wrote: Hello, We talked in Okinawa shortly about the possibility of adding references to measurement data into MIASE. These data could then also be used in the generation of the plots. How exactly such data will be represented in a formal way is not defined yet but under investigation. A side effect could be that it would be possible to define the simulation time points based on the time vector in measurements. A suggestion would be to add a top-level "listOfMeasurements" and keep it empty for further use. /Henning |
|
From: Michael H. <mh...@ca...> - 2008-02-18 21:35:21
|
Super. Thank you. MH >>>>> On 18 Feb 2008, Frank Bergmann <fbergman@u.washington.edu> wrote: fbergman> Hello Mike, the latest PDF will be at the MIASE fbergman> cvs repository: fbergman> fbergman> http://miase.cvs.sourceforge.net/*checkout*/miase/miaseOM/miaseOM/miaseOM.pdf?revision=1.4 fbergman> fbergman> though Ions changes are not yet incorporated fbergman> ... so i'll attach the PDF. fbergman> fbergman> Cheers Frank fbergman> fbergman> On Feb 18, 2008, at 9:15 PM, Michael Hucka fbergman> wrote: fbergman> >> Um, not meaning to be annoying, but could someone point >> me to the most recent agreement on this? I'm just >> trying to catch up. It sounds like people's opinions >> on the OM are converging. >> >> (If there are diagrams, can you provide PDFs please? I >> don't want to have to deal with 'dia'....) >> >> MH >> |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-18 21:33:23
|
OK, here's the latest, including the small adjustments mentioned before, and with attached example XML file implementation and SBML model. Brief overview: A simple SBML model of 3 species (ca, buffer, and bound ca) in a single compartment, with one reaction, mass action binding of ca to buffer, with specified Kd and on-rate, and derived off-rate. Initial conc'ns specified for ca and buffer, zero for bound complex. A timecourse simulation will show how reaction reaches equilibrium. Time to equilibrium as well as final concentration of free calcium will depend on on rate, affinity, and initial concentrations. A simple MIASE file uses this model as a "baseline" (unchanged) model, and specifies a modified model, where initial concentration of calcium as well as the affinity of binding have been changed. It specifies 2 tasks to run the original and the modified model for 10 seconds with a uniform timecoruse output with 1000 timepoints. A single 2D line plot is being specified, with 3 lines: total calcium over time from original model run, and free calcium over time, from both original and modified model. I would like to create an example file for a more complex "real-world" situation - e.g. choosing a particular curated BMDB model and describing one of its referenced figures from a publication. Please suggest some representative cases. Ion ________________________________ From: Frank Bergmann [mailto:fbergman@u.washington.edu] Sent: Mon 2/18/2008 12:18 PM To: Henning Schmidt Cc: Moraru,Ion; 'Boss'; 'Sven Sahle'; mia...@li... Subject: Re: [Miase-discuss] Updated OM Right ... though i think there could be an alternative, by sub-classing the "Column" or as Ion called them "DataVector" / "DataMatrix" to have source attribute. SImilar how we did it already with the model element. I'm not sure that you would need the data actually at the top level .. cheers Frank On Feb 18, 2008, at 7:22 AM, Henning Schmidt wrote: Hello, We talked in Okinawa shortly about the possibility of adding references to measurement data into MIASE. These data could then also be used in the generation of the plots. How exactly such data will be represented in a formal way is not defined yet but under investigation. A side effect could be that it would be possible to define the simulation time points based on the time vector in measurements. A suggestion would be to add a top-level "listOfMeasurements" and keep it empty for further use. /Henning |
|
From: Frank B. <fbergman@u.washington.edu> - 2008-02-18 21:33:16
|
Hello Mike, the latest PDF will be at the MIASE cvs repository: http://miase.cvs.sourceforge.net/*checkout*/miase/miaseOM/miaseOM/miaseOM.pdf?revision=1.4 though Ions changes are not yet incorporated ... so i'll attach the PDF. Cheers Frank On Feb 18, 2008, at 9:15 PM, Michael Hucka wrote: > Um, not meaning to be annoying, but could someone point me > to the most recent agreement on this? I'm just trying to > catch up. It sounds like people's opinions on the OM are > converging. > > (If there are diagrams, can you provide PDFs please? I > don't want to have to deal with 'dia'....) > > MH > |
|
From: Michael H. <mh...@ca...> - 2008-02-18 21:15:51
|
Um, not meaning to be annoying, but could someone point me to the most recent agreement on this? I'm just trying to catch up. It sounds like people's opinions on the OM are converging. (If there are diagrams, can you provide PDFs please? I don't want to have to deal with 'dia'....) MH |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-18 17:02:36
|
Frank, thanks for catching that - I removed it from Task class. Also introduced another subclass of abstract SBMLModelModification for changes to initial concentration attributes on species. Will email the update later tonight with the example file. Ion ________________________________ From: Frank Bergmann [mailto:fbergman@u.washington.edu] Sent: Mon 2/18/2008 2:17 AM To: Moraru,Ion Cc: 'Boss'; 'Sven Sahle'; mia...@li... Subject: RE: [Miase-discuss] Updated OM Ok, that still works for me ... I look forward to your example files. Not to be picky, but the annotation property is not needed on task, as all elements inherit from MBase anyway. Other than that, the only question I have is what you have planned for the legend attribute. Given that the plots can be named, the individual columns as well, what would you want to use this for? Cheers Frank From: mia...@li... [mailto:mia...@li...] On Behalf Of Moraru,Ion Sent: Sunday, February 17, 2008 8:08 PM To: Dagmar Koehn Cc: Boss; Sven Sahle; mia...@li... Subject: Re: [Miase-discuss] Updated OM Hi Dagmar, Attached is the revised OM diagram that includes the definition of data for combination of lines/surfaces etc. in plots. Tomorrow is a holiday in the US, so I will have an easier day at work, and really be able to wirte up notes, comments, example XML file etc. Cheers, Ion ________________________________ From: Moraru,Ion Sent: Thursday, February 14, 2008 9:19 AM To: Dagmar Koehn Subject: RE: [Miase-discuss] Updated OM Hi Dagmar, I am sorry, too, that I didn't follow up with the comments (and the promised example file). It's been a hectic week, with outside guests, winterstorms, meetings, and deadlines. Getting more relaxed from tomorrow... Ion PS - BTW, I have another version with a few more changes, we had forgotten about what we called "Curves" in Okinawa, about the ability to define individual lines/surfaces in a single plot that come from data from different Tasks PPS - do you use any instant messaging tool (AOL, Yahoo, MSN?) ________________________________ From: Dagmar Koehn [mailto:da...@eb...] Sent: Thu 2/14/2008 7:25 AM To: Moraru,Ion Subject: Re: [Miase-discuss] Updated OM Hej Ion, sorry for the late reply, I was away from the computer for a couple of days... How should I do with the new version - should I just put it on the cvs? Will you write another mail to miase-discuss explaining your changes? Dagmar Moraru,Ion wrote: > Ok, second try, was rejected by size, now .dia is compressed... > > >> -----Original Message----- >> From: Moraru,Ion >> Sent: Monday, February 11, 2008 4:02 PM >> To: 'Dagmar Koehn'; 'Frank Bergmann' >> Cc: Boss; Sven Sahle; mia...@li... >> Subject: Updated OM >> >> >> Dagmar & Frank: >> >> Attached is the updated UML diagram (and PDF version). Does >> the discussion list handle the attachments properly, or do >> they get stripped? I guess we'll see... and then I'll get >> back with some comments and a sample XML file that uses all >> classes defined so far. >> >> Ion >> >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Miase-discuss mailing list > Mia...@li... > https://lists.sourceforge.net/lists/listinfo/miase-discuss -- Dagmar Köhn, EMBL - European Bioinformatics Institute, Computational Neurobiology Group, Hinxton, Cambridge, CB10 1DS, UK, http://www.ebi.ac.uk/compneur-srv/, da...@eb..., Tel: +441223494418 |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-18 15:02:46
|
Yes, indeed. I think Nicolas is still catching up to his email after being away... We have changed to subclassing from MBase, all separate namespace. Along the same way of thinking, we proposed to make the classes that deal with model modification explicit, separate for each of the modeling languages that may be "supported" by the MIASE specification. Ion ________________________________ From: Frank Bergmann [mailto:fbergman@u.washington.edu] Sent: Mon 2/18/2008 5:32 PM To: le...@eb... Cc: 'Dagmar Koehn'; 'Henning Schmidt'; 'Sven Sahle'; 'Akira Funahashi'; Moraru,Ion; mia...@li... Subject: RE: miaseOM > > I strongly oppose that. SBase belongs to SBML namespace. Subclassing > MIASE elements from SBase would de facto make MIASE part of SBML. If we > create a class SBase in MIASE namespace, it is different form SBML's > SBase, and then, why calling it the same. > Well ... actually ... all we were saying here was that similar to how it is handled in SBML every element in the MIASE object model should provide the facilities for adding annotations and notes to it. This by no way implies that MIASE would be a part of SBML (though I still believe that being able to embed a subset of MIASE in an SBML model would be advantageous). Looking at the OM right now we see it called MBase and that is fine :) Cheers Frank |
|
From: Frank B. <fbergman@u.washington.edu> - 2008-02-18 14:33:44
|
> > I strongly oppose that. SBase belongs to SBML namespace. Subclassing > MIASE elements from SBase would de facto make MIASE part of SBML. If we > create a class SBase in MIASE namespace, it is different form SBML's > SBase, and then, why calling it the same. > Well ... actually ... all we were saying here was that similar to how it is handled in SBML every element in the MIASE object model should provide the facilities for adding annotations and notes to it. This by no way implies that MIASE would be a part of SBML (though I still believe that being able to embed a subset of MIASE in an SBML model would be advantageous). Looking at the OM right now we see it called MBase and that is fine :) Cheers Frank |
|
From: Frank B. <fbergman@u.washington.edu> - 2008-02-18 09:18:47
|
Right ... though i think there could be an alternative, by sub- classing the "Column" or as Ion called them "DataVector" / "DataMatrix" to have source attribute. SImilar how we did it already with the model element. I'm not sure that you would need the data actually at the top level .. cheers Frank On Feb 18, 2008, at 7:22 AM, Henning Schmidt wrote: > Hello, > > We talked in Okinawa shortly about the possibility of adding > references to measurement data into MIASE. > > These data could then also be used in the generation of the plots. > How exactly such data will be represented in a formal > > way is not defined yet but under investigation. > > A side effect could be that it would be possible to define the > simulation time points based on the time vector in > > measurements. > > A suggestion would be to add a top-level “listOfMeasurements” and > keep it empty for further use. > > > > /Henning > |
|
From: Henning S. <he...@hs...> - 2008-02-18 07:25:41
|
Hello, We talked in Okinawa shortly about the possibility of adding references to measurement data into MIASE. These data could then also be used in the generation of the plots. How exactly such data will be represented in a formal way is not defined yet but under investigation. A side effect could be that it would be possible to define the simulation time points based on the time vector in measurements. A suggestion would be to add a top-level "listOfMeasurements" and keep it empty for further use. /Henning |
|
From: Frank B. <fbergman@u.washington.edu> - 2008-02-17 23:17:31
|
Ok, that still works for me I look forward to your example files. Not to be picky, but the annotation property is not needed on task, as all elements inherit from MBase anyway. Other than that, the only question I have is what you have planned for the legend attribute. Given that the plots can be named, the individual columns as well, what would you want to use this for? Cheers Frank From: mia...@li... [mailto:mia...@li...] On Behalf Of Moraru,Ion Sent: Sunday, February 17, 2008 8:08 PM To: Dagmar Koehn Cc: Boss; Sven Sahle; mia...@li... Subject: Re: [Miase-discuss] Updated OM Hi Dagmar, Attached is the revised OM diagram that includes the definition of data for combination of lines/surfaces etc. in plots. Tomorrow is a holiday in the US, so I will have an easier day at work, and really be able to wirte up notes, comments, example XML file etc. Cheers, Ion _____ From: Moraru,Ion Sent: Thursday, February 14, 2008 9:19 AM To: Dagmar Koehn Subject: RE: [Miase-discuss] Updated OM Hi Dagmar, I am sorry, too, that I didn't follow up with the comments (and the promised example file). It's been a hectic week, with outside guests, winterstorms, meetings, and deadlines. Getting more relaxed from tomorrow... Ion PS - BTW, I have another version with a few more changes, we had forgotten about what we called "Curves" in Okinawa, about the ability to define individual lines/surfaces in a single plot that come from data from different Tasks PPS - do you use any instant messaging tool (AOL, Yahoo, MSN?) _____ From: Dagmar Koehn [mailto:da...@eb...] Sent: Thu 2/14/2008 7:25 AM To: Moraru,Ion Subject: Re: [Miase-discuss] Updated OM Hej Ion, sorry for the late reply, I was away from the computer for a couple of days... How should I do with the new version - should I just put it on the cvs? Will you write another mail to miase-discuss explaining your changes? Dagmar Moraru,Ion wrote: > Ok, second try, was rejected by size, now .dia is compressed... > > >> -----Original Message----- >> From: Moraru,Ion >> Sent: Monday, February 11, 2008 4:02 PM >> To: 'Dagmar Koehn'; 'Frank Bergmann' >> Cc: Boss; Sven Sahle; mia...@li... >> Subject: Updated OM >> >> >> Dagmar & Frank: >> >> Attached is the updated UML diagram (and PDF version). Does >> the discussion list handle the attachments properly, or do >> they get stripped? I guess we'll see... and then I'll get >> back with some comments and a sample XML file that uses all >> classes defined so far. >> >> Ion >> >> > > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > ------------------------------------------------------------------------ > > _______________________________________________ > Miase-discuss mailing list > Mia...@li... > https://lists.sourceforge.net/lists/listinfo/miase-discuss -- Dagmar Köhn, EMBL - European Bioinformatics Institute, Computational Neurobiology Group, Hinxton, Cambridge, CB10 1DS, UK, http://www.ebi.ac.uk/compneur-srv/, da...@eb..., Tel: +441223494418 |
|
From: Moraru,Ion <Mo...@NE...> - 2008-02-11 13:08:36
|
Ok, second try, was rejected by size, now .dia is compressed... >-----Original Message----- >From: Moraru,Ion >Sent: Monday, February 11, 2008 4:02 PM >To: 'Dagmar Koehn'; 'Frank Bergmann' >Cc: Boss; Sven Sahle; mia...@li... >Subject: Updated OM > > >Dagmar & Frank: > >Attached is the updated UML diagram (and PDF version). Does >the discussion list handle the attachments properly, or do >they get stripped? I guess we'll see... and then I'll get >back with some comments and a sample XML file that uses all >classes defined so far. > >Ion > > |
|
From: Frank B. <fbergman@u.washington.edu> - 2008-02-11 09:38:37
|
> > But what you will have is something similar to: > > <changedModel id="123" type="SBML" source="http://..."> > <modelModification link="linkToModelModification" /> > </changedModel> > > <listOfChanges> > <SBMLModelModificationInformation /> > </listOfChanges> > > So, we should find a way of encoding the modifications differently, > but > in my opinion that has nothing to do with the changedModel element, > does it? > well ... what it actually should look like is something like this: <ListOfChanges> <SBMLParameterChange id="P1" /> <SBMLAssignmentRuleChange id="A1" /> </ListOfChanges> <ListOfModels> <UnchangedModel id="M1" source="BIOMODEL86.xml" type="SBML / CellML / BioPAX" /> <ChangedModel id="C1" name="Model86 with changes" modelReference="M1"> <ListOfChangeReferences> <ChangeReference reference="P1" /> <ChangeReference reference="A1" /> </ListOfChangeReferences> </ChangedModel> </ListOfModels> as you see ... there is no direct inheritance from the UnchangedModel ... no source attribute :) .. you also see ... for the ListOfModels ... nothing would change ... it would only be for the actual Modification that specific language knowledge is needed >> >> > Any other opinions on that? The question is: Is the model version > information so much important that we would want to query it directly > before choosing a simulation task? (Or are there only a few cases when > the version is needed and we can use libSBML for that?) > -> Just imagining we want to query a set of MIASE files to find a > simulation setting that we can use with our model - in a specific > version and level. Then we would want to be able to query the version > information directly, right? > (I am not sure though how this could work using libSBML, I am just > afraid it might be far more effort than querying the information in > the > XML file) > For all intents and purposes ... levels and versions in SBML actually play a minor role ... most of the time conversion happens flawlessly ... in fact it only was at the beginning that we had to query the SBML level and based on that define id's or name's ... The point I'm trying to make is that I'm not sure you would ever want to query just the SBML level and version of a model. Given that whatever is specified in the ListOfChanges / ListOfVariables is much more dependent on a single SBML model (as it contains actual SBML id's of that model), you would be more interested in that rather than the level and version of the original document. >>> >> >> Hm ... I'll wait and see the final version ... so far it seems >> different >> from what I expected ... >> >> - unchanged model should have (id, type, source) >> - changed model a reference to unchanged and references to >> modifications :) >> > So, Frank, you do agree with Ion here? I guess that was the point I > did > not get in Okinawa: What is the use of storing a model reference in an > unchangedModel element, and then referencing this model again using a > changedModel element? Why don't we just reference a model in a model > repository and store modifications on it (as this referenced model > is an > unchanged model anyways)? > > I made up an example above that should help sort this out a bit more ... cheers Frank |
|
From: Dagmar K. <dk...@in...> - 2008-02-11 00:22:14
|
(just commenting on the first parts and skipping everything starting from expressions ;)) Frank Bergmann wrote: >>> 6. ChangedModel and UnchangedModel classes should be ChangedSBMLModel >>> >> and UnchangedSBMLModel, reflecting the current support for SBML format; >> their "type" attribute (inherited from model) should be "SBML"; >> additional similar subclasses are to be expected in the future, e.g. >> for CellML, BioPAX3, VCML models etc. >> >> As the model type says "SBML" already, what is the reason to stress >> that >> in the name of the changed/unchangedModel as well? That would result in >> a number of different classes - on for each supported format. In my >> opinion this is just redundant!? >> > > > The thing is ... we have a hard time anticipating the sort of changes > possible in another language ... just imagine to change the components in a > CellML model ... you would need a different language to go about doing this. > To accommodate this we have added the type (e.g.: SBML) to the unchanged > model ... this way if you look for models modifying this model you would > look for the SBMLtype of changed models. > But what you will have is something similar to: <changedModel id="123" type="SBML" source="http://..."> <modelModification link="linkToModelModification" /> </changedModel> <listOfChanges> <SBMLModelModificationInformation /> </listOfChanges> So, we should find a way of encoding the modifications differently, but in my opinion that has nothing to do with the changedModel element, does it? > >>> 7. Open question regarding #6 above: should the language version and >>> >> level be specified in the "type" attribute? i.e. should we have a finer >> granularity, like type=SBML_L2_R3? >> >> We could have optional version and level/subversion attributes here!? >> > > I don't really think that is necessary ... supposing our SBML reading > capabilities are what they are (thanks to libSBML) different levels / > versions should not make much of a difference. > Any other opinions on that? The question is: Is the model version information so much important that we would want to query it directly before choosing a simulation task? (Or are there only a few cases when the version is needed and we can use libSBML for that?) -> Just imagining we want to query a set of MIASE files to find a simulation setting that we can use with our model - in a specific version and level. Then we would want to be able to query the version information directly, right? (I am not sure though how this could work using libSBML, I am just afraid it might be far more effort than querying the information in the XML file) >>> 8. ChangedModel should have 1 required attribute, modelReference, >>> >> referencing one UnchangedModel; it should also have 1 or more elements >> referencing 1 or more Modification to be applied to the unchanged model >> >> ChangedModel so far has and id, a type and a reference to a source. So >> the source is the reference to an unchanged model, isn't it? >> Additionally, you have the link to a certain modelModification. So, >> everything should be in here. If we want to reference to an unchanged >> model instead, we should probably change the inheritance relation >> between the three (model-changedModel-unchangedModel) somehow. But in >> my >> opinion it should as well work the way it is now!? >> > > Hm ... I'll wait and see the final version ... so far it seems different > from what I expected ... > > - unchanged model should have (id, type, source) > - changed model a reference to unchanged and references to modifications :) > So, Frank, you do agree with Ion here? I guess that was the point I did not get in Okinawa: What is the use of storing a model reference in an unchangedModel element, and then referencing this model again using a changedModel element? Why don't we just reference a model in a model repository and store modifications on it (as this referenced model is an unchanged model anyways)? Dagmar (and yes, we are getting closer :)) >>> 9. Expression class needs some more significant changes. Basically, >>> >> it will have a listOfDeclaredParameters (declared locally, that is), >> which you already have OK; then it needs a listOfSymbols (see 10 >> below); and it needs a Math element, which again is OK the way you have >> it (the syntax in the example which you are referring to is indeed >> specific to the MathML language) >> > > I'm still not sure we will need the listOfDeclaredParameters ... not quite > sure why we would have them. We have a list of variables from the different > task outcomes ... and everything else should be perfectly well contained in > the MathML ... so ... uhm ... what would I used those declared parameters > for? > > >>> 10. Symbol class - this defines the symbols that are being used in >>> >> addition to the declared parameters in the Math of an Expression in >> order to compute the actual values for the data column; a Symbol can be >> of 2 types: (i) a predefined symbol, like ___TIME___ (the only one that >> we discussed in Okinawa, for simulation time), or (ii) a locally >> defined symbol, which could be (most often) a variable from a model >> (e.g. a Species in an SBML model), but also a parameter from within >> that model; such locally defined symbol needs 2 attribute, a >> taskReference (from which it can uniquely access the model and >> simulation results), and an identifierReference (e.g. a >> SpeciesReference or a ParameterReference), pointing to the approipriate >> id in the Model referenced by the Task >> >>> Sorry if #10 sounds complicated, it really isn't, maybe I'm just not >>> >> explaining it very clearly... (for example an Expression class might >> want to describe something like (v1+v2)/2 where it would define symbols >> v1 and v2 as some species references from some task(s) and "2" as a >> locally declared parameter) >> >> Ok, that does seem to make sense. I'll wait for your model before >> making >> changes. >> > > I do think we are getting close :) > > Cheers > Frank > > -- Dagmar Koehn,GRK dIEM oSiRiS, http://www.diemosiris.de Joachim-Jungius-Strasse 9, D-18059 Rostock, Germany Tel: 0049-381-4987440, dk...@in... |
|
From: Frank B. <fbergman@u.washington.edu> - 2008-02-11 00:02:45
|
> > 6. ChangedModel and UnchangedModel classes should be ChangedSBMLModel > and UnchangedSBMLModel, reflecting the current support for SBML format; > their "type" attribute (inherited from model) should be "SBML"; > additional similar subclasses are to be expected in the future, e.g. > for CellML, BioPAX3, VCML models etc. > > > As the model type says "SBML" already, what is the reason to stress > that > in the name of the changed/unchangedModel as well? That would result in > a number of different classes - on for each supported format. In my > opinion this is just redundant!? The thing is ... we have a hard time anticipating the sort of changes possible in another language ... just imagine to change the components in a CellML model ... you would need a different language to go about doing this. To accommodate this we have added the type (e.g.: SBML) to the unchanged model ... this way if you look for models modifying this model you would look for the SBMLtype of changed models. > > > > 7. Open question regarding #6 above: should the language version and > level be specified in the "type" attribute? i.e. should we have a finer > granularity, like type=SBML_L2_R3? > > > We could have optional version and level/subversion attributes here!? I don't really think that is necessary ... supposing our SBML reading capabilities are what they are (thanks to libSBML) different levels / versions should not make much of a difference. > > > > 8. ChangedModel should have 1 required attribute, modelReference, > referencing one UnchangedModel; it should also have 1 or more elements > referencing 1 or more Modification to be applied to the unchanged model > > > ChangedModel so far has and id, a type and a reference to a source. So > the source is the reference to an unchanged model, isn't it? > Additionally, you have the link to a certain modelModification. So, > everything should be in here. If we want to reference to an unchanged > model instead, we should probably change the inheritance relation > between the three (model-changedModel-unchangedModel) somehow. But in > my > opinion it should as well work the way it is now!? Hm ... I'll wait and see the final version ... so far it seems different from what I expected ... - unchanged model should have (id, type, source) - changed model a reference to unchanged and references to modifications :) > > > > 9. Expression class needs some more significant changes. Basically, > it will have a listOfDeclaredParameters (declared locally, that is), > which you already have OK; then it needs a listOfSymbols (see 10 > below); and it needs a Math element, which again is OK the way you have > it (the syntax in the example which you are referring to is indeed > specific to the MathML language) > > I'm still not sure we will need the listOfDeclaredParameters ... not quite sure why we would have them. We have a list of variables from the different task outcomes ... and everything else should be perfectly well contained in the MathML ... so ... uhm ... what would I used those declared parameters for? > > 10. Symbol class - this defines the symbols that are being used in > addition to the declared parameters in the Math of an Expression in > order to compute the actual values for the data column; a Symbol can be > of 2 types: (i) a predefined symbol, like ___TIME___ (the only one that > we discussed in Okinawa, for simulation time), or (ii) a locally > defined symbol, which could be (most often) a variable from a model > (e.g. a Species in an SBML model), but also a parameter from within > that model; such locally defined symbol needs 2 attribute, a > taskReference (from which it can uniquely access the model and > simulation results), and an identifierReference (e.g. a > SpeciesReference or a ParameterReference), pointing to the approipriate > id in the Model referenced by the Task > > > > Sorry if #10 sounds complicated, it really isn't, maybe I'm just not > explaining it very clearly... (for example an Expression class might > want to describe something like (v1+v2)/2 where it would define symbols > v1 and v2 as some species references from some task(s) and "2" as a > locally declared parameter) > > > Ok, that does seem to make sense. I'll wait for your model before > making > changes. I do think we are getting close :) Cheers Frank |
14 messages has been excluded from this view by a project administrator.
