The words you need before you build an enterprise ontology

Seven terms carry most of the confusion in enterprise ontology work. Three are plain definitions, starting with ontology itself. The other four are not definitions at all. They are positions, contested between vendors and disciplines. This page states each term plainly, shows it on one small worked case before it argues anything, says how it earns its keep inside an AI system, and where it is a position, tells you which side we are on and why the answer changes what you build.

I did not understand most of these words the first time I heard them used in earnest. I understood them the third time, on a real project, when using the wrong one had already cost us a week. So this is the page I wish someone had handed me. Most of the examples come from one setting the rest of this cluster uses too, a fast-growing healthcare payer standing up AI on its claims adjudication. Two entries borrow a smaller, more universal case: an HR department. That's where the abstraction gets hardest, and a claims example would need its own explaining first. Where someone else explains a piece of this well, I credit them, mostly gathered in Recommended Reading and Watching at the end, not scattered through the page.

Ontology

An ontology is a system's map of some subject: the things in it, how they connect, and the rules about what's allowed, written so software can act on it, not just show it on a screen.

Take one fact a payer's system might hold: semaglutide covered-for type-2-diabetes. A plain list of terms, a taxonomy, can tell you both things exist. It takes an ontology to hold the actual relationship between them, and a rule about what else has to be true (the right plan, the right line of business) before that relationship counts. That's the part a slide full of boxes and arrows can't do: a diagram doesn't object when something's wrong. An ontology does.

Formal means unambiguous: logic, not prose. And "machine-readable" is doing too much work in that definition, so it's worth splitting in two. Machine-readable just means a computer can parse the file at all: load it, store it, move it around. A CSV is machine-readable and knows nothing. Machine-interpretable is the stronger claim this page actually needs: the structure carries an agreed specification of what operations are valid over it, so software can correctly compute whether two facts contradict, not just store them side by side. RDF gets you the first. OWL is what gets you the second. The relationships are what a taxonomy misses either way: not just that a drug and a diagnosis both exist, but that this drug is covered for that diagnosis under this plan. The rules are what the system can enforce.

The mistake this prevents: treating a diagram of your domain as if it were the ontology. A whiteboard sketch and a machine-readable ontology can say the exact same thing to a person; only one of them can be checked by software. Teams that skip straight from the sketch to "we have an ontology" find out the gap the first time an agent needs to act on it, not just display it.

Here's why it matters for AI, which is the reason this whole page exists. A language model learns statistical correlation, not meaning. It knows "semaglutide" and "diabetes" turn up together; it does not know that semaglutide treats type 2 diabetes, belongs to the GLP-1 class, or is covered only under specific criteria. Ask it the same question twice and you can get two different answers. An ontology gives the model a formal structure to reason against and to check its output against, which is what turns a plausible answer into a verifiable one. In our payer, the ontology is what lets the system decide whether a claim should be paid, and show the rule that decided it.

Triple, RDF, and OWL: the primitives

A triple is the smallest unit of machine-checkable knowledge: a subject, a predicate, and an object. One fact a machine can check, not a sentence a human has to interpret.

Watch what happens to one claim as three triples stack up:

• claim-88213 billed-for semaglutide — accepted.
• claim-88213 type PayableClaim — accepted.
• claim-88213 type ExcludedClaim — also accepted.

RDF (the Resource Description Framework) happily stores all three. It has no opinion about whether one claim can be both a PayableClaim and an ExcludedClaim. It just records facts. That silence is the whole problem: a claim that should never exist, sitting in the system as three perfectly valid statements.

OWL (the Web Ontology Language) is what changes that. Declare PayableClaim and ExcludedClaim disjoint classes, meaning nothing can belong to both (a class-level rule, not a data fix), and the moment one claim is typed as each, OWL raises the violation. The three facts are identical in both cases; what changed is that one layer was given a rule about what cannot coexist.

The mistake this prevents: building a graph and assuming it reasons just because it stores connected data. Most people conflate RDF and OWL, then wonder why their graph holds facts but never catches a contradiction. The reasoning lives in OWL, not in the triple store underneath it.

In an AI system this is what makes verification possible at all. An agent's answer is just prose until you can restate it as triples and test each one against the rules in OWL. That's the line between an output that sounds right and one a reasoner can actually test. It's the whole reason to put a formal layer under a language model.

Graph versus graph database

A graph is an information structure. A graph database is one product for storing it. The two get collapsed constantly, and the collapse has a commercial cause.

"Graph" is four different words wearing one coat, and the confusion starts before anyone says "database." Say "let's put this in a graph" in most companies and you could mean: a bar chart (the everyday meaning, and a dead end here); a graph in the math sense: nodes and edges, a set of connected facts; a knowledge graph: nodes and edges where the edges carry formal, typed meaning; or a graph database, a product for storing any of the above. This page means the second and third. Keeping them separate from the fourth is the actual point of this entry.

Neo4j is a graph database. It is very good at storing and querying connected data. It is not, by itself, a knowledge graph, because it carries no formal account of what the connections mean. You can build a knowledge graph using Neo4j underneath, and you can hold the same set of triples in a triplestore, a search index, a labeled property graph, or the configuration tables of a claims adjudication engine. The store is not the knowledge.

Neo4j isn't the whole market, and the split that actually matters isn't the vendor name. It's labeled property graph (LPG) versus RDF triplestore, two different ways of storing the same connected facts:

An LPG models an edge as a flexible, mutable property: fast to write, fast to traverse, no fixed vocabulary required. An RDF triplestore models every edge as a formally typed statement in a shared vocabulary, queryable in SPARQL, with the OWL reasoning from the previous entry available in the store itself rather than bolted on later. Neither one is the knowledge graph by default. On an LPG you add the formal typing yourself, which is the whole argument of this entry. On an RDF store some of that formality comes for free. Either way the formal typing has to exist before you have a knowledge graph, and the store only decides how much of it you write by hand.

The mistake this prevents: buying a graph database and believing the hard part is done. Once you see that the graph is the knowledge and the database is only storage, you stop treating "put an agent on our knowledge" as a procurement decision. The reasoning and verification you actually want can sit over any store. The team that misses this has bought storage and called it understanding.

Why it matters for AI: the reasoning and verification an agent needs don't come from the database layer at all. They come from whether the graph underneath carries formal meaning, which is a modeling question, not a vendor question.

Taxonomy versus ontology

Start with the question people actually hold and never get answered: is a taxonomy a small ontology, or an ontology a fancy taxonomy, or are they siblings? None of those. A taxonomy is not a type of ontology, and an ontology is not a type of taxonomy. An ontology usually contains a taxonomy (the hierarchy of what's-a-kind-of-what) and adds the typed relationships and rules a taxonomy has no way to express. Skeleton isn't a kind of body. Skeleton is part of the body. That containment is how we use the two words operationally; a formal ontology can technically consist of nothing but a class hierarchy, which is exactly the case where the distinction stops paying for itself.

Here's what that looks like in one department. An HR team already has a job-level taxonomy (IC1 through IC6 on the individual-contributor track, M1 through M5 on the management track), usually adopted wholesale from an industry leveling framework, not built from scratch. That's the taxonomy: a clean hierarchy that's borrowed and cheap to stand up. It tells you a manager outranks an IC. It does not tell you anything about what a manager is and isn't allowed to do.

The ontology adds that: manager reports-to nobody at their own level, expense requires-approval-bythe submitter's manager, and one rule that actually does the work: a manager cannot approve an expense they themselves submitted. The taxonomy can't express that rule; a hierarchy has no concept of "self." The ontology can, and it's the only one of the two that can stop an approval-bot from being tricked into rubber-stamping its own submitter's expense.

That's also the answer to the other question people ask: should you build the taxonomy first? Mostly, yes. It's the scaffold, and in HR's case it's often sitting there already, borrowed. But finishing the taxonomy is not finishing the ontology. The relationships and the rule are separate work, done after, and skipping that step is exactly how a company ends up with a tidy level hierarchy and an approval workflow nothing actually enforces.

The same shape holds back in claims adjudication, which is where this cluster lives the rest of the time: ICD-10 and CPT are the borrowed taxonomy, the skeleton every payer shares. The taxonomy is borrowed. The domain-specific ontology (which diagnosis justifies which drug, under which plan) is the one your payer has to build. That's why the ontology, not the taxonomy, is the expensive part. (If you want the concepts drawn rather than described, our ontology explainer is the interactive version.)

The mistake this prevents: mistaking "we finished the taxonomy" for "we finished the ontology." They're different deliverables, built in sequence, and only the second one can enforce anything.

None of this is really a contest between the two, though. Most teams don't start from zero on either side, and the real question is what to do with what's already sitting there. If you have a taxonomy and no ontology (the common case: a classification scheme inherited from some other project, or a borrowed standard like ICD-10), you're not starting over. You already have the scaffold; the relationships and the rule are the only piece left to add, and that's exactly what this entry describes. If you have neither, build the taxonomy first, for the same reason the HR team above did: it's cheaper, and some version of it is usually lying around already. "Taxonomy or ontology" is the wrong question. "What do we already have, and how much of the expensive part is still missing" is the one that actually gets answered.

In an AI system the two do different jobs. A taxonomy is enough to classify a document or route a query, most of what retrieval needs. Catching that a claim pairs a drug with a diagnosis it should never pair with needs the relationships and rules only the ontology carries, which is why a retrieval system can surface that claim without ever flagging it.

Schema versus ontology

You've probably met "schema" in two places, and this entry means something closer to the second one than the first. There's the database kind: a field must hold a valid date, a valid ICD-10 code. And there's the kind you already use for SEO: schema.org, the markup you add to a page (Article, FAQPage, Product) so a search engine or an AI system knows what the page is, not just what bytes it contains. That second one is already a lightweight ontology, and it's a better bridge into this entry than the database version, because you're probably already doing the thing this page is trying to explain.

Here's the progression. A Product type on a page, with a brand and an offers block carrying the price: a machine now knows what the page is, not just that it has text on it. That's schema.org: a shared vocabulary that attaches meaning, down to which type each property is allowed on. The price hangs off the offer rather than the product, and getting that wrong is the small version of the mistake this whole page is about. Where it stops: schema.org can say a Drug treats a Condition, but it can't enforce "this drug is covered for this diagnosis only under this plan, when criteria are met," and it can't object when two facts contradict. It's a vocabulary, not a rulebook.

An ontology is schema.org that can reason and say no. A databaseschema isn't a small ontology at all. It constrains storage, a different layer entirely, not contained in the ontology on either side. A schema.org-style schema, though, roughly is a lightweight one: the same spectrum without the enforcement. No disjointness, no cardinality, no rule that fires.

Back on the payer's own claim: the database schema tells you the diagnosis field holds a valid ICD-10 string. It says nothing about whether that diagnosis is a covered indication for the drug on the same claim, under this member's plan. A claim can be perfectly valid against the schema, every field well-formed, and still assert something the plan doesn't cover. It gets paid without complaint, because no rule about meaning was ever there to object. Every check that ran, ran on the shape of the data, and nothing in the stack was responsible for whether the claim made sense.

The mistake this prevents: validating a record against its schema and calling that correctness. A schema-valid row and a semantically impossible fact can be the same row.

This is the gap AI walks straight into. A language model produces fluent, schema-valid output all day, and a schema has no opinion about whether the content is possible. Only a declared rule can object, and the ontology is where that rule lives. That's why a system meant to catch a wrong answer needs one, and a database alone does not.

Semantic layer, thin versus rich

A semantic layer is the mapping between raw data and the business language people actually ask questions in. What varies is how much of the meaning it carries, and that variation is the whole entry.

"Semantic layer" is a real, widely used industry term. dbt ships one, so does Looker, Cube, AtScale. Splitting it into thin and richis not an industry standard; that split is ours. Worth saying plainly before using it: the field doesn't label semantic layers this way, we do, because the difference it names is the one that decides whether you can trust the answer.

Take an HR analytics question: "what's our attrition rate by department?" A thin semantic layer maps that business phrase to a column and a table, generates the SQL, and returns a number. Ask it twice, get the same number both times. It cannot tell you whether any single departure was a policy problem.

Now ask the harder version: "was this termination defensible under our policy and under employment law?" That needs a structure that reasons over the HR policy and the legal requirement together, and returns an answer with the clause that justifies it, not just a count. That's the rich layer. Same two words, "semantic layer," describing two different capabilities.

A short way to tell which one a vendor just put in front of you:

• Does it turn a business term into SQL, or does it hold rules about what the data means?
• Can it object (flag an answer as not defensible), or only retrieve and count?
• Ask it the same question twice: do you get a defensible answer, or just a repeatable one?
• Does the answer arrive with the rule that justifies it, or just the number?
• Can it reason across two governing sources at once (a policy and a mandate together), or one table at a time?

The mistake this prevents: buying the thin layer for a job that needs the rich one. If the job is a dashboard, thin is plenty, and I'm not going to pretend otherwise. If the job is a decision someone can be held to, thin fails on exactly the question that matters: it returns the number without the clause that would justify it.

Swap "termination" for "claim denial" and the same split holds in the payer's world: was this denial defensible against the medical policy and the state mandate together, not just how many denials happened.

Grounding, and what "hangs as a fact" means

Grounding is attaching a mined fact to a defined concept in your domain, which is what makes the fact checkable rather than merely well-formed.

Here are two facts about the same claim, and they look identical:

• claim-88213 billed-for semaglutide
• claim-88213 billed-for compounded-glp1-blend

Same shape, same confidence, both perfectly well-formed, but only one of them has somewhere to go. semaglutideresolves to a valid NDC, a defined concept in the payer's domain with rules already attached, so the coverage question can at least be asked. The compounded blend reaches for the same kind of anchor and finds nothing: no NDC, and no concept for a rule to attach to. It hangs as a fact.

this-service is medically-necessaryis a clean triple and also homeless until you know the line of business. A commercial plan and the Medicaid line define medical necessity differently, and a system that grounds it to the wrong one enforces the wrong rule. Grounding is what gives a fact a home. An ungrounded fact has the exact shape of a hallucination: fluent, well-formed, attached to nothing. An agent can't tell the difference by looking.

The mistake this prevents, and this is the one the rest of the cluster keeps returning to. Follow what happens after a fact is mined, down two different paths:

• Mined → grounded → consumed: the drug grounds to a valid NDC. An agent downstream can check it against the coverage rule, cite the concept it grounded to, and produce an answer someone can trace and defend.
• Mined → ungrounded → consumed anyway:the compounded blend attaches to nothing, but it's still well-formed, so an agent reads it as true. It acts on it. The wrong rule fires, or no rule fires at all, and a hallucination-shaped fact has just propagated into a decision nobody can trace back to anything real.

The agent cannot tell these two paths apart by looking at the fact alone. That's what makes grounding the step that decides whether everything built on top of it (the OWL rule that's supposed to fire, the schema check that's supposed to catch a contradiction) has anything real to check against at all. An ungrounded fact gives those rules nothing to fire against, so the answer comes back with no record of what was actually checked.

The general idea of knowledge needing to be "grounded in reality" is shared across the field (see Recommended Reading, below). The phrase "hangs as a fact" is ours, and it names the specific failure this cluster keeps returning to: a fact that's syntactically fine and semantically nowhere.

Recommended reading and watching

Curated, not a link dump. This list is for going broader after the page, where each "Go deeper" above was going deeper on one specific entry.

• RDF 1.1 Primer and OWL 2 Primer, W3C. The standards themselves. Read these for precision, not for a gentle introduction.
• Taxonomy, Ontology, Knowledge Graph, and Semantics, Casey Hart. The cleanest short teaching of how these four words differ.
• Three Metaphors for Ontology, Casey Hart. An ontology as a language, a graph, and a model. The most useful mental model on the channel for a non-specialist.
• The Shape of SHACL, Casey Hart (pair with the W3C SHACL spec). How you write shapes that test a graph, relevant because validation is where the rich semantic layer earns its keep.
• LLMs Don't Hallucinate, They Make Mistakes, Casey Hart. Sharp, and mostly in agreement with this page: fuzzy language protects a system from scrutiny.

Questions people actually ask