sed-ml-discuss — Migrating to google groups: https://groups.google.com/d/forum/sed-ml-discuss

Re: [Miase-discuss] miase-discuss

[Dagmar K. <dk...@in...>]

Hej,

1. Seems everybody in your recipient list is on miase-discuss already - 
except Sven and Nicolas.
> 3. I have an updated .dia file that includes some of the additions/changes that I am describing below, should I just email it to you for now?
>   
Yes, please.
>  
> 5. Modification class - should have one subclass for now, SBMLModelModification, specific on how to describe changes to a Model that is in SBML format
>   
I agree.
>  
> 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!?
>  
> 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!?
>  
> 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!?
>  
> 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)
>  
> 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.
Dagmar

-- 
Dagmar Koehn,GRK dIEM oSiRiS, http://www.diemosiris.de
Joachim-Jungius-Strasse 9, D-18059 Rostock, Germany
Tel: 0049-381-4987440, dk...@in...

Re: [Miase-discuss] miase-discuss

[Michael H. <mh...@ca...>]

  Moraru> Also, I've added Mike to the recipients list -

Thanks, but I'm on miase-discuss already...

MH

Re: [Miase-discuss] miase-discuss

[Moraru,Ion <Mo...@NE...>]

Hi Dagmar,
 
I subscribed to the maillist, and I'm posting this message there, too, but I am keeping the email recipients until everybody subscribes - I can't see who subscribed already, since the list of subscribers is hidden...
 
Also, I've added Mike to the recipients list - Mike, please check out the sourceforge page for latest OM diagram and a little digest of our previous email exchanges that Dagmar has put on the maillist.
 
OK, now getting to the subject:
 
1. developer list / who has rights to upload - sure, it is fine to wait for Nicolas to get back until acting on that
 
2. current version of OM diagram (I looked at version 1.5) is now much improved, close to the final example and proposal from Okinawa
 
3. I have an updated .dia file that includes some of the additions/changes that I am describing below, should I just email it to you for now?
 
4. I like the alternative of subclassing from MBase, instead of SBase (but where MBase provides /almost/ the same stuff as SBase), it is cleaner that way, especially since we agreed that MIASE should support more formats than just SBML
 
5. Modification class - should have one subclass for now, SBMLModelModification, specific on how to describe changes to a Model that is in SBML format
 
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.
 
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?
 
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
 
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)
 
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)
 
Cheers,
Ion
 

________________________________

From: Dagmar Koehn [mailto:dk...@in...]
Sent: Fri 2/8/2008 2:53 AM
To: Moraru,Ion
Cc: Frank Bergmann; Henning Schmidt; Boss; Sven Sahle; Akira Funahashi
Subject: miase-discuss



Hej Ion,
hej all,

ignoring all the comments in all the other mails for the moment,
I just wanted to ask you to subscribe to miase-discuss on sourceforge -
that might be a much more convenient way of communicating... and now
that the mailing list is (finally) working - why not use it :)

mia...@li...

Dagmar

--
Dagmar Koehn,GRK dIEM oSiRiS, http://www.diemosiris.de <http://www.diemosiris.de/> 
Joachim-Jungius-Strasse 9, D-18059 Rostock, Germany
Tel: 0049-381-4987440, dk...@in...

Re: [Miase-discuss] miaseOM

[Dagmar K. <da...@eb...>]

Heho,
>> You are right. I did not put those changes in the UML so far, because I
>> actually couldn't remember the reason(s) to do that.
>> Can anyone explain again?
>>     
>
> Sorry ... explain what?
>   
I was looking at the part of the example file that specifies the output:
- why was the listOfVariables on the same level as listOfFigures and 
listOfColumns?
- why did we specify SBMLSymbolReferences and how did the ___TIME___ 
thing work?
... I am not sure if that bit was done shortly before the lunch break or 
what happened to me so that I really can't follow the XML file design at 
that point, so if someone of you could explain it again :) That would be 
nice.
Otherwise, I'll just put it in the OM and we'll see what people say and 
discuss it later on (hopefully South Africa meeting).
>> Concerning your remark on my data types: I think I didn't put any so
>> far actually (all being strings). Thought to fix that later on. But
>> suggestions are welcome :)
>>     
>
> Hm ... I am sure I saw a "positiveInteger" on those types :) 
>   
Well is there? ;) I actually decided to skip data types, but I might 
have been inconsistent on that!

>> Does anybody want to suggest an SBase like class for MIASE? How do we
>> name it and what attributes will it have?
>>     
> Actually, you could just take it as is from the SBML spec, strip the SBO
> term and call it SBase / MBase
>   
I'll do so. Go for MBase until further objection.
>   
>> Do we give the annotation element any specific structure or do we just
>> say: "Put the extra information in the annotation" and provide an
>> example of how to do it?
>>     
>
> I would say for right now we do not have to clarify that point :) ... ymmv
>   
ymmv?

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

Re: [Miase-discuss] miaseOM

[Frank B. <fbergman@u.washington.edu>]

Heja, 

I guess I keep this short: 


> I have taken that one as an example now.



> I have changed that in the new version (on sourceforge). I was just
> wondering: What was the reason that we did not put the listOfChanges
> inside the changedModels? I guess it was because we wanted to apply one
> change to more than one model. Still, the way you described the
> listOfModels above, it would make more sense to put the changes
> directly on the changedModels... Just so that we are sure that the way we
do
> things is correct :)

Correct, you might want to apply changes to for example a series of models,
all coming from the same WildType. We thought it could look like this: 

<ListOfChanges>
	<SBMLParameterChange id="PChange1"
someAttributesTellingWhatParameterToChangeHow/>
	<SBMLAssignmentRuleChange id = "AChange1"
someMoreSpecificAttributesAndElementscontainingarule/>
</ListOfChanges>
<ListOfModels>
	<UnchangedModel id="M1" source="BIOMODEL86.xml" type="SBML / CellML
/ BioPAX"/>
	<ChangedModel id="M2" name="Model86 with changes"
modelReference="M1">
		<ListOfChangeReferences>
			<ChangeReference reference="PChange1"/>
		</ListOfChangeReferences>
	</ChangedModel>
</ListOfModels>


> You are right. I did not put those changes in the UML so far, because I
> actually couldn't remember the reason(s) to do that.
> Can anyone explain again?

Sorry ... explain what?

> 
> Concerning your remark on my data types: I think I didn't put any so
> far actually (all being strings). Thought to fix that later on. But
> suggestions are welcome :)

Hm ... I am sure I saw a "positiveInteger" on those types :) 

> 
> Does anybody want to suggest an SBase like class for MIASE? How do we
> name it and what attributes will it have?
Actually, you could just take it as is from the SBML spec, strip the SBO
term and call it SBase / MBase

> Do we give the annotation element any specific structure or do we just
> say: "Put the extra information in the annotation" and provide an
> example of how to do it?

I would say for right now we do not have to clarify that point :) ... ymmv

> 
> Basically, we are describing that in order to produce a certain
> "simualtion result" (e.g. a figure in a paper), one would have to take
> one, or more, models (SBML or otherwise), apply none, or some, changes
> to them (different parameters, or initial conditions, etc.), then run
> one, or more, simulations, using some specific simulator settings, than
> take the variable values obtained from those simulations and combine
> them using one or more arbitrary mathematical expressions
> (postprocessing), and then use the resulting collection of numerical
> data sets ("columns") and put them together in one or more graphs, as
> specified.  Whew!
> 

There you go ... that's quite a mouthful ...  I would have preferred
something simpler myself, but in order to keep it extensible I guess this is
the way it has to be. 

> Have a nice weekend in case we don't speak again before (oh yes, I know
> we will).

And a great weekend from here :) 
Cheers
Frank

Re: [Miase-discuss] miaseOM

[Dagmar K. <dk...@in...>]

Hej Frank,
hej all,

> Thank you so much ... from the UML point of view things look nice, however
> it does not seem to correspond to what we had in the last version: 
>
> http://sys-bio.org/fbergman/MiaseBrainStorm_Biomodel8.xml
>   
I have taken that one as an example now.
> here we had a listOfModels as top level element, which in turn could consist
> of unchanged model instances or changed model instances with list of
> changes. In your UML diagram those still belong only to the tasks. 
>   
I have changed that in the new version (on sourceforge). I was just 
wondering: What was the reason that we did not put the listOfChanges 
inside the changedModels? I guess it was because we wanted to apply one 
change to more than one model. Still, the way you described the 
listOfModels above, it would make more sense to put the changes directly 
on the changedModels... Just so that we are sure that the way we do 
things is correct :)
> Also the listOfVariables was in the final version on the same level as
> ListOfFigures and ListOfColumns. And there was no listOfParameters anymore
>   
You are right. I did not put those changes in the UML so far, because I 
actually couldn't remember the reason(s) to do that.
Can anyone explain again?

Concerning your remark on my data types: I think I didn't put any so far 
actually (all being strings). Thought to fix that later on. But 
suggestions are welcome :)


Does anybody want to suggest an SBase like class for MIASE? How do we 
name it and what attributes will it have?


[From Ions Mail]

 
- we describe 4 types of things: (i) what models, with or without changes, were simulated - in listOfModels, (ii) what were the simulation-specific settings - in listOfSimulations, (iii) what combination of the above two things were done in the actual simulation jobs - in listOfTasks, and (iv) what data was extracted, and how, from the one or more jobs described by the tasks, and how the data was represented graphically - in listOfOutputs


That's a good summary on what we agreed on. Raises the 
listOfModelChanges issue again!?

 
- the concrete details of an actual accomplishment of a "simulation experiment" described in a MIASE file would not be part of the MIASE specification, but would be included in SBML-style annotation elements (e.g. what simulator software was used, what version, on what platform, etc.)


Do we give the annotation element any specific structure or do we just 
say: "Put the extra information in the annotation" and provide an 
example of how to do it?

 
Basically, we are describing that in order to produce a certain "simualtion result" (e.g. a figure in a paper), one would have to take one, or more, models (SBML or otherwise), apply none, or some, changes to them (different parameters, or initial conditions, etc.), then run one, or more, simulations, using some specific simulator settings, than take the variable values obtained from those simulations and combine them using one or more arbitrary mathematical expressions (postprocessing), and then use the resulting collection of numerical data sets ("columns") and put them together in one or more graphs, as specified.  Whew!
 

Then, for the project developer issue: As Nicolas is the boss and he is 
on holiday... can we postpone the decision of to whome to give the 
sourceforge rights until FEB 17th? Until then, I can update the MIASE-OM 
versions for you if you want to!? Hope that is an exceptable compromise?!

Guys, thanks for all your input!
Have a nice weekend in case we don't speak again before (oh yes, I know 
we will).
Dagmar

-- 
Dagmar Koehn,GRK dIEM oSiRiS, http://www.diemosiris.de
Joachim-Jungius-Strasse 9, D-18059 Rostock, Germany
Tel: 0049-381-4987440, dk...@in...

[Miase-discuss] mailing list working

[Dagmar K. <da...@eb...>]

Hej all,

the mailing list should now (finally) work properly!

Sorry for the inconvenience, there seemed to be a problem with the 
sourceforge account.

News from the MIASE/KiSAO side: We are currently working on a MIASE 
object model draft which you will find in the sourceforge cvs 
http://miase.cvs.sourceforge.net/miase/miaseOM/miaseOM/ .

Additionally, a first version of KiSAO is available from the download 
section - including a short documentation 
https://sourceforge.net/project/showfiles.php?group_id=20666 .


Kind regards,
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

[Miase-discuss] Test email

[Jeremy F. <jfi...@co...>]

This is a test email sent to test the function of the SourceForge.net  
email system.

--
Jeremy Fincher

Systems Programmer/Analyst, SourceForge.net
fi...@us...
jfi...@co...

************************************************************************ 
*
This email may contain confidential and privileged material for the
sole use of the intended recipient. Any review or distribution by
others is strictly prohibited. If you are not the intended recipient,
please contact the sender and delete all copies.
************************************************************************ 
*