Re: Identifying thing resources

Surely you cannot know a description of a resource before you load it.
But you can use semantics to infer possible types, instead of
designing new HTTP conventions.

E.g. if you have a relation foaf:knows <document#person>, the it is
clear that the resource is not a document (because foaf:knows
rdfs:range foaf:Person), even before you dereference the URI.

In general, the client cannot make a final decision on how to display
a resource before its description is loaded. It can assume and infer
beforehand, but the actual description might contradict the
assumption.

So if you want to render a lot of links correctly, you will need to
issue a lot of HTTP requests to do that.

On Sat, Dec 3, 2016 at 11:38 PM, László Lajos Jánszky
<laszlo.janszky@gmail.com> wrote:
> 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 Sunday, 4 December 2016 00:28:16 UTC