The Semantic Web is here, and it’s also sovereign and decentralised

Josh Field — Mon, 23 Mar 2026 12:26:33 GMT

The Semantic Web is Here, and It’s Also Sovereign, Decentralised & Alive

For thirty years, the Semantic Web has been the web’s most promising unfulfilled vision: a web where data has meaning, where machines can reason over relationships, where information flows freely between systems because it’s structured as a universal graph. The W3C delivered the specifications — RDF for data, SPARQL for queries, SHACL for validation — and then not much happened.

The standards worked, but the adoption didn’t. RDF stayed in academic papers and enterprise knowledge graphs. SPARQL ran inside corporate data warehouses. The average developer never touched a triple store, and the web that actually got built was one of JSON APIs, platform silos, and proprietary databases.

There have been attempts to course-correct. Solid gave users personal data pods backed by Linked Data, but kept the client-server model: your pod lives on a server someone runs, applications request access to it, and the protocol is HTTP with extra semantics on top. It decentralised storage but not infrastructure, and your sovereignty extends exactly as far as your pod provider allows. Mastodon and the Fediverse decentralised platforms through ActivityPub federation, but each instance is still a server run by an administrator who sets the rules, controls the data, and can disappear overnight. You don’t own your social graph; your instance admin does. And neither Solid nor the Fediverse made the Semantic Web standards native to their runtime — Solid uses RDF as a serialisation format layered over HTTP resources, and Mastodon uses JSON-LD as an interchange format between servers. In both cases, the semantic layer is a wire protocol, not the foundation the application actually thinks in.

The real problem was that the Semantic Web had nowhere meaningful to live. It needed a runtime where triples are the native data structure, where SPARQL isn’t a niche query language but the default way to ask questions, where SHACL shapes aren’t theoretical constraints but the actual schema layer that applications depend on. And it needed that runtime to be sovereign by default, not dependent on a server, an instance admin, or a pod provider.

That runtime now exists. It’s called AD4M, and it isn’t just semantic — it’s decentralised, sovereign, agent-centric, and designed to give it’s users choice.

What AD4M Actually Is

AD4M (the Agent-centric Distributed Application Meta-ontology) is a personal agent runtime. You run it on your devices. It holds your identity (a did:key backed by Ed25519), your data as a local knowledge graph, and your relationships with others through shared graphs called neighbourhoods.

The core data structure is the perspective — a knowledge graph made of links. Each link is an RDF triple: source, predicate, target. Your perspective is yours; you control what’s in it, what you share, and with whom. When you share a perspective with others, it becomes a neighbourhood, synchronised through a link language — a pluggable protocol adapter that handles gossip, conflict resolution, and persistence across peers. The default link language uses Holochain’s DHT, but a link language can be backed by anything: a centralized server, IPFS, a blockchain, a Git repository. The carrier is a choice, not a constraint.

This is the layer the Semantic Web was always missing — the personal layer. Not a global graph owned by Google or a corporate triplestore in an enterprise data center, but a graph that belongs to you, speaks standard W3C protocols, and federates with others through cryptographic identity and whatever transport suits the context.

RDF as the Native Data Structure

Every AD4M link is an RDF triple — not metaphorically, but literally. When you add a link to a perspective:

source: literal://string:channel-general
predicate: flux://has_channel_name
target: literal://string:general

it’s stored in an embedded SPARQL engine (Oxigraph) as a direct RDF triple:

Link metadata (who created it, when, their cryptographic signature) is stored as RDF-star annotations:

<<    >>
     "did:key:z6Mkr8wn..." ;
     "2026-03-23T04:15:00.000Z" .

This isn’t a compatibility layer or an export format — RDF is the storage model. Oxigraph maintains native SPO/POS/OSP indexes on every triple, and SPARQL queries resolve through direct index probes rather than full-store scans.

SHACL as the Schema Layer

The Semantic Web’s answer to “how do I define what valid data looks like” is SHACL, the Shapes Constraint Language. In AD4M, SHACL serves as the schema layer that applications use to define their data models.

Developers write TypeScript with semantic decorators:

@Model({ name: 'Channel' })
export class Channel extends Ad4mModel {
    @Flag({ through: 'flux://entry_type', value: 'flux://has_channel' })
    type: string;

    @Property({ through: 'flux://has_channel_name', required: true })
    name: string;

    @HasMany(() => Message, { through: 'flux://has_message' })
    messages: Message[];
}

At runtime, this generates a W3C SHACL shape:


    a sh:NodeShape ;
    sh:targetClass  ;
    sh:property [
        sh:path  ;
        sh:hasValue "flux://has_channel"
    ] ;
    sh:property [
        sh:path  ;
        sh:minCount 1 ;
        sh:maxCount 1
    ] ;
    sh:property [
        sh:path  ;
        sh:nodeKind sh:IRI ;
        sh:class 
    ] .

The SHACL shape is stored in the graph itself as AD4M links — the shapes are data. They’re shareable, forkable, versionable. A community can adopt a set of shapes, extend them, or compose them differently. The schema becomes part of the social fabric rather than something an administrator imposes.

This is what SHACL was designed for but rarely gets to do: defining constraints on a graph, validated by the participants, without requiring a central authority to enforce them.

Subject-Oriented Programming and Object-Graph Mapping

Traditional application development starts with a database schema. You define tables, columns, foreign keys, and then write an ORM (Object-Relational Mapping) layer to bridge the gap between your relational data and the objects your application actually works with. The schema is fixed, lives on a server, and every application that touches that database must conform to it.

AD4M inverts this. There is no fixed schema and no central database. There’s a graph of links, and subject classes that define how to view that graph as structured objects. A subject class is a lens — it declares “a Channel is any entity in the graph that has a flux://entry_type link pointing to flux://has_channel and a flux://has_channel_name property." If those links exist, the entity conforms. If they don't, it doesn't. The graph itself is schema-free; the structure emerges from how you look at it.

This is what AD4M calls Object-Graph Mapping — OGM rather than ORM. Where an ORM maps objects to rows in relational tables, an OGM maps objects to patterns in a semantic graph. The distinction matters:

ORMs are tightly coupled to a schema. Change the table, break the mapping. Migrations are painful, versioning is manual, and two applications can’t easily impose different structures on the same data.
OGMs are loosely coupled to a graph. The same set of links can conform to multiple subject classes simultaneously. A Channel subject class and a ForumSection subject class might match the same entity if its links satisfy both shapes. Applications don't fight over the schema because there isn't one to fight over — each brings its own lens.

This is what makes AD4M’s approach subject-oriented rather than object-oriented. In traditional OOP, the class defines what the object is. In subject-oriented programming, the subject class defines how an observer sees the data. The same underlying links can be a Channel in one application, a ForumSection in another, and a TaskBoard in a third — depending on which subject classes each application loads. The data doesn’t change; the perspective does.

Social DNA takes this further by making the subject classes themselves programmable social artefacts. The shapes that define your data model are stored as links in the graph, which means they can be shared across neighbourhoods, forked by communities, and evolved over time. A community doesn’t install a schema update from a vendor — they modify their own shapes, and those modifications propagate through the same peer-to-peer infrastructure as any other data. The rules for how data is structured are governed by the same social processes as the data itself.

For developers, the surface area feels familiar — decorators, findAll, where, include — but what's happening underneath is fundamentally different from an ORM. You're not mapping objects to rows. You're pattern-matching over a semantic graph, and the patterns are as fluid and composable as the data they describe.

SPARQL as the Query Engine

AD4M uses SPARQL 1.1 as its primary query engine, with full support for:

Triple patterns — the basic building blocks of graph queries
OPTIONAL — left-join semantics for nullable properties
FILTER — comparison operators, string matching, date ranges
UNION — combine multiple query branches in a single request
RDF-star — annotate triples with metadata (who created them, when, their signature)

The query builder generates SPARQL from the same decorator metadata that generates SHACL shapes. When a developer calls:

const channels = await Channel.findAll(perspective, {
    include: { messages: true }
});

The runtime produces a UNION query that fetches both channels and their messages in a single round-trip:

SELECT ?depth ?parentBase ?relationName ?source ?predicate ?target WHERE {
    {
        ?source   .
        ?source ?predicate ?target .
        BIND("0" AS ?depth)
    }
    UNION
    {
        ?parentBase  ?source .
        ?source   .
        ?source ?predicate ?target .
        BIND("1" AS ?depth)
        BIND("messages" AS ?relationName)
    }
}

Results are hydrated into typed objects by depth and relation name. The developer never sees SPARQL — they write findAll, findOne, where, include, a familiar ORM-style interface. Underneath, every query is a standard W3C SPARQL query running against a proper triple store with proper indexes.

The Semantic Web’s original pitch was structured, meaningful data with a standard query language. In AD4M, that pitch is finally delivered as the query engine for a real application platform.

DIDs as the Identity Layer

Every AD4M agent has a decentralised identifier, a did:key backed by Ed25519 cryptography. This isn't bolted on after the fact — it's the foundation everything else is built on.

Every link you create is signed with your DID’s Ed25519 key. When another agent receives your link through a shared neighbourhood, they can verify who created it (the did:key in the proof), when (the RFC 3339 timestamp), and that it hasn't been tampered with (the Ed25519 signature over the SHA-256 hash of the canonical JSON).

This means every triple in the graph has provenance — not just “this data exists” but “this data was asserted by this specific cryptographic identity at this specific time, and here’s the proof.” The DID isn’t issued by a platform; it’s derived from a keypair that the agent generates and stores locally. You don’t need permission to have an identity and you don’t need a server to verify one. The identity layer is as decentralised as the data layer.

Decentralised the Right Way

There are many ways to “decentralise,” and most of them end up recentralising something else. Put data on a blockchain and you’ve centralised consensus. Use a federated protocol and you’ve centralised servers.

AD4M’s decentralisation is agent-centric. The organising principle isn’t a global ledger, a federation of servers, or a content-addressed filesystem — it’s the agent, a person (or AI) with a cryptographic identity, running software they control, on devices they own.

Your knowledge graph lives on your devices. No server has a copy unless you choose to sync it there. When you share a perspective, agents sync through a link language — the default uses Holochain’s DHT, where every participating agent validates and stores a portion of the shared data, but a link language can wrap any transport: a centralised relay, IPFS, ActivityPub, a home server, a custom protocol, smoke signals… The point isn’t that every neighbourhood must use a DHT, it’s that every neighbourhood can choose what to use.

AD4M doesn’t mandate a single storage or networking protocol. A “language” is a pluggable adapter that uses whatever the context requires. And the meta-ontology itself is neutral: AD4M doesn’t prescribe what your data looks like. It provides the grammar — links, perspectives, neighbourhoods — and lets communities define their own vocabulary through subject classes and SHACL shapes. The same underlying graph can be viewed through different lenses by different applications.

This is what decentralising “the right way” means. The architecture doesn’t just move data off a server, it moves authority to the edges. Each agent decides what to share, with whom, under what rules. The rules themselves (encoded as SHACL shapes) are data in the graph — visible, auditable, forkable, evolvable.

The Road Ahead: Verifiable Credentials and ZCAPs

AD4M’s identity layer is currently DID + Ed25519 signatures. The next steps extend this into the full W3C Verifiable Credentials ecosystem.

Verifiable Credentials will allow agents to make and verify claims about each other without a central authority. “Alice is a member of this community” or “Bob has permission to moderate this channel” become cryptographic assertions, issued by one agent, held by another, verified by anyone, and revocable by the issuer. VCs turn social relationships into portable, privacy-preserving credentials.

ZCAPs (Authorisation Capabilities) will replace the current permission model with fine-grained, delegatable capabilities. Instead of “this app can access everything,” it becomes “this app can read channels in this community, add messages, but not delete anything, and this permission expires in 24 hours.” Capabilities can be attenuated and delegated — Alice can give Bob a subset of her own permissions, and Bob can pass an even smaller subset to an AI assistant. This is object-capability security applied to a decentralised social graph.

Together, VCs and ZCAPs complete the picture: identity, data, schemas, queries, permissions, and credentials, all standards-based, all decentralised, all under the control of the people who use them.

The Semantic Web We Were Promised

The Semantic Web vision was always compelling: a web of meaning, where data is structured, queryable, and interoperable. It didn’t fail because the standards were wrong, but because they were designed for a web that didn’t exist yet — one where individuals controlled their own data, where identity was portable, where schemas were social agreements rather than corporate decisions.

It also needed something the W3C couldn’t specify: an unenclosable carrier. A network layer that can’t be captured, shut down, or toll-gated by any single entity. HTTP doesn’t qualify, since it depends on servers someone controls. Blockchains don’t qualify either — they centralise consensus and charge rent for every transaction. What the semantic web needed was a peer-to-peer substrate where participation is infrastructure, where the more agents that join, the more resilient and available the network becomes, with no chokepoint in between.

Holochain paved the way for this. Its agent-centric architecture — where each participant runs their own node, validates their own data, and contributes to a shared DHT — provided the first credible unenclosable carrier for structured data. But Holochain alone is a networking layer. It doesn’t speak RDF, doesn’t understand SPARQL, and doesn’t validate SHACL shapes. It needed a semantic layer on top, and the semantic web needed a carrier underneath.

AD4M is what happens when those two halves meet. It inherits Holochain’s agent-centric philosophy — you are the centre of your digital world, not a platform, not a ledger, not a server — and brings in the W3C’s semantic standards as first-class citizens:

RDF works when triples are your native data structure, not an export format
SPARQL works when it’s backed by proper indexes and real query planning
SHACL works when shapes are social agreements stored in the same graph they constrain
DIDs work when identity is the foundation, not an afterthought

The Semantic Web is here. It’s just not on the web you’re used to — it’s running on personal agents, backed by peer-to-peer networks, secured by cryptographic identity, and governed by the communities that use it.

AD4M is open source at github.com/coasys/ad4m.

The Semantic Web is here, and it’s also sovereign and decentralised was originally published in Coasys on Medium, where people are continuing the conversation by highlighting and responding to this story.

Stories by Josh Field on Medium