Issue 239: Release policy and draft usage recommendation
Posted by Martin Scholz on 31/1/2014
the last official version (v5.0.4) of the CIDOC CRM has been released more than two years ago. Since then, new revisions were released as drafts. Before the last official release, there were official releases at least once per year and hardly no drafts. (At least from what I read on the CRM website. [1,2,3])
As a user of the CIDOC CRM I am wondering what is the status of a draft like version 5.1.2?
I would like to use classes and properties introduced by the drafts in some applications, but I am feeling a bit uncomfortable if they are only based on a draft and likely(?) to change in future versions... In particular I have the following questions:
- What is the release policy of the SIG? Is there something like a roadmap for an official release in the near future or even a release cycle, e.g. one official release per year approx. as it was in the past?
- A transparent policy from the SIG would for instance make the decision easier, whether to better wait for an official release or use an unstable version.
- What is the status of draft releases and constructs introduced in drafts?
Does the SIG give recommendation if and how such constructs may be used by CRM users?
As an example, the RDFS version of v5.1  implements properties P150, P151 and P152 introduced by draft v5.1. Is their use in applications encouraged or discouraged? If discouraged, how about the whole file?
The same questions apply to the FRBRoo releases : Version 2.0 from mid-2013 is a draft, the last "official" release is two years old. Will there be a stable version in the near future and what is the status of the latest RDFS file?
Posted by Martin 14/4/2014
Here a proposed explanation to the release policy of CRM-SIG:
a) Draft releases are published to indicate to users which changes are upcoming.
On one side, this should provide more trust in the stability of the rest of the constructs, even though non-backwards compatible changes are very rare. Mostly, we add new properties, generalize domains or ranges, or change scope notes.
On the other side, this is to encourage users which do have a mapping problem the new constructs will solve to use them right away.
We us to publish draft releases when we regard that new concepts are accepted, whereas details of scope notes are yet to be settled.
Therefore RDFS versions of draft releases are encouraged to be used.
b) An official release is a form with scope notes and concepts in a consistent state. There is no policy of when a new release is to be made. New constructs are entered on a request & evidence base.
c) Normally, any set of new concepts introduced should result in a second order change of version number. (5.0 - 5.1 etc.).
d) A change of scope notes, introduction or generalization of property range should result in a third order change of version number. (5.0.1 - 5.0.2 etc.).
e) A change of practical scope or modelling principle should result in a first order change.
I believe that FRBRoo should soon provide a stable release of RDFS. I suggest to regard the current definition (result of the Den Haag Meeting) of FRBRoo should be regarded as "official" in RDFS, regardless of the publishing policy of IFLA wrt minor editorial changes, which has blocked publication so far.
I suggest to produce an official FRBRoo 2.0 in RDFS by May 15, 2014.
I propose to relabel CIDOC CRM version 5.1.2 to 6.0, because we have extended the scope to spatiotemporal reasoning, according to discussions ISSUE 239.
PLEASE VOTE yes or no.
In the sequence, I suggest to declare an official release which corresponds to the new ISO version as CIDOC CRM version 5.x.x, as appropriate.
PLEASE VOTE yes or no.
Posted by CB on 14/4/2014 - Results of voting
On 14/4/2014, posted by
Christos Papatheodorou : I vote yes
Carlisle, Philip : +1
Athanasios Velios: For the newcomers of the list, who has the right to vote?
email@example.com: I vote yes to both proposals.
Øyvind Eide : yes
On 15/4/2014, posted by
Riva Patricia <Patricia.Riva@banq.qc.ca> : I vote Yes also.
Richard P Smiraglia <firstname.lastname@example.org> :I vote YES on both.
Steve Stead: I vote YES to both.
Christian Emil Ore: I agree, and vote yeas to both.
The crm-sig accepted this proposal by vote