Re: Identifying thing resources

Struggling with email a little... This was my response:

On Sun, 4 Dec 2016 at 01.27, Martynas Jusevičius <martynas@graphity.org>
wrote:

> 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.
> >>>
>