concepts · graph retrieval

Graph retrieval starts with a foothold, not a dump

Retrieval usually means turning documents into chunks, embedding them, and hoping the nearest text fragment contains the answer. sempods starts from a different unit: a resource in a graph.

An event is not only a paragraph about an event. It has a URI, a type, a name, a start date, an image, a location and links to other resources. A task, note, person or project can work the same way. Retrieval can therefore move from one known thing to related things instead of searching every fact from scratch.

question or view need
        |
        v
      find
  semantic entry
        |
        v
  working graph
   |          |
   |          +--> answer or render
   |
   +--> follow URIs
        get_resource / SPARQL
        merge facts back into the graph

The role of find

find is the entry abstraction. A client gives the pod text and may constrain the returned resource type. The result is not a proprietary search result object. It is an RDF subgraph: matching resources plus a small expansion such as type, label and name.

The important design choice is that find is a contract, not an algorithm. In the reference implementation today, the live adapter is a SPARQL regex text match over literals. In another implementation, the same shape has already been useful with lexical search and vector search adapters running beside it. The caller still says find; the pod decides which engines can satisfy that request.

Traversal does the deeper work

Once find gives a foothold, the client can inspect the graph. It can fetch a known resource, follow a URI, or run a SPARQL graph query for the exact neighbourhood the view or question needs.

That loop matters for AI, but it is not AI-only. A calendar widget can use the same pattern to find events and fetch venue data. An agent can use it to gather enough grounded facts before it answers. The last step differs: applications render the graph, agents turn the graph into text.

Permissions are part of retrieval

Graph retrieval only works if it cannot quietly step around authorization. sempods keeps retrieval inside the same context sandbox as SPARQL and resource reads. An anonymous visitor can find public events. A private agent can find more only when its token grants the relevant contexts.

Contexts are the current boundary in the reference implementation. The broader authorization work may become more expressive, especially around ACP-style policies and fine-grained AuthZ, but the principle should survive: search depth is a function of permission, not of which client surface was used.

Why this matters for memory

A local memory browser pod is the natural place where this becomes personal: notes, tasks, calendar entries, projects and observations can become a graph the user controls. That surface is not public yet, but it explains why graph retrieval is central to sempods.

The agent should not own the memory. It should arrive with a grant, usefind to locate a useful foothold, traverse what it is allowed to read, and leave the knowledge where it belongs.

Where MCP fits

MCP makes the same idea available to agents. The pod MCP endpoint exposesfind, resource reads and SPARQL-style traversal as tools, but it does not turn AI into a privileged path. A multi-MCP setup is interesting for the opposite reason: an agent can work across several independent pods, each with its own grants.

The near-term direction is simple: keep find small, add better adapters behind it, and let clients traverse real linked data instead of flattening knowledge into one more private index.

Back to conceptsNext: federated grantsImplementation notes