IX. Versioning layer

The versioning layer provides a formal framework to handle the evolution of the ontology model in time, considering the multi-organizational context. Aside from structural change requests, the layer also contains information about forward and backward mappings of the modified structure. With the support of a voting system, relevant change requests and associated mappings are selected, processed and used as input for the new version.

Migrating from one version of an ontology to another requires two pieces of information. Firstly, one must describe the changes that are to be performed by using change requests and secondly, one must associate forwards and backwards mappings needed to transition between the old and new versions. Mappings, as well as change requests, can be encapsulated into a structured data file (such as JSON or XML).

{
  "$type": "versioning",
  "$version": "1.0",
  "$schema": "A01564DBBCB04816A9BFE5FB50723EFD3BBE119E",
  "$id": "7491104BD46D3B2E51B824800F3D66775CCD1600",
  "$author": "Andrei",
  "$description": "Change request for splitting property",
  "change-requests-sets": [
    {
      "atomic": true,
      "change-requests": [
        {
          "space-type": "concept",
          "action": "delete",
          "layer": "structure",
          "target": "DA4B9237BACCCDF19C0760CAB7AEC4A8359010B0",
          "comment": "Property is not required",
          "request": {
            "properties": {
              "lastSeen": "DateTime"
            }
          }
        },
        {
          "space-type": "concept",
          "action": "update",
          "layer": "structure",
          "target": "DA4B9237BACCCDF19C0760CAB7AEC4A8359010B0",
          "comment": "Update date property from date to date time",
          "request": {
            "properties": {
              "lastSeenDate": "Date"
            }
          }
        },
        {
          "space-type": "concept",
          "action": "update",
          "layer": "structure",
          "target": "DA4B9237BACCCDF19C0760CAB7AEC4A8359010B0",
          "comment": "Update date property from date to date time",
          "request": {
            "properties": {
              "lastSeenTime": "Time"
            }
          }
        }
      ],
      "change-mappings": [
        {
          "target": "DA4B9237BACCCDF19C0760CAB7AEC4A8359010B0",
          "lastSeen": {
            "1.0>1.1": "function (source, target ){ target.lastSeenDate = date(source.lastSeen); target.lastSeenTime = time(source.lastSeen); }",
            "1.1>1.0": "function (source, target ){ target.lastSeen = dateTime(source.lastSeenDate, source.lastSeenTime); }"
          }
        }
      ]
    }
  ]
}

From a design perspective, the change request set embeds change mappings and change requests. A change request set has an attribute called atomic that defines how the set is executed.

Mappings are usually added when there are modifications in the structural layer of a concept. The list of change mappings contains the information from the Connection Layer chapter. A change request provides the following essential attributes: space-type, action, layer and target.

Change request

Space type can have the following values: "concept" and "classification" and it is used to discriminate between concept and classification spaces. Using the action field, one can define what kind of action will be applied; the allowed actions are: "create", "update", "delete".

Specifying which ontology layer is affected can be accomplished via the layer field. In the concept space, the versioning layer cannot be the scope of a change request, and in the classification space, only two layers are relevant: structure and naming.

The identifier from the target field specifies what entity is going to be modified in the next version. Additional information regarding why the modification is necessary can be given in the comment field; the voters and approvers use this information to understand the purpose of the changes.

The request field contains the change request payload, which holds the concept’s modifications and is coded in a text field. A possible implementation of the payload is a text that corresponds to the serialized representation of the concept for that particular layer.

For a create action, the payload is the full concept representation for that specific layer. In contrast, for an update or delete action, the full definition is not required but only the parts that will be modified.

Change request mapping

The mapping model contains all the information from the Connection Layer mapping model. However, it has an extra field to target the concept where the mapping should be applied.