[cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files
Hi folks, I'm just fishing for some comments on how to handle cases where there are models which describe, for example, the properties of multiple cell types. Bondarenko et al. 2004 is a good example of this: In the Bondarenko et al. 2004 publication described here, the authors develop a computer model of the mouse ventricular action potential (see below). The model includes parameters for both the apex and the septum regions of the heart (the apex parameters have been substituted into the CellML version of the model described in ), and this helps to illustrate how there are regional differences in myocyte repolarisation in the mouse heart. Penny Noble has just sent me a zip file containing the latest versions of all the models she has curated for COR. I'm currently in the process of comparing these versions to the latest versions we have on the repository. In some cases, she has provided several variants of the same model which describe different cell types, as above. Firstly, are these true 'variants'? If so, then the matter is relatively simple. Unfortunately, if one goes through the repository list, variants simply come up as a duplication of the model listing, with no information concerning what the variant represents. This is something I imagine will be fixed in time, but is presently rather frustrating considering the issue at hand. Does anyone have any comments on this? Should I simply put the files up as different variants, with a note in the documentation? Thanks, James Lawson ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files
Addendum: The model in the repository describes the apex cells only. James Lawson wrote: Hi folks, I'm just fishing for some comments on how to handle cases where there are models which describe, for example, the properties of multiple cell types. Bondarenko et al. 2004 is a good example of this: In the Bondarenko et al. 2004 publication described here, the authors develop a computer model of the mouse ventricular action potential (see below). The model includes parameters for both the apex and the septum regions of the heart (the apex parameters have been substituted into the CellML version of the model described in ), and this helps to illustrate how there are regional differences in myocyte repolarisation in the mouse heart. Penny Noble has just sent me a zip file containing the latest versions of all the models she has curated for COR. I'm currently in the process of comparing these versions to the latest versions we have on the repository. In some cases, she has provided several variants of the same model which describe different cell types, as above. Firstly, are these true 'variants'? If so, then the matter is relatively simple. Unfortunately, if one goes through the repository list, variants simply come up as a duplication of the model listing, with no information concerning what the variant represents. This is something I imagine will be fixed in time, but is presently rather frustrating considering the issue at hand. Does anyone have any comments on this? Should I simply put the files up as different variants, with a note in the documentation? Thanks, James Lawson ___ 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] model variants(?): e.g. where multiple cell types are described by the same model in different files
This scratches a couple of important pending issues: 1) I feel the term 'variant' is odd (even though I originally suggested it). It was intended to mean that the model labelled as a variant is a variation of the one it is a variant of. However, this isn't really a very applicable definition, especially if one may consider a model to be a variant of more than one other model. Since variant is bound up in the URI and name then this makes for dilemmas. My suggestion would be that we drop variants altogether. We can mark relations in a better way through metadata. I am also querying whether the flatness of our URI scheme is appropriate for our uses. e.g. perhaps: http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson_2004_version01 should be something like http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson/2004/ventricular?rev=1 (no that is not a formal proposal) But this doesn't really help you now. The technically correct method at the moment would be that the new models that are similar but different only in their parameterisations are added as variants. Another alternative in the short term would to simply name the models as separate models (which they are) and we define now an rdf relation scheme that is very explicitly about how different models at different URIs relate to the one you are editing. This would mean that Tommy needs to update the rendering of the pages for these models to reflect this information. 2) These models should use imports so that we can at least point to the generic model and then the specialised parameterised ones. But that won't work right now because the repository can't handle 1.1 models. cheers Matt On 4/12/07, James Lawson [EMAIL PROTECTED] wrote: Addendum: The model in the repository describes the apex cells only. James Lawson wrote: Hi folks, I'm just fishing for some comments on how to handle cases where there are models which describe, for example, the properties of multiple cell types. Bondarenko et al. 2004 is a good example of this: In the Bondarenko et al. 2004 publication described here, the authors develop a computer model of the mouse ventricular action potential (see below). The model includes parameters for both the apex and the septum regions of the heart (the apex parameters have been substituted into the CellML version of the model described in ), and this helps to illustrate how there are regional differences in myocyte repolarisation in the mouse heart. Penny Noble has just sent me a zip file containing the latest versions of all the models she has curated for COR. I'm currently in the process of comparing these versions to the latest versions we have on the repository. In some cases, she has provided several variants of the same model which describe different cell types, as above. Firstly, are these true 'variants'? If so, then the matter is relatively simple. Unfortunately, if one goes through the repository list, variants simply come up as a duplication of the model listing, with no information concerning what the variant represents. This is something I imagine will be fixed in time, but is presently rather frustrating considering the issue at hand. Does anyone have any comments on this? Should I simply put the files up as different variants, with a note in the documentation? Thanks, James Lawson ___ 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
Re: [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files
Matt wrote: This scratches a couple of important pending issues: 1) I feel the term 'variant' is odd (even though I originally suggested it). It was intended to mean that the model labelled as a variant is a variation of the one it is a variant of. However, this isn't really a very applicable definition, especially if one may consider a model to be a variant of more than one other model. Since variant is bound up in the URI and name then this makes for dilemmas. My suggestion would be that we drop variants altogether. We can mark relations in a better way through metadata. My thoughts exactly. In a perfect world, the models would start off as version01 and finish at whatever version## and they are all sequential changes, but then (I think) we have cases where we have models originally written using COR but then PCEnv doesn't run it. Now we have a new version of the model which will work in PCEnv but may or may not work in COR. Now someone gets the latest version and may find COR no longer reads it. Version should signify improvement. Okay, about variants. (bad example time). We have variant01 and variant02. Which is PCEnv, which is COR? That was just two, what if we have a bigger and more developed model? I agree, please drop variants. I am also querying whether the flatness of our URI scheme is appropriate for our uses. e.g. perhaps: http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson_2004_version01 should be something like http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson/2004/ventricular?rev=1 (no that is not a formal proposal) I definitely like that second URI a lot better (I also discussed with James briefly about this and that was similar to the idea I had), a very brief statement that might explain which model I am looking at instead of trying to find out what version01_variant01 might mean. Also, another benefit of treating the list of authors (and year-month-day as publication date?) as a directory could potentially pave the way to attaching files and clean URIs to point to them. Of course, this is not a formal proposal, but it's a good idea. As for changing URIs again, I have to say it is necessary, but please do make this one permanent (as in, design it good). But this doesn't really help you now. The technically correct method at the moment would be that the new models that are similar but different only in their parameterisations are added as variants. Another alternative in the short term would to simply name the models as separate models (which they are) and we define now an rdf relation scheme that is very explicitly about how different models at different URIs relate to the one you are editing. This would mean that Tommy needs to update the rendering of the pages for these models to reflect this information. Ugh making me work ;). Possible idea, but I will have to defer this for a bit. I do agree, the current lack of relationship between links between updates bother me. Let me finish fixing what's broken first. 2) These models should use imports so that we can at least point to the generic model and then the specialised parameterised ones. But that won't work right now because the repository can't handle 1.1 models. I will be working on that when I finish up getting the metadata class integrated into the repository. The hiccup for 1.1 models (I think) is the XSLT involved with the transformation (which is used by certain chunks of code), but there may be more than that. There is no real special limitations as to why 1.1 models cannot be stored into the repository. As the requirements for the repository to properly support 1.1 models are much greater (recall the discussion during the CellML workshop), I've been putting that off until it becomes absolutely necessary. I also have notes about the quirks to get 1.1 going written down somewhere, but it's not up yet. Cheers, Tommy. cheers Matt ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files
Matt wrote: This scratches a couple of important pending issues: 1) I feel the term 'variant' is odd (even though I originally suggested it). It was intended to mean that the model labelled as a variant is a variation of the one it is a variant of. However, this isn't really a very applicable definition, especially if one may consider a model to be a variant of more than one other model. Since variant is bound up in the URI and name then this makes for dilemmas. My suggestion would be that we drop variants altogether. We can mark relations in a better way through metadata. I am also querying whether the flatness of our URI scheme is appropriate for our uses. e.g. perhaps: http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson_2004_version01 should be something like http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson/2004/ventricular?rev=1 (no that is not a formal proposal) But this doesn't really help you now. The technically correct method at the moment would be that the new models that are similar but different only in their parameterisations are added as variants. Right. Another alternative in the short term would to simply name the models as separate models (which they are) That's an interesting proposal. Given the current way that the models are listed, that would be a good way of displaying that the models are variants. If you upload two variants of a model, they come up as duplicate listings (i.e. no information is displayed about the nature of the variant,) so simply making them two different models would get around this. Anyone else have comments on this? and we define now an rdf relation scheme that is very explicitly about how different models at different URIs relate to the one you are editing. This would mean that Tommy needs to update the rendering of the pages for these models to reflect this information. 2) These models should use imports so that we can at least point to the generic model and then the specialised parameterised ones. But that won't work right now because the repository can't handle 1.1 models. In this case there is no generic model available. The model we have on the repository for Bondarenko et al. 2004 is the one describing the apical cells. cheers Matt ___ cellml-discussion mailing list cellml-discussion@cellml.org http://www.cellml.org/mailman/listinfo/cellml-discussion
Re: [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files
On 4/12/07, James Lawson [EMAIL PROTECTED] wrote: Matt wrote: This scratches a couple of important pending issues: 1) I feel the term 'variant' is odd (even though I originally suggested it). It was intended to mean that the model labelled as a variant is a variation of the one it is a variant of. However, this isn't really a very applicable definition, especially if one may consider a model to be a variant of more than one other model. Since variant is bound up in the URI and name then this makes for dilemmas. My suggestion would be that we drop variants altogether. We can mark relations in a better way through metadata. I am also querying whether the flatness of our URI scheme is appropriate for our uses. e.g. perhaps: http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson_2004_version01 should be something like http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson/2004/ventricular?rev=1 (no that is not a formal proposal) But this doesn't really help you now. The technically correct method at the moment would be that the new models that are similar but different only in their parameterisations are added as variants. Right. So given the current system I would do the following: 1) create a generic form of the model without parameters set - a broken model in one sense 2) add these other models that are different parameterisations of this model as variants of this generic-ish one 3) add the existing apical cell one in as a variant of this generic model also. 4) put an HTTP redirect in for the old URI to point to the variant form. I take it the existing one is: http://www.cellml.org/models/bondarenko_szigeti_bett_kim_rasmusson_2004_version01 which actually says: The model includes parameters for both the apex and the septum regions of the heart (the apex parameters have been substituted into the CellML version of the model described in ) Which I find confusing. Another alternative in the short term would to simply name the models as separate models (which they are) That's an interesting proposal. Given the current way that the models are listed, that would be a good way of displaying that the models are variants. If you upload two variants of a model, they come up as duplicate listings (i.e. no information is displayed about the nature of the variant,) so simply making them two different models would get around this. Anyone else have comments on this? and we define now an rdf relation scheme that is very explicitly about how different models at different URIs relate to the one you are editing. This would mean that Tommy needs to update the rendering of the pages for these models to reflect this information. 2) These models should use imports so that we can at least point to the generic model and then the specialised parameterised ones. But that won't work right now because the repository can't handle 1.1 models. In this case there is no generic model available. The model we have on the repository for Bondarenko et al. 2004 is the one describing the apical cells. cheers Matt ___ 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
