LLM Wikis And Hierarchical Structure - Source Excerpt 02 - Literature on hierarchical knowledge representation

Back to LLM Wikis And Hierarchical Structure

Summary

This source excerpt begins near Literature on hierarchical knowledge representation and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis and Hierarchical Structure.md.

**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis and Hierarchical Structure.md

Two cross-cutting patterns stand out. First, **authoring systems and retrieval systems optimize different things**: MediaWiki, Notion, and Obsidian are strong at durable editing and information organization, while Kagi, Perplexity, LangChain, and LlamaIndex are stronger at query routing, source control, and programmatic retrieval. Second, systems with the best long-term maintainability tend to separate **content**, **metadata**, and **links** instead of flattening everything into undifferentiated chunks. That pattern shows up in Notion’s page/data-source schema, Obsidian’s note/properties split, Wikidata’s item/statement/references model, and LangChain/LlamaIndex’s loader-document-retriever abstractions. citeturn24view12turn23view0turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn24view3turn23view7turn24view3turn24view3turn24view3turn24view3turn24view3turn31view2turn25view13turn26view0

## Literature on hierarchical knowledge representation

The literature supports a layered view of external knowledge for LLMs. Ontologies define explicit vocabularies and constraints; taxonomies and thesauri organize concepts into broader, narrower, and related terms; knowledge graphs represent entities and relations; vector indexes supply fast approximate similarity; and newer RAG methods add higher-order structure such as summary trees or graph-derived communities. Each layer solves a different failure mode of flat retrieval. citeturn33view0turn25view4turn25view5turn25view8turn25view6turn25view7turn25view1turn25view3

| Representation layer | What it contributes | Why it matters for LLM retrieval | Canonical sources |
|---|---|---|---|
| **Ontology** | Explicit classes, relations, functions, and constraints over a shared domain vocabulary. | Improves disambiguation, type safety, schema governance, and query interpretation; especially useful when the corpus represents domain facts rather than just prose. | Gruber’s ontology paper and OWL 2. citeturn33view0turn25view4 |
| **Taxonomy / thesaurus / KOS** | Broader-narrower-related concept structures with a lightweight migration path from existing vocabularies. | Useful for navigation, faceting, concept expansion, and soft hierarchy without requiring a full logical ontology. | SKOS Reference. citeturn25view5 |
| **Knowledge graph** | Graph of entities, properties, and relations, often with schema and context. | Supports multi-hop reasoning, entity-centric QA, and provenance-rich traversal that flat chunk retrieval often misses. | Knowledge Graphs survey; Wikidata/Wikibase model. citeturn25view8turn24view2turn24view3 |
| **Dense vector index** | Approximate nearest-neighbor search over embeddings with strong semantic recall at low latency. | Essential for semantic matching at scale, but weak alone on provenance, compositional constraints, corpus-wide summarization, and exact symbolic filters. | RAG; Faiss; HNSW. citeturn25view0turn25view6turn25view7 |
| **Hierarchical summary tree** | Recursive clustering and summarization across multiple abstraction levels. | Works better than plain local chunks when the answer requires document-level or cross-document synthesis. | RAPTOR. citeturn25view1 |
| **Graph and hybrid RAG** | Combines semantic retrieval with graph extraction, community hierarchies, and often summary layers. | Especially useful for “global” questions, exploratory analysis, and relation-heavy domains. | GraphRAG docs and paper; recent KG-RAG surveys and hybrid RAG papers. citeturn25view2turn25view3turn22search6turn22search7turn22search10 |

A few implications are especially relevant for LLM Wikis. First, if the wiki must answer **global questions** such as “what are the main themes across this space?” or “how do these systems compare across teams?”, plain top-*k* vector retrieval is often the wrong primitive; GraphRAG explicitly frames this as a query-focused summarization problem rather than a local retrieval problem, and RAPTOR makes the same point from the angle of tree-organized summaries. citeturn25view2turn25view3turn25view1

Second, if the wiki must answer **precision questions with provenance** such as “what is the author / owner / status / version / policy that governs X?”, symbolic structure helps. Wikidata’s statement-qualifier-reference model shows how typed claims and sources reduce ambiguity, while ontology and taxonomy standards explain how to keep those structures interoperable rather than hard-coded to one tool. citeturn24view3turn24view4turn31view2turn33view0turn25view4turn25view5

Third, hybrid retrieval is increasingly the operational default. Production systems such as Weaviate combine BM25F keyword search and vector search with configurable fusion and weighting, while Neo4j exposes HNSW-based vector indexing directly inside a graph database. LangChain’s retriever ecosystem also treats lexical, vector, and permission-aware filtering as composable concerns rather than mutually exclusive choices. citeturn25view10turn25view9turn27view5turn21search0

## Lessons from Wikipedia and related wiki structures

Wikipedia and the broader Wikimedia stack offer the richest real-world example of knowledge that is **simultaneously navigable by humans and legible to machines**. The most important lesson is not “copy Wikipedia’s category tree.” It is “separate different kinds of structure so they can each do their job well.” Categories, infoboxes, headings, redirects, templates, and Wikidata statements all express different kinds of organization. citeturn24view5turn24view6turn24view7turn24view8turn24view9turn24view3turn31view0turn31view3turn31view4

| Observed pattern in Wikimedia | Why it works | Best practice for an LLM Wiki | Evidence |
|---|---|---|---|
| **Categories are useful, but not a strict tree** | Wikipedia explicitly notes that categories are not a strict hierarchy because pages and categories can each have multiple parents. | Use categories or concepts as a **polyhierarchical navigation layer**, not as the only truth model. | citeturn31view0 |
| **Still, editors aim for specificity** | Wikipedia’s categorization guidance says pages should be placed in the most specific categories possible rather than treated like loose tags. | Allow multiple parents, but enforce “closest valid bucket” rules to reduce category sprawl. | citeturn31view1 |
| **Maintenance metadata is kept separate** | Hidden categories and tracking categories are used for maintenance and are intentionally hidden from normal reader-facing category boxes. | Separate reader-facing concepts from admin/maintenance labels such as stale, needs-review, or parse-error. | citeturn30search0turn30search8turn30search11 |
| **Infoboxes are fixed-format summaries built from templates** | Infoboxes summarize key facts consistently, often using template parameters, and many emit structured metadata reused by downstream systems. | Build typed summary panels or structured sidecars rather than relying only on free-text intros. | citeturn24view6turn24view9 |
| **Sections are first-class retrieval boundaries** | TOCs are generated from section headings, and headings are stable navigation anchors. | Chunk and retrieve primarily at the section level, with child chunk offsets inside the section. | citeturn24view7turn23view4turn25view12 |
| **Templates and transclusion centralize reuse** | MediaWiki transclusion reuses shared content or structure across pages without manual duplication. | Put repeated schema, policy text, or standard cards into reusable templates or generated sidecars. | citeturn24view5 |
| **Stable IDs and aliases reduce ambiguity** | Wikidata uses unique QIDs, plus labels, descriptions, aliases, and sitelinks. | Mint immutable IDs for pages, entities, and claims; treat titles and aliases as mutable metadata. | citeturn31view3turn31view4 |
| **Claims can be qualified and sourced** | Statements can be refined with qualifiers and backed with references. | Store facts separately from prose, and attach qualifiers such as time, status, jurisdiction, or confidence. | citeturn24view3turn24view4turn31view2 |