A logical model is not a semantic model.

Three levels of one design

Data modeling has taught the same three levels for half a century, since the ANSI/SPARC architecture of 1975. You start abstract and refine toward storage: a conceptual model of business concepts, a logical model that commits to a structure, and a physical model that lands it on a particular database. Each level answers “how do we store this?” at a finer grain than the last.

Then knowledge graphs arrived with a semantic model — also technology-independent, also drawn as boxes-and-lines of entities and relationships — and it was natural to file it on the same ladder, as a slightly fancier logical model. That instinct is the single most expensive mistake in enterprise semantics. The semantic model is not a fourth rung on the storage ladder. It is a different ladder entirely, leaning against a different wall.

The three levels form one lineage. Each is a refinement of the one above, and every step trades abstraction for implementation detail — moving from what the business means toward how a specific engine stores it.

Watch what happens to the shape as you descend. The conceptual model says a policy involves several parties. The logical model, to store that many-to-many without redundancy, invents a Policy_Party junction table with a role_code column — a table that corresponds to nothing in the business, a pure artifact of normalization. The physical model then indexes it. By the bottom of the stack, the structure serves storage, and the original meaning is an inference you make from column names.

The lineage: conceptual → logical → physical is top-down database design. One system, closed world, growing more concrete and more storage-driven at every step. Nothing on this ladder is about sharing meaning — that was never its job.

A semantic model — an ontology — also has “entities” and “relationships,” and it too is drawn as boxes and lines. That surface resemblance is exactly what fools people. Underneath, almost every commitment is different, because it exists for a different reason: not to store data in one system, but to state what that data means in a way any system, and a reasoner, can share.

The two deepest differences drive all the others. First, the world assumption. A relational schema is complete for its scope — if the row isn’t there, the fact is false. An ontology assumes the opposite: anyone can add a fact later, so absence means “not known,” never “not true.” That is what lets ontologies merge and federate; it is also why they cannot, on their own, reject incomplete data. Second, identity. A primary key of 42 is meaningless outside its table; an IRI like https://data.chubb.com/resource/party/42 means the same thing everywhere. Global identity is the whole basis of integration — and a thing a logical model, by design, never provides.

Take the single fact that a policy involves several parties, each in a role. Watch how the logical model and the semantic model render it — and why the difference is meaning, not syntax.

# LOGICAL — a junction table, an artifact of normalization
TABLE Policy_Party ( policy_id FK, party_id FK, role_code )   # meaning is in the codes

# SEMANTIC — the relationship carries its own meaning, with global identity
ex:Policy-1  agr:hasPartyInRole  ex:PIR-7 .
ex:PIR-7    a agr:PartyInRole ;
             agr:party ex:Acme ; core:hasRole policy:UnderwriterRole .   # a defined role, not "UW"

Conflate the two and you build the ontology the lazy way: lift the logical schema one-to-one into RDF. Tables become classes, columns become properties, foreign keys become object properties, and you declare victory. What you actually get is a database wearing RDF syntax — an ontology that has inherited every accident of a relational design:

• Junction tables become junk classes. Policy_Party lands as a class PolicyPartyLink that models nothing anyone in the business would recognise.
• Surrogate keys become properties. policy_id becomes a datatype property, competing with the IRI that should carry identity.
• NULLs become modeling puzzles. Closed-world “empty” is silently reinterpreted as open-world “unknown,” and cardinality axioms you copied from NOT NULL quietly stop meaning what you think.
• Denormalization scars carry over. Columns fused for performance become fused concepts; the model now encodes a tuning decision as though it were a fact about the world.

The reverse mistake is just as common and just as costly: treating a genuine ontology as a storage schema — expecting it to reject incomplete records, assuming two different IRIs must be two different things, waiting for a “required field” to fail. It never will; that is not what an open-world theory does.

The four models are not a single stack. Three of them — conceptual, logical, physical — descend one ladder toward storage in a system. The semantic model rises a different way toward shared, formal meaning. They touch at exactly two places: they are born from the same domain concepts at the top, and they reconnect through a mapping at the bottom, where physical data is lifted up to the ontology’s vocabulary.

The map is not the territory. Alfred Korzybski

A logical model is a superb map of a database — it tells you where every value goes and how the rows fit together without contradiction. But a map of the container is not a theory of the terrain. The semantic model is that theory: it says what a policy is, what a claim means, how a party relates to both — in terms that hold across every system, and that a machine can reason with. Draw the two the same way and you will keep reaching for a map when you needed to understand the land.