The W3C RDF 1.2 stack —RDF-Start, SHACL, SKOS, Prov-O, SPARQL, and ODRL— provides the necessary building blocks to create a graph-based version of holons. A holon itself is an entity that is also a system, based initially upon the work of Arthur Koestler in the 1960s with his work The Ghost in the Machine. A graph version of a holon contains a knowledge graph that describes the entities within given system, a context or event graph that describes the evolution of resources over time, a boundary graph that determines the constraints and rules acting upon the system as well as actions that the system can expose as interfaces when viewed as an entity, and one or more projections that effectively create maps of the system.
While holons have immediate applications with mapping and GIS systems, they are also instrumental in areas as diverse as supply chain management, decision support, narrative media structures, games and simulations and so on. They effectively utilise the graph as state machine, and can be used both in a static mode to describe the evolution of existing historical systems and as mechanisms for creating dynamic system, and they have strong relevance to grounding AI-based conversational and computational system.
The Holon Graph Community Group seeks to promote the development of holon envelope ontologies, architecture and usage. It will also seek to help developers build Holon-specific applications and coordinate meetings and other activities within this developing field. This group will publish Specifications.
w3c-cg/holonGroup's public email, repo and wiki activity over time
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Chairs, when logged in, may publish draft and final reports. Please see report requirements.
I have led group efforts before, but getting a specification group up and running (especially one as multipronged as the Holon CG) has proven to be a fascinating exercise in the art of herding cats.
First a quick overview about what exactly we’re trying to do. A few years ago, I asked myself a vexing question as an ontologist: Why were ontology projects so hard to accomplish well? This was related to a second question: How do we best get Generative AI to actually do precisely what we want it to do (see above comment on cats)? There was a third question also waiting in the wings: How do we build graph networks that people can use without knowing they are graph networks?
These don’t sound like it, but they are actually facets of the same question. I am also not the first person to ask these questions – they have all been sore spots for the semantics community for a while now. I remember a long conversation with ontologist Bobbin Teegarden several years ago over a Thai lunch, where the topic drifted toward holons and the difficulty of modelling them well. At the time, they were interesting curiosities, but I think we both sensed that semantics didn’t yet have the vocabulary to talk about them. It would take a decade and the advent of a whole suite of new standards – RDF-Star, SHACL, advances in SPARQL and so forth – for that to change.
What is a holon? A holon is an entity that is simultaneously a system. Holons can thus contain (and be contained by) other holons, but holons can also be connected to other holons. The Earth is a holon, and it’s tempting to see it as a container of entities – seas and continents, with each continent broken into countries, with each country broken into regions which contain cities that contain districts, which contain neighbourhoods, and so forth.
At the same time, however, the Earth can be seen as made up of atmospheric systems, magnetic systems, meteorological systems, hydrological systems, lithospheric systems, and so forth. Each model is correct as far as it goes, but the layers themselves are not completely self-contained: they connect across boundaries, and those boundaries, in turn, connect to other systems. Put another way, holons form a graph.
What is most crucial to understand about most systems, however, is that they are dynamic. They change over time. In general, from outside the system, you generally do not see what is happening within the system directly, but only see the projections of the interior state of the holon over its surface. We can’t, usually, see fault lines in bedrock directly, but we can see their shadows in seismograph recordings. The interior of the holon changes its state and can record that state, creating a history of that holon. There are constraints that also limit what the things within the system can do as the holon evolves.
The idea of graph-based holons would have remained a backwater academic concern if it hadn’t been for the rise of generative, neural net AI and transformer-based LLMs. Transformers are powerful tools, but even since their debut, it became more and more obvious that transformers also had a major Achilles heel – they could not tell when they didn’t know something, and consequently made things up. They hallucinated. They also couldn’t tell you anything about your organisation or domain if that information wasn’t in their training set. They could not tell you why they made the decisions that they did.
They still can’t, by the way; almost all the improvements in large language models over the last year have come from either performance optimisations or out-of-band memory systems (file systems, RAG, and so forth). This led to the rise of knowledge graphs as one form of read/write substrate layer, but even here it took a fair amount of experimentation to figure out how these could work together. Terms like control planes, harnesses, agentic systems, and MCPs became common in conversation, but so did knowledge graphs and context graphs. Arguments about what each of these things actually was became commonplace, as everyone had their own (usually wildly divergent) definition based primarily on their tool du jour.
That’s when a group of us decided it was time to standardise the terminology and identify what a good working definition for such a system should be. Holons became one such approach: a way to model each of these entities as systems, allowing various agents to move through them and gating actions that were impermissible or at least problematic. The W3C Holon Community Group held its inaugural meeting on 19 June 2026, with more than thirty people in the room.
That’s three months ago now, which caught me off guard when I sat down to write this – it hasn’t felt like three months, mostly because so much of it has gone into administrative scaffolding rather than anything visible from outside the group.
I seeded the group with my own initial recommendations; others have since begun contributing their own, and our intent with the HCG is ultimately to provide a common specification for holon-like interchange, structure, and to some extent architecture.
After that first meeting, things went quiet for a while as we did the necessary work of pulling together working group leads, determining focus, scope, and domain, and establishing procedure. We’re still not totally done there, but we’re getting much closer, and the meetings are increasingly focused on standardisation, IP and licensing, use case deployment, serialisation and harmonisation.
Last Thursday (10 September 2026) we had our second plenary session with all members in attendance, and started formally seeding the working groups. We will continue this mission for some time, and as we can we will be making our workings public. Our groups include the following:
Core Holon Architecture. Works out the ontology needed to describe holons formally – what a holon is, what properties it can carry, and what has to stay invariant across different representations of the same one.
Networking. Looks at how holons hosted in different systems discover, connect to, and exchange state with one another across a shared federated network – and how that same architecture doubles as a grounding layer for AI agents that need to move through it.
Serialisation and Messaging. Focuses on the DataBook standard – the Markdown+YAML data documents that are, in effect, the HTML of Holons – along with the messaging and parsing conventions that let holons travel between systems intact.
Identity. Handles authentication, user profiles, agents, access control, and the clients through which users and agents actually interact with the holon network.
Industry Utilisation. Translates the architecture into practical guidance for specific industries, and builds the bridge between the standards work and actual deployments in the field.
IP and Licensing. Works out what’s public and what’s protected, and under what terms – unglamorous, but it determines whether any of this is usable outside the group.
Harmonisation. Makes sure holons work well alongside existing standards and ontologies rather than duplicating or fragmenting them.
In addition we have a couple of administrators who do the hard and necessary work of keeping the organisation going.
We are planning for our next open plenary meeting in early October – I’ll post the day and time, and will be regularly posting what we have accomplished week to week on both the community blog and my newsletter The Cagle Report. We look forward to seeing you there.
This Thursday, September 10, the W3C Holon Community Group is holding its next general meeting — and it’s open to anyone curious about where knowledge graphs and AI-native infrastructure are headed.
It’s been a little over two months since our inaugural meeting in June, and the four working groups that came out of it have been doing real work since: 🔹 Core — The foundation of what constitutes a holon, terminology, schema, ontology specification. 🔹 Identity — Establishes user identity, access control, personalisation, and agent management 🔹 Network Architecture / API & Control-Plane — the control-plane layer connecting AI systems to graph infrastructure 🔹 DataBook — a self-describing, Markdown-native data format, now in active dialogue with an independently-developed peer format (Open Knowledge Format) 🔹 Industry Utilisation — outreach and adoption, including outside organizations already exploring holon-adjacent ideas on their own 🔹 Harmonization — keeping ontology drift and cross-group consistency in check as several groups develop vocabulary in parallel
Thursday’s meeting will cover what each group has been up to since June — a good entry point whether you want to get actively involved or just want to follow along with holons, control planes, Markdown-native data formats, and distributed, time-centric knowledge graphs. 📅 Thursday, September 10, 2026 — 7 AM PDT
2nd W3C Holon Community Group General Meeting Thursday, September 10 · 7:00 – 9:00am Time zone: America/Los_Angeles Google Meet joining info Video call link: https://lnkd.in/gvANgFfH
To make it easy to capture who wants to contribute what, we have prepared a short participation form at the link below. We ask you to fill this out in the coming days so that we can synthesize the information and share at the July 3rd meeting.
Your name, background, and organisational affiliation (if any)
Whether you are interested in a co-chair, admin, editor or working group lead role
What you are hoping to get out of the CG and the respective working groups
Any reference implementations or prior work you would like to contribute
Feedback on the overall charter or approach
A page for each of the currently proposed working groups*, asking for both:
Your interest in a role as Working Team Lead, Heavy Participant or Light Participant
Your broad input and feedback on anything from scope, reference projects, concerns, challenges, questions, interactions with other groups and beyond. We hope for this to be an efficient way to gather thinking at the onset to shape the groups.
Any final input, or input on the “What do we call a tracked entity” question
* Note that within the survey, you will see that the Working Group names and descriptions are represented as the list below, representing some evolution even since the “After the Inaugural: What Comes Next” post was shared on Jun 19. We welcome feedback and questions within the form and/or through this email thread.
At the 3 July meeting, we will share our final proposed structure, discuss any evolutions and hope to formally approve these working groups and their initial chairs.
Current Proposed Structure for Working Groups:
I. Core Architecture
Define the canonical holon model, vocabulary, and reference patterns across implementations
Includes holon model, named graph containers, boundary semantics, the scene/event graph partition structure
II. DataBook Standard
Markdown-based substrate for holon grounding, provenance, and LLM integration
Establish the databook format specification – metadata conventions, code block patterns, and exchange protocols
Posted 19 June 2026 — Kurt Cagle, Acting Chair, W3C Holon Community Group
Thank you to everyone who joined us this morning for the inaugural meeting of the W3C Holon Community Group. Thirty-plus people showing up at 7am Pacific on a public holiday — and staying engaged for nearly two hours — is a strong signal that this work matters to a lot of people across a lot of domains. The conversation in the chat channel alone was remarkable: category theory, biomedical graphs, scene description formats, and active inference all appearing within the first half hour. This is the room we wanted.
The meeting recording, presentation deck, agenda, and transcript are available at the community GitHub repository:
We encourage anyone who missed the session, or who wants to share it with colleagues, to link there directly.
A Terminology Question: What Do We Call a Tracked Entity?
One thread that surfaced clearly during the meeting — in both the presentation and the chat — is that the term agent is badly overloaded and may not serve us well going forward.
It carries at least three incompatible meanings in the communities this group spans: the classical AI / rational-agent sense; the AI tooling sense (autonomous LLM stacks, “agentic” pipelines); and domain-specific senses in biomedical contexts where an agent may be a protein, a peptide, a molecule, or a cell. Using the same word for a tracked entity inside a holon invites confusion from the start.
Several alternatives were raised or suggested:
Participant — neutral, implies being part of a context, but perhaps too passive
Character — maps well to game, media, and narrative theory uses; a character has identity, state, and trajectory through a world. The concern raised is that it skews too strongly toward the entertainment domain.
Actor — has distributed systems baggage (the actor model) as well as theatrical connotations
Subject — perhaps the most promising candidate. In RDF, subject already occupies a precise structural role (the S in an SPO triple). In linguistics and philosophy, a subject is the entity around which predication and action organise. It scales from proteins to player characters to legal persons without strain, and it carries no AI-agent connotations. One caveat worth noting: in medical and legal contexts, “subject” can imply a human under observation or study, with associated ethical weight (research subjects, GDPR data subjects), so we will want to examine how it lands in biomedical and regulatory domains.
This is an open question, not a decision. We will raise it formally at the next meeting on 3 July, but we would very much like to hear your thinking beforehand. Please post to the mailing list at public-cg-holon@w3.org with your candidate and your reasoning — especially if you bring a domain perspective (biomedical, legal, geospatial, gaming, supply chain) that these candidates handle well or handle badly.
Good terminology, established early, saves a great deal of rework later.
Working Groups: Formalising Structure
At the inaugural meeting we proposed the following initial working groups:
I. Core Architecture — holon model, named graph containers, boundary semantics, the scene/event graph partition structure
II. DataBook Standard — the Markdown-based substrate for holon grounding, provenance, and LLM integration
V. Industry Utilisation — domain application patterns across healthcare, media, supply chain, finance, education
VI. Ontology & Heterarchical Alignment — alignment with BFO, UFO, DSRP, and related foundational frameworks
At the 3 July meeting we will be formally approving these working groups and their initial chairs. If you are interested in leading or co-chairing any of these groups, we want to hear from you.
Interest and Participation Form — Coming Shortly
To make it easy to capture who wants to contribute what, we are preparing a short participation form that will ask for:
Your name, background, and organisational affiliation (if any)
Which working groups you want to participate in
Whether you are interested in a chair or editor role
What you are hoping to get out of the CG and the respective working groups
Any reference implementations or prior work you would like to contribute
Watch the mailing list for the link — it will go out before the end of next week, well ahead of the July 3rd meeting, so we can arrive there with a clearer picture of who is doing what.
Next Meeting
Date: Friday, 3 July 2026 Time: 7:00–8:00am Pacific / 10:00–11:00am Eastern / 15:00–16:00 BST Agenda: Will be distributed to the mailing list no later than 48 hours prior.
Agenda items for the July 3rd session are welcome now. If you have something you want to present, demonstrate, or raise for discussion, please send it to the mailing list or contact me directly at kurt.cagle@gmail.com.
Kurt Cagle is a consulting ontologist, knowledge graph architect, and technical author. He serves as Acting Chair of the W3C Holon Community Group and publishes The Ontologist and The Inference Engineer on Substack. Copyright 2026 Kurt Cagle.
The W3C RDF 1.2 stack —RDF-Start, SHACL, SKOS, Prov-O, SPARQL, and ODRL— provides the necessary building blocks to create a graph-based version of holons. A holon itself is an entity that is also a system, based initially upon the work of Arthur Koestler in the 1960s with his work The Ghost in the Machine. A graph version of a holon contains a knowledge graph that describes the entities within given system, a context or event graph that describes the evolution of resources over time, a boundary graph that determines the constraints and rules acting upon the system as well as actions that the system can expose as interfaces when viewed as an entity, and one or more projections that effectively create maps of the system.
While holons have immediate applications with mapping and GIS systems, they are also instrumental in areas as diverse as supply chain management, decision support, narrative media structures, games and simulations and so on. They effectively utilise the graph as state machine, and can be used both in a static mode to describe the evolution of existing historical systems and as mechanisms for creating dynamic system, and they have strong relevance to grounding AI-based conversational and computational system.
The Holon Graph Community Group seeks to promote the development of holon envelope ontologies, architecture and usage. It will also seek to help developers build Holon-specific applications and coordinate meetings and other activities within this developing field. This group will publish Specifications.
This is a community initiative. This group was originally proposed on 2026-06-01 by
Kurt Cagle. The following people supported its creation: Kurt Cagle, Stephane Fellah, Joerg Baach, Yousef Hooshmand, Mathias Vanden Auweele, Brandon Dorman, Mike Topalovich, Jonathon Storm, Zac Ruiz, Scott Carroll, Dan Everett, Bo Lora, Sobha M and Michael Ellerbeck.
W3C’s hosting of this group does not imply endorsement of the activities.
w3c-cg/holon
