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:07:35 -0500
Message-ID: <511FBCD7.2040105@openlinksw.com>
To: public-webid@w3.org
On 2/16/13 10:42 AM, Jürgen Jakobitsch wrote:
> hi,
> please also note openlink's #this-uri-style, kingsley, correct me if i'm
> wrong, but the idea is to use hash-based uris that are also unique
> without the hash. that way a redirect is saved and you don't get a lot
> of data you are not interested in.

Yes, in a nutshell :-)

We've looked at this issue from a number of perspective and concluded: 
it has to be "horses for courses" when minting Linked Data URIs. The key 
thing is to implement the principles of Linked Data consistently rather 
than take a hard line for either style of HTTP URI.

> wkr turnguard
> On Sat, 2013-02-16 at 15:42 +0100, Henry Story wrote:
>> On 16 Feb 2013, at 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.
>> Ah. Really what is needed is that you be able to send a specifc query
>> to the graph to give you a subset of it. If you could send an SPARQL
>> DESCRIBE query to the resource, you'd be fine, right?
>> That sounds something that one should get the LDP group to specify.
>> Essentially you'll always have that problem with GET. You need to define
>> a different verb. I think something like the WebDAV SEARCH
>>    http://greenbytes.de/tech/webdav/rfc5323.html#METHOD_SEARCH
>> Or have a relation in the header to a search end point. The SEARCH
>> method or equivalent seems to me the correct way of doing it.
>> Henry
>>> cu
>>> Adrian
>>> -- 
>>> Adrian Gschwend
>>> @ netlabs.org
>>> ktk [a t] netlabs.org
>>> -------
>>> Open Source Project
>>> http://www.netlabs.org
>> Social Web Architect
>> http://bblfish.net/



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:07:59 UTC

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