The Living Graph: Holons and the Four-Graph Model
How a fifty-year-old idea from biology is reshaping the way we think about knowledge graphs
I’ve had a lot of people comment on my holon post, and it’s probably a good time to dig into it in greater depth.
The world, as you know it, is continuous.
You walk through doorways, open up boxes, and store things in safes and warehouses.
When you get into an aeroplane, you see the airport, then, as the plane takes off, the surrounding city, the region, and, if you go high enough, the whole planet.
We have become used to zooming in microscopically, and drilling down has become synonymous with digging deeper into a topic.
When your car breaks down and needs to be serviced, you open up the hood to get to the engine parts,
when a surgeon operates on a body, the operation exposes the muscles, veins, nerves, organs, ligaments and bones of that body.
Your mind, on the other hand, can’t hold all of the world within it; nor, despite the best efforts of AGI advocates, can you fit the whole of reality into a computer system. Instead it decomposes complex systems into collections of interconnected containers, limiting the scope of the model so that it can be processed while isolating the extraneous context, creating encapsulation and boundaries.
This is the world of the Holon. The following article looks at holons at both a conceptual and graph model as a basic primer. It’s a work in progress, and is intended primarily to introduce some of the core aspects of holonic RDF graphs. It is a continuation of ideas first developed in my previous article
This is tied into the W3C Context Graph Community Group.
Preface: A Problem With Flat Graphs
If you have worked with RDF for any length of time, you have probably run into a particular kind of frustration. You start with a clean, elegant graph. A handful of classes, some properties, a set of well-formed triples. Then the requirements arrive: this data is sourced from three different authorities with different confidence levels; this concept exists at multiple scales of resolution; this relationship needs to carry a timestamp and a provenance note; these subgraphs need different access controls; and by the way, the same entity appears in five different contexts that all need to remain coherent with each other.
The standard RDF toolkit — triples, named graphs, a SPARQL endpoint — handles any one of these requirements gracefully. It handles all of them simultaneously with considerably more difficulty. You end up with workarounds: blank nodes that proliferate beyond control, named graphs that have no principled relationship to one another, reification patterns that solve one problem while creating three more.
The deeper issue is that flat RDF has no native concept of inside and outside. A triple is just a triple. A named graph is just a bag of triples with a label. There is no principled way to say: these triples constitute a coherent entity with a well-defined boundary, and that boundary governs how the entity relates to everything else in the graph.
This is the problem that holons solve.
Part One: What Is a Holon?
The word was coined by the Hungarian-British writer Arthur Koestler in his 1967 book The Ghost in the Machine. Koestler was trying to describe a pattern he saw everywhere in biological and social systems: things that are simultaneously wholes in themselves and parts of something larger.
A cell is a whole — it has a membrane, an interior, a coherent biochemistry, a life cycle. But it is also a part — of a tissue, of an organ, of a body. Remove it from that larger context and it loses meaning. A word is a whole — it has a sound, a spelling, a definition. But it is also a part — of a sentence, of a paragraph, of an argument. Neither characterisation is more fundamental than the other. The cell is not “really” just a component; the body is not “really” just an assembly of cells. Both levels of description are real and necessary.
Koestler called this pattern a holon (from the Greek holos, whole, plus the suffix -on suggesting a particle, as in proton or neutron). A system of nested holons — cells within tissues within organs within bodies, or words within sentences within paragraphs within documents — he called a holarchy.
The pattern has three essential properties:
Self-consistency. A holon makes sense on its own terms. Its interior is coherent. It does not require knowledge of the larger system to be understood.
Relational dependence. A holon’s meaning is shaped by its position in the holarchy. The same cell behaves differently in a heart than in a liver. The same word means different things in different sentences.
Dual interface. A holon has two faces: an inward face that governs its interior coherence, and an outward face that governs how it appears to and interacts with the systems that contain it.
These three properties are not philosophical abstractions. They translate directly into architectural requirements for a knowledge graph system — and the four-graph model is the architecture that satisfies all three.
Part Two: The Cell as Mental Model
Before introducing the four graphs formally, it is worth dwelling on the cell analogy, because it does most of the conceptual work.
Picture a living cell under a microscope. It has four distinguishable structural elements:
The contents — the organelles, the DNA, the proteins being manufactured, the chemical reactions in progress. Everything that makes this cell this cell, described entirely on its own terms.
The membrane — the cell wall. Selectively permeable: some things pass through, others do not. Studded with receptor proteins that recognise specific molecules. The membrane is not just a container; it is an active participant in the cell’s identity, deciding what belongs inside and what does not.
The signals the cell broadcasts — the hormones, surface proteins, and chemical gradients that tell neighbouring cells what type this cell is, what state it is in, and where it is. The cell does not expose its DNA to the bloodstream. It exposes a carefully curated set of signals that external systems can interpret.
Its position in the organism — whether this cell belongs to the liver, the heart, the immune system. This contextual placement does not change what the cell is, but it fundamentally shapes what the cell does and what it means.
The four-graph model maps these four elements onto a knowledge graph architecture. Each holon in the graph has four named graphs associated with it, each playing one of these roles.
Part Three: The Four Graphs
The Interior Graph — What the Holon Knows About Itself
The interior graph is the holon’s private world. It contains the triples that constitute the holon’s own assertions about itself — the facts that are true within this context, asserted by this authority, coherent on these terms.
A city holon’s interior graph contains the city’s name, its population, its coordinates, its founding date. A musical movement’s interior graph contains its tempo marking, its key signature, its measure count. A dungeon chamber’s interior graph contains its lighting, its contents, its dimensions.
The interior is the authoritative, self-contained record of what this holon is. Nothing outside the holon placed these facts here. Nothing outside the holon is responsible for their consistency.
In RDF terms, the interior graph is a standard named graph — a set of triples identified by an IRI. What makes it distinctive in the holonic model is not its structure but its role: it is the data graph, the A-Box in description logic terminology, the thing being described.
GRAPH <urn:holon:geo:canada:bc:vancouver> {
<urn:holon:geo:canada:bc:vancouver> a geo:City ;
rdfs:label "Vancouver" ;
geo:population "675218"^^xsd:integer ;
geo:latitude "49.2827"^^xsd:decimal ;
geo:longitude "-123.1207"^^xsd:decimal .
}
The Shapes Graph (Boundary Membrane) — What the Holon Allows In and Out
This is the most architecturally important of the four layers, and the one that most distinguishes a holon from an ordinary named graph.
The boundary membrane is the holon’s rulebook. It defines what counts as valid data inside the holon, what can enter, what can exit, and under what conditions. In the holonic model, this layer is where SHACL shapes live — the constraint definitions that say “a city must have exactly one label,” “population must be a non-negative integer,” “every city must declare which province it belongs to.”
But the boundary membrane does more than validate data. It is also where portals live — the controlled openings through which traversal from this holon to another is possible. We will return to portals in detail shortly. For now, the key point is that the membrane governs the boundary from this side: it defines what the holon exposes and what it permits.
A SHACL violation in the boundary layer is not merely a data quality problem in this model. It is a broken membrane — the holon’s interior has leaked something that does not conform to its own boundary definition. Thinking about validation failures as membrane breaches changes how you prioritise remediation: a sh:Violation means the membrane is genuinely compromised; a sh:Warning means it is weakened but still functional; a sh:Info means it is advisory.
GRAPH <urn:holon:geo:canada:bc:vancouver/boundary> {
cga:CityHolonShape a sh:NodeShape ;
sh:targetClass geo:City ;
sh:closed true ;
sh:property [
sh:path rdfs:label ;
sh:minCount 1 ;
sh:maxCount 1 ;
sh:severity sh:Violation
] ;
sh:property [
sh:path geo:population ;
sh:datatype xsd:integer ;
sh:severity sh:Warning
] .
}
The sh:closed true declaration is doing boundary-membrane work: it says that the interior is impermeable to unspecified predicates. Any property not explicitly declared in the shape is a membrane violation.
The Projection Graph — What the Holon Shows to the World
The interior may contain far more than the outside world needs to see, or it may describe things in vocabulary that only makes sense internally. The projection graph is the holon’s curated outward face — a deliberate selection of facts expressed in terms that external systems can interpret.
The projection is not a copy of the interior. It is a translation. Vancouver’s interior might use a provincial address schema and a local coordinate system; its projection speaks GeoNames IRIs and schema.org vocabulary, so any external system can consume it without knowing anything about the interior’s structure. A musical work’s interior might describe harmony in a specialised tonal vocabulary; its projection links to MusicBrainz and Wikidata identifiers that catalogue systems already understand.
The projection is also where external bindings live — the assertions that connect this holon to the broader linked data ecosystem:
GRAPH <urn:holon:geo:canada:bc:vancouver/projection> {
<urn:holon:geo:canada:bc:vancouver>
cga:bindsTo <https://sws.geonames.org/6173331/> ;
skos:exactMatch <https://www.wikidata.org/entity/Q24639> .
}
Notice the choice of cga:bindsTo rather than owl:sameAs. This is deliberate. owl:sameAs asserts full logical identity, which triggers OWL’s inference machinery to treat every property of the external resource as a property of Vancouver and vice versa. That is almost never what you want when linking to an external authority — it collapses the distinction between your representation and theirs. Directional predicates like cga:bindsTo and skos:exactMatch acknowledge the relationship without asserting identity, preserving the holon’s representational independence.
The Context Graph — Where the Holon Sits in the Larger Whole
A holon is always both a whole in itself and a part of something larger. The context graph records the second half of that statement: which holon contains this one, which holons are its peers, which larger structures it participates in.
The context graph does not change what the holon is. It records where it belongs.
In practice the context graph has two distinct strata that should be managed separately, though they share the same layer. The structural stratum records stable membership — this city is in this province, this movement is in this sonata, this dungeon chamber is in this dungeon. The temporal stratum records event-derived annotations — census updates, performance events, signal-driven state changes.
GRAPH <urn:holon:geo:canada:bc:vancouver/context/structural> {
<urn:holon:geo:canada:bc:vancouver>
cga:memberOf <urn:holon:geo:canada:british-columbia> ;
cga:memberOf <urn:holon:region:metro-vancouver> ;
cga:adjacentTo <urn:holon:geo:canada:bc:burnaby> .
}
Reifications in the context graph typically show the evolution of a given resource over time. In the above illustration, for instance, a car can be shown “moving” in the graph through successive reifications:
GRAPH <urn:holon:myRoad/context/temporal> {
urn:holon:vehicle:myRedSportsCar a <urn:holon:vehicle>;
cga:hasTemporalAnnotation
<urn:event:redCarMoveEvent:4mile-1minute>,
<urn:event:redCarMoveEvent:5mile-2minute>,
<urn:event:redCarMoveEvent:6mile-3minute>
.
<urn:event:redCarMoveEvent:4mile-1minute> a urn:event ;
event:frame <urn:frame:MileMarker> ;
event:locus (4,1) ;
event:status "Good" ;
.
<urn:event:redCarMoveEvent:5mile-2minute> a urn:event ;
event:frame <urn:frame:MileMarker> ;
event:locus (5,2) ;
event:status "Good" ;
.
<urn:event:redCarMoveEvent:6mile-3minute> a urn:event ;
event:frame <urn:frame:MileMarker> ;
event:locus (6,3) ;
event:status "Flat Tire" ;
.
}This can also be condensed with reifier notation:
GRAPH <urn:holon:myRoad/context/temporal> {
urn:holon:vehicle:myRedSportsCar a <urn:holon:vehicle>
~ urn:event:redCarMoveEvent:4mile-1minute {|
a urn:event ;
event:frame <urn:frame:MileMarker> ;
event:locus (4,1) ;
event:status "Good" ;
|},
~ urn:event:redCarMoveEvent:5mile-2minute {|
a urn:event ;
event:frame <urn:frame:MileMarker> ;
event:locus (5,2) ;
event:status "Good" ;
|},
~ urn:event:redCarMoveEvent:6mile-3minute {|
a urn:event ;
event:frame <urn:frame:MileMarker> ;
event:locus (6,3) ;
event:status "Flat Tire" ;
|}.
}Notice that the reifier events are named here, meaning that they can be referenced by external processes or queries.
Part Four: The IRI as Identity Thread
The holonic model has one more essential structural element that cuts across all four layers: the holon’s IRI — its Internationalized Resource Identifier, the web address that names it — is the same in every graph.
This seems obvious until you consider what it means. The IRI <urn:holon:geo:canada:bc:vancouver> appears as:
The subject of triples in the interior graph
The target of shape declarations in the boundary layer
The subject of external bindings in the projection graph
The subject of membership assertions in the context graph
It is the thread that stitches all four layers into a coherent entity. Query any layer using the IRI and you are querying the same thing. Navigate from the interior outward through the projection, or inward from the context down to the interior — you never lose track of which holon you are in.
This is what distinguishes a holon from a named graph with some extra machinery. A named graph is just a container. A holon is an entity with genuine inside/outside distinction, four layers of description, and an IRI that anchors all four. The IRI is not just a name — it is a persistent identity that survives updates to any individual layer.
Part Five: Portals
Portals are the most architecturally interesting object in the model, and the one with the least obvious precedent in standard RDF practice.
A portal is a boundary membrane object that belongs to the source holon but resolves to the target holon’s identity. It is the controlled opening through which traversal from one holon to another is possible.
To understand why portals are necessary, consider the alternative. You could represent the relationship between a province and its cities with a simple triple:
<urn:holon:geo:canada:british-columbia>
cga:contains <urn:holon:geo:canada:bc:vancouver> .
This is a fact about containment. It says nothing about how you get from one to the other, what conditions govern the traversal, what the relationship looks like from a user’s perspective, or whether the connection is currently active. It is a static structural assertion, not a dynamic traversal mechanism.
A portal reifies all of that missing information into a first-class entity:
GRAPH <urn:holon:geo:canada:british-columbia/boundary> {
<urn:portal:icon:bc:vancouver> a cga:IconPortal ;
cga:portalType cga:UnidirectionalPortal ;
cga:sourceHolon <urn:holon:geo:canada:british-columbia> ;
cga:targetHolon <urn:holon:geo:canada:bc:vancouver> ;
cga:activationEvent cga:ClickActivation ;
cga:iconImage <urn:asset:skyline:vancouver> ;
cga:iconPosition <urn:geo:centroid:vancouver> .
}
Now the relationship is navigable: it has a source, a target, a type, an activation mechanism, and a visual representation. A rendering agent can display the icon at the correct geographic position. A navigation agent can follow the portal to the target holon. A validation agent can check that the target holon actually exists and contains the expected data.
Portals Are Not Containment
The distinction between containment and portals matters precisely because traversal in a holonic graph is not just graph walking — it is a transition between epistemic contexts. When you cross from the British Columbia holon into the Vancouver holon, you are moving from one named graph (one set of assertions, one authority, one boundary ruleset) into another. A portal is the object that makes that transition legible, governable, and annotatable.
This also means portals can express relationships that strict containment cannot:
Cross-level portals. A direct link from a continent to a city, bypassing province and country levels, for a “jump to capital” interaction. The containment hierarchy is unchanged; a new traversal path exists.
Lateral portals. In the dungeon example, the hidden passage between the Ossuary and the Throne Room is not a containment relationship — both are children of the same dungeon. It is a peer-to-peer traversal. No containment model expresses this without distorting the hierarchy.
Sealed portals. The collapsed passage in the dungeon points at a subvault holon that is unreachable:
<urn:portal:blackspire:ossuary-collapse> a cga:Portal ;
cga:portalType cga:SealedPortal ;
cga:sourceHolon <urn:holon:dungeon:blackspire:ossuary> ;
cga:targetHolon <urn:holon:dungeon:blackspire:subvault> ;
cga:isTraversable false .
The subvault holon exists — it has an IRI and an interior. But traversal is currently blocked. This is a meaningful distinction from the connection not existing at all. The IRI persists even when the membrane is sealed.
Part Six: Annotating Relationships — Why Reification Matters
Standard RDF triples are binary: a subject, a predicate, an object. They say nothing about when the relationship was established, who asserted it, how confident we are in it, or under what conditions it holds.
For a long time the standard workaround was to mint a new resource and hang the metadata off that:
# RDF 1.1 workaround
:binding1 a rdf:Statement ;
rdf:subject <urn:holon:geo:canada:bc:vancouver> ;
rdf:predicate cga:bindsTo ;
rdf:object <https://sws.geonames.org/6173331/> ;
dct:created "2026-03-19"^^xsd:date ;
cga:confidence "0.97"^^xsd:decimal .
This works, but it is verbose, creates blank node proliferation, and is not directly queryable as a triple — you have to join across the reification resource to get at the original relationship.
RDF 1.2 introduced a cleaner syntax called annotation (using the {| |} notation in Turtle 1.2) that attaches metadata directly to a triple without minting an intermediate resource:
<urn:holon:geo:canada:bc:vancouver>
cga:bindsTo <https://sws.geonames.org/6173331/>
{|
dct:created "2026-03-19"^^xsd:date ;
cga:bindingStrength cga:StrongBinding ;
cga:confidence "0.97"^^xsd:decimal ;
prov:wasAttributedTo <urn:agent:curator-kg>
|} .
This reads as: “Vancouver binds to GeoNames 6173331, and that assertion was created on 19 March 2026 by the knowledge graph curator, with strong binding and 97% confidence.”
Where Reification Is Not Just Convenient But Necessary
The holonic model surfaces several situations where reification is the correct tool rather than a workaround.
The portal-target binding. The assertion that a portal resolves to a specific target holon is itself a claim with provenance. Who established this connection? When? Has it been validated recently? These are facts about the assertion, not about either the portal or the target.
Cross-frame coordinate bindings. When a holon’s local coordinate is bound to an external coordinate system, the binding has confidence, a source authority, and a validity period.
Motivic relationships in music. The assertion that a musical theme in the first movement recurs transformed in the third movement is not a fact about either theme independently — it is a claim about their relationship, with its own analytical provenance.
Transport route connections. The travel time between Vancouver and Hope via Highway 1 is not a fact about Vancouver, not a fact about Hope, and not a fact about the highway. It is a fact about the triple that connects them, annotated with seasonal variation, source authority, and last-validated date.
<urn:portal:route:hwy1-bc:west-terminus>
cga:targetHolon <urn:holon:geo:canada:bc:vancouver>
{|
transport:travelTimeTypical "PT1H45M"^^xsd:duration ;
transport:distanceKm "148.0"^^xsd:decimal ;
dct:created "1962-07-30"^^xsd:date ;
prov:wasAttributedTo <urn:org:bc-ministry-transport>
|} .
The philosophical point: reification is the right tool when the thing you want to say is a claim about a relationship rather than a claim about either of the related entities. In a holonic graph, these situations arise constantly — because the model’s entire purpose is to represent relationships that carry their own meaning.
Part Seven: The Holarchy — Holons All the Way Down (and Up)
The real power of the model emerges when you nest holons. A city is a holon. So is the province that contains it. So is the country that contains the province. So is the continent. Each level is simultaneously a whole in itself and a part of the next level up.
In geographic terms:
North America (depth 0)
├── Canada (depth 1)
│ ├── British Columbia (depth 2)
│ │ ├── Vancouver (depth 3)
│ │ └── Victoria (depth 3)
│ ├── Ontario (depth 2)
│ └── Quebec (depth 2)
├── United States (depth 1)
└── Mexico (depth 1)
But it is not just geography. The same pattern holds for:
Musical composition: Work → Movement → Section → Motif. A sonata movement is complete in itself but derives its meaning from its position in the work. A fugue subject is a coherent musical idea but is only fully intelligible in the context of the development that follows it.
Organisational structure: Corporation → Division → Department → Team. Each level has its own governance, its own data, its own membership rules, while participating in the larger whole.
Software architecture: System → Service → Module → Function. Each component encapsulates its implementation while exposing a defined interface.
Legal corpora: Treaty → Convention → Article → Clause. Each level has normative force at its own resolution.
The holarchic depth counter (cga:holonDepth) is not mere metadata — it is the record of where a holon sits in the nesting structure, and it enables queries like “find all holons at depth 2 that have no valid projection binding” that span the hierarchy.
The Icon Portal Pattern
When each child entity in a holarchy needs a navigation mechanism, the icon portal pattern makes the connection between hierarchy and interaction explicit:
GRAPH <urn:holon:geo:canada/boundary> {
<urn:portal:icon:canada:bc> a cga:IconPortal ;
cga:iconLabel "British Columbia" ;
cga:sourceHolon <urn:holon:geo:canada> ;
cga:targetHolon <urn:holon:geo:canada:british-columbia> ;
cga:activationEvent cga:ClickActivation ;
cga:iconImage <urn:asset:shield:ca-bc> ;
cga:iconPosition <urn:geo:centroid:bc> .
}
The icon portal is simultaneously a data assertion (this holon contains that holon, reachable via this portal), a presentation specification (here is the visual that represents the portal, here is where to place it), and a navigation contract (clicking activates traversal to the target holon). Knowledge graph, user interface, and navigation architecture are unified in a single RDF construct.
Part Eight: Coordinate Systems Are Abstract
A common misconception about holonic systems is that they are inherently spatial — that coordinates, frames, and transforms are specific to geographic or physical applications. The musical example reveals this is not the case.
A coordinate is a position in a frame. The frame is the interpretive context that gives the position meaning. 49.2827 is not a latitude until you specify that it is measured in degrees, in the WGS84 reference frame, on a specific ellipsoidal model of the Earth. Separated from its frame, it is just a number.
In a musical holon, the equivalent coordinate is a position in metric space — [movement 1, measure 24, beat 3, tick 0] — or in tonal space — [pitch class 1, octave 4, scale degree I]. These are rank-1 tensors in abstract frames, not geographic space:
<urn:tensor:op27n2:mvt1:opening:tonic> a tensor:Value ;
tensor:rank 1 ;
tensor:shape "3" ;
tensor:frame <urn:holon:crs:tonal-harmonic> ;
tensor:components "[1, 4, 1]"^^tensor:Vector3D .
# pitch class 1 = C♯, octave 4, scale degree I
The reference frame is a holon too — it has its own IRI, its own interior (axis definitions, units, origin), and its own projection (binding to external standards like EPSG codes or musical notation conventions). When a portal crosses a frame boundary — when you move from a holon using metric score coordinates to a holon using tonal harmonic coordinates, or from one geographic CRS to another — the portal carries the transformation tensor that converts positions between frames.
For a geographic portal crossing from WGS84 to UTM:
<urn:portal:icon:bc:vancouver>
crs:sourceFrame <urn:holon:crs:wgs84> ;
crs:targetFrame <urn:holon:crs:utm-10n> ;
crs:frameTransform <urn:transform:wgs84-to-utm10n> .
For a dungeon portal crossing between two local Cartesian frames — a rotation of 90 degrees about the vertical axis and a translation of 15 metres east and 3 metres north:
<urn:tensor:transform:ossuary-throne-matrix> a tensor:Value ;
tensor:rank 2 ;
tensor:shape "4,4" ;
tensor:variance tensor:Mixed ;
tensor:components "[[0,-1,0,15],[1,0,0,3],[0,0,1,0],[0,0,0,1]]"^^tensor:Matrix4x4 .
The tensor machinery is identical whether the frame is geographic, tonal, Cartesian, or something more abstract. This generality is not incidental — it reflects the fact that any measurable property can be understood as a position in some frame, and any transition between holons that use different frames can be characterised by a transformation tensor.
Part Nine: Event-Driven Context and Scene Graphs
The context graph has two interpretations that initially seem incompatible but turn out to be complementary aspects of the same layer.
The first interpretation is the scene graph: the context layer records the structural position of the holon in the holarchy — what contains it, what it is adjacent to, what networks it belongs to. This is relatively static, changing only when the hierarchy itself reorganises. A city is in a province. A musical movement is in a sonata. A dungeon chamber is in a dungeon.
The second interpretation is the event-driven datalog: the context layer receives signals from the outside world, fires rules against those signals, and deposits temporal annotations. A census signal arrives, a rule fires, and a new population annotation is written. A GPS signal arrives, a rule fires, and a new position annotation is written. The layer is not a static map but a living record of everything that has happened to or around this holon.
The resolution is that these two interpretations are not competing — they are answering the same question (”what larger whole does this holon belong to?”) along two independent axes. A city belongs to a province structurally. It also belongs to an ongoing stream of demographic, meteorological, and administrative events temporally. Both senses of belonging are real. Neither reduces to the other.
The practical architecture separates them into two named sub-strata:
<urn:holon:geo:canada:bc:vancouver/context/structural>— stable hierarchy facts, versioned, authority-stamped<urn:holon:geo:canada:bc:vancouver/context/temporal>— event-derived annotations, append-only, signal-sourced
The parent IRI <.../context> serves as a union view over both for queries that need the full picture. Each stratum is independently queryable and separately manageable — different retention policies, different indexing strategies, different update frequencies.
Signals enter the model through the boundary membrane. This is architecturally correct: a signal is something crossing the membrane from outside, not an interior fact and not a structural membership assertion. The boundary layer contains both SHACL shapes (which validate structural conformance) and datalog rules (which fire on signal patterns and produce temporal annotations). Both are membrane operations, and their outputs go to different strata of the context graph.
Part Ten: Routes, Networks, and Shared Boundaries
The geographic and dungeon examples treat portals as owned by their source holons. A city’s navigation portals live in the city’s boundary layer. A dungeon chamber’s door portals live in the chamber’s boundary layer. Ownership is unambiguous.
Routes — highways, railways, corridors — introduce a structural complication that is worth understanding because it reveals something the basic model needs to extend.
A highway between two cities is not owned by either city. It is not a portal in the standard sense — a portal is a mechanism owned by its source. A highway has ontological independence: it has its own governance authority, its own physical properties, its own sub-structure of junctions and segments. It exists regardless of whether either terminus exists in the graph. It is, in the full sense, a holon in its own right.
This produces an architecture where routes are holons whose portals resolve to city holons, and city holons reference those portals without owning them:
# The route's boundary layer owns the portal
GRAPH <urn:holon:route:trans-canada-hwy1-bc/boundary> {
<urn:portal:route:hwy1-bc:west-terminus>
cga:sourceHolon <urn:holon:route:trans-canada-hwy1-bc> ;
cga:targetHolon <urn:holon:geo:canada:bc:vancouver> .
}
# The city's boundary layer references but does not own the portal
GRAPH <urn:holon:geo:canada:bc:vancouver/boundary> {
<urn:holon:geo:canada:bc:vancouver>
cga:exposesPortal <urn:portal:route:hwy1-bc:west-terminus> .
}
The distinction between cga:hasPortal (ownership) and cga:exposesPortal (reference) preserves the single-ownership principle while allowing both holons to surface the connection. The portal IRI is the shared identity; each holon’s relationship to it is different.
And the properties of the connection — travel time, distance, provenance — belong neither to the route nor to the city but to the assertion that connects them. This is the case reification was designed for:
<urn:portal:route:hwy1-bc:west-terminus>
cga:targetHolon <urn:holon:geo:canada:bc:vancouver>
{|
transport:travelTimeTypical "PT1H45M"^^xsd:duration ;
transport:distanceKm "148.0"^^xsd:decimal ;
dct:created "1962-07-30"^^xsd:date
|} .
Part Eleven: SHACL as the Formal Membrane
Earlier we described the boundary membrane informally as the holon’s rulebook — the layer that defines what is valid inside and what is permitted through. SHACL (Shapes Constraint Language) is what makes that rulebook formally executable.
For readers unfamiliar with SHACL: it is a W3C standard for defining constraints over RDF graphs. You write a shape that says “every node of class City must have exactly one label, a decimal latitude between -90 and 90, and a reference to its containing province.” SHACL can then validate any RDF graph against that shape and produce a report listing every violation.
In the holonic model, SHACL is not just a validation tool — it constitutes the boundary membrane. A holon without a shapes graph has no membrane. It is just a named graph with an IRI. The SHACL shapes are what make it a holon in the full architectural sense, because they are what enforce the inside/outside distinction.
This mapping extends across all four holonic layers:
Interior validation. Node shapes with sh:closed true enforce that the interior contains only the predicates explicitly permitted by the membrane. Unexpected predicates are membrane breaches, not just data quality issues.
Portal validation. Portals are first-class entities and need their own shapes. SHACL 1.2’s sh:deactivated true allows specific constraints to be formally suspended for specific subtypes — a sealed portal has no presentation surface, so its icon constraint is deactivated, not just absent.
Cross-holon constraints. Some validity conditions are relational — they cannot be satisfied by inspecting a single holon. SHACL’s SPARQL constraints allow shapes to reach through portals into neighbouring holons to validate inter-membrane coherence: “the target holon of every portal must have at least one interior triple,” “every city holon must trace a valid containment chain through province and country holons.”
Projection governance. Separate shapes for the projection layer enforce that external bindings meet interoperability requirements — every city projection must link to at least one recognised external authority, and that authority must be from an approved namespace.
Shape inheritance. The holarchic depth hierarchy maps naturally onto SHACL’s sh:node inheritance. A city shape inherits from a province shape which inherits from a base geographic holon shape. Each depth level adds constraints without repeating the parent’s.
The deepest point about SHACL in this model: when you think of a SHACL validation report as a membrane health report — listing holons with breached boundaries, degraded projections, and advisory weaknesses — the standard tooling becomes immediately interpretable in holonic terms. A violation is not just a data error; it is a structural integrity failure in a specific layer of a specific holon.
Part Twelve: When Holons Are Not the Answer
A model this rich in structure comes with a corresponding cost in complexity. It is worth being explicit about when that cost is not justified.
Flat, uniform datasets have no meaningful containment hierarchy, no boundary semantics, and no need for projection. A sensor reading, a log line, or a financial transaction record does not benefit from four layers of named graph infrastructure. Adding holonic structure to a time series is like building a Gothic cathedral to house a filing cabinet.
Simple controlled vocabularies are well served by SKOS. If skos:broader and skos:narrower capture everything you need — and for pure classification they usually do — holons are overkill. The moment you find yourself asking “what are the boundary rules for this SKOS concept?”, that is a signal that the vocabulary has grown into something genuinely holonic. Until that point, SKOS is leaner and better-supported.
Single-authority, single-resolution graphs — where everything is asserted by one agent, queried at one granularity, and never federated — do not benefit from the boundary membrane machinery. The overhead is real and the payoff is absent.
High-throughput transactional systems are not a good fit for RDF in general and for holons in particular. Event sourcing, IoT telemetry, and audit logs require write throughput that the per-holon named graph structure penalises. Purpose-built time-series stores handle these workloads better.
Teams without RDF fluency will struggle with the conceptual overhead. The holonic model requires understanding named graphs, IRI identity, boundary layers as first-class objects, and RDF 1.2 annotation syntax. If the consuming team thinks primarily in property graphs, the translation cost may outweigh the architectural benefits.
A domain probably warrants holons if it satisfies at least three of the following: entities exist at multiple scales and queries need to work at any of them; different parts of the graph have different provenance, authority, or confidence; navigation between levels is a first-class interaction; the graph will be federated across organisational boundaries; individual subgraphs need independent versioning or access control.
Part Thirteen: The Complete Picture
Let us revisit the four-graph model now that all its components are in view.
A holon is an entity in a knowledge graph that has four layers, each answering a distinct question:
Layer Question RDF mechanism Interior graph What is true inside this holon? Named graph, A-Box triples Shapes graph (boundary) What is allowed here, and how do you get in or out? SHACL shapes, portal definitions Projection graph What does this holon look like to the outside? External bindings, translated vocabulary Context graph What larger whole does this holon belong to? Structural membership, temporal annotations
Holons are stitched together by portals — first-class entities in the boundary layer that govern traversal between holons, carry transformation tensors when frames differ, and accumulate relational metadata via RDF 1.2 annotation.
The holarchy — the nested structure of holons within holons — gives the system multi-resolution querying, federated authority, and navigable structure that flat RDF cannot provide.
The IRI threading through all four layers is the persistent identity that makes every layer of the holon queryable as part of the same coherent entity.
And SHACL — executing in the boundary layer — is not merely a validation tool but the formal specification of the membrane itself, the thing that turns a named graph into a holon with genuine inside/outside distinction.
Afterword: Koestler’s Pattern in the Machine
There is something satisfying about the fact that a concept developed to describe biological and social systems in 1967 maps so cleanly onto the architectural requirements of knowledge graphs in 2026. Koestler’s insight was not about biology or sociology specifically — it was about organisation in general, about the irreducible reality of levels, about the way things are always both whole and part simultaneously.
RDF has always been theoretically capable of representing anything. What it has lacked is a principled architecture for representing structure — not just facts about things, but the organisational relationships that give facts their meaning, the boundaries that define what belongs where, the navigation mechanisms that connect levels of description.
The holonic model does not add new facts to a graph. It adds architecture — the inside/outside distinction, the layered description, the governed traversal. In doing so it turns a flat graph into something that behaves more like the systems it is meant to model: complex, multi-level, self-consistent at every scale, and navigable from any entry point.
That is what it means for a graph to be alive.
In Media Res,
If you like these articles, please consider becoming a paid subscriber. It helps me support my work so I can continue writing code, in-depth analyses, educational pieces, and more.
Check out my LinkedIn newsletter, The Cagle Report.
I am also currently seeking new projects or work opportunities. If anyone is looking for a CTO or Director-level AI/Ontologist, please get in touch with me through my Calendly:
If you want to shoot the breeze or have a cup of virtual coffee, I have a Calendly account at https://calendly.com/theCagleReport. I am available for consulting and full-time work as an ontologist, AI/Knowledge Graph guru, and coffee maker. Also, for those of you whom I have promised follow-up material, it’s coming; I’ve been dealing with health issues of late.
I’ve created a Ko-fi account for voluntary contributions, either one-time or ongoing, or you can subscribe directly to The Ontologist. If you value my articles, technical pieces, or general reflections on work in the 21st century, please consider contributing to support my work and allow me to continue writing.
Thanks Kurt. I am enjoying this series and your talk this morning.
I am curious about reification in this approach.
It seems that a single atomic triple is a holon itself and would be treated as such as an extension of this model. Some statements about the holon itself that might be otherwise handled through reification may be handled as statements about the holon itself (e.g. whether the triple is still true?), or about the parent holon that introduced the triple to the graph (e.g. where did the triple come from).
Then reification would be limited to statements about the relationship itself. (e.g. weight of relationship)
Appreciate your thoughts.
What a MOFO, Kurt (master of fabulous ontology)!