Pizza.owlPizza.owlPizza.owl to Knowledge GraphBefore we begin this chapter, it is important to clarify something to you.
This chapter intentionally goes beyond the original scope of Michael DeBellis’ Pizza.owl tutorial.
The Pizza tutorial primarily focuses on helping you understand ontology engineering through practical, hands-on exercises inside Protégé. Its emphasis is natually centered on learning OWL concepts, building classes, using reasoners, and understanding semantic modeling fundamentals.
However, through years of practical work in enterprise architecture, ontology engineering, meta-modeling, graph databases, and knowledge-driven systems, I have repeatly observed a common challenge amonge learners:
Many people learn how to use the tool, but far fewer truly understand what the tool is generating underneath.
This distinction matters!
Previously, while teaching enterprise architecture and meta-modeling, I introduced a similar perspective thorugh analysis of ArchiMate modele structure and exchange formats. Many enterprise architects become proficient at drawing ArchiMate diagrams but never examine the underlying model exchange specification that makes architecture portable, interoperable, and executable across repositories and tools.
Eventually, I realize ontology learning suffers from a similar challenge.
Protégé is simply the editor. (–> mapping to Archi, the ArchiMate Modeling Tool)
The ontology is the language. (–> mapping to ArchiMate, the language)
For this reason, Chapter 08 intentionally introduces a more theoretical perspective. Instead of treating ontology merely as a modeling exercise, we will examine ontology from the viewpoint of RDF language specification, semantic representation, and practical implementation into Knowledge Graphs.
This perspective becomes especially important if your long-term ambition extends beyond Pizza.owl toward:
Because eventually ontology engineers must answer a deeper question:
What exactly is an ontology made of?
The answer begins with:
RDF – Resource Description Framework.
This chapter therefore marks an important transition in the EKA roadmap:
flowchart LR
A[Diagramming]-->B[Meta-Model]-->C[Ontology]:::myStyle
C-->D[Knowledge Graph]:::myStyle-->E[Executable Intelligence]
classDef myStyle fill:#008844
Up until now, we have focused primarily on the Ontology phase.
Beginning here, we start preparing for the next transformation:
flowchart LR
C[Ontology]-->D[Knowledge Graph]
And RDF is the bridge that makes this transition possible.
One of the most important conceptual transition in ontology engineering is recognizing a subtle but fundamental truth:
When you see in Protégé is not the ontology itself.
Rather, what you see is a visual abstration of the ontology.
This idea may initially feel surprising because you spend most of your time interacting with:
Everything feels highly visual and tool-oriented.
However, underneath Protégé exists something far more important.
A standards-based semantic representation language.
Whenever Protégé saves an ontology, it serializes knowledge into formal semantic structures using standards based on RDF and OWL.
In other words:
Protégé is simply an ontology authoring environment.
The real ontology exists independently of the tool.
This mirrors an important lesson from enterprise architecture.
When architects create ArchiMate diagrams, the diagram itself is not the architecture model. The real model becomes portable through a formal exchange structure.
Likewise:
Protégé diagrams are not the ontology.
The RDF/OWL representation is.
This serialization fundamentally changes how ontology engineers think.
You stop thinking:
“I built something in Protégé.”
And being thinking:
“I authored a semantic knowledge specification.”
That is a major maturity leap.
Many beginners explanations describe RDF as:
“A graph data format.”
While technically correct, this explanation is incomplete.
To understand RDF professionally, we should instead view it as:
A formal language specification for representing semantica assertions.
RDF was standardized to solve an important problem:
How can machines understand meaning and relationships?
Traditional systems primarily store data.
RDF stores meaning.
This distinction is profound.
Relational databases organize information through:
But RDF organizes knowledge differently.
Instead of tables, RDF models everything as statements.
Every semantic statement follows the same structure - triple:
Subject –> Predicat –> Object
For example:
VegetarianPizza –> subClassOf –> Pizza
In semantic terms:
Similarly:
CheesePizza –> hasTopping –> CheeseTopping VegetarianPizza –> hasTopping –> VegetableTopping
These are not simply data records.
They are formal semantic assertions.
This distinction becomes extremely important for reasoning.
Reasoners do not interpret diagrams.
Reasoners interpret semantic statements.
And RDF is the language they understand.
Pizza.owlTo understand RDF deeply, you should begin thinking like language designers.
Resource
Everything meaningful in RDF is modeled as a resource.
Examples from Pizza.owl include:
Each concept receives a globally identifiable reference.
This solves ambiguity and enables semantic interoperability.
For enterprise systems, this becomes extremely important because concepts can be reused across repositories, APIs, metadata platforms, and knowledge graphs.
Property
Relationships themselves are also explicitly defined.
Examples include:
Unlike traditional systems where relationships may feel secondary, RDF treats relationships as first-class semantic meaning.
With my sayings in certain EA tooling practices:
Triple
The triple becomes RDF’s atomic unit of knowledge.
Everything eventually becomes:
Subject –> Predicate –> Object
Like sentences in human language.
This elegant simplicity explains why RDF scales effectively for knowledge systems.
Complex ontologies are ultimately collections of semantic statements.
Pizza.owlAt first glance, RDF/XML syntax may appear intimidating.
You may encounter elements such as:
Initially, many learners assume they must understand XML deeply.
In reality, ontology engineers should instead learn to read RDF/XML as semantic meaning.
For example:
<owl:Class rdf:about="#VegetarianPizza">
<rdfs:subClassOf rdf:resource="#Pizza"/>
</owl.Class>
Rather than viewing this as technical systax, translate it semantically:
VegetarianPizza is a subclass of Pizza.
Similarly:
<owl:disjointWith rdf:resource="#NonVegetarianPizza"/>
means:
VegetarianPizza cannot be NonVegetarianPizza.
This perspective is transformative.
You stop reading RDF/XML as code.
You begin reading RDF/XML as machine-readable meaning.
That is precisely how semantic technologies should be understood.
One of the most important realization in ontology engineering is this:
RDF is already a graph.
Every RDF triple naturally forms:
Node –> Relationship –> Node
Example:
VegetarianPizz ↓ subClassOf Pizza
From ontology perspective:
VegetarianPizza is a subclass of Pizza.
From graph perspective:
VegetarianPizza node connected to Pizza node through SUBCLASS_OF relationship.
The transformation is almost direct.
This insight becomes strategically important.
When ontology engineers understand RDF deeply, they begin realizing:
We are already modeling graph structures.
Protégé may appear to be an ontology editor.
But underneath, you are constructing graph-ready semantic structures.
This realization often represents a major maturity leap for practitioners, especially enterprise architects transitioning toward knowledge engineering.
At this point, you may naturally ask:
If ontology already represents semantic knowledge, why do we still need a graph database?
Gool catch! This question deserves a deeper answer.
Ontology and graph databases are related, but they solve different problems.
| Ontology | Graph Databases | |
|---|---|---|
| Focus on | Semantic meaning and formal logic | Operational querying, scalable relationship traversal, and executable intelligence |
| Answer questions such as | <li>What does a concept mean?</li><li>What rules govern relationships?</li><li>What constraints must remain true?</li> | <li>How are concepts connected?</li><li>What paths exist between entities?</li><li>What hidden patterns emerge?</li><li>What knowledge can be operationalized? |
| Provides | Semantic truth | Operational execution |
This distinction is fundamental in EKA.
Many organizations successfully document enterprise knowledge.
Far fewer operationalize it.
The problem is often not lack of modeling.
The problem is lack of execution.
This is exactly why the EKA roadmap exists.
Each layer increases knowledge maturity.
One of the biggest misconceptions in knowledge engineering is assuming ontology and graph databases compete with one another.
In fact, they do not!
They complement one another.
A useful way to understand this relationship is:
Ontology defines meaning.
For example:
VegetarianPizza?Ontology answers:
What should be true?
Meanwhile, graph databases operrationalize these semantics.
For example:
Graph databases answer:
What is happening?
This mirrors enterprise architecture practice.
Meta-models define meaning.
Repositories operationalize knowledge.
This is precisely why ontology and graph databases work naturally together.
Pizza.owl to Knowledge GraphInside EKA, ontology is not the final destination.
It is an intermediate maturity stage.
The real goal is:
Executable Intelligence
A practical implementation path may look like this.
Architects begin with diagrams and conceptual structures.
Knowledge remains visual.
Relationships become formalized.
Meaning becomes structured.
Concepts become formal semantic definitions.
Now we define:
Protégé exports semantic knowledge as:
At this stage, the ontology becomes portable.
This is where many organizations stop.
However, semantic knowledge still remains underutilized.
RDF now becomes operational.
Semantic structures can be imported into graph databases such as Neo4j.
Classes become nodes.
Properties become relationships.
Semantic triples become traversable graph structures.
The ontology becomes queryable.
Once implemented as a graph, organizations can begin asking intelligent questions.
For example:
Suddenly:
Knowledge becomes executable.
This is the vision of EKA.
A natural next question becomes:
Can
Pizza.owlbe imported into Neo4j?
The answer is:
Yes.
And this represents the next maturity phase of EKA.
A practical implementation often follows this approach:
Save ontology as RDF/XML, OWL, or Turtle.
Using semantic plugins and import pipelines, RDF tripes are converted into graph structures.
Example include:
For example:
VegetarianPizza --> SUBCLASS_OF --> Pizza
Pizza --> HAS_TOPPING --> CheeseTopping
The ontology becomes operational rather than merely descriptive.
Organizations can now perform:
Ontology becomes actionable.
This is where ontology engineering becomes truly valuable in enterprise environments.
Many organizations already have:
but lack semantics.
Others have:
but lack execution.
Some have:
but still lack operational intelligence.
The missing bridge is often:
Knowledge Graph realization
And RDF is the enabling layer.
RDF transforms ontology from:
Semantic specification
into:
Executable graph knowledge
The complete EKA maturity path becomes visible:
flowchart LR
A[Diagramming] --> B[Meta-Model] --> C[Ontology]
C --> D[RDF Serialization] --> E[Knowledge Graph]
E --> F[Executable Intelligence]
This is perhaps the most important message of Chapter 08.
Because at this stage, you are no longer merely learning Pizza.owl.
They are learning how to engineer knowledge itself.
In this chapter, we intentionally moved beyond the standard Pizza.owl tutorial to examine ontology from a language specification perspective.
You explored:
For the first time in this book, ontology becomes more than modeling.
It becomes:
Portable, Executable, and Operational Knowledge.
In the next chapter (09), we continue exploring ontology implementation in Protégé by deepening our understanding of OWL structures and semantic modeling practices. Building upon the RDF foundation introduced here, you will continue progressing toward more advanced ontology engineering capabilities.
Demo Video Reference in YouTube: Chapter 08 - (https://youtu.be/qjer-vEKMNg)
Last updated at 5/23/2026