The urn:solid namespace
Draft specification — for review by the W3C Solid Community Group.
Summary
The urn:solid namespace provides location-independent identifiers for use in Solid-based applications where stable naming across protocols, storage locations, or offline contexts is required. It complements HTTP URIs rather than replacing them. HTTP URIs remain the primary mechanism for dereferencing resources on the Web.
Namespace structure
Identifiers conform to the URN syntax defined in RFC 8141 and have the form:
urn:solid:<namespace-specific-string>
Identifiers are opaque and must not be assumed to be dereferenceable without an appropriate resolution mechanism (see Resolution).
The namespace-specific string is partitioned into two surfaces:
- Bare form (
urn:solid:<Name>) is reserved for vocabulary terms.urn:solid:Person,urn:solid:knows,urn:solid:Authorizationare all of this form. The bare form is, by convention, the implicittermsubspace. - Subspaced form (
urn:solid:<subspace>:<identifier>) is used for everything else. Examples a deployment might define:urn:solid:agent:<id>for an agent identifier,urn:solid:msg:<id>for a message,urn:solid:resource:<id>for an application-level object.
Subspace names are reserved by the same process used to assign vocabulary terms. The set of registered subspaces is part of this specification.
Scope
Identifiers in this namespace are used for:
- Vocabulary terms — stable names that reference existing RDF classes and properties (e.g.
urn:solid:Person→foaf:Person), providing a uniform naming surface across heterogeneous upstream vocabularies. Such identifiers do not assert canonical equivalence or replace existing vocabulary IRIs, but may be used by applications as stable references to them. - Logical resources, agents, and application-level objects whose identity should persist independently of any particular origin or transport.
This namespace does not require all Solid resources or vocabularies to use urn:solid.
Resolution
Resolution is application-defined. A urn:solid identifier may be mapped to one or more concrete identifiers, such as HTTP URIs, WebIDs, or other schemes.
The namespace does not define a global resolution protocol. Resolution behaviour may vary by deployment without affecting the identity of the URN.
Persistence and assignment
Identifiers in the urn:solid namespace are intended to remain stable once accepted and are not expected to be reassigned. Assignment is managed through an open process with public documentation and review.
The namespace may distinguish between provisional and stable identifiers as part of its assignment process. The current vocabulary-term registry tracks this with a per-term status field.
Governance
The namespace is maintained through open community processes, with specification, discussion, and change tracking conducted in public repositories and forums associated with the W3C Solid Community Group.
Use cases
- Signed data — content whose identity must outlive its current hosting URL.
- Cross-protocol references — identifiers cited from non-HTTP transports (Nostr, Matrix, IPFS, local storage).
- Agent-based systems — stable identifiers independent of transport, suitable for relayed or stored-and-forwarded messages.
- Local-first applications — software that operates offline or with intermittent connectivity, where binding identity directly to a URL is insufficient.
- Agent and LLM interoperability — providing a stable naming surface that remains consistent despite vocabulary churn, multiple registries, or changing HTTP identifiers.
Relationship to HTTP URIs
urn:solid is not a replacement for HTTP URIs. Where dereferencing via HTTP is required, HTTP URIs remain the appropriate choice. The urn:solid namespace is intended for cases where identifier stability across contexts is required independently of any specific location.
Compatibility
urn:solid identifiers are valid JSON-LD 1.1 IRIs and may appear in any position a JSON-LD IRI is permitted (@id, @type, predicates, values).
The bare-form vocabulary terms are intended to function as a default vocabulary surface for JSON-LD documents and JSON-LD subsets such as Linked Objects (LION). Specifically:
Processors requiring RDF compatibility — that is, processors that emit or consume JSON-LD, RDF/Turtle, or any other RDF serialisation — SHOULD assume
@vocab: "urn:solid:"as the default vocabulary unless an explicit@contextis supplied.
This gives JSON-shaped data formats a stable, vocabulary-agnostic surface for RDF interoperability without forcing any single upstream vocabulary on document authors. Each urn:solid term carries an owl:sameAs mapping to its canonical upstream IRI (foaf:, schema:, dcterms:, etc.), which RDF consumers resolve via this registry.
Status
This is an early draft. Implementations may experiment with the namespace. The companion registry at urn-solid.github.io is the operational implementation of the vocabulary-term portion of the namespace. Feedback and proposals are welcome via the issue tracker.