Chronological Thread 

< Chronological >      < Thread >

---

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] 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

---

Archive powered by MHonArc 2.6.18.