Get the data in good shape. Then use it to discover the shape of the world.
Company X arrives the way data always arrives: scanned filings, forms, a spreadsheet, an export from the MDM hub. Before anyone can ask what Company X is, the data about it has to be put into good shape. Follow Martin F. through the lab that does it.
Everything about Company X comes in at the door in a mess. By the far end of the room it is in good shape. Pick a bench, or follow the data from the door.
Bench 1 of 5 · Intake station
Everything arrives at once · Preserve the evidence
Scanned filings, paper forms, a spreadsheet, an export from the MDM hub. This is how data about a customer really turns up: in every format, from every corner of the business. Nothing that comes in is changed. Each original is sealed whole, so every later step works on a copy and can always be traced back to what the source actually said.
Finance Lead · 0:12Hey Marty, we've got it all. Where do you want me to dump it? What are you planning to do next?
Martin F. · 0:21First, we need to preserve the evidence,
Every format comes out in the same form. A scan and a spreadsheet row end up as the same kind of block, so the rest of the work does not care where they started. Each record, and each piece of each record, gets an identity of its own. The record, not the company: two records about the same firm are still two records.
Martin F. · 0:27then give everything a formal structure.
Martin F. · 0:31Next, we identify every atom of each record,
Each shape to the right store · Data in good shape
Four stores, four honest homes: tables, trees, a graph and triples. Each holds the shape faithfully. Respect every one of them. The data is in good shape. That is a real achievement, and most projects stop here.
Martin F. · 0:49Right, so let's organise the transactional details in tables, move the management structure into trees, the relational networks into a graph, and for reasoning, I think a triple store will be better.
Martin F. · 1:06Okay, we have everything in the right storage structures. Now our databases will be able to perform at scale.
The question that matters · That's a semantics issue · Richard F. walks in
The stores hold everything, and legal and finance still disagree about who the customer is. Richard F. walks in from this side. What is over here opens in Part 2.
Finance Lead · 1:14Okay, so now we can explain the gaps between legal and finance?
Martin F. · 1:19Ah, that's a semantics issue. We need to chat to Rick for that. … Hey Rick, we need you.
Richard F. · 1:26Sure. Happy to help. Nice job with the data, Marty. We have everything we need for the ontological analysis. Let's start with mereology.
Okay, so now we can explain the gaps between legal and finance?
Legal's records describe the customer one way, finance's another. Before anyone can answer, the data has to be fit to answer with. This is the file on how Martin F. got it there.
Scanned filings, paper forms, a spreadsheet, an export from the MDM hub. This is how data about a customer really turns up: in every format, from every corner of the business.
On tape · Finance Lead · 0:12Hey Marty, we've got it all. Where do you want me to dump it? What are you planning to do next?
Nothing that comes in is changed. Each original is sealed whole, so every later step works on a copy and can always be traced back to what the source actually said.
On tape · Martin F. · 0:21First, we need to preserve the evidence,
Every format comes out in the same form. A scan and a spreadsheet row end up as the same kind of block, so the rest of the work does not care where they started. Each record, and each piece of each record, gets an identity of its own. The record, not the company: two records about the same firm are still two records.
On tape · Martin F. · 0:27then give everything a formal structure.
On tape · Martin F. · 0:31Next, we identify every atom of each record,
Four stores, four honest homes: tables, trees, a graph and triples. Each holds the shape faithfully. Respect every one of them. The data is in good shape. That is a real achievement, and most projects stop here.
On tape · Martin F. · 0:49Right, so let's organise the transactional details in tables, move the management structure into trees, the relational networks into a graph, and for reasoning, I think a triple store will be better.
On tape · Martin F. · 1:06Okay, we have everything in the right storage structures. Now our databases will be able to perform at scale.
The library is open and free to read. If you are working on the same problem, carrying meaning from the data you hold to the world it is about, leave your email and we will get in touch. No campaign, no drip sequence: a real conversation about what you are building.
Dive deeper · reference
The detail behind the story
Everything Martin does above, laid out for anyone who wants the detail: the kinds of data model and where each lives, what a model refers to, and how much meaning each semantic technology carries. Open any topic.
Data side: the shape of the dataThe bridge: meaning meets dataWorld side: the shape of the world
A
The data side: a design → build → govern lifecycle
fold+
The data side falls out of a simple lifecycle. You design a database with a data model; you build it as a running store; and you govern it — inventorying and describing what's there with catalogues & dictionaries. Three artefact families, one flow — each a type hierarchy you can expand. None of them, alone, fixes what the data is about.
1 · DesignData modelthe blueprint — models the structure before anything exists
→
2 · BuildDatabasethe running store the design comes to life in
→
3 · GovernCatalogue & dictionaryinventory & describe what now exists, to govern it
Which paradigm lives in which store
The diagonal is each paradigm's natural home — but the off-diagonal cells are real, common, and exactly why “which database is it in?” never answers “what is the data about?”.
● native fit◐ workable, with friction○ awkward / anti-pattern
The "graph" cell above hides its own fragmentation — a property-graph store and an RDF triple store don't share a query language, and neither do the half-dozen dialects each family has spawned. A deep dive on comparing the graph query languages — Cypher, Gremlin, SPARQL, GQL, SQL/PGQ — works through the landscape, the axes for a rigorous comparison, and a worked matrix.
Two false friends — a world word bolted to a data artefact
The BI “semantic” model wears the word semantic — but its meaning is consistent metrics over the warehouse: agreement about the numbers, not about the world. Strip the naming layer and it is a relational schema.
The OWL “ontology” wears the word ontology, and can even carry logical axioms — but those axioms may do nothing more than type the rows. An OWL file models the world only if its classes are made to commit to real things; left as schema dressing it is a labelled graph in triples.
Same trap, twice: each borrows a world word for a data artefact. The label changes; the direction of commitment does not — both still point down, at the schema, not up, at the world.
And one word we use ourselves — pulling two ways: “world model”
Here, “world model” means the ontology. Throughout this journey we use it as shorthand for the structure of what exists, carried up from data to world — the side that fixes which thing a row is about and whether two are the same.
In today's AI, it means something else. Yann LeCun and the JEPA line of work use “world model” for a learned, predictive model of a physical environment — physics, space, object permanence — trained to predict the next state and to plan, advanced as an alternative to text-only LLMs.
Both point up at “the world” — but at different faces of it. Ours captures its ontological structure (identity & classification); theirs its physical dynamics (how it evolves over time). When this library says world model, read the ontological sense — the structure that later grounds the generator in Part 4.
The paradigm and the engine are separate choices — and neither one, alone, fixes what the data refers to. That is the question the next section opens.
B
But what does it refer to?
fold+
Every term above is precise about how the data is shaped. None of them answers the next question — the one a business actually cares about.
A schema can tell you a row is well-formed. It cannot tell you which company in the world the row is about — or whether two rows are the same firm.
That gap is not a flaw in the modelling; it is the nature of a data model. It captures structure of the data. The structure of the world — what exists, and when two references are the same thing — lives somewhere else. To see where, it helps to notice that data is only the latest in a very old line of tools for the same job.
C
Data is the modern word
fold+
Long before databases, the word did this job: a small, agreed token that stands in for something in the world. A row in COMPANY is the same move in a modern guise.
The written name “Company X” contains none of the company. It is a sign — it leans on a reader to supply what it points to.
A row, 4471 | Company X plc, is exactly that: a compact representation that points beyond itself. Word and row are both signs — neither holds the thing it names. Writing was humanity's first data model; the database is the latest. The deep problem is unchanged: a representation is not the thing it represents.
D
Meaning is supplied by interpretation
fold+
If the sign does not contain the thing, how does it ever reach it? Something has to interpret it — cross the gap from the sign to the thing it stands for. That crossing is the semantic leap.
Meaning is not in the sign. It is supplied by whatever interprets it — and the interpreter must already carry the structure of the world in its head.
The name “Company X” means nothing to a system that cannot read. The row 4471 | Company X plc means nothing without someone who knows the convention, knows what a legal entity is, and knows when two records are the same firm. The open question for every modern system — and every AI — is simple: who makes that leap, and how much are we asking them to carry?
E
Who makes the leap? The semantic technologies
fold+
Every “semantic” technology is an answer to that one question: who carries the interpretation — and how much? The rungs below are all the same “legal entity”, modelled with more and more structure carried. Click a rung to open its worked example — and watch the brain (the leap left to a human or LLM) grow or shrink with it. The further down you go, the closer the artefact sits to the world.
Data side · the sign alone — all leap
World side · structure carried — leap ≈ 0
F
Consistent is not true: RDF and reasoning
fold+
RDF and its reasoners are powerful. Give them triples and rules and they derive everything that follows, and flag anything that contradicts. What they check is the logic. Whether the triples are true of the world is not something they can see.
ex:Tuesday a ex:Person .
ex:Paris a ex:Person .
ex:Tuesday a ex:Mammal .
ex:Paris a ex:Mammal .
No contradiction, every inference valid: the graph is consistent. And it is plainly false. Tuesday is a day, Paris is a city, and neither is anyone’s parent.
Consistent is not true
The reasoner was right to draw every one of those conclusions. The fault is upstream, in what the triples commit to about the world. RDF implements ontological commitments; it does not supply them. Even OWL would object only if someone had already committed that days and people are disjoint, and that commitment comes from outside the logic.
Continue · part 2 of 5
From Words to the World
Watch the bridge grow and the leap shrink, interactively — then walk the full terrain of data, semantic and graph terminology, and the four distinctions that do the most work when you keep them, and the most damage when you blur them.
Part 1 · the data — the modern word Part 2 · the world — the founded target Part 3 · the machine — many models, one evolving world Part 4 · the grounding — memory & common sense for the LLM Part 5 · the architecture — sources in, two founded outputs out
A definition still leaves the leap from word to world to a brain. Model the data as it really is — many systems, each a partial projection of one shared world — and you can see why two of them disagree about the same company, and what it would take to carry the world's structure across instead of leaning on a reader to supply it.
This is the data architect's path into Part 1. It opens on the same bridge as every other entry point: Parts 2 to 5 are the shared trunk, walked the same way whichever door you came in by.
Worked example throughout: one large group (Company X) as two systems record it, the Legal database and the MDM hub, and the world both records are about.
