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

Re: [Miase-discuss] MIASE-ML independent of SBML

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

On Mar 12, 2008, at 4:44 AM, Dagmar Koehn wrote:

> Nicolas Le novère wrote:
>> Frank Bergmann wrote:
>>
>>
>>>>> To make it short ... if my software were to write a MIASE file
>>>>> changing an
>>>>> element of the model, it would make sure it would have an id.
>>>>>
>>>> Well, actually, if you really want to use a real "id", you would
>>>> have to use the metaid attribute. But being not mandatory in SBML,
>>>> that is actually unfeasible. And again, an XPath is the perfect id
>>>> to identify unambiguously and XML element.
>>>>
>>> I did not really think it was unfeasible, given the fact that the
>>> software already had to indicate an interest of changing that  
>>> element,
>>> when creating the MIASE file, it would have been absolutely possible
>>> to tag it by a (meta) id.
>>>
>>
>> But you assume your software created both the SBML file and the MIASE
>> file.
>
> Thats the point- we can't assume that all the tools do the same
> pre-processing on the model files, so everything that is done to the
> model internally (like internal ids for elements or whatever you do
> there) cannot be used in MIASE, because it will not work when used in
> another software, right?

Actually there would be no problem with that, the modifications *if*  
necessary would be made in the way prescribed by the MIASE spec :) so  
every software would be able to interpret the Id's ...

>
>> I guess this is where the problem (or the misunderstanding) lies.
>> But I think I start seeing what you mean (of I think I do). You  
>> read the
>> SBML file anyway, wherever it comes from, so you can rewrite it  
>> when you
>> generate the MIASE file. And thus provide an "updated" version of the
>> SBML file together with the MIASE file. In that respect, yes, your
>> approach makes sense.
>>
>
> Nicolas, Frank: Just to make sure that I am missing something here.  
> Does
> that mean that with a MIASE file you might provide an updated  
> version of
> the model file as well? (Where do you put that updated model then? I
> mean, where would you store it physically?)
> I thought we were not providing any updated SBML/model file here, but
> rather record the changes so that we just reuse the same model, and  
> then
> apply the different changes we wanted to make on them. There is no use
> in storing the same model over and over again, right?! (As long as we
> consider it to be still the same model...)
>

That is the point we needed to get to ... initially i was hoping of  
being able to embed a subset of MIASE directly in a model, this would  
be extremely useful for us (and the COPASI folks among others), and  
would completely bypass any relocation issues. But i totally  
understand that you and Nicolas are absolutely opposed to it. The  
thing is ... as the MIASE ML and the model file will be two separate  
things, the model file will have to be accessible from the MiaseML  
file ... you already have a location/source string in the OM ...

But don't get me wrong ... modifications of model or model location  
won't be necessary if they are still valid after saving a new MiaseML  
file

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

Re: [Miase-discuss] Purpose of MIASE ?

[Sven S. <sve...@bi...>]

Hello all,

I think I would answer "both" to Ions question. Basically documenting  
what has been done to get a result is structurally similar to  
describing what needs to be done to reproduce a result.

And I can imagine that an implementation of MIASE can also be used for  
day to day simulation work. So a subset of MIASEML could be used by  
Copasi (and other simulators) to store the simulation and output  
settings in an interchangable format. We would probably (even without  
official approval) also put it inside an sbml file (annotation).

Sven

Re: [Miase-discuss] Purpose of MIASE ?

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

I would say...

Moraru,Ion wrote:
>  
> Is this supposed to describe what has been done?  Unambigously document a simulation experiment?  Stored in databases of models and modeling studies?  And used mainly by curators and by modelers only when they wish to "publish" results?
>   

Yes. That's one of the use cases.. (remove the "only")
>  
> Is this supposed to be a recipe on what to do? Instructions for a simulation tool to produce results? Stored anywhere?  And used day-to-day by modelers to organize their work, as in JigCell run files, VCell simulation specifications, CellML simulation metadata?
>   

It is supposed to be a "recipe on what to do". But for every day life 
modeling and simulation/organizing modelers work I tend to think that 
people would rather use the internal storing mechanisms of the 
simulation tool - as soon as it comes to exporting and exchanging things 
(as well as publishing) MIASE would step in.

Dagmar

Re: [Miase-discuss] Purpose of MIASE ?

[Nicolas Le n. <le...@eb...>]

Moraru,Ion wrote:
> All:
>  
> I think people have different concepts as to what the purpose of MIASE is.  This is obvious from both the discussions in Okinawa and the posts on this list.
>  
> Is this supposed to describe what has been done?  Unambigously document a simulation experiment?  Stored in databases of models and modeling studies?  And used mainly by curators and by modelers only when they wish to "publish" results?
>  
> Is this supposed to be a recipe on what to do? Instructions for a simulation tool to produce results? Stored anywhere?  And used day-to-day by modelers to organize their work, as in JigCell run files, VCell simulation specifications, CellML simulation metadata?
>  
> Both of the above?
>  
> Let's try to establish this before making major decisions on ML technical aspects.  It is hard to resolve divergences in opinions on language details without a consensus on the short-term and long-term purpose of the language.

Jut a bit of precision before we get in the core of the discussion...

MIASE itself is not a language. MIASE stands for Minimum Information 
required to Annotate a Simulation Experiment. Thus, it is meant to 
describe what we do to a model in order to get a result.

*One* way to implement MIASE is to encode this description in a standard 
format. The blessed one would be MIASE-OM, serialised in MIASE-ML.

(But one can image someone describing a simulation experiment with words)

MIASE eq MIRIAM eq MIAPE eq MIAME
MIASE-OM eg SBML eq PSI-MI eq MAGE-OM


-- 
Nicolas LE NOVERE,  Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223494521, Fax: 468, Mob: +44(0)7833147074  Skype:n.lenovere
http://www.ebi.ac.uk/~lenov, AIM: nlenovere, MSN: nle...@ho...

[Miase-discuss] Purpose of MIASE ?

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

All:
 
I think people have different concepts as to what the purpose of MIASE is.  This is obvious from both the discussions in Okinawa and the posts on this list.
 
Is this supposed to describe what has been done?  Unambigously document a simulation experiment?  Stored in databases of models and modeling studies?  And used mainly by curators and by modelers only when they wish to "publish" results?
 
Is this supposed to be a recipe on what to do? Instructions for a simulation tool to produce results? Stored anywhere?  And used day-to-day by modelers to organize their work, as in JigCell run files, VCell simulation specifications, CellML simulation metadata?
 
Both of the above?
 
Let's try to establish this before making major decisions on ML technical aspects.  It is hard to resolve divergences in opinions on language details without a consensus on the short-term and long-term purpose of the language.
 
Ion
 
 
 
 
 

Re: [Miase-discuss] MIASE-ML independent of SBML

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

Nicolas Le Novere wrote:
> Dagmar Koehn wrote:
>
>   
>>> I like it, I agree with Nicolas that it is a better and more flexible
>>> approach.  I never liked having specific classes to describe specific
>>> changes.  The reason why specific classes were proposed in Okinawa is
>>> because people wanted to explicitly show what kind of models (languages)
>>> and what kind of changes to models are being supported.  
>>>       
>> The disadvantage being that you restrict the changes in quite a harsh 
>> way by defining the attributes that can be changed. I think the whole 
>> question here really comes down to: How generic do we want to be?
>>     
>
> But that is not uncompatible. There is a difference between what we CAN do, and what we MAY do. In SBML, we CAN used any MathML construct in a kineticLaw, but in the spec (and the associated XML-schema) we restrict the subset of MathML we use. To use XPath to target a specific element or attribute does not mean in MIASE-ML Level 1 Version 1 Release 1 we can use ANY valid XPath expression. We can perfectly say that for the time being, the prototyping stage, we allow only simple changes to the values of global parameters and species initial quantities.
>
> The problem is that if we start creating specific classes for this and that, we will have 1) to follow this pass when we extend the scope of MIASE and 2) maintain those classes in the future.
>
>   
>>> and (ii) it is not very
>>> descriptive, and it may be hard to understand what kind of changes were
>>> done to the models in a particular simulation experiment.
>>>       
>
> I do not understand that. An XPath is very explicit. You can actually READ what the change is, without the need of analysing which class you are using etc.  
>   

It is easy for reading the file into your simulation tool. But the 
difficulty more is on the side of really *searching* for a specific 
MIASE descpription (eg. when having stored 100 simulation runs on a 
model - how do you find the one where you set a certain parameter to a 
certain value quickly!?) ...
>   
>> That is what I thought about before as well - if we put XPath 
>> expressions in the XML file, it might be harder to perform query/search 
>> (without mapping the XML to relational again). 
>>     
>
> XPath is meant to be used for searching. 
>
>   
>> I am not sure though if 
>> this could be solved by using a native XML database to build up the 
>> MIASE repository (Nicolas, I know what you are about to say ;)).
>>     
>
> No, no, no. No need to anything like that. 

Predicted answer ;)

> You can either directly read the XML, or interpret the XPath and use libSBML to get and set the adequat object. No need of database etc.
>   

Again, I was not talking about how the simulation tool handles the XPath 
(that's probably fine), but I was talking about how people store their 
MIASE files they want to exchange/make available.
Dagmar

Re: [Miase-discuss] MIASE-ML independent of SBML

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

Nicolas Le novère wrote:
> Frank Bergmann wrote:
>
>   
>>>> To make it short ... if my software were to write a MIASE file  
>>>> changing an
>>>> element of the model, it would make sure it would have an id.
>>>>         
>>> Well, actually, if you really want to use a real "id", you would  
>>> have to use the metaid attribute. But being not mandatory in SBML,  
>>> that is actually unfeasible. And again, an XPath is the perfect id  
>>> to identify unambiguously and XML element.
>>>       
>> I did not really think it was unfeasible, given the fact that the  
>> software already had to indicate an interest of changing that element,  
>> when creating the MIASE file, it would have been absolutely possible  
>> to tag it by a (meta) id.
>>     
>
> But you assume your software created both the SBML file and the MIASE 
> file. 

Thats the point- we can't assume that all the tools do the same 
pre-processing on the model files, so everything that is done to the 
model internally (like internal ids for elements or whatever you do 
there) cannot be used in MIASE, because it will not work when used in 
another software, right?
> I guess this is where the problem (or the misunderstanding) lies. 
> But I think I start seeing what you mean (of I think I do). You read the 
> SBML file anyway, wherever it comes from, so you can rewrite it when you 
> generate the MIASE file. And thus provide an "updated" version of the 
> SBML file together with the MIASE file. In that respect, yes, your 
> approach makes sense.
>   

Nicolas, Frank: Just to make sure that I am missing something here. Does 
that mean that with a MIASE file you might provide an updated version of 
the model file as well? (Where do you put that updated model then? I 
mean, where would you store it physically?)
I thought we were not providing any updated SBML/model file here, but 
rather record the changes so that we just reuse the same model, and then 
apply the different changes we wanted to make on them. There is no use 
in storing the same model over and over again, right?! (As long as we 
consider it to be still the same model...)


Hmm.
Dagmar

Re: [Miase-discuss] MIASE-ML independent of SBML

[Nicolas Le N. <le...@eb...>]

Dagmar Koehn wrote:

>> I like it, I agree with Nicolas that it is a better and more flexible
>> approach.  I never liked having specific classes to describe specific
>> changes.  The reason why specific classes were proposed in Okinawa is
>> because people wanted to explicitly show what kind of models (languages)
>> and what kind of changes to models are being supported.  
> 
> The disadvantage being that you restrict the changes in quite a harsh 
> way by defining the attributes that can be changed. I think the whole 
> question here really comes down to: How generic do we want to be?

But that is not uncompatible. There is a difference between what we CAN do, and what we MAY do. In SBML, we CAN used any MathML construct in a kineticLaw, but in the spec (and the associated XML-schema) we restrict the subset of MathML we use. To use XPath to target a specific element or attribute does not mean in MIASE-ML Level 1 Version 1 Release 1 we can use ANY valid XPath expression. We can perfectly say that for the time being, the prototyping stage, we allow only simple changes to the values of global parameters and species initial quantities.

The problem is that if we start creating specific classes for this and that, we will have 1) to follow this pass when we extend the scope of MIASE and 2) maintain those classes in the future.

>> and (ii) it is not very
>> descriptive, and it may be hard to understand what kind of changes were
>> done to the models in a particular simulation experiment.

I do not understand that. An XPath is very explicit. You can actually READ what the change is, without the need of analysing which class you are using etc.  

> That is what I thought about before as well - if we put XPath 
> expressions in the XML file, it might be harder to perform query/search 
> (without mapping the XML to relational again). 

XPath is meant to be used for searching. 

> I am not sure though if 
> this could be solved by using a native XML database to build up the 
> MIASE repository (Nicolas, I know what you are about to say ;)).

No, no, no. No need to anything like that. You can either directly read the XML, or interpret the XPath and use libSBML to get and set the adequat object. No need of database etc.

Re: [Miase-discuss] MIASE-ML independent of SBML

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

Moraru,Ion wrote:
> Since I'm just catching up to email after 3 rounds, I'm not going to
> further indent comments throughout the text, it is becoming difficult to
> follow, I'm summarizing my opinions here.
>
> The discussions address 3 changes to the OM, one major, two minor.  
>
> 1. XPath:
>
> I like it, I agree with Nicolas that it is a better and more flexible
> approach.  I never liked having specific classes to describe specific
> changes.  The reason why specific classes were proposed in Okinawa is
> because people wanted to explicitly show what kind of models (languages)
> and what kind of changes to models are being supported.  

The disadvantage being that you restrict the changes in quite a harsh 
way by defining the attributes that can be changed. I think the whole 
question here really comes down to: How generic do we want to be?
> I would prefer
> to use XPath, but I also agree with Frank that it is simple from MIASE
> perspective, but it really is not "starting small".  It implies to a a
> certain degree that any and all types of models/changes must be
> supported by MIASE software (you can't know offhand what to expect when
> there can be some generic unlimited XML changes).  

If it is for starting small, we could as well restrict the changes we 
would allow for the first MIASE examples in a textual way - to make sure 
we don't end up with super-complicated examples.
Question is if all your tools can handle the XPath expressions they get 
from the MIASE description!? But I would suppose they can!?
> In my opinion, this
> is not an issue, I never really cared much about starting small.  The
> only potential problems I see with such a very generic approach without
> any specific model language support: (i) it makes it difficult in
> particular cases (like paramter scans), 

Ion, what would be the difficulty here??
> and (ii) it is not very
> descriptive, and it may be hard to understand what kind of changes were
> done to the models in a particular simulation experiment.
>   

That is what I thought about before as well - if we put XPath 
expressions in the XML file, it might be harder to perform query/search 
(without mapping the XML to relational again). I am not sure though if 
this could be solved by using a native XML database to build up the 
MIASE repository (Nicolas, I know what you are about to say ;)). It 
could actually be as efficient as using the sub-classing approach and 
storing the changes in a relational manner ... But in theory native XML 
storage *should* make it easy to query and compare the changes recorded 
in XPath...!?
> 2. Unchanged/changed model vs. Model + optional list of changes.
>
> Most of you know my side here :) I was fighting the changed/unchanged
> stuff to death, but to no avail...  Some folks were adamant about
> explicitly identifying in the listOfModels all "original" models and all
> the modified models that are variations starting from the same original.
>   

A model that does not have any changes applied will automatically be an 
original model. So I really do not see the point in storing the original 
models and then having an extra listOfChangedModels. But I didn't get it 
in Oki neither, so probably somebody has a good reason for that!?
> 3. Empty lists.
>
> I believe some listOfs could be empty, but that all top level lists
> (simulations, models, tasks, outputs) should not be empty.  A MIASE file
> is supposed to describe how a particular set of results have been
> produced (the "simulation experiment").  Therefore it must have at least
> one DataVector - this is what we describe, how we arrived at this data
> (but plots are obviously optional).  Any dataset must refer to at least
> one Task, and any task must refer to at least one Simulation and one
> Model.
>   

So, is it that in the end none of the listsOf can be empty? You 
mentioned the output, the task, the model and the simulation ;) Really 
not sure what to do here, actually...


Dagmar

[Miase-discuss] On combining graphical output and simulation information

[Andrew M. <ak....@au...>]

Dear all,

I notice that MIASE combines both metadata on how to carry out 
simulations with a metadata of how to graph them in a single specification.

While I am sure that such approach might be very convenient for 
graphical tools which perform simulations and then graph the results, I 
believe that simulation and graphing are quite different concerns 
(although the latter often depends on the former), and I am not sure 
that it is a very good design to lump the two together.

I would therefore suggest that creating two separate specifications, 
which can be implemented independently of each other (although they 
would still allow reference to information from the other), would be 
cleaner.  This is the approach which I have taken with the CellML 
Simulation Metadata 
(http://www.cellml.org/specifications/metadata/simulations/) and CellML 
Graph Metadata (http://www.cellml.org/specifications/metadata/graphs/) 
specifications.

There are potentially many different types of tool which perform one, 
but not both, of simulation and graphing, and it is still useful for 
these tools to exchange information. The MIASE specification as it 
stands is particularly unfriendly to such tools, because the composition 
of both Simulation and Output into Sed is one to one-or-more and not one 
to zero-or-more, meaning that at minimum, simulation-only tools need to 
specify a DataVector.

Best regards,
Andrew

[Miase-discuss] Specifying the variable(s) of integration / independent variable(s) in MIASE

[Andrew M. <ak....@au...>]

Dear all,

Based off the UML diagram at
http://miase.cvs.sourceforge.net/*checkout*/miase/miaseOM/miaseOM/miaseOM.pdf?revision=1.5 

, I notice that the UniformTimeCourse UML class makes the assumption
that the model is being evaluated across a time variable (in other
words, that time is special in some sense).

I understand that one of the goals of MIASE is for it to be format
independent. However, I believe that the assumption that time is special
harms the applicability to languages such as CellML (which aim to
represent models in a domain-independent form, which means that concepts
like time are not built into the standard, but rather, are defined as
part of the model).

As has been pointed out on an earlier thread on the MIAME mailing list,
https://sourceforge.net/mailarchive/forum.php?thread_name=18374.18884.225456.303727%40mellow.local&forum_name=miase-discuss 

, I have previously defined a short draft specification designed to
represent similar information (although I agree entirely with the idea
of replacing this with a better specification common to multiple
modelling languages).

The CellML Simulation Metadata focuses on the equivalent of the
UniformTimeCourse simulation. However, these simulations are composed of
one or more objects, which each associate with a variable in the CellML
model and the range of the variable over the simulation (in the common
case where time is the independent variable, there is one such object,
which references time, and the initialStartTime and initialEndTime
attributes on UniformTimeCourse simulation correspond to similar slots
on the object in CSM).

It looks like a structure similar to that used in CellML Simulation
metadata would make sense in MIASE too. This structure would have the
additional benefit of providing some of the simulation information
necessary for PDE simulations.

Best regards,
Andrew

Re: [Miase-discuss] MIASE-ML independent of SBML

[Nicolas Le n. <le...@eb...>]

Frank Bergmann wrote:

>> sbml/model/listOfSpecies/species[@id="atp"]/@initialConcentration
>> sbml/model/listOfParameters/parameter[@id="kon"]/@value
>> sbml/model/listOfReaction/reaction[@id="atpase"]/kineticLaw/ 
>> listOfParameters/parameter[@id="kcat"]/@value
>> model/component[name="C2"]/variable[name="C2"]/@initial_value
>>
>> (Note the different namespaces above for the component and the  
>> variable)
>>
> 
> Actually not so small anymore, generic it is by using XPath you allow  
> to change any and all values, not only in the named case like you do  
> it but also using relative values and indexes. Apart from being not  
> very readable ... aren't we missing something here? what you describe  
> so far are simple value changes ... how would you apply your approach  
> for a change of an assignment rule ...

What I describe above is the way to target something, not to change this 
something. When it comes to that, my approach is no different of yours. 
I think.

>>> To make it short ... if my software were to write a MIASE file  
>>> changing an
>>> element of the model, it would make sure it would have an id.
>> Well, actually, if you really want to use a real "id", you would  
>> have to use the metaid attribute. But being not mandatory in SBML,  
>> that is actually unfeasible. And again, an XPath is the perfect id  
>> to identify unambiguously and XML element.
> 
> I did not really think it was unfeasible, given the fact that the  
> software already had to indicate an interest of changing that element,  
> when creating the MIASE file, it would have been absolutely possible  
> to tag it by a (meta) id.

But you assume your software created both the SBML file and the MIASE 
file. I guess this is where the problem (or the misunderstanding) lies. 
But I think I start seeing what you mean (of I think I do). You read the 
SBML file anyway, wherever it comes from, so you can rewrite it when you 
generate the MIASE file. And thus provide an "updated" version of the 
SBML file together with the MIASE file. In that respect, yes, your 
approach makes sense.

-- 
Nicolas LE NOVERE,  Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223494521, Fax: 468, Mob: +44(0)7833147074  Skype:n.lenovere
http://www.ebi.ac.uk/~lenov, AIM: nlenovere, MSN: nle...@ho...

Re: [Miase-discuss] MIASE-ML independent of SBML

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

>
> Small but generic. This is what the problem is. Ion's data-model is  
> becoming quite large, and all the extra classes are dues to lack of  
> generality.
> And XPath is actually the way to start small. The only thing you  
> need is to build the path to the value you want to change:
>
> sbml/model/listOfSpecies/species[@id="atp"]/@initialConcentration
> sbml/model/listOfParameters/parameter[@id="kon"]/@value
> sbml/model/listOfReaction/reaction[@id="atpase"]/kineticLaw/ 
> listOfParameters/parameter[@id="kcat"]/@value
> model/component[name="C2"]/variable[name="C2"]/@initial_value
>
> (Note the different namespaces above for the component and the  
> variable)
>

Actually not so small anymore, generic it is by using XPath you allow  
to change any and all values, not only in the named case like you do  
it but also using relative values and indexes. Apart from being not  
very readable ... aren't we missing something here? what you describe  
so far are simple value changes ... how would you apply your approach  
for a change of an assignment rule ...

>> I really was fine with the consensus reached at Okinawa and
>> was under the impression that that was the first OM.
>
> I don't think what is currently in the CVS is the consensus reached  
> in Oki, is-it? Maybe I am wrong. If this is the case, I am doubly  
> guilty not to have been more attentive.
>

I'm no against XPath generally ... i was just initially hoping for a  
fast adoption ... (anyone else noticed that it has been a very long  
time we heard from Sven or Henning?) ... In fact the case solved in  
okinawa, was really just the most simplest one ... create a miase file  
carrying out the same simulation ...

>> To make it short ... if my software were to write a MIASE file  
>> changing an
>> element of the model, it would make sure it would have an id.
>
> Well, actually, if you really want to use a real "id", you would  
> have to use the metaid attribute. But being not mandatory in SBML,  
> that is actually unfeasible. And again, an XPath is the perfect id  
> to identify unambiguously and XML element.

I did not really think it was unfeasible, given the fact that the  
software already had to indicate an interest of changing that element,  
when creating the MIASE file, it would have been absolutely possible  
to tag it by a (meta) id. But still lets not mince words here ...

I'll just sit this one out until your proposed changes have made it  
into the UML or more importantly non-trivial examples :)

cheers
Frank

Re: [Miase-discuss] MIASE-ML independent of SBML

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

Since I'm just catching up to email after 3 rounds, I'm not going to
further indent comments throughout the text, it is becoming difficult to
follow, I'm summarizing my opinions here.

The discussions address 3 changes to the OM, one major, two minor.  

1. XPath:

I like it, I agree with Nicolas that it is a better and more flexible
approach.  I never liked having specific classes to describe specific
changes.  The reason why specific classes were proposed in Okinawa is
because people wanted to explicitly show what kind of models (languages)
and what kind of changes to models are being supported.  I would prefer
to use XPath, but I also agree with Frank that it is simple from MIASE
perspective, but it really is not "starting small".  It implies to a a
certain degree that any and all types of models/changes must be
supported by MIASE software (you can't know offhand what to expect when
there can be some generic unlimited XML changes).  In my opinion, this
is not an issue, I never really cared much about starting small.  The
only potential problems I see with such a very generic approach without
any specific model language support: (i) it makes it difficult in
particular cases (like paramter scans), and (ii) it is not very
descriptive, and it may be hard to understand what kind of changes were
done to the models in a particular simulation experiment.

2. Unchanged/changed model vs. Model + optional list of changes.

Most of you know my side here :) I was fighting the changed/unchanged
stuff to death, but to no avail...  Some folks were adamant about
explicitly identifying in the listOfModels all "original" models and all
the modified models that are variations starting from the same original.

3. Empty lists.

I believe some listOfs could be empty, but that all top level lists
(simulations, models, tasks, outputs) should not be empty.  A MIASE file
is supposed to describe how a particular set of results have been
produced (the "simulation experiment").  Therefore it must have at least
one DataVector - this is what we describe, how we arrived at this data
(but plots are obviously optional).  Any dataset must refer to at least
one Task, and any task must refer to at least one Simulation and one
Model.

Also, on the subject of Okinawa consensus.

The OM in CVS is indeed the consensus from the working group session
there, but that doesn't mean we shouldn't consider radical changes to
it.  It simply is a starting point which is complete, consistent, and
implementable (see included examples).  And Nicolas, you are not guilty
of not paying attention, you just weren't there at the last session, you
were at some SBGN working group...

Ion

>-----Original Message-----
>From: mia...@li... 
>[mailto:mia...@li...] On Behalf 
>Of Dagmar Koehn
>Sent: Tuesday, March 11, 2008 4:46 AM
>To: mia...@li...
>Subject: Re: [Miase-discuss] MIASE-ML independent of SBML
>
>This actually was Nicolas reply to Franks mail, I am just 
>being the secretary here ;)
>
>- - - -
>
>Subject:
>Re: [Miase-discuss] MIASE-ML independent of SBML
>From:
>Nicolas Le Novere <le...@eb...>
>Date:
>Tue, 11 Mar 2008 08:34:26 +0000
>
>To:
>Frank Bergmann <fbergman@u.washington.edu> Frank Bergmann wrote:
>> At the moment I can't see how the approach we have chosen so 
>far would 
>> have been dependent on version / level changes within the standards.
>
>Yes, because it relies on what the elements are, and to which 
>namespace they belong.
>
>
>> I guess it really depends here what we want to do. I was under the
>> assumption that we were trying to start *small* and have 
>some software
>> support fast. 
>
>Small but generic. This is what the problem is. Ion's data-model is 
>becoming quite large, and all the extra classes are dues to lack of 
>generality.
>And XPath is actually the way to start small. The only thing 
>you need is 
>to build the path to the value you want to change:
>
>sbml/model/listOfSpecies/species[@id="atp"]/@initialConcentration
>sbml/model/listOfParameters/parameter[@id="kon"]/@value
>sbml/model/listOfReaction/reaction[@id="atpase"]/kineticLaw/lis
>tOfParameters/parameter[@id="kcat"]/@value 
>
>model/component[name="C2"]/variable[name="C2"]/@initial_value
>
>(Note the different namespaces above for the component and the 
>variable)
>
>> I really was fine with the consensus reached at Okinawa and
>> was under the impression that that was the first OM. 
>
>I don't think what is currently in the CVS is the consensus reached in 
>Oki, is-it? Maybe I am wrong. If this is the case, I am doubly guilty 
>not to have been more attentive.
>
>> To make it short ... if my software were to write a MIASE file 
>> changing an
>> element of the model, it would make sure it would have an id. 
>
>Well, actually, if you really want to use a real "id", you 
>would have to 
>use the metaid attribute. But being not mandatory in SBML, that is 
>actually unfeasible. And again, an XPath is the perfect id to identify 
>unambiguously and XML element.
>
>
>/Dagmar
>
>---------------------------------------------------------------
>----------
>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
>

Re: [Miase-discuss] MIASE-ML independent of SBML

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

This actually was Nicolas reply to Franks mail,
I am just being the secretary here ;)

- - - -

Subject:
Re: [Miase-discuss] MIASE-ML independent of SBML
From:
Nicolas Le Novere <le...@eb...>
Date:
Tue, 11 Mar 2008 08:34:26 +0000

To:
Frank Bergmann <fbergman@u.washington.edu>
Frank Bergmann wrote:
> At the moment I can't see how the approach we have chosen so far would 
> have
> been dependent on version / level changes within the standards. 

Yes, because it relies on what the elements are, and to which namespace 
they belong.


> I guess it really depends here what we want to do. I was under the
> assumption that we were trying to start *small* and have some software
> support fast. 

Small but generic. This is what the problem is. Ion's data-model is 
becoming quite large, and all the extra classes are dues to lack of 
generality.
And XPath is actually the way to start small. The only thing you need is 
to build the path to the value you want to change:

sbml/model/listOfSpecies/species[@id="atp"]/@initialConcentration
sbml/model/listOfParameters/parameter[@id="kon"]/@value
sbml/model/listOfReaction/reaction[@id="atpase"]/kineticLaw/listOfParameters/parameter[@id="kcat"]/@value 

model/component[name="C2"]/variable[name="C2"]/@initial_value

(Note the different namespaces above for the component and the variable)

> I really was fine with the consensus reached at Okinawa and
> was under the impression that that was the first OM. 

I don't think what is currently in the CVS is the consensus reached in 
Oki, is-it? Maybe I am wrong. If this is the case, I am doubly guilty 
not to have been more attentive.

> To make it short ... if my software were to write a MIASE file 
> changing an
> element of the model, it would make sure it would have an id. 

Well, actually, if you really want to use a real "id", you would have to 
use the metaid attribute. But being not mandatory in SBML, that is 
actually unfeasible. And again, an XPath is the perfect id to identify 
unambiguously and XML element.


/Dagmar

Re: [Miase-discuss] MIASE-ML independent of SBML

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

> > There was one thing that Nicolas said where he is probably right: We
> > don't want to spend our time keeping the MIASE structure up to date
> with
> > every change in the different standards we support, do we?
> 

At the moment I can't see how the approach we have chosen so far would have
been dependent on version / level changes within the standards. What we said
was very generic and *any* software supporting those standards would know
how to handle them. 
 
> Another thing is that we may want to target unidentified elements in
> some languages. If we have something like:
> 
> <myComponent id="foobar">
>    <value>XXXX</value>
>    <unit>millimole</unit>
> </myComponent>
> 
> and want to change the content of the element <value>, we cannot use an
> id. XPath is generic. It can be applied to any XML format.
> 

I guess it really depends here what we want to do. I was under the
assumption that we were trying to start *small* and have some software
support fast. I really was fine with the consensus reached at Okinawa and
was under the impression that that was the first OM. 

To make it short ... if my software were to write a MIASE file changing an
element of the model, it would make sure it would have an id. 

Cheers
Frank

Re: [Miase-discuss] MIASE-ML independent of SBML

[Nicolas Le n. <le...@eb...>]

Dagmar Koehn wrote:

>>> MIASE-ML has to be entirely independent of SBML, CellML, MML etc. 

 >>> We can even envision a MIASE-ML
>>> describing a simulation experiment using both SBML *and* CellML models.

>> Exactly ... we thought the same thing ... and thus preferred to subclass the
>> changes and expressions according to the type of language we are targeting
>> (SBML/CellML/BioPax). 
>>   
> 
> There was one thing that Nicolas said where he is probably right: We 
> don't want to spend our time keeping the MIASE structure up to date with 
> every change in the different standards we support, do we?

Yes. And there are other problems too. The way the changes refer to the 
SBML elements is using an SId. What about a model that have a unit, a 
local parameter and a compartment with the same SId? How about the 
future speciesReference's ID?

Yes, one can build a compound ID, made-up of the reaction's ID and the 
parameter's or the speciesReference's ID. Aren't-we reinventing the 
XPath here?

Another thing is that we may want to target unidentified elements in 
some languages. If we have something like:

<myComponent id="foobar">
   <value>XXXX</value>
   <unit>millimole</unit>
</myComponent>

and want to change the content of the element <value>, we cannot use an 
id. XPath is generic. It can be applied to any XML format.

-- 
Nicolas LE NOVERE,  Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223494521, Fax: 468, Mob: +44(0)7833147074  Skype:n.lenovere
http://www.ebi.ac.uk/~lenov, AIM: nlenovere, MSN: nle...@ho...

Re: [Miase-discuss] MIASE-ML independent of SBML

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

Frank Bergmann wrote:
>  
>   
>> MIASE-ML has to be entirely independent of SBML, CellML, MML etc. It
>> cannot possibly depend on the internal structure of a particular
>> language. Otherwise, we will not only have to subclass everything for
>> every language, but even release a new OM for each version of each
>> language. We cannot do that. The only thing we can require for the
>> models is to be encoded in XML. We can even envision a MIASE-ML
>> describing a simulation experiment using both SBML *and* CellML models.
>>     
>
> Exactly ... we thought the same thing ... and thus preferred to subclass the
> changes and expressions according to the type of language we are targeting
> (SBML/CellML/BioPax). 
>   

There was one thing that Nicolas said where he is probably right: We 
don't want to spend our time keeping the MIASE structure up to date with 
every change in the different standards we support, do we?
Plus, I hope we won't be restricted to SBML/CellML/BioPax :)

I was thinking that for search issues later on, we could add an 
(optional) attribute like "modelType" to the model class - then it is at 
least clear what type the referenced model uses (for example, if some 
tools can only load certain model definition languages).

>   
>> So gone are all the classes SBMLfoobar.
>>
>> A sed has a listOfModels
>>
>> A model has a listOfChanges (that can be empty, no need for an
>> unchanged
>> model)
>>
>> A change refers to a target that is described as an XPATH, and an
>> attribute newValue.
>>
>>     
>
> I think we fare better with going with the attributes for selecting the type
> of language rather than XPATH, the reason being, that XPATH will not allow
> us to figure out how the expressions need to change (imagine different
> subsets of MathML being supported and the like).
>   

Well, as "we" (being humans) won't encode all this, it should not be a 
major problem, should it!?
The tools should do valid changes in the expressions for us. And what 
the user can so far do in a tool, that can later on be referenced in 
XPath to store the changes. So that really should not make any difficulties.

Am I wrong somewhere?
Dagmar

Re: [Miase-discuss] MIASE-ML independent of SBML

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

 
> MIASE-ML has to be entirely independent of SBML, CellML, MML etc. It
> cannot possibly depend on the internal structure of a particular
> language. Otherwise, we will not only have to subclass everything for
> every language, but even release a new OM for each version of each
> language. We cannot do that. The only thing we can require for the
> models is to be encoded in XML. We can even envision a MIASE-ML
> describing a simulation experiment using both SBML *and* CellML models.

Exactly ... we thought the same thing ... and thus preferred to subclass the
changes and expressions according to the type of language we are targeting
(SBML/CellML/BioPax). 

> So gone are all the classes SBMLfoobar.
> 
> A sed has a listOfModels
> 
> A model has a listOfChanges (that can be empty, no need for an
> unchanged
> model)
> 
> A change refers to a target that is described as an XPATH, and an
> attribute newValue.
> 

I think we fare better with going with the attributes for selecting the type
of language rather than XPATH, the reason being, that XPATH will not allow
us to figure out how the expressions need to change (imagine different
subsets of MathML being supported and the like).

> 
> Et voila!
> 
> PS: Now that the superficial authority has spoken, the real
> knowledgeable person, i.e. Dagmar, will attempt to transform that into
> a
> proper UML :-)
> 
> --
> Nicolas LE NOVERE,  Computational Neurobiology,
> EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD,
> UK
> Tel: +44(0)1223494521, Fax: 468, Mob: +44(0)7833147074
> Skype:n.lenovere
> http://www.ebi.ac.uk/~lenov, AIM: nlenovere, MSN: nle...@ho...
> 
> -----------------------------------------------------------------------
> --
> 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

[Miase-discuss] MIASE-ML independent of SBML

[Nicolas Le n. <le...@eb...>]

Hi,

Sorry to have been silent so long. I had a look at proposals of Dagmar 
and Ion. Thank-you very much for the hard work. I have some comments 
though, that will hopefully simplify the OM a lot, but not the work of 
developers :-(

MIASE-ML has to be entirely independent of SBML, CellML, MML etc. It 
cannot possibly depend on the internal structure of a particular 
language. Otherwise, we will not only have to subclass everything for 
every language, but even release a new OM for each version of each 
language. We cannot do that. The only thing we can require for the 
models is to be encoded in XML. We can even envision a MIASE-ML 
describing a simulation experiment using both SBML *and* CellML models.
So gone are all the classes SBMLfoobar.

A sed has a listOfModels

A model has a listOfChanges (that can be empty, no need for an unchanged 
model)

A change refers to a target that is described as an XPATH, and an 
attribute newValue.

Same for Expression used for the output. The list of symbols (or 
variables)  refer to any element or attribute of a model through an xpath.

Et voila!

PS: Now that the superficial authority has spoken, the real 
knowledgeable person, i.e. Dagmar, will attempt to transform that into a 
proper UML :-)

-- 
Nicolas LE NOVERE,  Computational Neurobiology,
EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK
Tel: +44(0)1223494521, Fax: 468, Mob: +44(0)7833147074  Skype:n.lenovere
http://www.ebi.ac.uk/~lenov, AIM: nlenovere, MSN: nle...@ho...

Re: [Miase-discuss] miaseOM vs miaseMAIN part 1: Agreements

[Nicolas Le N. <le...@eb...>]

(dagmar, can-you configure the list so that a reply is posted by default to the list and not the sender?)

Dagmar Koehn wrote:

> Question concerning the agreements are:
> 1. Does anybody disagree on using XHTML for notes (as in SBML) or does 
> anybody have a better idea of what to do? Basically, I do support the 
> idea of keeping notes as simple as possible, maybe suggesting XHTML, but 
> not forcing people to use it. I know I had this discussion with you 
> before, Mike, but I still think leaving people freedom with the notes 
> really is the best thing to do :/

I disagree with Dagmar here (sorry Dagmar). The basic thing is that pure text does not exist. 
1) MIASE-ML will be generated by tools, not humans. 
2) We are not in the era of 7bit ASCII anymore. If we do not enforce a format, people will copy/paste what they consider being "pure text", because this is text on their screen. Because  miase-ml defines an encoding on the top, there is a significant risk that the so-called "text" breaks everything. We struggled *a lot* with that at the beginning of BioModels DB. 
3) XHTML is understood everywhere. We could take DOCBOOK or any other simple XML description, but they require specific software. XHTML is simple and can be viewed everywhere. When a user will pass its mouse over a miase-ml file, the pop-up will show him the annotations!

> 2. Regarding the classes being part of the Sed (simulation, model, task, 
> output) what should the cardinalities be? I do prefer the 0..* (One Sed 
> can have 0 to many simulation definitions, model declarations, tasks and 
> output). The question is whether it will make more sense to put 1..*, 
> meaning that one/some of the classes is mandatory, while others are not. 
> Ion was proposing to have all of them mandatory (1..*). I think a 
> simulation description can be completed even without a defined output, 
> for example. It much depends on the users point of view - does he want 
> to define different simulation tasks and then share them with others on 
> whichever model? Or does he see the model as a starting point, creating 
> a certain simulation on it, choosing not to define a certain task (output)?

I agree and not. Yes, there can be a simulation description without output, but then you can put the listOfOutput optional, but never empty. This is not the SBML approach, but it is perfectly fine, and somehow more intuitive. A listOfFoo is created only if the user has created at list one Foo.

> 3. Which simulation types should we additionally derive from Simulation? 
> Which ones would you want me to add?

Do-we need that now?

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

[Miase-discuss] miaseOM vs miaseMAIN part 1: Agreements

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

its always useful to add the attachments...
/dagmar

[Miase-discuss] miaseOM vs miaseMAIN part 1: Agreements

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

Hej all,

I have tried to kind of compare the two different versions of miaseOM we 
do have at the moment. One was suggested by Ion (miaseMAIN), the other 
one is the one I uploaded on Sourceforge (miaseOM v1.5). I think it is a 
good idea to see how they do differ and then discuss the differences.
Afterwards, it might be time to look at the different bits of MIASE and 
discuss them again in a bit more detail, before doing some samples? What 
do you think?

(anything you disagree on in the following, please let me know!)

In this mail, lets try to summarize agreements first (see the pdf draft 
of the OM for the bits mentioned in this mail if things remain unclear):
1. MiaseML will be the root, followed by an Sed (simulation experiment 
description) class.
2. We'll have an MBase class with a note and an annotation that extends 
MiaseML and all other classes.
3. Sed has an optional attribute Id and and optional name attribute.  
Following the Sed there will be 4 classes: Simulation - Model - Task - 
Output
4. For the Simulation, we have so far derived a class UniformTimeCourse, 
SteadyStateAnalysis, and a general simulation class (AnySimulationType). 
All simulations use an Id (required) and an optional name; depending on 
the simulation type, various additional attributes are being added, e.g. 
initialTime...
5. I'd like to postpone the discussion of the other classes (model-, 
output-, task class) to future mails as it seems we don't agree there at 
all ;)
Ion, I have removed the annotation attribute from the task class for my 
version, as this is being inherited from MBase anyways!? Should I do 
that for miaseMAIN as well?

Question concerning the agreements are:
1. Does anybody disagree on using XHTML for notes (as in SBML) or does 
anybody have a better idea of what to do? Basically, I do support the 
idea of keeping notes as simple as possible, maybe suggesting XHTML, but 
not forcing people to use it. I know I had this discussion with you 
before, Mike, but I still think leaving people freedom with the notes 
really is the best thing to do :/
2. Regarding the classes being part of the Sed (simulation, model, task, 
output) what should the cardinalities be? I do prefer the 0..* (One Sed 
can have 0 to many simulation definitions, model declarations, tasks and 
output). The question is whether it will make more sense to put 1..*, 
meaning that one/some of the classes is mandatory, while others are not. 
Ion was proposing to have all of them mandatory (1..*). I think a 
simulation description can be completed even without a defined output, 
for example. It much depends on the users point of view - does he want 
to define different simulation tasks and then share them with others on 
whichever model? Or does he see the model as a starting point, creating 
a certain simulation on it, choosing not to define a certain task (output)?
3. Which simulation types should we additionally derive from Simulation? 
Which ones would you want me to add?

BTW: Has anyone already tried to ''reproduce'' Ions sample file on a 
simulation tool?

So far for the start.
Dagmar

Re: [Miase-discuss] CellML graph metadata specification

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

Indeed, good find.

The graph issues looked related to some of the Okinawa
discussions about how to describe the data and the figure.

MH

Re: [Miase-discuss] CellML graph metadata specification

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

I really hope that we are more along the lines of:

http://www.cellml.org/specifications/metadata/simulations/

the point should be *how* to arrive at a final data set to display,  
instead of exactly specifying the graph.

Cheers
Frank

On Feb 27, 2008, at 9:42 PM, Michael Hucka wrote:

> It seems the CellML people are discussing some topics that
> are possibly relevant to MIASE too:
>
> http://www.cellml.org/specifications/metadata/graphs
>
> MH
>
>
> -------------------------------------------------------------------------
> 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