Solid Content Representation Spec
Note: This spec is a component of the parent Solid specification; the parent spec and all its components are versioned as a whole.
Table of Contents
The Resource Description Framework (RDF) is a framework for representing information on the Web, It was originally designed as a graph-based data model, where the core structure of the abstract syntax is a set of triples, each consisting of a subject, a predicate and an object.
Solid uses several serialization syntaxes for storing and exchanging RDF such as Turtle and JSON-LD. When creating new RDF resources, the preferred default serialization is Turtle. Solid-compliant servers should implement content negotiation in order to handle different serialization formats.
A very important aspect of Solid revolves around naming resources, and keep the namespaces consistent across both the Web and local file systems.
Our motivation is threefold:
Aspect: app developers care about URLs -- i.e.
Portability: resources should still resolve after being exported/imported into different servers. For instance, if Server A decides to store RDF resources as Turtle files, then Server B needs to be able to understand and use those resources (including doing content negotiation on them -- i.e. serve JSON-LD even though the resource is stored as a Turtle file).
Direct mapping: the URLs map directly to the file system resources -- i.e.
Servers must support the HEAD method for reading data. This returns a list of
headers related to the resource in question. Among these headers, two very
Link headers contain pointers to corresponding ACL and metadata
resources. More information on naming conventions for these resources can be
found in the Authorization and Access Control
HEAD /data/ HTTP/1.1 Host: example.org
HTTP/1.1 200 OK .... Link: <https://example.org/data/.acl>; rel="acl" Link: <https://example.org/data/.meta>; rel="describedby"
The metadata (extra RDF triples such as types, titles, comments, and so on) about non-RDF resources (e.g. containers, images, binaries, etc.) will be stored in a corresponding meta resource.
The metadata resource is a "special" type of resource, which is not publicly listed by the server when browsing files (typically when doing a GET on an LDP container). However, it can still be modified by client apps using the methods described in this section. The corresponding metadata resource is advertised through a Link header having rel="describedby", which can be discovered when doing HTTP GET/HEAD on regular resource, as mentioned before in case of ACLs. The naming of a meta resource is also arbitrary and may change from one server implementation to another.
For example, the corresponding metadata resource for a container called /data/
may be accessible through this URI:
Alternatively, the photo at
https://example.org/data/image.jpg may have it's
metadata stored in
https://example.org/data/image.jpg.meta. The following is an
example of a typical request.
GET /data/ HTTP/1.1 Host: example.org
Link: <https://example.org/data/.meta>; rel="describedby"