We present ContentCVS, a system that implements a novel approach to facilitate the collaborative development of ontologies. Our approach adapts Concurrent Versioning, a successful paradigm in collaborative software development, to allow several developers to make changes concurrently to an ontology. Conflict detection and resolution are based on novel techniques that take into account the structure and semantics of the ontology versions to be reconciled by using precisely-defined notions of structural and semantic differences between ontologies and by extending existing ontology debugging and repair techniques.
OWL Ontologies are already being used in many application domains. In particular, OWL is extensively used in life sciences; prominent examples of OWL ontologies are the National Cancer Institute (NCI) Thesaurus, SNOMED CT, the Gene Ontology (GO), the Foundational Model of Anatomy (FMA), and GALEN.
Most realistic ontologies, including the ones just mentioned, are being developed collaboratively. Maintaining such large ontologies in a collaborative way is a highly complex process: developers need to regularly merge and reconcile their modifications to ensure that the ontology captures a consistent unified view of the domain. Changes performed by different users may, however, conflict in complex ways and lead to errors. These errors may manifest themselves both as structural (i.e., syntactic) mismatches between developers’ ontological descriptions, and as unintended logical consequences.
Tools supporting collaboration should therefore provide means for: (i) keeping track of ontology versions and changes and reverting, if necessary, to a previously agreed upon version, (ii) comparing potentially conflicting versions and identifying conflicting parts, (iii) identifying errors in the reconciled ontology constructed from conflicting versions, and (iv) suggesting possible ways to repair the identified errors with a minimal impact on the ontology.
In this paper we present ContentCVS3, a system that is available for download as
a Prote´ge´ 4 plugin [
ContentCVS closely follows the Concurrent Versioning paradigm. The change history and the most recent version OR of the ontology, which represents the developers’ shared understanding of the domain, are kept in a server’s shared repository. Each developer with access to the repository can connect to the server to check out a copy of OR, allowing developers to work on their own local copy OL, which they can modify at will. Developers can commit their changes to the server at any time. This allows several developers to make changes concurrently to the shared ontology. To keep the system in a consistent state, the server only accepts changes to the latest version of the shared ontology. Developers should hence use the CVS client to regularly update their local copy with changes made by others.
Manual intervention is only needed when a conflict arises between a committed version in the server and a yet-uncommitted local version. Conflicts are reported whenever the two compared versions of an ontology are not “equivalent” according to a given notion of equivalence, which we describe next. 3
A typical CVS system treats the files in a software project as ordinary text files and hence checking equivalence amounts to determining whether the two compared files are syntactically equal (i.e., they contain exactly the same characters in exactly the same order). This notion of equivalence is, however, too strict in the case of ontologies, since OWL files have very specific structure and semantics. For example, if two OWL files are identical except for the fact that the axioms appear in different order, the corresponding ontologies should be clearly treated as equivalent: an ontology contains a set of axioms and hence the order in which they appear is irrelevant.
An alternative in the case of ontologies is to use the notion of logical equivalence. This notion is, however, too permissive: even if two ontologies are logically equivalent (the strongest assumption from a semantic point of view), conflicts may still exist. This might result from incompatible annotations (statements that act as comments and do not carry logical meaning), mismatches in modelling styles, and so on.
ContentCVS uses the notion of structural equivalence between OWL 2 ontologies
[
Once the user has selected the desired axioms from the structural difference (marked L with a X in Figure 1) a temporary version of the reconciled ontology Otmp is built from the non-conflicting part of OL plus the axioms selected from the structural differL ence. At this point, the user may declare the conflict resolved and commit Otmp to the repository, in which case conflict resolution remains a purely syntactic process. Otherwise, ContentCVS allows the ontology developer to use a reasoner to examine the L semantic consequences of their choices and ensure that Otmp meets their requirements (typically, that it includes as much intended information as possible without leading to inconsistencies or other undesired entailments).
To facilitate error detection, ContentCVS compares the entailments that hold in
OtLmp with those that hold in OL and OR by using the notion of logical difference [
Figure 2(a) shows the GUI in ContentCVS for displaying new entailments, that is, those that hold in Otmp but not in OL. The GUI allows users to indicate which of those
L entailments are unintended and should be “deleted”. ContentCVS provides a similar GUI for displaying lost entailments (those that hold in OL but not in OtLmp) and for selecting which of those should be “recovered”. 5
Changing the set of entailments in an ontology can only be achieved by modifying the
ontology itself (see for example [
L tentCVS implements a number of heuristics for ranking the possible repair plans and provides a GUI (see Figure 2(b)) that indicates whether the axioms in the plan come from OL or OR (marked with “L”, “R” respectively), and whether an axiom is shared by all plans (marked with a “P”). 6
We conducted a pilot user study to evaluate the usability of ContentCVS and to show
the adequacy of our approach in practice (see [
The main points of criticism were, on the one hand, the excessive amount of information displayed when using “large” approximations of the logical difference and, on the other hand, slow response of the tool when performing reasoning-intensive tasks. We consider addressing these deficiencies as a part of our future work.