Ask a traditional knowledge graph who the president is, and it gives you a name. Ask who the previous president was, and it has nothing — unless someone built in a versioning mechanism. 

That gap is one reason Kurt Cagle is rethinking how graphs handle time. His proposal: the Holonic Graph Architecture.

Kurt, a prolific writer, ontologist, and architect who’s been involved in web standards for over 20 years now,  most recently launched a World Wide Web Consortium (W3C) Community Group to explore holons in graph engineering. The group’s goal is to ground AI systems in a spatiotemporal Datalog architecture compatible with RDF 1.2.

In the holonic graph approach, each entity (a shipment, a ship, a container) is a holon: a whole made of parts, and also a part of something larger. In this way, an entity isn’t just a record — it’s a system with its own boundary, its own internal state, and its own view of the outside world.

Traditional knowledge graphs can’t track how content changes over time. The Holonic Graph Architecture fixes this. It separates static knowledge from event data through reification (making the model more concrete) and versioning, so systems can track change directly.

The idea borrows from Arthur Koestler’s book the Ghost in the Machine: holons are whole-part systems with clear boundaries and their own internal state. In a graph, named graphs act as identifiers for these holons. Instead of one massive centralized graph, the architecture lets you query individual holons directly. 

Supply chains show why this matters. Instead of managing one massive graph for a global state, users query individual holons — a single shipment, a single transport leg — to trace provenance and movement.

The same bounding principle makes AI more reliable. Give an AI a specific holon instead of an unbounded knowledge base, and it hallucinates less. The framework keeps testing the model of the world against reality — correcting itself when the two don’t match.

Kurt details the entire concept in an episode of the GraphRAG Curator Podcast, where he walks through the new W3C Holon Community Group, the origins of the Holonic Graph Architecture, and what holons mean for supply chains and AI reliability. The YouTube video and edited transcript follows.

YouTube Embed

Edited Transcript

Alan Morrison: I am pleased to have you on the GraphRag Curator Podcast, Kurt. We are on the line with my old boss, Kurt Cagle.

For those who don’t know you, Kurt, you’re ubiquitous in the semantic technology community. You have a new role, and I want to make sure that people are aware of what you’re involved with and how to reach out to you.

The W3C Holon Community Group

Kurt Cagle: I just launched a new community group with the W3C. A community group is not quite the same thing as a working group. Working groups establish recommendations and focus on a particular standard, providing testing and integration. At the end, there is an artifact that becomes part of the web.

Community groups are vehicles for establishing specifications and determining exactly what you’re trying to do in the first place. They are now the first stage in the development process for creating standards.

I wanted to create the Holon Community Group. It is dedicated to exploring the concept of holons as they apply to graphs and graph engineering. We look at how they help ground AI systems and provide a data log architecture in sync with recent specifications like RDF 1.2.

The group acts as a mediator, and we hope to build a formal standard. Our first meeting had nearly 40 participants, which is astonishing for this niche. Participation is open at w3.org/community/holon/.

I am officially the chairman. I’m hoping to promote the concept of holons and get people talking with one another.

Genesis of Holonic Graph Architecture

Alan Morrison: This ties back to your writing on holonic graphs. Can you tell us how you got started? What was the pain point you were addressing?

Can you tell us how you got started with this topic? What was the pain point you were trying to address? 

Kurt Cagle: It started simply. I found I had too many triple files and was losing provenance—how things were connected and related. I took a page from how Anthropic manages skills, using a Markdown file with a YAML header and multiple code blocks.

And so as part of this process, I took a page from what had been the… how, I think, Anthropic was basically managing their skills and saying, here is a way of utilizing a barbed-down file with a header and yammer and additional pieces along those lines. But once I had that, those additional pieces basically included multiple code blocks. 

This led to the Holonic Graph Architecture (HGA). A second area involves describing context. For years, people have wanted knowledge graphs, but those graphs have difficulty representing the evolution of content over time. They are essentially static snapshots.

So that was one part of the genesis, and that’s actually part of what’s up there now in what I’m calling a holonic graph architecture, the HGA, and it’s one proposal that we’ll be discussing. 

A second area that goes back to the whole definition of how we effectively describe context? And this has been an ongoing issue for probably the last five or six years of my professional life, where inevitably what people would come to is they say, well, we want a knowledge graph.

And a knowledge graph is a very good way of talking about these things in your system. These are the designs the architecture lists how they can connect it. But the problem that you run into with such graphs is that in general, they have difficulty representing the evolution of content over time. And that becomes a very key point of the architecture, because if you have trouble involving the evolution of what you have with essentially a snapshot, this is how things are in a certain way.

If you ask a knowledge graph who the president is, it gives you a name, but you lose the previous president’s name unless you have a versioning mechanism. A version is essentially an event. This sparked the idea of separating the architecture into a knowledge graph and an event graph.

Around 2017, I started looking at reification—talking about a statement as an assertion. Earlier RDF required four different triples for this, but the RDF-star working group made it possible to talk about assertions as individual terms or IRIs.

This is crucial because relationships are not static facts; they reflect observations that mutate over time. By using a reifier, we can track the evolution of an assertion. This turns the observable into an event graph. Recently, AI has focused on “context graphs,” but the semantic community solved this with data logs and standards like BFO that discuss events and endurance.

Defining the Holon

Kurt Cagle: I kept coming back to the notion of the evolution of relationships over a specific scope. This led me to the work of Arthur Koestler, who wrote The Ghost in the Machine. Koestler defined whole-part systems: a cell is part of an organ, yet is made of its own systems like proteins. Each building block is a system with unique characteristics compared to its subordinates.

This applies to business, ecosystems, and supply chains. A holon has: an initial state, an evolutionary mechanism, a boundary (or Markov blanket), and a projection.

In programming, objects are holons. In graphs, we use named graphs as identifiers for holons. A holon constitutes the graph, the boundaries (what is inside vs. outside), and the projections (how it looks to an outside observer). You never see the interior of the graph; you only see the view produced by a query mechanism like SPARQL. [For more on named graphs and how they’re used in practice, see Pieter Colpaert’s post “Named graphs and RDF messages”.] 

SHACL 1.2 [See Kurt’s post on Understanding SHACL 1.2 Rules for more information.] is emerging similarly with rules and node expressions. For example, you might not expose a birth date, but rather a calculated age. These are all characteristics of wholeness.

Alan Morrison: So you are applying holon theory to graphs to treat them as systems and entities within systems. You’ve put all the pieces on the table using established standards to make this holistic concept functional in a graph mode.

It’s a rich concept. Let me just try to describe what the takeaways seem to be.

You’ve got all the piece parts out on the table now to make this possible because you have these established standards that people are using, they’re delivering value, but the holistic concept has not been put together in a way that it can function in this graph mode. And so that’s what you’re doing and you’ve got this nesting of named graphs that you’re articulating further and all these have identities, all these aspects of this graph have these identities, 

There are huge and very complex use cases for holonic graphs, but I’m sure that they can’t always be used in every use case. You’ve got much simpler use cases that don’t need this complexity.

Where is this applicable? You mentioned supply chains—that seems like a wonderful context for this.

Kurt Cagle: Exactly. Massive centralized graphs lose performance and are hard to keep in sync. In a supply chain, different holons are involved: the transport mechanism, containers, and ports. You don’t manage everything globally. Instead, you query a ship for its manifest because it knows its own environment.

This distributes the load. You can identify a package’s trajectory by walking through a series of holons, tracking the provenance as it transits from one to the next. Each hand-off leaves a record of disposition.

Each of these, in turn, essentially becomes simpler and simpler and simpler, but they also allow you to abstract the things that aren’t relevant until you need to be able to begin. And it also distributes the load. 

A primary challenge in this architecture is managing distributed state. For instance, a holon might track a ship’s location while providing access to the resources it carries—even if those resources reside on a separate ‘holon server’ responsible for regional tracking. 

Rather than attempting a complex global query, you can scope your search. By knowing the item’s history or shipment ID, you can traverse a chain of holons to trace the package’s trajectory. As an item moves from drop-off to sorting, and eventually to a vehicle, each transition creates a hand-off record, effectively tracking the package’s provenance.

Alan Morrison: Record keeping is vital in a digitized business environment. You’ve described this in your blog posts on The Ontologist Substack and The Inference Engineer. How do we get people on board? It can be intimidating compared to simpler methods like SKOS.

And just being able to do the kinds of recording that you need to for a particular purpose and then retrieve that when you need to, you know, the records, just that gets complicated. But it’s sort of like there’s this whole mechanism that you’re describing in these blog posts. And, you know, people can look at these wonderful blog posts on your ontologist sub stack. We also have the inference engineer, is that correct? 

Kurt Cagle: Yes, Inference Engineer is next to the other one. 

Yeah. So you’ve laid this out. And so there’s this organization that really hasn’t been that visible that’s possible with the graphs now. And so the challenge is, how do we get people on board with this approach?

First of all, it can be intimidating to think about it. And there are so many simpler ways that people can get started with SKOS, for example, control vocabularies, for simpler purposes. This is when you’ve got the whole library, the whole large enterprise involved, or the whole supply chain involved. 

And you want this organization system, this nested, you know, named graph approach that allows you to manage at scale, essentially, using the graph approach. Ideally, you’ve got people who are talking to you about who have these complex problems who are talking to you about this sort of thing. 

Kurt Cagle: By agreeing on standards for the “envelope,” complex problems can be decomposed into something manageable. We’ve watched the AI hype cycle and seen that LLMs hallucinate because they are too open. They have too much information and no boundaries.

LLMs are pattern recognition systems for narrative content. To make them effective, you must narrow the boundary—provide the holons they are expected to work with. This establishes what is valid and how to represent change. We are moving away from one big schema that controls everything, which simply hasn’t worked.

We can now use these tools to create records with reliability scores. In epistemology, we ask how reliable a message is. By encapsulating provenance within the model, we can determine the source of truth. We can also apply active inference, a concept from Karl Friston about minimizing surprise.

I call this what you build, and it is a core component of any programming system. Beyond basic architecture, you must be able to determine the reliability of a provenance chain. This involves assessing the basis of an event: What happened? What is the likelihood of it occurring again? By analyzing previous similar instances, you can gauge the reliability of the chain.

This brings us to epistemology, which has become increasingly relevant in this space. At its core, epistemology asks: how reliable is the message? When determining a source of truth, the answer depends on the context and the reliability of the underlying data. By encapsulating these reliability metrics within your model, you can validate specific scenarios.

You can also apply other principles, such as active inference. Pioneered by Karl Friston and his team, this concept focuses on how systems minimize surprise. It helps us evaluate the extent to which our perceived world aligns with actual reality, moving us into the realm of simulations where historical records are used to test expectations.

This moves us into the realm of simulations where we use historical records to see if outcomes are mapped to expectations. This allows us to talk about evolutionary systems and physical truth.

Alan Morrison: Thank you, Kurt, for laying out these capabilities. 

For More Information:

———. “On the Modelling of Worlds.” The Ontologist (blog). October 1, 2025. https://ontologist.substack.com/p/on-the-modelling-of-worlds.

Cagle, Kurt. “The Holonic Graph: A New Architecture for Knowledge That Thinks.” The Inference Engineer (blog). April 2, 2026. https://inferenceengineer.substack.com/p/the-holonic-graph-a-new-architecture.

Cagle, Kurt, and Chloe Shannon. “Understanding SHACL 1/2: Rules.” The Ontologist (blog). November 7, 2024. https://ontologist.substack.com/p/understanding-shacl-12-rules.

Colpaert, Pieter. “Named Graphs.” Pieter Colpaert (blog). September 30, 2025. https://pietercolpaert.be/linkeddata/2025/09/30/named-graphs.