Deep dive · Knowledge graph layer

The knowledge graph

Every typed edge in a wiki page's frontmatter reifies to an RDF triple. The wiki is not just linked Markdown; it is a queryable knowledge graph with a formal ontology, SHACL validation, and SPARQL-shaped queries an agent can traverse. Two interactive graphs below let you see the structure directly.

Why typed edges reified to RDF matters

A wiki with body links ([[Page]]) is a document graph: pages connected by untyped edges. That is what most wikis are, and it is what you can do with GitHub or Obsidian out of the box.

The llm-wiki pattern's typed-edge frontmatter (extends:, supports:, criticizes:, related:, up:) upgrades that from a document graph to a semantic graph. Each edge carries a meaning the agent can reason about. The KG pipeline (scripts/kg/build-graph.sh in the base template) turns those frontmatter declarations into RDF triples against a formal ontology, validates the result with SHACL shapes, and produces graph files an agent (or a human, or any SPARQL client) can query directly.

Two properties fall out that a document graph cannot deliver:

The llm-wiki-colab ontology

The semantic layer for the pattern is defined at la3d/llm-wiki-colab. It declares the classes a wiki page can inhabit (28 in the current version) and the properties by which pages connect (36). The graph below is an interactive view of the ontology's structure. Drag nodes, zoom, click to inspect.

Core concept Note type Structure page Person / Org

Nodes are the 28 classes a wiki page can inhabit. Edges express the semantic connections the pattern is designed for: affiliation from Person to Organization, authorOf from Person to note types, supports and criticizes from evidence pages to Concept, up for hierarchy, implementation from Concept to code notes, defines from ConceptNote to Concept. Page-to-page semantic properties (extends, supports, criticizes) are drawn as dashed self-loops on Concept because they can connect any concept-typed page to any other.

A real graph: the markov_embeddings_and_rag wiki

Below is a slice of an actual research wiki reified to RDF: the markov_embeddings_and_rag project's llm-wiki, focused on the theory tree that runs through the group's work on Markov-walk retrieval. The full graph is in graph.ttl. This wiki is the project that produced the "Real world example" callout on the flyer.

Concept Synthesis Entity edges that made the case study possible

30 nodes, 39 edges. All 10 extends edges are shown; supports and criticizes edges are highlighted, and a subset of related edges gives context. Node types dominated by Concept (17) and Synthesis (12), an unusually high Synthesis count that indicates the group's understanding has grown beyond what's in the papers they read.

What the highlighted (gold) edges are. The flyer's "Real world example" callout describes the pattern: a finding on a demo branch cascaded through prior experiments via typed extends: edges, and a current empirical result criticized an earlier framework claim. On this wiki, that maps to a specific chain. Dense-RAG-Scale-Collapse is the leaf finding. Follow its extends: edges backward and you traverse V5c2-Gold-Rank-PositionsMarkov-Chain-v5c2Iterative-NL-SPARQLIterative-Chained-RAG: four hops of experimental lineage the reviewer could walk. And Dense-RAG-Scale-Collapse also criticizes: RAG-Sanity-Check, a page five hops up the up: hierarchy. The current experimental result contradicts an early framework claim, and the graph records both the finding and the disagreement together. These six edges (four extends + two criticisms) are what made the finding traceable and legible in a way body links alone could not have.

What the graph enables: SPARQL queries

Because the graph is real RDF, an agent can issue SPARQL queries against it directly. The base template ships eleven canned queries in scripts/kg/sparql/*.rq covering hierarchy traversal, hub detection, evidence walks, and orphan detection. All eleven were run in-process against the live markov_embeddings_and_rag wiki's graph-full.ttl; every query executed without error. Three of the more illustrative results are shown below.

All typed evidence edges (supports / criticizes)

PREFIX llm-wiki-colab: <https://la3d.github.io/llm-wiki-colab/ontology#>
PREFIX dcterms: <http://purl.org/dc/terms/>

SELECT ?source ?sourceTitle ?relation ?target ?targetTitle WHERE {
    VALUES ?relation { llm-wiki-colab:supports llm-wiki-colab:criticizes }
    ?source ?relation ?target .
    ?source dcterms:title ?sourceTitle .
    ?target dcterms:title ?targetTitle .
} ORDER BY ?targetTitle ?relation

Executed via rdflib against the markov_embeddings_and_rag wiki. Four rows returned — an unusual result: both supports and criticizes edges exist here, which most catalog and survey wikis don't reach.

SourceRelationTarget
Dense-RAG-Scale-CollapsecriticizesRAG-Sanity-Check
Trajectory-Length-ArgumentsupportsEnergy-Based-Drift
Extraction-Retrieval-Co-DesignsupportsMarkov-Retrieval-Tutorial
Iterative-NL-SPARQLcriticizesTyped-Predicate-Ontology

The two criticism edges are the load-bearing ones for the wiki's discipline. Dense-RAG-Scale-Collapse criticizes RAG-Sanity-Check is exactly the pattern the flyer's Real world example describes: a current experimental finding contradicting an earlier framework claim, filed as a typed edge so the disagreement is preserved in the graph rather than lost when the successor page is written. The two supports edges anchor the theoretical scaffold: an argument (Trajectory-Length-Argument) supports an energy-drift claim, and a co-design principle supports the Markov-retrieval synthesis. RAG-only wikis rarely accumulate either kind of edge because there is no author with a stake in maintaining them; here the pattern's discipline makes them cheap enough to file that they exist.

Ancestors of a concept (transitive hierarchy)

PREFIX llm-wiki-colab: <https://la3d.github.io/llm-wiki-colab/ontology#>
PREFIX dcterms: <http://purl.org/dc/terms/>

SELECT ?ancestor ?ancestorTitle WHERE {
    <.../page/NOTE_SLUG> llm-wiki-colab:up+ ?ancestor .
    ?ancestor dcterms:title ?ancestorTitle .
}

The + in up+ is SPARQL's transitive-closure operator: one or more up hops. A single query returns the entire breadcrumb chain. Executed against Dense-RAG-Scale-Collapse — the leaf experimental finding at the far end of the theory tree — the chain runs 12 hops deep:

Dense-RAG-Scale-Collapse
  → V5c2-Gold-Rank-Positions
  → Markov-Chain-v5c2
  → Iterative-NL-SPARQL
  → Iterative-Chained-RAG
  → RAG-Sanity-Check
  → Typed-Predicate-Ontology
  → Operator-Spanning-Set
  → Operations-Basis
  → Markov-Retrieval-Tutorial
  → Home
  → WIKI-INDEX

Twelve hops from a current experimental result all the way up to the wiki root. An agent asked "what's the project context around this scale-collapse finding?" reconstructs the entire research trajectory in one query. Notice that RAG-Sanity-Check — the page Dense-RAG-Scale-Collapse criticizes — is itself in the ancestor chain (five hops up). The current finding contradicts a claim from its own conceptual heritage; the graph makes that visible.

Hub notes (structural centrality)

PREFIX llm-wiki-colab: <https://la3d.github.io/llm-wiki-colab/ontology#>
PREFIX dcterms: <http://purl.org/dc/terms/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>

SELECT ?title (COUNT(?src) AS ?inbound) WHERE {
    ?src ?pred ?note .
    ?note dcterms:title ?title .
    FILTER(?pred NOT IN (rdf:type, dcterms:title, dcterms:created,
        llm-wiki-colab:tag, llm-wiki-colab:status, llm-wiki-colab:timeline))
    FILTER(isIRI(?note))
} GROUP BY ?title ORDER BY DESC(?inbound) LIMIT 25

Top of 25 on the markov_embeddings_and_rag wiki:

NoteTypeInbound edges
Random-Walk-With-RestartConcept48
Markov-Retrieval-TutorialSynthesis42
Path-Length-DecompositionConcept37
Heterogeneous-GraphConcept34
MuSiQue-PoC-ResultsSynthesis32
BM25-Energy-DriftConcept31
Energy-Based-DriftConcept30
Trajectory-Length-ArgumentConcept24
Operations-BasisSynthesis24
Restart-ProbabilityConcept22

Two structural features stand out. First, the top ten are research Concepts and Syntheses — no Index or admin pages. Compare to a topic-review wiki where topic Indexes dominate the hubs; here the theory is what holds the graph together. Second, the wiki's central algorithm — Random-Walk-With-Restart — surfaces automatically at the top with 48 inbound edges. Nobody had to hand-author a "start here" page; the query is the "start here" surface for a new reader or a fresh agent session.

Additional observations from the graph

The markov_embeddings_and_rag graph is unusually rich compared to the other example wikis. Four observations that fall out of it:

  1. Two branch points in the theory tree. Two Concepts are extended by more than one child, which are the places the research forked: An agent asked "what versions of X have we tried?" gets the fork structure back as a graph query, not as a git-log dig.
  2. Four theoretical roots. Concepts that get extended by others but don't themselves extend anything: Random-Walk-With-Restart, Heterogeneous-Graph, Operations-Basis, Iterative-Chained-RAG. These are the load-bearing foundations of the group's framework. If you're onboarding, these are the four pages to read first.
  3. Five experimental leaves. Concepts that extend something but aren't yet extended: Dense-RAG-Scale-Collapse, Trajectory-Length-Argument, BM25-Energy-Drift, Claims-Plus-Walk, Answer-Chunks. These are the current experimental frontier. If you're the maintainer, these are the pages most likely to move next.
  4. Synthesis outnumbers SourceSummary 18 to 5. A 3.6:1 ratio of self-authored synthesis to external-paper summary. That is what a mature research-execution wiki looks like: the group's own understanding has grown well beyond the papers it started from. Neither a catalog wiki (where SourceSummary dominates) nor a survey wiki (where Index-plus-SourceSummary structures the graph) will reach this ratio; only a wiki where the group is doing the research does.

How the graph is built and validated

The base llm-wiki-memory-template ships the KG build pipeline as scripts/kg/build-graph.sh. Three phases:

  1. Extract. Walk the wiki's Markdown files. For each page, read the YAML frontmatter and the body. Emit RDF triples: type from the frontmatter's type: field; up from up:; typed edges from extends:, supports:, criticizes:, related:, source:; mentions from body wikilinks.
  2. Validate. Run the SHACL shapes at wiki/agents/shapes.ttl (via pyshacl) against the generated graph. Shape violations mean the wiki has structural issues (a page declaring itself type: Concept without a required field, an edge to a non-existent page, a broken typed reference). Violations are reported at build time.
  3. Serialize. Emit the graph in multiple formats: Turtle (graph.ttl) for humans, JSON-LD (graph.jsonld) for JavaScript, an optional weighted variant (graph-weights.ttl).

The ontology graph on this page renders the actual ontology.ttl from llm-wiki-colab. The instance graph and SPARQL results come from the actual graph.ttl output of a recent build of the markov_embeddings_and_rag wiki, converted to Cytoscape's JSON by a small rdflib-in-JSON-out script. Nothing was hand-authored.

Wrap-up

The knowledge graph layer is what turns a wiki-grounded research agent from "an agent with better document memory" into "an agent that can reason about the shape of the project's knowledge." Typed edges mean the reasoning is not just similarity search over prose; it is graph traversal along semantic relationships the pattern's ontology defines and SHACL shapes enforce. Every wiki instantiated from the template gets this layer for free, without the researcher having to author any ontology themselves — llm-wiki-colab is the shared semantic foundation.