Chronological Thread 

< Chronological >      < Thread >

---

I think we really need to start thinking about the model repository
structure and work flows as we move more toward a CellML 1.1 world.
Especially in the current framework you can not imply any sequential
nature of the version numbering - it has already been used for too many
different interpretations. You can easily see the case where version 1
is the original model encoding, version 2 was curated by X with further
curation by Y into version 3. But then person Z takes version 1 and
corrects just a single parameter value and calls it version 4.

As part of the outcomes from the workshop I will be proposing that we
set up a working group to establish the path we are going to take moving
the model repository forward. Things like the model URI need to be
considered in terms of working with CellML 1.1 model hierarchies and the
importing into the repository of such hierarchies from varying
file-based structures. It should also be possible for non-published
models to be stored in the model repository. I suspect the only way we
are going to be able to define stable URIs for models is to go with
Matt's original proposal (I think it was Matt's) and simply have a
unique ID for each model in the repository
(http://www.cellml.org/models/1jwe84jkf73kf93kg) and then provide
services to be able to retrieve such URIs based on model metadata.


Andre.

Tommy Yu 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.
>>
>
> 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 at 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: david.nickerson at nus.edu.sg

---

• [cellml-discussion] Workshop presentations now available, David Nickerson, 04/11/2007
  • [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files, James Lawson, 04/12/2007
    • [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files, James Lawson, 04/12/2007
      • [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files, Matt , 04/12/2007
        • [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files, Tommy Yu, 04/12/2007
          • [cellml-discussion] model variants(?): e.g. where multiple celltypes are described by the same model in different files, David Nickerson, 04/12/2007
            • [cellml-discussion] model variants(?): e.g. where multiple celltypes are described by the same model in different files, Matt , 04/12/2007
              • [cellml-discussion] model variants(?): e.g. where multiplecelltypes are described by the same model in different files, David Nickerson, 04/12/2007
        • [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files, James Lawson, 04/12/2007
          • [cellml-discussion] model variants(?): e.g. where multiple celltypes are described by the same model in different files, David Nickerson, 04/12/2007
            • [cellml-discussion] curation annotation framework, James Lawson, 04/12/2007
              • [cellml-discussion] curation annotation framework, David Nickerson, 04/12/2007
              • [cellml-discussion] curation annotation framework, James Lawson, 04/12/2007
              • [cellml-discussion] curation annotation framework, Matt , 04/12/2007
              • [cellml-discussion] curation annotation framework, David Nickerson, 04/12/2007
              • [cellml-discussion] curation annotation framework, David Nickerson, 04/12/2007

---

Archive powered by MHonArc 2.6.18.