Versioning Tool Design

Published on : 24 April 20183 min reading time

Introduction

This document specifies the public API and the internal design of the versioning component of the Ontology Management System. See Deliverable 4: OMS Architecture for the architectural view of where this component fits. Futher, see Deliverable 6.1: Versioning Requirements for a list of the requirements on this component.

Initially, any interfaces are represented as pseudocode (akin to Java), UML diagrams will replace the pseudocode in the future.

Public API

Currently, we plan to fulfill the requirements for version representation, identification and metadata.

Version Identification

Version identifier is a wrapper for a string value, which may become useful in case we change the structure/type of the value. Initially, the string will contain only a single integer number but as the usual numerical operations are not to be supported with this number (even comparison should only be for equality, not for ordering), it is represented as a string. Any information linking two versions together will be added further in the scope of transformation specification.

interface VersionIdentifier {
   String getID();
}

Version Metadata

Version metadata contains multiple values with specified uses but also a general extensible bag of other values.

interface VersionInformation {
   VersionIdentifier getVersion();
   UserCredentials getUser();
   Date getDate();
   String getComment();
   Map/NonFunctionalProperties getVersionMetadata();
}

Authentication information is initially going to be a simple string with the user name. This will be changed during the efforts of integration with ORDI as the ORDI API should provide its own mechanism for user autentication. Versioning API requires only the user name for the version metadata, whereas ORDI uses user credentials to authorize any persistent changes.

interface UserCredentials {
   String getUserName();
}

class SimpleUserCredentials implements UserCredentials {
   private String username;
   public SimpleUserCredentials(String user) {
      this.username = user;
   }
   public String getUserName() {
      return this.username;
   }
}

Version Representation

To represent versions of ontologies, the versioning component will extend rRDI RepositoryBrowser. Initially, only versioning of Ontologies will be implmeneted, but versioning of other ORDI elements is a natural evolution.

As we expect the users will simply expect to be able to version ontologies, subelements of ontologies (i.e. concepts, relationships, instances etc.) will not have their own version numbers.

  • for every getXXX(URI) method add getXXX(URI, VersionIdentifier) method to retrieve a single version
  • for every getXXX(URI) method add getXXXVersions(URI) to get a List of VersionInformation
  • add boolean isCommitted() set to true when current status is in sync with the persistent latest version; set to false by any update in the structure
  • add VersionIdentifier commit(Map/NonFunctionalProperties versionInfo) creating new version (in case isCommitted() == false) out of the current status, returning the ID
  • add drop() dropping all updates and getting back to the last state when isCommitted() was true

Internal Design

todo

For the internals, we’ll have to implement a facade for all ORDI API and depending on the conversation with Naso, put the version information somewhere.

Representing Versions

We have identified two viable options on how to represent ontologies with versions in ORDI:

  • A single ontology contains all the different versions of the subcomponents, each marked with a set of versions to which it belongs.
  • For every version, the whole ontology is stored with its version number as a separate ORDI ontology.

Plan du site