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 addgetXXX(URI, VersionIdentifier)
method to retrieve a single version - for every
getXXX(URI)
method addgetXXXVersions(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.