Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add payload and representations in RDF #196

Merged
merged 7 commits into from Oct 11, 2020
Merged

Conversation

csarven
Copy link
Member

@csarven csarven commented Sep 4, 2020

Initial requirement on Representations. This particular requirement involves issues:

Will update this space to include related issues.

Feedback on making this more readable is most welcome.

@csarven csarven added this to the ~First Public Working Draft milestone Sep 4, 2020
@csarven csarven added this to Drafting in Specification via automation Sep 4, 2020
@bblfish
Copy link
Member

bblfish commented Sep 4, 2020

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).

@csarven csarven force-pushed the feature/representations branch 2 times, most recently from d73e25c to f4598ba Compare Sep 5, 2020
@michielbdejong
Copy link
Contributor

michielbdejong commented Sep 6, 2020

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
Copy link
Member Author

csarven commented Sep 6, 2020

@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
Copy link
Member Author

csarven commented Sep 6, 2020

@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
Copy link
Contributor

michielbdejong commented Sep 6, 2020

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

main/resource-access.bs Outdated Show resolved Hide resolved
@csarven csarven force-pushed the feature/representations branch from 4d88586 to 658dc4c Compare Sep 12, 2020
@csarven
Copy link
Member Author

csarven commented Sep 13, 2020

@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.

main/resource-access.bs Outdated Show resolved Hide resolved
@michielbdejong
Copy link
Contributor

michielbdejong commented Sep 23, 2020

Yes, approach 2 is fine.

@csarven csarven merged commit 568370c into master Oct 11, 2020
2 checks passed
Specification automation moved this from Drafting to Done Oct 11, 2020
@csarven
Copy link
Member Author

csarven commented Oct 11, 2020

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Specification
  
Done
Development

Successfully merging this pull request may close these issues.

None yet

7 participants