[LOCKED] COOS governance document: Part 1: Foundations of COOS -> please go to: https://github.com/linked-statistics/COOS/issues/25

[zoltanvereczkei]

Ownership:

The owner of the core ontology is the High-Level Group for the Modernisation of Official Statistics (HLG-MOS). The Supporting Standards Group is responsible for the maintenance and support of the standard.

Versioning:

Core ontology using semantic versioning according to https://semver.org/. Based on this, the following convention is used for the different versions of the ontology. The versioning number is changed depending on the impact of changes made:

• MAJOR version: Incremented when incompatible API changes are made.
• MINOR version: Incremented when new functionality is added in a backward compatible manner.
• PATCH version: Incremented when backward compatible bug fixes are made.

Main parts of a semantic version number: X.Y.Z (X = MAJOR, Y = MINOR, Z = PATCH)

Example: base version is 1.0.0. A bug fix to an internal implementation is a patch, resulting in 1.0.1. Suppose a new argument with default value is added to a public method, and the default value is consistent with the base version. This is a minor update, resulting in 1.1.0. If the new argument has no default value, this is an incompatible API change, resulting in 2.0.0. [Source of example: https://devopedia.org/semantic-versioning]

In case of the release of a new version, the following rules also apply:

• previous versions are still available to the community, clearly indicating that they are previous versions
• upon release of a new version, an informative ReadMe needs to be written highlighting the most important changes to the previous version

Revisions:

Revisions take place under two scenarios:

• when the standards involved in core ontology are revised. In case of these revisions, the core ontology needs to be checked if revision is needed and if so, the revision work should start.

• when the community requires that the core ontology should be reviewed because of new/changed user needs, independent of the revision cycle of the involved standards.

In both cases, the revision process should start in the form of a Task Team activity, approved by the Supporting Standards Group, ultimately by the Executive Board.

The output of a revision process is a new version where the version naming convention applies.

---

OLD CONTENT:

Operating environment and basic characteristics:

• The main driver of COOS is to translate existing models and connect them in an easy and understandable way to provide a simple but comprehensive overview.
• COOS has important connections to other models, both ModernStats external. COOS is explicitly linked to the ModernStats models of GSBPM, GSIM, GAMSO, CSDA but is also linked to general vocabularies, data models and existing ontologies, such as DCAT, PROV, SKOS.
• COOS is basically the means of realising the benefits of integrating different models by providing a practical implementation.
• There are several models available for information management for official statistics with their own design and decision principles. The COOS is aimed at reusing these principles and linking them as much as possible. This connection with other models also means that the core ontology deducts its own principles from the existing models.
• COOS will guide the review of the connected models involved in the ontology: it will show the discrepancies, contradictions in the models, identify the focus points for the review of each model and ideally will also show potential solutions. This has a positive effect on the ontology itself as it will speed up future revisions of COOS.

Core ontology as a standard:

• Owner: the owner of the core ontology is the High-Level Group for the Modernisation of Official Statistics (HLG-MOS).
• Versioning: core ontology has its own version naming convention. New version of COOS are indicated, the actual version is the one that is directly and easily accessible to users but previous versions are also accessible.
• Revision of COOS: the revision of the COOS is harmonised with the revision of the ModernStats models. If a linked ModernStats model is revised, the need for revision of COOS is always assessed. There is a targeted revision in every 5 years.

[FlavioRizzolo]

For versioning, I propose to follow semantic versioning, as described here:

https://semver.org/

Given a version number MAJOR.MINOR.PATCH, increment the:

• MAJOR version when you make incompatible API changes,
• MINOR version when you add functionality in a backwards compatible manner, and
• PATCH version when you make backwards compatible bug fixes.-
  Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.

This is the approach followed by SDMX 3.0, among others. This level of fine-grained versioning (at the class and individual levels) can be handy given that all the models integrated by COOS have their own lifecycles.

[zoltanvereczkei]

Thanks Flavio! I also checked this after our SSG meeting last week. I like this approach. If the group supports this, we will incorporate this into the COOS governance.

[zoltanvereczkei]

Many elements of the original post incorporated into Part 2: Principles of COOS. ---> Link: #37

[ChLaaboudi]

Dear @zoltanvereczkei
Is it foreseen to include a section about Change Management Policy?
Eg. How to submit change request, timelines for submitting/processing changes
See: https://joinup.ec.europa.eu/collection/semantic-interoperability-community-semic/solution/dcat-application-profile-data-portals-europe/document/change-and-release-management-policy-dcat-ap
Best regards,
Christine

[zoltanvereczkei]

Discussions continue using the Google Docs version of the governance document. Available here:

#25

Please check the latest posts there for the link to the Google Docs.