First login?
Lost password?
 
 
cellml-discussion AT lists.cellml.org 
CellML Discussion List

Text archives Help


[cellml-discussion] Solicitation of feedback on CellML 1.2


Chronological Thread 
  • From: jonathan.cooper at cs.ox.ac.uk (Jonathan Cooper)
  • Subject: [cellml-discussion] Solicitation of feedback on CellML 1.2
  • Date: Sun, 04 Nov 2012 21:10:11 +0000
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
>> <https://tracker.physiomeproject.org/show_bug.cgi?id=67>) and the
>> inclusion of stochastic variation in models (tracker item 2809
>> <https://tracker.physiomeproject.org/show_bug.cgi?id=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


Archive powered by MHonArc 2.6.18.

Top of page