Chronological Thread 

< Chronological >      < Thread >

---

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] Solicitation of feedback on CellML 1.2, David Nickerson, 10/29/2012
  • [cellml-discussion] Solicitation of feedback on CellML 1.2, Peter Hunter, 10/30/2012
  • [cellml-discussion] Solicitation of feedback on CellML 1.2, Andrew Miller, 10/30/2012

---

Archive powered by MHonArc 2.6.18.