W3C home > Mailing lists > Public > public-webid@w3.org > February 2013

Re: Problem with Hash based Linked Data URIs

From: Melvin Carvalho <melvincarvalho@gmail.com>
Date: Sat, 16 Feb 2013 12:10:39 +0100
Message-ID: <CAKaEYhKs8b7GM+iQXq1SgcmW+7AYbaY7FN59r7=LQ9MsA2JMYg@mail.gmail.com>
To: Kingsley Idehen <kidehen@openlinksw.com>
Cc: public-webid@w3.org
On 15 February 2013 23:43, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> All,
> This is a simple FYI that can be added to the collection of material about
> why Hash based HTTP URIs aren't perfect. Basically, this also relates to
> the persistence of the warning notice re. Hashless URIs in the WebID spec,
> at the current time.
> See: http://bit.ly/XcTP9R .
> Problem:
> The SPARQL query results URL resolves to a document bearing the SPARQL
> query solution (or resultset). As you can see, there's a single column of
> HTTP URIs that are really Web-scale Super Keys (one of the many powerful
> aspects of Linked Data). If you click on one of the URIs you won't resolve
> to the description of the entity denoted by the hash HTTP URI, instead,
> you'll end up with the entire Good Relations ontology.

Hi Kingsley, just trying to understand the problem better.  When I click,
http://purl.org/goodrelations/v1#BusinessEntity it takes me to the section
of the GR vocab that is related to BusinessEntity (via html anchors).  What
should it be doing?

> If I flip this demo around and work with a localized data, the problem
> goes away, but that requires a specialized kind of application where
> de-reference is localized, and when I say that, it has nothing to do with
> cache invalidation, since the presentation of the data requires some app.
> logic.
> See: http://kingsley.idehen.net/**describe/?url=http%3A%2F%**
> 2Fpurl.org%2Fgoodrelations%**2Fv1%23BusinessEntity<http://kingsley.idehen.net/describe/?url=http%3A%2F%2Fpurl.org%2Fgoodrelations%2Fv1%23BusinessEntity>.
> Henry/Andrei:
> I am now giving you a "deceptively simple" demonstration of this problem.
> I have a very simple goal here: help you really understand why the notice
> is an unnecessary distraction. If you refute this point, there's a very
> simply why to nullify my claims. Make an application or simple demo that
> refutes these demos.
> BTW -- here's the same thing for DBpedia : http://bit.ly/VnNlrI . As per
> the GoodRelations example, click on the hashless HTTP URI based Super Keys.
> That's what this kind of URI facilitates.
> --
> Regards,
> Kingsley Idehen
> Founder & CEO
> OpenLink Software
> Company Web: http://www.openlinksw.com
> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
> Twitter/Identi.ca handle: @kidehen
> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
Received on Saturday, 16 February 2013 11:11:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:49 UTC