Concept Taxonomies and Ontologies
Summary
Covers how concepts are grouped into balanced, non-overlapping categories using taxonomies and ontologies. Introduces the mechanics of taxonomy classification (TaxonomyID, node groups, concept-to-taxonomy mapping) along with the graph-theory operations — abstraction and clustering — needed to keep a taxonomy well-formed.
Concepts Covered
This chapter covers the following 13 concepts from the learning graph:
- Concept Taxonomy
- Ontology
- TaxonomyID
- Taxonomy Classifier
- Taxonomy Category
- Taxonomy Distribution Report
- Taxonomy Legend
- Node Group
- Concept-to-Taxonomy Mapping
- Balanced Taxonomy
- Miscellaneous Category
- Abstraction (Graph)
- Clustering (Graph)
Prerequisites
This chapter builds on concepts from:
Welcome back!
Let's connect the concepts! Chapter 3 gave you the vocabulary to reason about a single dependency chain — one concept leading down to its prerequisites. But a real learning graph for a 200-concept course is not one chain. It is hundreds of concepts and thousands of edges, and a learner staring at that raw tangle has no way to orient themselves. This chapter introduces the second organizing structure every learning graph needs: a way to group concepts into categories a human can actually scan.
A dependency graph answers "what must I learn before this?" A taxonomy answers a completely different question: "what kind of thing is this?" Both structures live on top of the same set of concept nodes, but they serve different purposes — one sequences, the other classifies. This chapter builds the vocabulary and tooling for classification, then closes with two graph-theory operations, abstraction and clustering, that keep a large taxonomy from collapsing into an unusable pile of near-duplicate categories.
Concept Taxonomy: Grouping Without Sequencing
A Concept Taxonomy is a set of categories used to classify every concept in a learning graph by subject area or type, independent of the prerequisite structure covered in Chapter 3. Where a dependency edge says "learn this first," a taxonomy category says "this concept belongs to this group." A course on learning graphs, for example, might sort its concepts into categories like "Graph Theory," "Metadata Standards," "Visualization," and "Learning Science" — categories that say nothing about which concept must come before another, only what family of ideas each concept belongs to.
Every concept in a well-formed taxonomy belongs to exactly one category. This single-category rule is what makes a taxonomy useful for navigation: a learner browsing "Metadata Standards" should never wonder whether a concept they're looking for was filed under "Graph Theory" instead. A taxonomy in the general sense (outside this book's specific usage) is simply a classification scheme; a concept taxonomy is that same idea applied specifically to the nodes of a learning graph.
The building relationship between Chapter 3's dependency vocabulary and this chapter's taxonomy vocabulary is worth stating plainly before we go further:
- A dependency graph organizes concepts by what must be learned first — vertical, prerequisite order.
- A concept taxonomy organizes concepts by what category they belong to — horizontal, thematic grouping.
- The two structures share the same set of nodes but use entirely different edges (or, in the taxonomy's case, no edges at all — just a label on each node).
Key Insight
Don't confuse "depends on" with "belongs to." A concept taxonomy is not a shorter or simpler dependency graph — it is a different kind of structure altogether, closer to a filing system than a roadmap. A course-design tool needs both: the dependency graph to sequence content, and the taxonomy to organize navigation, search, and reporting.
Ontology: When Categories Get Relationships of Their Own
A concept taxonomy sorts concepts into categories, but it says nothing about how those categories relate to each other. An Ontology is a formal representation of knowledge as a set of concepts within a domain and the relationships between those concepts — a structure one level more expressive than a taxonomy, because it can capture relationships like "is a type of," "is part of," or "requires," not just flat category membership.
Every concept taxonomy is a simplified ontology: it is the special case where the only relationship being modeled is "belongs to category X." A full ontology can go further — it might specify that "Taxonomy Category" is a type of "Classification Node," or that "Ontology" itself is part of a broader family of knowledge-representation structures. This book deliberately works with the simpler taxonomy structure for classifying concepts, because a flat, single-category system is far easier for both humans and generative AI tools to build, validate, and keep balanced across hundreds of concepts. Where the course description mentions ontologies for classifying concepts, it is describing this same taxonomy-building work, using the more general term from the knowledge-representation field.
Naming a Category: TaxonomyID and Taxonomy Category
Building a usable taxonomy requires two more precise pieces of vocabulary: a way to identify each category and a way to describe what that category contains.
A TaxonomyID is the unique identifier assigned to a single category within a concept taxonomy — a short code (often numeric, like 1 through 12) that every concept-to-category assignment references instead of repeating the category's full name. A Taxonomy Category is the human-readable label and description attached to a TaxonomyID — the actual name a learner sees, such as "Graph Theory" or "Visualization Tools," along with a short explanation of what belongs there. The TaxonomyID is the machine-facing key; the taxonomy category is the human-facing name that key points to.
This split matters for the same reason Chapter 2's distinction between a concept's ID and its preferred label mattered: IDs are stable and compact for software to store and compare, while labels are what a person reads. A concept-taxonomy dataset typically stores a small lookup table of TaxonomyIDs to category names, then tags each concept node with only the ID.
Before looking at how a full taxonomy is structured, let's define one more term this book uses specifically for the process of assigning categories.
A Taxonomy Classifier is the process — whether performed by a human editor or a generative AI tool — that examines each concept in a learning graph and assigns it to the single most appropriate taxonomy category. Given a concept like "Force-Directed Layout," a taxonomy classifier decides it belongs under "Visualization Tools" rather than "Graph Theory," using the concept's label, definition, and context within the graph to make that call.
The table below summarizes the four terms introduced so far, now that each has been explained individually.
| Term | Role |
|---|---|
| Concept Taxonomy | The full classification scheme — the complete set of categories |
| TaxonomyID | The unique short code identifying one category |
| Taxonomy Category | The human-readable name and description behind a TaxonomyID |
| Taxonomy Classifier | The process (human or AI) that assigns each concept to a category |
The diagram below lets you run a small taxonomy classifier yourself: pick a concept, see its label and definition, and assign it to the category you think fits, then check your assignment against the reference classification.
Diagram: Taxonomy Classifier Workbench
View Taxonomy Classifier Workbench Fullscreen
Taxonomy Classifier Workbench
Type: microsim
sim-id: taxonomy-classifier-workbench
Library: p5.js
Status: Specified
Purpose: Let learners practice the taxonomy-classifier task by hand — reading a concept's label and short definition, then choosing which TaxonomyID/Taxonomy Category it belongs to — before trusting an AI tool to do it at scale.
Bloom Level: Apply (L3) Bloom Verb: classify, apply
Learning objective: Given a concept label and definition, the learner can select the single most appropriate taxonomy category from a fixed set of options and explain why competing categories are a worse fit.
Canvas layout: - Top (100px): concept card showing a concept label in bold and a one-sentence definition below it - Middle (300px): six category buttons arranged in a grid, each showing a TaxonomyID (1-6) and its Taxonomy Category name: "1: Graph Theory", "2: Metadata Standards", "3: Visualization Tools", "4: Learning Science", "5: Personalization", "6: Governance & Validation" - Bottom (120px): feedback panel and "Next Concept" button
Sample concept deck (8 cards, cycled): - "Force-Directed Layout" — "A physics-based algorithm that positions graph nodes by simulating repulsion and spring forces." Correct: Visualization Tools - "Cycle Detection" — "A check that confirms a graph contains no circular dependency chains." Correct: Governance & Validation - "Zone of Proximal Development" — "The gap between what a learner can do alone and with guidance." Correct: Learning Science - "Hop Count" — "The number of edges separating two concepts along a prerequisite chain." Correct: Graph Theory - "SKOS" — "A W3C standard vocabulary for expressing preferred and alternate labels." Correct: Metadata Standards - "Adaptive Learning Path" — "A sequence of concepts customized to one learner's mastery state." Correct: Personalization - "Orphaned Node" — "A concept with no incoming or outgoing dependency edges." Correct: Governance & Validation - "Node Group" — "A collection of interconnected nodes treated as a unit for visualization." Correct: Visualization Tools
Interactive controls: - Click a category button to submit a classification - "Next Concept" button advances the deck (wraps to start after the last card) - "Show Reasoning" toggle reveals a one-sentence explanation of why the correct category fits best
Behavior: - Correct click: button flashes green, feedback panel states "Correct — {category} is the best fit because {reasoning}." - Incorrect click: chosen button flashes red, feedback panel states "Not quite. {Category chosen} usually holds concepts like {example}. This concept fits {correct category} better because {reasoning}." - Running score displayed as "Correct: X / Attempted: Y" in the top-right corner
Default parameters: concept deck starts at card 1, score reset to 0/0
Implementation notes: - Use p5.js for rendering and click detection on button regions - Store the concept deck as an array of objects with label, definition, correctCategoryId, and reasoning fields - Responsive: canvas width tracks container width, category grid reflows from 3 columns to 2 columns below 500px
The Category List: Node Group and Miscellaneous Category
A taxonomy category, once defined, needs a way to refer to the actual concepts sitting inside it. A Node Group is a collection of interconnected nodes within a graph that share common characteristics or relationships, often treated as a unit for analysis or visualization. In the context of a concept taxonomy, the node group for a given taxonomy category is simply the set of every concept node currently assigned that category's TaxonomyID — "the Graph Theory node group" means every concept tagged with the Graph Theory TaxonomyID, considered together.
Node groups matter beyond bookkeeping. Chapter 5's visualization tools use node groups to color-code concepts in a diagram, collapse an entire category into a single summary node, or filter a crowded graph down to just one subject area at a time — all operations that depend on every concept already carrying a clean category assignment.
No classification scheme, however carefully built, achieves perfect coverage on the first pass. Some concepts genuinely resist a clean category assignment — they might touch three categories equally, or be too new and specialized for any existing category to fit well. A Miscellaneous Category is a deliberately defined catch-all taxonomy category reserved for concepts that do not cleanly fit any other category, used sparingly and monitored closely rather than treated as a dumping ground. A well-run taxonomy tolerates a small miscellaneous category — a handful of edge-case concepts — but treats a large one as a warning sign that the category scheme itself needs revision.
Watch Out
A miscellaneous category above roughly 5% of your total concepts is a red flag, not a convenience. It usually means one of two things: either a real category is missing from the scheme entirely, or the taxonomy classifier is being applied too hastily. Resist the urge to let "Miscellaneous" quietly grow — audit it regularly and split out new categories when a pattern emerges among the leftovers.
Recording the Assignment: Concept-to-Taxonomy Mapping
Everything so far has described the scheme — the categories, their IDs, the classifier process, the miscellaneous safety valve. None of it is useful until every individual concept is actually tagged. A Concept-to-Taxonomy Mapping is the specific data structure — typically a table or a field on each concept node — that records which TaxonomyID each individual concept has been assigned. If the taxonomy is the list of possible categories, the concept-to-taxonomy mapping is the record of which concept went into which bucket.
In practice, this mapping is usually as simple as a two-column table: concept ID and TaxonomyID. The example below shows a small slice of what that mapping looks like for concepts introduced earlier in this book.
| Concept | TaxonomyID | Taxonomy Category |
|---|---|---|
| Force-Directed Layout | 3 | Visualization Tools |
| Cycle Detection | 6 | Governance & Validation |
| Hop Count | 1 | Graph Theory |
| SKOS | 2 | Metadata Standards |
| Adaptive Learning Path | 5 | Personalization |
Storing the mapping this way — as a flat lookup rather than embedding the category name directly on every concept — means the taxonomy can be renamed, reorganized, or re-balanced later without touching every concept record individually. Only the small category lookup table changes; the mapping table's TaxonomyID values stay valid.
Seeing the Whole Scheme: Taxonomy Legend
A concept-to-taxonomy mapping is a table meant for software to query. A human skimming a rendered learning-graph diagram needs a different artifact entirely: something that tells them, at a glance, what each color or shape on screen means. A Taxonomy Legend is the visual key — typically a small labeled swatch for each taxonomy category — that lets a reader interpret color-coded or shape-coded concepts in a rendered graph diagram without having to memorize the category scheme first.
Every diagram in this book that color-codes concepts by subject area depends on a taxonomy legend to stay readable. Without one, a reader sees a graph full of blue, gold, and green nodes with no way to know that blue means "Graph Theory" and gold means "Visualization Tools." Before we look at the interactive legend below, notice that it does double duty: it is both a reference for interpreting a diagram and a filter control for exploring one, since clicking a legend entry can hide or show every node in that category.
Diagram: Interactive Taxonomy Legend and Filter
View Interactive Taxonomy Legend and Filter Fullscreen
Interactive Taxonomy Legend and Filter
Type: graph-model
sim-id: interactive-taxonomy-legend
Library: vis-network
Status: Specified
Purpose: Show learners how a taxonomy legend both explains a color scheme and acts as a live filter over a rendered concept graph, reinforcing that a legend is a functional taxonomy tool, not decoration.
Bloom Level: Understand (L2) Bloom Verb: interpret, classify
Learning objective: Given a color-coded concept graph and its legend, the learner can correctly identify which taxonomy category any node belongs to and predict which nodes will disappear when a given legend entry is toggled off.
Base dataset: 24-node sample concept graph drawn from this book's own learning graph, pre-assigned to 6 taxonomy categories: Graph Theory (blue), Metadata Standards (teal), Visualization Tools (gold), Learning Science (purple), Personalization (pink), Governance & Validation (gray)
Layout: force-directed, categories loosely clustered by mutual attraction
Legend panel (right side, fixed width): - 6 rows, each showing a color swatch, the Taxonomy Category name, and a live count of visible nodes in that category - Each row is a clickable checkbox-style toggle, checked by default
Interactive features: - Click a legend row: all nodes in that category fade to 15% opacity and their edges hide; click again to restore full opacity - Hover any node: tooltip shows the concept label and its Taxonomy Category name - "Isolate" button per legend row: hides every other category at once, showing only that one node group - "Reset" button: restores all categories to visible
Visual styling: - Node color matches its taxonomy category exactly as listed above - Node shape: circle for all concepts (shape is reserved for other purposes elsewhere in the book) - Edge color: light gray, low opacity, so category color dominates the visual read
Canvas size: responsive, 100% width, 520px height, legend panel fixed at 180px on desktop and stacking below the graph under 600px viewport width
Implementation: vis-network JavaScript library; legend built as an HTML overlay bound to the DataSet's updateOnly API for toggling node/edge visibility without a full re-render
Auditing the Scheme: Taxonomy Distribution Report
A taxonomy can look correct at the level of any single concept — every concept has exactly one category — and still be badly designed at the level of the whole scheme. The most common failure is imbalance: one category swollen with 80 concepts while another holds only 2. A Taxonomy Distribution Report is a generated summary showing how many concepts fall into each taxonomy category, used to spot categories that are too large, too small, or suspiciously empty before the taxonomy is published.
Reading a taxonomy distribution report is a skill in its own right, and it is exactly the kind of table this book has been building toward: a table that reinforces a concept — imbalance — you can already picture from the plain-language description above. The table below is a representative distribution report for a 200-concept learning graph split across six categories.
| Taxonomy Category | Concept Count | % of Total |
|---|---|---|
| Graph Theory | 34 | 17% |
| Metadata Standards | 22 | 11% |
| Visualization Tools | 41 | 20.5% |
| Learning Science | 28 | 14% |
| Personalization | 19 | 9.5% |
| Governance & Validation | 31 | 15.5% |
| Miscellaneous | 25 | 12.5% |
Two rows in that table deserve a second look with a course designer's eye rather than a casual glance. Visualization Tools, at 20.5%, is not necessarily wrong, but it is worth checking whether it should split into two categories (for example, "Layout Algorithms" and "Rendering Libraries"). Miscellaneous, at 12.5%, is well past the roughly-5% caution line from earlier in this chapter and signals that the classification scheme needs revision before this taxonomy should be considered finished.
Balanced Taxonomy: The Target State
Everything in this chapter has been building toward a single quality bar. A Balanced Taxonomy is a concept taxonomy whose categories each hold a roughly similar, non-trivial number of concepts — typically 10 to 12 categories, none dramatically over- or under-represented — as verified by inspecting its taxonomy distribution report. "Balanced" does not mean every category has an identical count; it means no category is so large it stops being a useful filter, and none is so small it barely justifies existing as its own category.
A balanced taxonomy is a design goal reached iteratively, not a property you get on the first attempt. The typical workflow looks like this:
- Run a taxonomy classifier (human or AI-assisted) across every concept in the graph
- Generate a taxonomy distribution report from the resulting concept-to-taxonomy mapping
- Inspect the report for categories that are too large (candidates for splitting), too small (candidates for merging), or a miscellaneous category above the caution threshold
- Revise the category scheme — split, merge, or rename categories as needed
- Re-run the classifier against the revised scheme and repeat from step 2 until the distribution is balanced
Helpful Tip
When you're using a generative AI tool to build a first-draft taxonomy, always ask it to classify first and report the distribution second — never ask it to "make 10 balanced categories" up front. An AI tool asked to force-balance categories before seeing the actual concept list will invent arbitrary category boundaries that don't reflect how the concepts naturally group.
Two Graph-Theory Tools for Keeping a Taxonomy Well-Formed
Building and rebalancing a taxonomy by inspection works for a first pass, but at real scale — a graph with hundreds of concepts — two graph-theory operations do much of this work automatically. Both operations work directly on the graph structure itself, independent of any category labels a human has already assigned, which is what makes them useful for proposing a taxonomy rather than just auditing one that already exists.
Abstraction (Graph) is the process of grouping a set of closely related, fine-grained concepts under a single higher-level concept that represents them collectively — the same instinct that turns "Force-Directed Layout," "Hierarchical Layout," and "Circular Layout" into one higher-level idea, "Graph Layout Algorithms." Abstraction is what a taxonomy category is, structurally: every taxonomy category is an abstraction over the concepts assigned to it. Where this chapter's earlier sections treated categories as already-given labels, abstraction is the graph-theory operation that produces a candidate label in the first place, by examining which concepts share dense connectivity or similar dependency patterns and proposing a name for the group they form.
Clustering (Graph) is the graph-theory technique of automatically detecting node groups — sets of nodes more densely connected to each other than to the rest of the graph — using algorithms that examine edge structure rather than relying on a human-assigned category. Clustering is the detection step; abstraction is the naming step that typically follows it. A clustering algorithm might discover that fifteen concepts form a tightly connected node group without knowing or caring what to call that group; a human (or an AI tool prompted to look at the cluster's contents) then applies abstraction to give it a taxonomy category name like "Graph Layout Algorithms."
The relationship between these two operations and everything else in the chapter is worth seeing end to end before moving on:
- Clustering examines the raw graph and finds candidate node groups based on connectivity alone
- Abstraction takes a candidate node group and proposes the higher-level taxonomy category name that describes it
- The taxonomy classifier then uses that category, going forward, to assign new or unclassified concepts
- The taxonomy distribution report checks whether the resulting scheme is balanced
- If not, the cycle of clustering and abstraction can run again on the categories that need to split or merge
This is the payoff of everything so far
If clustering and abstraction feel abstract right now, that's expected on first read — they're genuinely the most algorithmic ideas in this chapter. Hold onto the plain-language version: clustering finds groups, abstraction names them. Chapter 6's deeper graph-theory coverage gives you the actual algorithms; for now, the concept-level understanding is exactly what you need.
The MicroSim below lets you run a simplified clustering pass over a small concept graph and watch abstraction propose category names for the clusters it finds — the same two-step workflow a taxonomy-building pipeline runs at full scale.
Diagram: Clustering and Abstraction Explorer
View Clustering and Abstraction Explorer Fullscreen
Clustering and Abstraction Explorer
Type: microsim
sim-id: clustering-abstraction-explorer
Library: vis-network
Status: Specified
Purpose: Let learners run a simplified graph-clustering pass over a small concept graph, see the detected node groups highlighted, and then trigger an abstraction step that proposes a taxonomy category name for each detected cluster.
Bloom Level: Analyze (L4) Bloom Verb: differentiate, organize
Learning objective: Given an unlabeled concept graph, the learner can distinguish which nodes a clustering algorithm groups together based on connectivity and explain why the proposed abstraction name fits that group.
Base dataset: 18-node concept graph with edges (undirected, "related to" for this exercise rather than dependency edges) forming three visually separable dense subgroups of 6 nodes each: a Graph Theory cluster (Node, Edge, DAG, Cycle Detection, Hop Count, Traversal), a Visualization cluster (Force-Directed Layout, Hierarchical Layout, vis-network, Node Group, Taxonomy Legend, Zoom/Pan), and a Learning Science cluster (Cognitive Load, Mastery Learning, Zone of Proximal Development, Scaffolding, Constructivism, Backward Design)
Interactive controls: - Button: "Run Clustering" — applies a simplified connected-components-style grouping and recolors each detected cluster a distinct color (no category names yet, clusters labeled "Group A," "Group B," "Group C") - Button: "Run Abstraction" (enabled only after clustering runs) — reveals a proposed taxonomy category name above each colored cluster, drawn from a small lookup keyed to the cluster's dominant concept types - Button: "Reset" — returns all nodes to a single neutral gray color and clears cluster labels - Hover any node: tooltip shows the concept label
Behavior: - Before "Run Clustering": all 18 nodes rendered gray, edges visible, layout force-directed so the three dense subgroups are already visually separated by physics alone - After "Run Clustering": each detected group recolors (blue, gold, purple) and a translucent bounding shape is drawn around each group with the temporary label "Group A / B / C" - After "Run Abstraction": temporary labels are replaced with proposed names — "Graph Theory," "Visualization Tools," "Learning Science" — displayed as a title above each bounding shape
Visual styling: - Neutral state: all nodes gray, edges light gray - Post-clustering: three distinct saturated colors per group, translucent convex-hull-style bounding region per cluster - Post-abstraction: bold category title label above each bounding region
Canvas size: responsive, 100% width, 560px height
Implementation: vis-network JavaScript library for rendering; clustering computed client-side as connected components over a pre-defined adjacency list (simplified stand-in for a real community-detection algorithm, appropriate for teaching the concept without requiring a full graph-theory library); abstraction step uses a static lookup table mapping each precomputed cluster's node-ID set to its category name
Putting the Whole Chapter Together
Every term in this chapter answers a piece of one overall question: how do you take a large, unruly set of concepts and turn it into a small number of categories a human can actually navigate? The list below traces that question from raw graph to finished, balanced scheme.
- A concept taxonomy is the target structure: a set of categories, each with a TaxonomyID and a human-readable Taxonomy Category name
- An ontology is the more general knowledge-representation idea a concept taxonomy is a simplified special case of
- A taxonomy classifier assigns each concept to a category, producing a concept-to-taxonomy mapping
- The concepts inside one category form a node group; concepts that resist classification land, sparingly, in the miscellaneous category
- A taxonomy legend makes the scheme readable in a rendered diagram; a taxonomy distribution report makes it auditable as data
- The end goal is a balanced taxonomy — verified, not assumed
- Clustering and abstraction are the graph-theory operations that can propose a first-draft scheme automatically, by detecting densely connected node groups and naming them, before a human classifier and distribution report take over to refine and validate it
Chapter 5 picks up directly from the distribution report and the miscellaneous-category warning signs introduced here, extending them into a full learning-graph quality-validation pass that checks not just taxonomy balance but structural soundness across the entire dependency graph.
Well done!
Pause and appreciate your progress — you can now explain the difference between a dependency graph and a taxonomy, walk through the full classify-report-rebalance workflow, and describe how clustering and abstraction can propose a first-draft category scheme straight from graph structure. That's a genuinely professional skill: most course designers never learn to audit a taxonomy this rigorously. Next, we put dependency graphs and taxonomies both under the microscope for quality validation. Let's connect the concepts!