Chronological Thread 

< Chronological >      < Thread >

---

Hello everybody,

I won't go into the discussion of definitional mathematics in metadata. I
will, instead, simply say that I heartily agree with Warren when it comes to
making CellML as backward compatible as possible.

I have no idea of what others' experience of CellML has been, but our group
has been using it from day one. This said, I must confess that I am
personally slightly concerned about the work that is currently being done on
CellML. No doubt that it is in the interest of the CellML community, but I
wonder whether we shouldn't try and stop the theory and put a bit more
effort into the practice. In other words: develop tools that are CellML
capable. This is indeed the main complaint I get from people to whom I
mention CellML.

First, they don't always know about CellML (some of them, however, do know
about SBML), but that's not a problem as I can tell them about it and even
compare CellML to SBML, if necessary. In the end, I usually end up
convincing them that CellML is the way forward for what they want to do.
Then, however, comes that big hurdle: CellML softwares!

That's when I have to tell them that they have to be patient, that CellML is
still a work in progress, etc. I also tell them about how many CellML files
are available in the repository (http://www.cellml.org/examples/repository/)
and that usually gets them all excited, but I wonder for how long?!

I am aware of the CellML tools page (http://www.cellml.org/public/tools/),
since our own software is listed there, but still there are not that many of
them at this stage...

At least, our software has so far been a rather successful way of
advertising CellML. One of its strength, I guess, is its ability to export a
CellML file (no pathways though) to various programming languages (C, C++,
Delphi for Win32, Java, MATLAB and Pascal at this stage). Our software's
design is such that we can litterally add a new export format within a
couple of hours. That is what it took us to generate some Java code that can
be directly used by simBio (http://www.card.med.kyoto-u.ac.jp/) or some C++
code that can be directly used in a modelling environment developed by some
students here at Oxford. On top of that, we can obviously edit and compute
(by running some automatically-generated machine code) a CellML file from
within the software.

We do think those are the kind of basic tools/features that are of interest
to potential CellML users (Penny Noble has, for instance, been able to 'fix'
some CellML files using our software). So, until we have a wide range of
such tools/features, CellML will just remain an academic exercise, which
would be really sad.

Cheers, Alan.

> -----Original Message-----
> From:
> cellml-discussion-bounces AT cellml.org
>
> [mailto:cellml-discussion-bounces AT cellml.org]
> On Behalf Of
> Warren Hedley
> Sent: 04 May 2005 01:21
> To:
> cellml-discussion AT cellml.org
> Subject: Re: [cellml-discussion] Definitional mathematics in metadata
>
> Hi Andrew,
>
> Like Matt, I'm not really sure what you mean by "definitional
> mathematics". In your example, I don't see how a relationship
> between several variables could not be part of the model,
> unless some of the variables were intermediate convenience variables.
>
> If you mean things like boundary conditions, I would prefer
> to add metadata to the <variable> elements. Moving any
> equations important to simulation into metadata would seem to
> be a recipe for breaking any tools that don't bother
> processing metadata. I think CellML should aim to maintain
> backward compatibility wherever possible.
>
> Cheers,
> Warren
>
>
>
> Andrew Miller postulated on 05/01/2005 05:39 PM:
> > Currently, a large number of repository models place "definitional
> > mathematics"(i.e. mathematical definitions which may be useful to
> > understand the model, but are not strictly part of the
> model) in the
> > mathematics, inside MathML inside the component. This means
> that tools
> > cannot distinguish between such definitional equations and the
> > equations that actually form part of the model.
> >
> > Therefore, I am proposing that definitional mathematics be
> moved into
> > the metadata, and that elements be added to a future version of the
> > cmeta specification that allows for definitions similar to
> the following:
> >
> > <rdf:Description rdf:about="#component_element_id">
> > <cmeta:definitions rdf:parseType="Resource">
> > <rdf:Bag>
> > <rd:li rdf:parseType="Resource">
> > <cmeta:variable name="x"
> reference="#another_variable_element_id" />
> > <cmeta:variable name="y"
> reference="#another_variable_element_id" />
> > <cmeta:variable name="z"
> reference="#yet_another_variable_element_id" />
> > <mathml:math>
> > <eq/>
> > <ci> x </ci>
> > <DEFANGED-APPly>
> > <plus/>
> > <ci> y </ci>
> > <ci> z </ci>
> > </apply>
> > </mathml:math>
> > </rdf:li>
> > </rdf:Bag>
> > </cmeta:definition>
> > </rdf:Description>
> >
> > Please let me know if you can think of a better way to
> handle this, or
> > if you have any comments.
> >
>
> --
> Warren Hedley
> Alliance For Cell Signaling
> San Diego Supercomputer Center
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion AT cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

---

• [cellml-discussion] Definitional mathematics in metadata, Andrew Miller, 05/02/2005
  • [cellml-discussion] Definitional mathematics in metadata, Warren Hedley, 05/04/2005
    • RE: [cellml-discussion] Definitional mathematics in metadata, Alan Garny, 05/04/2005

---

Archive powered by MHonArc 2.6.18.