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

	2 toppings: Tomato, Mozzarella
	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:

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	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	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 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	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	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	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.