Re: Problem with Hash based Linked Data URIs

On 2/16/13 6:10 AM, Melvin Carvalho wrote:
>
>
> On 15 February 2013 23:43, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto: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?

It doesn't do that on Safari. It does so Chrome and I presume Firefox. 
Irrespective, the client has to load: http://purl.org/goodrelations/v1 . 
When using a hashless URI you don't have to retrieve 
<http://purl.org/goodrelations/v1> just to find out about 
<http://purl.org/goodrelations/v1#BusinessEntity> .

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

Hence the comments above.

There's a tradeoff irrespective of what kind of HTTP URI you adopt re., 
Linked Data .


Kingsley

>
>     -- 
>
>     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/%7Ekidehen>
>     Twitter/Identi.ca handle: @kidehen
>     Google+ Profile: https://plus.google.com/112399767740508618350/about
>     LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
>


-- 

Regards,

Kingsley Idehen	
Founder & CEO
OpenLink Software
Company Web: http://www.openlinksw.com
Personal Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca handle: @kidehen
Google+ Profile: https://plus.google.com/112399767740508618350/about
LinkedIn Profile: http://www.linkedin.com/in/kidehen