Re: Problem with Hash based Linked Data URIs

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.

Kingsley
>
> 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/
>>


-- 

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