- From: László Lajos Jánszky <laszlo.janszky@gmail.com>
- Date: Sat, 3 Dec 2016 00:07:55 +0100
- To: "public-hydra@w3.org" <public-hydra@w3.org>
Sorry that I am a little bit off topic here, but there are lot of RDF ppl. here helped to develop JSONLD, so I guess somebody is able to answer. I have a problem with the standard ways we handle thing resources. Afaik. we have 2 standard ways to identify thing resources. The first way to use fragment identifiers, so the URI with the fragment `/doc#thing` can identify the thing and the URI without the fragment `/doc` can identify the document which describes the thing (meta document hereafter). The other standard solution that by requesting the URI of the thing `/thing` we redirect the request with 301 to the URI of the meta document `/doc`. The problem with these two ways is that none of them provide any information about what we were requesting, they just simply give us the meta document, and we have no clue that we were requesting a thing and getting a meta document or we were just requesting a regular document. There can be scenarios where this difference really matters (at least I just have one). I was thinking about how to distinguish things from documents and I came up with a few possible solutions: a.) Don't use any of these standard approaches. Use 204 no content by requesting /thing and return a Link header to the meta document. I am not sure whether this meets the standards related to things, but I guess it doesn't. b.) Use the XHR fetch API, which contains manual redirect. This is cumbersome, since having a thing resource is not the only cause of HTTP redirection and the feature is not widely supported yet anyways. c.) Make a convention about the meta document. For example the meta document should contain a json-ld response with meta-document type. Another way to check whether the @id is the same URI we requested, or the rdf:about is the URI we requested. I don't think any of these are general solutions. d.) Make a convention about the link to the thing. So for example the thing link have /aThing link relation, while the documents have something different. This is not a general solution as well, for example in my case I need the link relation to describe the relationship between the document and the thing. Another problem that I don't know whether we are talking about the link before requesting the URI. Adding code to check that would make server side code much heavier, and I won't be able to add this info to every hypermedia type, e.g. by markdown I don't know a way of adding properties to hyperlink. My best hope is a.), but maybe you have a better solution, which meets the standard as well.
Received on Friday, 2 December 2016 23:08:28 UTC