A property graph — labeled Vault/Folder/Document/Section nodes and HAS/NEXT_SECTION/LINKS_TO edges, each carrying properties.
Neo4j's Zach Blumenfeld argues Andrej Karpathy's LLM-maintained wiki needs a property-graph overlay to scale, built with zero LLM calls by the open-source ki tool. Kingsley Uyi Idehen's two LinkedIn articles — on turning any document URL into a queryable RDF graph and on the agent engineering stack — propose an LLM-driven RDF overlay instead. This collection compares both paths across eleven dimensions, then tests the “agent long-term memory” use case each side gestures at against agent-rdf-memory, a shipped, dated, 277-plus-rule production system running in this very repository.
Neo4j's Zach Blumenfeld argues that Andrej Karpathy's LLM-maintained-wiki recipe — raw files, a processed wiki, curated summaries — runs out of road once a vault grows past a handful of documents, because Markdown alone cannot answer structural questions. His fix is a Neo4j property-graph overlay, built deterministically by the open-source ki tool with zero LLM calls, queried in Cypher, and enriched with Neo4j GDS Leiden community detection for emergent theme clustering.
Kingsley Uyi Idehen's companion proposal reaches the same destination — a queryable graph over an LLM wiki — from the opposite direction: a neuro-symbolic process in which an AI-agent skill's LLM decomposes fuzzy natural-language content to its subject-predicate-object essence, then SPARQL-based entity lookups — able to combine deterministic reasoning/inference with full-text and vector-similarity search on Virtuoso — ground those fragments against typed entities in the graph, publishing dereferenceable HTTP IRIs over WebDAV and a Virtuoso SPARQL endpoint rather than standing up a proprietary graph database. His follow-up, The Agent Engineering Stack Nobody Shows You, tests an 11-layer agent architecture against agent-rdf-memory — a real, shipped, 277-plus-rule RDF behavioral-memory system for AI coding agents. Where Neo4j's article names “agent long-term memory” as an aspirational use case with no implementation shown, agent-rdf-memory already runs it, in production, today. This is not a “Neo4j bad, RDF good” argument — ki's zero LLM calls make a generation error in that step categorically impossible, Neo4j cites a real external benchmark, and an LLM grounded in the target ontology writes RDF just as reliably, buying semantic richness rather than trading away safety. The genuine asymmetries run both ways, and this collection names them rather than picking a winner.
Zach Blumenfeld's post proposes a property-graph overlay for Andrej Karpathy's LLM-wiki recipe, built by the open-source ki tool — four node types, Vault, Folder, Document, and Section, joined by three relationships: HAS (containment), NEXT_SECTION (reading order), and LINKS_TO (cross-reference). ki syncs a Markdown vault into this schema with zero LLM calls — a deterministic structural parse, not a model interpreting content — so the graph-build step itself carries no hallucination risk.
The whole Markdown wiki as a single root container.
A directory-level node, nested under a Vault or another Folder via HAS.
A single wiki page/file, containing one or more Section nodes in reading order.
The finest-grained node — one heading-delimited section, chained via NEXT_SECTION.
ki exposes exactly four operations: outline (hierarchy), search (fulltext), get (sequential read), and graph-reason (ad hoc Cypher). For theme discovery, Neo4j GDS's Leiden community-detection algorithm runs over the LINKS_TO graph — ki theme can surface a cluster of [[aip-paper]], [[aip]], and [[aip-launch-blog]] links as one emergent topic without anyone labeling it. The article cites a Newcastle University NICD study: graph-augmented retrieval beat vector-only RAG on a Wikipedia benchmark by more than 2x on precision and recall, plus +80% truthfulness and +69% answer relevancy.
Each row below is its own described entity in the companion RDF — click a dimension name to look it up. ki has zero LLM calls, so there is categorically no possibility of a generation error in that specific step; Virtuoso/agent-rdf-memory takes a neuro-symbolic path instead — an LLM decomposes fuzzy content to subject-predicate-object essence, and SPARQL-based entity lookups (with deterministic reasoning, full-text, and vector-similarity search on Virtuoso) ground those fragments against real, typed entities, buying semantic richness ki's structural-only nodes cannot express. And where RDF works differently rather than identically elsewhere — theme detection is deterministic ontology reasoning, not Leiden's statistical clustering — that difference is named plainly too, rather than smoothed over in either direction.
| Dimension | Neo4j / ki | Virtuoso / agent-rdf-memory |
|---|---|---|
| Graph model paradigm | A property graph — labeled Vault/Folder/Document/Section nodes and HAS/NEXT_SECTION/LINKS_TO edges, each carrying properties. | RDF triples — subject-predicate-object statements identified by globally dereferenceable IRIs, mergeable across documents without a shared schema agreed in advance. |
| Query language | Cypher, Neo4j's proprietary graph query language. | SPARQL, the W3C standard RDF query language, runnable against any compliant store. |
| Identifier scheme | Database-internal or application-level node IDs, meaningful only inside the Neo4j instance that minted them. | Dereferenceable HTTP IRIs — “follow-your-nose” Linked Data navigation, where fetching the identifier returns a description of the thing itself. |
| Storage substrate | A Neo4j database instance — self-hosted, or Neo4j Aura's managed cloud service. | A single Virtuoso instance — WebDAV and the RDF quad store are both native Virtuoso features, not two systems combined. WebDAV simplifies uploading RDF using the familiar filesystem UI/UX; that same content is simultaneously a SPARQL-queryable graph over plain HTTP. Virtuoso installs and runs on-premise, on any cloud provider's VMs, as a managed/hosted cloud offering, or as a Docker container — this document's own live resolver links and SPARQL endpoints are real Web-hosted instances of exactly this kind. |
| Construction method & cost | ki's zero-LLM deterministic structural sync — categorically no possibility of a generation error (there is no generation, only parsing), but only structural typing (containment, order, cross-reference). | A neuro-symbolic construction: an LLM decomposes the document's fuzzy content to subject-predicate-object essence, then SPARQL-based entity lookups — combining deterministic reasoning with full-text and vector-similarity search on Virtuoso — ground those fragments against real, typed entities rather than generating untethered guesses. The real cost is an LLM call plus graph lookups, for semantic richness ki cannot express at all. |
| Interop standard | A proprietary graph-database API and Bolt wire protocol. | The W3C standards stack — RDF, SPARQL, WebDAV, and plain HTTP — implementable by any compliant server. |
| Retrieval primitives | Four named operations: outline, search, get, graph-reason. | SPARQL queries of arbitrary shape, plus resolver-based hyperlink browsing with no predefined operation name — both can draw on deterministic reasoning transparently, returning inferred relationships (RDFS/OWL entailment) alongside asserted ones, and can combine that reasoning with full-text and vector-similarity search in the same query on Virtuoso, not just literal stored-triple lookup. |
| Theme & community detection | Neo4j GDS Leiden community detection, used by ki theme to surface emergent topic clusters with no manual labeling. | A different mechanism, not a missing one: deterministic RDFS/OWL reasoning and SPARQL property-path queries derive grouping from typed relationships already asserted at construction time. |
| Agent-memory maturity | Named as an aspirational use case alongside personal vaults, team docs, and enterprise knowledge layers — no shipped implementation shown. | agent-rdf-memory is shipped, dated, and running today: 277-plus recorded rules and a chronological session log of real corrected behavior. |
| Governance / behavioral-contract layer | No analog — the article is about structural navigation, not agent behavior constraints. | preferences.ttl is an explicit operational behavioral contract, tied to the Agent Engineering Stack's Policy & Guardrails, Identity, and Evaluation layers. |
| Empirical evidence style | An external, third-party benchmark — the Newcastle University NICD study on Wikipedia: >2x precision/recall, +80% truthfulness, +69% relevancy. | Longitudinal and operational evidence — a growing, dated rule count and a session log of corrected agent behavior over real use. Different, but both are real. |
A property graph — labeled Vault/Folder/Document/Section nodes and HAS/NEXT_SECTION/LINKS_TO edges, each carrying properties.
RDF triples — subject-predicate-object statements identified by globally dereferenceable IRIs, mergeable across documents without a shared schema agreed in advance.
Cypher, Neo4j's proprietary graph query language.
SPARQL, the W3C standard RDF query language, runnable against any compliant store.
Database-internal or application-level node IDs, meaningful only inside the Neo4j instance that minted them.
Dereferenceable HTTP IRIs — “follow-your-nose” Linked Data navigation, where fetching the identifier returns a description of the thing itself.
A Neo4j database instance — self-hosted, or Neo4j Aura's managed cloud service.
A single Virtuoso instance — WebDAV and the RDF quad store are both native Virtuoso features, not two systems combined. WebDAV simplifies uploading RDF using the familiar filesystem UI/UX; that same content is simultaneously a SPARQL-queryable graph over plain HTTP. Virtuoso installs and runs on-premise, on any cloud VM, as a managed cloud offering, or as a Docker container.
ki's zero-LLM deterministic structural sync — categorically no possibility of a generation error (there is no generation, only parsing), but only structural typing (containment, order, cross-reference).
A neuro-symbolic construction: an LLM decomposes the document's fuzzy content to subject-predicate-object essence, then SPARQL-based entity lookups — combining deterministic reasoning with full-text and vector-similarity search on Virtuoso — ground those fragments against real, typed entities rather than generating untethered guesses. The real cost is an LLM call plus graph lookups, for semantic richness ki cannot express at all.
A proprietary graph-database API and Bolt wire protocol.
The W3C standards stack — RDF, SPARQL, WebDAV, and plain HTTP — implementable by any compliant server.
Four named operations: outline, search, get, graph-reason.
SPARQL queries of arbitrary shape, plus resolver-based hyperlink browsing with no predefined operation name — both can draw on deterministic reasoning transparently, returning inferred relationships (RDFS/OWL entailment) alongside asserted ones, and can combine that reasoning with full-text and vector-similarity search in the same query on Virtuoso, not just literal stored-triple lookup.
Neo4j GDS Leiden community detection, used by ki theme to surface emergent topic clusters with no manual labeling.
A different mechanism, not a missing one: deterministic RDFS/OWL reasoning and SPARQL property-path queries derive grouping from typed relationships already asserted at construction time.
Named as an aspirational use case alongside personal vaults, team docs, and enterprise knowledge layers — no shipped implementation shown.
agent-rdf-memory is shipped, dated, and running today: 277-plus recorded rules and a chronological session log of real corrected behavior.
No analog — the article is about structural navigation, not agent behavior constraints.
preferences.ttl is an explicit operational behavioral contract, tied to the Agent Engineering Stack's Policy & Guardrails, Identity, and Evaluation layers.
An external, third-party benchmark — the Newcastle University NICD study on Wikipedia: >2x precision/recall, +80% truthfulness, +69% relevancy.
Longitudinal and operational evidence — a growing, dated rule count and a session log of corrected agent behavior over real use. Different, but both are real.
Kingsley Uyi Idehen's article extends Karpathy's LLM-wiki idea past static Markdown into machine-readable RDF: supply any document URL, invoke an AI agent skill defined via OPAL, and the agent fetches the content, extracts entities and relationships typed against schema.org plus domain ontologies, and generates RDF/Turtle — saved locally or to WebDAV. His core insight, in his own words: “a file, a skill, a webby graph” — reusing existing Web architecture (HTTP, WebDAV, dereferenceable IRIs) instead of a proprietary platform.
OpenLink's platform for authoring the document-to-RDF AI agent skill.
The universal server: WebDAV filesystem, SPARQL endpoint, and Linked-Data follow-your-nose navigation, in one.
Attribute-based access control governing who may read or write the generated graph on WebDAV.
The article demonstrates the skill by converting Werner Vogels' “S3 Files and the Changing Face of S3” into a live SPARQL-queryable graph. A commenter's insight, as the author paraphrases it: the shift moves the model “from interpretation to constraint” — once relationships are explicit in the graph, the model stops filling gaps from its own prior and starts operating within stated boundaries, so its failure mode shifts from confidently wrong (hallucination) to visibly missing (incompleteness) — a failure mode that is far easier to detect and fix.
The canonical SAMPLE-based summary query over this document's own companion graph — one representative instance IRI per rdf:type, so every row stays clickable. This is the query the footer's 'Explore Knowledge Graph using SPARQL' button runs.
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
SELECT ?type (SAMPLE(?s) AS ?sampleEntity) (SAMPLE(?label) AS ?sampleLabel) (COUNT(?s) AS ?entityCount) WHERE {
GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/llm-wiki-graph-neo4j-vs-agent-rdf-memory-claude_sonnet_5-1.ttl> {
?s rdf:type ?type .
OPTIONAL { ?s rdfs:label ?label }
}
} GROUP BY ?type ORDER BY DESC(?entityCount)Every cdx:ComparisonDimension instance in this document's graph, with its own IRI and name — a starting point for browsing the full dimension-by-dimension comparison via the resolver.
PREFIX post: <https://linkeddata.uriburner.com/DAV/demos/daas/llm-wiki-graph-neo4j-vs-agent-rdf-memory-claude_sonnet_5-1.html#>
PREFIX cdx: <https://neo4j.com/blog/graph-database/introducing-neo4j-virtual-graph-graph-reasoning-on-the-data-you-already-have/#>
PREFIX schema: <http://schema.org/>
SELECT ?dimIri ?dim ?description WHERE {
GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/llm-wiki-graph-neo4j-vs-agent-rdf-memory-claude_sonnet_5-1.ttl> {
?dimIri a cdx:ComparisonDimension ;
schema:name ?dim ;
schema:description ?description .
}
} ORDER BY ?dimLists the three source articles and the agent-rdf-memory software entity together, with their rdf:type and publication date where one exists.
PREFIX post: <https://linkeddata.uriburner.com/DAV/demos/daas/llm-wiki-graph-neo4j-vs-agent-rdf-memory-claude_sonnet_5-1.html#>
PREFIX schema: <http://schema.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
SELECT ?sourceIri ?name ?type ?published WHERE {
GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/llm-wiki-graph-neo4j-vs-agent-rdf-memory-claude_sonnet_5-1.ttl> {
VALUES ?sourceIri { post:neo4jScalingArticle post:kingsleyLlmWikiArticle post:kingsleyAgentStackArticle post:agentRdfMemorySoftware }
?sourceIri schema:name ?name ; rdf:type ?type .
OPTIONAL { ?sourceIri schema:datePublished ?published }
}
}Every schema:Question in this document's FAQ, joined to its schema:Answer text via schema:acceptedAnswer — both entity IRIs are projected.
PREFIX post: <https://linkeddata.uriburner.com/DAV/demos/daas/llm-wiki-graph-neo4j-vs-agent-rdf-memory-claude_sonnet_5-1.html#>
PREFIX schema: <http://schema.org/>
SELECT ?questionIri ?question ?answerIri ?answer WHERE {
GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/llm-wiki-graph-neo4j-vs-agent-rdf-memory-claude_sonnet_5-1.ttl> {
?questionIri a schema:Question ; schema:isPartOf post:faqSection ;
schema:name ?question ; schema:acceptedAnswer ?answerIri .
?answerIri schema:text ?answer .
}
} ORDER BY ?questionIriEvery schema:DefinedTerm in this document's glossary, with its own IRI and definition text.
PREFIX post: <https://linkeddata.uriburner.com/DAV/demos/daas/llm-wiki-graph-neo4j-vs-agent-rdf-memory-claude_sonnet_5-1.html#>
PREFIX schema: <http://schema.org/>
SELECT ?termIri ?term ?description WHERE {
GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/llm-wiki-graph-neo4j-vs-agent-rdf-memory-claude_sonnet_5-1.ttl> {
?termIri a schema:DefinedTerm ; schema:isPartOf post:glossarySection ;
schema:name ?term ; schema:description ?description .
}
} ORDER BY ?termagent-rdf-memory is the actual software artifact The Agent Engineering Stack Nobody Shows You describes: an RDF-Turtle-based memory and behavioral framework for AI coding agents, living in this very repository's agent-rdf-memory/ directory. Tested against an 11-layer agent architecture (Model, Context, Memory, Tools, Skills, Orchestration, Identity, Policy & Guardrails, Observability, Evaluation, Runtime), the article finds Context, Memory, Skills, Orchestration, Identity, Policy & Guardrails, and Evaluation fully implemented, with Tools, Observability, and Runtime partial. Where Neo4j's scaling-the-wiki article names “agent long-term memory” as an aspirational use case alongside personal vaults, team docs, and enterprise knowledge layers — with no shipped implementation shown — this is the shipped implementation.
277-plus numbered schema:HowToStep rules — the Policy & Guardrails layer, described as “an operational behavioral contract,” not passive warnings.
Ontology-routed selection of what an agent sees for a task — the Context layer.
Dozens of topic-specific schema:HowTo documents — the Skills layer as executable operating knowledge.
A chronological record of corrected agent behavior over months of real use — the Memory layer's episodic half.
Neo4j's article names agent memory as future-facing. agent-rdf-memory already runs the identical “queryable structure an agent consults before acting” pattern today, governing the very agent that generated this comparison — on RDF/SPARQL/WebDAV rather than a property graph, and self-hosted rather than commercially operated.
Each side gets its own complete seven-step procedure, so either can be followed on its own without cross-referencing the other. The two are laid out side by side only for comparison — neither depends on the other.
Start from Karpathy's LLM-wiki recipe: an existing Markdown vault or team knowledge base already maintained by an LLM coding agent. ki treats that Markdown tree as the corpus to graph — no other source type is supported.
Provision a Neo4j database instance, self-hosted or Aura. This is the only place the graph will live — there is no filesystem-plus-endpoint duality.
Run ki to parse the Markdown structure deterministically, producing Vault/Folder/Document/Section nodes and HAS/NEXT_SECTION/LINKS_TO edges. No model call happens in this step, so there is no hallucination risk in the graph-build itself — only structural typing, not semantic typing of what the content is about.
Nodes get database-internal or application-level IDs, meaningful only inside that Neo4j instance. There is no public dereferencing step — looking a node up requires a Cypher query against that specific database.
Use ki's four named operations — outline, search, get, graph-reason — each a fixed Cypher pattern under the hood, to navigate the wiki structurally instead of re-reading raw files.
Use ki theme, backed by Neo4j GDS's Leiden algorithm, to surface emergent topic clusters over the link graph with no manual labeling.
The scaling-the-wiki article names 'agent long-term memory' as a candidate use case for this graph but stops at structural navigation — it does not add a governance or behavioral-contract layer on top, and ki's own scope ends here.
Supply any document URL — HTTP or file, not only a Markdown wiki file — generalizing past Karpathy's original Markdown-only scope to arbitrary source documents.
Use a single Virtuoso instance — WebDAV and the RDF quad store are both native Virtuoso features, not two systems combined. WebDAV simplifies uploading RDF into the quad store using the universally familiar filesystem UI/UX; that same content is simultaneously a SPARQL-queryable graph, with no separate import step into a dedicated graph-database process. Virtuoso installs and runs on-premise, on any cloud provider's virtual machines, as a cloud-managed/hosted server offering, or as a Docker container — the live endpoints this document links to (linkeddata.uriburner.com and the two Beyond-LLM-Wiki weblogs) are real Web-hosted instances of exactly this kind.
Relevant agent skills are invoked to generate RDF, in the user's preferred notation (Turtle, JSON-LD, and others), using terms from a variety of shared ontologies — richer semantic typing than ki's structural-only nodes.
Every node gets a dereferenceable HTTP IRI, minted from the source document's own URL plus a fragment, so any client can fetch the identifier directly and get a description back — no proprietary lookup API required.
Run arbitrary SPARQL queries against the graph, plus resolver-based hyperlink browsing (describe/?url=) that lets a reader click from any entity to any related entity, without a predefined operation name. Both surfaces can draw on deterministic reasoning transparently: a SPARQL query or a describe/?url= page can return inferred relationships (RDFS/OWL entailment, transitive closure, owl:sameAs/equivalentClass) alongside the asserted ones, not just literal stored triples.
Because relationships were typed against schema.org/domain ontologies back in step 3, run RDFS/OWL reasoning (transitive closure, owl:sameAs/equivalentClass entailment, SKOS broader/narrower) and SPARQL property-path queries to derive grouping and thematic structure directly from the asserted semantics — deterministic entailment, not Leiden's statistical clustering over untyped topology. This is a different mechanism from ki theme, not a missing one; it only falls short of Leiden's specific case of finding clusters over a graph with zero semantic typing at all.
Add preferences.ttl as an explicit operational behavioral contract, enforced against the agent's own future actions and tied to the Agent Engineering Stack's Policy & Guardrails, Identity, and Evaluation layers — the step that turns a queryable graph into agent governance, with no analog on the Neo4j/ki side.
That Andrej Karpathy's LLM-maintained-wiki recipe has no graph layer, so it cannot answer structural questions (what links to what, what order sections read in, what themes recur) once a vault or team knowledge base grows past a handful of documents.
Vault, Folder, Document, and Section nodes, joined by HAS (containment), NEXT_SECTION (reading order), and LINKS_TO (cross-reference).
ki parses Markdown structure deterministically rather than asking a model to interpret it, so the graph-build step carries no hallucination risk — at the cost of only structural typing, not semantic typing of what the content is about.
It's a neuro-symbolic process. An AI agent skill fetches a document URL, and an LLM handles its fuzzy natural-language content by decomposing it to subject-predicate-object essence. The system then looks up matching entities in the underlying graph for type-level matches that supply rich context — via SPARQL queries that can combine deterministic reasoning and inference with full-text and vector-similarity search (on Virtuoso) — grounding each fragment against real, typed entities rather than generating untethered guesses, and producing RDF/Turtle. The real cost is an LLM call plus graph lookups, in exchange for semantic typing ki's pure structural sync cannot express at all.
Kingsley Idehen's summary of his approach's core insight: reuse existing Web architecture — HTTP, WebDAV, dereferenceable IRIs — as the graph's substrate, instead of standing up a proprietary graph-database platform.
Once relationships between entities are explicit in the graph, the model stops filling gaps from its own prior and starts operating within stated boundaries — its failure mode shifts from confidently wrong answers to visibly missing ones, which are easier to detect and fix.
ki theme runs Neo4j's Graph Data Science Leiden algorithm over the wiki graph to surface emergent topic clusters — for example a cluster of [[aip-paper]], [[aip]], and [[aip-launch-blog]] links — without anyone manually labeling the theme.
Not the same mechanism — and it does not need to be. agent-rdf-memory's relationships are typed against schema.org/domain ontologies at construction time, so deterministic reasoning (RDFS/OWL transitive closure, owl:sameAs/equivalentClass entailment, SKOS broader/narrower, SPARQL property-path queries) already derives grouping and thematic structure from those asserted semantics — reasoning outward from declared meaning, not guessing statistically from raw link density. The real, narrower gap is Leiden's specific trick of finding emergent clusters over an untyped graph with zero semantic input; that gap matters less here because typed relationships were the point of this path from the first step.
It is real and shipped: agent-rdf-memory is the actual agent-rdf-memory/ directory in this repository, holding 277-plus schema:HowToStep behavioral rules, dozens of howto/*.ttl companions, and a chronological sessions/ log of corrected agent behavior over months of real use.
Neo4j's article names 'agent long-term memory' as an aspirational use case with no shipped implementation shown. agent-rdf-memory already runs that exact use case in production, on RDF/SPARQL/WebDAV rather than a property graph.
A governance/behavioral-contract layer: preferences.ttl is described as 'an operational behavioral contract,' tied directly to the Agent Engineering Stack article's Policy & Guardrails, Identity, and Evaluation layers, and enforced against the agent's own actions, not merely advisory.
It is already in production, beyond this one document. The generalized pattern is: (1) encounter a document of interest, (2) ask an AI-agent skill to generate an HTML + RDF knowledge-graph collection deployed as Linked Data, (3) upload that collection to a dedicated, publicly accessible WebDAV weblog folder. Two real, currently live examples of exactly this workflow: the URIBurner DaaS Weblog (232 posts as of this writing) and the OpenLink Software Weblog (222 posts), both Virtuoso-rendered views over a WebDAV collection of prior HTML/RDF generations — several of which are themselves Neo4j-vs-RDF and agent-rdf-memory comparison documents from the same lineage as this one.
Every entity and relationship in each post's companion RDF graph is queryable, not just full-text-searchable. A natural-language question compacts down to its subject-predicate-object essence — 'what links to what,' 'who authored which post,' 'which posts share a comparison dimension' — and that SPO shape maps directly onto a SPARQL WHERE clause, so a query template can be reused across every post in the collection rather than hand-written per document. The SPARQL Workbench below queries this exact document's own graph the same way; the weblog examples run the identical mechanism across hundreds of documents at once.
Andrej Karpathy's pattern for maintaining a knowledge base with an LLM coding agent: raw files ingested into a processed Markdown wiki, periodically distilled into curated summaries.
Neo4j's data model: labeled nodes and relationships, each carrying key-value properties — the model ki's Vault/Folder/Document/Section schema is built in.
A subject-predicate-object statement, the atomic unit of the Resource Description Framework — the model the AI-agent-skill approach and agent-rdf-memory are both built in.
An identifier that is also a working HTTP URL — fetching it returns a description of the thing it names, unlike a database-internal node ID.
The Linked Data practice of discovering related information by dereferencing one IRI, finding links to other IRIs in the response, and dereferencing those in turn.
Neo4j's proprietary graph query language, used for ki's structural navigation and graph-reason queries.
The W3C standard query language for RDF, runnable against any compliant triple/quad store — used throughout agent-rdf-memory's Virtuoso deployment and this document's SPARQL Workbench.
An HTTP extension for reading and writing files on a remote server as though it were a local filesystem — the substrate Kingsley Idehen's article and agent-rdf-memory both use to publish generated RDF.
A graph community-detection algorithm, available in Neo4j's Graph Data Science library and used by ki theme to surface emergent topic clusters with no manual labeling.
A queryable, persistent knowledge substrate an AI agent consults across sessions instead of re-deriving context from a fresh prompt each time — aspirational in the Neo4j article, shipped as agent-rdf-memory.
Kingsley Idehen's description of preferences.ttl: standing rules an agent is expected to follow, enforced at generation time rather than presented as passive documentation.
A shared vocabulary of types and properties (Person, Article, Question, HowToStep, and others) used to give AI-agent-skill-generated RDF and this document's own knowledge graph consistent, widely understood semantic typing.
A natural-language question reduced to its subject-predicate-object essence so it maps directly onto a reusable SPARQL WHERE-clause pattern — the mechanism that lets a deployed weblog of RDF+HTML collections be queried at scale instead of only full-text-searched.
An architecture combining a neural component (an LLM handling fuzzy natural-language input) with a symbolic component (SPARQL-based graph lookups, deterministic reasoning/inference, and, on Virtuoso, full-text and vector-similarity search). The LLM decomposes language to its subject-predicate-object essence; the symbolic layer resolves those fragments against typed entities already in the graph.
Interactive graph visualization derived from the companion RDF. Click nodes to resolve, drag to explore. Graph data embedded from companion RDF at generation time.
Track B above is not a one-off demonstration. The same three moves generalize into a standing workflow: (1) encounter a document of interest, (2) ask an AI-agent skill to generate an HTML + RDF knowledge-graph collection deployed as Linked Data, (3) upload that collection to a dedicated, publicly accessible WebDAV weblog folder. The result is queryable, not just readable — every entity and relationship compacts down to a subject-predicate-object query template, so a natural-language question becomes a reusable SPARQL WHERE pattern instead of a one-off prompt. This document's own SPARQL Workbench, directly below, queries exactly this document's graph the same way — the two weblogs here run the identical mechanism across hundreds of documents at once.
232 posts (as of this writing), Virtuoso-rendered live over a WebDAV folder of prior HTML + RDF generations — full-text searchable, RSS/Atom syndicated, faceted by category (Semantic Web & RDF, AI Agents & LLMs, SPARQL & Querying, Knowledge Graphs, and more). Several posts already listed there are earlier entries in this same document's own comparison lineage. Visit the weblog →
222 posts, a second and independently deployed instance of the identical folder-to-weblog-to-queryable-data-space workflow — confirming the pattern is repeatable across separate WebDAV collections, not a one-off. Visit the weblog →
⚡ Live proof, not a diagram: the graph behind this whole document — sources, comparison dimensions, FAQ, glossary, both HowTo tracks, and this Beyond-LLM-Wiki showcase — is queryable right now, below. This is the same SPARQL-Workbench mechanism the URIBurner DaaS and OpenLink Software weblogs run across hundreds of documents at once.
Choose a query recipe, edit the SPARQL if needed, then open the encoded URIBurner query.
SELECT uses text/x-html+tr. DESCRIBE and CONSTRUCT use text/x-html-nice-turtle, matching the SPARQL format guidance in the skill contract.