-
Notifications
You must be signed in to change notification settings - Fork 0
Solid & LDP Concepts
solid.drive is built on a stack of open web standards that can feel unfamiliar if you come from a traditional client-server background. This glossary explains each concept in plain terms: what it is, why it exists, and how solid.drive uses it.
A WebID is a globally unique URI that identifies a person or agent on the web. When dereferenced, it returns an RDF document (the profile) that describes the person: their name, avatar, contacts, Pod storage locations, and inbox.
solid.drive uses WebIDs to resolve display names, discover where a user’s Pod storage lives, and identify contacts in the sharing workflow. Everywhere you see a "contact" in the app, what is actually stored is their WebID URI.
A Solid Pod is a personal online data store that implements the Solid Protocol. It exposes resources (files, RDF documents, and containers) over HTTP using standard LDP and WAC semantics.
The key difference from a traditional file host is ownership: the user controls the Pod, not the application. solid.drive can read and write to your Pod, but it never holds a copy of your data and cannot access it without your authenticated session.
LDP defines a standard HTTP-based API for creating, reading, updating, and deleting RDF resources and container hierarchies.
- LDP BasicContainer
-
A folder-like resource that contains other resources. solid.drive creates one BasicContainer per uploaded file to keep the binary and its metadata document together in one addressable unit.
- LDP Resource
-
Any non-container resource: a binary file, an RDF document, or an ACL file.
- LDP Inbox
-
A special container used as a message box. solid.drive writes access request messages to a contact’s inbox and reads incoming messages from the authenticated user’s own inbox.
WAC is the permission system used by most Solid servers.
Access rules are stored in .acl files that live alongside the resources they govern.
Each rule specifies a set of agents (by WebID) and the modes they are permitted.
Modes: acl:Read · acl:Write · acl:Append · acl:Control
In solid.drive, sharing a file adds an acl:Read rule for the recipient’s WebID to the file container’s .acl.
Revoking access removes that rule.
The per-contact shared catalog also has its own .acl that restricts access to that contact exclusively.
Solid OIDC extends OpenID Connect to work with Solid.
The user authenticates with their identity provider (e.g. solidcommunity.net) and receives a DPoP-bound access token that proves Pod ownership to any Solid server, without sharing credentials with the application.
From solid.drive’s perspective, Solid OIDC is handled by the @ldo/solid library.
The app never sees your password; it only receives a token scoped to your Pod.
DCAT is a W3C vocabulary for describing datasets and data catalogs in RDF.
solid.drive maintains a catalog.ttl at the Pod storage root with one dcat:Dataset entry per uploaded file.
This makes the Pod’s contents discoverable and queryable by any Solid application that can read linked data. The catalog is not a private index; it is a first-class linked data resource.
schema.org is a widely-adopted vocabulary for describing things on the web.
solid.drive uses schema.org classes and predicates to describe uploaded files in index.ttl, giving each file a machine-readable type, title, upload date, publisher, and format.
This means your files are not just bytes with a name; they are semantically typed resources that other applications can understand and filter.
ShEx is a language for describing and validating the structure of RDF graphs, conceptually similar to JSON Schema but for linked data.
solid.drive uses two ShEx shapes in src/.shapes/:
-
solidProfile.shexdescribes the fields of a Solid WebID profile the app needs to read -
catalogEntry.shexdescribes the metadata fields stored in each file’sindex.ttl
These shapes are compiled to typed TypeScript objects by the LDO generator, so RDF data can be read and written with full type safety.
SHACL is a W3C standard for validating RDF graphs against a set of constraints. Where ShEx describes the shape of data you read, SHACL enforces the quality of data you write.
solid.drive loads SHACL constraints from public/tbox.ttl when the upload form opens.
If the user’s metadata does not satisfy the constraints (missing title, upload date, or publisher), the upload is blocked and the missing fields are surfaced inline.
No invalid metadata reaches the Pod.
@ldo/solid is the TypeScript library solid.drive uses to interact with RDF resources on a Solid Pod. It generates typed JavaScript objects from ShEx shapes, so you can read and write Pod data with the same ergonomics as a plain TypeScript object, without writing SPARQL or manually parsing Turtle.
All generated bindings live in src/.ldo/ and are regenerated by running npm run build:ldo.