Add payload and representations in RDF

[csarven]

Initial requirement on Representations. This particular requirement involves issues:

• Required RDF serializations for Solid #45
• Specify/advise semantics of default Container resources (index.html/.ttl) #69
• Representation URLs and interactions #109
• PUT RDFa, then GET turtle #195

Will update this space to include related issues.

Feedback on making this more readable is most welcome.

[bblfish]

There seems to be another question which is if a PUT of Turtle doc is done at <foaf.ttl>, should the <> refer to <foaf.ttl> or to the content negotiable <foaf>? Should clients rather PUT at <foaf>, and have <foaf.ttl> be linked to from there? The same question for jpegs and image formats and video formats (minus the relative URI problems, unless some of them have metadata support).

[michielbdejong]

The way it currently works in Solid is that if you PUT turtle to https://example.com/profile/card, then that is its URL. You can then fetch it as Turtle or as JSON-LD or as human-viewable HTML at https://example.com/profile/card (or https://example.com/profile/card#me within that document). At no point is there any need to access the Turtle and JSON-LD (which is what we call "representation of the resource" right?) at a URL different from https://example.com/profile/card.

[csarven]

@bblfish I've raised something similar in #69 (comment) in context of container representations. The suggested practice for clients to not explicitly set base URI in the document, however, if set, it should refer to container's URI (as opposed to a representation URL).

Should clients rather PUT at , and have <foaf.ttl> be linked to from there?

Yes. Some implementations may expose representation URLs (covered in issue #109 ) but we want writes to go through the preferred content negotiable URI of the resource (ie. <foaf>). So, GET /foaf with Accept: text/turtle may get a response including Content-Location: /foaf.ttl. I've updated this PR covering what's in 109.

Note https://tools.ietf.org/html/rfc7231#appendix-B :

The definition of Content-Location has been changed to no longer
affect the base URI for resolving relative URI references, due to
poor implementation support and the undesirable effect of potentially
breaking relative links in content-negotiated resources.
(Section 3.1.4.2)

So, if /foaf.ttl includes <> (or equivalent in other RDF syntaxes), GET /foaf's response with Content-Location: /foaf.ttl entails that when the document is parsed <> refers to URI ending /foaf.

Edit: As there is no guarantee that the content of a representation embeds a base URI (ie. using the resource URI) - unless server injects a base URI without conflicts - clients could potentially obtain a RDF graph from the representation that is not isomorphic with the RDF graph obtained from the resource URI. Without redirect or setting base URI, what's possible to avoid different graphs? Would rel=canonical on the representation be meaningful/helpful? Alternatively, would a simple non-normative text for clients to bear this in mind be sufficient?

[csarven]

@michielbdejong Issue #109 raised whether implementations may advertise representation URLs through Content-Location. FWIW, servers are not forbidden from advertising representation URLs, so if some servers expose them, how should read and write operations work? The agreement was that write requests targeting the representational URL should be done through the URI of the resource.

[michielbdejong]

OK then it's #109 I disagree with :)

[csarven]

@michielbdejong On the contrary, we agree on the same requirement: clients should target the resource URI for write operations.

Two approaches for Solid where both would conform to RFC 7231 (Content-Location is optional for servers and clients):

1. Servers and clients MUST NOT use Content-Location.
2. Servers MUST redirect (eg. 307, 308 - this PR) or fail (eg. 405) in response to write requests on representation URLs.

Solid servers MUST implement the server parts of RFC 7231 and Content-Location still remains optional. Disallowing Content-Location seems like a significant limitation (approach 1) in comparison to specifying what should happen when server uses Content-Location (approach 2).

Open to alternative approaches or an update to what's proposed.

[michielbdejong]

Yes, approach 2 is fine.

[csarven]

Great, thanks all! All approved, feedback and objections addressed.