Chronological Thread 

< Chronological >      < Thread >

---

I thought it was time to bring this up again.

The current interpretation of versions of a cellml model as
represented in the URI we see for models in the model repository has
caused a bit of confusion in terms of what it means and how to use it.

The next iteration of the repository proposes o introduce a versioning
system more typical to that of software versioning systems such as
subversion. In fact a first implementation is likely to be model
documents populating a subversion repository.

This gives us a notion of version, which is a number that will
increment to a new number for every change - however small (e.g. one
character) - in the document. This is great from the point of view of
being able to roll back very to very precise states of the model
document. This also allows us to refer to changesets, which are the
groupings of changes that have occurred across the entire repository
in a single commit by an individual.

I need to stress that this is all at the document level, not at an
abstract level, and I feel that in some conversations, people have
actually been talking about abstract versions, but confusing it with
document versions.

I think there is a case for a model or perhaps workspace to have an
abstract version - just like software. You know, those numbers like
1.1-alpha, 1.1-release etc. In the meeting today we talked a bit about
curation data. In this case, the curation data of a model is relevant
to a specific version of a model. But the catch 22 in some people's
minds was that by adding in any metadata representing curation, the
version of the model would increase, and that curation data would then
end up being applied to that version. This highlights the confusion I
am trying to get at here.

Ideally the model (or model set/workspace - especially in the case of
imports) would have an abstract version. This would not change as a
consequence of changing the document - only the repository document
version would change. So the addition of new metadata to the model
would still be applied to the abstract version it was intended to be
applied to.

The difference between abstract version and document version is also
highlighted when we look at a workspace of models related through
imports. To me this workspace of models is a unit of work that should
have an abstract version applied to it and could be released as a
versioned bundle in archive formats similar to software releases.
Obviously someone working on the documents in this workspace will be
changing various documents at different times and therefore their
document versions in the repository. They would all individually have
different document versions, but would all still be part of the same
abstract version.

The minimal case is a single CellML 1.0 model document with all
metadata residing inside it. This would of course have an abstract
version and a document version and be treated no differently to a
group of models that were related through an abstract version.

Using abstract versions also means multiple workspaces can incorporate
the same or different document versions of the same models into their
"package".

So, more concretely, I am proposing that:
- we start the notion of a versioned workspace or package.
- the package is named and has an abstract version
- for the minimal case of a CellML 1.0 model and metadata in a single
document, the package name can be the model name, but the abstract
version is still separate from the document version
- that we add a package name and version number metadata construct to
all the models.
- that for most purposes in our discussions we will be talking about
this abstract version and what it would mean to increase its major or
minor numbers, alpha, beta, or release status etc.

cheers
Matt

---

• [cellml-discussion] Model versions, Matt , 08/15/2007
  • [cellml-discussion] Model versions, David Nickerson, 08/15/2007
    • [cellml-discussion] Model versions, Matt , 08/15/2007

---

Archive powered by MHonArc 2.6.18.