sempods

concepts · retrieval

A foothold is more useful than a dump

An event has a name, dates, a place and links. A task has people and projects around it. Retrieval can begin with one useful resource and follow those relationships until the client has what its task needs.

Find is the entry point

A client gives find text and optional constraints such as resource type. It receives an RDF subgraph with matching resources and useful surrounding statements. The result gives it things to inspect and addresses to follow.

The contract describes the result rather than a search algorithm. Kotlin 0.2 supplies a SPARQL regex adapter over literals. A deployment can add other adapters behind the same interface; vector retrieval is not a feature shipped by that adapter.

Traversal does the deeper work

Fetch a known resource, follow its links, or query the neighbourhood you need. Add those facts to the working graph. A calendar can render it; an agent can use it to answer a question.

This loop is client behavior built on the data operations. The client chooses when it has enough information, while each pod decides which facts it may return.

Permissions apply throughout

The current contract limits retrieval and traversal to readable Contexts. An anonymous visitor can find public events. A caller with private grants can reach more. Search cannot bypass the authorization decision made for the same data through a resource read or SPARQL.

Useful for memory, useful for ordinary apps

Notes, tasks and observations could become linked knowledge in a personal pod. An agent could gather the relevant slice for one question without making its own product the permanent home of that memory.

The same pattern helps a venue website fetch a location for an event. Shared meaning and stable addresses make the links useful to both clients.