Contradictory or inconsistent statements

[kjetilk]

There's a problem that I've been thinking about that perhaps this panel might address: The potential for making statements that are contradictory to some central ideas of Solid. The simplest such example would be:

<> a ldp:NonRDFSource .

i.e. to say in RDF that the present resource is a not RDF. You could also have resources where the request itself is internally inconsistent between headers and body, e.g.:

PUT /foo HTTP/1.1
Content-Type: text/turtle
Link: <http://www.w3.org/ns/ldp#RDFSource>; rel="type"

@prefix ldp: <http://www.w3.org/ns/ldp#> .
<> a ldp:BasicContainer ;
     ldp:contains </bar/> .

This says that it is not a container, since the request URI does not end with a / and the headers are consistent (see solid/specification#301 ), but the body is really sneaky, because it tries to act as a container. I imagine that this is the kind of thing that attackers might try to confuse access control or something. I therefore think we should reject such things in a validation step.

It gets tricky, because I also think that the server should mainly concern itself with headers when deciding to reject or accept a request, but this makes it possible to add stuff that more body-oriented systems would find confusing.

I think this fits well with other validation-oriented work.

[ericprud]

I've imagined so far that [Non]RDFResource just says whether you enable parsing, validation and PATCH. If we take a libertarian view, the user is free to store e.g. {grammar,schema}-invalid Turtle files (with a .ttl extension) by associating them with a NonRDFResource Shape Tree. That would probably push any warnings like "this smells like an LDP Container" into informal heuristics in client apps.

As a thought exercise, what would it look like to implement Solid over the interop ecosystem, where each successive layer's control data is considered NonRDFResources by the layer below?

[elf-pavlik]

@csarven I think we should move this issue to the specification repo. It seems related to other existing 'protected statements' like containment and resource metadata statements.