Re: Identifying thing resources

Thanks for the answers!

I thought about it last night, and I managed to solve this. Actually I
am working on a semantic storage, and from the example A and B were
the stored content or tag, while mdA and mdB were resource and
relationship descriptors. So for example A can be an article about
mathematics (a document), while B can be the concept of mathematics
(thing). The A-[r]->B relation represents in this case that the
article is about mathematics. The article does not need to be stored
as hypermedia, it can be plain text too. That was what helped, because
by plain text content I still have to represent the
article-[about]->mathematics relationship somehow. I can do this by
adding a div for tags, or I can replace every "mathematics", "math",
etc... terms in the article with a span, which displays a popup about
mathematics by mouse over.

2016-12-04 0:17 GMT+01:00 Melvin Carvalho <melvincarvalho@gmail.com>:
>
>
> On 3 December 2016 at 23:38, 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.
>
>
> Why not use fragment identifiers for all things, and documents to contain
> those things.
>
> Dont forget the 301 pattern (which many including me consider an anti
> pattern) was an amendment to the RDF spec.  I'd be happy to see it go
> unsupported, except for a few exceptions such as certain vocabs like FOAF,
> dcterms and dbpedia which have gained some traction.
>
>>
>>
>> 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 19:01:08 UTC