Chronological Thread 

< Chronological >      < Thread >

---

On 4/12/07, David Nickerson <david.nickerson at nus.edu.sg> wrote:
> 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.

Yes.

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

Versions should be easy, they are any modification of a model
whatsoever. Yes this does mean someone can replace a model with an
entirely different structure, but that's their prerogative, and it's
not that greater practice to break dependencies on it - which we
should be testing each time a model is updated.

I don't think 'version' should hold any other meaning except 'change
of bytes in the object'. There is no distinction between removing
white space in an xml file to changing its elements. The more
important consideration would be what representation is chosen to
determine that there has been a change in bytes.

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

While I did propose this, I don't think it has to be this way without
really going through the mechanics of what we are expecting from a
URI, apart from it being permanent. For example, what use-cases does
building a URI based on metadata have (where you would have a many to
one relation - i.e. many virtual URIs mapping to the physical resource
http://www.cellml.org/models/1jwe84jkf73kf93kg) ?

I have also been jumping up and down about using subversion's webdav
REST type URIs; but that also has some idiosyncrasies of code
versioning that doesn't cover all our usecases. For example, branching
a model makes sense in the case of perhaps incrementally improving a
model through large structural changes, but doesn't make sense in
terms of creating a model that is simply another parameterisation of
another.

I think the subversion-like URIs work well for the intended function
of version and changesets, and should remain orthogonal to URI pieces
that reflect logical local groupings - for example parameterisations.

So the question would be, should some sub parts of the URI capture the
mental logical grouping that the author is placing on them ...

e.g.
model-1/generic/1.xml
model-1/parameterisations/1.xml
model-1/parameterisations/2.xml

Anyway, yes. Needs a working group, but also needs a starting document
that at least lists the objectives of this before we all throw in our
draft-specifications.

cheers
Matt


>
>
> 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 mailing list
> cellml-discussion at cellml.org
> http://www.cellml.org/mailman/listinfo/cellml-discussion
>

---

• [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
          • [cellml-discussion] model variants(?): e.g. where multiple cell types are described by the same model in different files, Matt , 04/12/2007

---

Archive powered by MHonArc 2.6.18.