Re: [Miase-discuss] MIME type - OM discrepancies - XPATH again

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

Frank Bergmann wrote:

> I know that
> Dagmar and Nicolas where definitely against embedding a miase description in
> an SBML file. So how about this:

But we could imagine a mechanism where you would embed the SBML in the SED-ML ...

> - we place the miase description file (e.g: miaseBioModels21.xml) along with
> all source files that are on the local machine (i.e: having a URI beginning
> with a file:// prefix) (and all other files you might want to include later
> on) into an archive with the same name as the miase description file, but an
> extension we can all agree upon ... like ..uhm '.miase' ... 
> - next we register a MIME sub-type like application/miase+xml with the
> network working group by  submitting a rfc. 
>
> And voila, applications receiving a file with that mime type, just unzip it,
> read the miase description, and find all sources along with it, no hassle,
> no more missing files, and no dependence on a particular model description
> language. Also, thanks to the whole thing just being a single file, suddenly
> export of miase files will be so much easier and adoption by tool authors
> should go along easier. This is an issue to be addressed before version 1
> leaves the door. 

That's brilliant.

 
> - The OM describes the datagenerator as having a 'mathExpression' while the
> example uses 'math' ... 

No ... I see "math" on the version online. 

> -  The OM defines a 'Column' element without attributes and a 1:1
> relationship with a DataGenerator, right now I see no need for that one,
> listOfColumns should contain a list of DataGenerators. 

I tend to agree, but I remember there was a reason for that. I just don't remember it right now :-)

> - ChangeMath and ChangeXML are really one and the same, if you just modify
> the XPATH target. 

No, no, no. There is a misunderstanding. ChangeMath is not meant to be used as a ChangeXML that change the element "math". It will allow us to *compute* changes based on external parameters.  

> - plot3D, will probably not work like it is drawn in the OM, this would
> result in a plot3d, with a list of curve and a dangling list of surfaces
> that only have a z axis. This should be revised. 

You are right of course.

> IMHO plot3d should extend
> 'output' directly and define logx,logy,logz and a list of surfaces.

Kind of. I just discussed with Nicolas Rodriguez and Duncan Berenguier (who is developing an SBML extension for formal models) and I think we found the solution.

1) A class "Plot" should inherit from "Putput", on par with "Report". "Plot2D" and "Plot3D" inherit from "Plot". The attribute logX and logY are moved in "Curve". Indeed, one may want to plot a curve with a linear ordinate together with a curve with a logarithmic ordinate. "Surface" inherits from "Curve" and contains logZ.

Attached.

> -AnySimulationType is specified as blue, aka version 1, but is not specified
> at all, it really should be used later :) 

Yes, yes, it should.

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