@prefix cdx: . @prefix gld: . @prefix owl: . @prefix post: . @prefix prov: . @prefix rdf: . @prefix rdfs: . @prefix schema: . @prefix xsd: . @prefix : . # ── Software products ──────────────────────────────────────────────────────── a schema:SoftwareApplication ; schema:name "Virtuoso Universal Server"@en ; schema:description "OpenLink's converged virtual DBMS: relational tables and RDF graphs in one quad-store engine, queried in SQL, SPARQL, SPASQL, GraphQL, GQL and openCypher, with named graphs, RDFS/OWL-subset inference, RDF Views, and WebID/ACL security — the runtime on which agent-rdf-memory runs, and on which the live demo below is executed."@en ; schema:url "https://virtuoso.openlinksw.com/" ; schema:publisher . a schema:SoftwareApplication ; schema:name "URIBurner"@en ; schema:description "OpenLink's Linked Data service: a Virtuoso-backed SPARQL endpoint, RDF sponger, and describe/resolver used to run the live queries in this collection."@en ; schema:isBasedOn . a schema:SoftwareApplication ; schema:name "agent-rdf-memory"@en ; schema:description "An RDF-based AI-agent memory harness that sits atop a Semantic Web: identity (core.ttl), a queryable behavioral contract (preferences.ttl, 200+ HowToSteps), episodic sessions, semantic entities, procedural howtos, and SPARQL-routed context selection — a portable, store-agnostic memory graph that can live in any of the four homes, and a live instance of the article's 'graph as agent memory' and 'graph as context platform' jobs."@en ; schema:isBasedOn ; schema:publisher . a schema:SoftwareApplication ; schema:name "kg-generator"@en ; schema:description "AI agent skill that generates standards-compliant Knowledge Graphs from file: or http(s): sources."@en . a schema:SoftwareApplication ; schema:name "rdf-infographic-skill"@en ; schema:description "AI agent skill that renders RDF knowledge graphs as interactive HTML infographics under a strict harness contract."@en . a schema:SoftwareApplication ; schema:name "Neo4j"@en ; schema:description "The labeled-property-graph database platform built by Emil Eifrem — the 'antibiotics' the article credits with winning the acute cases (fraud rings, network topology, supply chains) where connections are the product."@en ; schema:url "https://neo4j.com/" ; schema:publisher ; owl:sameAs . a schema:SoftwareApplication ; schema:name "Atlan"@en ; schema:description "The context layer for enterprise AI — reads warehouses, databases, pipelines and BI tools to reverse-construct an enterprise data graph, then exposes governed context repos over SQL, APIs, SDKs and MCP-style protocols. Publisher of the Context & Chaos newsletter that ran the source article."@en ; schema:url "https://atlan.com/" ; schema:publisher . a schema:SoftwareApplication ; schema:name "Palantir"@en ; schema:description "The article's case-in-point for the historical modeling cost: Palantir deploys application-by-application rather than company-wide, because modeling a whole business costs more than any single answer is worth."@en ; schema:url "https://www.palantir.com/" . # ── Organizations ───────────────────────────────────────────────────────────── a schema:Organization ; schema:name "OpenLink Software"@en ; schema:description "Creator of Virtuoso and URIBurner, and the steward of the ai-agent-skills repository (including agent-rdf-memory)."@en ; schema:url "https://www.openlinksw.com/" . a schema:Organization ; schema:name "Neo4j, Inc."@en ; schema:description "The graph database company Emil Eifrem built on the observation that when you hand people a marker they draw circles joined by lines, never tables."@en ; schema:url "https://neo4j.com/" . a schema:Organization ; schema:name "Atlan Pte. Ltd."@en ; schema:description "The data-and-AI context company that publishes Context & Chaos. Founded 2019 in Singapore by Prukalpa Sankar and Varun Banka."@en ; schema:url "https://atlan.com/" . # ── People ──────────────────────────────────────────────────────────────────── a schema:Person ; schema:name "Austin Kronz"@en ; schema:jobTitle "Author, Context & Chaos"@en ; schema:description "Author of the source article 'Where Should the Graph Live?' (Atlan, 2026-09-17)."@en ; schema:url "https://www.linkedin.com/in/austinkronz/" ; schema:worksFor . a schema:Person ; schema:name "Prukalpa Sankar"@en ; schema:jobTitle "Co-founder & Co-CEO, Atlan; Chief Editor, Context & Chaos"@en ; schema:description "Atlan co-founder and the chief editor of Context & Chaos, who argued on the panel that a GPT-authored ontology is 'beautiful but not accurate' and that the only way to develop judgment is to 'build yourself personally.' She republished the source article on her LinkedIn Pulse (display name 'Prukalpa ⚡')."@en ; schema:url "https://www.linkedin.com/in/prukalpa/" ; schema:worksFor ; owl:sameAs , . a schema:Person ; schema:name "Emil Eifrem"@en ; schema:jobTitle "CEO and Co-founder, Neo4j"@en ; schema:description "Neo4j's CEO, who coined 'ontology-washing', named the impedance mismatch between the whiteboard drawing and the relational schema, and argued — despite building a graph database — that 'having a graph and running a graph database are not the same commitment.'"@en ; schema:url "https://www.linkedin.com/in/emileifrem/" ; schema:worksFor . a schema:Person ; schema:name "Kingsley Uyi Idehen"@en ; schema:jobTitle "Founder & CEO, OpenLink Software"@en ; schema:description "Principal of this meshup: founder of OpenLink Software, creator of Virtuoso, and steward of agent-rdf-memory."@en ; schema:url "https://www.linkedin.com/in/kidehen" . # ── Comparison scaffolding (ontology) ───────────────────────────────────────── :comparisonOntology a owl:Ontology ; schema:name "Where Should the Graph Live — Four Homes vs agent-rdf-memory Comparison Ontology"@en ; schema:description "Lightweight terms scaffolding a two-way comparison between the source article's 'where does the graph live' routing framework (four homes, answered per workload rung) and the agent-rdf-memory Semantic Web RDF harness, plus the sample decision-graph vocabulary used by the live demo."@en ; rdfs:label "Where Should the Graph Live — comparison ontology"@en ; rdfs:comment "Document-local vocabulary for a two-way meshup of the source article against agent-rdf-memory: the comparison-scaffolding properties (hasArticleApproach, hasArmApproach, classifies), the graph-home and graph-job analysis classes, and the synthetic decision-graph demo terms (gld:)."@en . :hasArticleApproach a owl:ObjectProperty ; rdfs:label "has article approach"@en ; rdfs:comment "Links a comparison dimension to the source article's framing of that dimension."@en ; rdfs:domain cdx:ComparisonDimension ; rdfs:range schema:Text ; rdfs:isDefinedBy :comparisonOntology . :hasArmApproach a owl:ObjectProperty ; rdfs:label "has agent-rdf-memory approach"@en ; rdfs:comment "Links a comparison dimension to agent-rdf-memory's approach to that dimension."@en ; rdfs:domain cdx:ComparisonDimension ; rdfs:range schema:Text ; rdfs:isDefinedBy :comparisonOntology . post:classifies a owl:ObjectProperty ; rdfs:label "classifies"@en ; rdfs:comment "Classifies a comparison dimension as convergent or divergent."@en ; rdfs:domain cdx:ComparisonDimension ; rdfs:range schema:DefinedTerm ; rdfs:isDefinedBy :comparisonOntology . post:dimConvergent a schema:DefinedTerm ; schema:name "Convergent dimension"@en ; schema:description "The source's framing and the agent-rdf-memory answer agree in substance; they differ in vocabulary and mechanism, not in the underlying claim."@en . post:dimDivergent a schema:DefinedTerm ; schema:name "Divergent dimension"@en ; schema:description "The approaches differ in kind: what the store is, how the model and the store relate, and how many engines the answer demands."@en . # ── Demo decision-graph vocabulary (the sample Turtle's own terms) ──────────── gld:Plan a rdfs:Class ; rdfs:label "Plan"@en ; rdfs:comment "A customer's service plan — the thing the support agent looks up at rung one and the thing whose migrated end-date caused the rung-two override."@en ; rdfs:subClassOf schema:Offer ; rdfs:isDefinedBy :comparisonOntology . gld:Policy a rdfs:Class ; rdfs:label "Policy"@en ; rdfs:comment "A business rule (e.g. 'no refund outside an active plan') that an agent applies — the 'known rules' half of the article's rung one."@en ; rdfs:subClassOf schema:CreativeWork ; rdfs:isDefinedBy :comparisonOntology . gld:Charge a rdfs:Class ; rdfs:label "Charge"@en ; rdfs:comment "A disputed charge on a customer's account — the object Dana wants refunded."@en ; rdfs:subClassOf schema:PriceSpecification ; rdfs:isDefinedBy :comparisonOntology . gld:Outage a rdfs:Class ; rdfs:label "Outage"@en ; rdfs:comment "A network outage event — a look-up fact at rung one, a live crossable graph at rung three."@en ; rdfs:subClassOf schema:Event ; rdfs:isDefinedBy :comparisonOntology . gld:SystemOfRecord a rdfs:Class ; rdfs:label "System of record"@en ; rdfs:comment "A source system (network event log, billing system) whose records the agent reconciles — the two systems that disagreed about when the outage began."@en ; rdfs:subClassOf schema:SoftwareApplication ; rdfs:isDefinedBy :comparisonOntology . gld:Override a rdfs:Class ; rdfs:label "Override"@en ; rdfs:comment "A human decision that reverses an automated denial — the article's rung-two artifact, whose value is the finding it records, not the refund itself."@en ; rdfs:subClassOf schema:Action ; rdfs:isDefinedBy :comparisonOntology . gld:Finding a rdfs:Class ; rdfs:label "Finding"@en ; rdfs:comment "What a decision reconciles — the two systems that disagreed, the class of plan that carries a bad end-date, and the fact that this override was correct."@en ; rdfs:subClassOf schema:CreativeWork ; rdfs:isDefinedBy :comparisonOntology . gld:Skill a rdfs:Class ; rdfs:label "Skill"@en ; rdfs:comment "A reusable procedure distilled from decision traces — the context platform's answer to 'why did we approve a refund like Dana's last quarter?'"@en ; rdfs:subClassOf schema:HowTo ; rdfs:isDefinedBy :comparisonOntology . gld:DecisionTrace a rdfs:Class ; rdfs:label "Decision trace"@en ; rdfs:comment "The record of the path an agent walked to make a decision — the raw material the context platform distills into skills."@en ; rdfs:subClassOf schema:CreativeWork ; rdfs:isDefinedBy :comparisonOntology . gld:Tower a rdfs:Class ; rdfs:label "Tower"@en ; rdfs:comment "A network tower — a node in the rung-three topology the agent must cross outward from a break."@en ; rdfs:subClassOf schema:Place ; rdfs:isDefinedBy :comparisonOntology . gld:SlaContract a rdfs:Class ; rdfs:label "SLA contract"@en ; rdfs:comment "A business contract that starts owing a customer money the moment service drops — the rung-three exposure the traversal has to surface while phones ring."@en ; rdfs:subClassOf schema:CreativeWork ; rdfs:isDefinedBy :comparisonOntology . gld:holdsPlan a owl:ObjectProperty ; rdfs:label "holds plan"@en ; rdfs:comment "Links a customer to the service plan they hold."@en ; rdfs:domain schema:Person ; rdfs:range gld:Plan ; rdfs:isDefinedBy :comparisonOntology . gld:charges a owl:ObjectProperty ; rdfs:label "charges"@en ; rdfs:comment "Links a charge to the customer it was charged to."@en ; rdfs:domain gld:Charge ; rdfs:range schema:Person ; rdfs:isDefinedBy :comparisonOntology . gld:appliesTo a owl:ObjectProperty ; rdfs:label "applies to"@en ; rdfs:comment "Links a policy to the plan it governs."@en ; rdfs:domain gld:Policy ; rdfs:range gld:Plan ; rdfs:isDefinedBy :comparisonOntology . gld:deniedBy a owl:ObjectProperty ; rdfs:label "denied by"@en ; rdfs:comment "Links an automated denial to the policy it invoked."@en ; rdfs:domain gld:Override ; rdfs:range gld:Policy ; rdfs:isDefinedBy :comparisonOntology . gld:overrides a owl:ObjectProperty ; rdfs:label "overrides"@en ; rdfs:comment "Links a human override to the automated denial it reverses."@en ; rdfs:domain gld:Override ; rdfs:range gld:Override ; rdfs:isDefinedBy :comparisonOntology . gld:reconciles a owl:ObjectProperty ; rdfs:label "reconciles"@en ; rdfs:comment "Links an override to the systems of record it reconciled."@en ; rdfs:domain gld:Override ; rdfs:range gld:SystemOfRecord ; rdfs:isDefinedBy :comparisonOntology . gld:records a owl:ObjectProperty ; rdfs:label "records"@en ; rdfs:comment "Links an override to the finding it records — the value that would otherwise die in a ticket comment."@en ; rdfs:domain gld:Override ; rdfs:range gld:Finding ; rdfs:isDefinedBy :comparisonOntology . gld:distilledInto a owl:ObjectProperty ; rdfs:label "distilled into"@en ; rdfs:comment "Links a decision trace to the skill it was distilled into — the context platform's closure of the loop."@en ; rdfs:domain gld:DecisionTrace ; rdfs:range gld:Skill ; rdfs:isDefinedBy :comparisonOntology . gld:affectedBy a owl:ObjectProperty ; rdfs:label "affected by"@en ; rdfs:comment "Links an entity to the outage that affected it."@en ; rdfs:domain schema:Thing ; rdfs:range gld:Outage ; rdfs:isDefinedBy :comparisonOntology . gld:serves a owl:ObjectProperty ; rdfs:label "serves"@en ; rdfs:comment "Links a tower to the customer it serves."@en ; rdfs:domain gld:Tower ; rdfs:range schema:Thing ; rdfs:isDefinedBy :comparisonOntology . gld:covers a owl:ObjectProperty ; rdfs:label "covers"@en ; rdfs:comment "Links an SLA contract to the customer it covers."@en ; rdfs:domain gld:SlaContract ; rdfs:range schema:Thing ; rdfs:isDefinedBy :comparisonOntology . gld:amount a owl:DatatypeProperty ; rdfs:label "amount"@en ; rdfs:comment "The monetary amount of a charge."@en ; rdfs:domain gld:Charge ; rdfs:range xsd:decimal ; rdfs:isDefinedBy :comparisonOntology . gld:currency a owl:DatatypeProperty ; rdfs:label "currency"@en ; rdfs:comment "The ISO currency code of a charge amount."@en ; rdfs:domain gld:Charge ; rdfs:range xsd:string ; rdfs:isDefinedBy :comparisonOntology . gld:recordsOutageStart a owl:DatatypeProperty ; rdfs:label "records outage start"@en ; rdfs:range xsd:date ; rdfs:comment "The outage start-date a system of record asserts — the field on which the network event log and the billing system disagreed."@en ; rdfs:domain gld:SystemOfRecord ; rdfs:isDefinedBy :comparisonOntology . gld:endedOn a owl:DatatypeProperty ; rdfs:label "ended on"@en ; rdfs:comment "The date a plan's coverage ended."@en ; rdfs:domain gld:Plan ; rdfs:range xsd:date ; rdfs:isDefinedBy :comparisonOntology . # ── Comparison dimensions (12) ──────────────────────────────────────────────── post:dimCoreQuestion a cdx:ComparisonDimension ; schema:name "The core question"@en ; schema:description "What the article actually asks: given that your business is a graph, where should that graph physically live — and is the answer one store or one store per workload?"@en ; post:classifies post:dimConvergent ; :hasArticleApproach post:dimCoreQuestionArticle ; :hasArmApproach post:dimCoreQuestionArm . post:dimCoreQuestionArticle a schema:Text ; schema:text "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."@en . post:dimCoreQuestionArm a schema:Text ; schema:text "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."@en . post:dimModelVsStore a cdx:ComparisonDimension ; schema:name "Model vs store separation"@en ; schema:description "The article's load-bearing distinction: the drawing (the business model) is one thing; the physical store is another."@en ; post:classifies post:dimConvergent ; :hasArticleApproach post:dimModelVsStoreArticle ; :hasArmApproach post:dimModelVsStoreArm . post:dimModelVsStoreArticle a schema:Text ; schema:text "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."@en . post:dimModelVsStoreArm a schema:Text ; schema:text "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."@en . post:dimFourHomes a cdx:ComparisonDimension ; schema:name "The four homes"@en ; schema:description "The article names four physical homes for a graph and asks which one your workload earns."@en ; post:classifies post:dimDivergent ; :hasArticleApproach post:dimFourHomesArticle ; :hasArmApproach post:dimFourHomesArm . post:dimFourHomesArticle a schema:Text ; schema:text "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."@en . post:dimFourHomesArm a schema:Text ; schema:text "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."@en . post:dimRungOne a cdx:ComparisonDimension ; schema:name "Rung one — known lookups"@en ; schema:description "The standard support picture: consistent, known queries, the same four or five joins against a schema that is not moving."@en ; post:classifies post:dimConvergent ; :hasArticleApproach post:dimRungOneArticle ; :hasArmApproach post:dimRungOneArm . post:dimRungOneArticle a schema:Text ; schema:text "Source: a relational database is probably fine — this rung likely does not need a graph database."@en . post:dimRungOneArm a schema:Text ; schema:text "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."@en . post:dimRungTwo a cdx:ComparisonDimension ; schema:name "Rung two — decisions & provenance"@en ; schema:description "The question shifts from 'what is true' to 'what did we decide, why, and what does that change' — relationships worth more than the objects."@en ; post:classifies post:dimDivergent ; :hasArticleApproach post:dimRungTwoArticle ; :hasArmApproach post:dimRungTwoArm . post:dimRungTwoArticle a schema:Text ; schema:text "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."@en . post:dimRungTwoArm a schema:Text ; schema:text "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."@en . post:dimRungThree a cdx:ComparisonDimension ; schema:name "Rung three — live traversal"@en ; schema:description "The break shapes the question, not you: crossing a live network under load while phones ring, with no fixed query to write in advance."@en ; post:classifies post:dimDivergent ; :hasArticleApproach post:dimRungThreeArticle ; :hasArmApproach post:dimRungThreeArm . post:dimRungThreeArticle a schema:Text ; schema:text "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."@en . post:dimRungThreeArm a schema:Text ; schema:text "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."@en . post:dimAgentMemory a cdx:ComparisonDimension ; schema:name "The agent-memory job"@en ; schema:description "One of the article's three non-optional jobs: what the agent has learned and can reuse — semantic, procedural, and long-term memory."@en ; post:classifies post:dimDivergent ; :hasArticleApproach post:dimAgentMemoryArticle ; :hasArmApproach post:dimAgentMemoryArm . post:dimAgentMemoryArticle a schema:Text ; schema:text "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."@en . post:dimAgentMemoryArm a schema:Text ; schema:text "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."@en . post:dimContextPlatform a cdx:ComparisonDimension ; schema:name "The context-platform job"@en ; schema:description "The newest job: the 'context graph' Emil renames a decision-trace graph — traces distilled into skills, with provenance that forces supersede/retire/write-new decisions."@en ; post:classifies post:dimDivergent ; :hasArticleApproach post:dimContextPlatformArticle ; :hasArmApproach post:dimContextPlatformArm . post:dimContextPlatformArticle a schema:Text ; schema:text "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."@en . post:dimContextPlatformArm a schema:Text ; schema:text "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."@en . post:dimRetrieval a cdx:ComparisonDimension ; schema:name "Retrieval"@en ; schema:description "How the right few memories (or facts) are chosen at decision time — the article's 'skills retrieval is an open problem.'"@en ; post:classifies post:dimDivergent ; :hasArticleApproach post:dimRetrievalArticle ; :hasArmApproach post:dimRetrievalArm . post:dimRetrievalArticle a schema:Text ; schema:text "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."@en . post:dimRetrievalArm a schema:Text ; schema:text "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."@en . post:dimModelingCost a cdx:ComparisonDimension ; schema:name "Modeling cost"@en ; schema:description "The cost that kept graphs and ontologies niche for decades — and what collapsed it."@en ; post:classifies post:dimConvergent ; :hasArticleApproach post:dimModelingCostArticle ; :hasArmApproach post:dimModelingCostArm . post:dimModelingCostArticle a schema:Text ; schema:text "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."@en . post:dimModelingCostArm a schema:Text ; schema:text "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."@en . post:dimQueryCost a cdx:ComparisonDimension ; schema:name "Query cost"@en ; schema:description "The article says the query cost is 'largely gone' — you just speak in natural language, while Cypher and GQL still exist underneath."@en ; post:classifies post:dimDivergent ; :hasArticleApproach post:dimQueryCostArticle ; :hasArmApproach post:dimQueryCostArm . post:dimQueryCostArticle a schema:Text ; schema:text "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."@en . post:dimQueryCostArm a schema:Text ; schema:text "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."@en . post:dimVolatility a cdx:ComparisonDimension ; schema:name "Volatility & maintainability"@en ; schema:description "The article's empirical test: maintainability by hop count, and how much of the model can go stale without anyone noticing."@en ; post:classifies post:dimDivergent ; :hasArticleApproach post:dimVolatilityArticle ; :hasArmApproach post:dimVolatilityArm . post:dimVolatilityArticle a schema:Text ; schema:text "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."@en . post:dimVolatilityArm a schema:Text ; schema:text "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."@en . # ── Document and article ────────────────────────────────────────────────────── post: a schema:CreativeWork ; schema:name "Where Should the Graph Live? — Four Homes vs agent-rdf-memory (meshup document)"@en ; schema:about post:article ; schema:accountablePerson ; schema:author , ; schema:hasPart post:comparisonSection ; prov:wasGeneratedBy , . post:article a schema:NewsArticle ; schema:name "Where Should the Graph Live?"@en ; schema:abstract "Every serious AI system needs relationships. Whether it needs a graph database is a different question — and it has a different answer for every workload. Austin Kronz's Context & Chaos piece separates the drawing (the business model) from the store (where it physically lives), walks a three-rung customer scenario to show that 'having a graph and running a graph database are not the same commitment,' and names three non-optional jobs — operational store, agent memory, and the decision-trace context platform. This meshup adds the agent-rdf-memory answer: the article's three jobs as portable RDF on a Semantic Web that lives in any of the four homes, with the Dana roaming-charge scenario modeled as synthetic RDF and queried live in SPARQL."@en ; schema:description "Notes and commentary on Austin Kronz's Atlan Context & Chaos article (2026-09-17), extended into a two-way meshup: the source's 'where does the graph live' routing framework (four homes, answered per workload rung) versus agent-rdf-memory (a Semantic Web RDF harness whose portable model lives in any home and hosts all three jobs). The demo models the article's Dana roaming-charge example as RDF and answers the three rungs as live SPARQL."@en ; schema:author ; schema:datePublished "2026-09-17"^^xsd:date ; schema:dateModified "2026-09-17"^^xsd:date ; schema:publisher ; schema:url ; schema:about , , , , , , , , , post:agentMemory ; schema:hasPart :comparisonOntology, post:sectionThesis, post:sectionModelVsStore, post:sectionThreeRungs, post:sectionRungOne, post:sectionRungTwo, post:sectionRungThree, post:sectionWhyNow, post:sectionThreeJobs, post:sectionWhiteboard, post:armNarrative, post:armSection, post:demoSection, post:faqSection, post:glossarySection, post:howToSection, post:comparisonSection ; prov:wasGeneratedBy . # ── Source article sections ─────────────────────────────────────────────────── post:sectionThesis a schema:CreativeWork ; schema:name "Everyone draws the same graph"@en ; schema:abstract "Put the people who know the business in a room with a marker and they never draw tables — they draw circles joined by lines. A customer joined to an account, joined to a plan, joined to the policy that defines what a refund even is. Emil Eifrem calls the gap between that drawing and the relational schema an impedance mismatch, and it is the same gap now sitting under enterprise AI."@en ; schema:isPartOf post:article . post:sectionModelVsStore a schema:CreativeWork ; schema:name "The drawing and the place you keep it are two different decisions"@en ; schema:abstract "A model of your business 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 — same drawing, four different homes, and the drawing does not care which you pick. The words (ontology, knowledge graph, context graph) are their own small war; Emil calls it ontology-washing, after cloud-washing."@en ; schema:isPartOf post:article . post:sectionThreeRungs a schema:CreativeWork ; schema:name "Three rungs, one customer"@en ; schema:abstract "To find your per-workload answer, take one decision and keep raising the stakes until the architecture underneath has to change. The article keeps the same Dana roaming-charge example all the way up: rung one is a look-up, rung two is a decision with a finding, rung three is a live graph being crossed under load."@en ; schema:isPartOf post:article . post:sectionRungOne a schema:CreativeWork ; schema:name "Rung one — look it up"@en ; schema:abstract "Dana calls about a forty-dollar roaming charge. An agent needs the standard support picture: who Dana is, what her plan covers, the refund policy, and known outages on her line. These are consistent, known queries — the same four or five joins over and over against a schema that is not moving. A relational database is probably fine; this rung likely does not need a graph database."@en ; schema:isPartOf post:article . post:sectionRungTwo a schema:CreativeWork ; schema:name "Rung two — decide, and record why"@en ; schema:abstract "Dana was denied, and the denial was wrong: her plan ended on the 14th, the outage is logged on the 15th, but the outage actually started on the 13th because the network event log and the billing system disagree, and her plan end-date was migrated incorrectly eighteen months ago. A human overrides it. The valuable thing is the finding — that these two systems disagree, that this class of plan carries a bad end-date, and that this override was correct — which must work its way back into context, not die in a ticket comment."@en ; schema:isPartOf post:article . post:sectionRungThree a schema:CreativeWork ; schema:name "Rung three — cross the live network"@en ; schema:abstract "Something breaks and the outage is happening again right now. Knowing what broke is easy; the hard question is who is affected — which towers went quiet, which customers are on them, which have contracts that start owing money the moment service drops. Answering means following the network outward from the break, with no fixed query to write in advance, while the phones ring."@en ; schema:isPartOf post:article . post:sectionWhyNow a schema:CreativeWork ; schema:name "Why this is a live decision only now"@en ; schema:abstract "Graph databases and ontologies both stayed niche for decades because of cost, not capability. The query cost is largely gone — you speak natural language. The modeling cost moved further: an ontology can be bootstrapped bottom-up from the systems you already run. Emil's name for the pattern is 'bottom-up produced by AI meets top-down'; Prukalpa's warning is that a GPT-authored ontology is 'beautiful but not accurate,' and getting from beautiful to accurate is the work."@en ; schema:isPartOf post:article . post:sectionThreeJobs a schema:CreativeWork ; schema:name "Graph in the enterprise AI architecture — three jobs"@en ; schema:abstract "Three jobs the graph does, each settled to a different degree: (1) the operational store — the system of record for an entity and its connections, the article's rung three, settled since long before anyone said 'agent'; (2) agent memory — what the agent has learned, an intrinsically graph-centric workload that the MCP spec's 500-line toy and a wave of startups all reached independently; (3) the context platform — the newest job, where traces are distilled into skills with provenance that forces a supersede/retire/write-new decision. All three jobs are not optional; storage and retrieval are choices made per workload."@en ; schema:isPartOf post:article . post:sectionWhiteboard a schema:CreativeWork ; schema:name "Start at the whiteboard, run the ladder twice"@en ; schema:abstract "Draw the hardest decision one of your agents has to make, mark it against four questions (how far must it travel, what must be explainable afterward, what are the real latency and scale limits, what will go stale underneath it), then run the ladder twice: once for the business decision the agent supports, and once for the agent's own memory. Most teams run the first ladder and never the second."@en ; schema:isPartOf post:article . # ── agent-rdf-memory narrative and showcase ───────────────────────────────── post:armNarrative a schema:CreativeWork ; schema:name "agent-rdf-memory: portable RDF on a Semantic Web — all four homes, all three jobs"@en ; schema:abstract "OpenLink's narrative positions agent-rdf-memory as the concrete answer to the article's question: instead of choosing among four homes per workload, a portable RDF model — a Semantic Web of triples — lives in any home and moves between them without re-modeling. The harness is the article's three jobs (operational state, agent memory, decision-trace context) as queryable RDF, and the demo below proves the three rungs are SPARQL queries, run here on a Virtuoso quad store."@en ; schema:author ; schema:hasPart post:armSection, post:demoSection ; schema:isPartOf post:article . post:agentMemory a schema:CreativeWork ; schema:name "agent-rdf-memory: the RDF-based AI agent memory system"@en ; schema:abstract "agent-rdf-memory is the reference showcase of an RDF-based AI-agent memory harness: core.ttl for identity, preferences.ttl for the behavioral contract (200+ HowToSteps), sessions/ for episodic memory, entities/ for semantic memory, howto/ for procedural memory — deployed on a Virtuoso instance and queried via SPARQL with file-read fallback. It is a production instance of the article's jobs two and three."@en ; schema:isBasedOn ; schema:url . # ── agent-rdf-memory mapping (point-for-point onto the article's three jobs) ─── post:armSection a schema:CreativeWork ; schema:name "agent-rdf-memory mapped onto the article's three jobs"@en ; schema:abstract "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."@en ; schema:hasPart post:armOperationalStore, post:armAgentMemory, post:armContextPlatform, post:armRetrieval, post:armProvenance ; schema:isPartOf post:article, post:armNarrative . post:armOperationalStore a schema:CreativeWork ; schema:name "Operational store ↔ RDF Views over the warehouse"@en ; schema:description "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."@en . post:armAgentMemory a schema:CreativeWork ; schema:name "Agent memory ↔ named-graph memory store"@en ; schema:description "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."@en . post:armContextPlatform a schema:CreativeWork ; schema:name "Context platform ↔ decision-trace provenance"@en ; schema:description "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."@en . post:armRetrieval a schema:CreativeWork ; schema:name "Skills retrieval ↔ ontology-routed SPARQL"@en ; schema:description "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."@en . post:armProvenance a schema:CreativeWork ; schema:name "Provenance ↔ PROV-O dates on every write"@en ; schema:description "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."@en . # ── The demo: sample Turtle + live SPARQL ───────────────────────────────────── post:demoSection a schema:CreativeWork ; schema:name "Live demo: the three rungs as SPARQL over synthetic RDF"@en ; schema:abstract "The agent-rdf-memory solution demonstrated concretely: a synthetic RDF graph modeling the article's Dana roaming-charge example (plan, policy, charge, the two disagreeing systems, the human override, the distilled skill, and the rung-three network topology), then the three rungs plus the model/store, three-jobs and decision-to-skill questions answered live in SPARQL over the named graph."@en ; schema:hasPart gld:demoGraph, post:queryRungOneLookup, post:queryRungTwoOverride, post:queryRungThreeTraversal, post:queryModelVsStore, post:queryThreeJobs, post:queryDecisionToSkill ; schema:isPartOf post:article, post:armNarrative . # ── Synthetic demo graph (Dana roaming charge) ──────────────────────────────── gld:demoGraph a schema:CreativeWork ; schema:name "Synthetic RDF — Dana's roaming-charge scenario as a graph"@en ; schema:description "Synthetic Turtle modeling the article's running example as an RDF graph: Dana, her Gold Roaming Plan (end-date migrated incorrectly), the refund policy, the forty-dollar charge, the network event log and billing system that disagree about the outage start, the human override, the distilled skill, and the rung-three towers/customers/contracts — all queryable live with SPARQL."@en ; schema:isPartOf post:demoSection . 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 . gld:outage1 a gld:Outage ; schema:name "Network outage (billing-logged 08-15)"@en ; gld:recordsOutageStart "2026-08-15"^^xsd:date . 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:denial a gld:Override ; schema:name "Refund denied (automated)"@en ; gld:deniedBy gld:refundPolicy . gld:override a gld:Override ; schema:name "Refund approved (human override)"@en ; gld:overrides gld:denial ; gld:reconciles gld:networkEventLog, gld:billingSystem ; gld:records gld:finding ; prov:wasGeneratedBy gld:supervisor ; schema:dateCreated "2026-09-17"^^xsd:date . gld:supervisor a schema:Person ; schema:name "Support lead"@en . gld:finding a gld:Finding ; schema:name "Migrated plan end-date + outage-window disagreement"@en ; schema:description "The network event log and the billing system disagree about when the outage began, this class of plan carries a bad end-date, and in this situation the override is correct."@en . gld:trace a gld:DecisionTrace ; schema:name "Decision trace: roaming-refund override"@en ; schema:description "I walked this path to make a decision — the reconciled systems, the bent policy, the person who stood behind it — then distilled it into a skill."@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 ; schema:description "A reusable skill distilled from Dana's override: check the network event log against the billing system before denying a refund outside an active plan."@en ; schema:dateCreated "2026-09-17"^^xsd:date . # rung three — the live network under a break gld:break1 a gld:Outage ; schema:name "Fiber cut — tower sector down"@en . gld:towerA a gld:Tower ; schema:name "Tower A"@en ; gld:serves gld:dana ; gld:affectedBy gld:break1 . 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:affectedBy gld:break1 . gld:contractAcme a gld:SlaContract ; schema:name "Business SLA — credit accrues on drop"@en ; gld:covers gld:acme . # ── SPARQL recipes (SoftwareSourceCode) — demo queries ──────────────────────── post:queryRungOneLookup a schema:SoftwareSourceCode ; schema:name "Rung one — the standard support picture (a look-up)"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: PREFIX gld: SELECT ?customerIri ?customer ?planIri ?plan ?policyIri ?policy ?chargeIri ?charge ?amount WHERE { GRAPH { ?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""" . post:queryRungTwoOverride a schema:SoftwareSourceCode ; schema:name "Rung two — what was decided, why, and what changed"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: PREFIX prov: PREFIX gld: SELECT ?overrideIri ?override ?systemIri ?system ?outageStart ?findingIri ?finding WHERE { GRAPH { ?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""" . post:queryRungThreeTraversal a schema:SoftwareSourceCode ; schema:name "Rung three — who is affected right now (traversal)"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: PREFIX gld: SELECT ?towerIri ?tower ?customerIri ?customer ?contractIri ?contract WHERE { GRAPH { ?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""" . post:queryModelVsStore a schema:SoftwareSourceCode ; schema:name "The drawing vs the store — the model is independent of its home"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: PREFIX rdf: PREFIX : SELECT ?homeIri ?home ?decision WHERE { GRAPH { ?homeIri a :GraphHome ; schema:name ?home ; schema:description ?decision . } } ORDER BY ?home""" . post:queryThreeJobs a schema:SoftwareSourceCode ; schema:name "The three non-optional jobs the graph does"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: PREFIX : SELECT ?jobIri ?job ?settledness WHERE { GRAPH { ?jobIri a :GraphJob ; schema:name ?job ; schema:description ?settledness . } } ORDER BY ?job""" . post:queryDecisionToSkill a schema:SoftwareSourceCode ; schema:name "From decision trace to skill — the context-platform loop"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: PREFIX prov: PREFIX gld: SELECT ?traceIri ?trace ?skillIri ?skill ?skillDate WHERE { GRAPH { ?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""" . # ── SPARQL recipes — meshup queries ─────────────────────────────────────────── post:queryDimensions a schema:SoftwareSourceCode ; schema:name "Comparison dimensions and both approaches"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX cdx: PREFIX schema: PREFIX : SELECT ?dimIri ?dim ?article ?virtuoso WHERE { GRAPH { ?dimIri a cdx:ComparisonDimension ; schema:name ?dim ; :hasArticleApproach/schema:text ?article ; :hasArmApproach/schema:text ?virtuoso . } } ORDER BY ?dim""" . post:queryArmMapping a schema:SoftwareSourceCode ; schema:name "agent-rdf-memory → the three jobs mapping"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: PREFIX : SELECT ?mappingIri ?name ?description WHERE { GRAPH { :armSection schema:hasPart ?mappingIri . ?mappingIri schema:name ?name ; schema:description ?description . } } ORDER BY ?name""" . post:queryFaq a schema:SoftwareSourceCode ; schema:name "FAQ questions and answers"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: SELECT ?questionIri ?question ?answer WHERE { GRAPH { ?questionIri a schema:Question ; schema:name ?question ; schema:acceptedAnswer/schema:text ?answer . } } ORDER BY ?question""" . post:queryGlossary a schema:SoftwareSourceCode ; schema:name "Glossary terms and definitions"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: SELECT ?termIri ?name ?definition WHERE { GRAPH { ?termIri a schema:DefinedTerm ; schema:name ?name ; schema:description ?definition . } } ORDER BY ?name""" . post:queryHowTo a schema:SoftwareSourceCode ; schema:name "HowTo steps in order"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: SELECT ?stepIri ?position ?title WHERE { GRAPH { ?howto a schema:HowTo ; schema:step ?stepIri . ?stepIri schema:position ?position ; schema:name ?title . } } ORDER BY ?position""" . post:queryThesis a schema:SoftwareSourceCode ; schema:name "Thesis bullets (load-bearing claims)"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX schema: PREFIX : SELECT ?claimIri ?claim ?description WHERE { GRAPH { ?claimIri a schema:Claim ; schema:name ?claim ; schema:description ?description . } } ORDER BY ?claim""" . post:querySummary a schema:SoftwareSourceCode ; schema:name "Entity-type summary of the knowledge graph"@en ; schema:codeSampleType "full"@en ; schema:programmingLanguage "SPARQL"@en ; schema:target ; schema:text """PREFIX rdf: PREFIX rdfs: SELECT ?type (SAMPLE(?s) AS ?sampleEntity) (SAMPLE(?label) AS ?sampleLabel) (COUNT(?s) AS ?entityCount) WHERE { GRAPH { ?s rdf:type ?type . OPTIONAL { ?s rdfs:label ?label } } } GROUP BY ?type ORDER BY DESC(?entityCount)""" . # ── The four homes and three jobs (article concepts) ────────────────────────── :GraphHome a rdfs:Class ; rdfs:label "Graph home"@en ; rdfs:comment "One of the four physical places a business model can live — the article's 'same drawing, four different homes.'"@en ; rdfs:subClassOf schema:Intangible ; rdfs:isDefinedBy :comparisonOntology . :GraphJob a rdfs:Class ; rdfs:label "Graph job"@en ; rdfs:comment "One of the three non-optional jobs a graph does in enterprise AI — operational store, agent memory, context platform."@en ; rdfs:subClassOf schema:Intangible ; rdfs:isDefinedBy :comparisonOntology . post:homeMemory a :GraphHome ; schema:name "In memory"@en ; schema:description "The drawing kept in RAM for the lifetime of a process — fast, and gone when the process ends."@en . post:homeFiles a :GraphHome ; schema:name "Files in cloud storage"@en ; schema:description "The drawing serialized to object storage — durable and cheap, but not traversable under query."@en . post:homeWarehouse a :GraphHome ; schema:name "Warehouse tables"@en ; schema:description "The drawing as rows in the warehouse you already run — no new store, but joins are the only traversal."@en . post:homeGraphDb a :GraphHome ; schema:name "A graph database"@en ; schema:description "The drawing in a store built for connected data — traversal is native, at the cost of a second store."@en . post:jobOperationalStore a :GraphJob ; schema:name "Operational store"@en ; schema:description "The system of record for an entity and its connections — the oldest job, settled long before anyone said 'agent' (the article's rung three)."@en . post:jobAgentMemory a :GraphJob ; schema:name "Agent memory"@en ; schema:description "What the agent has learned and can reuse — semantic, procedural and long-term memory, reached by convergence, not design."@en . post:jobContextPlatform a :GraphJob ; schema:name "Context platform"@en ; schema:description "The newest job: decision traces distilled into skills, with provenance that forces a supersede/retire/write-new decision."@en . # ── Thesis bullets (load-bearing claims) ────────────────────────────────────── post:thesisModelVsStore a schema:Claim ; schema:name "Having a graph and running a graph database are not the same commitment"@en ; schema:description "The drawing is one thing, the store another — and someone who built a graph database will tell you plainly that you can have the graph without buying the database."@en . post:thesisPerWorkload a schema:Claim ; schema:name "There is an answer per workload, not one answer"@en ; schema:description "There is no single answer; the answer changes per workload rung, and it is less satisfying than the diagram anyone will sell you."@en . post:thesisRelationshipsCarryAnswer a schema:Claim ; schema:name "When relationships carry the answer, you need the graph database"@en ; schema:description "When the relationships between things become more valuable than the objects themselves, you need the graph; when they must be traversed many hops, fast, under load, that is when you need the graph database."@en . post:thesisThreeJobsNotOptional a schema:Claim ; schema:name "The three jobs are not optional; storage and retrieval are choices"@en ; schema:description "An AI context platform needs the operational state, the agent's memory, and the record of what got decided and why — regardless of which store keeps each and how the agent retrieves it."@en . post:thesisConvergedQuadStore a schema:Claim ; schema:name "Portable RDF hosts the model in any of the four homes"@en ; schema:description "Because RDF is a home-agnostic W3C model, the same graph serves rung one (RDF Views over tables), rung two (decision triples) and rung three (SPARQL traversal) — with agent-rdf-memory as the live instance of jobs two and three."@en . post:thesisHyperlinks a schema:Claim ; schema:name "Hyperlinks as identifiers make the model portable across homes"@en ; schema:description "RDF IRIs (not internal node IDs) let the same entity be 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."@en . # ── FAQ ─────────────────────────────────────────────────────────────────────── post:faqSection a schema:FAQPage ; schema:name "FAQ — Where Should the Graph Live? (agent-rdf-memory meshup)"@en ; schema:about post:article ; schema:isPartOf post:article ; schema:mainEntity post:faq1, post:faq10, post:faq11, post:faq12, post:faq2, post:faq3, post:faq4, post:faq5, post:faq6, post:faq7, post:faq8, post:faq9 . post:faq1 a schema:Question ; schema:name "What is the article's central distinction?"@en ; schema:acceptedAnswer post:faq1Answer . post:faq1Answer a schema:Answer ; schema:parentItem post:faq1 ; schema:text "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."@en . post:faq2 a schema:Question ; schema:name "What are the three rungs in the Dana example?"@en ; schema:acceptedAnswer post:faq2Answer . post:faq2Answer a schema:Answer ; schema:parentItem post:faq2 ; schema:text "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."@en . post:faq3 a schema:Question ; schema:name "When does the article say you need a graph database?"@en ; schema:acceptedAnswer post:faq3Answer . post:faq3Answer a schema:Answer ; schema:parentItem post:faq3 ; schema:text "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."@en . post:faq4 a schema:Question ; schema:name "Why is this a live decision only now?"@en ; schema:acceptedAnswer post:faq4Answer . post:faq4Answer a schema:Answer ; schema:parentItem post:faq4 ; schema:text "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.'"@en . post:faq5 a schema:Question ; schema:name "What are the three jobs a graph does in enterprise AI?"@en ; schema:acceptedAnswer post:faq5Answer . post:faq5Answer a schema:Answer ; schema:parentItem post:faq5 ; schema:text "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."@en . post:faq6 a schema:Question ; schema:name "Where does agent-rdf-memory fit?"@en ; schema:acceptedAnswer post:faq6Answer . post:faq6Answer a schema:Answer ; schema:parentItem post:faq6 ; schema:text "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."@en . post:faq7 a schema:Question ; schema:name "How does agent-rdf-memory map onto the article's three jobs?"@en ; schema:acceptedAnswer post:faq7Answer . post:faq7Answer a schema:Answer ; schema:parentItem post:faq7 ; schema:text "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."@en . post:faq8 a schema:Question ; schema:name "Can I reproduce the article's three rungs in SPARQL?"@en ; schema:acceptedAnswer post:faq8Answer . post:faq8Answer a schema:Answer ; schema:parentItem post:faq8 ; schema:text "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."@en . post:faq9 a schema:Question ; schema:name "What are the trade-offs?"@en ; schema:acceptedAnswer post:faq9Answer . post:faq9Answer a schema:Answer ; schema:parentItem post:faq9 ; schema:text "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."@en . post:faq10 a schema:Question ; schema:name "Does the model survive a move between homes?"@en ; schema:acceptedAnswer post:faq10Answer . post:faq10Answer a schema:Answer ; schema:parentItem post:faq10 ; schema:text "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."@en . post:faq11 a schema:Question ; schema:name "How does agent-rdf-memory stay fail-safe?"@en ; schema:acceptedAnswer post:faq11Answer . post:faq11Answer a schema:Answer ; schema:parentItem post:faq11 ; schema:text "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."@en . post:faq12 a schema:Question ; schema:name "Is one approach clearly better?"@en ; schema:acceptedAnswer post:faq12Answer . post:faq12Answer a schema:Answer ; schema:parentItem post:faq12 ; schema:text "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."@en . # ── Glossary ────────────────────────────────────────────────────────────────── post:glossarySection a schema:DefinedTermSet ; schema:name "Glossary — graphs, context and RDF terms"@en ; schema:isPartOf post:article ; schema:hasDefinedTerm , , , , , , , , , post:agentMemoryTerm, post:impedanceMismatch, post:ontologyWashing, post:contextGraph, post:decisionTraceGraph, post:graphRag, post:contextRepos, post:quadStore, post:rdfViews, post:bottomUpBootstrap . a schema:DefinedTerm ; schema:name "Knowledge Graph"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . a schema:DefinedTerm ; schema:name "Graph Database"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . a schema:DefinedTerm ; schema:name "RDF"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . a schema:DefinedTerm ; schema:name "SPARQL"@en ; schema:description "The W3C query language for RDF graphs — the language of a Semantic Web, and of the live demo queries in this collection."@en ; schema:inDefinedTermSet post:glossarySection . a schema:DefinedTerm ; schema:name "Linked Data"@en ; schema:description "Best practices for publishing structured data on the web using HTTP URIs as identifiers and hyperlinks to connect entities."@en ; schema:inDefinedTermSet post:glossarySection . a schema:DefinedTerm ; schema:name "Named Graph"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . a schema:DefinedTerm ; schema:name "Provenance"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . a schema:DefinedTerm ; schema:name "Ontology"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . post:agentMemoryTerm a schema:DefinedTerm ; schema:name "Agent Memory"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . post:impedanceMismatch a schema:DefinedTerm ; schema:name "Impedance Mismatch"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . post:ontologyWashing a schema:DefinedTerm ; schema:name "Ontology-washing"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . post:contextGraph a schema:DefinedTerm ; schema:name "Context Graph"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . post:decisionTraceGraph a schema:DefinedTerm ; schema:name "Decision-Trace Graph"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . post:graphRag a schema:DefinedTerm ; schema:name "GraphRAG"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . post:contextRepos a schema:DefinedTerm ; schema:name "Context Repos"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . post:quadStore a schema:DefinedTerm ; schema:name "Quad Store"@en ; schema:description "A database that stores RDF triples plus a fourth element — the named graph IRI — enabling graph-level partitioning, provenance and access control."@en ; schema:inDefinedTermSet post:glossarySection . post:rdfViews a schema:DefinedTerm ; schema:name "RDF Views"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . post:bottomUpBootstrap a schema:DefinedTerm ; schema:name "Bottom-up Bootstrap"@en ; schema:description "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.'"@en ; schema:inDefinedTermSet post:glossarySection . a schema:DefinedTerm ; schema:name "Semantic Web"@en ; schema:description "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."@en ; schema:inDefinedTermSet post:glossarySection . # ── HowTo ───────────────────────────────────────────────────────────────────── post:howToSection a schema:HowTo ; schema:name "Decide where the graph lives — and keep the model portable"@en ; schema:description "A seven-step guide that separates the model from the store, walks the three-rung ladder, then deploys the answer as portable RDF with agent-rdf-memory."@en ; schema:isPartOf post:article ; schema:step post:step1, post:step2, post:step3, post:step4, post:step5, post:step6, post:step7 . post:step1 a schema:HowToStep ; schema:name "Separate the drawing from the store"@en ; schema:position 1 ; schema:text "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."@en ; schema:isPartOf post:howToSection . post:step2 a schema:HowToStep ; schema:name "Walk the three-rung ladder"@en ; schema:position 2 ; schema:text "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."@en ; schema:isPartOf post:howToSection . post:step3 a schema:HowToStep ; schema:name "Answer rung two empirically"@en ; schema:position 3 ; schema:text "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."@en ; schema:isPartOf post:howToSection . post:step4 a schema:HowToStep ; schema:name "Run the ladder twice"@en ; schema:position 4 ; schema:text "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."@en ; schema:isPartOf post:howToSection . post:step5 a schema:HowToStep ; schema:name "Keep the model portable across the four homes"@en ; schema:position 5 ; schema:text "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."@en ; schema:isPartOf post:howToSection . post:step6 a schema:HowToStep ; schema:name "Deploy agent-rdf-memory for jobs two and three"@en ; schema:position 6 ; schema:text "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."@en ; schema:isPartOf post:howToSection . post:step7 a schema:HowToStep ; schema:name "Query the decision live"@en ; schema:position 7 ; schema:text "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."@en ; schema:isPartOf post:howToSection . # ── Sources ─────────────────────────────────────────────────────────────────── post:sources a schema:ItemList ; schema:name "Sources cited"@en ; schema:itemListElement post:source1, post:source2, post:source3, post:source4, post:source5 . post:source1 a schema:CreativeWork ; schema:name "Where Should the Graph Live? (Atlan Context & Chaos)"@en ; schema:url . post:source2 a schema:CreativeWork ; schema:name "Where Should the Graph Live? (Prukalpa Sankar, LinkedIn Pulse)"@en ; schema:url . post:source3 a schema:CreativeWork ; schema:name "How do graph databases and the context layer fit together? (Context & Chaos recording)"@en ; schema:url . post:source4 a schema:CreativeWork ; schema:name "Virtuoso Universal Server (OpenLink)"@en ; schema:url . post:source5 a schema:CreativeWork ; schema:name "agent-rdf-memory (OpenLink ai-agent-skills)"@en ; schema:url . # ── LinkedIn Pulse republication (same work, second URL) ────────────────────── post:linkedinRepost a schema:NewsArticle ; schema:name "Where Should the Graph Live? (LinkedIn Pulse republication)"@en ; schema:description "Prukalpa Sankar's LinkedIn Pulse republication of the same Context & Chaos article — same headline and description, published 2026-09-17 under her 'Prukalpa ⚡' profile, where the author of record is the Context & Chaos chief editor rather than the byline author."@en ; schema:url ; schema:author ; schema:publisher ; schema:datePublished "2026-09-17"^^xsd:date ; schema:isBasedOn post:article ; owl:sameAs post:article . # ── Comparison section (document-level) ─────────────────────────────────────── post:comparisonSection a schema:CreativeWork ; schema:name "Head-to-Head: the four homes vs agent-rdf-memory"@en ; schema:abstract "Twelve comparison dimensions across two terms: the source article's 'where does the graph live' routing framework (four homes, answered per workload rung) and agent-rdf-memory (a Semantic Web RDF harness whose portable model lives in any home and hosts all three jobs). The source's load-bearing distinction — the model is not the store — holds throughout; agent-rdf-memory's contribution is expressing that model in W3C RDF/SPARQL standards, with the demo proving the article's three rungs are SPARQL queries."@en ; schema:about post:article, post:armNarrative, post:agentMemory ; schema:hasPart post:armSection, post:demoSection ; schema:isPartOf post: .