Patterns documentation

About patterns

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

Margherita Pizza 2 toppings: Tomato, Mozzarella
Sloppy Giuseppe Pizza 5 Toppings: Tomato, Mozarella, Onion, Green pepper, and Hot spiced beef

The difference among sub-classes of NamedPizza is their toppings. Nevertheless, an instance of NamedPizza 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

template pattern example

This web-site collects all the tools and the documentation for encoding patterns using OPPL 2.

 

OPPL patterns have been developed as part of the CO-ODE project, by Luigi Iannone at The University of Manchester with the contribution of

 

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:

The Patterns View

This view lets you add/remove/edit pattern definitions from an ontology. Pattern definitions are special ontology annotations. Their URI must be http://www.co-ode.org/patterns#.

 

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
Food
?x:CLASS, ?y:CLASS,
?forbiddenContent:CLASS=createUnion(?x.VALUES)
BEGIN
ADD $thisClass equivalentTo contains only
(not ?forbiddenContent)
END;
A ?x free stuff;
RETURN $thisClass
Menu free of ?x pattern Any class specified as not containing something (e.g.: vegetarian food does not contain meat)
Food
?x:CLASS[subClassOf Food]
BEGIN
ADD $thisClass subClassOf Menu,
ADD $thisClass subClassOf contains Course and only ($FreeFromPattern(?x))
END;
A ?x - free Menu
Menu free of ?x pattern Menu sub-class specified as not containing something (e.g.: vegetarian menu does not contain meat)
Patterned Pizza
?base:CLASS,
?topping:CLASS,
?allToppings:CLASS = createUnion(?topping.VALUES)
BEGIN
ADD $thisClass subClassOf Pizza,
ADD $thisClass subClassOf hasTopping some ?topping,
ADD $thisClass subClassOf hasTopping only ?allToppings,
ADD $thisClass subClassOf hasBase some ?base
END;
A pizza with ?base base and ?topping toppings
Named pizza pattern Sub-class of Pizza characterised by its base and toppings
Patterned DOLCE Ultra Light
?informationObject:CLASS,
?informationRealization:CLASS,
?realizationProperty:OBJECTPROPERTY
BEGIN
ADD ?informationRealization subClassOf InformationRealization,
ADD ?informationObject subClassOf InformationObject,
ADD ?realizationProperty subPropertyOf realizes,
ADD ?informationRealization subClassOf PhysicalObject
and ?realizationProperty some ?InformationObject
END;
Information Realization Pattern:
?informationRealization ?realizationProperty ?informationObject
Named pizza pattern 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
?person:CLASS,
?role:CLASS,
?timeInterval:CLASS
BEGIN
ADD $thisClass subClassOf Situation,
ADD $thisClass subClassOf isSettingFor some ?person,
ADD $thisClass subClassOf isSettingFor some ?role,
ADD $thisClass subClassOf isSettingFor some ?timeInterval
END;
Situation where ?person play the role ?role during the time interval ?timeInterval
Named pizza pattern 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.

simple pattern with two variables

A simple pattern with two unassigned variables.

analysis breakdown

The safety analysis details.