Re: [cellml-discussion] Solicitation of feedback on CellML 1.2

[Jonathan Cooper]

Hi all,

Just wanted to respond to a couple of points.

On 30/10/2012 02:53, Andrew Miller wrote:

On 29/10/12 22:36, David Nickerson wrote:

In addition, we specifically ask for feedback on the issue of moving to
MathML 3.0 (tracker item 67
) and the
inclusion of stochastic variation in models (tracker item 2809
). The editors
generally agree that switching to MathML 3.0 at this time provides too
little benefit (mathematical clarity) for the cost involved in making
the change (tool support, interoperability with other exchange formats).


I think that it would be worth including MathML 3.0 in CellML 1.2 
because:
  1. It makes implementation easier by providing clear rules about the 
mathematical interpretation of models.
  2. It is more cleanly extensible through the use of OpenMath content 
dictionaries.
  3. It is mostly forwards and backwards compatible with MathML 2.0 - 
nearly every MathML 2.0 expression is valid MathML 3.0, and you can 
write MathML 3.0 so it is valid MathML 3.0.
  4. The only implementation of the CellML 1.2 proposals so far has 
already been coded to use MathML 3.0 - so the cost in terms of tool 
support so far would actually be higher to change that implementation 
to support MathML 2.0.


For the sake of those not at the ABI, could you give more details of 
this implementation? Is it an API library that can be used from multiple 
programming languages?





While the proposal for stochastic variation is fairly mature, we feel
that it requires further work to meet the requirements for inclusion in
the CellML standard. We also think that given sufficient impetus from
the community this could be one of the first proposals to pass through
the new development process for CellML.


I'm not sure there even is a stochastic variation proposal (unless it 
is private to the editorial board). I put together a proposal for 
parameter uncertainty (which is different from stochastic variation - 
a system is stochastic if the relationship between the initial and a 
later state is not deterministic, while it has parameter uncertainty 
if the true initial state is not known).


Your parameter uncertainty proposal was the one we had in mind.



I don't think there needs to be 'one CellML' that every tool 
implements exactly - parameter uncertainty is probably most 
appropriate as an officially endorsed secondary specification that 
adds to core CellML.


+1

Best wishes,
Jonathan
___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion

Re: [cellml-discussion] Solicitation of feedback on CellML 1.2

[Andrew Miller]

On 05/11/12 10:10, Jonathan Cooper wrote:

Hi all,

Just wanted to respond to a couple of points.

On 30/10/2012 02:53, Andrew Miller wrote:

On 29/10/12 22:36, David Nickerson wrote:

In addition, we specifically ask for feedback on the issue of moving to
MathML 3.0 (tracker item 67
) and the
inclusion of stochastic variation in models (tracker item 2809
). The 
editors

generally agree that switching to MathML 3.0 at this time provides too
little benefit (mathematical clarity) for the cost involved in making
the change (tool support, interoperability with other exchange 
formats).


I think that it would be worth including MathML 3.0 in CellML 1.2 
because:
  1. It makes implementation easier by providing clear rules about 
the mathematical interpretation of models.
  2. It is more cleanly extensible through the use of OpenMath 
content dictionaries.
  3. It is mostly forwards and backwards compatible with MathML 2.0 - 
nearly every MathML 2.0 expression is valid MathML 3.0, and you can 
write MathML 3.0 so it is valid MathML 3.0.
  4. The only implementation of the CellML 1.2 proposals so far has 
already been coded to use MathML 3.0 - so the cost in terms of tool 
support so far would actually be higher to change that implementation 
to support MathML 2.0.


For the sake of those not at the ABI, could you give more details of 
this implementation? Is it an API library that can be used from 
multiple programming languages?


The implementation is intended as a demonstration of CellML 1.2 
features, and so design decisions have primarily focused on minimising 
development costs and maintaining agility rather than providing the best 
possible interface.


It is written in Haskell, but with the work currently being completed, 
limited C++ bindings to access generated code and run simulations will 
also be available.


Best wishes,
Andrew

___
cellml-discussion mailing list
cellml-discussion@cellml.org
http://lists.cellml.org/mailman/listinfo/cellml-discussion