Issue 373: Managing CRM and CRM extension versions

Starting Date: 
2018-05-14
Status: 
Open
Background: 

Posted by Thanasis Velios on 9/5/2018

During the last meeting we agreed to review the way that the
documentation about CRM base and its extensions is managed. This is
probably as part of issue 358, but there have been messages in the list
about this issue (e.g. by Rob, but I can't find the reference)

Francesco, George and I discussed this and produced the following text,
which is a first attempt to specify what it is we need:

---

# Specification of CRM-SIG work

## Functions

### Versioning:

* manage CRM core and extensions document versions, i.e. specifying the
classes and properties (and their versions) which exist in each
document, to ensure coherence among versions of extensions and CRM core
versions,
* manage content changes in the class and property declarations in
current document version (including scope notes),
* document arguments for each committed change and dismissed proposal

### Visualization:

* visualize class and property hierarchies
* visualize combinations of extensions with CRM core
* visualize evolution in time of CRM core and extensions

### Serialization:

* produce a formatted encoding (e.g. PDF file) for each document version
* produce an RDFS encoding for each document version

### Interpretation and best practice:

* capture discussions about classes, properties and their meaning
* recommend best practice at implementation level

## Roles

* SIG members: participate in meetings to make decisions on version and
scope note changes
* version maintainers (SIG): collect contributions, editorial work,
animate and moderate the discussion in the community, ensure completeness
* version contributors (SIG) : produce and discuss the content
(including serializations) and propose changes
* public (non-SIG) : discuss the content, raise questions on interpretation

### Access level

* Public, contributors and SIG members raise questions, discuss
proposals, comment, answer questions
* Contributors can create issues and recommend changes at any level
* Maintainers summarize/introduce issues for discussion in the SIG
* SIG members 'vote' on issues, classes definitions, ...

## Existing platforms:

* Drupal in FORTH (existing but not accessible for contributors and
maintainers)
* dataforhistory.org application (open, but still under development) +
an internal forum / API
* GitHub (versioning, discussions, API)

---

It would be useful to receive feedback on whether this captures the
SIG's activities and whether there are any other platforms we should be
considering. We can then assign people to evaluate the different
platforms, so volunteers with expertise on a platform are welcome. 

Current Proposal: 

In the 41st joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 34th FRBR - CIDOC CRM Harmonization meeting, the sig decided to ask George, Oyvind and Francesco to collaborate for making a proposal about improving the design of CIDOC-CRM site and making implementations' proposals.

Lyon, May 2018

 

In the 44th joint meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9; 37th FRBR - CIDOC CRM Harmonization meeting, the sig pondered on the steps necessary for maintaining the crm (base and extensions) and went through proposals regarding tools that might come in handy in the process. 
Most sig members mentioned that the process of maintaining the models (integrating changes from the master document to the rdfs version and testing for consistency across models/different versions of models) is extremely cumbersome and error-prone as it is now done manually. Which is why they would prefer updating the models and checking for compatibility issues among them to be done in a (semi)automated way. 
In principle none was against that, but it's not a pragmatic solution given the lack of funding. 

FB proposed that OntoME be used for the purpose of supplementing the maintenance of the models, as it can do versioning, text comparison etc. However, opting for one tool or another at this stage would require optimizations --that they, themselves would require funding to be implemented --so this solution was abandoned.
CB suggested that the sig describe the functionality that a system would require to assist in maintaining the crm (base and compatible models) but without setting its mind on one particular tool.
DECISION: There should be an outline of what is needed to maintain the models. 
HW: AG is assigned with preparing a requirement analysis regarding what the tool/service should do and the sig is to review that.

Paris, June 2019

Meetings discussed: