How to Design a Taxonomy That Can Grow Without Constant Rework
How to separate concepts from labels, keep hierarchy shallow enough to govern, and add a branch without rewriting the catalog.
- 01 Name the decision
- 02 Separate label and concept
- 03 Limit the hierarchy
- 04 Plan for growth
Start from the decision the catalog has to support
A taxonomy is a set of concepts used to make a repeated decision. The decision might be where a record appears, which team reviews it, or which values are allowed in a field. If you cannot name the decision, you are collecting labels, not designing a classification.
Write the decision in one sentence before drawing a tree. “Which storefront grouping should list this record?” is a decision. “We need categories” is not. Different decisions often need different concept schemes. A scheme built for navigation will frustrate a scheme built for internal review if you force them to be the same tree.
Growth without rework means a new concept can be added, renamed in public, or narrowed without assigning a new identity to every record that already used the old one. That is a design constraint. It is not a promise that the first tree will be perfect.
Keep the concept separate from the label
People see words. The catalog should store a stable concept and attach words to it. When the public name changes, the concept stays, and records that point at the concept do not all need a new identifier.
SKOS, the Simple Knowledge Organization System, is a W3C Recommendation dated 18 August 2009. It models a knowledge organization system as a concept scheme made of concepts. The reference says a resource has no more than one skos:prefLabel per language tag, and that preferred, alternative, and hidden labels are pairwise disjoint. In operational language: one preferred wording per language, and a wording is not both preferred and alternative at the same time.
An alternative label is a real wording people use, not a junk drawer for typos you hope to delete later. If a wording is wrong, do not store it as an alternate. If people search for it, you can record it as a hidden label where your system supports that SKOS property. This page does not require a SKOS implementation. It uses those distinctions because they are already defined and public.
DCMI Metadata Terms says that for the subject of a resource, recommended practice is to refer to the subject with a URI, or otherwise with a literal, and that both should preferably point at a controlled vocabulary. A catalog can follow that practice without using Dublin Core as its whole data model: store the concept identifier, and treat the visible words as labels.
Before a new wording becomes a new concept, normalize the label. Two strings that differ only by case, spacing, or a unicode look-alike are not two concepts. They are a normalization problem that will look like taxonomy growth if you skip it.
Use hierarchy only where the decision needs it
A broader concept is more general. A narrower concept is more specific. SKOS states that skos:broader and skos:narrower are inverse properties: if A is narrower than B, then B is broader than A. You should not have to maintain both directions by hand if the system can derive one. If it cannot, pick one direction as the one people edit, and generate the other. Editing both is how trees contradict themselves.
Hierarchy is expensive. Every level is a governance decision: what belongs here, what belongs one step down, and what happens to records on the parent when a child is added. A deep tree feels precise and becomes impossible to explain. Prefer the shallowest tree that still supports the decision in the first section.
Categories and tags are not interchangeable just because both are words on a record. Use a category, or a single concept from a scheme, when the record must have one place in a governed list. Use tags when several independent labels can apply and none of them is the record’s primary place. If tags are secretly required and single-valued, they are a category with a casual name. Rename the practice so the rule is visible.
Do not use hierarchy to express “related to.” Sibling concepts that are merely associated should not be forced into parent and child. A false parent will pull records into the wrong group the moment someone queries “everything under this node.”
This table scrolls sideways on a narrow screen.
| Need | Use | Do not use |
|---|---|---|
| One place in a governed list | A concept in a scheme, with a broader link if the decision needs it | A free tag that happens to look like a path |
| Several independent labels | Tags or alternate labels, each allowed to be absent | A fake parent invented to hold them |
| A wording change only | A new preferred label on the same concept | A new concept and a bulk rewrite of records |
| A real split in meaning | A new narrower concept, with a map from the old one | A longer label on the old concept |
Add a branch on purpose
A new concept needs a reason, a preferred label for each language you actually publish, and a place in the scheme: top concept, or narrower than a named concept. It also needs an owner. Ownership of the vocabulary is the same kind of rule as ownership of a record. Someone must be allowed to add a concept, and someone else must not be able to add a near-duplicate because they could not find the first one.
Ask four questions before the concept is created.
- Which decision will change because this concept exists?
- Which existing concept is broader, if any?
- Which records should move, and which should stay on the parent until a person reviews them?
- What is the preferred label, and which alternate labels are real wordings rather than drafts?
If you cannot answer the first question, do not add the concept. A tree that grows because a spreadsheet had a new column will need a rewrite. The rewrite is the rework this page is trying to avoid.
Moving records is a migration, not a side effect. Keep the old concept identifier resolvable until the move is finished. Records that still point at it should show the old concept, not a silent gap. Retire the concept in the scheme, with a note of what replaced it, rather than deleting the identifier on the same day you add the new one.
Govern the vocabulary as a small catalog of its own
The concept scheme has its own quality bar. The metadata quality checklist applies to concept records as well as to the product or content records that use them. A concept with two preferred labels in the same language tag is a broken concept under the SKOS constraint cited above. A concept whose only label is a code nobody can read will pass a uniqueness check and fail every human task.
Review proposed concepts on the same cadence as other controlled values. An emergency label typed into a record and “added to the taxonomy later” is how the taxonomy fills with one-off strings. Either the emergency value is a real concept, with an owner, or it stays out of the scheme and the record uses a broader concept plus a note.
What this page does not claim
SKOS is a data model for sharing knowledge organization systems. It does not design your tree, and it does not say how many levels a retail or media catalog should have. Dublin Core’s subject guidance does not choose your subjects. This page uses both as public definitions so the editorial method has something stable to point at. The decisions about depth, tags, and migration are the publication’s method. They are not quotations from those documents.
When the taxonomy should change
When is a new label enough?
When the meaning is unchanged and only the public wording moved. Keep the concept. Replace the preferred label. Keep the old wording as an alternate if people still use it.
When needed: A rename, a spelling correction, or a language update.
When do you need a new concept?
When records that shared a concept now need different decisions. Split them with a narrower concept and an explicit move, not with a longer name.
When needed: A real change in how records are grouped, reviewed, or published.
When should you refuse a level?
When the new level does not change the decision from the first section. Extra depth feels precise and adds a parent nobody will govern.
When needed: A proposal whose only justification is that the tree looks incomplete.
Sources
- SKOS Simple Knowledge Organization System Reference — W3C
- DCMI Metadata Terms — Dublin Core Metadata Initiative