Intensional and Extensional in OWL

By Semantic Universe Admin on September 17, 2009 12:23 PM

In an earlier post I was making the case for being more intentional about the difference between intensionally and extensionally defined sets. Let’s get a bit more specific.

In OWL if you create a class (and say nothing further about its definition), you have a concept that will only ever result in extensional sets. That is the only way for an instance to become a member of this class, and therefore the set of things of that type, is if someone asserts membership in the class.
For instance, in the famous pizza ontology (http://www.co-ode.org/ontologies/pizza/2007/02/12/pizza.owl) and the excellent tutorial that accompanies it (http://www.co-ode.org/resources/tutorials/) there are concepts, such as DeepPanBase, ThinAndCrispyBase and most of the Toppings, that have no formal definition. Something will be an instance of DeepPanBase if someone asserts that it is. The set of all DeepPanBases is an extensionally defined set. This isn’t a critique; every ontology has to have some extensional sets. We can’t build everything out of each other; there is some ground beneath our feet.

But it’s very easy for designers of traditional (relational and object oriented) systems to lapse into designs where all sets are extensional (because in traditional they are all extensional). And a great deal of the power in a semantic system comes from its ability to make inferences, and in particular to infer members into an intensional set.

In the pizza ontology tutorial they distinguish between “primitive” classes (named classes that have only necessary conditions) and “defined” classes that have necessary and sufficient classes. But this is not quite the same distinction between intensional and extensional.

For instance, if we make a necessary and sufficient (equivalent) condition that contains an allValues restriction (and nothing else) we will never infer any members into that class. It really makes it an extensional set. For instance, the VegetarianPizzaEquivalent1 class in the tutorial defines a vegetarian pizza as a Pizza and hasTopping allValuesFrom VegetarianTopping. This is a reasonable definition, and it can even help with TBox reasoning, but it’s not an intensional set. Because of the open world assumption, we cannot infer any pizza to be a vegetarianPizza this way, we can only assert them. (There are some tricks to closing the open world, but they are subtle edge cases relative to what we’re talking about here.)

If you work through this you come to these conclusions:

A class/set is intensional if it has:

· Any subclasses (this is the sort of trivial intensional set, if A is a superclass of B, then if you can infer or assert membership in B then you infer membership in A), or

· Is Equivalent to a union or an intersection, or

· Has sufficient existential restrictions (that is a someValues restriction either in the equivalentClass or a subclass) or

· Sufficient min cardinality restrictions

It’s extensional if

· There are no sub classes, and

· There are any sufficient Universal restrictions, or

· There are any sufficient Maximum cardinality, or

· There are any Complements.

I realize as I write this I didn’t express this very rigorously, but I wanted to get the thought out there because as more people start adopting semantic technologies they might be dismayed when things don’t work they way they expect, and this is a big part of it.

If you work through this thought process, on the Pizza ontology or any other ontology you look at, you’ll see the ontology differently. In the pizza ontology the only classes that are intensional, beyond the simple asserted superclasses, are the meatyPizza, the cheesyPizza, the interestingPizza, the spicyPizza and the RealItalianPizza. All the rest, including all the named pizzas, and the vegetarian and nonVegetarian pizzas, are extensional sets.

This is not meant as a criticism; the pizza ontology is correct and useful, but I think many students don’t follow this subtlety and as a result design ontologies that aren’t working the way they expect.

If, as you design your ontology, you give some thought to which classes you will require your users to assert membership into and which classes the reasoner will infer membership, you’ll go a long way toward building ontologies that are useful.