Re: Identifying thing resources

On 3 December 2016 at 22:23, Martynas Jusevičius <martynas@graphity.org>
wrote:

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

+1 I do this also

There is also a loose convention to commonly name the primary topic in a
document <#this>, similar to the 'this' keyword in javascript.

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