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