Re: Identifying thing resources

Thanks Martynas, but this is the fragment identifier approach I
already wrote of. Currently I don't see any chance to make this work
without breaking the standard. :S

(I forgot to add hydra by the other answer.)

Maybe the question was not clear enough, I try again with an example.

We have 2 resources: `A` and `B`, and there is a relationship between
them, so `A-[r]->B`. Both A and B have meta documents: `mdA` and
`mdB`, which describe them, so `mdA-[d]->A` and mdB-[d]->B. We know
for certain that `A` is a document, but we don't know for certain what
`B` is, so it can be a thing, or it can be a document.

`A` contains this `A-[r]->B` connection, so if it is a hypermedia
(e.g. HTML, JSONLD, etc.) we will get a hyperlink too by displaying it
`<a href="B" relation="r" />`. By following that hyperlink if `B` is a
document, then we will end up displaying `B`, but if B is a thing,
then by both of the standard approaches we will end up by displaying
`mdB`, which is a known document describing `B`. The first standard
approach is the 301 + redirection, which looks like this: `GET B` =>
`301, Location: mdB` => `GET mdB`. The other standard approach is the
fragment identifier: `GET mdB#B`.

My problem that my clients needs to know that it is displaying `mdB`
or `B`, since `B` can be either a document or a thing.

 - I could inject that information into `A`, so it would know that the
link is leading to a thing, which will redirect to a meta document.
The problem that I cannot modify A.
 - Another option to merge somehow the meta document with the
resources they describe, so everything will have a meta envelope. This
could work, but I don't want to invent a new protocol, it would be
like a SOAP envelope.
 - Another option to use the not so prevalently supported XHR fetch
API, which can stop redirection. But still it does not describe why it
was redirected.

Every relatively good solution leads to breaking the standard, e.g.
not redirect if `B` is a thing, but return a Link header, or `B`
should have a meta representation which I can select with a Prefer
header, etc...

Hmm maybe modifying the displayed `A` by using the content of the
`mdA` can be the solution, since I can inject additional link info
into `mdA`, but not into `A`. That will result in two HTTP requests
instead of just one by loading `A`, but I can live with that.

2016-12-03 22:23 GMT+01:00 Martynas Jusevičius <martynas@graphity.org>:
> We use this approach:
>
> 1. Document
>
> <document> a foaf:Document .
>
> 2. Document + thing
>
> <document> a foaf:Document ;
>   foaf:primaryTopic <document#thing> .
>
> <document#thing> a owl:Thing ;
>   foaf:isPrimaryTopicOf <document> .
>
> Hope it helps.
>
>
> Martynas
> atomgraph.com
>
> On Sat, Dec 3, 2016 at 12:07 AM, László Lajos Jánszky
> <laszlo.janszky@gmail.com> wrote:
>> 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 Saturday, 3 December 2016 22:39:09 UTC