Re: [Miase-discuss] miase-discuss

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

(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...