the model

One graph, many clients, one permission model

sempods is easier to understand if you do not start with apps. Start with the data: every thing has an address, every statement has meaning, and every statement belongs to a context.

HTTP resources     SPARQL queries      MCP tools
      \                 |                /
       \                |               /
        v               v              v

          same context permissions
                    |
                    v
              one RDF graph

1. Resources are web addresses

A pod resource is identified by a URI. That URI is not just an internal ID; it is an address. Request it over HTTP and the pod can return a machine-readable description of the resource, typically JSON-LD.

This is what makes the model feel web-native rather than platform-native. Links can cross apps, pods and organizations without asking a central service to translate every identifier.

2. Data is RDF, not a private app shape

sempods stores knowledge as RDF statements. A task, event, place or person is not reduced to a JSON object invented by one product. It can use shared vocabulary such as schema.org and later more specific models.

That does not mean every app developer has to think in triples all day. It means the underlying contract stays semantic, so apps and AI agents can meet on common meaning instead of one-off integrations.

3. Contexts are the permission boundary

RDF has a fourth dimension: the named graph, or context. sempods makes that context the core authorization primitive. Every statement belongs to exactly one context. Access is granted as read, write ormanage on contexts.

4. SPARQL is sandboxed by the server

The SPARQL endpoint is powerful because it queries the graph directly. That only works safely if the server, not the client, decides which contexts are visible.

A query can ask broad questions, but the result is limited to contexts the caller may read. The same rule applies to write operations. An app or agent cannot escape by naming a private graph in the query.

5. HTTP, SPARQL and MCP use the same path

A browser, a web app and an AI agent can enter through different doors. HTTP resource requests, SPARQL queries and MCP tools are different interfaces over the same pod model.

That matters because MCP does not become a privileged backdoor for AI. An agent is just a client. It sees the contexts its token allows, and nothing more.

In the reference implementation, a pod exposes that client path at/_system/mcp. The aaltra pod has one too, which makes the live event example testable through more than HTTP and SPARQL.

6. The control plane is protected

Pod data can describe permissions, apps and identities as knowledge. But the authority to grant access lives in the protected /_system area, not in arbitrary RDF statements written by an app.

That keeps a sharp line between data that says something and control-plane state that actually authorizes something.

Where the model goes deeper

The next technical layer is graph retrieval: start with a semanticfind, inspect the returned graph, then follow URIs throughget_resource or SPARQL until the app or agent has the slice of knowledge it needs.

SHACL shapes and a TBox model are still being explored as future semantic contracts. They matter, but they are not the first published deep dive.

Try a live queryRead graph retrievalRead sempods-kotlin