Context Is Infrastructure

A comparative thesis about Sierra's Context Engine: the advantage is not merely accumulated app memory, but the quality of pluggable context across identity-aware Linked Data spaces.

Source: Sierra blog RDF: Turtle companion Resolver: deck entity
01

Alternative thesis

Context Belongs To Infrastructure

If foundation-model intelligence is rentable, durable advantage comes from pluggable context infrastructure: named entities, linked relationships, identity-aware access, and reusable data spaces that remain independent of any one application.

  • Context is not an app feature
  • Context is a web of dereferenceable claims
  • Quality of pluggable context becomes the differentiator
02

Rent intelligence, own relationships

Sierra's Position

Sierra argues that enterprises can rent model intelligence, while the unique record of customer relationships, decisions, observations, and outcomes becomes the defensible moat.

  • Business systems and agent interactions create context
  • Outcome evidence compounds over time
  • Long-running agents act on the accumulated record
03

Where the thesis changes

The Loose-Coupling Gap

The strongest version of the context thesis separates context from the app. Identity, identification, authentication, authorization, and source data can be independently governed while still being joined by HTTP IRIs and RDF relationships.

  • Identity is not the same thing as a login
  • Authorization is not the same thing as application ownership
  • Data spaces can remain authoritative without being copied into a product silo
04

URIs, HTTP, RDF, links

Linked Data Turns Context Into Addressable Infrastructure

Linked Data principles make each entity and relationship addressable. A customer, policy, claim, file, table row, API operation, decision, and outcome can carry its own resolvable identity and provenance.

  • Use HTTP IRIs to name things
  • Return useful descriptions when names are looked up
  • Link to other named things so discovery compounds
05

Databases, knowledge bases, filesystems, APIs

Sources Of Truth Stay Pluggable

A Semantic Web context layer does not require one universal database. It lets multiple data spaces remain sources of truth while agents consume a linked, policy-aware view over them.

  • Relational systems expose entity IRIs and views
  • Knowledge bases publish reusable assertions
  • Filesystems and APIs participate through metadata, links, and access policies
06

Pluggability beats hoarding

The New Quality Frontier

The differentiator shifts from who owns the largest app-contained memory to who can deliver the best governed, interoperable, current, and explainable context to many agents and tools.

  • Freshness and provenance become product qualities
  • Policy-aware joins become operational leverage
  • Context can be improved without replacing applications
07

Deterministic inference layer

Ontologies Make Context Reasonable

Linked Data names and connects things; ontologies define what those things mean. Classes, properties, domains, ranges, constraints, and inference rules let agents derive repeatable conclusions from context instead of improvising every join in prompt space.

  • Ontology terms are themselves Linked Data resources
  • Reasoners infer class membership, relationships, and policy-relevant facts
  • Deterministic inference turns context into operational infrastructure
08

Reasoning in the query pipeline

SPARQL Surfaces Inferred Solutions

Reasoning and inference are exploitable inside SPARQL query solution production. A query can return solutions based on explicit triples plus ontology-driven entailments produced in the engine pipeline, so the answer reflects governed semantics rather than only stored assertions.

  • SPARQL queries can operate over asserted and inferred graph facts
  • Inference affects which bindings become valid query solutions
  • The query layer becomes a deterministic context interface for agents and applications
09

Prior work as evidence

agent-rdf-memory Is The Demonstration

The agent-rdf-memory system already demonstrates the alternative approach: operational context is encoded as RDF documents, indexed by session, routed through HowTo rules, and retrievable by SPARQL or direct RDF reads without depending on a single app memory silo.

  • core.ttl identifies the operator, agent, and output-routing contract
  • preferences.ttl links rules to dereferenceable HowTo documents
  • index.ttl and sessions/*.ttl make prior decisions queryable context, not hidden transcript state
10

Support cases as linked operations

Virtuoso Support Skill Shows Resolution Context

The Virtuoso Support Skill shows why support resolution needs pluggable context. Instance selection, tool namespaces, query templates, RDF Views generation, audits, SPARQL validation, SQL/SPASQL execution, and GQL-oriented mappings become reusable resolution state rather than a private exchange inside a chat UI.

  • A case starts by selecting Demo, URIBurner, or Localhost context
  • Resolution uses entity discovery, schema metadata, RDF operations, SQL/SPASQL, SPARQL, GraphQL, GQL-oriented graph access, and predefined query templates
  • RDF Views workflows require pre-audit, generated ontology/data rules, post-audit, and graph validation
11

Comparative frame

App Context vs Semantic Web Context

Sierra's Context Engine is an application-platform answer to compounding customer context. A Linked Data answer turns context into a cross-application infrastructure layer.

  • Platform loop: agent interactions improve platform decisions
  • Semantic Web loop: linked assertions improve every authorized consumer
  • The moat becomes graph quality, policy fidelity, and resolver reach
12

A decision architecture for agents

Context Is The Interface Contract

Agents should plug into context the way browsers plug into Web pages: through resolvable identifiers, typed relationships, content negotiation, and access controls. Applications can innovate above that layer without trapping the context beneath it.

  • Loose coupling protects optionality
  • Linked identity protects governance
  • Resolvable context protects reuse

Comparative Thesis

Linked Data context

Context is expressed as resolvable, typed relationships across independently governed data spaces.

Moat

The platform view emphasizes exclusive accumulated observations. The Linked Data view emphasizes reusable context quality, provenance, and policy-aware interoperability.

Agent access

Agents should retrieve relevant context through resolvable identifiers and authorization policies rather than through platform-specific memory alone.

Ontology proof

Ontologies make Linked Data context deterministic enough for inference, validation, and policy-sensitive support workflows.

Query proof

SPARQL query solutions can reflect reasoning and inference, while Virtuoso lets those graph solutions participate through SQL/SPASQL and GQL-oriented graph-query access.

Operational memory proof

agent-rdf-memory shows context as durable RDF and SPARQL-addressable memory rather than hidden transcript state.

Support resolution proof

The Virtuoso Support Skill shows a case-resolution workflow in which tools, queries, audits, graph validation, and chosen data spaces are explicit context.

Glossary

A Semantic Web

A deployment of Linked Data principles where entities and relationships are identified by resolvable IRIs and described using RDF.

Linked Data

A practice of publishing structured data with HTTP IRIs, useful descriptions, and links to other named things.

Context infrastructure

A shared semantic layer that presents identity-aware, policy-aware, provenance-bearing context independent of one application.

Data space

A source of truth such as a database, knowledge base, filesystem, or API that can expose or participate in linked descriptions.

WebID

An HTTP IRI that identifies an agent, person, or organization and can connect identity to authentication and authorization workflows.

Pluggable context

Context that can be joined, governed, and reused across agents because it is expressed through standards and resolvable identifiers.

Ontology

A Linked Data vocabulary of classes, properties, constraints, and relationships that defines the meaning of context entities.

Deterministic inference

Repeatable derivation of new facts from explicit RDF statements and ontology rules, rather than probabilistic reconstruction in a prompt.

SPARQL solution production

The pipeline that evaluates graph patterns and returns variable bindings, potentially over asserted and inferred RDF statements.

SPASQL

Use of SPARQL from SQL, allowing relational workflows to invoke graph queries and consume RDF-derived solutions.

GQL mapping

A graph-query access path in which Virtuoso can map Linked Data and RDF graph context into GQL-oriented graph-query usage.

agent-rdf-memory

A working RDF memory substrate that stores agent identity, preferences, HowTo rules, session logs, and provenance as queryable Linked Data.

Support resolution context

The evidence, tool choices, audits, queries, instance selection, and validation steps needed to resolve a technical support case.

FAQ

What is the core alternative thesis?

Context should be treated as infrastructure built from Linked Data and identity-aware access, not as a private memory feature of one application platform.

How does this differ from Sierra's Context Engine thesis?

Sierra emphasizes owned customer relationship context inside a long-running agent platform. The alternative emphasizes interoperable context that many authorized applications can discover and reuse.

Why does loose coupling matter?

Loose coupling lets identity, authentication, authorization, and data spaces evolve independently while still participating in one linked context fabric.

What becomes the competitive differentiator?

The quality of pluggable context: provenance, freshness, semantic precision, policy fidelity, and the reach of links across trustworthy sources.

What role do ontologies play?

Ontologies provide the shared vocabulary and formal relationship model that lets context be interpreted deterministically. They allow agents and reasoners to infer classes, relationships, constraints, and policy-relevant facts from Linked Data.

How does SPARQL exploit reasoning and inference?

SPARQL query solutions can be produced over explicit triples and inferred facts. Ontology-driven entailments can change which variable bindings satisfy a graph pattern, making reasoning part of the solution-production pipeline.

How do SQL/SPASQL and GQL fit the thesis?

When Virtuoso is the engine of choice, SPARQL is not isolated from other query surfaces. It can be used from SQL through SPASQL and mapped into GQL-oriented graph-query access, allowing the same context infrastructure to serve relational, RDF, and graph-query consumers.

How does agent-rdf-memory demonstrate the alternative thesis?

It externalizes operational memory into RDF files such as core.ttl, preferences.ttl, index.ttl, and sessions/*.ttl. That makes context inspectable, linkable, portable, and queryable beyond the current application session.

Why does the Virtuoso Support Skill matter?

It treats support resolution as a structured, tool-mediated, auditable context workflow: select the target instance, use predefined templates first, retrieve schema and entity context, generate or validate RDF Views, and confirm outcomes with SPARQL.

Knowledge Graph Explorer

Deck Graph

0 nodes, 0 links

Explore Knowledge Graph using SPARQL

SPARQL Workbench

SELECT result format: text/x-html+tr. DESCRIBE/CONSTRUCT result format: text/x-html-nice-turtle.

SELECT ?type (SAMPLE(?s) AS ?sample) (COUNT(*) AS ?count)
WHERE {
  GRAPH <https://sierra.ai/blog/context-engine-linked-data-context-deck-gpt5-chat-1.ttl> { ?s a ?type }
}
GROUP BY ?type
ORDER BY DESC(?count)