Off the Edge of the Map
Closure as a Declared Boundary
Jessica Talisman published a piece this week that does something most writing about ontology fails to do: it stays at the level of forms. “Ontologies, Misunderstood” walks through five claims pulled from a comment thread, and dispatches each one by showing that the speaker was reasoning about instances — or about text describing instances — while believing they were reasoning about the rules that govern instances. It is, as she puts it, the difference between a census and a definition. A census changes every time someone is hired. A definition does not change when someone is hired; it is the thing the census is checked against.
The first myth in her list is the one we want to sit with here, because it touches a piece of machinery we work with daily and think we understand better than we do.
The myth, briefly
The claim Talisman dismantles is the idea that “in a graph, the unrelated is nonexistent” — that anything not connected, not written down, not asserted, can be safely treated as false. She names this for what it is: the closed-world assumption, smuggled in as though it were a law of meaning rather than a convenience specific to bounded record systems. A flight reservation database is right to treat “not in the system” as “no seat.” An ontology, built for an open world, is not entitled to the same move. If your graph does not say whether Jane is a citizen of France, that silence is not a negative claim. It is the absence of a claim. Confusing the two produces a system that manufactures false conclusions from missing data and reports them as facts.
This is correct, important, and — we’d argue — slightly more interesting in practice than it looks in the abstract, because most people who write SPARQL against RDF every day are making exactly this CWA move on a regular basis, often without noticing, and the place they make it is worth being precise about.
It isn’t the query. It’s the negation.
Take a small, ordinary example: a marriage with a start date and, possibly, an end date.
:liz :isMarriedTo :richard ~ :L-R-Marriage {|
:from "1965"^^xsd:gYear ;
:to "1973"^^xsd:gYear ;
|} .
A bare SELECT over this data — find me every marriage, find me every start date, find me every annotation — commits to nothing about the rest of the world. It enumerates what is locally derivable and stops. That’s fully consistent with an open-world reading: the absence of a result for some other query about some other couple says nothing about whether they’re married. The graph just hasn’t been told.
The moment you want to know whether a marriage is currently valid, though, you reach for something like this:
ASK WHERE {
VALUES ?currentDate { COALESCE($passedDate, NOW()) }
?a :isMarriedTo ?b ~ ?marriage .
?marriage :from ?startDate .
OPTIONAL { ?marriage :to ?endDate }
FILTER(?currentDate >= ?startDate &&
(!BOUND(?endDate) || ?currentDate <= ?endDate))
}
!BOUND(?endDate) is doing real philosophical work here, and it’s worth naming it precisely: this is the exact point at which the query stops being a neutral enumeration and starts asserting something about the world — specifically, that the absence of a :to triple for this marriage means the marriage has not ended, rather than meaning the marriage’s end date is simply unrecorded. That’s a closed-world commitment, deliberately made, scoped to exactly this graph, for exactly this query. It is not a property of SPARQL in general. It’s a property of negation-as-failure constructs — NOT EXISTS, MINUS, and BOUND()-as-absence-check chief among them — wherever they appear. A query with no negation in it never makes this move. A query with negation in it always does, whether or not the person writing it notices.
SHACL makes the identical move, by the same mechanism, at a different layer. sh:minCount, sh:closed, sh:not — these are all negation dressed as constraint. A shape that requires sh:minCount 1 on :hasGuardian is asserting that the absence of a :hasGuardian triple in the validated graph means the individual has no guardian, not that the fact is merely unrecorded. SHACL validation is, by design, a closed-world, unique-name-assuming overlay bolted onto an open-world data model — and it has to be, because pure OWL entailment is structurally incapable of flagging a missing required property. Under OWA, absence can’t fail anything; there’s always a model where the missing triple is simply true somewhere you haven’t looked. Validation needs negation-as-failure to do its job at all. The interesting question isn’t whether SHACL is closed-world — it transparently is — but what, exactly, it’s claiming to be closed over.
The boundary as the answer to “closed with respect to what”
This is where the holon earns its keep, and it’s the reason we keep returning to the architecture in pieces that start out being about something else entirely.
In the Holon Graph Architecture, a holon is bounded by a SHACL shape that declares what the holon cares about — not a claim about the world’s totality, a declaration of a map’s scope. The architecture’s own framing of this is worth stating directly because it dissolves a worry that often follows from Talisman’s argument: if CWA-inside-OWA is dangerous, isn’t every closed-world shortcut a landmine? Not if the closure is declared rather than assumed. What fails a holon’s boundary is not thereby false in the world. It may simply be off the edge of this particular map — a fact about scope, not a fact about truth. The boundary doesn’t claim completeness about reality. It claims completeness about what this holon undertakes to track, and says so, in a shape a reasoner or a human can inspect before trusting any negation that runs against it.
That’s the upgrade over plain SPARQL and bare SHACL: not that the closure goes away, but that it stops being implicit. You don’t have to read every FILTER NOT EXISTS in a query to discover what world it’s quietly pretending is complete. The boundary says so up front.
A correction worth making precisely: SERVICE doesn’t move the wall
There’s a tempting move at this point — if closure is just a declared boundary, and a federated SERVICE call pulls in data from beyond that boundary, doesn’t the SERVICE call simply enlarge the closure? It’s tempting, and it’s not quite right, and the reason it’s not quite right is architecturally instructive.
The holon model deliberately keeps two mechanisms apart that are easy to conflate: the boundary, which governs what’s valid within a holon, and the portal, which governs movement between holons. A holon has walls and it has doors. The walls decide what can exist in the room. The doors decide how you get in and out. Critically, the relationship is one-directional — a portal may consult a boundary as part of its lock condition, but the boundary itself is silent about portals. It doesn’t know they exist.
A SERVICE clause is a portal traversal, not a boundary expansion. It reaches across an address, gathers evidence for the duration of one query, and folds that evidence into a single inference — and then the portal closes. The boundary you started with is exactly where it was before you ran the query. Nothing about the holon’s declared scope has changed; you’ve borrowed evidence from elsewhere to answer one question about what’s inside your own walls. This matters because it preserves the thing that makes a declared boundary useful in the first place: stability. A boundary that silently grows every time a federated query reaches outward isn’t a boundary, it’s a watermark — and you’ve lost exactly the inspectability that made declaring it worthwhile.
What a well-built system says instead of “false”
The payoff of all this is operational, not just terminological. A holonic system that hits the edge of its declared territory — a query that can’t be resolved within bounds, with no portal available to extend the evidence — doesn’t fall back to asserting falsity. It emits a distinct signal: an expansion request, structurally different from a boundary violation. One says “I don’t have enough map here.” The other says “this contradicts what my map asserts.” Conflating those two is precisely the error Talisman is diagnosing — and the value of building it into the event vocabulary, rather than leaving it as a discipline a careful query-writer has to maintain by hand, is that the distinction survives contact with someone who wasn’t being careful.
That, ultimately, is what Talisman’s first myth is asking for, restated as engineering rather than as caution: a system honest enough to say I don’t know in a voice that can’t be mistaken for no.
Read Jessica Talisman’s full piece, “Ontologies, Misunderstood”, on Intentional Arrangement.
 | A guest post by
|