A taxonomy sorts things into a hierarchy of categories, where each step down is narrower than the one above: Kitchen appliances > Coffee machines > Espresso machines. An ontology describes the kinds of things in a domain, the properties they have and the typed relations between them, with rules a computer can reason over: a water filter is an accessory of a specific espresso machine, a descaler is consumed by it, its boiler is made of stainless steel.
In a product catalog the short version is this: the taxonomy answers where a product belongs, the ontology answers how products relate. Most stores need a solid taxonomy first, then attributes with controlled value lists, and only then a small set of typed relations where shoppers ask questions that span products, such as compatibility, spare parts, replacements and bundles. The rest of this guide shows both models on one catalog, the layer in between, and when each one pays off.
A taxonomy in a product catalog: one tree, one kind of link
A product taxonomy is the category tree you navigate in a webshop and map to channels. Its only real relation is broader and narrower: Espresso machines is narrower than Coffee machines. The W3C's SKOS Primer describes exactly this for "thesauri, taxonomies, classification schemes": concepts linked by broader and narrower, plus an optional associative "related" link that carries no further meaning.
Public taxonomies work the same way at scale. Google's product taxonomy, version 2021-09-21, has 5,595 categories, from Apparel & Accessories down to single product types (see our Google product taxonomy guide). Every category is a node in one tree, and every product gets a path from the root.
Taxonomies are cheap to build and easy to explain to a merchandiser. Their limit shows the moment you ask a question that is not about placement. "Which filters fit this machine?" has no answer in a tree, because a filter and a machine sit in different branches and the tree has no edge between them.
An ontology in a product catalog: classes, properties and typed relations
An ontology starts from the same classes (Espresso machine is a kind of Coffee machine) and adds what a tree cannot say. The W3C's OWL 2 Primer calls OWL "a language for expressing ontologies" and lists the building blocks: classes and subclasses, object properties that relate one thing to another, inverse properties, domain and range restrictions, and cardinality limits.
Translated to the illustrative espresso catalog, an ontology holds statements like these:
- Water filter WF-2 is an accessory of espresso machine EM-200
- Descaler 500 ml is a consumable for EM-200 and EM-300
- Portafilter 58 mm is a spare part for EM-200
- EM-300 replaces EM-200
- EM-200 is made of stainless steel, a value from a material list, not free text
- Every espresso machine has exactly one pump pressure in bar (a cardinality rule)
Each statement has a type that software can act on. Because "accessory of" is defined once, the store can show accessories on the machine's page, flag a filter with no machine linked, and answer the question the tree could not. Defining "replaces" as directional means the shop can point a visitor from the discontinued EM-200 to the EM-300, but not the other way round.
One espresso machine in a taxonomy and an ontology
Taxonomy vs ontology, side by side
Taxonomist Heather Hedden makes a useful point in her comparison of the two: taxonomies mainly support tagging and retrieval by subject, while ontologies support retrieval, comparison and multistep queries over data. Both are built on W3C standards, SKOS for taxonomies and OWL for ontologies, so they combine rather than compete.
Taxonomy and ontology compared on a product catalog
| Shape | Tree (sometimes a product in two branches) | Graph of classes, properties and relations |
|---|---|---|
| Relations | Broader and narrower, maybe an untyped related link | Typed relations you define: accessory of, made of, replaces |
| Typical question | Where does this product belong? | Which products fit, replace or complete this one? |
| W3C standard | SKOS | OWL |
| Catalog example | Webshop category tree, Google product taxonomy | Compatibility and spare part links, material lists, class rules |
| Who maintains it | Category or e-commerce manager | Product data or catalog architect, with category managers |
The table also shows the shape of the work. A taxonomy is finished when every product has a place. An ontology is never finished, and that is fine as long as each relation type you add answers a real question.
Attributes and controlled vocabularies: the layer between the two
Most catalogs that think they need an ontology actually need this middle layer first. It has two parts.
- Attributes per product class. An espresso machine has pump pressure, boiler type, water tank volume and power. A grinder has burr type and burr diameter. The set of attributes per class (often called a product family or attribute set) is already a small ontology: it says what kind of thing has which properties.
- Controlled vocabularies for attribute values. Material is one of stainless steel, aluminium, plastic or brass, not "inox", "RVS" and "stainless" side by side. A controlled list is what makes a value filterable, translatable and comparable across suppliers.
Our guide to reference data covers how to govern these value lists, and the attribute modeling guide covers which attributes belong to which class. Once both are in place, typed relations between products are a small step, because the things you relate are already well defined.
Where a knowledge graph comes in
The three terms are often used as if they were interchangeable. They are layers:
- Taxonomy: the hierarchy of categories.
- Ontology: the schema, meaning the classes, properties, relation types and rules.
- Knowledge graph: the ontology filled with real instances, so the actual EM-200, WF-2 and descaler records and the links between them.
A product catalog with typed links is a small knowledge graph, even if nobody calls it that. Our dictionary entry on the product knowledge graph goes deeper into graph databases and query languages; for most catalogs, the relations can live in the PIM next to the products.
Which model your catalog needs: signals to look for
Match the model to the questions shoppers and channels ask of your data:
- A taxonomy is enough when products are mostly standalone (apparel basics, home decor, books) and the main jobs are navigation and channel category mapping.
- Add attributes and controlled vocabularies when shoppers filter and compare on specs, or when you sell on marketplaces that require structured values per category.
- Add typed relations when a meaningful share of questions span products: "does this fit", "what replaces this", "what do I need with it". Spare parts, consumables, tools with accessories, electronics with chargers and cases, and B2B catalogs with successor products live here.
- Consider a dedicated graph database only when relations are the product itself, such as a parts catalog where a part fits thousands of machine models and configurations, and the PIM's link tables stop being enough.
Adding typed relations to an existing catalog in five steps
You do not need to model the whole domain before the first relation pays off. Start from the questions, not from the schema:
- Collect the cross-product questions. Read a month of customer service tickets, product Q&A and site search queries, and sort the questions that involve two products: fits, replaces, needs, refills. In a coffee equipment catalog that is typically compatibility, spare parts and consumables.
- Pick two or three relation types and define them in one sentence each. "Accessory of: an optional product that works only with the target product." Write down the direction and which product classes may sit on each side, so a descaler can never be an accessory of a grinder by mistake.
- Seed the links from data you already have. Supplier files often carry compatibility lists, and old descriptions often say "fits EM-200". Turn those into links once, then remove the sentence from the description.
- Add a completeness check. Every product in the Water filters category needs at least one accessory-of link; every discontinued machine needs a replaces link pointing to it. A product that fails the check is a data gap, not a style issue.
- Publish the relations where they are read. The product page block for accessories, the BMEcat or channel export, and structured data on the page. A relation that only lives in the back office answers nobody's question.
Expect the first pass to cover the top-selling machines and their consumables, not the long tail. That is usually where the questions are.
Why typed relations matter to search engines and AI shopping agents
A shopper who asks an AI assistant "which water filter fits my EM-200" needs an answer that comes from data, not from a description that says "compatible with most EM models". Prose like that gives a machine nothing it can follow. A typed relation from WF-2 to EM-200 does.
The vocabulary for publishing those relations already exists. Schema.org's Product type has isAccessoryOrSparePartFor, isConsumableFor, isSimilarTo and isRelatedTo, plus material, category and isVariantOf. Each one is a typed relation in the ontology sense, which is why a catalog with typed links can be published in a form crawlers and agents can read, and a catalog with only a category tree cannot. Our schema.org taxonomy guide covers how category and product types map.
No standard guarantees that a given AI assistant reads a given property today. What is clear is the direction: structured attributes, controlled values and explicit relations are the parts of a catalog a machine can use without guessing.
Six ways catalogs blur taxonomy and ontology
- Attributes disguised as categories. A category called Red Espresso Machines is a filter value pretending to be a node. Color belongs in an attribute; the tree stays about product type.
- Marketing collections inside the taxonomy. Gifts under 50 and New arrivals are useful collections, but mixing them into the classification tree breaks channel category mapping.
- Relations written in description text. "Fits EM-200 and EM-300" in a description cannot be filtered, checked or exported as a link.
- One catch-all related link. If accessories, alternatives and replacements all go into "related", the shop cannot treat them differently on the page, and neither can a crawler.
- Free-text values where a list belongs. Three spellings of one material create three filter options and three translations.
- Relations without direction. "Replaces" and "is replaced by" are different statements. Store the direction once and derive the inverse, rather than maintaining both by hand.
Categories, families and typed product links in WISEPIM
WISEPIM covers the three layers in one place. The category tree is the taxonomy, with AI categorization that is 95%+ accurate and a category map to Google's product taxonomy. Product families hold the attribute set per class, with inheritance from parent families and optional ETIM classes. Option sets are the controlled vocabularies: shared lists of allowed values for select and multi-select attributes, each with a rule for unknown values on import (add them, add them but flag them for review, or skip them).
Typed product links are the ontology layer. In the product editor you link products as cross-sells, upsells, related products, replacements or accessories, and bundle items carry a quantity. The types survive export only where the format has a place for them: the BMEcat export in Feed Hub writes them as typed article references, with accessories as accessories, replacements as follow-up products and bundle items as consists-of. Store connections are narrower: the Lightspeed eCom connection sends only the Related Products links, as Lightspeed related products, and the other store connections do not send product links. If you are preparing product data for AI shopping assistants, our agentic commerce page shows what WISEPIM publishes for them.
