Re: [cellml-discussion] Leftover thoughts from the CellML workshop
(Whoops, I meant to send this to the list, but replied directly to Poul instead...) - Forwarded message from Lucian Smith lpsm...@spod-central.org - A couple follow-up thoughts: * Poul Nielsen p.niel...@auckland.ac.nz [2010-03-11 03:28] writes: Dear Lucian Many thanks for your participation in the CellML workshop and subsequent comments. On 2010-02-27, at 08:43, Lucian Smith wrote: 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. Certainly I don't think SBML translation is *the* goal of CellML 1.2, I just posited that it might be *a* goal. Piecewise functions say while (condition), the following is always true. SBML events say when (condition) becomes true, set the following to be true at that instant, and let it change after that. Depending on the nature of the condition, these can be very different beasts. As an example, you could have a species X controlled by various reactions, and at regular intervals, it's being injected into the system (daily feeding, say). An SBML event would just say something like 'when time is a multiple of 24, X = X+5'. A piecewise function would have to incorporate that event into all the other things that change X. It might be possible, but the resulting expression will probably be very complicated. And it might be impossible to write any sort of automatic translator that translated SBML events to CellML. At the core, SBML events allow you to separate 'the sort of math the normally happens to these variables' from 'these things happen every so often, and the model adjusts accordingly'. If you require those two things to be mushed together into piecewise functions, I *think* you could probably end up with a function that produced the same output (though there might be some counter-examples), but it would be complicated. I'm not saying you definitely should add SBML-style events to CellML, but the tradeoff is simplicity for interpreters if you leave it as-is vs. simplicity for modelers if you add some new construct. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Leftover thoughts from the CellML workshop
Funny - we just realised this ourselves in this morning's CellML meeting. Lukas is talking with Andrew right now about events - and I think he wants to talk with Poul about this too... I'm sure you'll get some more feedback. Best wishes Catherine On 17/03/2010, at 11:02 AM, Lucian Smith wrote: (Whoops, I meant to send this to the list, but replied directly to Poul instead...) - Forwarded message from Lucian Smith lpsm...@spod-central.org - A couple follow-up thoughts: * Poul Nielsen p.niel...@auckland.ac.nz [2010-03-11 03:28] writes: Dear Lucian Many thanks for your participation in the CellML workshop and subsequent comments. On 2010-02-27, at 08:43, Lucian Smith wrote: 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. Certainly I don't think SBML translation is *the* goal of CellML 1.2, I just posited that it might be *a* goal. Piecewise functions say while (condition), the following is always true. SBML events say when (condition) becomes true, set the following to be true at that instant, and let it change after that. Depending on the nature of the condition, these can be very different beasts. As an example, you could have a species X controlled by various reactions, and at regular intervals, it's being injected into the system (daily feeding, say). An SBML event would just say something like 'when time is a multiple of 24, X = X+5'. A piecewise function would have to incorporate that event into all the other things that change X. It might be possible, but the resulting expression will probably be very complicated. And it might be impossible to write any sort of automatic translator that translated SBML events to CellML. At the core, SBML events allow you to separate 'the sort of math the normally happens to these variables' from 'these things happen every so often, and the model adjusts accordingly'. If you require those two things to be mushed together into piecewise functions, I *think* you could probably end up with a function that produced the same output (though there might be some counter-examples), but it would be complicated. I'm not saying you definitely should add SBML-style events to CellML, but the tradeoff is simplicity for interpreters if you leave it as-is vs. simplicity for modelers if you add some new construct. -Lucian ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] Leftover thoughts from the CellML workshop
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 the re 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
