validates fine on http://ttl.summerofcode.be/ and also using Jena's
@base <http://base1> . <a> <b> <c> . @base <http://base2> . <d> <e> <f> . <g> <h> <i> .
<http://base1/a> <http://base1/b> <http://base1/c> . <http://base2/d> <http://base2/e> <http://base2/f> . <http://base2/g> <http://base2/h> <http://base2/i> .
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