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/