Re: Identifying thing resources

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