Once the conceptual overview, in terms of a somewhat informal class diagram, has been designed in the course of engineering an ontology, the process of adding many of the appropriate logical axioms is mostly a routine task. We provide a Protege3 plugin which supports this task, together with a visual user interface, based on established methods for ontology design pattern modeling.
When modeling with domain experts, particularly when they do not possess
intimate knowledge about ontology engineering, it is in our experience best to
use a visual approach to rst design a conceptual overview of ontology modules
(or corresponding content ontology design patterns), in the form of class
diagrams [
The ontology engineers in the modeling team will of course keep track of the precise meaning of each part of the diagram, so that they can convert their insights into exact speci cations, i.e., axioms for the ontology. This conversion can then, based on the class diagram and the discussions during the modeling sessions, in our experience mostly be done by the ontology engineers without a lot of required further interaction with the domain experts. For documentation (or publication) purposes, the class diagram will usually also be redrawn using appropriate software tools.
In our experience, based on the class diagram and the discussions with domain experts during its design, it is mostly a routine, albeit somewhat tedious, task to write down appropriate axioms for an ontology module in an ontology editing tool. Most axioms in fact arise out of a systematic exploration of the class diagram. In order to simplify this part of the work, we have cast this systematic exploration into a Protege plugin, which we describe herein. Of course, some axioms { arguably the more interesting and more critical ones { will not come up as candidates during our systematic exploration, and so will have to be added manually. Nevertheless, our plugin is helpful in making the task of adding many routine axioms much quicker and less error prone. 3 http://protege.stanford.edu/
More information about the plugin is located at http://daselab.org/content/ ontology-axiomatization-support. 2
The plugin provides an interface for drawing a class diagram, and a command (accessible through an item in the menu or a button in the toolbar) to generate axioms from the given diagram, which are to be added into the currently active ontology. As seen in Fig. 1, the class diagram itself is composed of nodes and edges. A node in the class diagram represents either a class, datatype, individual name, or literal. Meanwhile, an edge represents either an object property, data property, the typing relation (i.e., rdf:type), or the subclass relation (i.e., rdfs:subClassOf). A pallette on the left side of the interface provides the user with those nodes and edges, which can be dragged and dropped onto the canvas.
In the following, X P! Y means that there is a directed edge P from a node
X to another node Y in the class diagram. Also, A and B denote class names, M
a datatype, c a named individual, ` a literal, R an object property, and Q a data
property. The plugin enforces the class diagram to contain at least one node, and
if there is an edge, it only allows the following node-edge-node con gurations:
A !R B, A !R c, A Q! M , A Q! `, c rdf:typ!e A, and A rdfs:subClassO!f B.
We do not aim to represent all possible relationships between components of
the class diagram above because in our experience when modeling, the class
diagram is usually considered informal, and the aforementioned node-edge-node
OWLAx: A Protege Plugin to Support Ontology Axiomatization
con gurations are those typically used to describe a conceptual overview when
we conduct modeling [
From the class diagram, a user can generate several types of candidate axioms based on the relationships depicted in the class diagram. They are only candidates since the class diagram is informal; each candidate axiom captures one way to read a relationship, and the actual intent should typically be inquired to the domain experts while conducting the modeling. Note that from one type relationship, more than one actual intents need to be formalized, i.e., the candidate axioms are not mutually exclusive. On the other hand, the list of candidate axioms is not exhaustive to keep it su ciently simple: there are obviously axioms that will not be directly generated from the class diagram, especially if it is too complex. For such axioms, one has to simply directly input them in Protege.
The plugin facilitates the creation of candidate axioms through a dialog box
(accessible through \Generate Axiom" command from the menu or toolbar)
that contains a checkbox of the candidate axioms presented in the Manchester
syntax. After clicking \Integrate", the plugin will integrate the axioms with a
check-mark to the ontology. We explain some of the candidate axioms below,
though we use mainly description logic notation [
Every c rdf:typ!e A leads to a class assertion A(c), and A rdfs:subClassO!f B to a subclass axiom A v B. Next, for every A !R B, the plugin generates several types of candidate axioms. First, it generates (unscoped) domain restriction 9R:> v A | equivalent to R rdfs:domain A | and scoped domain restriction 9R:B v A. The former would be later integrated if the domain experts involved in modeling agrees that for every pair of instances x; y, if x R y holds, then x belongs to A (regardless whether or not y belongs to B), while the latter is chosen if the domain experts agrees that if x R y holds and y is known to belong to B, then x belongs to A. Such agreements will be solicited from domain experts involved in the modeling for every candidate axiom. Besides domain restrictions, the plugin also generates scoped and unscoped range restrictions A v 8R:B, > v 8R:B | equivalent to R rdfs:range B; several existential axioms, e.g., A v 9R:B, etc.; and several functionality restrictions, e.g., A v ( 1 R:B), etc.
Similar types of candidate axioms are generated for every A Q! M , A !R c, and A Q! ` relationships. Finally, class disjointness axioms are generated as candidate axioms for every pair of di erent classes, unless there is a path of rdfs:subClassOf edges in the diagram connecting one class to the other. 3
The plugin is implemented on top of the OWL API provided by Protege. The visual components are built using mxGraph.4 The plugin allows users to save the diagram as XML-annotated PNG, which can then be loaded again. This plugin 4 http://jgraph.github.io/mxgraph/ is not for visualizing an ontology for which there are a number of Protege plugins already existing, but rather, it facilitates creating graphical class diagrams inside Protege and provides a way to generate axioms from it. It eliminates the need to use separate tools for creating the class diagram and writing down the axioms. In addition, the user can customize various aspects of the class diagram, e.g., coloring, size of nodes and edges, text formatting, etc., through the provided menu or by right-clicking the corresponding graphical components.
One could use this plugin for modeling from scratch, or starting from an already created ontology. In the latter case, the plugin will not attempt create a class diagram from the ontology, and rather, start with an empty canvas. Nevertheless, when the user wishes to generate axioms through the plugin, existing axioms that are already in the ontology will be included as part of the list of candidate axioms, and the user can con rm whether to keep them. Finally, we hope to continue improving this plugin, particularly to support quick modeling of modular ontologies and ontology design patterns, and furthermore, evaluate the usability of our plugin via a comprehensive user study.
Acknowledgements. This work was supported by the National Science Foundation award 1017225 III: Small: TROn { Tractable Reasoning with Ontologies.