77 
 
I.e., it might be the case that we never get the data to satisfy every integrity constraint which would mean 
the reasoner is never of any use except to tell us that the ontology is not consistent.  
Thus, SHACL provides a way to define data integrity constraints that overlap to some degree with what 
can be defined in OWL and SWRL. For example, both can define the number of values allowed for a 
specific property. E.g., that each instance of Employee must have one and only one social security 
number (ssn). If this were defined as a DL axiom, then the axiom would never fire for employees that 
had no ssn because of the OWA. On the other hand, if an Employee accidentally had 2 ssn values then 
the entire ontology would be inconsistent until one value was removed. SHACL on the other hand can 
handle both these examples and rather than making the entire ontology inconsistent it simply logs 
warnings at various levels of severity.  
11.3 Basic SHACL Concepts 
To understand SHACL recall that the language underlying OWL is RDF which describes graphs as triples 
of the form: Subject Predicate Object. SHACL also works at the level of RDF because some developers 
may want to simply use that lower level for reasons of efficiency. Thus, RDF can validate an RDF graph 
as well as an OWL ontology. Fundamentally, SHACL consists of two components: 
1. An RDF vocabulary for defining data constraints on RDF graphs (which includes OWL since an 
OWL ontology is an RDF graph). 
2. A reasoner for applying the constraints defined in 1 to a specified data graph such as the Pizza 
ontology.  
One of the most important classes in 1 is a SHACL Shape. An instance of the SHACL Shape class 
consists of a set of Targets and Constraints. A Target defines which nodes in the RDF graph that the data 
constraints apply to. For OWL ontologies this is typically the name of a class which indicates that the 
constraints apply to all instances of that class. The Constraints define the specific property for the 
constraint as well as the actual constraints such as the minimum or maximum number of values and the 
datatype.  In the following example, a Target is the Employee class in the Pizza ontology. An example 
constraint is that the ssn property must have exactly one value. Another example constraint is that the 
format of the ssn value must be a string of the form: “NNN-NN-NNNN” where each N must be an 
integer. For more on SHACL see the references in the bibliography.  
11.4 The Protégé SHACL Plug-In 
To start go to Windows>Tabs and see if you have SHACL Editor as an option. If you don’t then go to 
File>Check for plugins and select the SHACL4Protege Constraint Validator. You need to restart Protégé 
to see the new plugin so save your work and then quit and start Protégé and load the Pizza ontology with 
data.  
Because editing SHACL is a bit more complex for this version of the tutorial we are only going to view 
some already written SHACL constraints and see how the validator processes them rather than writing 
additional constraints. First download the PizzaShapes.txt file to your local hard drive. This file can be 
found at:  https://tinyurl.com/pizzatshapes    Once you have downloaded the file open the SHACL Editor: 
Window>Tabs>SHACL Editor.  
You will see an example shapes file in the editor when it opens but that isn’t the shapes file you are 
looking for. From the editor click on the Open button at the top of the tab and navigate to the 
PizzaShapes.txt file you downloaded.