Re: Identifying thing resources

Triples, but the project is in the early days. Maybe I later share
some parts of it on github.

2016-12-04 20:03 GMT+01:00 Melvin Carvalho <melvincarvalho@gmail.com>:
>
>
> On 4 December 2016 at 20:00, László Lajos Jánszky <laszlo.janszky@gmail.com>
> wrote:
>>
>> 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.
>
>
> Are you storing triples or quads?  Part of the reason for quads is to solve
> this problem.
>
>>
>>
>> 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:09:26 UTC