Problem with Hash based Linked Data URIs

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.

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.

-- 

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