What Is a Product Ontology?
A taxonomy tells you where a product belongs; a product ontology tells machines what it is and how it relates to other things. A practical definition for industrial catalogs, without the academic baggage.
A product ontology defines the entities, attributes and relationship types in a catalog so machines can reason over them. A taxonomy tells you where a product belongs; an ontology tells you what it is and how it relates to other things.
Every distributor has a taxonomy: the category tree a product is filed under. Far fewer have an ontology, the model that lets software know a 6204-2RS is a variant of the 6204 family, fits a housing with a 47 mm bore and is documented by a specific datasheet.
Definition
A product ontology defines the entities, attributes and relationship types in a catalog so machines can reason over them, not just file products into categories.
The one-line distinction: a taxonomy tells you where a product belongs; an ontology tells you what it is and how it relates to other things. Taxonomy is a filing cabinet. Ontology is the wiring diagram.
Taxonomy vs ontology
| Taxonomy | Ontology | |
|---|---|---|
| Answers | Where does this belong? | What is this and how does it relate? |
| Structure | A tree (parent and child) | A graph (typed relationships) |
| Example | Bearing, Ball bearing, Deep-groove | manufactured_by SKF, variant_of 6204 family |
| Use | Browsing, navigation, reporting | Matching, substitution, compatibility, agent answers |
| Relationship types | One (is-a) | Many (variant, compatible, replaced by, documented by) |
Take an SKF 6204-2RS. A taxonomy places it: Bearing, Ball bearing, Deep-groove ball bearing. That is enough to browse a category page, and no more. An ontology states the facts a machine needs to work with it: it is manufactured_by SKF, a variant_of the 6204 family, compatible_with a housing with a 47 mm bore and documented_by page 4 of its datasheet. Those relationships let a procurement search, a configurator or an AI agent answer a real question instead of returning a category.
Keep it operational, not academic
Ontology is a loaded word. It carries decades of semantic-web machinery that most catalog teams neither need nor want. Claro’s position is deliberately narrow: an ontology is only worth having if it changes what the catalog can do. We model the entities and relationships that have operational consequences in distribution and nothing for its own sake. No upper ontologies and no reasoning for its own sake, only the structure that makes write-back correct and agent answers trustworthy.
The three parts of a practical ontology
- Entities: product, product family, manufacturer, supplier, document, pack.
- Attributes: typed, with units and allowed values (bore diameter in mm, coil voltage range).
- Relationships: the typed edges between entities, each carrying a source and a confidence.
Standards such as ETIM and ECLASS supply classes and features that make good inputs. They are classification and attribute vocabularies; the relationships between your specific products are what you still have to model. See ETIM vs UNSPSC vs ECLASS for how the standards compare, and catalog, taxonomy and attribute schema for how the pieces fit.
The relationships that matter in distribution
In an industrial catalog the consequential relationships are concrete: variant, pack, replacement, equivalent, compatible-with, accessory, component, supplied-by and documented-by. Each has a cost attached to getting it wrong. Ship an EQUIVALENT_TO where only SAME_AS was acceptable and you have substituted the wrong part. The product relationship types guide defines each one and the line between them.
Common mistakes
- Calling the taxonomy an ontology. If it is a tree with one relationship type, it is a taxonomy.
- Modeling everything. Start with the relationships that drive a decision you already make.
- Relationships without evidence. An unsourced
COMPATIBLE_WITHcan cause a returned order. - Building it in a separate tool nobody writes back from. The ontology must feed the systems that act.
How Claro uses the ontology
The ontology is the schema the Product Identity & Evidence Graph is built on. It lets Claro write a resolved value back to the right field in your ERP or PIM, expose machine-answerable relationships to an agent and keep the catalog’s meaning stable as suppliers churn. It sits one layer above the semantic product layer’s resolved identities: identity says which product, and ontology says what it is and how it connects.
Related
Guide
Product Relationship Types
Each relationship defined, with the lines between them.
Glossary
Semantic Product Layer
Where the ontology sits in the stack.
Glossary
Product Knowledge Graph
The populated data that follows an ontology.
Article
Catalog, Taxonomy, Attribute Schema
How the pieces differ.
Guide
Product Identity & Evidence Graph
The graph built on this ontology.
Glossary
Product Identity
Which product, before what it is.
FAQ
What is a product ontology?
A product ontology defines the entities, attributes and relationship types in a catalog so machines can reason over them. It records what a product is and how it relates to others, not only which category it is filed under.
What is the difference between a taxonomy and an ontology?
A taxonomy is a hierarchy that tells you where a product belongs. An ontology is a graph of typed relationships that tells you what the product is and how it relates to other things, such as variants, replacements and compatible parts.
Do I need a product ontology if I already use ETIM or ECLASS?
ETIM and ECLASS give you classes and standardized features, which are valuable inputs. They do not model the relationships between your own specific products, such as replacements or compatibility, so an ontology still adds operational value on top.
Is a product ontology the same as a knowledge graph?
They are related. The ontology is the schema: the entity and relationship types. A knowledge graph is the populated data that follows that schema. Claro’s Product Identity and Evidence Graph is built on its ontology.
Claro
See how Claro handles this in production
This concept is one piece of keeping a catalog trusted. See how Claro resolves identity, enriches missing attributes, and validates every update before it reaches your PIM or ERP.
Learn more