csarven on server-link-auxiliary-type
Apply suggestions from code rev… (compare)
csarven on main
Add missing subsections (compare)
csarven on main
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.
https://frederick.trinpod.us/@as subject, with this approach
https://frederick.trinpod.us/profile/card#mewould not be used any more
@elf-pavlik So completely removing #me from the picture would still be spec compliant as long as profile/card is in use? (My worry was that devs would hard code /profile/card#me)
if devs hardcode something like that their application wouldn't comply with the spec,
/profile/card#me is just convention specific to internal choice of one implementation, clients have to "follow their nose"
https://ontology.graphmetrix.com/node/as the base URI, but then
2is not a valid XML local name (needs to start with a letter)