The collaborative development of web ontologies is an important topic being actively researched. In this paper, we present a set of tools that facilitate collaborative development of web ontologies using distributed version control systems. The main purpose of these tools is to replace inefficient built-in diff and three-way merge tools, which rely on text representation rather than on ontology structure. Being based on popular distributed version control systems, owl2vcs can be easily integrated into popular issue trackers.
Ontology is a formal description of a specific domain in a standardized language readable by both humans and computers. Like software, ontologies need to be maintained after development. Managing changes between ontologies is an essential part of ontology engineering. There are many reasons for ontologies to be changed. Firstly, the domain may change. Secondly, the understanding of the domain by ontology engineers may change. Thirdly, there may be errors to fix and new ways of representing the domain in an ontology language. Development and maintenance of large ontologies are performed by groups of specialists. Nowadays collaborative development of software is inconceivable without using revision control and issue tracking systems. Using the same approach for ontology development is very promising but has some pitfalls. All tools designed for software code development are text-oriented. For example, diff and three-way merge tools are useless for ontologies stored in one of XML formats.
The OWL 2 language has two semantics: 1) RDF-based semantics where resources
and relations between them are the main concepts, and complex constructs are
represented using so called “blank nodes”, and 2) direct semantics where entities and
axioms are the main concepts. There are works related to comparison of RDF graphs but
they either do not mention the blank nodes problem, or the algorithms are too
complex and non-deterministic [
The development of owl2vcs was inspired by SVoNt [
There are also some tools for comparing ontologies using OWL direct semantics:
1. OWLPatch [
Let us denote a set of all OWL 2 ontologies as OU, and introduce the notation for
ontology components:
EU – set of all possible OWL 2 entities (classes, data types, individuals and
properties);
AU – set of all possible OWL 2 axioms (logical statements about entities);
NU – set of all possible ontology annotations – pairs of the form (np, nv), where np is
an annotation property and nv is its value;
IU – set of all possible imports (links to other ontologies);
PU ⊂ S × S – functional binary relation defined on the set of strings S representing
the set of all possible prefixes – pairs (pn, pi), where pi – prefix value – is a part of
1 The notion of structural difference is borrowed from [
IRI, and pn – prefix name – is a short string used to shorten names of entities and can be used instead of pn; D – set of all possible pairs (ro, rv) called ontology identifiers, where ro is an ontology IRI, and rv is a version IRI; F = { «RDF/XML», «Turtle», «OWL/XML», «OWL Functional Syntax», «OWL
Manchester Syntax» } – set of possible ontology formats.
An ontology is a tuple E, A, N, I, P, d, f, where E ⊂ EU – finite unordered set of entities; A ⊂ AU – finite unordered set of axioms; N ⊂ NU – finite unordered set of ontology annotations; I ⊂ IU – finite unordered set of imports; P ⊂ PU – finite unordered set of prefixes; d ∈ D – ontology identifies; f ∈ F – ontology format.
An ontology can only contain those entities, which are referred by at least one axiom. Consequently, removing an entity from an ontology implies removing all axioms referred to that entity; adding an entity implies adding at least one axiom referring to that entity; changing an entity implies adding an axiom which refers to that entity and is not the first one, or removing an axiom which refers to that entity and is not the last one.
Let us denote changes in each component: CU = CAU ∪ CNU ∪ CIU ∪ CPU ∪ CdU ∪ CfU – set of all possible changes; CAU = СAU+ ∪ СAU– – set of all possible axiom changes; СAU+ = { AddAxiom(a) | a ∈ AU } – set of all possible axiom additions; СAU– = { RemoveAxiom(a) | a ∈ AU } – set of all possible axiom removals; CNU = СNU+ ∪ СNU– – set of all possible ontology annotation changes; СNU+ = { AddOntologyAnnotation(n) | n ∈ NU } – set of all possible ontology annotation additions; СNU– = { RemoveOntologyAnnotation(n) | n ∈ NU } – set of all possible ontology annotation removals; CIU = СIU+ ∪ СIU– – set of all possible import changes; СIU+ = { AddImport(i) | i ∈ IU } – set of all possible import additions; СIU– = { RemoveImport(i) | i ∈ IU } – set of all possible import removals; CPU = CPU+ ∪ CPU– ∪ CPU* ∪ CPU# – set of all possible prefix changes; CPU+ = { AddPrefix(pn, pi) | (pn, pi) ∈ PU } – set of all possible prefix additions; CPU– = { RemovePrefix(pn, pi) | (pn, pi) ∈ PU } – set of all possible prefix removals; CPU* = { ModifyPrefix(pn, pi, pi′) | (pn, pi) , (pn, pi′) ∈ PU ∧ pi ≠ pi′} – set of all possible prefix modifications; CPU# = { RenamePrefix(pn, pi, pn′) | (pn, pi), (pn′, pi) ∈ PU ∧ pn ≠ pn′} – set of all possible prefix renames; CdU = { SetOntologyID(d, d′) | d, d′ ∈ D ∧ d ≠ d′ } – set of all possible ontology identifier changes; CfU = { SetOntologyFormat(f, f′) | f, f′ ∈ F ∧ f ≠ f′ }– set of all possible ontology format changes. 3.1
Let v1 = E1, A1, N1, I1, P1, d1, f1 ∈ OU be the first version of an ontology and v2 = E2, A2, N2, I2, P2, d2, f2 ∈ OU – the second one; δ : OU × OU (CU) is a function that returns the change set С between two versions; ε : OU × (CU) OU is a function which applies the change set С to the ontology. The problem of comparing two versions v1 and v2 is to find such a change set C = δ(v1, v2) that ε(v1, C) = v2. Let’s denote the functions which compare constituents of ontologies: δA : (AU) × (AU) (CAU) – the axiom comparison function; δN : (NU) × (NU) (CNU) – the ontology annotation comparison function; δI : (IU) × (IU) (CIU) – the import comparison function; δP : (PU) × (PU) (CPU) – the prefix comparison function; δd : D × D ≤1(CdU) – the ontology identifier comparison function; δf : F × F ≤1(CfU) – the ontology format comparison function.
The change set between v1 and v2 is a union of changes in separate constituents:
C = δ(v1, v2) = = δA(A1, A2) ∪ δN(N1, N2) ∪ δI(I1, I2) ∪ δP(P1, P2) ∪ δd(d1, d2) ∪ δf(f1, f2) = = CA ∪ CN ∪ CI ∪ CP ∪ Cd ∪ Cf Axiom changes can be found by comparing two sets A1 and A2:
CA = δA(A1, A2) = = { AddAxiom(a) | a ∈ A2 \ A1 } ∪ { RemoveAxiom(a) | a ∈ A1 \ A2 }.
That is, added axioms are axioms which present in A2 but absent in A1, and removed axioms are those which present in A1 but absent in A2.
Ontology annotation changes can be found in a similar way:
CN = δN(N1, N2) = = { AddOntologyAnnotation(n) | n ∈ N2 \ N1 } ∪ ∪ { RemoveOntologyAnnotation(n) | n ∈ N1 \ N2 }.
Import changes are obtained similarly:
CI = δI(I1, I2) = { AddImport(i) | i ∈ I2 \ I1 } ∪ { RemoveImport(i) | i ∈ I1 \ I2 }.
Prefix changes CP fall into four categories: additions, removals, modifications and renames:
CP = δP(P1, P2) = = { AddPrefix(pn2, pi2) | (pn2,pi2) ∈ P2 ∧ ∄(pn1, pi1) ∈ P1: (pn1=pn2 ∨ pi1=pi2) } ∪ ∪ { RemovePrefix(pn1, pi1) | (pn1,pi1) ∈ P1 ∧ ∄(pn2, pi2) ∈ P2: (pn1=pn2 ∨ pi1=pi2) } ∪ ∪ { ModifyPrefix(pn1,pi1,pi2) | (pn1,pi1) ∈ P1 ∧ ∃(pn2, pi2) ∈ P2: (pn1=pn2 ∧ pi1≠pi2) } ∪ ∪ { RenamePrefix(pn1,pi1,pn2) | (pn1, pi1) ∈ P1 ∧ ∃(pn2, pi2) ∈ P2: ((pn2, pi2) ∉ P1) ∧ pn1≠pn2 ∧ pi1=pi2 }.
Thus prefixes in P2 but not in P1 are considered added; prefixes in P1 but not in P2 are considered removed; prefixes with different values but the same name are considered modified; and prefixes with different names but the same values are considered renamed.
The δd function returns the set of at most one element which describes the change of the ontology identifier:
Cd = δd(d1, d2) = { SetOntologyID(d1, d2) | d1 ≠ d2 }.
The δf function returns the set of at most one element which describes the change of the ontology format:
Cf = δf(f1, f2) = { SetOntologyFormat(f1, f2) | f1 ≠ f2 }. 3.2
Let the first version of an ontology v1 contain a set of entities E1, and the second version v2 contain another set of entities E2. The problem of change analysis is to do the following: 5. Find the set of entities E′ ⊂ E1 ∪ E2 affected by changes; 6. Split the set E′ into three subsets: E+ – new entities; E– – removed entities; E* – modified entities (which present in both versions); 7. For each new, removed, or modified entity, find a set of corresponding changes. Let’s define the signature σ(a) of axiom a as a finite unordered set of entities which are referred by axiom a. The signature of a set of axioms can be found as a union of separate axiom signatures:
σ({a1, a2, …, an}) = σ(a1) ∪ σ (a2) ∪ … ∪ σ(an).
The signature of a change is equal to the signature of the corresponding axiom: σ(AddAxiom(a)) = σ(a), σ(RemoveAxiom(a)) = σ(a).
The signature of a change set can be found as a union of single change signatures: σ({с1, с2, …, сn}) = σ(с1) ∪ σ (c2) ∪ … ∪ σ(сn).
The set of entities affected by changes CA can be found as a signature of CA: E′ = σ(CA). It is shown in Figure 1 as a dashed rectangle. It follows from the figure that removed entities E– = E′ \ E2 = E1 \ E2, added entities E+ = E′ \ E1 = E2 \ E1, and modified entities E* = E′ ∩ E1 ∩ E2. The figure also shows unaffected entities E|| = E1 ∩ E2 \ E′.
E|| E–
E2
E+
E′
Fig. 1. Relationship between E1, E2, E+, E–, E*, E|| and E′ For each modified, removed or added entity e we can find all related changes as follows:
σ–1(e) = { c | c ∈ CA ∧ e ∈ σ(с) }. 3.3 Let
Three-way Merge of Ontologies v0 = E0, A0, N0, I0, P0, d0, f0 ∈ OU be the initial version of an ontology; v1 = E1, A1, N1, I1, P1, d1, f1 ∈ OU – the version changed by the first user; v2 = E2, A2, N2, I2, P2, d2, f2 ∈ OU – the version changed by the second user; C1 = δ(v0, v1) = C1A ∪ C1N ∪ C1I ∪ C1P ∪ C1d ∪ C1f – finite unordered set of changes made to v0 by the first user; C2 = δ(v0, v2) = C2A ∪ C2N ∪ C2I ∪ C2P ∪ C2d ∪ C2f – finite unordered set of changes made to v0 by the second user.
The changes made by both users C1 ∪ C2 can be split into following subsets: Matching changes Cm = C1∩C2; Conflicting changes by the first user: C′1; Non-conflicting changes by the first user: C||1 = (C1 \ Cm) \ C′1; Conflicting changes by the second user: C′2; Non-conflicting changes by the second user: C||2 = (C1 \ Cm) \ C′2.
The problem of three-way merging of ontologies v0, v1 and v2 is to get the v3 ontology based on v0 and containing changes Cm, C||1, C||2 and some changes from C′1 ∪ C′2 which don’t lead to a conflict.
In this paper, we assume that import changes and ontology annotation changes cannot lead to a conflict. The conflicting changes therefore include conflicting changes of axioms, prefixes, ontology identifiers and ontology formats:
C′1 = C′1A ∪ C′1P ∪ C′1d ∪ C′1f; The architecture of the collaborative distributed ontology development system is shown in Figure 2.
Browser e d i
t n e i l C
Fig. 2. Implementation architecture
e d i S r e v r e S When an ontology developer creates the initial version of an ontology using an ontology editor, he puts it to the local repository of the version control system, and then he publishes (pushes) it to the remote repository. After publishing any developer can get (pull) this version to his local repository and work on it using any ontology editor. During this work, he can compare his version to the initial one using the local diff tool. After changing an ontology, the developer commits his changes to his local repository and then pushed them back to the remote repository in order to make them available for other developers. It is worth noting that it is possible to commit changes (that is create new versions of ontologies) even without network access, for example during a trip or network troubles. Information about each new version is also available through the issue tracker, which can be accessed with a web browser. Remote services perform comparing of adjacent versions and create an index of all entities, which occur in ontologies using the algorithms described above. This index is used to display change log of a specific entity on a special page in the issue tracker where it is easy to see when, by whom and in what ontology the entity was introduced, modified or abolished.
In case when two developers try to push their changes to the remote repository after working on the same ontology, the second developer has to perform the three-way merge operation using the local merge tool in order to ensure the integrity of the ontology. If changes of both developers do not affect the same entities, or if their changes on the same entity are the same, the merge operation is done automatically. From the other hand, if there are conflicting changes, the second developer has to resolve conflicts using the graphical user interface of the local merge tool and an ontology editor (in complex cases). 5
The diff and merge tools are implemented in Java using OWL API2 and are available for download at GitHub3. Git or Mercurial can be used as a version control system. Any ontology editor with capability of editing RDF/XML, OWL/XML, OWL Functional Syntax, Manchester OWL Syntax or Turtle can be used with the tools. 5.1
The main purpose of the tool is finding changes δ(v1,v2) between two versions v1 and
v2. It can also perform a shallow analysis of changes in order to find which entities
were added, modified, or removed. It takes into account ontology format changes and
import changes. It takes two OWL 2 files as an input and produces a change set in
form of text, which is close to OWL Functional Syntax. Here is the EBNF grammar
of the change set:
2 http://owlapi.sourceforge.net/
3 https://github.com/utapyngo/owl2vcs
changeset
iri ::= fullIRI | abbreviatedIRI
literal ::= quotedString ( '^^' iri | languageTag )?
The prefixName, fullIRI, abbreviatedIRI, quotedString, languageTag, annotation and
axiom elements are described in OWL 2 Structural Specification [
Sometimes it may be useful to see the short representation of the changes (when there are many of them) – just entities affected by the changes. Here is the short representation of the changes shown above produced by owl2diff with the “-e” option: +++ NamedIndividual: pizza:Russia *** Class: owl:Thing *** NamedIndividual: pizza:France *** NamedIndividual: pizza:England *** NamedIndividual: pizza:Italy *** NamedIndividual: pizza:Germany *** Class: pizza:Country *** NamedIndividual: pizza:America In order to create change logs for each entity, a detailed representation of changes is required. Invoked with the “-c -e” options, the tool outputs all related changes for each entity: +++ NamedIndividual: pizza:Russia + Declaration(NamedIndividual(pizza:Russia)) + DifferentIndividuals(pizza:America pizza:England pizza:France pizza:Germany pizza:Italy pizza:Russia ) + ClassAssertion(owl:Thing pizza:Russia) + ClassAssertion(pizza:Country pizza:Russia) *** Class: owl:Thing + ClassAssertion(owl:Thing pizza:Russia) *** NamedIndividual: pizza:France - DifferentIndividuals(pizza:America pizza:England pizza:France pizza:Germany pizza:Italy ) + DifferentIndividuals(pizza:America pizza:England pizza:France pizza:Germany pizza:Italy pizza:Russia ) … *** Class: pizza:Country + ClassAssertion(pizza:Country pizza:Russia) *** NamedIndividual: pizza:America - DifferentIndividuals(pizza:America pizza:England pizza:France pizza:Germany pizza:Italy ) + DifferentIndividuals(pizza:America pizza:England pizza:France pizza:Germany pizza:Italy pizza:Russia ) 5.2
The main purpose of this tool is helping the user to resolve conflicts and perform the three-way merge of ontologies. The tool takes three ontology versions as an input (v0, v1, v2) and outputs the resulting ontology v3, which contains changes made by both users. It uses the same grammar as the diff tool to represent the changes. The graphical user interface of the three-way merge tool is shown in Figure 3. The user interface contains four tabs, which display common (matching) changes, conflicting changes, other changes and resulting changes. By default, all common and nonconflicting changes are selected, and conflicts are to be resolved by the user. If there are no conflicts, changes can be applied automatically without interfering with the user. With owl2vcs, we have local diff and merge tools for web ontologies. It allows us to use any software for editing ontologies (including text editors). If developers are used to a specific ontology editor, they do not have to learn another one. This approach does not restrict ontology language expressiveness. Being based on OWL API, the tools support all OWL constructs including SWRL rules. The solution takes into account peculiarities of ontology storing and allows tracking changes of ontology format. The proposed algorithms are simple and easy to maintain.
However, it would be nice to see the difference between ontologies in the issue tracker using just a web browser. One of the most extensible issue trackers is Redmine4. Our next goal is to develop a plugin for Redmine to allow comparing ontologies and analyzing changes at the server side using the algorithms described in this paper.