csarven on main
Add server-auxiliary-resources-… Apply suggestions from code rev… Clarify server-auxiliary-resour… and 2 more (compare)
csarven on server-link-auxiliary-type
Make server-auxiliary-resources… (compare)
kjetilk on restrict-requirement
Remove requirement markup on fl… Fix typo in ID (compare)
Acceptheader, and check whether the returned Content-Type included either
application/ld+json, which is what we ended up doing: inrupt/solid-client-js#214. If it did not include those, then we treat it as a NonRDFSource.
/, so you don't need the
typeLink header for that. Unfortunately I'm not sure what are and are not it's use cases, I'm mostly just regurgitating what I got as answers when I asked the same question a while ago :)
typerelation is used for is indicating the creation of a container in a POST? Beyond that content-type and
/should be used to determine (from the client’s viewpoint) whether something is container or not or consumable as RDF?
I have a (potentially flawed) mental model of the general categories of resources:
I was asking for confirmation that the determination of RDF resources vs. Container was based on the
/ (which you confirmed above)
And that it is up to the client to determine RDF vs. non-RDF based on
Content-Type header — based on which content types the client can process as RDF.
Accept-Patch: application/sparql-update). The other clue is that the
Content-Typeheader will be an RDF syntax that the client understands
@Vinnl_gitlab You said "not send Accept header" was recommended but I don't see it at the link you've provided.
:point_up: January 4, 2021 9:18 PM @csarven I asked whether I can be sure that I won't get a Content Type of Turtle or JSON+LD if I didn't send an Accept header in the follow-up message, to which @acoburn responded affirmatively.
Accept-Patch: application/sparql-updateheader rather than such a Content-Type might be more explicit - at least in my case, I want to know whether such a PATCH will have the desired effect.
@Vinnl_gitlab RFC 7231:
A request without any Accept header field implies that the user agent
will accept any media type in response.
The Solid Protocol doesn't specify how servers should respond to requests without a Accept header. It is within server's right to reject or respond with an "appropriate" representation.
In the case of resources having an existing representation ie. can be represented with a concrete RDF syntax, then server must accept requests including Accept: text/turtle, application/ld+json. If no Accept header targeting those resources, server can indeed respond with something other than Turtle or JSON-LD.
Silent non-normative: servers might want to / maybe even encouraged to respond with Turtle or JSON-LD if it is "appropriate" (re RDFable resources) so that clients can presumably work with the response. But this is really edge-case territory because clients should indicate which media types they are able to accept.
There is no "default format" per se. Reasonable Variability.