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

At the 5th International CellML Workshop
<http://www.cellml.org/community/events/workshop/2011/>, we discussed
the main list of features that were desirable to have in CellML 1.2. The
CellML Editorial Board has been discussing the implementation of these
features in regard to the next version of the CellML standard. Early on,
we decided that the entire list of features arising from the workshop
was too broad and far reaching to accommodate an easy transition from
CellML 1.1 to CellML 1.2 in a timely manner. We have therefore selected
a subset of these features which we feel address immediate shortcomings
in the CellML 1.1 specification and introduce a minimal set of often
requested new features.

Tracker item 55
<https://tracker.physiomeproject.org/showdependencytree.cgi?id=55>shows
a detailed overview of our current plans. This is by no means meant to
be the final composition of CellML 1.2, but it reflects the current view
of the editorial board as to the types of models users wish to encode in
CellML and what is possible to implement in both the specification and
software tools.

Jonathan Cooper presented our thoughts on CellML 1.2 at the recent
COMBINE 2012 meeting <http://co.mbine.org/events/COMBINE_2012/agenda>.
Please see the slides and video of the presentation to get a more
consumable view of the proposed changes.

This email is to solicit specific feedback from the community regarding
the subset of changes that we have selected for inclusion in CellML 1.2.
The CellML 1.2 specification will mark a significant change in the way
the CellML standard is specified, and we hope that this change will
enable a more rapid process for standardising new features that
modellers require in order to encode and share their models using CellML.

 From tracker item 55
<https://tracker.physiomeproject.org/show_bug.cgi?id=55>, we would like
to highlight the following main changes that we think should be in
CellML 1.2:

  * Remove reaction element (tracker item 49
    <https://tracker.physiomeproject.org/show_bug.cgi?id=49>);

+1

  * Remove the directional aspect of connections (tracker item 337
    <https://tracker.physiomeproject.org/show_bug.cgi?id=337>);

+1

  * Replace grouping with a simplified encapsulation-only mechanism
    (tracker item 356

+1

    <https://tracker.physiomeproject.org/show_bug.cgi?id=356>);
  * Delayed variables (introduction of the evaluatedAtoperator with
    reduced functionality to allow infinitesimal delays and initial
    values) (tracker item 70
    <https://tracker.physiomeproject.org/show_bug.cgi?id=70>).

+1



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.

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

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.

Best wishes,
Andrew

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

Reply via email to