protege_pizza

Chapter 02 – Building Your First Ontology in Protégé

After establishing the conceptual foundations of ontology engineering in Chapter 01, we now move into the practical world of ontology construction inside Protégé. This chapter marks the transition from semantic theory into hands-on ontology modeling.

The goal of this chapter is not merely to “click through a tool,” but to understand how semantic structures are engineered systematically. In traditional software engineering, developers write executable code. In ontology engineering, architects build executable meaning.

This distinction is fundamental.

The Pizza ontology may appear simple on the surface, but it introduces modeling patterns used throughout enterprise semantic systems, knowledge graphs, and AI-driven architectures.

This chapter is primarily based on the ontology construction sections from Michael DeBellis’ revised Pizza Tutorial for Protégé 5.5.

2.1 From Theory to Construction

In Chapter 01, we introduced the core OWL concepts:

An quick AI-generated picture below brings them together systematically:

core-owl-concept

Now we begin building actual semantic structures.

This is where ontology engineering stars to feel very different from traditional modeling disciplines.

In a traditional diagramming tool, creating a class hierarchy is often just a visual activity. In Protégé, however, every modeling action contributes to a machine-processable semantic structure.

This means that:

As Michael DeBellis emphasizes throughout the tutorial, ontology engineering should be approached as semantic knowledge modeling rather than merely graphical editing.

2.2 Understanding the Protégé Workspace

When Protégé is launched for the first time, many new users feel overwhelmed by the interface.

This is normal.

Protégé is not designed as a lighweight diagramming application. On the contrary, it is a semantic engineering environment.

The workspace contains multiple perspectives for editing different ontology components:

One of the most important concepts for beginners to understand is that Protégé does not separate “diagramming” from “logic”.

Everything visible in the interface ultimately contributes to OWL axioms underneath.

This is why ontology engineering feels closer to knowledge programming than traditional modeling.

2.3 Creating a New OWL Ontology

The first practical step is creating a new ontology project.

During this chapter’s writing, I’m using Protégé v5.6.9.

Inside Protégé: File > New...:

ch02_01_file-new

If you’re having existing ontology file opened in Protégé, you will get below pop-up with question:

ch02_02_file-new-popup

If you choose Yes (default), your current ontology file will be closed and your new ontology project will occupy current window, ensure you save any previous changes beofre losing them.

Or, you may choose No so a new window will be opened for your new ontology project, your existing opened ontology will not be impacted.

You then can see the new ontology project screen:

ch02_03_new-project-screen

When you want to save the project, Protégé then asks for:

At this stage, beginners often underestimate the importance of ontology IRIs - Internationalized Resource Identifier.

As defined by W3C, “Each ontology may have an ontology IRI, which is used to identify an ontology.” An ontology IRI acts as the global semantic identifier for the ontology.

Unlike filenames or database table names, ontology IRIs are intended to be globally unique identifiers in semantic ecosystems.

For example:

# IRI for pizza.owl
http://xiaoqi.com/ontologies/pizza.owl

# My new ontology project IRI (local)
http://www.semanticweb.org/xiaoqi/ontologies/2026/4/untitled-ontology-121

Using WebVOWL - the OWL Visualization Tool, you can paste above pizza.owl IRI then visualize it for now:

ch02_04_webvowl-pizza

This is conceptually similar to namespaces in programming languages, but with web-scale semantic inter-operability.

In enterprise environments, ontology naming strategies become critically important because ontologies may later integrate across:

This is one of the first points where ontology engineering begins to intersect with enterprise architecture governance.

2.4 The Importance of Ontology Naming Conventions

One of the subtle but important lessons from the Pizza tutorial is disciplined naming.

Ontology projects quickly become unmanageable if naming conventions are inconsistent.

Michael DeBellis repeatly exphasizes semantic clarity and hierarchy organization throughout the tutorial.

Good ontology naming should satisfy several critiria, as below:

For example in our pizza.owl:

Pizza
PizzaTopping
VegetarianPizza
SpicyPizza

These names are concise and semantically clear.

In enterprise ontology projects, naming conventions become even more important because ontologies may evolve into shared organizational semantic standards.

Within EKA, naming discipline is essential because ontology entities later become:

Poor naming eventually creates semantic debt and chaos across the organization.

This is analogous to technical debt in software engineering.

2.5 Understanding Thing: The Root of All Classes

Every OWL ontology begins with a universal root class: owl:Thing

Thing

All classes ultimately inherit from Thing.

This concept initially appears trivial, but it represents an important philosophical principle in ontology engineering.

OWL assumes that all modeled entities exist within a universal semantic space.

For example:

Thing
 |-- Pizza
 |-- PizzaTopping
 |-- PizzaBase
 |-- Spiciness

Unlike relational databases where tables are independent structures, OWL organizes concepts into a globally connected semantic universe.

This is one reason ontology systems integrate natually with knowledge graphs.

2.6 Creating the Core Pizza Taxonomy

The next step involves building the foundational class hierarchy.

From Wikipedia, Taxonomy is a practice and science connerned with classification or categorization.

The Pizza ontology begins with several top-level conceptual categories:

Pizza
PizzaTopping
PizzaBase
Spiciness

These represent the primary semantic domains within the ontology.

At this stage, ontology engineering resembels taxonomy construction.

However, ontologies extend far beyond simple taxonomies.

An ontology additionally defines:

This distinction is critical.

Many enterprise “ontologies” are actually only taxonomies because they lack formal semantics.

2.7 Building Class Hierachies Systmatically

One of the most powerful productivity features demostrated in the Pizza tutorial is the “Create Class Hierarchy” wizard.

In Protégé, from menu [Tools] > [Create class hierarchy…]

ch02_06_Class-Hierar

Instead of manually creating classes one by one, Protégé allow ontology engineers to rapidly construct semantic hierarchies using indentation-based structure.

For example:

PizzaTopping
  CheeseTopping
  MeatTopping
  SeafoodTopping
  VegetableTopping

Tip: you may create those structure in one TXT file upfront, then paste into the wizard.

This approach provides several advantages:

In enterprise-scale ontology projects containing thousands of concepts, hierarchical discipline becomes essential.

Without strong hierarchy goverannce:

Ontology engineering therefore requires architectural thinking, not merely modeling skills.

2.8 Disjoint Classes: Preventing Semantic Contradictions

An extremely important concept introduced during hierarchy creation is class disjointness.

For example:

MeatTopping
VegetableTopping
Seafoodtopping

These categories should logically be mutually exclusive.

A topping cannot simultaneously be both:

Protégé allows classes to be declared as disjoint.

This enables reasoners to detect controdictions automatically.

For example, if an individual were incorrectly classified as both:

HamTopping
AND
VegetableTopping

Since HamTopping is one type of MeatTopping, the reasoner would identify an inconsistency.

This capability becomes enormously important in enterprise environments.

The Disjointness supports:

Within EKA, this is one of the first places where architecture becomes executable.

The ontology no longer merely describes the domain, it actively validates semantic correctness.

2.9 Primitive vs Defined Classes

One of the most intellectually important concepts in OWL modeling is the distinction between:

2.9.1 Primitive Class

A primitive class only specifies necessary conditions.

For example:

Pizza

may simply be declared as a subclass of:

Food

without fully defining what constitutes a pizza.

2.9.2 Defined Class

A defined class, however, specifies both:

You may find similar terms in Sets Theory, correct, they’re inherited from that theory indeed.

For example:

VegetarianPizza
  ≡ Pizza
  AND NOT (hasTopping some MeatTopping)

This means the reasoner can automatically infer membership.

If a pizza satisfies the logical conditions, it becomes classified automatically.

This is one of the defining characteristics of semantic systems.

Traditional systems rely heavily on manual categorization, while, ontology systems support computational classification.

2.10 Why Automated Classification Matters

This concept may initially seem academic, but it becomes transformative at enterprise scale.

Consider a large organization containing:

Manually classifying all semantic relationships become impossible.

Ontology reasoning introduces automation into semantic governance.

Within EKA, automated classification enables:

flowchart LR
    A[Enterprise Architecture] --> B[Ontology Semantics]
    B --> C[Reasoning]
    C --> D[Knowledge Graph Intelligence]

This is one of the major strategic advantages of semantic architecture over static repositories.

2.11 Ontology Engineering vs Diagramming

A common beginner’s mistake is treating Protégé like Visio or UML modeling software.

This is fundamentally incorrect.

In diagramming tools:

While in ontology engineering:

This difference is profound.

Ontology engineering sits much closer to software engineering and knowledge programming than to traditional architecture diagramming.

Protégé therefore represents a semantic compiler environment rather than merely a drawing tool. (In fact, you don’t have actual “drawing” activities in Protégé.)

This distinction becomes central within EKA because the ultimate goal is not documentation.

The goal is executable knowledge.

2.12 Early Modeling Discipline

One of the most valuable lessons from the Pizza tutorial is modeling discipline.

Good ontology engineering requires:

New ontolgoy engineers often attempt to model everything immediately.

Experienced ontology architects instead:

  1. establish clean top-level structures,
  2. define semantic boundaries,
  3. create reusable patterns,
  4. and evolve the ontology incrementally.

This mirrors good enterprise architecture practices.

Ontology engineering is therefore both:

2.13 The Emerging Semantic Architecture Mindset

At this stage in the learning journey, you should begin recongnizing a major conceptual transition.

Traditional enterprise systems are largely:

Data-centric

Ontology systems are

Meaning-centric

This shift has enormous implications for AI systems.

Modern intelligent systems increasingly require:

Ontology engineering provides the formal semantic layer necessary for this evolution.

This is why ontology, knowledge graphs, and semantic AI are rapidly converging across modern enterprise architecture.

Chapter 02 Summary

In this chapter, we began constructing the foundational structure of the Pizza ontology inside Protégé.

We have explored together:

More importantly, we examined how ontology engineering fundamentablly differs from traditional diagramming approaches.

Protégé was introduced not simply as a modeling tool, but as a semantic engineering environment capable of creating executable knowledge structures.

The chapter also reinforced the EKA perspective that ontology serves as the semantic transformation layer between enterprise architecture and executable intelligence systems.

Kew OWL Concepts

Concept Description
owl:Thing The universal superclass from which all OWL classes inherit.
Taxonomy A hierarchical classification structure organizing concepts into parent-child relationships.
Ontology A semantic model that includes taxonomy, properties, restrictions, semantics, and reasoning logic.
Disjoint Classes Classes declared mutually exclusive to prevent semantic contradictions.
Primitive Classes Classes containing necessary conditions only.
Defined Classes Classes containing both necessary and sufficient conditions, enabling automated classification.

Protégé Operations (Skill) Learned

During this chapter, you learned how to:

EKA Connection

Wihtin EKA, this chapter represents the transition from static architecture modeling toward executable semantic structure.

Traditional enterprise repositories often contain disconnected diagrams.

Ontology introduces:

The class hierarchies created in this chapter are not merely documentation artifacts.

They are the foundational semantic structures that later evolve into:

Knowledge Graph Perspective

Knowledge graphs require semantically meaningful entities and relationships.

The ontology structures created in this chapter provide the semantic backbone necessary for graph intelligence.

For example:

Pizza
  ↓ hasTopping
CheeseTopping

can later become graph nodes (entities) and graph endgs (relationships) enriched within formal semantics.

Ontology therefore as the semantic schema layer for knowledge graphs.

Without ontology:

Next Chapter (03) Preview

In the next chapter, we will install Protégé and become familiar with the ontology engineering workspace used throughout the Pizza OWL tutorial series.

Readers will learn how to:

This step establishes the operational foundation for all future ontology modeling activities in the book.

Protégé is not simply a modeling application.

It is the primary semantic engineering environment where ontology structures are transformed into machine-readable knowledge models. Within the EKA framework, this represents the beginning of hands-on ontology engineering practice and the transition from conceptual understanding into executable semantic modeling.

Reference

Demo Video for this Chapter

YouTube Demo Video - Chapter 02: https://youtu.be/eWx9_zJkiUY

Last updated: 2026/05/15

This site is open source. Improve this page.