Re: Problem with Hash based Linked Data URIs

On 2/16/13 12:08 PM, Henry Story wrote:
>
> On 16 Feb 2013, at 17:47, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto:kidehen@openlinksw.com>> wrote:
>
>> 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> .
>
> A few points:
>
>   1. Our spec is dealing with WebID profiles, not the generic issue, 
> so please try to find an example that works with Profiles.

The spec defines a WebID . You don't place notices of the kind you have 
in such a spec.

When dealing with WebID-TLS you have an opening to discuss the 
implications of HTTP URI preferences since access to profile data is an 
essential part of the protocol.

>   2. The above does not seem to be a problem for the adoption of the 
> GoodRelations ontology

Tell that the Google and all the major retailers that use GoodRelations. 
Likewise, pass the message on to all of those using FOAF etc..

>   3. You have the same problem with 303s in another famous vocabulary 
> called foaf. In foaf each foaf vacabulary URI redirects to the foaf 
> spec, which takes just as long to download. So now you have the so 
> called problem of GoodRelations + one redirect for each vocabulary item.

GoodRelations and FOAF are widely used. You are the only one 
complaining. The impracticality of your comments is growing 
exponentially, with each of your responses. Please rewind back to the 
problem at hand: you have an unnecessary notice inserted into a spec, 
driven by your personal preferences. You've done this by exploiting 
editorial control etc..

If you are so confident about the wisdom of your actions, put it to a 
vote. I brazenly predict you will lose that vote!

>
>  Essentially it will be easy for me to show you that whatever example 
> you give me you can have the same problem with 303s, + you'll have the 
> redirect slowdown.
>
>  That is why that text remains in the spec.

Nonsense, and you know it.

Go make a Linked Data application. Until you've done that, don't lecture 
those that have built, shipped, and received payments for Linked Data 
useful products.

Kingsley
>
>>
>>>
>>>     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 <http://www.openlinksw.com/>
>>>     Personal Weblog: http://www.openlinksw.com/blog/~kidehen
>>>     <http://www.openlinksw.com/blog/%7Ekidehen>
>>>     Twitter/Identi.ca <http://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  <http://Identi.ca>  handle: @kidehen
>> Google+ Profile:https://plus.google.com/112399767740508618350/about
>> LinkedIn Profile:http://www.linkedin.com/in/kidehen
>>
>>
>>
>>
>
> Social Web Architect
> http://bblfish.net/
>


-- 

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