Copyright © 2004 DERI®, All Rights Reserved. DERI liability, trademark, document use, and software licensing rules apply.
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.
Currently, we plan to fulfill the requirements for version representation, identification and metadata.
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 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;
}
}
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.
getXXX(URI) method add
getXXX(URI, VersionIdentifier) method to retrieve a single
versiongetXXX(URI) method add
getXXXVersions(URI) to get a List of
VersionInformationboolean isCommitted() set to true when current status is in sync
with the persistent latest version; set to false by any update in the
structureVersionIdentifier commit(Map/NonFunctionalProperties versionInfo)
creating new version (in case isCommitted() == false) out of the current
status, returning the IDdrop() dropping all updates and getting back to the last state
when isCommitted() was truetodo
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.
We have identified two viable options on how to represent ontologies with versions in ORDI:
todo
The work is funded by the European Commission under the projects DIP, Knowledge Web, Ontoweb, SEKT, SWWS, Esperonto and h-TechSight; by Science Foundation Ireland under the DERI-Lion project; and by the Vienna city government under the CoOperate programme.
The authors would like to thank to all the members of the OMWG working group for their advices and inputs to this document.
$Date: 2004/10/04 18:24:35 $