try it yourself
Start with the part that is real today
sempods is still young, so the entry points are not equally polished. The first one takes ten seconds. The deeper ones are for people who want to read or run the reference implementation.
1. Query a live public pod
Public contexts are readable without authentication. This query reads a real venue's event calendar from its own pod:
curl -X POST https://sempods.org/aaltra/_system/sparql/query \
-H "Content-Type: application/sparql-query" \
-H "Accept: application/sparql-results+json" \
--data 'PREFIX schema: <https://schema.org/>
SELECT ?e ?name ?start WHERE {
?e a schema:Event ; schema:name ?name ; schema:startDate ?start
} ORDER BY ?start LIMIT 3'The endpoint is ordinary HTTP. The query is ordinary SPARQL. The result is JSON from live linked data, not a special website API.
2. Follow the data
The query returns event URIs. Open one and the pod returns the resource itself with the statements you are allowed to see. That is the Linked Data part: the identifier is also the address.
This is the smallest useful proof of decentralization. The venue owns the event graph. Apps and websites can use it without becoming the place where the data lives.
3. Ask for a hosted test pod
Concrete pods can already live under sempods.org paths such as aaltra. There is no public hosting entry UI yet; new pods for early ideas or tests are created manually on request.
That is the fastest path when you want a real pod without operating the infrastructure yourself: backups, updates and migrations across version or schema changes are handled on the hosted side. For a test pod, write to danilo@sempods.org.
4. Run your own pod
The stronger decentralization proof is self-hosting. In sempods-kotlin, the local deployment brings up a pod and the services behind it, so you can test against infrastructure you run yourself.
This path is rougher than asking for a hosted test pod, but it matters. It proves sempods is not one hosted service with a public API; the hosted path is only the fastest way to begin.
5. Read or run the reference implementation
sempods-kotlin is the reference implementation. It contains the working server and client stack: Linked Data CRUD, contexts, grants, SPARQL sandboxing and a pod MCP endpoint at /_system/mcp.
The aaltra pod exposes that MCP path too, so the same live data can be tested through HTTP, SPARQL or MCP without changing the ownership model.
It is not meant to be the only implementation. It is the executable proof while the dedicated sempods-spec repository and OpenAPI contract are being prepared.
6. Build against the JVM artifacts
The artifacts are on Maven Central. Until a compiled quickstart example is pulled into the website, the coordinates live in one place here:
implementation(platform("org.sempods:sempods-bom:0.1.0"))
implementation("org.sempods:sempods-client")Version 0.1.0, Java 21 bytecode. SempodsPodClientcovers reading, writing, contexts and SPARQL.
7. Try the preview apps
apps.sempods.org is an early collection of apps that connect to a pod by URL. Focus is a todo app, Explorer visualizes the graph, and Konsum is a small shopping-list app.
The surface is still rough, but the architecture is the important part here: these apps work against pods through the SDK that is being prepared for public release.
Open ExplorerOpen FocusSee preview apps
8. Wait for the easier path
The public TypeScript SDK is the next important surface for app builders. Once it is open, this page should shift from "read the reference implementation" toward "build a small app against a pod".
SHACL shapes and a TBox model may become part of that later: apps and agents should eventually be able to discover the shapes and meaning they can work with, not rely only on prose and convention.
Something does not behave as written?Open an issue. A first-run problem is one of the most useful reports a project at this stage can receive.