=Paper=
{{Paper
|id=Vol-1080/owled2013_2
|storemode=property
|title=Owl2vcs: Tools for Distributed Ontology Development
|pdfUrl=https://ceur-ws.org/Vol-1080/owled2013_2.pdf
|volume=Vol-1080
|dblpUrl=https://dblp.org/rec/conf/owled/ZaikinT13
}}
==Owl2vcs: Tools for Distributed Ontology Development==
https://ceur-ws.org/Vol-1080/owled2013_2.pdf
Owl2vcs: Tools for Distributed Ontology Development
Ivan Zaikin, Anatoly Tuzovsky
Tomsk Polytechnic University, Tomsk, Russia
{i,tuzovskyaf}@tpu.ru
Abstract. The collaborative development of web ontologies is an important
topic being actively researched. In this paper, we present a set of tools that fa-
cilitate 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.
Keywords: OWL 2, ontology, structural difference, three-way merge, change,
change set.
1 Introduction
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 main-
tained after development. Managing changes between ontologies is an essential part
of ontology engineering. There are many reasons for ontologies to be changed. First-
ly, 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 represent-
ing the domain in an ontology language. Development and maintenance of large on-
tologies are performed by groups of specialists. Nowadays collaborative development
of software is inconceivable without using revision control and issue tracking sys-
tems. 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 repre-
sented using so called “blank nodes”, and 2) direct semantics where entities and axi-
oms 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 com-
plex and non-deterministic [1]. It is shown in [2] that in the general case it is impossi-
ble to compare unambiguously two RDF triples containing blank nodes, though there
are computationally complex algorithms of checking whether two RDF graphs are
isomorphic. In this paper, we present algorithms and structural 1 diff and three-way
merge tools for OWL 2 ontologies, which use OWL 2 direct semantics. Applying
direct semantics eliminates problems with blank nodes and allows comparing ontolo-
gies axiom by axiom. They also take into account some attributes, which are not in-
cluded into the logical constituent but still important for ontology development.
2 Related Work
The development of owl2vcs was inspired by SVoNt [3] – an SVN-based ontology
versioning system. However, it is not available for download and looks like to be
abandoned.
There are also some tools for comparing ontologies using OWL direct semantics:
1. OWLPatch [4] is a simple command line tool, which compares two ontologies and
saves the result for future patching of the first ontology.
2. Ecco [5] is a system, which compares two ontologies and analyzes the changes de-
tecting whether removals and additions were logically effectual.
3. OWLDiff [6] is a tool, which compares ontologies axiom by axiom, finds the ef-
fectual changes and analyzes them to find the affected entities.
4. OWL Diff Tool [7] is plug-in for Protégé 4.2, which calculates the structural dif-
ferences between ontologies and focuses on alignment of renamed entities.
The tools mentioned above only compare the logical constituent of ontologies (i.e.
axioms) and do not take into account import changes, prefix changes, and ontology
format changes. However, such changes are important for ontology developers and it
is useful to keep record of them. During the research, we found no tool capable of
three-way merge of OWL ontologies. That is why we have developed our own one.
3 Algorithms
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 proper-
ties);
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 [5] where it is defined through the
notion of structural equivalence used in [8].
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 ontol-
ogy 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 an-
notation 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 pos-
sible 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 Ontology Diff
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 func-
tion 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 ∪ C I ∪ 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 re-
moved 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 consid-
ered 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 Analysis of Changes
Let the first version of an ontology v1 contain a set of entities E1, and the second ver-
sion 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′.
E1
E||
E+
E* E′
E– E2
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 fol-
lows:
σ–1(e) = { c | c ∈ CA ∧ e ∈ σ(с) }.
3.3 Three-way Merge of Ontologies
Let
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 chang-
es 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 chang-
es of axioms, prefixes, ontology identifiers and ontology formats:
C′1 = C′1A ∪ C′1P ∪ C′1d ∪ C′1f;
C′2 = C′2A ∪ C′2P ∪ C′2d ∪ C′2f.
The ontology format change is conflicting if another user has also changed the on-
tology format:
C′1f = { c | c ∈ C1f ∧ c ∉ C2f };
C′2f = { c | c ∈ C2f ∧ c ∉ C1f }.
Similarly, the ontology identifier change is conflicting if another user also changed
the ontology identifier, and the change was not the same:
C′1d = { c | c ∈ C1d ∧ c ∉ C2d };
C′2d = { c | c ∈ C2d ∧ c ∉ C1d }.
Conflicting changes of axioms are non-matching changes made by different users
and affecting same entities:
C′1A = { c ∈ C1 | σ(c) ∩ σ(C2A \ Cm) ≠ Ø };
C′2A = { c ∈ C2 | σ(c) ∩ σ(C1A \ Cm) ≠ Ø }.
Let’s introduce a function σP : 𝒫(CPU) ∪ CPU 𝒫(S) which calculates the signa-
ture of prefix changes which is just a set of all prefix names and prefix values:
σP(AddPrefix(pn, pi)) = { pn, pi };
σP(RemovePrefix(pn, pi)) = { pn, pi };
σP(ModifyPrefix(pn, pi, pi′)) = { pn, pi, pi′};
σP(RenamePrefix(pn, pi, pn′)) = { pn, pi, pn′};
σP({c1, c2, …, cn}) = σP(c1) ∪ σP(c2) ∪ … ∪ σP(cn).
Conflicting prefix changes are non-matching changes made by different users and
having the same prefix name or the same prefix value:
C′1P = { c ∈ C1 | σP(c) ∩ σP(C2P \ Cm) ≠ Ø };
C′2P = { c ∈ C2 | σP(c) ∩ σP(C1P \ Cm) ≠ Ø }.
4 Architecture and Workflow
The architecture of the collaborative distributed ontology development system is
shown in Figure 2.
Issue Tracker
Browser
Server Side
Client Side
Ontology Editors
Local Repository Remote Repository
Local Tools Remote Services
Version Control System
Fig. 2. Implementation architecture
When an ontology developer creates the initial version of an ontology using an ontol-
ogy 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 re-
pository 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 availa-
ble 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 af-
ter 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 on-
tology. If changes of both developers do not affect the same entities, or if their chang-
es 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 Implementation
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 Func-
tional Syntax, Manchester OWL Syntax or Turtle can be used with the tools.
5.1 The Diff Tool: owl2diff
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
::= prefix*
setOntologyFormat? setOntologyId?
prefixChange* importChange*
annotationChange* axiomChange*
prefix ::= prefixName '=' fullIRI
setOntologyFormat
::= '* OntologyFormat' '(' quotedString ')'
setOntologyId
::= '+ ' ontologyIDStatement
| '- ' ontologyIDStatement
| '* ' ontologyIDStatement
ontologyIDStatement
::= 'OntologyID' '(' oid ')'
oid ::= fullIRI fullIRI?
prefixChange
::= '+ Prefix' '(' prefix ')'
| '- Prefix' '(' prefix ')'
| '* Prefix' '(' prefix fullIRI ')'
| '# Prefix' '(' prefixName prefix ')'
importChange
::= '+ ' importsDeclaration
| '- ' importsDeclaration
importDeclaration
::= 'Import' '(' iri ')'
annotationChange
::= '+ ' annotation
| '- ' annotation
axiomChange
::= '+ ' axiom
| '- ' axiom
iri ::= fullIRI | abbreviatedIRI
literal ::= quotedString ( '^^' iri | languageTag )?
The prefixName, fullIRI, abbreviatedIRI, quotedString, languageTag, annotation and
axiom elements are described in OWL 2 Structural Specification [8]. It can be seen
from the grammar that change set consists of prefixes used to abbreviate entities,
ontology format change, ontology identifier change, prefix changes, import changes,
ontology annotation changes, and axiom changes. Each addition of a new axiom, an
ontology annotation, an import or a prefix is denoted by the “+” sign, whereas remov-
al is denoted by the “–” sign. Modification of a prefix, an ontology identifier, or an
ontology format is denoted by the “*” sign. Renaming of a prefix is denoted by the
“#” sign. Here is an example of a change set produced by the owl2diff tool:
owl:=
:=
pizza:=
* OntologyFormat("OWL Functional Syntax")
- Prefix(dc:=)
- DifferentIndividuals(pizza:America pizza:England
pizza:France pizza:Germany pizza:Italy )
+ 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)
The first three lines declare the prefixes used in subsequent changes. The first change
is the change of ontology format to “OWL Functional Syntax”. The following chang-
es are removal of the “dc” prefix, removal of the “DifferentIndividuals” axiom, and
addition of four axioms related to adding the “Russia” country to the ontology.
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 rep-
resentation 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 Three-Way Merge Tool: owl2merge
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 graph-
ical user interface of the three-way merge tool is shown in Figure 3. The user inter-
face contains four tabs, which display common (matching) changes, conflicting
changes, other changes and resulting changes. By default, all common and non-
conflicting 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.
Fig. 3. Conflicting changes tab of the main window of the three-way merge tool
6 Conclusion and Future Work
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 ac-
count peculiarities of ontology storing and allows tracking changes of ontology for-
mat. 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 on-
tologies and analyzing changes at the server side using the algorithms described in
this paper.
References
1. Carroll, J. Matching RDF Graphs. (2001),
http://www.hpl.hp.com/techreports/2001/HPL-2001-293.pdf
2. DiffAndPatch, http://www.w3.org/wiki/DiffAndPatch
3. Luczak-Rösch, M., Coskun, G., Paschke, A., Rothe, M., Tolksdorf, R.: Svont – version con-
trol of OWL ontologies on the concept level. In: Fähnrich, K.P., Franczyk B. (eds.) In-
formatik 2010. Service Science – Neue Perspektiven für die Informatik. Band 2. LNI 176,
Gl 2010, pp. 79–84. Gesellschaft für Informatik, Bonn (2010)
4. Drummond, N.: OWL Patch (2011), http://owl.cs.manchester.ac.uk/patch/
5. Gonçalves, R.S., Parsia, B., Sattler, U.: Ecco: A Hybrid Diff Tool for OWL 2 ontologies. In:
Klinov, P., Horridge, M. (eds.) OWLED 2012: OWL Experienced and Directions
Workshop, Heraklion, Crete, Greece (2012)
6. Kremen, P., Smid, M., Kouba, Z: OWLDiff: A Practical Tool for Comparison and Merge of
OWL Ontologies. In: DEXA 2011, pp. 229-233. IEEE Press (2011)
7. Redmond, T., Noy, N.: Computing the Changes Between Ontologies. In: Novacek, V.,
Huang, Z., Groza, T. (eds.) EvoDyn 2011: Joint Workshop on Knowledge Evolution and
Ontology Dynamics, Bonn, Germany (2011)
8. Motik, B., Patel, P.F., Parsia, B.: OWL 2 Web Ontology Language Structural Specification
and Functional-Style Syntax: World Wide Web Consortium (2009),
http://www.w3.org/TR/owl2-syntax/
4 http://www.redmine.org/