Ontology, Taxonomy, Schema: The Vocabulary That Makes Knowledge Possible

Knowledge Graph Practitioner’s Guide: Overview | Part 1 | Part 2 | Part 3 | Part 4 | Part 5 | Part 6 | Part 7 | Part 8 | Part 9 | Part 10 | Part 11a | Part 11b | Part 11c | Appendix A | Appendix B | Appendix C | Part 12

The Three Words That Sound Identical in Meetings and Behave Differently in Production

A bank’s enterprise architecture team rolls out what they call the customer ontology. It is a tree of customer types: Retail Customer, Commercial Customer, Private Wealth Customer, Institutional Customer, with sub-types under each. Customer service applications use it to tag accounts. Marketing uses it to segment campaigns. The Data Catalog renders it under the heading Ontology.

Six months later, the AI risk team tries to use it to answer a question: “for every Commercial Customer whose ultimate parent is incorporated outside the United States and whose primary banker has changed in the last 90 days, list the open credit facilities and their guarantors.” The system cannot answer it. The customer ontology has no notion of ultimate parent, no notion of relationship types between customers, no constraints on what a guarantor is, no inference rules that link a customer’s parent’s incorporation to a credit facility’s risk profile.

The bank does not have an ontology. It has a taxonomy. The two words got used interchangeably. The cost shows up two years later when an AI agent needs to reason and cannot.

This article is the design vocabulary for the meaning layer of a knowledge graph. By the end you will be able to draw the precise lines between taxonomy, schema, and ontology, identify which one your organization actually has, and pick a target architecture that survives year two. The conceptual core in Part 3 defined a knowledge graph as a graph plus a vocabulary plus identity. This article unpacks the second component.

Three Different Things

The cleanest way to keep them straight is to ask what each one answers.

Concept	Answers the question	Structure	Example
Taxonomy	What kind of thing is this?	Tree of categories with parent-child relationships	Customer is a kind of Counterparty; Retail Customer is a kind of Customer
Schema	What shape can valid data take?	List of allowed types, properties, and structural constraints	Every Customer must have a name, a primary address, and at least one account
Ontology	What does this mean and what follows from it?	Classes, relationships, constraints, axioms, and inference rules	If X is a Subsidiary of Y and Y is a Subsidiary of Z, then X is a Subsidiary of Z

A taxonomy is a subset of an ontology. A schema is a complementary contract. An ontology contains both, and adds the rules that let a reasoner derive new facts from old ones.

In practice, Hogan et al. note in their survey that “a knowledge graph’s data conforms to a graph-based data model… [where] ontologies and rules can be used to define and reason about the semantics of the terms used in the graph.” The phrase “and reason about” is doing the load-bearing work. A taxonomy classifies. A schema constrains shape. Only an ontology supports reasoning.

Taxonomy: classification, full stop

A taxonomy is a tree. Children inherit from their parents through a single relationship type, usually subClassOf or is-a. Most Data Catalogs run on taxonomies. Most folder structures are taxonomies. Most product hierarchies are taxonomies.

Taxonomies are good at:

• Tagging documents and assets so they can be filed and retrieved.
• Navigating a hierarchy from general to specific.
• Reporting roll-ups (revenue by Industry; transactions by Channel).
• Imposing a controlled vocabulary on a corpus of unstructured content.

Taxonomies are bad at:

• Expressing relationships other than parent-child.
• Cross-cutting categories (a single thing can sit in many places, but the tree only allows one).
• Constraints (a taxonomy cannot say “every Customer must have at least one Account”).
• Inference (a taxonomy cannot derive new facts).

If your Data Catalog tags datasets under a hierarchy of business domains, you have a taxonomy. If your master data system classifies products as Retail Banking > Deposit Account > Savings Account, you have a taxonomy. These are useful and they are not ontologies.

Schema: structural contract

A schema specifies what shape data must take to be valid. Relational schemas (DDL) are the canonical example. JSON Schema, XSD, and Avro schemas play the same role for documents and messages. SHACL plays this role for RDF graphs (more on this below).

Schemas are good at:

• Catching malformed records at write time (before they pollute downstream).
• Documenting expected structure for consumers.
• Enabling tooling that depends on knowing types and cardinalities.
• Coordinating producers and consumers around a contract.

Schemas are bad at:

• Expressing meaning beyond shape (a schema can require a customerId field; it cannot say what a customer is).
• Cross-system semantics (two schemas can both define customerId as a string and refer to different things).
• Inference (a schema describes what is allowed; it does not derive what follows).

A schema is a structural commitment. An ontology is a semantic commitment. They are different scopes.

Ontology: meaning plus rules

An ontology specifies what kinds of things exist in a domain, what relationships are allowed between them, what constraints those relationships satisfy, and what new facts follow logically from existing ones. The classical definition by Studer, Benjamins, and Fensel in their 1998 paper is that an ontology is “a formal, explicit specification of a shared conceptualization.” Each word matters: formal (machine-interpretable), explicit (written down, not implicit in code), shared (agreed across the parties using it), conceptualization (a model of what exists).

Ontologies are good at:

• Defining classes of entities and the relationships allowed between them.
• Capturing constraints that span systems (a Loan can have at most one Primary Obligor; a Person cannot be their own Parent).
• Inference: subclass entailment (every Subsidiary is a Counterparty), transitivity (Subsidiary-of is transitive), inverse (employs is the inverse of worksAt).
• Federation: the same ontology can govern many graphs from many sources.

Ontologies are bad at:

• Being cheap. Building one well is months of disciplined work.
• Surviving without sponsorship. Per Part 2, failure mode three (governance vacuum) hits ontologies hardest.
• Holding still. The ontology must evolve as the business does, with versioning and change management.

What this looks like in practice: take any candidate ontology in your organization. Ask whether it has classes with allowed relationships (not just a class hierarchy), whether it has at least one constraint a machine can check, and whether a reasoner or validation engine can derive or flag a fact that is not stored explicitly. If any answer is no, what you have is a taxonomy or a schema. Both are useful. Neither is an ontology.

The Stack: Vocabulary, Taxonomy, Schema, Ontology

The four concepts layer cleanly. Each adds expressivity to the one below.

Layer	Adds	Question it answers	Example construct
Vocabulary	Agreed names for entities and relationships	What do we call this thing?	”Customer” is the name; “owns” is the name
Taxonomy	Hierarchical classification of those names	What kinds of things are there?	Customer > Commercial Customer > Subsidiary Customer
Schema	Structural constraints on instances	What shape must valid data take?	Every Customer must have a name and at least one Account
Ontology	Axioms and inference rules over classes and relationships	What follows from what is stated?	Subsidiary-of is transitive; if A is a Subsidiary of B and B is a Subsidiary of C, then A is a Subsidiary of C

You can have a vocabulary without a taxonomy. You can have a taxonomy without a schema. You can have a schema without an ontology. You can have an ontology that contains all of them. In a knowledge graph designed for inference, you almost always do.

A common confusion in 2026, surfaced in a Lettria practitioner guide, is that “as complexity grows, especially with unstructured data, taxonomy alone becomes limiting. Ontologies unlock the ability to build knowledge graphs, power document understanding, and enable natural language interfaces. For AI and automation, they’re often a requirement, not a luxury.” The reason is exactly the layering above: an AI agent that needs to traverse relationships and chain inference cannot do its job on a tree of categories.

The RDFS, OWL, SHACL Stack: What Each Does

Inside the RDF paradigm, three W3C standards layer to give you ontology and validation. They are commonly conflated. They have different jobs.

Standard	Purpose	Key constructs	When to reach for it
RDFS	Lightweight ontology language	rdfs:Class, rdfs:subClassOf, rdfs:domain, rdfs:range, rdfs:label	When a class hierarchy and basic typing is all you need
OWL	Rich ontology language	Cardinality constraints, disjoint classes, equivalence, inverse, transitive, symmetric properties	When inference is a load-bearing part of the system
SHACL	Shape and constraint validation	NodeShape, PropertyShape, mincount, maxcount, datatype constraints, SPARQL-based constraints	When you need to validate data against rules at write time

RDF Schema (W3C, 2014) is the simplest. It gives you classes and a class hierarchy. If you say :Customer rdfs:subClassOf :Counterparty, an RDFS-aware system will treat every customer as a counterparty for type-based queries. RDFS also gives you rdfs:domain and rdfs:range to declare which classes a property applies to.

OWL (W3C, 2012) is much richer. It lets you say things like:

• A Loan has exactly one Primary Obligor (cardinality constraint).
• Customer and Vendor are disjoint classes (no entity can be both).
• subsidiaryOf is a transitive relationship (chains compose).
• employs is the inverse of worksAt (one direction implies the other).
• OurEmployee is equivalent to Person who has a worksAt relationship to OurCompany (definitional class).

OWL has multiple profiles, formalized in OWL 2 Profiles (W3C, 2012), that trade expressivity for tractability. OWL 2 EL is designed for very large terminologies (SNOMED CT uses an EL-flavored profile). OWL 2 QL is designed for query rewriting against relational data. OWL 2 RL is designed for forward-chaining rule-based inference and is the workhorse for most enterprise KGs (FIBO targets RL among others). OWL 2 DL and OWL 2 Full are full expressivity; DL is decidable but expensive, Full is undecidable in the general case.

SHACL (W3C, 2017) does a different job. SHACL validates an RDF graph against shapes. A shape is a constraint expressed in RDF. Example: “every Customer must have at least one Account, of type DepositAccount or CreditAccount, where the Account’s status is one of {Active, Suspended, Closed}.” SHACL checks data conformance; it does not derive new facts.

The relationship between OWL and SHACL is one of the most-litigated topics in the field. The honest answer, as Semantic Arts explains, is that they sit at different epistemic levels. OWL is governed by the Open World Assumption: a missing fact does not mean false; it means unknown. SHACL is governed by the Closed World Assumption: if a constraint says minCount 1 and the fact is missing, the data fails. OWL says what is true and what follows. SHACL says whether what is present is sufficient.

A 2025 paper at K-CAP, “Lessons Learned from the Combined Development of OWL and SHACL”, formalizes what most production teams have already arrived at by trial and error: classes and properties are represented in both languages, “and constraints may be represented in one or both languages according to the need for ontology reasoning and knowledge graph correctness requirements.” OWL for inference, SHACL for validation, both layered on the same RDF graph.

For practitioners: do not pick one and ignore the other. Use OWL where you need entailment (subclass, transitivity, inverse). Use SHACL where you need to catch malformed or incomplete data at ingest. The same Customer class can have OWL axioms (Customer is disjoint from Vendor) and SHACL shapes (Customer must have a name) on the same RDF graph.

Worked Example 1: Schema.org as a Pragmatic Vocabulary

Schema.org is the most widely deployed semantic vocabulary on the web. Per the Schema.org documentation, the vocabulary contains 823 Types, 1529 Properties, 19 Datatypes, 96 Enumerations, and 535 Enumeration members. Per the same source, “over 45 million web domains markup their web pages with over 450 billion Schema.org objects.”

Schema.org sits at the vocabulary layer of the stack with a light taxonomic and schema overlay. It is intentionally not a rigorous ontology. There are no formal cardinality constraints. There are no disjointness axioms. The class hierarchy is shallow and pragmatic. Most properties are documented in prose, not formal axioms.

This is a feature, not a bug. Schema.org’s job is to let a publisher annotate a web page with structured data so a search engine can render a rich result. The cost of compliance must be near zero. Adding constraint axioms would slow adoption. The trade-off is that you get a vocabulary but not deep reasoning.

Schema.org is the right model when you need:

• A pragmatic, web-scale vocabulary that many parties will adopt with low friction.
• Lightweight structured-data markup for SEO, LLM training corpora, or document understanding.
• A shared baseline that downstream systems can extend.

Schema.org is the wrong model when you need:

• Rigorous reasoning over a regulated domain (use FIBO or a similar OWL ontology).
• Validation at write time (use SHACL).
• Federation across legal entities with constrained vocabularies.

For most enterprise KGs, Schema.org is a useful import for common types (Person, Organization, PostalAddress) but it is not the load-bearing layer. The load-bearing layer is your domain ontology.

Worked Example 2: FIBO as a Regulated-Industry Ontology

The Financial Industry Business Ontology is the canonical OWL ontology in finance. It is published by the EDM Council. Per the FIBO Ontology Guide on GitHub and recent industry analyses, as of the 2026/Q1 Production release FIBO contains roughly 2,400 classes (2,446 in that release) spanning Foundations, Business Entities, Finance, Business and Commerce, Securities, Derivatives, and Instruments, distributed across about 194 ontology files in a multi-level modular structure. The exact count drifts with each quarterly release.

FIBO is what a serious ontology looks like:

• It is OWL-based. Classes have formal axioms, not just prose definitions.
• It is modular. The 194 files are organized into modules with explicit dependencies. You can import only the modules you need (e.g., FBC for Foundational Business Concepts, BE for Business Entities, LOAN for loan products).
• It is reasoning-tested. Per FIBO release rules, “ontologies including all reference data and examples that have Release level maturity must be provably logically consistent using multiple OWL 2 compliant reasoners.”
• It targets OWL 2 RL for production reasoning, which keeps inference tractable.
• Major banks have contributed to its development: Wells Fargo, State Street, Bank of America, Citigroup, Deutsche Bank, Goldman Sachs, Mizuho, and others (per the EDM Council FIBO page; the roster reflects cumulative, not necessarily current, participation).

What FIBO buys a bank is a vocabulary that has already been argued through by the industry. When two institutions exchange data using FIBO concepts, they have a shared definition of what a Mortgage is, what a Counterparty is, what a Beneficial Owner is. This matters for regulatory reporting, for cross-institutional data exchange (think open banking), and for the kind of multi-hop traversal an AI risk agent needs to perform.

The cost is non-trivial. FIBO has a steep learning curve. Mapping internal data into FIBO requires investment. Most banks adopt it incrementally, starting with one module (often Business Entities for KYC and counterparty management) and extending over time.

For Part 11 the Lakeside Trust Bank reference architecture imports FIBO modules selectively (FBC, BE, LOAN, SEC) and extends them with a thin Lakeside-specific module for internal concepts that FIBO does not cover. The pattern is generalizable.

Worked Example 3: SNOMED CT as a Clinical Terminology Backed by an Ontology

SNOMED CT is the most widely adopted clinical terminology in the world. Per SNOMED International, the International Edition includes more than 360,000 active concepts, carries over a million formal relationships, and is in use in more than 80 countries (the organization itself has 53 member countries; the wider footprint is via affiliate and licensee use). It is a terminology with an ontology underneath: each concept has a unique identifier, a preferred term, synonyms, and is positioned in a class hierarchy with formal is-a relationships and a controlled set of attribute relationships (e.g., finding-site, causative-agent).

SNOMED CT illustrates a useful design pattern: the user-facing surface (the terms a clinician picks from a drop-down) is separate from the formal ontology underneath (the OWL-EL axioms that allow a reasoner to recognize that “non-insulin-dependent diabetes mellitus” is a kind of “diabetes mellitus” is a kind of “metabolic disorder”). The terminology serves human users; the ontology serves machine reasoning. Both are necessary.

The lesson for enterprise KGs: do not collapse the user-facing vocabulary into the formal ontology. Keep the user-facing terms readable and the formal axioms machine-checkable. SKOS (Simple Knowledge Organization System) is the W3C standard for managing the user-facing terminology layer; OWL handles the formal ontology layer.

The Modular Ontology Pattern

Real-world ontologies are not monoliths. They are modules with explicit dependencies. The standard pattern stratifies them into three layers.

Layer	Purpose	Examples
Upper ontology	Domain-independent abstractions	BFO (Basic Formal Ontology), DOLCE, SUMO; FIBO Foundations
Mid-level ontology	Cross-domain concepts (organizations, people, places, time)	FIBO Business Entities, Schema.org, FOAF, Time Ontology
Domain ontology	Specific to one domain	FIBO LOAN/SEC; SNOMED CT; FIBO Securities; your bank’s internal product ontology

The discipline is to keep classes at the level where they belong. A Person belongs in the mid-level. A Mortgage belongs in the domain. Mixing them creates ontologies that are simultaneously too abstract to use and too specific to share. The Netflix metamodel covered in our existing Netflix Data Governance teardown does exactly this discipline: a thin upper layer (the Upper metamodel) binds many domain models together.

The architectural payoff is reuse. Two different domain ontologies that share an upper ontology can talk to each other. Two domain ontologies that do not share an upper layer cannot, and you find this out at integration time, which is the worst time to find it out.

Top-Down vs Bottom-Up: The Year-Two Decision

Two design philosophies dominate ontology engineering. They optimize for different things.

Top-down. Start from the conceptual model. Design the ontology before fitting data to it. Use upper and mid-level ontologies as anchors. The advantage is rigor and reusability. The risk is the boil-the-ocean failure mode from Part 2: two years of ontology design and no production data.

Bottom-up. Start from the data. Reverse-engineer types and relationships from existing systems. Generalize where patterns repeat. The advantage is speed and grounded relevance. The risk is ad-hoc design, inconsistent class semantics, accumulated technical debt that becomes painful to clean up later.

Hybrid (the production answer). Pick a bounded high-value domain. Inside that domain, design top-down using a published upper or mid-level ontology as the anchor. Sketch the formal axioms first. Validate against real data quickly (within weeks, not quarters). Iterate. Extend horizontally to adjacent domains only after the first one is in production with consumers.

This is consistent with a recent industry observation that “successful knowledge graph construction rarely starts from scratch with an enterprise-wide rollout, but instead organizations choose a single, high-value, bounded domain, such as product master data, customer identity, or regulatory reporting, and build incrementally.” The bounded-domain rule is the hedge against failure mode one (boil the ocean) and failure mode two (no consumer KG) at the same time.

Ontology Design Patterns

The ontology engineering community has accumulated a catalog of Ontology Design Patterns (ODPs) over the past two decades. ODPs are reusable mini-ontologies that solve a recurring modeling problem. Examples: the Time-Indexed Person Role pattern (which lets you say “Alice was a CFO of Acme from 2018 to 2022” without overloading the Person class with time-dependent attributes); the Participant Role pattern; the Provenance pattern; the Information Realization pattern.

The Association for Ontology Design and Patterns runs an annual workshop and maintains pattern catalogs. The 2025 WOP workshop emphasized “applications of ODPs for knowledge graph construction and maintenance,” reflecting the current alignment between the ontology engineering community and the modern KG practitioner.

The discipline for an enterprise team: when a new modeling problem arises, check the ODP catalog before inventing your own pattern. Most problems have been solved. Most amateur attempts at solving them produce ontologies that work for the immediate case and fail when extended.

How to Tell Your “Ontology” Is Actually a Schema or a Taxonomy

Use this diagnostic when an internal team or vendor claims they have an ontology.

Question	If answer is no, what you have
Are classes defined with allowed relationship types between them, not just a class hierarchy?	A taxonomy
Are there cardinality constraints (exactly one, at least one, at most three) on properties?	A taxonomy or a vocabulary
Are there disjointness axioms (Customer and Vendor cannot be the same entity)?	A taxonomy
Is at least one relationship typed as transitive, symmetric, or inverse?	A class hierarchy at most
Can a reasoner or validation engine derive or flag a fact that is not explicitly stored?	A schema or taxonomy
Is there a formal published ontology (OWL, SHACL, or both) that you can show me?	An informal model, regardless of what it is called
Does the vocabulary survive across systems (you find the same Customer class in three different applications, with the same axioms)?	A local artifact, not a shared ontology

If you answer no to most of these, the artifact in question is doing useful work as a taxonomy or schema, but it will not give you the inference, federation, or governance benefits that an ontology gives a knowledge graph. Calling it an ontology will create misaligned expectations with the AI agent team, the regulatory team, and the data integration team that depend on those properties.

The Decision Tree

When you start to design the meaning layer of a knowledge graph, walk the questions in this order.

1. Do you need shared vocabulary for human and SEO consumption only? Use Schema.org or another lightweight vocabulary. Stop here.
2. Do you need to classify and navigate? Add a taxonomy on top of the vocabulary. Stop here.
3. Do you need write-time validation against shape rules? Add SHACL shapes on top of the taxonomy. Stop here unless inference is also needed.
4. Do you need inference (subclass entailment, transitivity, inverse, equivalence)? Add OWL axioms. Pick an OWL profile (RL for production rules, EL for very large terminologies, QL for relational rewriting).
5. Are you in a regulated industry with cross-institutional integration needs? Adopt an industry ontology (FIBO for finance, SNOMED CT for clinical, GoodRelations for e-commerce, NIEM for government) and extend it modularly.
6. Do you need to federate across organizations or geographies? Anchor everything in a published upper ontology so semantic alignment is automatic.

Most enterprise KGs end up at level 4 or 5. The point of walking the steps in order is that each level adds cost, and you should not pay for level 5 capability when level 3 solves your problem.

What You Should Now Be Able to Do

If you read this article cold, you should now be able to:

• Distinguish taxonomy, schema, and ontology with one specific test for each.
• Map any given artifact in your organization (a Data Catalog tag tree, a master data hierarchy, an internal “ontology”) to its actual layer in the stack.
• Decide between RDFS, OWL, and SHACL based on whether you need lightweight typing, rich inference, or shape validation.
• Decide between Schema.org, FIBO, SNOMED CT, or a custom domain ontology based on the domain you operate in and your federation needs.
• Apply the modular ontology pattern (upper plus mid plus domain) to scope a first KG project to a bounded domain.
• Walk a decision tree from “we need shared names” to “we need inference and federation” without paying for capability you do not need.

What you cannot yet do is decide identity. Two systems can use the same ontology and still disagree on whether two records refer to the same entity. The next article handles that problem.

Do Next

Priority	Action	Why it matters
This week	Inventory the artifacts in your organization called ontology, taxonomy, schema, or data model. For each, run the diagnostic table in this article. Categorize what you actually have.	Most organizations have at least one taxonomy claiming to be an ontology and at least one schema claiming to be one. The mislabeling is the single most common source of misaligned expectations between architecture, engineering, and AI teams.
This week	If you operate in finance, banking, or insurance, download the FIBO Ontology Guide and skim the module structure. If you operate in healthcare, the SNOMED CT documentation. The exercise of walking through a real production ontology recalibrates expectations.	Building from a published industry ontology is dramatically cheaper than building one from scratch. Most organizations underestimate this until they see how much has already been done.
This month	Pick one bounded domain (customer master, product hierarchy, regulatory reporting, supply chain) and sketch a first ontology fragment using the modular pattern: import an upper ontology (or use FIBO Foundations as a stand-in), add mid-level concepts, define your domain classes with axioms. Limit it to 30-50 classes.	Sketching forces the design decisions that talking does not. The first sketch will be wrong; that is the point. The right next sketch comes after seeing real data go through the wrong one.
This month	If you have an internal “ontology” in a Data Catalog or master data system, write the SHACL shapes that would validate it. The exercise reveals which constraints exist informally in the heads of stewards and which exist in the system.	Implicit constraints are technical debt. Making them explicit is the cheapest governance improvement you can buy. SHACL is operationally lighter than OWL and is the right place to start.
This quarter	Read Part 5 of this series before designing your first identity scheme or making your first inference rule. Vocabulary is only half the meaning layer; identity and inference are the other half.	The most expensive design mistakes in KGs are made in the identity layer. Vocabulary mistakes can be refactored. Identity mistakes propagate forever.

---

Part 5 of this series, “Identity, Reference, and Inference: How a Graph Becomes Knowledge,” covers IRIs, entity resolution, materialization, and the runtime semantics of a working KG. Read it next.