- One governed category and attribute model shared by search, filters, feeds and the assistant
- Catalogue loads validated on every run, with failing products quarantined and explained
- Synonyms and preferred labels managed once and reused by search and the assistant
- Merchandisers able to change the taxonomy through review, not engineering tickets
Anonymised composite. Client names, identifying details and confidential figures are withheld; public facts are cited in the references.
The situation
An online retailer sold products from many suppliers. Each supplier feed brought its own category tree, attribute names and conventions: one sent "colour", another "color_name", a third put colour in the title. Sizes, materials and units varied by feed. The internal category tree had grown by accretion, with near-duplicate branches and categories that meant different things to different teams.
The symptoms were familiar. Filters returned partial results because half the products lacked the attribute being filtered. Search relied on hand-maintained synonym lists. A new AI shopping assistant made the problem more visible: asked to compare products, it reasoned confidently over data that was inconsistent underneath.
What had to be true
- One model of meaning for categories and attributes, shared by search, filters, feeds and the assistant.
- Mapping, not rewriting: supplier data is mapped to the model, with the original preserved.
- Validation on every load, so bad data is caught before customers see it.
- Business ownership: merchandisers change the taxonomy through review, without engineering in the loop for every edit.
- Standards, not a bespoke format, so the model outlives any one tool.
Architecture
The taxonomy was modelled in SKOS, which is designed for concept schemes with broader and narrower relations and preferred and alternative labels1. A deliberately small OWL core covered the classes and properties that needed formal definitions2. The reasoning behind that split is in SKOS vs OWL for enterprise taxonomies.
The data flow, end to end
- ReceiveSupplier feed lands raw, unchanged, with supplier and load identifiers
- MapSupplier categories and attributes mapped to concepts and properties
- NormaliseUnits converted, values matched to controlled lists, originals kept
- ValidateSHACL shapes check required attributes and values per category
- PublishValid products to search, facets and the assistant; failures quarantined
- ImproveZero-result queries and quarantine reasons feed the taxonomy backlog
SHACL describes the conditions data must meet and produces a validation report, which made it a natural release gate for each load3. Patterns for writing shapes are in SHACL validation for knowledge graphs.
The hard part: attributes, not categories
Agreeing a category tree was comparatively quick. Agreeing attributes was not, because attributes are where search filters and assistant answers actually come from. The work that made a difference:
- Attributes defined per category, with required, recommended and optional tiers, so a shape knows what "complete" means for a sofa versus a shoe.
- Controlled value lists with preferred and alternative labels, so "navy", "dark blue" and supplier codes resolve to one value while search still matches all of them.
- Canonical units with conversion at load, never in the search layer.
- Duplicate and variant handling, the same product from two suppliers, which is an entity resolution problem in its own right; see entity resolution for knowledge graphs.
An AI assistant is only as consistent as the attributes it reads. Many apparent "hallucinations" about products turn out to be faithful readings of contradictory data.
How the engagement ran
- Proposes category changes
- Approves attribute rules
- Owns value lists
- Maintains supplier mappings
- Runs validation
- Works the quarantine
- Consume published model
- Report zero-result gaps
- Test assistant answers
- Feed and attribute inventory
- Search log analysis
- Highest-value categories
- SKOS category scheme
- Attribute core
- First SHACL shapes
- Supplier mappings
- Validation gate
- Quarantine and reports
- Search and facets
- Assistant integration
- Governance workflow
Product pages also emitted schema.org Product markup generated from the same model4, so structured data for external search stayed consistent with internal search. More in structured data for AI search.
Key decisions and trade-offs
| Decision | Alternative | Why |
|---|---|---|
| SKOS for the taxonomy | Full OWL ontology | Labels and hierarchy are what categories need; easier for the business to own |
| Small OWL core | No formal model at all | Precise definitions where products are compared and filtered |
| SHACL as a load gate | Ad hoc scripts in the pipeline | Declarative, standard rules with readable reports |
| Keep supplier originals | Overwrite on mapping | Mappings can be corrected and replayed |
| Assistant reads structured attributes | Assistant reads raw descriptions | Comparisons and filters grounded in validated facts |
What I'd do again, and differently
Again: start from search logs and the categories that matter commercially, and make validation a gate rather than a report. Differently: put merchandising ownership and the review workflow in place before the model grows, not after. A taxonomy without a clear owner drifts back to where it started.
If your catalogue or knowledge model has the same symptoms, the ontology and knowledge graph page describes how I approach it, or analyse your challenge and bring the result to a call.
- 1
- 2
- 3
- 4ProductSchema.org