Chronological Thread 

< Chronological >      < Thread >

---

Dear Lucian

Many thanks for your participation in the CellML workshop and subsequent
comments.

On 2010-02-27, at 08:43, Lucian Smith wrote:

> Thanks to all of you who were at the workshop for letting me attend
> remotely. I found it quite valuable, and hope you didn't mind me asking
> you all to repeat the questions too often. And special thanks to
> Catherine for being the driving force behind getting it all set up!
>
> I had a couple extra thoughts on some of the presentations, which I
> probably would have chatted with you about had I been there, but since I
> wasn't, here they are in email instead.
>
> The OpenCell network visualization tool:
> I agree that there is definitely a need both for automatically-
> generated network visualization and for human-arranged network
> visualization. One thing that might help this is to have a standard for
> exchanging or at least storing these--I know SBML has a 'layout extension'
> that stores the visual representation of SBML models. I don't know if a
> CellML extension is the right way to go or if that information is better
> suited to storing in a separate file, but you could at least look at that
> extension for an example of the information you'd want to store.
Being able to store useful layouts of CellML model visualisations would be a
very worthwhile addition. I think, however, that this is a nontrivial
problem. If one is only wishing to reproduce the biophysical representation
of a model by associating components with processes and variables with
entities, the resulting visualisation will in general be very complicated.
Aside from the obvious collapsing of connected variables, there is no unique
way of generating simpler diagrammatic representations. Sarala's PhD work
indicated how annotations and simple rules can be used to simplify the
biophysical view to something more resembling a biological view, but the
result is dependent upon the ordering of rules applied by the user. It would
be useful formalise the process into a sequence of rules so that it could be
applied to several related models to generate similar views. The graph could
then be manipulated and the resulting diagram stored for future use. So it
seems to me that there are several distinct parts to this workflow:
simplification based upon annotations and a sequence of graph reduction
rules; laying out the nodes (processes and entities) after simplification. I
think that both are candidates for expressing in a marked up form so that
they can be re-run to generate the same or similar diagram.
>
> CellML 1.2:
> One thing I noticed was the claim that events could be stored in
> CellML as piecewise formulas. I'm pretty sure that won't be the case with
> SBML events, which are 'fire once' events instead of 'true while' events.
> Maybe one could come up with a piecewise hack to store SBML events, but if
> a goal is to become more amenable to SBML-translated models, you might
> want to think about how best to translate SBML events. Or maybe I'm wrong
> and there's already a way to do it?
> Another thing I noticed was a reluctance to add too many new features
> to the language in the fear that interpreters might not be able or willing
> to handle them. One way to mitigate this would be to allow models to
> claim somewhere in the header whether the model required that feature or
> not--an interpreter could then more cleanly note whether it was able to
> correctly interpret a given model, while still being able to interpret
> other 1.2 models.
I don't think the goal is necessarily to become more amenable to
SBML-translated models. What we are most strongly motivated by is to come up
with simple, powerful generic mechanisms for representing events and
behaviours that depend on them. I would value your thoughts on why piecewise
representations are insufficient for handling events.

It is correct that we are reluctant to add features to CellML. This is only
partly motivated by a desire to ease the burden on tool developers. The
stronger motivation is to keep the language as simple as possible by ensuring
that any new feature is orthogonal to existing features. I agree that tools
should reserve the right to declare that they cannot handle particular
features.
>
> Roundtrip translators:
> I think I'm coming around to the theory that we don't need non-lossy
> translators--that's probably an unattainable goal. What might be more
> helpful instead is roundtrop re-integrators. What I mean by that is that
> nobody actually needs a way to round-trip a model that has never been
> modified, because you still have the original. Instead, what you need is
> a way to translate a model to a new format, modify it in that new format,
> translate it back to the original format, and end up with a model that is
> identical to the original model except for those bits that have been
> changed. I think the best hope for this is if you take the original model
> and the round-tripped-and-modified model, and re-integrate the two.
>
> Obviously, the trickiest bit of this is if you've modified the model by
> deleting something--you need to know that the round-tripping was *able* to
> keep the information, so that if it's gone, that means it's been deleted
> on purpose. But everything else can stay. Similarly, you need to know if
> the format of the information will have changed, and if so, how to map the
> new format to the old format. This may well be the trickier bit--I
> certainly don't know off the top of my head what a good algorithm would be
> to track CellML's modularity through modularless SBML, for example. But
> perhaps with the Hierarchical Modeling extention up and running SBML, this
> would become attainable?
>
> At any rate, I'd be interested in others' thoughts on this. I'm certainly
> not saying that translators should discard information they could have
> saved--the more information they save, the better. I just think there
> will alwaybe be information they can't save (even if it's just some
> proprietary annotations), and re-itegration seems like the way to go here.
Yes, demanding the ability to 'round-trip' is a big ask! As you point out,
correctly handling models, if the model is modified, is especially difficult.
My interest in round-tripping is motivated by the fact that doing so provides
a good demonstration (but no guarantee) that no information loss is incurred
during translation. The advantage of striving for round-tripping is that it
should become clearer exactly what information is lost (and thus has to be
encoded as annotations - such as modularity) when translating from one format
to another. If we can better formalise the information loss during
translation then we might improve the process of automatic conversion,
enabling us to more reliably carry curation and annotation information in the
process.
>
> -Lucian
> _______________________________________________
> cellml-discussion mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion

Best wishes
Poul

---

• [cellml-discussion] Leftover thoughts from the CellML workshop, Poul Nielsen, 03/11/2010
  • [cellml-discussion] Leftover thoughts from the CellML workshop, Lucian Smith, 03/17/2010
    • [cellml-discussion] Leftover thoughts from the CellML workshop, Catherine Lloyd, 03/17/2010

---

Archive powered by MHonArc 2.6.18.