Can a taxonomy improve an AI classifier?

It can clarify the labels the classifier must predict, but predictive performance still requires evidence.

Is a taxonomy an ontology?

A taxonomy may form part of an ontology; an ontology can express additional properties, relationships, and constraints.

Should everything have one category?

That depends on the scheme. A single-label task and a multi-label task require different rules.

AI Glossary / Governance, ethics and safety / Advanced

Taxonomy

Definition

A taxonomy is an organized classification of categories, usually arranged from broader categories to more specific ones. In the AI knowledge-representation sense used here, a taxonomic hierarchy connects categories through subclass relationships: members of a narrower class are also members of its broader class. Taxonomies help people and systems organize information, assign labels, navigate collections, and interpret how categories relate.

What it means

A taxonomy does more than list names. It explains a structure. For example, an organization might place maintenance manuals and installation guides under technical documents. The hierarchy can support a search for all technical documents without requiring users to name every narrower category.
The categories and relationships must have a defined purpose. A hierarchy for browsing website topics may differ from one used to classify customer requests. Similar labels do not guarantee equivalent meanings, and a useful structure for one task should not be assumed suitable for another.

How it works

Define the scope, establish category meanings, and specify the relationship used between levels. In a strict subclass hierarchy, every member of a child class belongs to its parent. If installation guides are a subclass of technical documents, a particular installation guide is also a technical document.
Universal properties of a parent class apply to its subclasses under that interpretation. Typical or default properties require additional rules about exceptions; a hierarchy alone does not make every generalization universally true.
Knowledge-organization systems may use broader and narrower relationships more flexibly. W3C SKOS supports hierarchical concept links, labels, and associative relationships. Such links should not automatically be interpreted as formal OWL subclass axioms. An ontology can add richer relationships and logical statements beyond a taxonomy, so the terms are related but not identical.

Three practical examples

An AI support classifier assigns requests to account access, payments, or technical problems, with more specific categories beneath each. Clear category boundaries help reviewers interpret and correct predictions.
A document search system lets users browse product documentation and then narrow to installation guides. The hierarchy supports navigation, while actual retrieval quality still depends on correct tagging and search behavior.
An AI inventory groups systems by application purpose. A taxonomy can support reporting across related uses, provided the organization documents whether a system may occupy several categories and how totals are counted.

Think of it this way

A taxonomy resembles a carefully labeled filing structure. The labels say what belongs in each place, and the arrangement shows which places fall within larger groupings. The structure is useful only if people agree on the meaning of the labels and apply the filing rules consistently.

Worked example

Consider an invented document taxonomy. Technical documents contains two subclasses: installation guides and maintenance manuals. A collection includes 30 installation guides and 25 maintenance manuals. Five documents belong to both categories because they cover both purposes.
The number of distinct documents in either subclass is 30 + 25 minus 5 = 50. Simply adding the category counts would report 55 and count the shared documents twice.
Suppose another ten technical documents belong to neither of those two subclasses. The parent category then contains 60 distinct documents. The children do not exhaust the parent merely because they appear beneath it in a diagram. Exhaustiveness must be an additional design rule or verified property.
Now suppose every technical document in this fictional scheme must identify its applicable product. Installation guides inherit that universal requirement because they are technical documents. However, a statement that technical documents are usually written in English does not establish that every installation guide is English.
This example distinguishes subclass membership, overlap, coverage, and universal properties. Each affects how an application should interpret the hierarchy; none can safely be inferred from indentation alone.

Illustrative case study

Fictional company WillowKnowledge builds an AI assistant for internal documentation. Its existing folders mix document type, department, and urgency at the same level. Reviewers disagree about where a troubleshooting guide belongs, and the assistant's category filters return inconsistent results.
The team separates document type from department and urgency. It defines the document-type taxonomy, keeps the other dimensions as separate metadata, and records examples of borderline cases. It permits a document to have multiple applicable types when the definitions genuinely overlap.
The team then reviews a sample of tagged documents and tests whether users can find the material they need. This fictional case illustrates improving the meaning of a classification scheme before automating its application. It does not claim that organizing labels alone guarantees better answers.

Common misconceptions and mistakes

“A taxonomy is just a glossary.” A glossary explains terms; a taxonomy organizes categories and their relationships.
“Every taxonomy must be a single-parent tree.” Some schemes allow multiple broader categories, producing a hierarchy with multiple paths.
“Sibling classes cannot overlap.” Disjointness must be specified; it is not implied merely by sharing a parent.
“A related topic is automatically a subclass.” Battery maintenance is related to batteries, but a maintenance activity is not a kind of battery.
“AI-generated categories need no review.” Proposed categories still need coherent definitions, suitable coverage, and validation against the intended use.

Business use

Use a taxonomy when consistent classification would help people find information, route work, or compare activity. Begin with actual questions the structure must answer. Test definitions on realistic examples and document how ambiguous cases are handled.
Assign responsibility for changes. Renaming a category may be simple, while splitting its meaning can affect old labels, reports, and training data. Preserve identifiers and mappings where appropriate, and avoid comparing results across changed category definitions without explaining the change.

Check your understanding

Why are there 50 distinct documents across the worked example's two subclasses?

Answer: Five belong to both and must be counted once.

Do the two subclasses necessarily contain every technical document?

Answer: No; the example includes ten others.

Why distinguish a related link from a subclass link?

Answer: They support different interpretations and inferences.

Related terms

Learn next

Create a small taxonomy for ten example documents. Define each category, test whether every subclass relationship is valid, and state whether overlaps and uncategorized cases are allowed. Check the resulting counts using distinct items.

Sources

Russell and Norvig, AIMA glossary, taxonomy: https://github.com/aimacode/aima-glossary/blob/master/glossary.md W3C, SKOS Simple Knowledge Organization System Primer: https://www.w3.org/TR/skos-primer/ W3C, OWL 2 Web Ontology Language Primer, class hierarchies and disjointness: https://www.w3.org/TR/owl2-primer/

Previous: Task decomposition Next: Taylor expansion