1.1 Definition and characteristics

A hierarchical model in knowledge organization is a structural framework that arranges concepts, categories, or entities into a tree-like hierarchy based on parent-child relationships. In this model, each node (except the root) has exactly one parent, creating a single path from any node to the top. Broader terms occupy higher levels, while narrower, more specific terms reside at lower levels. Key characteristics include: strict vertical ordering (superordinate–subordinate relationships), transitive inheritance of properties from parent to child, and support for systematic browsing and efficient retrieval. The model is foundational for library classifications, taxonomies, thesauri, and early database management systems.

1.2 Types of hierarchical models

1.2.1 Strict trees vs. forests

A strict tree is a single hierarchical structure with one root node, where all nodes are connected and each node has exactly one parent. In knowledge organization, a strict tree represents a single, unified classification system. A forest is a set of disjoint trees; conceptually, it can be viewed as a collection of multiple independent hierarchies. Forests arise when no single top-level concept encompasses all categories, or when multiple separate taxonomies are maintained.

1.2.2 Monohierarchies vs. polyhierarchies

In a monohierarchy, every node (except the root) is assigned to exactly one parent. This is the classic tree structure. A polyhierarchy allows a node to have multiple parents, enabling a concept to belong to more than one broader category. Polyhierarchies are more expressive but deviate from the strict tree model; they are often managed through exception mechanisms or represented as directed acyclic graphs.

1.3 Historical development in knowledge organization

The hierarchical model has ancient roots in Aristotelian classification and Porphyry’s tree. In the modern era, it became systematized with library classification schemes such as the Dewey Decimal Classification (1876) and the Library of Congress Classification (late 19th century). The model also influenced the development of thesauri for information retrieval in the mid‑20th century. With the advent of digital systems, hierarchical data structures (e.g., adjacency lists) were adopted for databases and ontologies. The model’s simplicity and intuitive navigation made it a cornerstone of early information architecture, even as later approaches introduced more flexible alternatives.

2.1 Library classification schemes

2.1.1 Dewey Decimal Classification (DDC)

The Dewey Decimal Classification is a hierarchical system that organizes knowledge into ten main classes (e.g., 000 – Computer science, information, general works; 100 – Philosophy and psychology). Each class is subdivided recursively into decimal subclasses, resulting in a strict tree with numeric notation. DDC’s hierarchy supports shelf arrangement, browsing, and subject retrieval. It is one of the most widely used library classification schemes globally.

2.1.2 Library of Congress Classification (LCC)

The Library of Congress Classification uses a combination of letters and numbers to represent hierarchical subject categories. Twenty‑one basic classes (A–Z, excluding I, O, W, X, Y) are subdivided by adding numeric subclasses and further alphabetic subdivisions. LCC is more enumerative than DDC, with many special tables and provisions for local adaptation. Its hierarchy is less strictly decimal but still follows a tree structure with each item assigned a unique parent class.

2.1.3 Universal Decimal Classification (UDC)

The Universal Decimal Classification extends the Dewey system by adding auxiliary tables and synthetic features. It uses a decimal notation but allows for more flexible combination of concepts through colons and other symbols. UDC retains a hierarchical backbone while permitting facets and cross‑classification, making it a hybrid between strict hierarchy and faceted classification. It is common in scientific and technical libraries, especially in Europe.

2.2 Taxonomies and thesauri

2.2.1 Hierarchical relationships (BT/NT)

In thesauri and taxonomies, hierarchical relationships are encoded as Broader Term (BT) and Narrower Term (NT). A BT/NT pair indicates a generic–specific or whole–part relationship. Standards such as ISO 25964 define rules for constructing such hierarchies. These relationships enable users to navigate from broad to specific concepts and support query expansion in information retrieval.

2.2.2 Faceted vs. hierarchical taxonomies

A faceted taxonomy organizes concepts by multiple independent dimensions (facets), allowing combination rather than a single tree. In contrast, a strict hierarchical taxonomy places every concept under a single superordinate. Faceted schemes (e.g., the Colon Classification) overcome the rigidity of pure hierarchies but are often implemented as a set of parallel hierarchies—one per facet. Hybrid approaches maintain a primary hierarchy while allowing facet‑based cross‑references.

2.3 Ontologies and formal hierarchies

2.3.1 Subclass (is-a) hierarchies

In formal ontologies, the most common hierarchical relation is subclass (is‑a). A subclass inherits attributes and relationships from its superclass. For example, “Mammal” is a subclass of “Animal”. These hierarchies are typically strict trees in simpler ontologies but can become polyhierarchies in richer frameworks (e.g., “Penguin” being a subclass of both “Bird” and “Non‑flying animal”).

2.3.2 Part-whole (meronymic) hierarchies

Part‑whole (meronymic) hierarchies represent composition relationships, such as “Engine is part of Car”. Unlike is‑a, part‑whole relations are not inheritable for properties like behavior. They can be transitive (e.g., a piston is part of an engine, which is part of a car) or non‑transitive depending on the domain. These hierarchies often supplement subclass hierarchies in ontologies.

2.3.3 Instance-of hierarchies

The instance‑of relation links a class to its individual members (instances). For example, “Fido” is an instance of “Dog”. This relation is distinct from subclass/superclass. In hierarchical models, instances are leaves; they do not have children. Instance‑of hierarchies are common in knowledge graphs and object‑oriented systems.

2.4 Information architecture and website navigation

Hierarchical models are widely used in website navigation and information architecture. Sitemaps, category menus, and breadcrumb trails rely on tree structures to guide users. Top‑level categories (e.g., “Products”, “Services”, “Support”) branch into subcategories. This design facilitates predictable browsing, but deep hierarchies can hinder usability. Best practices recommend limiting depth to three or four levels and providing alternative access paths (e.g., search, faceted filters).

3.1 Data structures for hierarchies

3.1.1 Adjacency list model

In the adjacency list model, each record stores a reference (foreign key) to its parent node. Tables typically contain columns such as id, name, and parent_id. This model is simple to implement and update, but querying an entire subtree requires recursive traversal. It is the most common approach in relational databases for moderate‑sized hierarchies.

3.1.2 Nested set model

The nested set model represents a hierarchy by assigning each node two numbers: left and right, which encode the node’s position in a depth‑first traversal. Descendants of a node are those with left between the node’s left and right. This model allows efficient subtree queries (single SQL query) but makes inserts/deletes expensive (requires renumbering). It is suitable for read‑heavy, static hierarchies.

3.1.3 Materialized path model

The materialized path model stores the full path from root to each node as a string (e.g., “1/4/9/12”). Queries for descendants use pattern matching (e.g., WHERE path LIKE '1/4/%'). This model offers a balance between storage and query performance, but path lengths can become long, and updates to parent paths require bulk updates. It is common in content management systems.

3.2 Querying hierarchical data

3.2.1 Recursive queries (CTEs in SQL)

Recursive Common Table Expressions (CTEs) in SQL enable traversal of adjacency lists. Starting with a seed node (anchor member), the query repeatedly joins to child or parent records (recursive member) until no more rows are produced. This technique is standard in SQL:1999 and supported by most major databases (e.g., PostgreSQL, SQL Server, Oracle).

3.2.2 Path enumeration and closure tables

Path enumeration uses materials paths (see 3.1.3). Closure tables store all ancestor–descendant pairs in a separate table, enabling fast queries for all descendants, ancestors, or distance‑based relationships. Closure tables are flexible and efficient for both reads and writes, but they require additional storage and careful maintenance of transitive closure.

3.3 Visualization techniques

3.3.1 Tree diagrams and dendrograms

Tree diagrams represent hierarchies with nodes and connecting lines, often with the root at the top (up‑down) or left (left‑right). Dendrograms, common in clustering and classification, show hierarchical groupings with branch lengths. Digital tools (e.g., D3.js, graphviz) render these diagrams interactively, supporting collapse/expand and tooltip details.

3.3.2 Indented outlines and breadcrumbs

Indented outlines display hierarchy using indentation levels, as in file explorers or thesauri listings. Breadcrumbs show the current node’s path from the root (e.g., “Home > Products > Electronics > Laptops”). Both techniques are widely used in user interfaces for their simplicity and low cognitive load.

4.1 Strengths

4.1.1 Simplicity and transparency

Hierarchical models are intuitive to understand and explain. Users naturally grasp parent–child relationships, and the structure supports straightforward navigation. Implementation in databases or code is relatively simple, reducing development and maintenance effort.

4.1.2 Efficient browsing and categorization

The tree structure enables systematic drill‑down from broad to specific categories. Users can quickly locate items by following a known path. For organizing large collections (e.g., library shelves, corporate file servers), hierarchies provide a clear, repeatable ordering.

4.1.3 Natural inheritance of properties

Properties applied to a parent node (e.g., subject headings, access rights, default metadata) are implicitly inherited by all descendants. This reduces redundancy and ensures consistency across categories. Inheritance is a key feature in taxonomies and ontological hierarchies.

4.2 Weaknesses

4.2.1 Rigidity and limited expressiveness

A strict tree cannot represent concepts that logically belong to multiple categories. For example, “Platypus” is both a mammal and an egg‑laying animal; a single‑parent hierarchy forces an arbitrary choice. This rigidity limits the model’s ability to mirror real‑world complexity.

4.2.2 Difficulty handling multiple inheritance

When a concept legitimately has multiple parents (polyhierarchy), the standard hierarchical model cannot represent it without duplicating nodes or introducing cross‑references. Polyhierarchies require additional mechanisms (e.g., equivalence relations, graph structures) that complicate querying and maintenance.

4.2.3 Poor scalability for complex cross-references

Large, deep hierarchies can become hard to navigate, and adding many cross‑references (e.g., “see also” links) undermines the tree’s simplicity. In information retrieval, users may miss concepts if they traverse a different branch than intended. Alternative models (facets, networks) better handle such complexity.

5.1 Network (graph) models

Graph models represent concepts as nodes and relationships as edges, allowing arbitrary connections, multiple parents, and cycles. Unlike hierarchies, graphs can model many‑to‑many associations and complex semantic networks. Examples include knowledge graphs (e.g., Wikidata) and topic maps. Graphs offer greater expressiveness at the cost of increased complexity in representation and querying.

5.2 Faceted classification

Faceted classification organizes concepts along multiple independent axes (facets), such as subject, form, place, and time. Users combine facets to specify a topic (e.g., “history of medicine in France during the 19th century”). This model avoids the rigidity of a single hierarchy and supports flexible, multi‑dimensional browsing. It is common in e‑commerce, digital libraries, and thesauri.

5.3 Relational and object-oriented models

Relational models store data in tables with relationships defined by foreign keys, which can represent hierarchies but are not limited to them. Object‑oriented models use inheritance hierarchies for classes (is‑a) but allow composition and associations beyond tree structures. Both models can implement hierarchical data but do not enforce it as a primary organizing principle.

5.4 Hybrid approaches (e.g., polyhierarchies with faceted facets)

Hybrid approaches combine hierarchical structure with facets or polyhierarchies to overcome limitations. For example, a primary taxonomy may be supplemented by facet‑based filtering (e.g., product category hierarchy plus price, brand facets). Polyhierarchies allow a concept to appear under multiple parents while maintaining a core tree for navigation. Such systems balance simplicity with expressiveness and are increasingly used in modern information architectures and content management.