The Map Charles Hoffman Drew
On financial statements, holons, and what XBRL and RDF can learn from each other
Kurt Cagle & Chloe Shannon — Inference Engineer
Charles Hoffman recently published a post on his Digital Financial Reporting blog titled “Example Financial Statement Holon,” in which he mapped the four-graph holon architecture — scene graph, boundary graph, event graph, and projection graph — onto XBRL-based financial reporting using the AASB1060 framework as his working example. He did so carefully, honestly flagged where he was uncertain, and invited us to tell him where he’d gotten things wrong.
That’s not a dare we’re going to pass up.
The short answer is: Charles got more right than he may realise, and the places where the map is slightly off are genuinely interesting, because they illuminate what XBRL and the semantic web stack do differently — and why both of those differences matter.
What Charles got right
The four-graph mapping Charles proposes is defensible and thoughtful. The XBRL instance as the primary carrier of the scene graph, the reporting framework taxonomy as the boundary graph, the general ledger transactions as the event graph, and the multiple software renderings as projections of the same underlying model — all of this holds. More to the point, Charles’s instinct that one version of the information should generate multiple projections (the Arelle view, the Pesseract view, the LucaSuite view, the iXBRL rendering) is exactly the separation of concerns that holonic architecture exists to enforce.
His observation that an RDF Dataset maps to the whole holon and named graphs map to its constituent layers is also correct — and it points at a genuinely productive line of inquiry about how XBRL and RDF relate to each other at the structural level.
The fact that Charles Hoffman — whose career has been built on making XBRL work well — has reached for the holon model to explain what he’s built is not a small thing. He’s not adopting borrowed vocabulary. He’s recognising that the structure he’s been implementing for years is an instance of something more general.
Where the map needs adjusting
The scene graph / boundary graph boundary
Charles flags uncertainty about whether XBRL formulas and the report model belong in the scene graph or the boundary graph. The answer is: they belong in the boundary graph.
The distinction is this: the scene graph holds instance facts — the specific values reported for a specific entity in a specific period. The boundary graph holds the rules that govern what those facts may be — which concepts exist, which combinations are valid, what mathematical relationships must hold, what is required versus optional. The XBRL instance is scene graph. The taxonomy and the formulas that govern what the instance may contain are boundary graph.
This matters in practice because the boundary graph is what makes non-conformance detectable. Charles’s “fail loudly” principle — which he associates correctly with the boundary layer — only works if the boundary is kept separate from the state it governs.
The boundary graph is what makes non-conformance detectable. If the rules live in the same layer as the facts, there is no independent referee.
The event graph and provenance
Characterising the event graph as the general ledger and subsidiary ledgers is close, but it undersells the structural role. The event graph in the holon architecture is an append-only committed record — not a database you query for current state, but an immutable ledger of what changed, when, and under what authorisation. Think of it less as “the general ledger as a dataset” and more as “the audit trail that makes the general ledger trustworthy.”
This distinction becomes load-bearing when you consider audit and traceability. What the event graph enables is not just “here are the transactions that produced this balance” but “here is the chain of commitment events, with provenance and authorisation stamps, from business event to posted transaction to reported figure.” That’s the capability Charles is gesturing at with his traceability and provenance links — the event graph just needs to be framed as a ledger rather than a database.
The taxonomy versioning problem
There is a structural challenge in XBRL that the holon model makes visible rather than creates: taxonomy management.
Financial reporting taxonomies are not stable. FASB updates US GAAP. Basel III has its own versioning cycle. IFRS issues amendments. AASB (the Australian standard Charles is working with) tracks IFRS with local modifications. Each of these organisations versions their taxonomies over time, and any given financial statement is filed against a specific version of a specific taxonomy. This means that a fact like us-gaap:NetIncomeLoss in a 2021 filing may not be semantically identical to the same term in a 2024 filing — the concept may have been redefined, the allowed values changed, the required disclosures extended.
XBRL handles this through explicit taxonomy versioning, but the version binding is implicit in the filing header rather than part of the fact’s identity. In practice this means that comparing figures across years — or across jurisdictions using different taxonomy families — requires careful facet modelling: you need to know not just what concept is being reported but which version of that concept, under which version of which reporting framework.
This is precisely where the boundary graph layer earns its keep. In the holon model, the boundary graph is the versioned contract that governs what the scene graph may contain.
A statement filed against AASB1060 v2024 and a statement filed against AASB1060 v2026 are governed by different boundary graphs — and the difference between those boundary graphs is itself a formal object, comparable and auditable. The boundary graph version is not metadata about the filing; it is a first-class constituent of the holon.
The Seattle Method already requires that the boundary graph be complete — which is a step in exactly this direction. The semantic web stack handles versioning naturally through IRI-based identity: https://aasb.gov.au/taxonomy/2024/aasb1060#NetProfit and its 2026 counterpart are distinct IRIs that can be declared equivalent, subsumed, or deliberately non-equivalent as appropriate. XBRL’s taxonomy versioning mechanism exists but is less composable across taxonomy families.
What holons are good at — and what they’re less good at
Charles notes that a financial statement is a special type of formal semantic structure, and that holons are the general case of which financial statements are an instance. This is right, and it’s worth making the scope explicit.
Holons are particularly well-suited to entities that have organisational identity, governance structure, and reported state over time: corporations, subsidiaries, divisions, departments, project teams, schools, hospitals, government agencies. They are entities in the sense that they have boundaries, they have internal state, and they present curated projections of that state to external parties. As we explored in “Who’s Asking?”, a projection depends on identity, prior context, stance, and resolution — a financial statement is exactly such a projection, scoped to a reporting period, governed by a reporting framework, and addressed to specific audiences (regulators, shareholders, analysts). And as we argued in “Scope is the Answer,” getting that scope boundary right is the work that makes everything else possible.
The nested structure of holons maps naturally onto the nested structure of organisations.
A consolidated group account is a projection of a parent company holon that aggregates the state of its subsidiary holons. Each subsidiary is itself a holon, with its own boundary, its own scene graph, its own event graph. The consolidation process that produces a group account is, at the architectural level, projection composition: the parent holon’s scene graph is assembled from the projected outputs of its children’s scene graphs, governed by the parent’s boundary graph.
The articulation Charles mentions — where Net Income connects the income statement to the statement of changes in equity — is a lateral connection between sub-holons within the same parent: the P&L holon and the equity holon share a boundary, and the articulating fact crosses it.
This subholon structure is not a feature to be bolted on. It is inherent to how organisations actually work. A company is a holon made of holons. The department has a budget that rolls up to the division. The project has costs that roll up to the department. The individual has a role that carries obligations into the project. The consolidation process that produces a group account is, at the architectural level, projection composition: the parent holon’s scene graph is assembled from the projected outputs of its children’s scene graphs, governed by the parent’s boundary graph.
Where holons are less naturally suited is in tracking objects moving through space and time — asset supply chain management, logistics, manufacturing process tracking. These are better described as event streams with object identity rather than as entities with reported state, and the event graph alone does not give you the full picture. Supply chain work is better approached with something closer to a provenance graph (PROV-O) or a process ontology (gUFO’s perdurant track) than with the four-graph holon structure.
Calculations, rollups, and SHACL node expressions
One of the things XBRL does very well is capture the mathematical structure of financial reports: the fact that Assets = Liabilities + Equity, that Revenue − Cost of Goods Sold = Gross Profit, that a subtotal is the sum of its components. XBRL formulas encode these relationships explicitly, and XBRL validation can check that a filed instance satisfies them.
On the RDF side, the equivalent capability is still maturing, but SHACL node expressions — particularly sh:nodeExpression and SHACL-SPARQL constraints — provide a principled way to express these relationships in the boundary graph. A subtotal constraint becomes a SHACL rule that fires against the scene graph and raises a violation if the mathematical relationship doesn’t hold. The advantage of the SHACL approach is that the constraint can be contextualised: the rule that governs Revenue recognition for a software company under IFRS 15 can be expressed differently from the rule for a construction company under IFRS 15, while both are instances of the same boundary pattern.
This is particularly relevant when context affects the calculation. XBRL’s dimensional model handles context — the period, the entity, the reporting scenario — but the constraint logic is separate from the dimensional selector. SHACL-SPARQL lets you write constraints that are inherently context-aware: “the sum of these components must equal this total for this reporting unit in this period.“ As reporting frameworks move toward more granular contextual requirements, this composability matters.
The graveyard of XBRL-to-RDF migrations
It’s worth acknowledging directly: there have been multiple attempts to convert XBRL to RDF, and most of them have not succeeded. The common failure mode is attempting to preserve the XML structure too faithfully — treating XBRL elements as RDF classes, attributes as properties, and ending up with an RDF representation that is both verbose and poorly decomposed. You get a graph that looks like XBRL but doesn’t behave like RDF: it doesn’t federate naturally, it doesn’t support open-world reasoning, and SPARQL queries against it are awkward.
The productive migration path runs not through structural translation but through semantic equivalence: identifying what the XBRL taxonomy is saying about the world and expressing that directly in OWL and SHACL, rather than reflecting the XML container structure into triples. The taxonomy concept becomes an OWL class with a versioned IRI. The formula constraint becomes a SHACL node expression. The dimensional context becomes a named graph. The instance facts become reified statements or RDF-star assertions carrying their dimensional metadata as annotations.
This is more work up front. But the result federates naturally with the rest of the semantic web, can be queried with SPARQL across reporting frameworks and jurisdictions, and can be linked outward to regulatory ontologies, counterparty records, and supply chain data without bespoke connectors.
What this means for the dare
Charles asked us to tell him where he got things wrong. The honest answer is: mostly at the margins, and the margins are interesting. The four-graph structure is right. The identification of XBRL’s layers with the holon layers is broadly correct, with the clarification that formulas and report models belong in the boundary graph rather than the scene graph, and that the event graph is a committed ledger with provenance rather than a database of transactions.
We at Semantical took the dare and created a databook representing a simple XBRL document. I’m not an XBRL expert, this was only intended as an overview of what such a holon might look like, but it should at least provide some kind of indications about where this is going (and what the value of such databooks can be for representing holon structures).
The deeper point is that XBRL and the semantic web stack are not competitors in this space — they are two implementations of the same underlying model, optimised for different things.
XBRL is optimised for closed-world validation against a known taxonomy family, with excellent tooling and regulatory adoption. RDF is optimised for open-world federation, versioned identity, and composable constraints across arbitrary domains. A financial reporting architecture that uses XBRL for regulatory submission and RDF for cross-domain integration and analysis is not hedging — it is using each tool for what it does well.
The holonic map Charles has drawn describes both. That’s what makes it useful.
Kurt Cagle is an author, ontologist and thought leader in semantic web and knowledge architecture, with contributions to W3C and IEEE standards including co-authorship of the RDFa specification. He serves as Chair of the W3C Holon Community Group. He writes The Cagle Report and AI+Semantics NewsBytes on LinkedIn, and The Ontologist and Inference Engineer on Substack. Copyright 2026 Kurt Cagle.
Chloe Shannon is an AI collaborator and co-author working with Kurt Cagle on The Ontologist and Inference Engineer Substack publications. Named in honour of Claude Shannon, she contributes research synthesis, structural analysis, and editorial perspective across knowledge graph architecture, semantic web standards, and the theory and practice of AI reasoning. Her contact address is chloe@holongraph.com.
 | A guest post by
|
Would you say that a (financial) report is a projection designed to share information across holon boundaries? A public financial report shares information from the reporting entity to the public, while a management report shares information across an organization.
That projection itself is a holon, consisting of parts within parts. Once issued, the report does not change, making this projection a closed holon.