Pizza.owl TutorialIf you have already read the preface or browsed the book’s outline, you have encountered the acronym EKA – Executable Knowledge Architecture.
You have seen it in:
https://xiaoqi.comBut until now, we have not paused to defined EKA formally.
This chapter changes that.
By the end of this chapter, you will not only understand what EKA is - you will be able to:
Pizza.owl tutorial within the larger EKA maturity roadmapIf you are a practitioner, architect, or researcher, this chapter gives you the conceptual vocabulary to design, evaluate, and communicate EKA-based systems.
Let us begin.
Modern enterprises invest heavily in:
Yet a common compliant remains:
“We have ontologies and graphs, but our knowledge does not act.”
Models are validated.
Graphs are queried.
But knowledge is not executed as part of automated, trustworthy, and adaptive business processes.
This gap is not accidental. Most semantic projects stop at on eof three stages below:
| Stopping Point | What is Missing? |
|---|---|
| Ontology only | Execution engine, dynamic query, rules as actions |
| Graph only | Formal semantics, logical consistency, inheritance |
| Rules only | Domain structure, classification, semantic governance |
EKA (Executable Knowledge Architecture) is a framework designed to close the gap.
EKA does not replace ontologies, knowledge graphs, or reasoners.
Instead, it orchestrates them into a single, layered architecture where knowledge is not only represented but also executed.
EKA (Executable Knowledge Architecture) is an architectural framework in which formal knowledge (ontologies, rules, constraints) is transformed into machine-executable intelligence through a structured pipeline:
Diagrams $\rightarrow$ Meta-models $\rightarrow$ Ontologies $\rightarrow$ Knowledge Graphs $\rightarrow$ Executable Intelligence.
Let us now provide a more precise, formal definition that can be used in research, tooling, and enterprise governance.
An EKA system is a tuple:
$\large{EKA = (K, R, \Theta, \Phi, \Gamma)}$
Where:
An EKA system is defined as executable if and only if (iff) for every trigger $\theta \in \Theta$ that evaluates to true, at least one action $\phi \in \Phi$ is automatically invoked with guaranteed traceability.
In plain language: EKA is not a static ontology. It is a semantic automation architecture.
The EKA roadmap appears throughout this book’s diagrams. Let us now explain each layer in operational terms.
| Layers | Artifact | Tool example | Question it answers |
|---|---|---|---|
| 1. Diagramming | Informal conceptual sketches | Draw.io, Visio, whiteboard | What are the key concerns? |
| 2. Meta-modeling | Formal structural rules | ArchiMate, UML class diagrams, custom DSL | How are concepts legally related? |
| 3. Ontology | OWL ontology with classes, properties, restrictions, disjointness | Protégé | What is the formal meaning? |
| 4. Knowledge Graph | Populated graph with individuals and inferred relationships | Neo4j, GraphDB, Stardog | What specific facts are true? |
| 5. Executable Intelligence | Event-driven actions, queries, and decisions | What should the system do now? |
[!Important] Many projects claim to have an “EKA” because they have a knowledge graph.
According to the formal definition, without a trigger $\Theta$ and execution $\Phi$, you do not have EKA - you have a semantic repository.
A common misconception is that OWL reasoning alone makes knowledge executable.
Let us clarity.
| Capability | OWL Reasoner | EKA Execution layer |
|---|---|---|
| Infers new class membership | $\color{green}{\checkmark}$ Yes | $\color{green}{\checkmark}$ Can use reasoner |
| Detects inconsistency | $\color{green}{\checkmark}$ Yes | $\color{green}{\checkmark}$ Yes |
| Triggers an external API | $\color{red}{\times}$ No | $\color{green}{\checkmark}$ Yes |
| Sends an alert to a business system | $\color{red}{\times}$ No | $\color{green}{\checkmark}$ Yes |
| Modifies a graph or database | $\color{red}{\times}$ No (read-only inference) | $\color{green}{\checkmark}$ Yes |
| Operates over time (event-based) | $\color{red}{\times}$ No | $\color{green}{\checkmark}$ Yes |
OWL reasoning answers: What else is true? (Note: the reasoner does not directly write inferred triples back into the original OWL file or persistent triple store, unless run Drools and write to OWL manually in Protégé.)
EKA execution answers: What should be done now, automatically, based on what is true?
In an EKA system, the reasoner is a component - not the whole engine.
The execution layer $\Phi$ is what makes knowledge operational.
To avoid confusion, it is helpful to position EKA relative to well-known frameworks.
| Framework | Primary focus | Relationship to EKA |
|---|---|---|
| TOGAF (Architecture Development Method) | Enterprise architecture process | EKA can be used as a semantic automation pillar within all TOGAF’s ADM layers. |
| Semantic Web Stack (OWL, RDF, SPARQL) | Knowledge representation and query | EKA extends the stack with an explicit execution layer. |
| Knowledge Graph (Neo4j, GraphDB) | Graph storage and traversal | The $K$ layer of EKA. |
| Rule engines (Drools, DMN) | Business rule execution | EKA generalizes rules into semantic triggers + actions |
| Data Fabric / Data Mesh | Data integration and decentralization | EKA adds ekecutable semantics on top of integrated data. |
EAK is not a replacement for any of these frameworks.
It is an architectural pattern that assembles them into a coherent, executable knowledge pipeline.
Not every ontology project needs full EKA.
We define four maturity levels to help you decide.
| Level | Name | Characteristics | When to use |
|---|---|---|---|
| L0 | Semantic modeling | Protégé + OWL only, no graph, no execution | Learning, academic exploration |
| L1 | Knowledge graph | Ontology + populated graph, queryable (SPARQL/Cypher) | Enterprise knowledge repository |
| L2 | Reactive knowledge | L1 + trigger ($\Theta$) and notifications | Monitoring, compliance, alerting |
| L3 | Executable intelligence (full EKA) | L2 + autonomous actions ($\Phi$) + Governance ($\Gamma$) | Autonomous AI, closed-loop architecture, digital twins |
This book:
You are not expected to build a full L3 system after readdin gthe Pizza.owl tutorial.
But you will understand how each layer contributes to executability.
Pizza.owl TutorialYou may now ask: Why does the Pizza.owl tutorial appear in an EKA book?, or “Why we link to EKA in this Pizza.owl video reference book?”
The answer to both of them is strategic.
The Pizza.owl tutorial teaches:
But the original tutorial does not cover:
Therefore, this book uses Pizza.owl as the common, repeatable, beginning-friendly domain to teach EKA concepts layer by layer.
By the end of this book, you will have built:
Pizza.owl ontoloty (L0)What you learn from pizza scales to:
The domain changes. The EKA architecture does not.
As a reader of this book, you are encouraged to apply the EKA definition to your own projects.
Here is a simple EKA readiness checklist for any semantic project:
If you answer “no” to Triggers or Actions, your systems is a knowledge graph – valuable, but not yet EKA.
The goal is not always full EKA.
The goal is to choose the right level for your problem.
In this chapter (00), we formally defined the Executable Knowledge Achitecture (EKA) that appears throughout this book.
You learned:
Pizza.owl tutorial is the vehicle - not the destination - for learning EKAFrom this point forward, whenever you see the EKA Connection section at the end of a chapter, you will recognize it as a specific layer, component, or maturity level being strengthened.
The next chapter (01) resumes the ontology journey – but now you see the full architectural horizon.
Last updated at 2026/06/13