Re: [cellml-discussion] [Tracker Item 42] New: CellML 1.1.1specification
Hi Andrew, > Still to be done (please open new tracker items on these and set them to block > this issue you want to comment): > a) Update appendix D (changes since last version). > b) Repair figure 18, name is invalid on model (found by Alan Garny). > c) Fix the formula for computing new values for equations per the CellML 1.1 > errata. > d) Renumber figures. > e) Fix up some URLs which are incorrect, especially to historic data. these should all block, if someone with access can do this. Thanks, Andre. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [Tracker Item 42]New: CellML1.1.1specification
The more this is explained, the more it sounds like this could all be achieved with some additions to the errata for the CellML 1.1 specification. What benefit is gained by making a 1.1.1 version? > 1.1.1 doesn't describe the reaction element, but 1.1 does, and 1.1.1 and > 1.1 are in the same namespace. If software which has supported reactions > per the CellML 1.1 specification sees the reaction element, it will > follow the 1.1 specification (indeed, we probably would benefit from an > implementation guide which encourages tool developers to support more > than one version of CellML if possible. How many versions back they want > to support is up to them). > > Model authors on the other hand will be strongly encouraged to use > CellML 1.1.1. > > Best regards, > Andrew > > ___ > cellml-discussion mailing list > cellml-discussion@cellml.org > http://www.cellml.org/mailman/listinfo/cellml-discussion -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [Tracker Item 42] New: CellML1.1.1specification
David Nickerson wrote: > Hi Matt, > > >> I think there does need to be some description of what the parts of a >> cellml specification version number is and how it relates to the >> cellml namespace(s). >> >> My understanding is that the 1.1.1 was chosen so that this did >> represent a minor step in thinking for CellML 1.1, but that the model >> remains valid as a 1.1 model. i.e. A CellML 1.1 model is not >> necessarily a valid 1.1.1 model and a migration step would be needed >> to make it so. The namespace of a 1.1.1 model would still be >> http://www.cellml.org/cellml/1.1# >> >> I also think that this minor version should be marked in glaring red >> that it is precisely a depreciation of reactions step and provide >> reasons why and the tools to help people transform any models they >> have with reactions into ones that don't. I think there will be some >> debate around that - especially pointing to lossless transforms >> between SBML and CellML and back again with existing transforms >> available out there. >> >> My assumption would be that CellML 1.2 or 2.0 namespace would be the >> one where reaction elements become invalid if indeed 1.1.1 was >> successful. >> > > you seem to be saying that version 1.1.1 is marking the reaction element > for deprecation but that the reaction element itself won't become > invalid until a 1.2 or 2.0 version is released? This doesn't seem to > match with completely removing all reference of and to reaction elements > in the 1.1.1 specification...maybe I'm missing something? > 1.1.1 doesn't describe the reaction element, but 1.1 does, and 1.1.1 and 1.1 are in the same namespace. If software which has supported reactions per the CellML 1.1 specification sees the reaction element, it will follow the 1.1 specification (indeed, we probably would benefit from an implementation guide which encourages tool developers to support more than one version of CellML if possible. How many versions back they want to support is up to them). Model authors on the other hand will be strongly encouraged to use CellML 1.1.1. Best regards, Andrew ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [Tracker Item 42] New: CellML1.1.1specification
Hi Matt, > I think there does need to be some description of what the parts of a > cellml specification version number is and how it relates to the > cellml namespace(s). > > My understanding is that the 1.1.1 was chosen so that this did > represent a minor step in thinking for CellML 1.1, but that the model > remains valid as a 1.1 model. i.e. A CellML 1.1 model is not > necessarily a valid 1.1.1 model and a migration step would be needed > to make it so. The namespace of a 1.1.1 model would still be > http://www.cellml.org/cellml/1.1# > > I also think that this minor version should be marked in glaring red > that it is precisely a depreciation of reactions step and provide > reasons why and the tools to help people transform any models they > have with reactions into ones that don't. I think there will be some > debate around that - especially pointing to lossless transforms > between SBML and CellML and back again with existing transforms > available out there. > > My assumption would be that CellML 1.2 or 2.0 namespace would be the > one where reaction elements become invalid if indeed 1.1.1 was > successful. you seem to be saying that version 1.1.1 is marking the reaction element for deprecation but that the reaction element itself won't become invalid until a 1.2 or 2.0 version is released? This doesn't seem to match with completely removing all reference of and to reaction elements in the 1.1.1 specification...maybe I'm missing something? Andre. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [Tracker Item 42] New:CellML 1.1.1specification
David Nickerson wrote: >>> To simply delete reaction elements from a version 1.1.1 specification >>> seems the wrong approach to me. This means that while a 1.0 model is a >>> valid 1.1 model it could be an invalid 1.1.1 model. So the most minor >>> version change is the one that invalidates the model?!? >>> >>> >> CellML 1.0 models are not valid 1.1 models because they are in the >> CellML 1.1 namespace. >> > > but given you are proposing not to change the namespace, how do > applications determine if they are looking at a CellML 1.1 or a 1.1.1 > version model? > They don't need to determine whether they are looking at a 1.1.1 or 1.1 model. The changes are all corrections of minor errors which everyone has just ignored and implemented how we intended it to be read, or describe changes that an author will need to make as opposed to changes that tool developers will need to make. > >> I think that 1.1.1 is backwards compatible with 1.1 (all 1.1.1 models >> are valid 1.1 models), it is simply a lack of forwards compatibility. >> Compare this with the relationship between CellML 1.0 and CellML 1.1 >> (there is neither backwards nor forwards compatibility due to the >> namespaces, and if you change the namespaces, there is forwards but not >> backwards compatibility). >> > > yes, and its this forward compatibility I am concerned with - at least > as far as CellML 1.0 to CellML 1.1.x compatibility is concerned. > See above for why we don't have 1.0 to 1.1, so we can't expect 1.0 to 1.1.1. Do you mean 1.1 to 1.1.1? > >>> If anything, a version 1.1.1 could mark the reaction element as >>> deprecated but still valid. Although if I recall some other >>> specification developments correctly (i.e., docbook), an element needs >>> to be marked for deprecation a version before it is actually deprecated >>> and removed from the language. >>> >> I think that reaction has been informally deprecated for quite some >> time, and there has been an effort to get rid of most reactions. >> > > thats the main problem I have - we had an option to formally mark the > reaction element for deprecation in 1.1 and the decision was made to not > do so. I have heard no reason why that decision no longer holds? While > attempting to develop community standards I don't think it is > appropriate to base specification revisions at such an informal level. > Application developers should be able to implement support for CellML > based on the specifications alone, not some combination of > specifications and trawling through mailing lists and bug trackers. As > an application developer I would be extremely annoyed to spend time > implementing support for an apparent core element just to have it > arbitrarily removed in a minor increment of the specification. > Most tool developers don't need to make any changes to support CellML 1.1.1 models, because CellML 1.1.1 is a subset of CellML 1.1, and so if they support CellML 1.1.1 they also support CellML 1.1 (authors, on the other hand, might be annoyed if they have just written a model in CellML 1.1, but such is the nature of an evolving specification). Validators are the one exception, because in a particular mode they might want to accept precisely CellML 1.1.1 and not models which are valid CellML 1.1 but not valid CellML 1.1.1. However, changes like this are to be expected for validators (and deprecation would be no more onerous on such validators anyway). I do not agree that specifications should act like some kind of 'news bulletin' that describes not only the current specification, but also things that are going to happen in the future. Developers can implement an individual specification perfectly well based solely on that specification, and if they want to know what is going to happen soon, then it is certainly more appropriate for them to look at mailing lists and trackers than to look at the last version of the specification. > >> We do need to change the CellML specification if we are to make >> progress, and I think removing historical mistakes is as important as >> adding new features. Models which are CellML 1.1 compliant will forever >> remain CellML 1.1 compliant, because we are not changing CellML 1.1, and >> instead we are making a new version of the specification. Everyone >> expects that new versions of specifications will change some things. >> > > Change is fine, its the abrupt deletion of an until now core element in > CellML that I have concerns with. Such is the nature of how specifications develop. > And classifying the reaction element > as a historical mistake seems a bit harsh given the CellML project would > probably not exist today if not for reaction elements. > > >> Furthermore, I don't exactly agree that we need to give 'notice' of >> things by way of formal specifications. Submitting a proposal for the >> CellML community to review is sufficien
Re: [cellml-discussion] [Tracker Item 42] New: CellML 1.1.1specification
> > Furthermore, I don't exactly agree that we need to give 'notice' of > things by way of formal specifications. Submitting a proposal for the > CellML community to review is sufficient 'notice'. > > In the case of mature standards which require a high level of > interoperability, a +-1 compatibility strategy is a good idea. A good > example is the Subversion protocol > (http://subversion.tigris.org/faq.html#interop): "The client and server > are designed to work as long as they aren't more than one major release > version apart. For example, any 1.X client will work with a 1.Y server. > However, if the client and server versions don't match, certain features > may not be available". Under such a strategy, you generally use a 'be > liberal in what you accept, and conservative in what you send' strategy, > which in CellML terms would require tools to support reactions, but > require that no new models be developed that use reactions. > > However, I don't think that this is a good approach for CellML: > 1) CellML tools generally support more than one version of CellML > anyway. For example, the CellML API has been quite explicitly coded to > support both CellML 1.1 and CellML 1.0. I expect that tools would > continue to support 1.1, 1.1.1, and 1.0 (in fact, any tool which > supports 1.1 properly will immediately be able to claim support for > CellML 1.1.1 models without making any code changes). > 2) As far as I know, no one has actually implemented a reaction based > simulator at the moment anyway. > > I think that having a separate implementation notes document to describe > what I have summarised would probably be a better way to achieve this. > I think Andre was pointing more at a more formal process that anyone could participate in and that more than one initial proposal for "new versions" of things, such as specifications, could be created in a setting where they can be referenced as a group. The technology we are looking at (albeit slowly) is the plone software center, and specifically relevant here are the proposal utility - e.g. see: http://plone.org/products/plone/roadmap - specifically - http://plone.org/products/plone/roadmap#discussion ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [Tracker Item 42] New: CellML 1.1.1specification
On 7/18/07, David Nickerson <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > To simply delete reaction elements from a version 1.1.1 specification > seems the wrong approach to me. This means that while a 1.0 model is a > valid 1.1 model it could be an invalid 1.1.1 model. So the most minor > version change is the one that invalidates the model?!? > > If anything, a version 1.1.1 could mark the reaction element as > deprecated but still valid. Although if I recall some other > specification developments correctly (i.e., docbook), an element needs > to be marked for deprecation a version before it is actually deprecated > and removed from the language. Not sure what process we want to follow > for CellML but this 1.1.1 draft specification would not be the way I > hope we go. Otherwise how can anyone have confidence in using CellML at > all when core elements can arbitrarily be dropped from the specification > with no notice? I think there does need to be some description of what the parts of a cellml specification version number is and how it relates to the cellml namespace(s). My understanding is that the 1.1.1 was chosen so that this did represent a minor step in thinking for CellML 1.1, but that the model remains valid as a 1.1 model. i.e. A CellML 1.1 model is not necessarily a valid 1.1.1 model and a migration step would be needed to make it so. The namespace of a 1.1.1 model would still be http://www.cellml.org/cellml/1.1# I also think that this minor version should be marked in glaring red that it is precisely a depreciation of reactions step and provide reasons why and the tools to help people transform any models they have with reactions into ones that don't. I think there will be some debate around that - especially pointing to lossless transforms between SBML and CellML and back again with existing transforms available out there. My assumption would be that CellML 1.2 or 2.0 namespace would be the one where reaction elements become invalid if indeed 1.1.1 was successful. > > Also, I'm wondering if we could set some ground rules for the > development of new versions of CellML. Rather than people simply > submitting draft specifications, I would favour an approach whereby > people submit proposals (using whatever technology we end up using) and > then we can discuss which version of CellML that proposal should be > considered for. This would allow us to start developing a detailed road > map of the features people want to include in new versions of CellML and > the priority with which they are incorporated, as well as possible > target dates for the various releases. > > > David. > > [EMAIL PROTECTED] wrote: > > http://trackerdev.cellml.org/show_bug.cgi?id=42 > > > >Summary: CellML 1.1.1 specification > >Product: CellML Core Specifications > >Version: Future versions > > Platform: PC > > OS/Version: Linux > > Status: NEW > > Severity: feature > > Priority: Moderate priority > > Component: Reactions > > AssignedTo: [EMAIL PROTECTED] > > ReportedBy: [EMAIL PROTECTED] > > > > > > I have created a proposed draft specification for CellML 1.1.1, and put it > > up > > at: > > http://www.cellml.org/Members/miller/proposed_cellml_1.1.1/ > > > > The draft is essentially the same as CellML 1.1, except that: > > 1) The version has been increased to 1.1.1. > > 2) The introduction is updated to make it clear that Physiome Sciences Inc. > > is > > no longer involved in CellML development. > > 3) The reactions section has been deleted and all references to sections > > after > > it have been renumbered. > > 4) All references to reaction have been deleted. > > 5) An copy-and-paste error reported by Alan Garny where we incorrectly used > > the > > word component instead of units was fixed. > > 6) The DTD was updated to remove reactions and so on. > > 7) I added myself as an author. > > > > Still to be done (please open new tracker items on these and set them to > > block > > this issue you want to comment): > > a) Update appendix D (changes since last version). > > b) Repair figure 18, name is invalid on model (found by Alan Garny). > > c) Fix the formula for computing new values for equations per the CellML 1.1 > > errata. > > d) Renumber figures. > > e) Fix up some URLs which are incorrect, especially to historic data. > > > > > > -- > David Nickerson, PhD > Research Fellow > Division of Bioengineering > Faculty of Engineering > National University of Singapore > Email: [EMAIL PROTECTED] > ___ > 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] [Tracker Item 42] New:CellML 1.1.1specification
>> To simply delete reaction elements from a version 1.1.1 specification >> seems the wrong approach to me. This means that while a 1.0 model is a >> valid 1.1 model it could be an invalid 1.1.1 model. So the most minor >> version change is the one that invalidates the model?!? >> > > CellML 1.0 models are not valid 1.1 models because they are in the > CellML 1.1 namespace. but given you are proposing not to change the namespace, how do applications determine if they are looking at a CellML 1.1 or a 1.1.1 version model? > I think that 1.1.1 is backwards compatible with 1.1 (all 1.1.1 models > are valid 1.1 models), it is simply a lack of forwards compatibility. > Compare this with the relationship between CellML 1.0 and CellML 1.1 > (there is neither backwards nor forwards compatibility due to the > namespaces, and if you change the namespaces, there is forwards but not > backwards compatibility). yes, and its this forward compatibility I am concerned with - at least as far as CellML 1.0 to CellML 1.1.x compatibility is concerned. >> If anything, a version 1.1.1 could mark the reaction element as >> deprecated but still valid. Although if I recall some other >> specification developments correctly (i.e., docbook), an element needs >> to be marked for deprecation a version before it is actually deprecated >> and removed from the language. > > I think that reaction has been informally deprecated for quite some > time, and there has been an effort to get rid of most reactions. thats the main problem I have - we had an option to formally mark the reaction element for deprecation in 1.1 and the decision was made to not do so. I have heard no reason why that decision no longer holds? While attempting to develop community standards I don't think it is appropriate to base specification revisions at such an informal level. Application developers should be able to implement support for CellML based on the specifications alone, not some combination of specifications and trawling through mailing lists and bug trackers. As an application developer I would be extremely annoyed to spend time implementing support for an apparent core element just to have it arbitrarily removed in a minor increment of the specification. > We do need to change the CellML specification if we are to make > progress, and I think removing historical mistakes is as important as > adding new features. Models which are CellML 1.1 compliant will forever > remain CellML 1.1 compliant, because we are not changing CellML 1.1, and > instead we are making a new version of the specification. Everyone > expects that new versions of specifications will change some things. Change is fine, its the abrupt deletion of an until now core element in CellML that I have concerns with. And classifying the reaction element as a historical mistake seems a bit harsh given the CellML project would probably not exist today if not for reaction elements. > Furthermore, I don't exactly agree that we need to give 'notice' of > things by way of formal specifications. Submitting a proposal for the > CellML community to review is sufficient 'notice'. see my concerns above. > In the case of mature standards which require a high level of > interoperability, a +-1 compatibility strategy is a good idea. A good > example is the Subversion protocol > (http://subversion.tigris.org/faq.html#interop): "The client and server > are designed to work as long as they aren't more than one major release > version apart. For example, any 1.X client will work with a 1.Y server. > However, if the client and server versions don't match, certain features > may not be available". Under such a strategy, you generally use a 'be > liberal in what you accept, and conservative in what you send' strategy, > which in CellML terms would require tools to support reactions, but > require that no new models be developed that use reactions. > > However, I don't think that this is a good approach for CellML: > 1) CellML tools generally support more than one version of CellML > anyway. For example, the CellML API has been quite explicitly coded to > support both CellML 1.1 and CellML 1.0. I expect that tools would > continue to support 1.1, 1.1.1, and 1.0 (in fact, any tool which > supports 1.1 properly will immediately be able to claim support for > CellML 1.1.1 models without making any code changes). name one tool outside the institute and my tools that supports CellML 1.1 models? > 2) As far as I know, no one has actually implemented a reaction based > simulator at the moment anyway. simulator - no, but I think you want to look at the extensive use of reaction elements in the SBML translation tools and the use people put those to. > Some one does also need to put these together to come up with a proposal > for a particular version (indeed, the document I produced does mop up a > list of issues on various pages and trackers and conso
Re: [cellml-discussion] [Tracker Item 42] New: CellML 1.1.1specification
David Nickerson wrote: > Hi Andrew, > > To simply delete reaction elements from a version 1.1.1 specification > seems the wrong approach to me. This means that while a 1.0 model is a > valid 1.1 model it could be an invalid 1.1.1 model. So the most minor > version change is the one that invalidates the model?!? > CellML 1.0 models are not valid 1.1 models because they are in the CellML 1.1 namespace. I think that 1.1.1 is backwards compatible with 1.1 (all 1.1.1 models are valid 1.1 models), it is simply a lack of forwards compatibility. Compare this with the relationship between CellML 1.0 and CellML 1.1 (there is neither backwards nor forwards compatibility due to the namespaces, and if you change the namespaces, there is forwards but not backwards compatibility). > If anything, a version 1.1.1 could mark the reaction element as > deprecated but still valid. Although if I recall some other > specification developments correctly (i.e., docbook), an element needs > to be marked for deprecation a version before it is actually deprecated > and removed from the language. I think that reaction has been informally deprecated for quite some time, and there has been an effort to get rid of most reactions. > Not sure what process we want to follow > for CellML but this 1.1.1 draft specification would not be the way I > hope we go. Otherwise how can anyone have confidence in using CellML at > all when core elements can arbitrarily be dropped from the specification > with no notice? > We do need to change the CellML specification if we are to make progress, and I think removing historical mistakes is as important as adding new features. Models which are CellML 1.1 compliant will forever remain CellML 1.1 compliant, because we are not changing CellML 1.1, and instead we are making a new version of the specification. Everyone expects that new versions of specifications will change some things. Furthermore, I don't exactly agree that we need to give 'notice' of things by way of formal specifications. Submitting a proposal for the CellML community to review is sufficient 'notice'. In the case of mature standards which require a high level of interoperability, a +-1 compatibility strategy is a good idea. A good example is the Subversion protocol (http://subversion.tigris.org/faq.html#interop): "The client and server are designed to work as long as they aren't more than one major release version apart. For example, any 1.X client will work with a 1.Y server. However, if the client and server versions don't match, certain features may not be available". Under such a strategy, you generally use a 'be liberal in what you accept, and conservative in what you send' strategy, which in CellML terms would require tools to support reactions, but require that no new models be developed that use reactions. However, I don't think that this is a good approach for CellML: 1) CellML tools generally support more than one version of CellML anyway. For example, the CellML API has been quite explicitly coded to support both CellML 1.1 and CellML 1.0. I expect that tools would continue to support 1.1, 1.1.1, and 1.0 (in fact, any tool which supports 1.1 properly will immediately be able to claim support for CellML 1.1.1 models without making any code changes). 2) As far as I know, no one has actually implemented a reaction based simulator at the moment anyway. I think that having a separate implementation notes document to describe what I have summarised would probably be a better way to achieve this. > Also, I'm wondering if we could set some ground rules for the > development of new versions of CellML. Rather than people simply > submitting draft specifications, I would favour an approach whereby > people submit proposals (using whatever technology we end up using) and > then we can discuss which version of CellML that proposal should be > considered for. Some one does also need to put these together to come up with a proposal for a particular version (indeed, the document I produced does mop up a list of issues on various pages and trackers and consolidate them into one document). I think that the process is: 1. Someone proposes issues for upcoming releases. 2. The group decides if they like the idea or not. If not, the idea either gets dropped or the proposer goes off and creates their own 'fork' of CellML and calls it something new (or ideally, some compromise is reached which achieves the same thing in a way everyone agrees on). 3. Someone collects proposals which are ready for inclusion into CellML, and makes a proposed new version of CellML. 4. The group discusses the new version of CellML, and if they like it, it becomes an official draft (which implementors are encouraged to work on). 5. Any problems in the official draft get fed back into it after going through the community. 6. If model authors have found the draft useful, it gets frozen and
Re: [cellml-discussion] [Tracker Item 42] New: CellML 1.1.1specification
Hi Andrew, To simply delete reaction elements from a version 1.1.1 specification seems the wrong approach to me. This means that while a 1.0 model is a valid 1.1 model it could be an invalid 1.1.1 model. So the most minor version change is the one that invalidates the model?!? If anything, a version 1.1.1 could mark the reaction element as deprecated but still valid. Although if I recall some other specification developments correctly (i.e., docbook), an element needs to be marked for deprecation a version before it is actually deprecated and removed from the language. Not sure what process we want to follow for CellML but this 1.1.1 draft specification would not be the way I hope we go. Otherwise how can anyone have confidence in using CellML at all when core elements can arbitrarily be dropped from the specification with no notice? Also, I'm wondering if we could set some ground rules for the development of new versions of CellML. Rather than people simply submitting draft specifications, I would favour an approach whereby people submit proposals (using whatever technology we end up using) and then we can discuss which version of CellML that proposal should be considered for. This would allow us to start developing a detailed road map of the features people want to include in new versions of CellML and the priority with which they are incorporated, as well as possible target dates for the various releases. David. [EMAIL PROTECTED] wrote: > http://trackerdev.cellml.org/show_bug.cgi?id=42 > >Summary: CellML 1.1.1 specification >Product: CellML Core Specifications >Version: Future versions > Platform: PC > OS/Version: Linux > Status: NEW > Severity: feature > Priority: Moderate priority > Component: Reactions > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > I have created a proposed draft specification for CellML 1.1.1, and put it up > at: > http://www.cellml.org/Members/miller/proposed_cellml_1.1.1/ > > The draft is essentially the same as CellML 1.1, except that: > 1) The version has been increased to 1.1.1. > 2) The introduction is updated to make it clear that Physiome Sciences Inc. is > no longer involved in CellML development. > 3) The reactions section has been deleted and all references to sections after > it have been renumbered. > 4) All references to reaction have been deleted. > 5) An copy-and-paste error reported by Alan Garny where we incorrectly used > the > word component instead of units was fixed. > 6) The DTD was updated to remove reactions and so on. > 7) I added myself as an author. > > Still to be done (please open new tracker items on these and set them to block > this issue you want to comment): > a) Update appendix D (changes since last version). > b) Repair figure 18, name is invalid on model (found by Alan Garny). > c) Fix the formula for computing new values for equations per the CellML 1.1 > errata. > d) Renumber figures. > e) Fix up some URLs which are incorrect, especially to historic data. > > -- David Nickerson, PhD Research Fellow Division of Bioengineering Faculty of Engineering National University of Singapore Email: [EMAIL PROTECTED] ___ 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, Thanks for that explanation. > We release the models publicly twice a year. just wondering what you mean by this? is it that the public database is only gets updated twice a year, while the model curators are working on the (private) next release of the models? Also, do you have any sense of curation (over and above the libSBML consistency checks) for a model not based on a particular peer-reviewed publication? 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? > 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? Thanks, David. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] [Tracker Item 42] New: CellML 1.1.1 specification
Hi, A brief note to the CellML Community about the tracker and its implications if you want to comment on the proposal: The tracker is currently only visible on the University of Auckland network (we are working on getting it externally usable). If you can, please feel free to reply to the issue through the tracker. If not, you may also reply on the mailing list and I will put your comments into the tracker. When the tracker becomes publicly visible, the URL to view the issue will be the same as below but will start with http://tracker.cellml.org. The tracker allows for people to be CCd to issues (and see all updates), so if anyone outside of the University of Auckland wants to be added to the CC list for this issue but can't do it themselves, please let me know by private e-mail and I will add you (you will be able to do this yourself when the tracker becomes publicly visible). Best regards, Andrew Miller [EMAIL PROTECTED] wrote: > http://trackerdev.cellml.org/show_bug.cgi?id=42 > >Summary: CellML 1.1.1 specification >Product: CellML Core Specifications >Version: Future versions > Platform: PC > OS/Version: Linux > Status: NEW > Severity: feature > Priority: Moderate priority > Component: Reactions > AssignedTo: [EMAIL PROTECTED] > ReportedBy: [EMAIL PROTECTED] > > > I have created a proposed draft specification for CellML 1.1.1, and put it up > at: > http://www.cellml.org/Members/miller/proposed_cellml_1.1.1/ > > The draft is essentially the same as CellML 1.1, except that: > 1) The version has been increased to 1.1.1. > 2) The introduction is updated to make it clear that Physiome Sciences Inc. is > no longer involved in CellML development. > 3) The reactions section has been deleted and all references to sections after > it have been renumbered. > 4) All references to reaction have been deleted. > 5) An copy-and-paste error reported by Alan Garny where we incorrectly used > the > word component instead of units was fixed. > 6) The DTD was updated to remove reactions and so on. > 7) I added myself as an author. > > Still to be done (please open new tracker items on these and set them to block > this issue you want to comment): > a) Update appendix D (changes since last version). > b) Repair figure 18, name is invalid on model (found by Alan Garny). > c) Fix the formula for computing new values for equations per the CellML 1.1 > errata. > d) Renumber figures. > e) Fix up some URLs which are incorrect, especially to historic data. > > > ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
[cellml-discussion] [Tracker Item 42] New: CellML 1.1.1 specification
http://trackerdev.cellml.org/show_bug.cgi?id=42 Summary: CellML 1.1.1 specification Product: CellML Core Specifications Version: Future versions Platform: PC OS/Version: Linux Status: NEW Severity: feature Priority: Moderate priority Component: Reactions AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] I have created a proposed draft specification for CellML 1.1.1, and put it up at: http://www.cellml.org/Members/miller/proposed_cellml_1.1.1/ The draft is essentially the same as CellML 1.1, except that: 1) The version has been increased to 1.1.1. 2) The introduction is updated to make it clear that Physiome Sciences Inc. is no longer involved in CellML development. 3) The reactions section has been deleted and all references to sections after it have been renumbered. 4) All references to reaction have been deleted. 5) An copy-and-paste error reported by Alan Garny where we incorrectly used the word component instead of units was fixed. 6) The DTD was updated to remove reactions and so on. 7) I added myself as an author. Still to be done (please open new tracker items on these and set them to block this issue you want to comment): a) Update appendix D (changes since last version). b) Repair figure 18, name is invalid on model (found by Alan Garny). c) Fix the formula for computing new values for equations per the CellML 1.1 errata. d) Renumber figures. e) Fix up some URLs which are incorrect, especially to historic data. -- Configure bugmail: http://trackerdev.cellml.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the tracker item. ___ 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
Alan Garny wrote: I think the current use of an embedded stimulus current is due to >> the repository being limited to CellML 1.0 models. The "correct" way to approach this problem is this: (1) define the mathematical model independent of parameter values and boundary/initial conditions; (2) (this is an optional step) import the mathematical model into a >> model which defines the common parameters and boundary conditions; (3) >> then import this model into any simulation specific models - it is at >> this level you define the particular stimulus protocol or other >> simulation specific parameter values and/or boundary conditions. For the case of a tissue/multi-cellular simulation, you'd probably >> use either (1) or (2) depending on the requirements of the tissue model >> and then connect the diffusive "stimulus" current to the single cell >> model stimulus current. While people (including myself) often point out the stimulus current >> as a special case, it is not really. Any extra or modified current >> being added to a model can be handled in the same way. For example, the >> way a (potassium) stimulus current is handled should not be any different >> to the case where you add the K(ATP) current to a model which does not already have one. >>> This looks like a very sound approach to me, but this relies on using >> CellML >>> 1.1 and though I would very much welcome a wider use of CellML 1.1, I >> cannot >>> help but wonder what to do with CellML 1.0 models... >> Unfortunately, I can't see any way to do this with 1.0 models other >> than >> to have multiple copies of the entire model with and without various >> boundary conditions imposed. This is, of course, one of the main >> reasons >> for CellML 1.1 :-) > > Shouldn't we therefore offer at least two different sets of CellML 1.0 > files? One that only contains the model itself and another that also > includes some simulation specific information? I actually replied to this somewhere else - I'll repeat it... We just talked about this issue in the meeting. We decided that it was probably worth providing one with and one without. Obviously the one without would not be able to be simulated in PCEnv or COR. > > Though CellML 1.1 is the obvious way to go, we have to accept the fact that > most CellML users probably only use CellML 1.0. But is that because they a.) don't need 1.1, b.) don't know how to use 1.1 or c.) want to use 1.1 but don't because the repository doesn't support it? I suspect it is either a or c, since most people would find out how to use 1.1 if it was a tool they thought would be useful. > >> Generally what I have done in the past for tissue models, is to use the >> simulation software to "override" aspects of the (1.0) cellular model >> as >> required for the particular tissue simulation. This would be enhanced >> by >> the use of the kinds of metadata mentioned below, which would allow >> software to automatically interpret certain key variables (stimulus >> currents, for example in electrophysiology models) - rather than the >> manual process currently employed (in CMISS). >> >> Personally, I would hope switching an application to using the CellML >> API and hence being able to handle CellML 1.1 models would be a much >> easier process than writing code to interpret certain pieces of >> metadata :-) > > Agreed in principle. I am just not sure whether this is always that easy in > practice. If it had been that 'easy', I would certainly have done it for > COR... :) > > Alan. > > ___ > 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] curation of BioModels Database
Dear CellML community, First of all, sorry for having be silent so long. We indeed read the exchanges about curation, and enjoyed them. It is nice to see that the various communities are committed to increase the quality of the quantitative models. We do not have much advice to give. The best we can do is to describe the procedure we use to curate our own models in BioModels Database. Hopefully you will find some reusable ideas. And if you have any comment, suggestion or criticism, they are most welcome! 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. Using libSBML, we check the syntax of the files. If a model is incorrect, it is rejected. Therefore, we accept only syntactically correct SBML files. The models are then entered in the curation pipeline. The first curation step is the consistency check. This is done by libSBML, which checks that all the rules listed in the SBML spec are fulfilled (e.g. units consistency, coherence of symbols etc.). Once a model is dubbed consistent, the export formats are generated (CellML, SciLab, XPP, BioPAX, GIF, SVG). The model can then be moved to the non-curated branch, or downloaded for further curation. The latter step is the verification of MIRIAM compliance. The curator checks that the structure of the model reflects the one described in the paper, that all the values are correct, and finally that one can reproduce published results *using different software than the one used by the authors*. If the model passes MIRIAM checks, it can be moved to the curated branch for annotation. We release the models publicly twice a year. I hope those explanations are clear enough. We remain available for any additional details. Various additional information can be found at: http://www.ebi.ac.uk/compneur-srv/biomodels/doc/curation.html http://www.ebi.ac.uk/compneur-srv/biomodels/doc/annotation.html Best regards, The BioModels Database team -- Nicolas LE NOVERE, Computational Neurobiology, EMBL-EBI, Wellcome-Trust Genome Campus, Hinxton, Cambridge, CB10 1SD, UK Tel: +44(0)1223494521, Fax: +44(0)1223494468, Mob: +44(0)7833147074 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] embedded stimulus currents in CellML models
>> Unfortunately, I can't see any way to do this with 1.0 models other >> than >> to have multiple copies of the entire model with and without various >> boundary conditions imposed. This is, of course, one of the main >> reasons >> for CellML 1.1 :-) > > Shouldn't we therefore offer at least two different sets of CellML 1.0 > files? One that only contains the model itself and another that also > includes some simulation specific information? yep - thats what I'd suggest. I think having models in the repository with stimulus currents, by default, is a byproduct of repository browsers wanting to be able to download the model and run it without having to change anything. Which also partly drives the sticking up of PCEnv sessions files, I guess > Though CellML 1.1 is the obvious way to go, we have to accept the fact that > most CellML users probably only use CellML 1.0. I would hope that most CellML users don't care that they're using CellML at all, let alone which version of it they are "using". My hope would be for all application developers to use the "standard" CellML API and hence we would not have to worry about coming up with hacky solutions to problems that have already been solved in newer versions of CellML. Of course, as you point out below that might not be so easy to achieve after all... ;-) >> Personally, I would hope switching an application to using the CellML >> API and hence being able to handle CellML 1.1 models would be a much >> easier process than writing code to interpret certain pieces of >> metadata :-) > > Agreed in principle. I am just not sure whether this is always that easy in > practice. If it had been that 'easy', I would certainly have done it for > COR... :) agreed :( ___ 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
> >> I think the current use of an embedded stimulus current is due to > the > >> repository being limited to CellML 1.0 models. The "correct" way to > >> approach this problem is this: (1) define the mathematical model > >> independent of parameter values and boundary/initial conditions; (2) > >> (this is an optional step) import the mathematical model into a > model > >> which defines the common parameters and boundary conditions; (3) > then > >> import this model into any simulation specific models - it is at > this > >> level you define the particular stimulus protocol or other > simulation > >> specific parameter values and/or boundary conditions. > >> > >> For the case of a tissue/multi-cellular simulation, you'd probably > use > >> either (1) or (2) depending on the requirements of the tissue model > and > >> then connect the diffusive "stimulus" current to the single cell > model > >> stimulus current. > >> > >> While people (including myself) often point out the stimulus current > as > >> a special case, it is not really. Any extra or modified current > being > >> added to a model can be handled in the same way. For example, the > way a > >> (potassium) stimulus current is handled should not be any different > to > >> the case where you add the K(ATP) current to a model which does not > >> already have one. > > > > This looks like a very sound approach to me, but this relies on using > CellML > > 1.1 and though I would very much welcome a wider use of CellML 1.1, I > cannot > > help but wonder what to do with CellML 1.0 models... > > Unfortunately, I can't see any way to do this with 1.0 models other > than > to have multiple copies of the entire model with and without various > boundary conditions imposed. This is, of course, one of the main > reasons > for CellML 1.1 :-) Shouldn't we therefore offer at least two different sets of CellML 1.0 files? One that only contains the model itself and another that also includes some simulation specific information? Though CellML 1.1 is the obvious way to go, we have to accept the fact that most CellML users probably only use CellML 1.0. > Generally what I have done in the past for tissue models, is to use the > simulation software to "override" aspects of the (1.0) cellular model > as > required for the particular tissue simulation. This would be enhanced > by > the use of the kinds of metadata mentioned below, which would allow > software to automatically interpret certain key variables (stimulus > currents, for example in electrophysiology models) - rather than the > manual process currently employed (in CMISS). > > Personally, I would hope switching an application to using the CellML > API and hence being able to handle CellML 1.1 models would be a much > easier process than writing code to interpret certain pieces of > metadata :-) Agreed in principle. I am just not sure whether this is always that easy in practice. If it had been that 'easy', I would certainly have done it for COR... :) 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
>> I think the current use of an embedded stimulus current is due to the >> repository being limited to CellML 1.0 models. The "correct" way to >> approach this problem is this: (1) define the mathematical model >> independent of parameter values and boundary/initial conditions; (2) >> (this is an optional step) import the mathematical model into a model >> which defines the common parameters and boundary conditions; (3) then >> import this model into any simulation specific models - it is at this >> level you define the particular stimulus protocol or other simulation >> specific parameter values and/or boundary conditions. >> >> For the case of a tissue/multi-cellular simulation, you'd probably use >> either (1) or (2) depending on the requirements of the tissue model and >> then connect the diffusive "stimulus" current to the single cell model >> stimulus current. >> >> While people (including myself) often point out the stimulus current as >> a special case, it is not really. Any extra or modified current being >> added to a model can be handled in the same way. For example, the way a >> (potassium) stimulus current is handled should not be any different to >> the case where you add the K(ATP) current to a model which does not >> already have one. > > This looks like a very sound approach to me, but this relies on using CellML > 1.1 and though I would very much welcome a wider use of CellML 1.1, I cannot > help but wonder what to do with CellML 1.0 models... Unfortunately, I can't see any way to do this with 1.0 models other than to have multiple copies of the entire model with and without various boundary conditions imposed. This is, of course, one of the main reasons for CellML 1.1 :-) Generally what I have done in the past for tissue models, is to use the simulation software to "override" aspects of the (1.0) cellular model as required for the particular tissue simulation. This would be enhanced by the use of the kinds of metadata mentioned below, which would allow software to automatically interpret certain key variables (stimulus currents, for example in electrophysiology models) - rather than the manual process currently employed (in CMISS). Personally, I would hope switching an application to using the CellML API and hence being able to handle CellML 1.1 models would be a much easier process than writing code to interpret certain pieces of metadata :-) >> There probably is a case for making stimulus protocols a little more >> explicit in domain specific interfaces. The proper way to handle this >> without compromising the generality of CellML would be to add metadata >> describing which variables are, for example, stimulus voltages, and >> which components (which will generally be imported components) are >> stimulus currents. > > This might be a very useful thing to have indeed (or rather: it wouldn't > harm having such information available). yep - and I think this is part of the general annotation of variables in models. Again, there is really nothing special about a stimulus current variable in a model, just in the simulation software's use of the variable. >> A domain specific command could then perform tasks >> such as, for example, replacing the stimulus protocol connected to the >> designated variables with a 'standard' stimulus of a user defined nature >> (which could be an arbitrary mathematical function, or even a FieldML >> field). >> >> A curve-based graphical editor for some small subset of MathML (which >> lets you drag points around on the screen to edit MathML parameters) >> would also make it easier to input and edit stimuli. > > Yes, that's the kind of thing we had started doing long before CellML was > available, and therefore something that some modellers would at least very > much welcome indeed. Its also something that is currently available in CMISS :-) Andre. ___ 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
> From Alan Garny (following some discussion on stimulus currents with > the Auckland group): > > > CellML models that require a stimulus protocol to generate an action > > potential currently implement one in the CellML model itself (Noble 98 is > > one such example indeed). Still, I don't think such a protocol should be > > part of the model. The only reason Penny Noble did it that way in the > first > > place is that we had no other choice in COR (she was waiting for me to > > implement my concept of COR project). > > > > Still, what happens if I want to use that model in a multi-cellular > > environment? Ideally I would, in that environment and at some point, > specify > > the different cellular models that I want to use by selecting different > > CellML files. Now, if those CellML files contain a hard-coded stimulus > > protocol in them, this will obviously cause problems. > > > > We may therefore want to think of another way of incorporating a stimulus > > protocol, not to mention that one could come up with a different protocol > > and still get an action potential (granted, the underlying physiology will > > likely be different, but that's another debate). What about, therefore, > > making the stimulus protocol(s?) available in some metadata? From there, > the > > modelling software could extract that protocol and use it, if and only if > > the user wants it. > > > > I would imagine you guys have already discussed this before, in which case > I > > would appreciate any conclusion that has been drawn about this. > > While I think that we have discussed this before, but perhaps not > officially, I'll kick it off here :-) > > I think the current use of an embedded stimulus current is due to the > repository being limited to CellML 1.0 models. The "correct" way to > approach this problem is this: (1) define the mathematical model > independent of parameter values and boundary/initial conditions; (2) > (this is an optional step) import the mathematical model into a model > which defines the common parameters and boundary conditions; (3) then > import this model into any simulation specific models - it is at this > level you define the particular stimulus protocol or other simulation > specific parameter values and/or boundary conditions. > > For the case of a tissue/multi-cellular simulation, you'd probably use > either (1) or (2) depending on the requirements of the tissue model and > then connect the diffusive "stimulus" current to the single cell model > stimulus current. > > While people (including myself) often point out the stimulus current as > a special case, it is not really. Any extra or modified current being > added to a model can be handled in the same way. For example, the way a > (potassium) stimulus current is handled should not be any different to > the case where you add the K(ATP) current to a model which does not > already have one. This looks like a very sound approach to me, but this relies on using CellML 1.1 and though I would very much welcome a wider use of CellML 1.1, I cannot help but wonder what to do with CellML 1.0 models... > From Andrew Miller: > > There probably is a case for making stimulus protocols a little more > explicit in domain specific interfaces. The proper way to handle this > without compromising the generality of CellML would be to add metadata > describing which variables are, for example, stimulus voltages, and > which components (which will generally be imported components) are > stimulus currents. This might be a very useful thing to have indeed (or rather: it wouldn't harm having such information available). > A domain specific command could then perform tasks > such as, for example, replacing the stimulus protocol connected to the > designated variables with a 'standard' stimulus of a user defined nature > (which could be an arbitrary mathematical function, or even a FieldML > field). > > A curve-based graphical editor for some small subset of MathML (which > lets you drag points around on the screen to edit MathML parameters) > would also make it easier to input and edit stimuli. Yes, that's the kind of thing we had started doing long before CellML was available, and therefore something that some modellers would at least very much welcome indeed. Alan. ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
