Ontologies for mere mortals: one that actually runs

Every article I have ever read about ontologies leaves me more confused than when I started. They open with "a formal specification of a shared conceptualization," spend two thousand words in strategy-deck abstraction, and end without ever showing you a single file. You nod along and retain nothing. So let me try the opposite: one real ontology, running inside a banking AI, explained in words a human uses — and then the bigger picture it points to.

The use case, so the rest lands

Picture a banking analytics assistant. An analyst types a plain-English question — "net transaction amount by customer segment," or "which customers overdraft the most" — and the assistant answers by generating SQL against governed banking data: customers, accounts, transactions, loans. Two things make this hard. First, a transaction row only carries an account id, not a customer id, so to attribute a transaction to a customer the AI has to know it must hop through the account. Get that join wrong and every number is wrong. Second, the assistant must never touch sensitive columns — names, account numbers — no matter how it is asked.

So the AI needs to know what the things are, how they connect, and what it is allowed to see. That knowledge is the ontology. The banking analyst is just the example; the same shape applies anywhere an AI or a team needs a shared, governed model of what exists.

What an ontology actually is

An ontology is a written-down map of what exists in your business and how those things connect. The nouns (Customer, Account, Transaction), the links between them (an Account belongs to a Customer), and the rules that always hold. That is genuinely the whole idea. Everything else is formality piled on top.

The useful analogy is a blueprint versus the building. Your data — the rows sitting in database tables — is the building. The ontology is the blueprint: it says what a "Customer" is and how it relates to an "Account," independent of any one table or system. Hand the blueprint to a new builder and they know how the thing is supposed to fit together.

The parts, decoded

Here is the actual ontology, with every piece of jargon translated into plain English:

• A class is a kind of thing. Customer, Account, Transaction — the nouns of your business. Each maps to a table the AI is allowed to read.
• A property is a fact about that thing: a customer's segment, an account's balance. Some get flagged sensitive (a name, an account number) so the AI never sees them.
• A relationship is how two things connect. "An Account BELONGS_TO a Customer." In database terms this is a join, and it is the single most drift-prone fact in the entire system — more on that below.
• A metric is a named calculation, like "overdraft ratio = events divided by active days." Defined once, so every part of the system computes it the same way instead of each guessing.
• An axiom is a rule that is always true: "every account belongs to exactly one customer." A fancy word for a very plain idea — an invariant, a constraint you can actually check.
• The perimeter is the fence around your data: which tables the AI may see, and which columns are walled off as sensitive. Governance, written as data instead of buried in a policy document.

That is the entire vocabulary. If an ontology article ever made you feel stupid, it was the article's fault, not yours.

A word on taxonomy, since people mix the two up

The moment you say "ontology," someone says "taxonomy," and the two get used as if they are the same thing. They are not. A taxonomy is a hierarchy of categories — a controlled vocabulary organized into a tree. It is actually a simpler, narrower thing than an ontology: an ontology has classes plus relationships plus rules, while a taxonomy is just the "is-a" tree. So a taxonomy is more like one ingredient of an ontology than a competitor to it.

The reason this matters in practice is column-level security. Most banks classify sensitive columns with a taxonomy — a tree of sensitivity labels like PII_DIRECT (names, emails) and PII_FINANCIAL (amounts, account numbers) — and use it to decide who may see what, masking the rest to NULL. That taxonomy is owned centrally, shared across every data product, and it should stay its own thing. The question is how it relates to the ontology.

The clean answer is: the ontology references the taxonomy; it does not absorb it. The taxonomy owns the definitions — what PII_FINANCIAL means and that it masks to NULL for analysts. The ontology owns the assignment — this column is PII_FINANCIAL — by pointing a property at a taxonomy term, not by re-describing it. Two separate jobs, one link between them. And the same discipline from the rest of this post applies: a check fails the build if a property references a term that does not exist, or if the ontology's assignments stop matching the labels actually deployed on the columns. So the model and the live access controls cannot quietly disagree about what counts as sensitive — the exact failure you do not want to discover in an audit.

Why bother

Four benefits, in order of how much they matter in practice:

• One source of truth. Before this, the fact "a transaction connects to a customer through its account" was written down in three separate places. Three copies means three chances to disagree, and two of them had already quietly drifted apart. Now that fact lives in one file and everything else is generated from it.
• The AI stops guessing. Left to introspect a raw database, an agent invents plausible-but-wrong joins and redefines your metrics three different ways. Grounding it on curated meaning fixes that.
• Governance becomes code. The perimeter and the sensitive-column flags live in the model, versioned in git, reviewable in a pull request. "How do you control what the AI can see?" becomes a file you can point at.
• The knowledge is portable. Swap the agent framework underneath and the model of your business does not get rewritten.

What it looks like in practice

Here is how that one file flows all the way to the answer the analyst sees:

One ontology.yaml feeds a compile step, which projects it into three artifacts. Naming the three, because they are the pieces people usually meet in isolation and never connect:

• The agent grounding is the packaging that hands the AI its curated context — the perimeter, the join list, and the concept descriptions it reads before answering. (This is what the Open Knowledge Format is: a tidy, portable way to serve an AI that context. I wrote about it separately.)
• The database graph — a join-model view plus a native property graph over the same tables — is the relationships expressed as data the query engine can read, so when the AI writes SQL it uses the correct joins, and so multi-hop questions ("customers connected to a flagged account") can be traversed directly.
• The perimeter and policy is the table allow-list plus the sensitive-column tags — the fence, enforced downstream by database security.

Those three feed the agentic router: one endpoint that reads the analyst's question and sends it to the right grounded tool — Analytics for a number, Knowledge Base for a policy document, Data Model for "what does this metric even mean." Every tool is grounded by the projections above, and every projection traces back to the one model. So the answer uses the right joins and the canonical metric definitions — not because someone kept four documents in sync by hand, but because there is only one document.

Here is that last route in action — the assistant answering the exact join question from the top of this post, straight from the model, without running a query:

The drift it killed

Concrete proof, because this is the part that pays for itself. The join model lived in three hand-maintained copies: the list the AI read, the database view, and the human docs. When I went to unify them, two had already diverged — the AI's copy described three relationships while the database view described four. Nobody noticed, because nothing forced them to agree. Now all three are generated from the ontology, and a continuous-integration test fails the build the moment any of them stops matching. That is the whole payoff in one sentence: you can no longer accidentally lie to yourself.

The bigger picture: what this becomes at enterprise scale

My version is deliberately small — a YAML file and a drift-guard test. It captures everything that actually drives the assistant, and reaching for a semantic-web stack to answer "how do transactions join to customers" would be a costume, not a solution. But the demo is one rung on a tall ladder, and it is worth seeing the whole ladder, because the higher rungs are real tools solving real problems — just ones my use case never hit.

Here is what "doing it properly" looks like in practice, not just in theory:

• RDF and OWL are the formal way to write the model. RDF states everything as simple subject-predicate-object facts ("Account-123 belongsTo Customer-9"). OWL adds real semantics: class hierarchies (a CheckingAccount is an Account) and property characteristics a machine can reason over — transitive, inverse, functional (exactly one value). You author it in a tool like Protégé. In my version, this is the humble twin: my ontology.yaml declares the very same classes and relationships, just as plain YAML with no formal semantics attached — the model, minus the machinery.
• A reasoner (HermiT, ELK, Pellet) is the payoff for going formal. Feed it the model and it infers facts you never wrote down and, more valuable, automatically flags contradictions — declare that every account has exactly one owner, load data where one has two, and it tells you something is broken. In my version, the stand-in is the CI drift-guard test: it cannot infer new facts, but it does the consistency half — regenerate every projection and fail the build if any disagree. A reasoner is that instinct, grown up.
• SHACL is the validation layer that checks real data against the model's shapes (cardinality, value ranges, required fields) and rejects bad records at the door. In my version, the axioms are still only documentation — the one rule with real teeth is the perimeter, enforced not by SHACL but by database access controls. SHACL is where the rest of the axioms would stop being prose and start blocking writes.
• A triple store or graph database (GraphDB, Stardog, Neptune, Neo4j) is where the knowledge graph lives once it outgrows a view, queried with SPARQL, Cypher, or GQL to traverse relationships — five hops of "who is connected to whom" — that are miserable as SQL joins. In my version, this already exists in miniature: a native property graph defined over the same tables (metadata only, no data copied). A dedicated graph database is what you graduate to when the graph gets big or spans domains.

And the reasons enterprises actually pay for the full stack, concretely: entity resolution (deciding that the "J. Smith" in three systems is one customer); regulatory data mapping and lineage (GDPR "where does this person's data live," BCBS 239 risk-data traceability); master data management across business lines that each modeled "Account" a little differently; and graph-native detection like fraud rings, where the answer is a pattern of relationships, not a row. In every one of those, the ontology is the shared vocabulary that lets systems, teams, and an acquisition you just bought agree on what a "Customer" is.

Notice what does not change as you climb: one authored model, many generated artifacts, automated checks keeping them honest. The formality grows, the number of projections grows, the enforcement gets teeth — but the architecture is identical to the small version. That is the reassuring part. You do not need the triple store to start; you need the discipline, and the discipline is legible in a YAML file.

So the practical path is the reverse of how ontologies are usually sold. Do not open with OWL and a reasoner. Name your nouns, write your joins down exactly once, generate everything else, let CI keep you honest — and add formality only when a real need shows up: inference you cannot do by hand, interop across domains that will not merge on their own, regulation that demands a provable map. The grand theory finally makes sense after you have watched a small version work. Which is, I think, exactly why most of us bounce off it the first ten times.