Re: Problem with Hash based Linked Data URIs

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> <http://purl.org/goodrelations/v1>just to find out about
> <http://purl.org/goodrelations/v1#BusinessEntity><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?


>   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
>
>
>> --
>>
>> 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
>>
>>
>>
>>
>>
>>
>
>
> --
>
> 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
>
>
>
>
> Social Web Architect
> http://bblfish.net/
>
>