concepts · permissions

Same resource, different depth

An event has one address. Its date can be public while its booking notes stay private. Contexts let the current sempods contract express that difference without creating a second event.

same event URI
      |
      +--> public Context
      |      title, date, location
      |
      +--> private Context
             notes, drafts, planning

A Context is a permission boundary

A Context is an RDF named graph. Every statement belongs to exactly one. Grants name its IRI with #read, #write or #manage. An app can receive access to public events and private planning without receiving access to contacts.

The pod resolves grants on each request. They are durable server-side policy, separate from the coarse OAuth scopes carried in a token. Revoking a grant changes what the next request may reach.

One decision across the data surfaces

Resource reads, find, SPARQL and optional MCP tools use the caller's readable Contexts. A query cannot gain access by naming a private graph. A write needs authority over its explicit target Context.

Clients can narrow a read to selected Contexts. Unknown or unreadable selections add no data; the result does not disclose the private catalogue.

Lifecycle is optional; the current boundary is core

Every current core implementation supports the Context contract. Creating and deleting Contexts through HTTP is a separate optional module. A deployment can provision its Contexts another way.

The direction is broader

The vision leaves room for different storage and policy models. Authorized data access proposes ordinary operations without Context setup, while retaining discovery and selection of named views. That proposal has not replaced the current contract.

The aim is a small common interface: the pod protects the data, and clients can use it without adopting its internal policy representation.

Context contract Grant contract Optional lifecycle module Explore retrieval