Re: Problem with Hash based Linked Data URIs

On 16 Feb 2013, at 18:13, Melvin Carvalho <melvincarvalho@gmail.com> wrote:

> 
> 
> On 16 February 2013 18:08, Henry Story <henry.story@bblfish.net> wrote:
> 
> On 16 Feb 2013, at 17:47, Kingsley Idehen <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> 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.
> 
> A profile with a large number of public keys?  

Thanks Melvin for pushing towards a concrete example. Let us take a very unlikely case of
a Profile with a large number of public keys. So how are 303s not going to make things slower?
Can you show me how you would organise the profile in such a way that the 303 is just as efficient as the equivalent # based scheme? My guess is that it will always require one HTTP connection more than the equivalent #based scheme.

This should be easy to do. Tell me what goes approximately into which file, where they are, what gets sent back.

Something like this would be great
   http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal

But I think it should be a lot simpler in this case.


>  
>   2. The above does not seem to be a problem for the adoption of the GoodRelations ontology
>   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.
> 
>  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.
> 
>> 
>>>  
>>> 
>>> 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 

Social Web Architect
http://bblfish.net/