Controlled vocabulary
A controlled vocabulary is a fixed, approved list of the values an attribute is allowed to hold: the only entries a field like Finish or Drive Type may contain. Anything a supplier writes outside that list is either mapped back into it or rejected. Controlled vocabularies are what make attributes filterable, comparable across brands, and readable by search engines and marketplace feeds.
What a controlled vocabulary actually is
Every attribute has a domain: the set of values it can legally hold. A controlled vocabulary makes that set explicit and enforceable.
Take Drive Type on a fastener. Suppliers submit "hex", "Hex", "HEX HD", "hexagon", "6-point", "Allen", "socket cap". Two distinct drives — external hex and hex socket — wearing seven labels, and three of those labels describe the head, not the drive. A controlled vocabulary declares the legal set (Hex, Hex Socket, Phillips, Torx, Slotted, Square) and forces every incoming string to resolve to one of them or get rejected.
Two parts make it work:
- The term list. The canonical values, each with a plain-language definition and a stable ID that survives relabeling.
- The synonym ring. Every alias, abbreviation, misspelling, and vendor-ism that maps to a canonical term.
Skip the synonym ring and you have a dropdown nobody can populate at scale. Build both and you have a machine that takes messy supplier text and returns one known value, the same way every time.
The synonym ring is never finished. Every supplier onboarding mints new aliases: a new vendor's spec sheet arrives with Hx Skt or int hex and your map has never seen either. Categories drift too, as manufacturers rename finishes and standards bodies add grades.
So treat the ring as a living asset with a queue for the strings that fail to match, not a file someone wrote once and closed. That unmatched queue is the honest measure of how well the vocabulary covers what suppliers actually send.
What it looks like on a real SKU
Here is a 3/8-16 Grade 8 hex bolt as four different suppliers described it, next to the value a controlled vocabulary resolves to.
| Attribute | Free-text values received | Controlled value |
|---|---|---|
| Thread Size | 3/8-16, 3/8 x 16, .375-16 UNC, 3/8in-16 | 3/8-16 UNC |
| Grade | G8, Gr. 8, grade eight, SAE J429 Gr8 | Grade 8 |
| Drive Type | hex, HEX HD, hex head, hexagonal | Hex |
| Finish | zinc, Zinc Plated, ZP | Zinc Plated (Clear) |
| Finish | yellow zinc, zinc yellow chromate, YZ | Zinc Plated (Yellow) |
| Material | steel, alloy stl, med carbon alloy | Alloy Steel |
The left column is unfilterable. A shopper who checks "Grade 8" in a facet sees one of your four bolts and assumes you don't stock the rest.
The same pattern hits electrical. A UL listed 600V wire connector arrives as 600V, 600 volts, 600VAC, rated up to 600V. The controlled answer is a numeric 600 in Voltage Rating with V in the unit field. The unit belongs in the UOM, not glued to the number.
Rules for a vocabulary that survives real suppliers
Most vocabularies fail in the same handful of ways. These rules prevent it:
- One concept per term. If Hex and Hex Socket both collapse into "Hex", the facet lies to the buyer. Split them.
- IDs, not labels. Terms need a stable key. Renaming "Zinc Plated" to "Zinc-Plated" should not orphan every SKU carrying it.
- Units out of the value string.
600Vis a label. 600 plus V is data. - Have a policy for nulls and ranges. "N/A", "varies", and "see chart" are answers you will receive. Decide now whether they are legal.
- Cap the list. If Finish carries 400 values, you have free text with extra steps. A long value tail signals missing synonyms, not real product variety.
- Give every term an owner and a retirement path. Vocabularies rot when nobody can approve an addition.
- Borrow before you build. ETIM, eCl@ss, UNSPSC, GS1 GPC, and Google's product category tree already publish vocabularies for many fields. Adopt, then extend.
Vocabulary vs taxonomy vs schema vs normalization
These four get used interchangeably in meetings. They are different layers of the same stack.
| Layer | What it controls | Example |
|---|---|---|
| Taxonomy | Where a product sits | Fasteners > Bolts > Hex Bolts |
| Attribute schema | Which fields that category requires | Hex Bolts need Thread Size, Grade, Drive Type, Finish |
| Controlled vocabulary | Which values each field may hold | Finish is one of: Zinc Plated, Hot-Dip Galvanized, Black Oxide, Plain |
| Normalization | The act of moving a value into the vocabulary | ZP becomes Zinc Plated |
Read it top to bottom. Taxonomy picks the aisle, the schema picks the questions, the vocabulary picks the legal answers, and normalization does the answering. Skip the vocabulary and normalization has no target to aim at.
Who does this work
PIMs are built to hold this. Reference lists, select attributes, and validation rules are standard container features. Storing and enforcing a vocabulary is a solved problem.
The unsolved part is upstream. Someone has to decide which Finish values are legal for your fastener categories, write the synonyms suppliers actually type, then push your existing free text through that map and flag the strings that don't resolve. That is analyst work, done once per category and then again every time a new supplier onboards.
The PIM stores your product data. Anglera does the work of completing it: building the term lists, mining synonyms out of your existing catalog and supplier spec sheets, normalizing the values, and routing the genuine ambiguities to a human instead of guessing. The vocabulary lands in your PIM, in your schema, under your governance.
Frequently asked questions
What's the difference between a controlled vocabulary and a taxonomy?
A taxonomy classifies products into categories: Fasteners > Bolts > Hex Bolts. A controlled vocabulary constrains the values inside an attribute on those products: Finish must be Zinc Plated, Hot-Dip Galvanized, Black Oxide, or Plain. Taxonomy answers "where does this SKU live?" Vocabulary answers "what may this field say?" You need both, and they are usually governed by different people on different cycles.
How many values should an attribute's controlled vocabulary have?
Few enough that a buyer can scan the facet without scrolling. If Finish has grown to 400 values, nobody has mapped the tail yet. Long value tails almost always mean missing synonyms rather than genuine product variety. Collapse the tail before you publish the facet, not after, and judge the list by whether a buyer can read it rather than by a target count.
Should we build our own vocabularies or adopt a standard like ETIM or UNSPSC?
Adopt first, extend second. ETIM and eCl@ss already define values for electrical and industrial attributes, and marketplaces enforce their own accepted-value lists. Starting from a standard buys you supplier alignment and syndication compatibility without arguing about it internally. Then add the handful of proprietary terms your categories genuinely need, and keep a mapping back to the standard so your feeds don't break.
Doesn't our PIM already give us controlled vocabularies?
PIMs give you the container — a fixed-value attribute type that enforces a set list of values. What the container does not do is decide which values belong on the list, write the synonym rings that catch "ZP" and "yellow zinc", or map the supplier strings already sitting in your catalog into that list. Deciding and mapping happen outside the tool, and someone still has to do them.
How do controlled vocabularies affect AI search and answer engines?
Language models and shopping agents extract facts, not prose. A field reading Voltage Rating: 600 with unit V is a fact they can lift and compare against a competitor's SKU. A description reading "rated up to 600 volts" is a sentence they have to guess about. Controlled values also feed clean JSON-LD and marketplace feeds, which is how a SKU becomes a candidate answer.