W3C home > Mailing lists > Public > public-webid@w3.org > February 2013

Re: Problem with Hash based Linked Data URIs

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Sat, 16 Feb 2013 12:08:38 -0500
Message-ID: <511FBD16.8030007@openlinksw.com>
To: public-webid@w3.org
On 2/16/13 10:46 AM, J├╝rgen Jakobitsch wrote:
> if the redirect is worth being mentioned in the spec as a performance
> issues, i would assume that it should also be mentioned in the spec
> that potentially people need to download huge amounts of data if
> hash-based uris are used in the wrong way.

Amen!

>
> please note that i would not put any performance debate into the spec at
> all.

Exactly why dropping the unnecessary notice is a simple and extremely 
important resolution to this distracting problem.

Kingsley
>
> wkr j
>
> On Sat, 2013-02-16 at 16:08 +0100, Melvin Carvalho wrote:
>>
>> On 16 February 2013 15:33, Adrian Gschwend <ktk@netlabs.org> wrote:
>>          On 16.02.13 12:10, Melvin Carvalho wrote:
>>          
>>          > 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?
>>          
>>          
>>          That's only because you requested it from a web browser, if
>>          you get that
>>          as RDF (via rapper for example) it will make a request to
>>          http://purl.org/goodrelations/v1 and instead of giving you the
>>          answer to
>>          what you really want to know  (#BusinessEntity) it downloads
>>          the whole
>>          ontology which according to rapper is 1834 triples. Everything
>>          after the
>>          # is handled client side and does not even get through the
>>          webserver.
>>          
>>          This is not handy at all when you start to write code, you get
>>          way more
>>          than you wanted to know and it gets harder to implement local
>>          caching
>>          for example. Did that done that, really no fun to implement
>>          properly
>>          with hash based URIs.
>>          
>>          So I'm really no fan of hash based URIs either, especially on
>>          bigger
>>          ontologies/datasets.
>>
>> Tabulator handles this quite well in that it will filter on the data
>> item that you requested.
>>
>> Sure if the author has chosen to make a large page you'll pull in a
>> lot of data.
>>
>> Isnt that true on the normal web tho?  You could have a million images
>> on a web page, but it's probably not a good idea...
>>   
>>          
>>          cu
>>          
>>          Adrian
>>          
>>          
>>          
>>          
>>          
>>          --
>>          Adrian Gschwend
>>          @ netlabs.org
>>          
>>          ktk [a t] netlabs.org
>>          -------
>>          Open Source Project
>>          http://www.netlabs.org
>>          
>>


-- 

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






Received on Saturday, 16 February 2013 17:09:01 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:05:49 UTC