LLM Wikis As Mind Maps For AI - Source Excerpt 02 - UX patterns for mind-map navigation

Summary

This source excerpt begins near UX patterns for mind-map navigation and preserves the surrounding evidence from Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis as Mind Maps for AI.md.
**Source path:** Wiki.FFTAC.org/agent-file-handoff/Archive/2026-05-11-improvement-concept-layer/LLM Wikis as Mind Maps for AI.md
| Stack family | Representative systems | What they do well | What they do not do well by default | Best fit |
|---|---|---|---|---|
| Semantic wiki | Semantic MediaWiki | Native page-property modeling and semantic query over categories/properties. citeturn29view0turn29view1 | Public SEO and structured data need extra implementation work; agent interfaces are not first-class out of the box. | Editorial teams that want wiki-like authoring with lightweight semantics. |
| Open knowledge graph wiki | Wikibase / Wikidata Query Service | Collaborative knowledge-base modeling, custom data model, REST API, and SPARQL endpoint. citeturn29view2turn29view3turn29view4 | Heavier ontology/query overhead than a docs site; page UX often needs custom front-end work. | High-value entity graphs, multilingual structured repositories, linked-data use cases. |
| Static docs platforms | Docusaurus, Starlight, MkDocs | Strong crawlability, Markdown workflows, versioning, i18n, performance, and docs UX. citeturn34view0turn34view1turn20search0turn28view4 | They do not natively model typed semantic edges or graph traversal. | Public documentation and knowledge hubs with predictable hierarchy. |
| Digital garden / wiki-link publishers | Quartz, MarkPub, Dendron publishing patterns, Obsidian-derived publishing | Wikilinks, backlinks, graph views, transclusion, hierarchy, full-text search. citeturn20search1turn28view5turn28view7turn28view6 | Semantics are often implicit rather than strongly typed; SEO quality depends on implementation details. | Small-to-mid-size public knowledge gardens where linked thinking is central. |
| GraphRAG layer | Microsoft GraphRAG, Neo4j GraphRAG, LlamaIndex KG RAG | Structured, hierarchical or subgraph-based retrieval for multi-hop/global questions. citeturn24view5turn19search8turn28view3turn33view0 | Needs a separate publishing surface and careful graph construction quality control. | Corpus-scale reasoning and agent traversal over relation-rich knowledge. |
| Hybrid retrieval/orchestration | Weaviate, Qdrant, pgvector, Pinecone, Haystack, LangGraph | Hybrid ranking, filtering, scalable vector search, modular workflows, agent orchestration. citeturn24view6turn28view0turn28view1turn28view2turn33view2turn26view7 | They are infrastructure components, not a user-facing wiki on their own. | Production AI backends behind a public wiki front end. |

The UX lineage for “mind-map wiki” behavior is also real and important. Obsidian’s graph view visualizes notes and local neighborhoods with depth control; Dendron formalizes dot-delimited hierarchies; Quartz and MarkPub bring wiki-links, backlinks, and graph views to public web publishing; and the Obsidian Breadcrumbs plugin demonstrates how typed links can be turned into trails, trees, previous/next views, and graph traversal rather than generic backlinks. Those patterns are highly relevant because they solve the *authoring and navigation* side of the problem even if they do not, by themselves, solve public SEO or LLM retrieval. citeturn28view6turn28view7turn20search1turn28view5turn2search4turn2search8

The academic literature of the last five years strongly reinforces the need for structure beyond flat chunk retrieval. The original RAG paper established the now-standard pattern of pairing a language model with an external dense vector index. Self-RAG added adaptive retrieval and self-reflection. RAPTOR showed gains from recursive hierarchical summaries over long documents. Microsoft’s GraphRAG proposed graph extraction, community hierarchies, and summarized communities for corpus-level and “global” questions. HippoRAG combined knowledge graphs with Personalized PageRank and reported both quality and efficiency gains on multi-hop retrieval. More recent surveys and benchmarks argue that GraphRAG needs better evaluation and that graph-aware systems should be stress-tested on graph construction, retrieval, and reasoning rather than just answer text. citeturn1search0turn10search1turn10search0turn1search1turn24view5turn1search2turn10search3turn22search2turn22search10

| Paper | Year | Core contribution | Why it matters here |
|---|---|---|---|
| *Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks* | 2020 | Established the classic LLM + external retriever pattern using a dense vector index of Wikipedia. citeturn1search0 | Baseline approach every LLM wiki will be compared against. |
| *Self-RAG* | 2023 | Adaptive retrieval and self-reflection tokens rather than always retrieving a fixed number of passages. citeturn10search1 | Suggests that node traversal and retrieval should be conditional, not mandatory on every turn. |
| *RAPTOR* | 2024 | Recursive clustering, summarization, and tree-organized retrieval. citeturn10search0 | Maps naturally to topic hubs and multi-level wiki summaries. |
| *From Local to Global: GraphRAG* | 2024 | Graph extraction, community hierarchy, and pre-generated summaries for query-focused summarization. citeturn1search1turn24view5 | Closest research analogue to a mind-map wiki that supports global and local traversal. |
| *HippoRAG* | 2024 | KG + Personalized PageRank memory-style retrieval with strong multi-hop gains and better speed/cost than some iterative methods. citeturn1search2 | Supports graph traversal as more than a UI metaphor; it can materially improve retrieval. |
| *ARES* | 2024 | Automated evaluation across context relevance, answer faithfulness, and answer relevance. citeturn22search3 | A practical metric set for measuring whether the wiki actually helps answers. |
| *GraphRAG-Bench* | 2025 | Large benchmark focused on graph construction, retrieval, and multi-hop reasoning. citeturn22search2 | Useful when the system’s value proposition is graph-enabled reasoning, not just page SEO. |

## UX patterns for mind-map navigation

The best public UX for this category is **dual-mode navigation**: a stable hierarchical path for comprehension and crawlability, plus a local graph or “mind map” view for exploration. Google’s breadcrumb guidance is explicitly location-based: the page should sit in a visible site hierarchy that users can navigate upward. Obsidian’s graph view adds local neighborhoods and adjustable depth. Dendron shows another useful principle: hierarchy and graph links can coexist, rather than competing as separate information architectures. citeturn24view2turn28view6turn28view7

The most reusable design pattern is therefore a node page with five visible navigation surfaces: a **summary box** for fast orientation, **breadcrumbs** for place in hierarchy, **children** for decomposition, **related nodes** for lateral exploration, and **backlinks / used by** for reverse context. That mix gives humans and agents both a “where am I?” answer and a “where next?” answer. When relations are typed, the “related nodes” area becomes much more useful because it can distinguish `prerequisite_for`, `example_of`, `implemented_by`, `part_of`, or `contrasts_with` rather than dumping all neighbors into a single list. Semantic MediaWiki’s properties and Wikibase’s statements are the clearest precedents for typed links. citeturn24view2turn29view1turn29view3

Recent KG interface research points in the same direction: raw node-link diagrams are not enough. KGScope adds **relation recommendations, similarity cues, and peculiarity hints** to help users know where to click next, and a 2025 participatory design paper on KG navigation argues that multilayered graph navigation remains difficult and benefits from explicit interface guidance and user-centric entry points. In other words, the graph should not be a beautiful but inert picture; it should actively scaffold exploration. citeturn18search0turn18search14

A practical UX consequence follows: **graph views should usually be local and task-oriented, not global and undifferentiated**. For large knowledge bases, a global galaxy view is often useful as branding or orientation, but local subgraphs around the current node, typed trails, and “next best node” recommendations are usually more actionable for both humans and agents. The Obsidian Breadcrumbs plugin’s trail/tree views are a strong example of how typed links can support traversal without overwhelming the interface. citeturn28view6turn2search4turn2search8

The navigation flow below captures the recommended interaction model.

' ' ' mermaid
flowchart LR
    Q[User query or agent goal] --> H[Hub page or canonical node page]
    H --> S[Summary and key facts]
    H --> B[Breadcrumb trail]
    H --> C[Children and subtopics]
    H --> R[Typed related nodes]
    H --> K[Backlinks and references]
    H --> M[JSON-LD and traversal API]
    M --> G[Graph or hybrid retriever]
    G --> N[Next canonical node]
    N --> H2[Next page view]
' ' '