Solid support for preserving the structure of RDF resources at user request

[phochste]

Pitch

Create support so that Solid can be used to preserve resources with structural guarantees, irrespective if the content is RDF or non-RDF. This is not always the case, when uploading resources that have RDF, they could end up in RDF storage backends (e.g. SPARQL database) that don't keep whitespace, comments, etc ... all things that are not part of the RDF graph are lost. In some scenarios this behaviour is not desired:

• users editing human readable RDF formats such as Turtle (which allows for comments). The Turtle a user stores in a Solid pod with a SPARQL backend storage is not the same (the same layout) as the Turtle that is returned.
• digital preservation of datasets.A collection with hundreds of files needs to be stored on a pod. Some of the files are binary formats, some in RDF formats, a manifest file is available that has the checksum of all files in the dataset. Moving this collection to a Solid pod without knowing how the RDF files are stored in the backend would break fixity checks, file size checks and preservation techniques would become dependent on the storage strategy of the Solid pods.

We need a way to indicate for some types of RDF resources that they need to be stored and retrieved as-is, without any transformation that would break the structure of the resources, without allowing RDF updates such as PATCH (that can't give structural guarantees).

Desired solution

• When uploading data to a Pod a special profile (urn:tbd:preserve) can be added to content-type that indicates that structural guarantees should be met when storing the file (or return an error when no storage method can be found providing such guarantees).
• Resources with the special profile should keep their structure.
• These special resources could still be interpreted as RDF in some way, but should disallow operations that break their structure (e.g. no PATCH).

Acceptance criteria

• When I upload a file with the urn:tbd:preserve profile the Solid should store it (or return an error, that no such support can be provided)
• The (MD5,SHA...) checksum of the file uploaded should match with checksum after the files has been retrieved from the pod (provided that the files was not overwritten by other actions).
• PATCH operations (or other operations) on the resource that break the structure return an error.

Pointers

See also: solid/specification#342

Scenarios

[RubenVerborgh]

Relevant: https://ruben.verborgh.org/articles/fine-grained-content-negotiation/