Architecture 10 min read

The Semantic Stack: RDF, OWL, and SHACL as Engineering Materials

RDF, OWL, and SHACL are engineering materials with real performance trade-offs, not academic formalisms.

Thesis

RDF, OWL, and SHACL are not academic formalisms - they are engineering materials with specific performance characteristics, trade-offs, and failure modes. Any team building an ontology-driven control system must understand these three W3C standards as deeply as a database team understands normalization. They are the foundation on which everything else in this series is built.

Why this matters

Most software engineers encounter the semantic web stack through one of two doors: either they read the W3C specs (which are precise but impenetrable) or they read a blog post about knowledge graphs (which is accessible but shallow). Neither gives them what they actually need: an understanding of these technologies as materials with properties - like choosing between PostgreSQL and MongoDB based on read patterns, not on marketing claims.

Here is what the semantic stack actually is, in engineering terms:

  • RDF is a schemaless graph database with a standard query language (SPARQL) and a merge operation that requires zero coordination between writers. Think of it as git for data: independent authors produce triples, and they merge without conflict resolution because RDF’s URI-based addressing eliminates naming collisions.
  • OWL is a reasoning layer that computes entailments for free. Declare your class hierarchy once and every query inherits it, with no JOIN tables or materialized views.
  • SHACL is a declarative constraint language that validates the graph in microseconds. It is the cheap filter that makes the expensive LLM-based system economically viable.

Together, these three standards give you a typed, reasoned, validated graph database that supports schemaless evolution, automated inference, and programmatic constraint checking. This is the substrate on which the control loop operates.

graph TB
    subgraph "The Semantic Stack"
        R["RDF<br/>schemaless graph<br/>zero-coordination merge"]
        O["OWL<br/>reasoning layer<br/>computed entailments"]
        S["SHACL<br/>constraint layer<br/>microsecond validation"]
        R --> O --> S
    end
    E["Embedding similarity<br/>+ LLM review"]
    S --> E
    E --> C["the validation cascade<br/>T1 to T4"]

RDF: schemaless merge without coordination

What it is

RDF (Resource Description Framework) represents information as subject-predicate-object triples. Every fact is a three-part statement: “chiller-9” “belongs-to” “main-campus.” Triples are stored in an Oxigraph triple store, queried with SPARQL, and serialized as Turtle for exchange.

@prefix org: <https://omoios.dev/org#> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .

org:chiller-9 a org:Chiller, org:Equipment ;
    org:belongs-to org:main-campus ;
    org:status "degraded" ;
    org:COP 3.8 .

Every statement here is a triple. The a keyword is shorthand for rdf:type. The @prefix declaration lets us write org:chiller-9 instead of the full URI.

Why it matters for control systems

In a multi-agent system, multiple agents are producing data simultaneously. An ingester extracts facts from a CRM system. An observer detects state changes from a telemetry stream. A generator proposes new ontology entries. All of these are writing triples to the same store.

In a relational database, concurrent writers need schema migrations coordinated by a DBA. In a document store, concurrent writers need agreed-upon document structures. In RDF, concurrent writers just produce triples - and they merge. Two agents can independently assert facts about the same entity, and the triples coexist in the store without conflict. URI-based addressing ensures that “chiller-9” is the same entity regardless of which agent wrote it.

This property is what makes the generator swarm possible: multiple generators produce ontology change proposals in parallel, and the cascade validates them independently before merging into the ontology store. Asking “which degraded assets sit at the main campus?” is a SPARQL query, not an application-specific join:

PREFIX org: <https://omoios.dev/org#>
SELECT ?asset ?cop WHERE {
  ?asset a org:Asset ;
         org:belongs-to org:main-campus ;
         org:status "degraded" ;
         org:COP ?cop .
  FILTER(?cop < 4.0)
}

Failure modes

RDF’s schemalessness is also its weakness. Without a schema, garbage triples accumulate silently. An ingester can assert “org:chiller-9 org:favorite-color ‘blue’” and nothing prevents it - unless a SHACL shape explicitly prohibits unrecognized predicates. The SHACL layer exists partly to compensate for this.

OWL: free inference from declared axioms

What it is

OWL (Web Ontology Language) adds a reasoning layer on top of RDF. You declare axioms using OWL’s vocabulary (owl:Class, rdfs:subClassOf, owl:inverseOf, etc.), and an OWL reasoner computes entailments - facts that must be true given the declared axioms and the existing triples.

Why it matters for control systems

OWL reasoning gives you computed relationships for free. Declare once:

org:Chiller rdfs:subClassOf org:Equipment .
org:Equipment rdfs:subClassOf org:Asset .

And the OWL reasoner in Oxigraph automatically knows that every Chiller is also an Equipment and an Asset. No application code, no JOIN tables, no materialized views. When an agent queries “show me all Assets,” the results automatically include chillers, pumps, HVAC units - whatever the class hierarchy defines.

This is especially valuable for the observation layer. If you add a new class EmergencyGenerator as a subclass of Equipment, all observation patterns that apply to Equipment automatically apply to EmergencyGenerator - without changing a single agent’s configuration.

OWL reasoning also supports property chain inference: “if X is-connected-to Y and Y supplies Z, then X depends-on Z.” These transitive relationships are expensive to compute in application code but trivial for a reasoner.

The performance trade-off

OWL 2 DL (the profile Oxigraph uses) is decidable and tractable - meaning reasoning terminates in finite time with a correct answer. OWL 2 Full (the full standard) is undecidable - meaning some queries will never terminate. In practice, the ontology store uses OWL 2 DL, which covers class hierarchies, property restrictions, and cardinality constraints - the vast majority of what a control system needs.

The cost of reasoning grows with ontology size. At the scale of an organizational ontology (thousands of classes, tens of thousands of instances), OWL reasoning adds milliseconds per query - negligible compared to LLM inference time. For control systems, we are safely in the tractable regime.

SHACL: the cheap filter that makes the system viable

What it is

SHACL (Shapes Constraint Language) is a W3C standard for validating RDF graphs against declarative constraints called “shapes.” A shape defines what a valid instance of a class looks like: which properties it must have, what their values can be, which cardinality constraints apply.

Why it matters for control systems

SHACL is the economic enabler of the ontology-driven control loop. Without it, every ontology change proposal - every triple an agent wants to add to the graph - would need to be reviewed by a frontier LLM model. At the scale of continuous agent operation (dozens of proposals per second), this would be prohibitively expensive.

SHACL catches the majority of bad proposals at Tier 1 of the cascade - before any LLM is invoked. The cost is near-zero: a SHACL validation check takes microseconds on a compiled shape definition. Invalid proposals (missing required properties, wrong types, constraint violations) are rejected with a specific violation report.

org:AssetShape a sh:NodeShape ;
    sh:targetClass org:Asset ;
    sh:property [ sh:path org:status ; sh:in ( "ok" "degraded" "failed" ) ; sh:minCount 1 ; sh:maxCount 1 ] ;
    sh:property [ sh:path org:belongs-to ; sh:class org:Site ; sh:minCount 1 ; sh:maxCount 1 ] ;
    sh:property [ sh:path org:COP ; sh:minInclusive 0.0 ; sh:maxInclusive 10.0 ] .

org:ActionProposalShape a sh:NodeShape ;
    sh:targetClass org:ActionProposal ;
    sh:property [ sh:path org:precondition ; sh:minCount 1 ] ;
    sh:property [ sh:path org:postcondition ; sh:minCount 1 ] ;
    sh:property [ sh:path org:affects ; sh:minCount 1 ] .

The AssetShape says: every Asset must have exactly one status (drawn from a closed vocabulary), exactly one site it belongs to, and a COP value between 0 and 10. The ActionProposalShape says: every action proposal must specify at least one precondition, one postcondition, and the asset it affects.

These shapes catch the most common failure modes before any LLM is invoked. An agent that proposes “schedule maintenance for chiller-9” without specifying preconditions or affected asset fails at SHACL - no Haiku, no Opus, no cost.

Where SHACL ends and LLMs begin

SHACL validates structural constraints. It cannot validate semantic constraints - whether a proposed action makes sense in context. “Chiller-9 needs inspection because its COP dropped below 4.0” is structurally valid but semantically wrong if the COP drop is caused by normal seasonal variation rather than a fault. Tier 3 (Haiku) and Tier 4 (Opus) of the cascade handle this semantic validation.

The cascade: composing the stack into a validation pipeline

The cascade tier system is where the semantic stack becomes operational. It composes RDF (the data format), OWL (the reasoning layer), and SHACL (the validation layer) with embedding similarity and LLM review into a single pipeline:

T1 SHACL $0 T2 Embedding ~$0.0001 T3 Haiku ~$0.001 T4 Opus ~$0.05 ✓ Accept write
Many proposals in, few out. The cheap tiers reject most of the noise before any expensive model runs.

The cascade is a cost-optimization strategy. T1 costs $0 and takes roughly 0ms. T2 costs about $0.0001 (embedding compute). T3 costs about $0.001 (a Haiku-class API call). T4 costs about $0.05 (an Opus-class API call). By filtering at each tier, the system only invokes expensive models for the proposals that survive all cheap checks. In the harness architecture, T1 to T3 filter out the majority; T4 only runs on the most promising candidates.

sequenceDiagram
    participant G as Generator
    participant T1 as T1: SHACL
    participant T2 as T2: Embedding
    participant T3 as T3: Haiku
    participant T4 as T4: Opus
    G->>T1: proposal
    T1->>T2: structurally valid
    T2->>T3: novel
    T3->>T4: plausible
    T4->>G: accept
    T1-->>G: reject (cost $0)
    T3-->>G: reject (cost $0.001)
    T4-->>G: reject (cost $0.05)

The stack in production

This is not theoretical. The semantic stack is the infrastructure layer of the centralized system described in “harnesses all the way down.” Oxigraph provides the RDF triple store with built-in OWL reasoning and SPARQL query support. SHACL shapes validate proposals. Turtle is the serialization format for proposals, subgraphs, and extractions. All three standards are W3C-standardized, have multiple implementations, and are battle-tested in production systems.

For an OrgOps system (the organizational control system this series builds toward), the semantic stack would hold:

  • Object types: Department, Team, Role, Person, BudgetLine, Project, Metric, Incident, Policy, Process
  • Link types: reports-to, owns-process, depends-on, affects, approves
  • Action types: hire, promote, restructure, allocate-budget, escalate-incident, close-quarter

The stack does not need to be complete on day one. The centralized-to-decentralized path principle applies: start with the minimum viable ontology (5 object types, 3 link types, 2 action types), prove the control loop works, then extend.

Failure modes and mitigations

Failure ModeWhat HappensMitigation
Garbage triplesAgents assert invalid predicates not in the vocabularySHACL shapes restrict allowed predicates per class
Vocabulary gapsA real-world concept has no class in the ontologyAgents flag gaps via ontology-bounded output; generators create new classes via cascade T4 approval
Reasoning explosionOWL inferences cascade into unintended conclusionsOWL 2 DL profile is decidable; restrict property chains to depth 3
Shape driftSHACL shapes don’t evolve with the ontologyShape governance: shapes reviewed with the same cascade that reviews proposals
Merge conflictsTwo agents assert contradictory triplesProvenance-based conflict resolution: newer triple wins, older triple archived with a flag

Open questions

  • What is the optimal shape authoring workflow? (Manual? LLM-generated? Hybrid?)
  • Can global ontology consistency be checked automatically across proposals accepted in the same epoch?
  • How does the cascade’s T4 throughput hold up against real organizational proposals with full subtree context?

Citations