68 
 
To understand what is going on you first need to understand that each SPARQL query consists of two 
parts. The first part at the beginning consists of several namespace prefixes. These statements consist of 
the prefix used for a particular namespace as well as the IRI associated with this namespace. Recall that 
these concepts were described in chapter 7. You may be wondering where all these prefixes came from 
since you didn’t add them to your ontology. The answer is that every OWL ontology comes with a set of 
namespaces and prefixes that are required to define the ontology.  
Also, to understand SPARQL you need to “peak under the hood” of OWL. So far, we have been 
discussing concepts in purely logical and set theoretic terms, i.e., at the semantic level. However, like any 
language or database there is a lower level that describes how the concepts are mapped to actual data. In a 
relational database the fundamental construct to represent data is a table. In OWL the fundamental 
construct is a triple. OWL is actually built on top of RDFS which is a language built on top of RDF. RDF 
(Resource Description Framework) is a language to describe graphs (in the mathematical sense of the 
term). I.e., to describe nodes and links.  
The foundation for RDF graphs are triples consisting of a subject, predicate, and object. This results in 
what is called an undirected or network graph because objects can be subjects and vice versa. Whenever 
you define a property in OWL you are defining a predicate. An individual can be a subject or an object 
(or both). E.g., in our ontology Customer1 purchasedPizza AmericanaHotPizza1. In this example 
Customer1 is the subject, purchasedPizza is the predicate and AmericanaHotPizza1 is the object.  
However, classes and properties themselves are also represented as triples. So for example, when you 
create the class Pizza what Protégé does for you is to add the triple: Pizza rdf:type owl:Class to 
the ontology. I.e., the Pizza entity is of type (is an instance of) owl:Class. Similarly when you add 
NamedPizza as a subclass of Pizza, Protégé adds the triple: NamedPizza rdfs:subClassOf 
Pizza.  
Hopefully, now you can make some sense of this initial query. The query is looking for all the entities 
that are the subjects of triples where the predicate is rdfs:subClassOf and the object is any other 
entity. The ? before a name indicates that the name is a wildcard that can match anything that fits with the 
rest of the pattern. This is part of the power of SPARQL, one can match a Subject, an Object, a Predicate 
or even all three. Making all 3 parts of the pattern wildcards would return every triple in the graph (in this 
case our entire Pizza ontology) being searched. You may notice that in some cases the object is simply the 
name of a class while in others it is a class expression with an orange circle in front of it. This is because 
when defining classes using DL axioms Protégé creates anonymous classes that correspond to various DL 
axioms.  
The SELECT part of a SPARQL query determines what data to display. The WHERE part of a query 
determines what to match in the query. If you want to display everything matched in the WHERE clause 
you can just use a * for the SELECT clause. The initial default query in this tab is set up with no 
knowledge of the specific ontology. I.e., it will return all the classes that are subclasses of other classes 
regardless of the ontology. To get information about Pizzas the first thing we need to do is to add 
another prefix to the beginning of the query. In our case the Pizza ontology has been set up with a 
mapping to the prefix pizza (you can see this in the ontology prefixes tab in the Active ontology tab 
discussed in chapter 7). So, add the following to the SPARQL query after the last PREFIX statement:  
PREFIX pizza: <http://www.semanticweb.org/pizzatutorial/ontologies/2020/PizzaTutorial#>