Why start with words
Every retail system eventually argues about the same thing without saying so: what do we call this product, and what do we know about it?
The price engine needs a category to apply a tax rule. The search box needs attributes to filter on. The planner needs a product family to forecast. The online shop needs a description that makes sense to a stranger. The store associate needs to find the item on a shelf. Each of them holds a slightly different picture of the product, and when pictures differ, systems disagree, customers get wrong answers, and people spend hours fixing records by hand.
A product ontology is the shared language that settles the argument. It is not glamorous, and it is the foundation under almost every useful thing you might later want to do with data or with generative AI. In a case study I published, I described how putting structure first changed catalogue upkeep from constant firefighting into something closer to an exception process. This essay is the how-to behind that idea, written so that a retail team can start on Monday.
What an ontology is, and is not
Taxonomy, attributes, relationships
Three layers make up the idea.
A taxonomy says what kinds of things exist and how they nest: a drink, a soft drink, a cola. It answers the question “what is this?”
Attributes say what you can know about a thing of each kind: size, flavour, pack count, ingredient list, dietary flags. They answer “what do we know about it?”
Relationships say how things connect: this item is a larger pack of that item, this product replaces that one, this accessory fits that device, these two are substitutes. They answer “how does it relate to other things?”
An ontology is the three together, with rules. A “cola” must have a volume and a unit. A “multipack” must point to the single item it contains and say how many. A “replacement” must not point to itself.
Ontology versus a data dictionary
Many teams already have a data dictionary, which lists fields and their meaning. A dictionary is useful, but it is flat. An ontology adds meaning that depends on the kind of product. It says that volume matters for a drink but not for a shirt, and that size means millilitres for one and a garment size for the other. The point is that rules follow the kind of thing, so a system can reason about what is missing or wrong.
A parable of the shopkeeper’s names
Here is a parable, in the spirit of the teaching stories I enjoy. It is a story I tell, not a record of history.
A shopkeeper in a busy market sold the same sweet under three names, because three suppliers named it three ways. Customers asked for it by a fourth name. The shopkeeper’s helper, hired to fetch stock, brought whichever sweet he found first. Some days the customer was delighted, other days annoyed. One evening the shopkeeper sat down and wrote a single name for each sweet on a small slate, with a line underneath saying what made it that sweet: the sugar, the shape, the weight of the packet. He taped the slate to the shelf. The helper stopped guessing. The customers got what they asked for. Even the suppliers began to use his names on their invoices.
The slate was an ontology. It was small, it was agreed, and it removed the need for judgment on the easy cases so that judgment could be saved for the hard ones.
Step 1: Decide what the ontology is for
It is tempting to model everything. Resist. Start by choosing the three or four decisions the ontology must support, and judge every design choice against them.
For a retailer, typical purposes are:
- Searching and filtering for customers online and for staff in store.
- Applying pricing, tax and promotion rules correctly.
- Forecasting and replenishing at the right grain of product.
- Generating accurate product content for channels.
- Giving an AI assistant a reliable base to answer questions about the range.
Write the purposes down. When someone asks for an attribute that serves none of them, you have a reason to say not yet.
Step 2: Gather the messy truth
Before drawing diagrams, look at what you have. Pull a sample of products across categories, suppliers and channels. Look at how names are written, which attributes are filled in, how units are expressed, and where records contradict each other.
You are looking for patterns of mess:
- The same attribute stored under several names.
- Free text where a controlled value should exist.
- Units mixed within a field: grams and kilograms, litres and millilitres.
- Categories that mean different things in different systems.
- Duplicates that differ by a typo or a pack size.
- Products that fit two categories and have been forced into one.
Keep a short log of examples. These become the test cases for your ontology, and the stories you use to explain it to others.
Step 3: Define the product classes
Start with a small tree. Aim for classes that matter to your purposes, not for a perfect scientific classification.
A few guidelines:
- Use a depth you can maintain. Three to four levels is usually enough at first. A deeper tree is harder to keep consistent.
- Make siblings mutually exclusive. If a product can belong to two siblings, either your categories overlap or you need a relationship or tag instead.
- Name classes in plain words. The names will be read by staff, suppliers and, increasingly, by language models. Clear words help all three.
- Leave room for “other, to be classified”. A holding class is better than a forced wrong placement, as long as it is reviewed.
Check the tree against your messy sample. If a quarter of the sample does not fit, the tree needs work.
Step 4: Define attributes and their rules
This is where most of the value is created.
Required, optional and derived
For each class, decide which attributes are required, which are optional, and which can be derived from others.
A required attribute is one without which the product cannot be sold, searched or priced correctly. A missing required attribute is an exception, and the product should not go live. An optional attribute adds value but does not block. A derived attribute is computed, such as price per unit from price and size, and should never be typed by hand.
Keep the required list short. The longer it is, the more likely people are to fill it with placeholders to get past the gate.
Allowed values and units
For each attribute, say what values are allowed. For categorical ones, a controlled list. For numeric ones, a unit and a sensible range. For text, a length and rules about what not to include, such as promotional wording inside a name field.
Units deserve special care. Decide on one stored unit per attribute and convert at the edges. Many painful errors in retail data come from a quantity that was right but in the wrong unit.
Write one line of definition for each attribute, in the language a store associate would use. If you cannot explain it that simply, the attribute is probably two attributes.
Step 5: Define relationships
Relationships turn a list of products into a network that systems can use.
Start with a few that carry real value:
- Pack relationship: a multipack contains N of a single item.
- Variant relationship: items that differ only by size, colour or flavour belong to one product family.
- Substitute relationship: items a customer would accept in place of another, which matters for out-of-stock handling and online substitutions.
- Complement relationship: items often bought or used together.
- Replacement relationship: a new item that supersedes an old one, which matters for range changes and stock carry-over.
Each relationship needs rules. A pack must point to a single item that exists. A replacement chain must not loop. A substitute should be in the same class or an approved neighbour. These rules are exactly the kind of checks a machine can run on every record, every night.
Step 6: Let a model propose, let a person approve
This is the step where generative AI earns its place, and where discipline matters most.
A language model is good at reading messy descriptions and proposing structure. Given a supplier’s free-text name and a short description, it can suggest the class, extract the size and unit, flag likely duplicates, and draft a clean name in your style. That work used to take people hours per hundred items.
But a model is a proposer, not an authority. The pattern that works is:
- The model reads the raw record and the ontology rules.
- It proposes values for the classes and attributes, with its confidence and the evidence it used.
- Rules check the proposal: required fields present, values allowed, units valid, relationships consistent.
- High-confidence proposals that pass all rules go through. Low-confidence or rule-failing proposals go to a person.
- The person’s decision is recorded and becomes training material and a new test case.
Two cautions. First, never let the model invent attributes that do not exist in the source. “Not stated” is a valid answer and much better than a confident guess. Second, measure the model on your own sample before trusting it, and keep measuring after, because supplier data changes and models drift.
Step 7: Turn maintenance into an exception process
Here is the shift that matters most for the people doing the work. Without structure, catalogue upkeep is a queue of everything: every new item, every correction, every supplier file, all handled by hand, and always behind.
With an ontology and rules, most records pass automatically, because they are complete, valid and consistent. What is left is a smaller queue of real exceptions: a product that fits no class, an attribute outside its range, a relationship that breaks a rule, a model proposal with low confidence. People now spend their time on the cases that need judgment.
To make this work in practice:
- Define the exception types. Missing required attribute, invalid value, unit conflict, probable duplicate, relationship violation, unclassifiable item.
- Give each type an owner and a target time.
- Show reviewers the evidence next to the proposal. The raw text, the model’s suggestion, the rule that failed.
- Make decisions one click where possible. Accept, correct, reject, escalate.
- Feed outcomes back. Repeated exceptions from one supplier suggest a supplier conversation, not a thousand manual fixes.
The quality of the catalogue becomes something you can measure: the share of records passing automatically, the size and age of the exception queue, the repeat causes.
Step 8: Govern change
An ontology is alive. New product types appear, channels demand new attributes, and regulations change what you must show. Without governance, the ontology slowly turns back into the mess it replaced.
A light structure is enough:
- A named owner for the ontology as a whole.
- A change request path for new classes, attributes and values, with a short reason and an impact check.
- Versioning, so that you know which rules applied when a record was approved.
- A regular review, monthly at first, to look at exceptions and decide what to change in the ontology and what to change upstream.
Governance is the part that people skip and then regret. A small, steady process beats a large, occasional one.
Common mistakes
- Modelling for completeness instead of purpose. A giant ontology no one can maintain is worse than a small one that is used.
- Mixing taxonomy and marketing. “Best sellers” and “new arrivals” are views, not product classes.
- Letting free text creep back in. If a controlled field has an “other” option that is overused, the list needs revising.
- Skipping units. It always costs more later.
- Trusting the model without a check. A fluent wrong answer is still wrong.
- Forgetting the people. If the reviewers find the tool slow or unclear, they will find workarounds, and the exceptions will move into spreadsheets.
- No feedback to suppliers. Fixing the same issue downstream forever is expensive.
A one-month starting plan
Week one. Choose the purposes. Pull a sample of a few hundred products from two or three categories. Log the patterns of mess.
Week two. Draft classes, required attributes, allowed values and units for those categories. Test them against the sample by hand and adjust.
Week three. Add the first relationships: packs, variants and replacements. Write the rule checks. Try a model on the sample as a proposer and compare its suggestions with what a person would decide.
Week four. Stand up the exception queue for those categories. Define owners, review the first batch together, and agree what changes in the ontology and what changes upstream.
At the end of the month you will not have a finished ontology. You will have a working loop on a small scope, evidence of what it saves, and a clear sense of what to extend next.
Closing thought
The sequence is the lesson. Structure first, then intelligence. A model placed on top of messy data amplifies the mess, quickly and with confidence. A model placed on top of a clear shared language becomes a patient assistant that handles the routine and leaves the judgment to people.
If you lead a catalogue, merchandising or retail data team and want to talk through where to start with your own range, I am happy to help. The first conversation is a free 20-minute call: https://topmate.io/raja_jeevan_kumar_maduri