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