What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
To support a taxonomy that can grow to any depth, model concepts as stable records connected by broader–narrower relationships—not as separate fields or entity types for each level. Keep direct parent links, calculate ancestor paths when needed, and add explicit level metadata or versioning only when the classification requires it.
What changes when you move beyond fixed levels?
A fixed-depth design often represents hierarchy with fields such as level_1, level_2, and level_3, or with a different record type for each rank. That design makes depth part of the schema: adding another rank can require a schema change and updates to code that assumes a particular number of levels.
An extensible design treats each category as a concept with its own identity. Hierarchy is stored as relationships between concepts, so another level means another relationship rather than another column. You can implement this pattern in a relational database with concept and relationship tables, or in a graph or RDF model. These are implementation options, not requirements of the SKOS standard.
SKOS, the W3C’s Simple Knowledge Organization System, is a vocabulary and data model for knowledge organization systems such as taxonomies, classifications, and thesauri. It provides a useful conceptual foundation, including concepts, labels, notes, schemes, and semantic relationships. It does not prescribe your storage technology, taxonomy depth, or governance process. W3C SKOS Reference
#1 Best Overall
How should concepts and hierarchy be represented?
Give concepts stable identities
Assign each concept an identifier that does not depend on its preferred label or current position. Store preferred and alternative labels as labels, rather than using a label as the identity. If a concept is renamed or moved to a different branch, its identifier can remain stable for records and systems that refer to it.
Keep scheme membership and hierarchy distinct from identity. In SKOS, concepts can be associated with a concept scheme, have lexical labels and notes, and be connected by semantic relations. This separation makes it possible to reorganize a classification without treating every move as a new concept. W3C SKOS Reference
Store immediate broader–narrower links
Represent the intended local structure with direct links between concepts. In SKOS, skos:broader and skos:narrower express immediate hierarchical relationships. The W3C reference says these properties are not transitive: a direct link from one concept to another does not itself assert every more distant ancestor or descendant. W3C SKOS Reference
Crashes, No Sound, or Screen Glitches?
Random freezes, missing sound and display glitches usually trace back to one bad driver. Find and replace yours safely.Free scan · under a minuteWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstallWhen an application needs the full path—for example, to include all ancestor topics in a search—calculate the ancestor closure or use the transitive properties skos:broaderTransitive and skos:narrowerTransitive. Keeping direct editorial links separate from derived paths preserves the structure editors actually asserted while still supporting broader queries.
Distinguish hierarchy from association
Use a broader–narrower link only when one concept genuinely sits within another in the classification. If two concepts are related but neither is a broader category of the other, model that connection as an associative relationship, such as SKOS’s skos:related. This prevents a hierarchy from becoming a general-purpose web of related topics. W3C SKOS Primer
Should a concept have one parent or several?
A single-parent tree is easier to navigate and validate when each concept belongs in exactly one broader context. A polyhierarchy allows a concept to have multiple broader concepts when it genuinely belongs under more than one classification context. SKOS permits multiple broader concepts; that flexibility should reflect the domain, not merely make navigation shortcuts convenient. W3C SKOS Primer
| Design choice | What it supports | Decision to make |
|---|---|---|
| One broader concept | A simpler tree structure | Does each concept have one legitimate place in the hierarchy? |
| Multiple broader concepts | More than one valid classification context for a concept | Does the domain require those multiple contexts, and can users understand the resulting navigation? |
| Associative relation | A meaningful connection that is not hierarchical | Are the concepts related without one being a category of the other? |
When should levels be explicit?
Variable depth does not mean level names are forbidden. If a classification publishes ranks such as section, division, class, or subclass—or if application rules depend on rank—represent that information separately from concept identity and parentage. FAO’s Caliper guidance provides one example: it models levels as collections of concepts and describes using a depth property to express generality. FAO Caliper data modeling
Do these 3 things before closing this tab:
1Fix the driver behind crashes, sound loss and screen glitches2Repair Windows errors before they cause bigger problems3Scan for outdated or missing drivers - takes under a minuteIf levels are only a visual consequence of the hierarchy, derive depth from the path instead of storing fixed level fields. If named ranks carry meaning, retain them as explicit metadata or collections. This keeps the taxonomy extensible while allowing consumers to use rank-specific information where it matters.
How should a changing taxonomy be versioned?
Classifications evolve: concepts may be renamed, split, merged, added, or moved. If consumers need to compare releases, migrate records, or aggregate data across them, make the scheme version explicit rather than silently replacing the old structure. FAO’s Caliper example uses versioned concept-scheme URIs and version information. It also distinguishes exact from close correspondences; a close match can represent a mapping that is not one-to-one. FAO Caliper data modeling
Keep mappings between versions when they help downstream users understand what changed. Do not assume that a renamed concept, a split, or a merger is always an exact match. The right mapping depends on how the meaning and scope changed.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What maintenance rules should accompany the model?
A flexible data model does not determine who may change the classification or how changes are reviewed. Define a maintenance process that covers at least these decisions:
- Who can propose and approve new concepts, label changes, and broader–narrower links?
- How are duplicate labels distinguished, and what happens when concepts are merged?
- How are orphan concepts and cycles detected and resolved?
- When is a new version published, and how are changes communicated to consumers?
- What is the policy for a topic with only one child?
GOV.UK’s topic-taxonomy principles illustrate context-specific responses to a single-child branch: merge the child into its parent, move it to the same level, or introduce sibling topics under a new parent. The same guidance also allows tagging content to a broader topic in suitable cases. These are practical options from a government topic taxonomy, not universal rules for every domain. GOV.UK Taxonomy principles
Quick Recap
Which design choices should you settle first?
| Question | Simpler approach | More expressive approach | Choose based on |
|---|---|---|---|
| How many broader concepts can an item have? | One parent | Multiple parents | Whether the domain has genuinely multiple classification contexts |
| How are distant ancestors found? | Store and query direct links | Compute or materialize transitive closure | Whether users or search need ancestors beyond the immediate parent |
| Are ranks meaningful? | Derive depth from the relationship graph | Represent named levels or depth metadata | Whether the classification publishes ranks or applies rank-specific rules |
| How are changes released? | Replace the current structure | Version schemes and preserve mappings | Whether consumers must compare or migrate between releases |
| How are edits controlled? | Informal editorial changes | Reviewed changes and a publication workflow | The impact inconsistent labels or links would have on downstream users |
A practical implementation sequence
- Define the concept. Decide what qualifies as a distinct concept in your domain and assign it a stable identifier.
- Separate labels from identity. Store preferred and alternative labels as descriptive data so label edits do not change references.
- Choose relationship semantics. Record immediate broader links for hierarchy and use associative links for non-hierarchical connections.
- Decide on parent count. Use a tree if one broader context is sufficient; permit multiple broader links only where the domain needs them.
- Add level metadata only where useful. Preserve named ranks or depth when consumers need them; avoid fixed level columns as the hierarchy’s foundation.
- Plan traversal and validation. Specify how applications find ancestors and descendants, and how editors detect cycles, orphans, and duplicate concepts.
- Set change and release rules. Decide how concepts are reviewed, how scheme versions are represented, and how mappings are maintained for consumers.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
