Linked Data Meshup · Comparative Analysis

Everyone draws the same graph. The only real fight is about where it lives.

KG curated by kg-generator, rdf-infographic-skill and DeepSeek V4 Pro on behalf of Kingsley Uyi Idehen
Source: Atlan Context & Chaos · Where Should the Graph Live? (Austin Kronz) · also on LinkedIn Pulse (Prukalpa Sankar)
Customer Account Plan Policy refund
The drawing — every team draws circles joined by lines, never tables

“Having a graph and running a graph database are not the same commitment.”

— Emil Eifrem, CEO & co-founder of Neo4j — the last thing you'd expect from someone who builds graph databases
The source

Four homes, one per workload

Memory, files, warehouse tables, or a graph database — the same drawing, four homes, chosen one workload at a time, with an honest “it depends” at rung two.

agent-rdf-memory

Portable RDF, any home

agent-rdf-memory on a Semantic Web — the article's three jobs as portable RDF that lives in any of the four homes, queried live with SPARQL.

Thesis at a Glance

Austin Kronz's Context & Chaos piece separates the drawing from the store: “having a graph and running a graph database are not the same commitment.” A three-rung customer scenario shows the answer is per-workload — a relational look-up at rung one, an empirical “it depends” at rung two, and a live traversal at rung three — and names three non-optional jobs: the operational store, agent memory, and the decision-trace context platform.

This meshup adds agent-rdf-memory — an RDF-based agent-memory harness deployed using Linked Data principles, i.e. a Semantic Web of queryable named graphs — as the concrete answer. The article's three jobs (operational store, agent memory, decision-trace context platform) become portable RDF, queried live with SPARQL; the demo below models Dana's roaming charge as synthetic RDF and answers the three rungs live.

Convergence Thesis

The source is right that the model is not the store, and that the three jobs are non-optional. agent-rdf-memory's contribution is making the model portable RDF: the same graph serves rung one (RDF Views over tables), rung two (decision traces with provenance) and rung three (graph traversal) — a live instance of jobs two and three, queryable in place, on whatever store serves the workload.

01 · The architecture

The drawing, its four homes, and the ladder

The article separates the drawing (the business model) from the store (where it lives), then walks a three-rung ladder that raises the stakes until the architecture has to change.

the drawingGfour homes

In memory

Fast, and gone when the process ends.

Files in cloud storage

Durable and cheap — not traversable under query.

Warehouse tables

No new store; joins are the only traversal.

A graph database

Traversal is native, at the cost of a second store.

Same drawing, four homes

And the drawing does not care which you pick. That is the load-bearing distinction — and the reason agent-rdf-memory can be the portable answer: because its model is RDF on a Semantic Web, the same graph moves between homes without re-modeling.

Three rungs, one customer — raise the stakes

The article keeps Dana's forty-dollar roaming charge the whole way up, raising the stakes until the storage argument changes.

1Look it up

Rung one — the standard support picture

Dana calls about a forty-dollar roaming charge. The agent needs who Dana is, what her plan covers, the refund policy, and any known outages on her line.

Storage argument: consistent, known queries — the same four or five joins, over a schema that is not moving. A relational database is probably fine.
2Decide & record

Rung two — the denial was wrong

The network event log and the billing system disagree about when the outage began, and the plan end-date was migrated incorrectly. A human overrides — and the finding must work back into context.

Storage argument: genuinely “it depends” — the decision, the reasoning, the systems reconciled and the person who stood behind it are relationships worth more than the objects.
3Cross the network

Rung three — who is affected right now

Something breaks and it is not just Dana. The agent must follow the network outward from the break — towers, customers, contracts that start owing money the moment service drops — while the phones ring.

Storage argument: the break shapes the question, not you — no fixed query to write in advance. This is what a graph database is for.

Objects describe

When the relationships just describe the objects, any store will do.

→the threshold

Relationships carry the answer

When the lines start carrying the answer — many hops, fast, under load — you need the graph.

02 · The head-to-head

Twelve comparison dimensions, two terms

Every aspect is a first-class entity in the companion knowledge graph — click a dimension name to open its RDF description. Table on wide screens; entity cards on narrow screens.

Table view on wide screens; entity cards on narrow screens.
Aspect The four homes — source framework agent-rdf-memory — a Semantic Web RDF harness
The core questionSource: there is no single answer — there is an answer per workload, and it is less satisfying than the diagram anyone will sell you. A routing choice you make one workload at a time.agent-rdf-memory: the routing question becomes moot at the model layer — because the graph is portable RDF, the same model lives in any home, and 'where' is a deployment detail rather than a re-modeling.
Model vs store separationSource: 'having a graph and running a graph database are not the same commitment.' The same drawing has four homes — memory, files, warehouse tables, or a graph database — and the drawing does not care which you pick.agent-rdf-memory: embodies the separation by construction — the model is RDF (home-agnostic triples) and the store is whichever home serves the workload, so the drawing and the home never entangle.
The four homesSource: memory, files in cloud storage, tables in the warehouse you already run, or a database built for connected data — four different homes, each a different store, each a different purchase.agent-rdf-memory: the same graph is at home in all four — held in memory, serialized to files, mapped onto warehouse tables via RDF Views, or loaded into a quad store — because RDF assumes no particular store.
Rung one — known lookupsSource: a relational database is probably fine — this rung likely does not need a graph database.agent-rdf-memory: agreed — rung one is served from whichever home already holds the facts, and RDF Views expose relational tables as triples in place, so no second store is needed.
Rung two — decisions & provenanceSource: genuinely 'it depends' — could be a graph database (the emerging context graph), could be the relational store and warehouse you already run. The answer is empirical: accuracy on evals, maintainability by hop count, latency, volatility, and the cost of the copy.agent-rdf-memory: the decision, its reasoning, the two systems it reconciled, the policy it bent and the person who stood behind it are RDF statements with prov:wasGeneratedBy — provenance queryable in the same SPARQL, whatever home the graph lives in.
Rung three — live traversalSource: this is what a graph database is for — when relationships stop describing the objects and start carrying the answer, traversed many hops, fast, under load.agent-rdf-memory: the topology is RDF, crossed with SPARQL property paths — the rung-three graph is traversable because it was modeled as a graph, not retro-fitted onto tables.
The agent-memory jobSource: 'memory is an intrinsically graph-centric workload' — even the initial MCP spec shipped a graph memory (a 500-line toy), and a wave of agent-memory startups landed on the same structure independently.agent-rdf-memory: a production instance of exactly that — core.ttl (identity), preferences.ttl (the behavioral contract), sessions/ (episodic), entities/ (semantic) and howto/ (procedural) as RDF named graphs, queried with SPARQL.
The context-platform jobSource: traces ('I walked this path to make a decision') become skills; a skill with no link back to what produced it is a snapshot with no expiry date.agent-rdf-memory: the same loop as queryable provenance — sessions/ and howto/ are decision traces and skills as RDF, linked by prov:wasGeneratedBy, so supersede/retire/write-new is a query, not a snapshotted log.
RetrievalSource: Prukalpa is blunt that retrieval is open — 'should you retrieve via graph, should you retrieve via keyword' — and expects all of it to change inside a year.agent-rdf-memory: ontology-routed SPARQL context selection over named graphs, with full-text and vector fallbacks and filesystem reads as the last resort — retrieval is a query, not a bespoke fan-out.
Modeling costSource: an ontology can be bootstrapped bottom-up out of the systems you already run — point at Postgres, Snowflake or Databricks and the tables become a proposed graph — 'bottom-up produced by AI meets top-down,' a draft a human corrects rather than authors.agent-rdf-memory: the same bootstrap is native — RDF Views (R2RML) turn existing relational schemas into a graph without copying, and the sponger reverse-constructs RDF from existing data; the human corrects, the model stays portable.
Query costSource: 'How do I query?' used to be the barrier; now the LLM speaks natural language and compiles to Cypher/GQL underneath, so specialized query skills are no longer a prerequisite.agent-rdf-memory: the LLM compiles natural language to SPARQL — one open, W3C-standard query language across every home — so query skill is not a per-store purchase and the same question is answerable everywhere.
Volatility & maintainabilitySource: two or three joins is routine, six is a conversation, and past some depth the query becomes something only its author can safely change — fixed, known queries reward the store you have; open-ended traversal is where a second store starts to make sense.agent-rdf-memory: SPARQL property paths express arbitrary-depth traversal declaratively, and inference keeps derived links in step as definitions drift — the hop-count wall is a language feature, not an architecture change.
Source

The four homes — source framework

The core question
Source: there is no single answer — there is an answer per workload, and it is less satisfying than the diagram anyone will sell you. A routing choice you make one workload at a time.
Model vs store separation
Source: 'having a graph and running a graph database are not the same commitment.' The same drawing has four homes — memory, files, warehouse tables, or a graph database — and the drawing does not care which you pick.
The four homes
Source: memory, files in cloud storage, tables in the warehouse you already run, or a database built for connected data — four different homes, each a different store, each a different purchase.
Rung one — known lookups
Source: a relational database is probably fine — this rung likely does not need a graph database.
Rung two — decisions & provenance
Source: genuinely 'it depends' — could be a graph database (the emerging context graph), could be the relational store and warehouse you already run. The answer is empirical: accuracy on evals, maintainability by hop count, latency, volatility, and the cost of the copy.
Rung three — live traversal
Source: this is what a graph database is for — when relationships stop describing the objects and start carrying the answer, traversed many hops, fast, under load.
The agent-memory job
Source: 'memory is an intrinsically graph-centric workload' — even the initial MCP spec shipped a graph memory (a 500-line toy), and a wave of agent-memory startups landed on the same structure independently.
The context-platform job
Source: traces ('I walked this path to make a decision') become skills; a skill with no link back to what produced it is a snapshot with no expiry date.
Retrieval
Source: Prukalpa is blunt that retrieval is open — 'should you retrieve via graph, should you retrieve via keyword' — and expects all of it to change inside a year.
Modeling cost
Source: an ontology can be bootstrapped bottom-up out of the systems you already run — point at Postgres, Snowflake or Databricks and the tables become a proposed graph — 'bottom-up produced by AI meets top-down,' a draft a human corrects rather than authors.
Query cost
Source: 'How do I query?' used to be the barrier; now the LLM speaks natural language and compiles to Cypher/GQL underneath, so specialized query skills are no longer a prerequisite.
Volatility & maintainability
Source: two or three joins is routine, six is a conversation, and past some depth the query becomes something only its author can safely change — fixed, known queries reward the store you have; open-ended traversal is where a second store starts to make sense.
RDF

agent-rdf-memory — a Semantic Web RDF harness

The core question
agent-rdf-memory: the routing question becomes moot at the model layer — because the graph is portable RDF, the same model lives in any home, and 'where' is a deployment detail rather than a re-modeling.
Model vs store separation
agent-rdf-memory: embodies the separation by construction — the model is RDF (home-agnostic triples) and the store is whichever home serves the workload, so the drawing and the home never entangle.
The four homes
agent-rdf-memory: the same graph is at home in all four — held in memory, serialized to files, mapped onto warehouse tables via RDF Views, or loaded into a quad store — because RDF assumes no particular store.
Rung one — known lookups
agent-rdf-memory: agreed — rung one is served from whichever home already holds the facts, and RDF Views expose relational tables as triples in place, so no second store is needed.
Rung two — decisions & provenance
agent-rdf-memory: the decision, its reasoning, the two systems it reconciled, the policy it bent and the person who stood behind it are RDF statements with prov:wasGeneratedBy — provenance queryable in the same SPARQL, whatever home the graph lives in.
Rung three — live traversal
agent-rdf-memory: the topology is RDF, crossed with SPARQL property paths — the rung-three graph is traversable because it was modeled as a graph, not retro-fitted onto tables.
The agent-memory job
agent-rdf-memory: a production instance of exactly that — core.ttl (identity), preferences.ttl (the behavioral contract), sessions/ (episodic), entities/ (semantic) and howto/ (procedural) as RDF named graphs, queried with SPARQL.
The context-platform job
agent-rdf-memory: the same loop as queryable provenance — sessions/ and howto/ are decision traces and skills as RDF, linked by prov:wasGeneratedBy, so supersede/retire/write-new is a query, not a snapshotted log.
Retrieval
agent-rdf-memory: ontology-routed SPARQL context selection over named graphs, with full-text and vector fallbacks and filesystem reads as the last resort — retrieval is a query, not a bespoke fan-out.
Modeling cost
agent-rdf-memory: the same bootstrap is native — RDF Views (R2RML) turn existing relational schemas into a graph without copying, and the sponger reverse-constructs RDF from existing data; the human corrects, the model stays portable.
Query cost
agent-rdf-memory: the LLM compiles natural language to SPARQL — one open, W3C-standard query language across every home — so query skill is not a per-store purchase and the same question is answerable everywhere.
Volatility & maintainability
agent-rdf-memory: SPARQL property paths express arbitrary-depth traversal declaratively, and inference keeps derived links in step as definitions drift — the hop-count wall is a language feature, not an architecture change.
03 · The live demonstration

The article's three rungs, as live SPARQL over synthetic RDF

The agent-rdf-memory solution demonstrated concretely. Below, a synthetic RDF graph models the article's running example — Dana's forty-dollar roaming charge, the two systems that disagree about the outage, the human override, the distilled skill, and the rung-three network — then the three rungs plus the model/store, three-jobs and decision-to-skill questions are answered live in SPARQL over the named graph.

The point of the demo

The article argues the graph's value shows at rung two (the finding must work back into context) and rung three (cross the network under load). The same rungs are SPARQL queries: a look-up is a few joins, the override is a gld:reconciles link carrying provenance, the traversal is a graph walk, and the decision trace distills into a skill via gld:distilledInto — each projecting an IRI you can click through to resolve.

Sample Turtle — Dana's roaming charge as an RDF graph▼
@prefix gld:    <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-demo#> .
@prefix schema: <http://schema.org/> .
@prefix prov:   <http://www.w3.org/ns/prov#> .
@prefix xsd:    <http://www.w3.org/2001/XMLSchema#> .

# Rung one -- the look-up facts
gld:dana     a schema:Person ; schema:name "Dana"@en ;
    gld:holdsPlan gld:planGold ; gld:affectedBy gld:outage1 .
gld:planGold a gld:Plan ; schema:name "Gold Roaming Plan"@en ;
    gld:endedOn "2026-08-14"^^xsd:date .
gld:refundPolicy a gld:Policy ; schema:name "No refund outside an active plan"@en ;
    gld:appliesTo gld:planGold .
gld:roamingCharge a gld:Charge ; schema:name "Roaming charge"@en ;
    gld:amount "40.00"^^xsd:decimal ; gld:currency "USD" ; gld:charges gld:dana .

# Rung two -- the two systems that disagree, and the override that records why
gld:networkEventLog a gld:SystemOfRecord ; schema:name "Network event log"@en ;
    gld:recordsOutageStart "2026-08-13"^^xsd:date .
gld:billingSystem a gld:SystemOfRecord ; schema:name "Billing system"@en ;
    gld:recordsOutageStart "2026-08-15"^^xsd:date .
gld:override a gld:Override ; schema:name "Refund approved (human override)"@en ;
    gld:overrides gld:denial ;
    gld:reconciles gld:networkEventLog, gld:billingSystem ;
    prov:wasGeneratedBy gld:supervisor .
gld:finding a gld:Finding ; schema:name "Migrated plan end-date + outage-window disagreement"@en ;
    gld:records gld:override .

# The context-platform loop -- decision trace distilled into a skill
gld:trace a gld:DecisionTrace ; schema:name "Decision trace: roaming-refund override"@en ;
    prov:wasGeneratedBy gld:override ; gld:distilledInto gld:skillReconcile .
gld:skillReconcile a gld:Skill ; schema:name "Reconcile outage windows before denying a roaming refund"@en .

# Rung three -- the live network under a break
gld:towerA a gld:Tower ; schema:name "Tower A"@en ; gld:serves gld:dana .
gld:towerB a gld:Tower ; schema:name "Tower B"@en ; gld:serves gld:acme .
gld:acme a schema:Organization ; schema:name "Acme Logistics"@en .
gld:contractAcme a gld:SlaContract ; schema:name "Business SLA — credit accrues on drop"@en ;
    gld:covers gld:acme .
Rung one — the standard support picture (a look-up)▼
PREFIX schema: <http://schema.org/>
PREFIX gld: <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-demo#>
SELECT ?customerIri ?customer ?planIri ?plan ?policyIri ?policy ?chargeIri ?charge ?amount
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?customerIri a schema:Person ; schema:name ?customer ; gld:holdsPlan ?planIri .
    ?planIri schema:name ?plan .
    ?policyIri a gld:Policy ; schema:name ?policy ; gld:appliesTo ?planIri .
    ?chargeIri a gld:Charge ; schema:name ?charge ; gld:amount ?amount ; gld:charges ?customerIri .
  }
}
ORDER BY ?customer
Run live
Rung two — what was decided, why, and what changed▼
PREFIX schema: <http://schema.org/>
PREFIX prov: <http://www.w3.org/ns/prov#>
PREFIX gld: <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-demo#>
SELECT ?overrideIri ?override ?systemIri ?system ?outageStart ?findingIri ?finding
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?overrideIri a gld:Override ; schema:name ?override ;
      gld:reconciles ?systemIri ; gld:records ?findingIri .
    ?systemIri a gld:SystemOfRecord ; schema:name ?system ; gld:recordsOutageStart ?outageStart .
    ?findingIri a gld:Finding ; schema:name ?finding .
  }
}
ORDER BY ?system
Run live
Rung three — who is affected right now (traversal)▼
PREFIX schema: <http://schema.org/>
PREFIX gld: <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-demo#>
SELECT ?towerIri ?tower ?customerIri ?customer ?contractIri ?contract
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?towerIri a gld:Tower ; schema:name ?tower ; gld:serves ?customerIri .
    ?customerIri schema:name ?customer .
    OPTIONAL { ?contractIri a gld:SlaContract ; schema:name ?contract ; gld:covers ?customerIri . }
  }
}
ORDER BY ?tower
Run live
The drawing vs the store — the model is independent of its home▼
PREFIX schema: <http://schema.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX : <https://atlan.com/context-and-chaos/issue/where-should-the-graph-live#>
SELECT ?homeIri ?home ?decision
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?homeIri a :GraphHome ; schema:name ?home ; schema:description ?decision .
  }
}
ORDER BY ?home
Run live
The three non-optional jobs the graph does▼
PREFIX schema: <http://schema.org/>
PREFIX : <https://atlan.com/context-and-chaos/issue/where-should-the-graph-live#>
SELECT ?jobIri ?job ?settledness
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?jobIri a :GraphJob ; schema:name ?job ; schema:description ?settledness .
  }
}
ORDER BY ?job
Run live
From decision trace to skill — the context-platform loop▼
PREFIX schema: <http://schema.org/>
PREFIX prov: <http://www.w3.org/ns/prov#>
PREFIX gld: <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-demo#>
SELECT ?traceIri ?trace ?skillIri ?skill ?skillDate
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?traceIri a gld:DecisionTrace ; schema:name ?trace ;
      prov:wasGeneratedBy ?overrideIri ; gld:distilledInto ?skillIri .
    ?skillIri a gld:Skill ; schema:name ?skill ; schema:dateCreated ?skillDate .
  }
}
ORDER BY ?skillDate
Run live
04 · The agent side

agent-rdf-memory mapped onto the article's three jobs

The article's three non-optional jobs mapped one-for-one onto agent-rdf-memory: the operational store becomes the business data graph over RDF Views; agent memory becomes the named-graph memory store (core/preferences/sessions/entities/howto); and the context platform becomes the decision-trace→skill provenance loop over sessions/ and howto/ — all as portable RDF named graphs.

Job 1 · settled

Operational store

The system of record for an entity and its connections — the article's rung three, settled long before anyone said “agent.”

agent-rdf-memory: RDF Views (R2RML) expose the warehouse and relational tables as a graph in place — zero copy.
Job 2 · converged

Agent memory

What the agent has learned and can reuse — an “intrinsically graph-centric workload” that the MCP toy and a wave of startups reached independently.

agent-rdf-memory: core.ttl, preferences.ttl, sessions/, entities/ and howto/ as RDF named graphs.
Job 3 · newest

Context platform

The decision-trace graph — traces distilled into skills, with provenance that forces a supersede/retire/write-new decision.

agent-rdf-memory: sessions/ and howto/ are traces and skills linked by prov:wasGeneratedBy.

Operational store ↔ RDF Views over the warehouse

The article's job one is the system of record for an entity and its connections. agent-rdf-memory's operational half maps to RDF Views (R2RML) that expose the warehouse and relational tables as a graph in place — zero copy, same store.

Agent memory ↔ named-graph memory store

The article's job two is what the agent has learned. agent-rdf-memory stores it as core.ttl (identity), preferences.ttl (procedural contract), sessions/ (episodic), entities/ (semantic) and howto/ (procedural) — each a named graph, each independently governable and queryable.

Context platform ↔ decision-trace provenance

The article's job three distills traces into skills with provenance. agent-rdf-memory does the same: every session and howto is a decision trace or a skill linked by prov:wasGeneratedBy, so supersede/retire/write-new is a SPARQL query, not a snapshotted log.

Skills retrieval ↔ ontology-routed SPARQL

Where the article calls skills retrieval an open problem, agent-rdf-memory answers with ontology-routed SPARQL context selection over named graphs, full-text/vector fallbacks, and filesystem reads as the last resort.

Provenance ↔ PROV-O dates on every write

Where the article wants 'why did we approve a refund like Dana's last quarter' to be answerable, agent-rdf-memory stamps every statement and session with schema:dateCreated and prov:wasGeneratedBy — history is PROV-O, queryable in the same SPARQL.

The graph is the source of truth

core.ttl, preferences.ttl, index.ttl, ontology.ttl, and the sessions/, entities/, projects/, and howto/ folders are RDF named graphs, queried via SPARQL at the local endpoint or URIBurner. Learning is cross-LLM and cross-environment — session filenames carry provenance, not isolation — and the synthetic demo graph below is loaded into the same store, alongside the memory.

05 · The playbook

Decide where the graph lives — and keep the model portable

A seven-step guide that separates the model from the store, walks the three-rung ladder, then deploys the answer with agent-rdf-memory.

Separate the drawing from the store

Treat the business model (the concepts and how they connect) and the physical store as two independent decisions. Same drawing, four homes — decide each on its own merits, not as one bundled purchase.

Walk the three-rung ladder

Take one decision and raise the stakes: rung one (a look-up), rung two (a decision with a finding), rung three (live traversal under load). Note which rung your hardest agent decisions actually sit on.

Answer rung two empirically

Instrument the agent and measure — accuracy on your own evals, maintainability by hop count, latency, volatility, and the cost of the copy. Anyone who names your rung-two answer without running it is guessing.

Run the ladder twice

Run it once for the business decision the agent supports, and once for the agent's own memory — what it has learned, where it lives, and how you will know when it has expired. Most teams never run the second ladder.

Keep the model portable across the four homes

Model the business once as RDF, then serve rung one from relational tables via RDF Views, rung two as decision triples with provenance, and rung three with SPARQL property paths — the same model, whichever home each rung needs.

Deploy agent-rdf-memory for jobs two and three

Load core.ttl, preferences.ttl, index.ttl, ontology.ttl, sessions/, entities/, projects/ and howto/ as RDF named graphs on a quad store; the graph becomes the agent's queryable memory, with file reads as fallback.

Query the decision live

Serve the graph over the SPARQL endpoint and run the demo recipes — the three rungs, the four homes, the three jobs, and the decision-to-skill loop — to confirm retrieval, provenance and traversal behave as promised.

06 · Questions & answers

Frequently asked questions

What is the article's central distinction?▼
The model and the store are two different decisions. A model of your business — the concepts and how they connect — is one thing; the physical store you put it in is another. It can sit in memory, in files, as warehouse tables, or in a graph database, and the drawing itself does not care which you pick.
What are the three rungs in the Dana example?▼
Rung one is a look-up: the standard support picture (who Dana is, her plan, the policy, known outages) — consistent joins a relational database handles fine. Rung two is a decision: the denial was wrong, a human overrides, and the value is the finding that must work back into context. Rung three is live traversal: a network break whose affected customers must be found by crossing the graph under load while phones ring.
When does the article say you need a graph database?▼
When the relationships between things become more valuable than the objects themselves, you need the graph; when those relationships have to be traversed across many hops, fast, under load, while someone waits — that is when you need the graph database. Rung two is the first; rung three is both.
Why is this a live decision only now?▼
Cost, not capability. Graphs and ontologies stayed niche for decades because modeling and querying were expensive. The query cost is largely gone (natural language), and the modeling cost collapsed — an ontology can be bootstrapped bottom-up from the systems you already run. Emil calls the pattern 'bottom-up produced by AI meets top-down.'
What are the three jobs a graph does in enterprise AI?▼
The operational store (the system of record for an entity and its connections), agent memory (what the agent has learned), and the context platform (decision traces distilled into skills with provenance). All three are non-optional; storage and retrieval are the per-workload choices.
Where does agent-rdf-memory fit?▼
It is the concrete answer: the article's three jobs expressed as portable RDF on a Semantic Web — a model that lives in any of the four homes and moves between them without re-modeling. agent-rdf-memory is a live instance of the agent-memory and context-platform jobs; the demo runs it on a Virtuoso quad store behind a SPARQL endpoint.
How does agent-rdf-memory map onto the article's three jobs?▼
Point for point: the operational store → RDF Views over the warehouse (tables as triples, in place); agent memory → core.ttl, preferences.ttl, sessions/, entities/ and howto/ as RDF named graphs; the context platform → the decision-trace→skill provenance loop over sessions/ and howto/, linked by prov:wasGeneratedBy.
Can I reproduce the article's three rungs in SPARQL?▼
Yes — that is exactly the demo in this collection. The synthetic graph models Dana, her plan, the refund policy, the two disagreeing systems, the human override, the distilled skill and the rung-three towers/customers/contracts, and six live SPARQL recipes answer the three rungs plus the model/store, three-jobs and decision-to-skill questions over the named graph.
What are the trade-offs?▼
The source's answer is honest 'it depends' — four homes, chosen empirically per workload, with no matrix to tell you which is yours. agent-rdf-memory trades that for a portable RDF model that lives in any home, but asks you to adopt RDF/SPARQL and to keep inference RDFS/OWL-subset rather than full OWL 2.
Does the model survive a move between homes?▼
Only if the model is portable. RDF IRIs make the same entity the same entity in memory, in files, in the warehouse, or in a graph database — so moving homes is a relocation, not a re-modeling. This is the hyperlinks-as-identifiers thesis of this meshup.
How does agent-rdf-memory stay fail-safe?▼
The SPARQL endpoint degrades to filesystem file reads when it is down, named graphs are independent, and every write carries schema:dateCreated/schema:dateModified and prov:wasGeneratedBy — the same 'memory breaking must not break the agent' invariant, enforced structurally.
Is one approach clearly better?▼
They answer the same question at different levels of consolidation. Choose the source's per-workload routing when each rung genuinely earns a best-of-breed store; choose agent-rdf-memory when you want the model to be portable RDF on a Semantic Web — the four homes and three jobs in one standards-based model, with the decision itself queryable in SPARQL rather than scattered across stores.
07 · The vocabulary

Core terms

Agent Memory

Durable, cross-session storage of what an agent learns — identity, facts, preferences, decisions and their relationships — so the agent can recall them at the right moment.

Bottom-up Bootstrap

Emil Eifrem's pattern for collapsing the modeling cost: point at the systems you already run, read the tables and data model, and derive a proposed graph — 'bottom-up produced by AI meets top-down.'

Context Graph

The emerging term for the graph that holds what an agent decided, why, and what that changed — the newest and least-settled of the three graph jobs.

Context Repos

Atlan's term for bounded, governed, versioned bundles of context — how a company defines key concepts and makes decisions — exposed through open interfaces to agents and copilots.

Convergent dimension

The source's framing and the agent-rdf-memory answer agree in substance; they differ in vocabulary and mechanism, not in the underlying claim.

Decision-Trace Graph

Emil Eifrem's more accurate name for the context graph: most of what it holds is decision traces — the paths agents walked to make decisions — distilled into skills.

Divergent dimension

The approaches differ in kind: what the store is, how the model and the store relate, and how many engines the answer demands.

Graph Database

A store built for connected data, where traversal is native — the article's point is that having a graph and running a graph database are two different commitments.

GraphRAG

Retrieval that adds a concepts layer over chunks: extract entities and relationships first, then follow links outward from a similarity-search entry point, so multi-hop reach and an inspectable path replace pure vector similarity.

Impedance Mismatch

Emil Eifrem's term for the gap between the whiteboard picture (circles joined by lines) and the relational schema it has to become — the gap now sitting under enterprise AI.

Knowledge Graph

A graph-based model of a domain in which entities become nodes, connections become relationships, and rules organise it all — the 'drawing' the article separates from the store it lives in.

Linked Data

Best practices for publishing structured data on the web using HTTP URIs as identifiers and hyperlinks to connect entities.

Named Graph

A set of RDF triples identified by an IRI, stored as a quad — the mechanism RDF stores use to partition and govern graphs, and how agent-rdf-memory keeps its memory kinds separate.

Ontology

A formal model of the concepts and relationships in a domain — historically expensive to build, now bootstrapable bottom-up from existing systems and corrected by a human.

Ontology-washing

Emil Eifrem's coinage (after cloud-washing) for the loose, sales-flavored use of 'ontology,' 'knowledge graph' and 'context graph' to mean whatever the speaker needs them to mean.

Provenance

The record of where a statement came from and when — modeled with PROV-O and schema:dateCreated, so 'why did we approve a refund like Dana's last quarter?' has an answer.

Quad Store

A database that stores RDF triples plus a fourth element — the named graph IRI — enabling graph-level partitioning, provenance and access control.

RDF

The W3C data model of subject-predicate-object triples — the model behind agent-rdf-memory and the graph format the demo data is written in.

RDF Views

A declarative mapping of relational schemas to RDF ontologies via Quad Map Patterns or R2RML; SPARQL is compiled to SQL and runs in place — the zero-copy answer to modeling cost, and the mechanism that lets a graph live in the warehouse without moving it.

SPARQL

The W3C query language for RDF graphs — the language of a Semantic Web, and of the live demo queries in this collection.

Semantic Web

A web of linked data — the W3C stack of RDF triples, SPARQL queries and Linked Data identifiers that agent-rdf-memory sits atop, which is what makes its model portable across the four homes.

Workbench

SPARQL Workbench

Query the companion knowledge graph live on URIBurner. Select a recipe, edit, and run — or open the query in the workbench.

Open in SPARQL workbench
Rung one — the standard support picture (a look-up)▼
PREFIX schema: <http://schema.org/>
PREFIX gld: <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-demo#>
SELECT ?customerIri ?customer ?planIri ?plan ?policyIri ?policy ?chargeIri ?charge ?amount
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?customerIri a schema:Person ; schema:name ?customer ; gld:holdsPlan ?planIri .
    ?planIri schema:name ?plan .
    ?policyIri a gld:Policy ; schema:name ?policy ; gld:appliesTo ?planIri .
    ?chargeIri a gld:Charge ; schema:name ?charge ; gld:amount ?amount ; gld:charges ?customerIri .
  }
}
ORDER BY ?customer
Run live
Rung two — what was decided, why, and what changed▼
PREFIX schema: <http://schema.org/>
PREFIX prov: <http://www.w3.org/ns/prov#>
PREFIX gld: <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-demo#>
SELECT ?overrideIri ?override ?systemIri ?system ?outageStart ?findingIri ?finding
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?overrideIri a gld:Override ; schema:name ?override ;
      gld:reconciles ?systemIri ; gld:records ?findingIri .
    ?systemIri a gld:SystemOfRecord ; schema:name ?system ; gld:recordsOutageStart ?outageStart .
    ?findingIri a gld:Finding ; schema:name ?finding .
  }
}
ORDER BY ?system
Run live
Rung three — who is affected right now (traversal)▼
PREFIX schema: <http://schema.org/>
PREFIX gld: <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-demo#>
SELECT ?towerIri ?tower ?customerIri ?customer ?contractIri ?contract
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?towerIri a gld:Tower ; schema:name ?tower ; gld:serves ?customerIri .
    ?customerIri schema:name ?customer .
    OPTIONAL { ?contractIri a gld:SlaContract ; schema:name ?contract ; gld:covers ?customerIri . }
  }
}
ORDER BY ?tower
Run live
The drawing vs the store — the model is independent of its home▼
PREFIX schema: <http://schema.org/>
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX : <https://atlan.com/context-and-chaos/issue/where-should-the-graph-live#>
SELECT ?homeIri ?home ?decision
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?homeIri a :GraphHome ; schema:name ?home ; schema:description ?decision .
  }
}
ORDER BY ?home
Run live
The three non-optional jobs the graph does▼
PREFIX schema: <http://schema.org/>
PREFIX : <https://atlan.com/context-and-chaos/issue/where-should-the-graph-live#>
SELECT ?jobIri ?job ?settledness
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?jobIri a :GraphJob ; schema:name ?job ; schema:description ?settledness .
  }
}
ORDER BY ?job
Run live
From decision trace to skill — the context-platform loop▼
PREFIX schema: <http://schema.org/>
PREFIX prov: <http://www.w3.org/ns/prov#>
PREFIX gld: <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-demo#>
SELECT ?traceIri ?trace ?skillIri ?skill ?skillDate
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?traceIri a gld:DecisionTrace ; schema:name ?trace ;
      prov:wasGeneratedBy ?overrideIri ; gld:distilledInto ?skillIri .
    ?skillIri a gld:Skill ; schema:name ?skill ; schema:dateCreated ?skillDate .
  }
}
ORDER BY ?skillDate
Run live
Comparison dimensions and both approaches▼
PREFIX cdx: <https://linkeddata.uriburner.com/DAV/demos/daas/ontology-terms#>
PREFIX schema: <http://schema.org/>
PREFIX : <https://atlan.com/context-and-chaos/issue/where-should-the-graph-live#>
SELECT ?dimIri ?dim ?article ?virtuoso
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?dimIri a cdx:ComparisonDimension ; schema:name ?dim ;
      :hasArticleApproach/schema:text ?article ;
      :hasArmApproach/schema:text ?virtuoso .
  }
}
ORDER BY ?dim
Run live
agent-rdf-memory → the three jobs mapping▼
PREFIX schema: <http://schema.org/>
PREFIX : <https://atlan.com/context-and-chaos/issue/where-should-the-graph-live#>
SELECT ?mappingIri ?name ?description
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    :armSection schema:hasPart ?mappingIri .
    ?mappingIri schema:name ?name ; schema:description ?description .
  }
}
ORDER BY ?name
Run live
FAQ questions and answers▼
PREFIX schema: <http://schema.org/>
SELECT ?questionIri ?question ?answer
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?questionIri a schema:Question ; schema:name ?question ;
      schema:acceptedAnswer/schema:text ?answer .
  }
}
ORDER BY ?question
Run live
Glossary terms and definitions▼
PREFIX schema: <http://schema.org/>
SELECT ?termIri ?name ?definition
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?termIri a schema:DefinedTerm ; schema:name ?name ; schema:description ?definition .
  }
}
ORDER BY ?name
Run live
HowTo steps in order▼
PREFIX schema: <http://schema.org/>
SELECT ?stepIri ?position ?title
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?howto a schema:HowTo ; schema:step ?stepIri .
    ?stepIri schema:position ?position ; schema:name ?title .
  }
}
ORDER BY ?position
Run live
Thesis bullets (load-bearing claims)▼
PREFIX schema: <http://schema.org/>
PREFIX : <https://atlan.com/context-and-chaos/issue/where-should-the-graph-live#>
SELECT ?claimIri ?claim ?description
WHERE {
  GRAPH <https://linkeddata.uriburner.com/DAV/demos/daas/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?claimIri a schema:Claim ; schema:name ?claim ; schema:description ?description .
  }
}
ORDER BY ?claim
Run live
Entity-type summary of the knowledge graph▼
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/where-should-the-graph-live-vs-virtuoso-agent-rdf-memory-meshup-deepseek_v4pro-1.ttl> {
    ?s rdf:type ?type .
    OPTIONAL { ?s rdfs:label ?label }
  }
}
GROUP BY ?type
ORDER BY DESC(?entityCount)
Run live
Knowledge Graph

Interactive Knowledge Graph Explorer

Drag to pin nodes, double-click to unpin, click a node or edge to open its RDF description via URIBurner. Click the graph surface to arm zoom; click outside to release.

0 nodes / 0 links

KG Settings

Physics

Charge-350
Link distance110
Collision16

Node filters

Resolver

Arrow style

Predicates

Articles Demo graph Software Concepts Dimensions Organizations People