Although the literature in Ontology Engineering seems to pay a great deal of attention towards patterns meant as re-usable knowledge components, there have been surprisingly few attempts to create a concrete language that supports pattern creation in OWL.
Our notion of a pattern is simply:
[...] namely representations which capture recurring structure within and across OWL ontologies
Adapted from Clark, P.: Knowledge patterns.
In Gangemi, A., Euzenat, J., eds.: EKAW.
Volume 5268 of Lecture Notes in Computer Science., Springer (2008) 1–3
OWL expressivity has its downside in the fact that models are complicated to understand. We observe that although ontology maintainers should in general understand the totality and the intricacies of the model there are some maintenance task where this can be avoided.
Consider, the follwing examples extracted from the Pizza Ontology
|2 toppings: Tomato, Mozzarella|
|5 Toppings: Tomato, Mozarella, Onion, Green pepper, and Hot spiced beef|
The difference among sub-classes of
is their toppings. Nevertheless, an instance of
cannot have toppings that are not in the union of the mentioned one (closure on the toppings). When creating new
NamedPizza sub-classes, then, the ontology engineer should reproduce the structure and adapt it to
the relative toppings. However, the truth is that the only characterising bits for this new sub-class, are its
toppings. What really needs to be done is to fill out the blanks of a template, or rather a pattern.
The information about how to implement the closure with respect to the set of declared toppings should be considered
scaffolding that maintaners interested only in expanding the ontology should not take into account,
because it could be automatically produced using a pattern based mechanism. The ontology engineer should rather
deal with structures like the following
This web-site collects all the tools and the documentation for encoding patterns using OPPL 2.
OPPL 2 Patterns examples
The full grammar for pattern syntax is available here
In order to use the OPPL 2 patterns plug-in, you should download the latest binary release. The copy it in the plugins folder of your Protégé installation.
Then, start Protégé, and select View, Ontology Views and, finally, Patterns. Place the Patterns View wherever it is most convenient for you.
The plug-in main view looks like the picture below:
This view lets you add/remove/edit pattern definitions from an ontology. Pattern definitions are special ontology annotations.
Their URI must be
Please notice that in OPPL 2, as a general rule, if you add type scope constraints to any variable in a script, you must have selected a reasoner beforehand in Protégé 4 Reasoner menu
|Ontology URL||OPPL2 pattern encoding||Editor (Click on the picture to enlarge it)||Pattern Brief Description|
ADD $thisClass equivalentTo contains only
A ?x free stuff;
|Any class specified as not containing something (e.g.: vegetarian food does not contain meat)|
ADD $thisClass subClassOf Menu,
ADD $thisClass subClassOf contains Course and only ($FreeFromPattern(?x))
A ?x - free Menu
|Menu sub-class specified as not containing something (e.g.: vegetarian menu does not contain meat)|
?allToppings:CLASS = createUnion(?topping.VALUES)
ADD $thisClass subClassOf Pizza,
ADD $thisClass subClassOf hasTopping some ?topping,
ADD $thisClass subClassOf hasTopping only ?allToppings,
ADD $thisClass subClassOf hasBase some ?base
A pizza with ?base base and ?topping toppings
|Sub-class of Pizza characterised by its base and toppings|
|Patterned DOLCE Ultra Light||
ADD ?informationRealization subClassOf InformationRealization,
ADD ?informationObject subClassOf InformationObject,
ADD ?realizationProperty subPropertyOf realizes,
ADD ?informationRealization subClassOf PhysicalObject
and ?realizationProperty some ?InformationObject
Information Realization Pattern:
?informationRealization ?realizationProperty ?informationObject
|represents the relations between information objects like poems, songs, formulas, etc., and their physical realizations like printed books, registered tracks, physical files, etc. (as defined here)|
|Patterned DOLCE Ultra Light||
ADD $thisClass subClassOf Situation,
ADD $thisClass subClassOf isSettingFor some ?person,
ADD $thisClass subClassOf isSettingFor some ?role,
ADD $thisClass subClassOf isSettingFor some ?timeInterval
Situation where ?person play the role ?role during the time interval ?timeInterval
|represents time indexing for the relation between persons and roles they play (as defined here)|
OPPL 2 Patterns Locality Evaluation
Locality is a logical property of an OWL axiom (or a set of them) with respect to a signature (i.e., a set of entity names) and an ontology; informally, an OWL axiom is local if, given a specific ontology O and a signature S, adding the axiom to the ontology does not change the interpretation of any of the symbols of the ontology.
When instantiating an OPPL pattern, it can be useful to see whether the pattern is safe with respect to a signature, in order to restrict unwanted side effects; this can be done in the current Pattern instantiation editor.
The safety check does not require all variables to be assigned; for the unassigned variables, all combinations of possible assignments (i.e., variable belonging to the signature or not) are tried; assigned variables are instead known to be included or not included in the signature.
The results of such analysis can be seen in the result analysis breakdown window; the variable combinations are represented as rows in a table, where a check means that a variable is inside the signature; a green light means that the configuration is safe, i.e., each variable can assume any of the values inside the signature (or outside of it, depending on whether the corresponding column is checked or not) without any other symbol changing its interpretation as a side effect; a red light means that interpretation changes cannot be ruled out, although this does not imply that any interpretation change will ensue.
A simple pattern with two unassigned variables.
The safety analysis details.