Skip to content

The sempods specification

Development snapshot — not a release

Core 0.1-dev · Source revision and matching artifacts.

A pod is a person's or an organisation's own store of linked data: they hold it, they say who may read and write which part of it, and applications talk to it over HTTP. This site is the contract such a pod implements. It is written so that somebody who has never seen the reference implementation can build a conformant pod in a language of their choosing without depending on its internals.

The point is not a new protocol stack. sempods profiles and composes standards that already exist: HTTP resources, RDF and named graphs, JSON-LD, SPARQL, OAuth/OIDC and MCP. The specification adds the pod contract between them: one base URL, one context per statement, server-resolved grants, sandboxed reads and writes, and an agent surface that uses the same rules as every other client.

Revisions and status

This website follows main. Its normative text already binds under governance, subject to the stated pre-publication limits. A changing development label is not a published version. This build's revision identifies its source and matching artifacts.

Published versions and canonical release notes are separate from website deployments. Selecting a revision explains how to consume one consistent snapshot.

Proposals and guides remain informative GitHub documents at this build's source revision. Repository checks explains validation limits; issues and the 0.1 milestone track the remaining work.

Core and modules

Core is not optional. Contexts, grants, auth, CRUD, SPARQL and find are what makes a pod a pod. Something implementing a subset of them is something else, and should not use the name.

Modules are optional and versioned separately. Context management, OIDC, media and MCP each add a surface a pod may choose to offer. A pod may implement core 0.1 alongside media 0.2.

"Optional" only means something if a client can ask, so a pod announces what it implements at GET {pod}/_system/conformance — see the core chapter.

The chapter map, the requirement scheme and what an identifier promises are on the specification page.

Try it

The HTTP surface is described in OpenAPI and rendered with a client you can send requests from. Anonymous reads and SPARQL need no token, so the read surface can be explored without registering anything.

Elsewhere

  • Vocabulary — the sps: terms, and what stability they promise.
  • sempods-kotlin — the reference implementation. It is one implementation of this contract, not the definition of it.
  • The repository — where the text is edited, and where a disagreement with it is filed.