In this paper we argue for a broader view of ontology patterns and therefore present different use-cases where drawbacks of the current declarative pattern languages can be seen. We also discuss usecases where a declarative pattern approach can replace procedural-coded ontology patterns. With previous work on an ontology pattern language in mind we argue for a general pattern language.
Though ontology engineers are supported by a wide range of authoring tools the
task of designing ontologies is still difficult even for experts. Several studies on
analyzing common errors in formalizing knowledge may serve as a prime example
(e. g. [
In this paper, we would like to broaden the term ontology pattern by looking
at different ontology engineering approaches. Some of them rely on
procedural knowledge. We argue that lifting them to a declarative level would enable
a (semi-)automatic handling of patterns with the aim to support the ontology
engineer during the entire ontology’s life-cycle. The instantiation of an ontology
pattern, e. g., a logical pattern, also depends on conditions that must be fulfilled.
Violating these conditions at a later stage typically results in an incorrect
instantiation. For that we argue that monitoring pattern instantiations is crucial.
In our opinion, there is also a duality between finding pattern instances and
instantiating patterns. For instance, finding axioms that correspond to a logical
ontology pattern without having explicitly applied that pattern could be useful
during (distributed) ontology engineering for better understanding or finding
undesired modeling issues. Only little work has been spent in guiding the
ontology engineer in finding patterns and monitoring correct instantiation of them.
Recently some work has been done with respect to collaborative and distributed
ontology engineering [
The reminder of this paper is organized as follows: first we discuss use-cases of the application of ontology patterns where some are hidden in procedural knowledge. Then we present a proposal for the obtained requirements and we will briefly discuss the integration in our language in an ontology authoring tool. 2
We will try to broaden the term ontology pattern by looking at different ontology
engineering support methods to extract commonalities that should be fulfilled by
a universal ontology pattern language in order to encode patterns in a declarative
way. These use-cases are mainly driven by our experience in ontology authoring
and therefore not intended to be exhaustive. As a starting point we take into
account a recently proposed pattern language [
Ontology Design Patterns Repositories such as ontologydesignpatterns.
org provide access to pattern catalogues. Instead of encoding patterns in a
declarative way they are described by their intent, examples and diagrams.
Recently, the authors of MPL propose to describe patterns in a declarative way
to support a more automatic handling of patterns. In the following we observe
two shortcomings of their approach. Consider a very simple partition pattern:
a partition is a structure that is divided into several disjoint parts. Using the
Abstract Syntax of OWL 2 [
The first axiom can be expressed in MPL using createUnion(?x.VALUES) to bind an arbitrary number of classes to a given variable ?x. However, MPL does not allow to express a set of classes as needed in the second axiom 1. Moreover, OPPL/MPL allow variables of named entities only. This limits the usage of the language because some situations (as shown before) cannot be expressed.
To sum up a general pattern language has to deal also with an arbitrary
number of classes in conjunction with all axioms in OWL which allow a set of
classes (unions, intersections as in MPL but also disjointness, equivalences etc.).
All types of OWL objects should be used as variable parts. Otherwise, the very
simple partition example would only contain named classes.
1 We refer here to the MPL grammar available at http://www.cs.man.ac.uk/
?iannonel/oppl/grammar.html, last accessed on 20th of July, 2009, and [
ObjectComplementOf(ObjectSomeValuesFrom(property ObjectOneOf(i2)))) whereas the former one has been recently introduced in OWL 2. Obviously, in both cases, the first statement is more intuitive and convenient and even experts seem to encounter problems in understanding the latter one. It is, of course, an extreme case but it illustrates the problem of understanding the meaning when users look at ontologies created by others. It is not a rocket science to transfer these axioms into each other by writing some code. However, this is not an adequate solution: the transformation is hidden in procedural knowledge. Another simple re-factoring example is the replacement of cyclic subclass axioms with an equivalent-class axiom. SubClassOf(C0 C1),..., SubClassOf(Cn C0) is equivalent to EquivalentClasses(C0,...,Cn). This is, for instance, implemented in a procedural manner in Prot´eg´e. This example shows that a pattern language needs also to support variability on axiom level: Here, the number of subclass axioms is unknown during pattern design-time.
Ontology Lint Tools In Software Engineering lint tools perform static analysis
of source code in order to detect suspicious scopes of code wrt. language usage,
condition violations, violation of type ranges etc. that might lead to unexpected
behavior on run-time. Transferring this idea to ontologies, ontology lint tools
give hints about potential modeling defects, i. e., they scan for “anti-patterns”
that should be avoided. In our opinion, these anti-patterns do not differ from
ontology patterns and therefore they should also be expressed in a declarative
way – re-usable independent of any programming language. For instance, Pellint
[
Inspired by the mentioned use-cases and the shortcomings of MPL we now
present building blocks of a pattern language which fulfills the discussed
requirements. We do not claim that those requirements are the only ones but they
are a good starting point. For the rest of this paper we refer to OWL 2, OWL
for short, and its Abstract Syntax for presentation purpose. Allowing arbitrary
class expressions as possible bindings for variables results in loosing decidability
because models of OWL ontologies, in general, are infinite. Therefore, we use the
finite set of class (property) expressions as introduced in [
Definition 1 (Variables). Class expressions with variables are defined analogously to OWL class expressions but allowing variables at positions of class expressions. The range of a variable can either be a named class, class expression, or any subtype of it as produced by the corresponding rule in OWL. Properties, individuals, and constants are defined analogously. A variable is either a single variable ?x that can be bound to a single expression (according to its range), or a multi-variable ??X which consists of a set of single variables where each of them is referable via an index. By default, different index values denote different single variables within the set.
Multi-variables allow to define an arbitrary number of expressions without loosing reference to the single variable if needed. Let ??X be a multi-variable whose range are classes. Then ObjectIntersectionOf(??X) defines an intersection of an arbitrary number of classes. In contrast to the MPL statement createIntersection(?x.VALUES), each ?X(i) is referable in other condition which have an impact on the variable binding. For instance, one could state that ?X(i) and ?X(j) are used in SubClassOf axioms: SubClassOf(?X(i) A) and SubClassOf(B ?X(j)) to define further constraints. By default, ?X(i) and ?X(j) have different bindings if there is no constraint specifying that both should be equal. Definition 2 (Variablized Axioms). Given an OWL ontology, axioms are defined analogously to OWL axioms according to the axiom rules, but also allow variables at position of class (resp. property) expressions (resp. indivduals). Axioms with variables are called variablized axioms. The semantic of using multivariables in axioms is the following: for each bounded ?X(i) a new re-incarnation of the axiom is produced.
Given an ontology containing the following axioms SubClassOf(A B), SubClassOf(A C), SubClassOf(A D), SubClassOf(C B), SubClassOf(B A). Let ?X be a class variable occurring in the axiom SubClassOf(?X B). Then ?X can be bound to either A or C and we get the bounded axioms SubClassOf(A B) or SubClassOf(C B). Let ??X be a multi-variable (range bounded to classes). Given the axiom SubClassOf(??X B), ??X would be bound to the set {A, B} and we get the axioms SubClassOf(A B) and SubClassOf(C B). Definition 3 (Constraints). Every OWL axiom and variablized axiom according to the Definition 2 is a constraint. Let ?x and ?y be variables, and ??Z a multi-variable. Then the following statements are also constraints: ?x != ?y, ?x = ?y (in- resp. equivalence of variable bindings), MinCount(??Z) = n, MaxCount(??Z) = n, resp. ExactlyCount(??Z) = n (specifying a minimum, maximum or exact number of bounded variables ?Z(0),..., ?Z(n) in ??Z). Definition 4 (Abstract OWL Pattern).
IRI iri <ACTION>
is an abstract pattern where iri is a unique identifier, ACT ION is an action’s placeholder, variables is a comma-separated set of variables containing all variables that are used in the pattern, and constraints is a comma-separated set of (conjunctively connected) constraints according to Definition 3. Axioms mentioned in the WHERE statement are either interpreted as explicit or implicit axioms. type denotes the type of the pattern (as explained in the following), documentation is a human-readable documentation of the pattern, and message is a message that can be displayed in tools.
Following the type categorization of patterns given in [
where axioms is a set of axioms according to the Definition 2 are defined. For instance, ODPs typically only use the ADD statement whereas re-factoring patterns also provide a remove section, and lint patterns might inform the user only (they do not provide any action).
Ontology patterns are often based on either entities or axioms defined in other patterns: combining patterns or re-using patterns is a key building block of pattern creation. We therefore introduce the following statement group
where iris is a set of comma-separated pattern identifiers (IRIs) and constraints is a set of comma-separated constraints referring to variables in the patterns identified by their IRI and variables of the surrounded pattern. To distinguished structural equivalent variables from different patterns it is always required that these variables are prefixed with the IRI. All axioms and variables contained in the patterns mentioned in iris are always part of the surrounding patterns. This allows, for instance, to combine two patterns and establish equivalence between variables with help of the AS statement.
In the following some very short examples of using our additional language constructs are given. An ontology lint pattern that finds redundant transitive property axioms because of the transitivity of the super-property can be formulated as follows:
A cyclic class definition can easily be defined by using variablized class expressions as follows:
REMOVE SubClassOf (??X ??Y) - ?X(i) = ?Y(i+1), ?X(0) = ?Y(n)
WHERE EXPLICIT SubClassOf(??X ??Y) - ?X(i) = ?Y(i+1), ?X(0) = ?Y(n)
An ontology lint patterns discovering at least 5 super-classes (borrowed from Pellint’s lint collection) can be expressed as follows:
We have integrated the proposed language constructs in a pattern language as
a supplement to the OWL API [
Since ontology lint are handled in the same way as ODPs the same mechanism is used to monitor the ontology in order to find lints as a background task. As shown in the upper part of Figure 4, a redundant transitive axiom for a property that is a sub-property of a transitive property has been found. In this paper we presented some shortcomings of ontology pattern languages such as the OPPL-based ontology language and motivated to broaden the term ontology pattern by looking at ontology analysis methods which encode ontology patterns in program structures. A declarative pattern approach could benefit from automatic detection of pattern instantiations, monitoring of patterns violations as well as interoperability of patterns. To overcome the presented limitations we briefly introduced the building blocks of a universal pattern language and gave an overview of the implementation and integration in an ontology authoring environment. Future work will be concerned with further analysis of ontology patterns related areas such as ontology lints as well as ontology extractions to include language constructs to better support these patterns in order to get to our aim to build a universal pattern language.