42 
 
 
 
 
 
 
 
 
 
 
 
 
 
4.13 Automated Classification and Open World Reasoning 
Make sure that the reasoner is synchronized (the little text in the lower right corner should say Reasoner 
active). Now switch from the Class hierarchy tab to the Class hierarchy (inferred) tab. You may notice 
something that seems perplexing. The classes MargheritaPizza and SohoPizza both only have 
vegetable and cheese toppings. So one might expect that the reasoner would classify them as subclasses 
of VegetarianPizza as it recently (in section 4.11) classified them and others as subclasses of 
CheesyPizza. The reason this didn’t happen is something called the Open World Assumption (OWA). 
This is one of the concepts of OWL that can be most confusing for new and even experienced users 
because it is different than the Close World Assumption (CWA) used in most other programming and 
knowledge representation languages.  
In most languages using the CWA we assume that everything that is currently known about the system is 
already in the database. However, OWL was meant to be a language to bring semantics to the Internet so 
the language designers chose the OWA. The open world assumption means that we cannot assume 
something doesn’t exist just because it isn’t currently in the ontology. The Internet is an open system. The 
information could be out there in some data source that hasn’t yet been integrated into our ontology. 
Thus, we can’t conclude some information doesn’t exist unless it is explicitly stated that it does not exist. 
In other words, because something hasn’t been stated to be true, it cannot be assumed to be false — it is 
assumed that the knowledge just hasn’t been added to the knowledge base. In the case of our pizza 
ontology, we have stated that MargheritaPizza has toppings that are kinds of MozzarellaTopping 
and also kinds of TomatoTopping. Because of the open world assumption, until we explicitly say that a 
MargheritaPizza only has these kinds of toppings, it is assumed by the reasoner that a 
MargheritaPizza could have other toppings. To specify explicitly that a MargheritaPizza has 
toppings that are kinds of MozzarellaTopping or kinds of TomatoTopping and only kinds of 
MozzarellaTopping or TomatoTopping, we must add what is known as a closure axiom on the 
hasTopping property. 
In situations like the above example, a common mistake is to use an intersection instead of a 
union. For example, CheeseTopping and VegetableTopping.  Although CheeseTopping 
and Vegetable might be a natural thing to say in English, this logically means something that 
is simultaneously a kind of CheeseTopping and VegetableTopping. This is incorrect 
because we have stated that CheeseTopping and VegetableTopping are disjoint classes 
and hence no individual can be an instance of both. If we used such a definition the reasoner 
would detect the inconsistency. 
In the above example it might have been tempting to create two universal restrictions — one 
for CheeseTopping (∀ hasTopping CheeseTopping) and one for 
VegetableTopping (∀ hasTopping VegetableTopping). However, when multiple 
restrictions are used (for any type of restriction) the total description is taken to be the 
intersection of the individual restrictions. This would have therefore been equivalent to one 
restriction with a filler that is the intersection of MozzarellaTopping and TomatoTopping 
— as explained above this would have been logically incorrect.