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 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 formal proposal, where should we put it? Perhaps send > it out to cellml-discussion, as well as all the groups we know to be > reliant on the spec for building tools, models etc. > > > 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, > > We could provide them with a new translation tool if we were so > inclined, couldn't we? But I see the issue here - if SBML has reactions > and we don't, then the translation process will have to be reworked and > re-evaluated. > > of which I don't think anyone has yet > > evaluated. > > _______________________________________________ > > 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 > _______________________________________________ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
