Skip to content

Resources management

Linked Data Platform

Each Solid Pod must comply with the Linked Data Platform protocol. This is a REST-based API for managing containers and resources.


We support both JSON-LD and Turtle format.


We support the BasicContainer type, as required by the Solid specs.


We support non-RDF resources (binaries) uploads. The description of the resource is stored in the triplestore as a

a <> ;
<> "picture.jpg" ;
<> "uploads/files/picture.jpg" ;
<> "image/jpeg" .

There is an issue to use the Solid recommended metadata instead.

PATCH method

LDP resources and containers can be selectively modified using the HTTP PATCH method. This method is important because it limits the risk of overwriting data, as with the simpler PUT method. However, due to the way RDF resources are formatted, the PATCH method cannot be used like more regular REST-based APIs. Many solutions have been proposed in the semantic web community to solve this problem:

Initially, the recommended method for Solid servers was SparqlPatch and this is what we implemented. In 2021, it was switched to a new N3 Patch method, as described in the Solid spec. It is not yet a W3C standard.

Until the N3 Patch method is standardized, we will continue to use the SparqlPatch format.

SparqlPatch update to modify a LDP resource.
PATCH /alice HTTP/1.1
Content-Type: application/sparql-update
PREFIX as: <>
INSERT DATA { <> as:preferredUsername "Alice" . };
DELETE DATA { <> as:preferredUsername "ALICE" . };
SparqlPatch update to add or remove a resource from a LDP container.
PATCH /alice/data/events HTTP/1.1
Content-Type: application/sparql-update
PREFIX ldp: <>
INSERT DATA { <> ldp:contains <http://url/of/resource/to/attach>. };
DELETE DATA { <> ldp:contains <http://url/of/resource/to/detach>. };

LDP Prefer header

👷 To be implemented. (#1168)

LDP paging

👷 To be implemented. (#176)


In ActivityPub, ActivityStreams collections are frequently used to handle side-effects. For example, when a Follow activity is sent, the actor is added to the as:followers collection.

Collections have their own paging system. They can be ordered or unordered. Also, they can dereference the items they contain (this is the case for the inbox) or only display their URIs (like the as:followers collection).

Create custom collection

In SemApps, ActivityStreams collections can be POSTed as regular LDP resources. The target container should be /as/collection.

The @type can be a as:Collection or a as:OrderedCollection, depending on weither you need items to be ordered or not.

In the case of a as:OrderedCollection, you must also indicate the semapps:sortPredicate and semapps:sortOrder.

We have added a semapps:dereferenceItems in order to declare if the items should be dereferenced or not, and semapps:itemsPerPage to activate pagination.

"@context": [
"semapps": ""
"@type": "OrderedCollection",
"semapps:sortPredicate": "as:published",
"semapps:sortOrder": "semapps:DescOrder", // or "semapps:AscOrder"
"semapps:dereferenceItems": false,
"semapps:itemsPerPage": undefined // No pagination per default

There are discussions in the fediverse to specify these missing predicates.

Add or remove items

It’s possible to add items to (or remove items from) a collection using the SparqlPatch method, the application/sparql-update Content-Type and a SPARQL query like this on the body:

PREFIX as: <>
<> as:items <> .
<> as:items <> .

SPARQL endpoint

Even though it is not required anymore by the Solid spec, every Pod comes with an SPARQL endpoint, linked to the WebID with the void:sparqlEndpoint predicate.

Only SPARQL queries are supported, not SPARQL updates (You MUST use LDP or ActivityPub to modify data). WAC permissions are applied to all SPARQL queries, in order to return only the resources that the autenticated user or application has the right to see.