Re: [cellml-discussion] curation of BioModels Database
For example, models that are designed simply as test-cases for particular expected software behaviour - where the structure and expected behaviour of the model are well known but not described in any specific published article. From what I remember, MIRIAM uses published articles as the reference description of a model in regard to MIRIAM compliance, but could another source reference description be used in model curation, albeit not in conjunction with MIRIAM compliance? This is actually incorrect. MIRIAM does not require publication in an article. It requires a unique reference description, that can be an article, a technical report, a web-page etc. ok - thanks for the clarification! finally that one can reproduce published results *using different software than the one used by the authors*. I think this is very important requirement for model curation, but one that is quite daunting for CellML models, especially CellML 1.1 based models. One question I have is how different different tools need to be to satisfy such curation? What I'm getting at is that there could potentially be many different tools based on a common library (the CellML API and code generation service, or libSBML for example), but to me these wouldn't be different enough as the actual interpretation of the model is essentially done by the common layer underneath whatever extra bits the specific tool is adding in. Or is throwing the model through a different numerical integrator, for example, enough to satisfy this requirement? :-) We did not formalise that far. You are entirely right of course. Let's say it very much depends on the model. Some can be simulated in many software and it is easy to get the results using different solvers. Some tricky models can only be simulated by a couple of software ... this is also a problem for CellML models since (currently) only applications built using the CellML API C++ implementation from the Auckland group can handle the newer CellML 1.1 models. While you'd hope it never happens, it is possible for errors in the API implementation to show up differently in different applications. Not much we can do about it though, except to be aware of such factors while curating and annotating CellML models. David. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML 1.1.1 specification
If we had our specification in a version control system and tagged out releases and release candidates etc, and if we followed a protocol of releasing at least one stable minor release that marks depreciation only, then the following would be the result (in my mind) - The current trunk is the development version of cellml 1.2 (i.e. unreleased-dev). - This current trunk look likes CellML 1.1 and the associated definitions in DTDs etc. - We update this to mark out that reaction elements are going to be depreciated, this includes comments in DTDs etc. We don't remove reaction elements from the specification at this stage because that's where we hang the depreciation notices. - We tag this as 1.1.1 and release it - We then delete reaction elements from the specification that is on trunk. Now, this is the kind of process I think covers the steps you have been talking about and at the end makes available a trunk version of 1.2-dev-unreleased that doesn't have reaction elements that people can check out an play with (this is essentially the proposal page the Andrew wrote up - though I think there are issues remaining now with the absence of biology from a Cell ML standard. yep - thats how I would see the specification evolving over time, subject, of course, to the various proposals being accepted and assigned to an appropriate version. I think the absence of biology from the core specification is probably a good thing, but there needs to be clear annotation of the specification describing how reactions should now be represented in a world without reactions - another best practice recommendation and examples in the model repository at the least, I would hope. But what I am also saying is that this is still just an idea, so it should be put forward as a proposal that has not been accepted. I.e. that the steps I described above are purely hypothetical at the moment, since we haven't had the chance to hear arguments from people about it - it might turn out to be a silly proposal. definitely. Your steps describe the process for how the specification may be updated, developed, etc., but each release will be the result of a set of proposals being accepted and assigned to that particular release. this is why the proposal to remove the reaction element should have first been put forward independently of any specific future version of CellML. In this discussion forum we could then debate the merits of this proposal and, if deemed suitable, develop a schedule for the implementation of the proposal (i.e., mark reaction element for deprecation in 1.1.1 and then remove the reaction element in 1.2). Other proposals would also be similarly evaluated and possibly assigned to the same or different releases of the CellML specification. It definitely should not, at this stage, be a forgone conclusion that the reaction element should be removed in 1.2 (or some specific future version of CellML) - that is still open to discussion in my mind, especially in regard to the tools that biomodels.net are using to import/export CellML models with their repository and any other tools utilising the reaction element, of which I don't think anyone has yet evaluated. This is also how I see it: CellML 1.1.1 marking reaction element for deprecation and then CellML 1.2 removing it. Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] embedded stimulus currents in CellML models
Depending on the end-user, it could be a, b and/or c, as well as the fact that apart from PCEnv, no other CellML-capable software that I am aware of can deal with CellML 1.1 models. This emphasises my view that we have to make the CellML API easy to use and provide several examples of its use. http://cellml.sourceforge.net :-) That is a good start indeed. Now, I am waiting for you to write the documentation... :) I was actually trying to get CellML2Dot running. I didn't try very hard... It's in the cellml-discussion archives (or if not the team-cellml, but I think the former.) It would definitely be cool to get some basic documentation for these tools. If you have a go at installing CellML2Dot in Linux Alan, let me know. I'd like to see Andre's simulator too. How does it differ from PCEnv or COR Andre? Documentation is a big issue when it comes to academic tools. To my experience, only a tiny proportion of those tools offer adequate documentation (and I am ashamed to say that COR is not in that tiny proportion). The reason is well known: even though things are starting to change (e.g. with our COR grant), funding bodies don't usually value software development very highly, hence they have to be developed as part of another research project (or even during someone's free time!), meaning that documentation is usually left aside (no time left for it!). Hopefully, with the FP7 NoE and other ongoing projects, things will change (it is, at least, very high on the Oxford agenda). We certainly do need to do something about it, otherwise people may simply not bother using our tools. Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] embedded stimulus currents in CellML models
It would definitely be cool to get some basic documentation for these tools. If you have a go at installing CellML2Dot in Linux Alan, let me know. I'd like to see Andre's simulator too. How does it differ from PCEnv or COR Andre? its quite different in that it has no GUI at all - it is a command line only application that simply processes my analysis metadata, cellml graphing metadata, and cellml simulation metadata to determine what simulations need to be run to produce the data required for the defined graphs and any analysis the user wants to perform. It uses the CellML API and CCGS to generate C code from CellML 1.1 models. There is no restriction to linux, as all the libraries I use are available on a whole bunch of platforms (I think?), including Windows and Macs...not that I have tried to build the tools under anything other than Linux :-) Yes, it would be good to have some information for Windows and Mac... and in fact for Linux too... :) Still, I have managed to recompile it. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] curation of BioModels Database
Hi Nicolas, Users can currently submit models in CellML and SBML (VCML is coming). All the models are then converted to SBML, which is our internal format. Can you point me to the transforms/code/alogorithm for this? cheers Matt ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] curation of BioModels Database
You can find our converters at: http://www.ebi.ac.uk/compneur-srv/biomodels/download.html Matt wrote: Hi Nicolas, Users can currently submit models in CellML and SBML (VCML is coming). All the models are then converted to SBML, which is our internal format. Can you point me to the transforms/code/alogorithm for this? cheers Matt ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK Tel: +44(0)1223494521, Fax: 468, Mob: +44(0)7833147074 Skype:n.lenovere http://www.ebi.ac.uk/~lenov, AIM: nlenovere, MSN: [EMAIL PROTECTED] ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] CellML 1.1.1 specification
David Nickerson wrote: Matt wrote: It seems there is some misunderstanding as to whether we are discussing a proposal to remove the reaction element from CellML or a proposed new specification. I thought it was the latter but you seem to be talking about the former... Both. I think. So I will try another explanation. If we had our specification in a version control system and tagged out releases and release candidates etc, and if we followed a protocol of releasing at least one stable minor release that marks depreciation only, then the following would be the result (in my mind) - The current trunk is the development version of cellml 1.2 (i.e. unreleased-dev). - This current trunk look likes CellML 1.1 and the associated definitions in DTDs etc. - We update this to mark out that reaction elements are going to be depreciated, this includes comments in DTDs etc. We don't remove reaction elements from the specification at this stage because that's where we hang the depreciation notices. - We tag this as 1.1.1 and release it - We then delete reaction elements from the specification that is on trunk. Now, this is the kind of process I think covers the steps you have been talking about and at the end makes available a trunk version of 1.2-dev-unreleased that doesn't have reaction elements that people can check out an play with (this is essentially the proposal page the Andrew wrote up - though I think there are issues remaining now with the absence of biology from a Cell ML standard. yep - thats how I would see the specification evolving over time, subject, of course, to the various proposals being accepted and assigned to an appropriate version. I think the absence of biology from the core specification is probably a good thing, It might be worth adding an editorial comment or similar to note that the metadata is where the vast majority of biological information is defined. but there needs to be clear annotation of the specification describing how reactions should now be represented in a world without reactions - another best practice recommendation and examples in the model repository at the least, I would hope. Yep, the 'signal transduction' tutorial will no longer be needed, since its main purpose is to describe the best practice for use of reaction elements to describe biochemical pathways. The question will be, do we just remove it, or do we create a new tutorial that is biochem specific, but doesn't talk about reaction elements. For example, there are two main ways to code up a biochem model: either you can use equations that describe, for example, the rate of change of conc. of species A, where species A might have a few different processes acting on it, so this equation would be a summation of the effect of these processes, OR, you can split the equation into 'fluxes,' which represent just the effect of one process on a species at a time. I think it would be worth writing a best practice guide for writing biochem models, even if it is relatively short, since there are a few things that are different from how an ephys model should be coded up. But what I am also saying is that this is still just an idea, so it should be put forward as a proposal that has not been accepted. I.e. that the steps I described above are purely hypothetical at the moment, since we haven't had the chance to hear arguments from people about it - it might turn out to be a silly proposal. definitely. Your steps describe the process for how the specification may be updated, developed, etc., but each release will be the result of a set of proposals being accepted and assigned to that particular release. this is why the proposal to remove the reaction element should have first been put forward independently of any specific future version of CellML. Perhaps we could start by formalising the actual proposal to get rid of the rxn element. Why are we doing it? How will we replace the purpose it served, using metadata for example? I realise that this has been discussed a lot in an informal manner, and was in fact decided well before my time, but I guess if we're going to do something as major as create a new spec version, we should build the foundations first. In this discussion forum we could then debate the merits of this proposal and, if deemed suitable, develop a schedule for the implementation of the proposal (i.e., mark reaction element for deprecation in 1.1.1 and then remove the reaction element in 1.2). Other proposals would also be similarly evaluated and possibly assigned to the same or different releases of the CellML specification. It definitely should not, at this stage, be a forgone conclusion that the reaction element should be removed in 1.2 (or some specific future version of CellML) - that is still open to discussion in my mind, It would be good to see a thorough list of pros and cons for the rxn element. If we do write a
Re: [cellml-discussion] embedded stimulus currents in CellML models
Matt wrote: On 7/19/07, David Nickerson [EMAIL PROTECTED] wrote: Of course. And in the same sense you could simply delete the stimulus protocol component if you didn't want it. I think the issue is in fact a curation issue - we are specifying one of our curation 'levels' as model is the same as is described in the paper. If there is a stimulus protocol that isn't in the paper in the CellML model, then this curation standard is invalidated. This is fine, as it (hopefully) moves the model up to the next 'level,' which requires that the model be able to produce the appropriate output, but doesn't necessarily require that the model be identical to that described in the paper. So the solution is that we should really have both. So there is validation in the sense that there is a true representation of a publication - which more often than not is pretty useless, and there is validation in the sense that the model can demonstrate what we think was intended by the publication (most obviously produces the right results) but perhaps many changes in the underlying formulation. Is it ok to only offer the former as a historical version? I guess it depends if you define all versions that are not the most recent version as 'historical.' What does historical mean here exactly? But essentially, I think it's okay if it's noted in the model documentation - perhaps a note on why the model won't run in a simulator, and that this particular version might be better for multicellular networks where the stimulus is externally defined? It's a pretty simple matter to get a model to the point where it is complete except for a stimulus protocol, upload it as version x, then add the stimulus protocol and upload that as version y. To be honest, if people are wanting to fiddle around with multicellular systems they probably know what they're doing enough to be able to identify and delete an extraneous stimulus component they don't want. The documentation will identify it as 'foreign.' and should it be necessary to actually do the former if we can easily see where the math needs to be written out differently? Hmm, if it doesn't really take any effort to do, then the only reason (besides the above,) I can think of not to do this, is that it just creates extra versions that aren't particularly useful. ___ 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] CellML 1.1.1 specification
More generally I think this issue is tapping on the bigger issue of a core modelling language and specification, and then special use cases, of which biological modelling would be a particular case of. Without reactions, we pretty much have that core language. My inclination is that biological modelling is a specification of minimum required annotation of mathematical models using the 'core' language. Poul's turn. On 7/20/07, James Lawson [EMAIL PROTECTED] wrote: David Nickerson wrote: Matt wrote: It seems there is some misunderstanding as to whether we are discussing a proposal to remove the reaction element from CellML or a proposed new specification. I thought it was the latter but you seem to be talking about the former... Both. I think. So I will try another explanation. If we had our specification in a version control system and tagged out releases and release candidates etc, and if we followed a protocol of releasing at least one stable minor release that marks depreciation only, then the following would be the result (in my mind) - The current trunk is the development version of cellml 1.2 (i.e. unreleased-dev). - This current trunk look likes CellML 1.1 and the associated definitions in DTDs etc. - We update this to mark out that reaction elements are going to be depreciated, this includes comments in DTDs etc. We don't remove reaction elements from the specification at this stage because that's where we hang the depreciation notices. - We tag this as 1.1.1 and release it - We then delete reaction elements from the specification that is on trunk. Now, this is the kind of process I think covers the steps you have been talking about and at the end makes available a trunk version of 1.2-dev-unreleased that doesn't have reaction elements that people can check out an play with (this is essentially the proposal page the Andrew wrote up - though I think there are issues remaining now with the absence of biology from a Cell ML standard. yep - thats how I would see the specification evolving over time, subject, of course, to the various proposals being accepted and assigned to an appropriate version. I think the absence of biology from the core specification is probably a good thing, It might be worth adding an editorial comment or similar to note that the metadata is where the vast majority of biological information is defined. but there needs to be clear annotation of the specification describing how reactions should now be represented in a world without reactions - another best practice recommendation and examples in the model repository at the least, I would hope. Yep, the 'signal transduction' tutorial will no longer be needed, since its main purpose is to describe the best practice for use of reaction elements to describe biochemical pathways. The question will be, do we just remove it, or do we create a new tutorial that is biochem specific, but doesn't talk about reaction elements. For example, there are two main ways to code up a biochem model: either you can use equations that describe, for example, the rate of change of conc. of species A, where species A might have a few different processes acting on it, so this equation would be a summation of the effect of these processes, OR, you can split the equation into 'fluxes,' which represent just the effect of one process on a species at a time. I think it would be worth writing a best practice guide for writing biochem models, even if it is relatively short, since there are a few things that are different from how an ephys model should be coded up. But what I am also saying is that this is still just an idea, so it should be put forward as a proposal that has not been accepted. I.e. that the steps I described above are purely hypothetical at the moment, since we haven't had the chance to hear arguments from people about it - it might turn out to be a silly proposal. definitely. Your steps describe the process for how the specification may be updated, developed, etc., but each release will be the result of a set of proposals being accepted and assigned to that particular release. this is why the proposal to remove the reaction element should have first been put forward independently of any specific future version of CellML. Perhaps we could start by formalising the actual proposal to get rid of the rxn element. Why are we doing it? How will we replace the purpose it served, using metadata for example? I realise that this has been discussed a lot in an informal manner, and was in fact decided well before my time, but I guess if we're going to do something as major as create a new spec version, we should build the foundations first. In this discussion forum we could then debate the merits of this proposal and, if deemed suitable, develop a schedule for the implementation of the proposal (i.e., mark
