64 
 
The Data properties tab also shows some new properties: 
• The hasDiscount data property has a domain of Customer and a range of xsd:decimal. This 
records the discount (if any) that the Customer will get on their next purchase.  
• The numberOfPizzasPurchased data property has a domain of Customer and a range of 
xsd:integer. It records the number of Pizzas that each customer has purchased.  
• The ssn property has a domain of Employee and a range of xsd:string. It maps from an 
Employee to their social security number. In the United States this is a number that all employers 
must have in order to process things such as insurance contributions and tax information.  
• The hasPhone data property has a domain of Person and a range of xsd:string.  
Most of these data properties have additional constraints in addition to their ranges. For example, a 
discount can only be between 0 and 1 and a phone number and social security number must correspond to 
a certain format.  
Many of these constraints could be expressed via DL axioms that define the range. However, for reasons 
that will be discussed below, it is often better to represent data integrity constraints using the SHACL 
language rather than as DL axioms. The general rule of thumb is that DL axioms are for reasoning and 
SHACL is for data integrity constraints. Of course, this begs the question what is the difference between 
reasoning and integrity constraints and the distinction is by nature a fuzzy one. However, there are 
guidelines that we will discuss in the section on SHACL which we hope will help shed some light on the 
difference. 
Finally, viewing the Individuals by class tab will help to understand the additional data in the ontology. If 
you go to that tab, you will see many new individuals. In addition to Employees and Customers there 
are instances of the Pizza class. You can see all these individuals in the Individuals by type (inferred) 
view in the upper right corner.  
Now with more instances you can see the value of the Individuals by type (inferred) view. You can 
expand and contract various classes and see the instances for them10.   Notice that the 4 
HighCaloriePizzas are also instances of Pizza but they aren’t shown under Pizza because all 
instances of HighCaloriePizza are always instances of the Pizza class. There is only one instance of 
the Pizza class displayed because all the other instances of Pizza are also instances of subclasses of 
Pizza so they are shown under those subclasses rather than under Pizza. If there are two or more 
classes that an Individual is an instance of that aren’t subclasses of each other then they will all be shown. 
For example, MargheritaPizza1 is an instance of both MargheritaPizza and LowCaloriePizza 
and it shows up under each class because neither is a subclass of the other. It is possible for a Pizza to be 
a LowCaloriePizza and not be a MargheritaPizza and vice-versa.  
 
 
 
 
10 Note that if you have an instance of a class selected in the Individuals by type (inferred) view, you won’t be able 
to collapse that class. E.g., in figure 8.2 we wouldn’t be able to collapse the Employee class because one of its 
instances (Chef) is selected. To collapse it just select a different instance that isn’t an instance of the class you 
want to collapse.