Re: Problem with Hash based Linked Data URIs

On 2/16/13 9:42 AM, 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.

Did you not realize in my example that I anticipated your comment above? 
I thought you would have spotted this URI 
<http://kingsley.idehen.net/describe/?url=http%3A%2F%2Fpurl.org%2Fgoodrelations%2Fv1%23BusinessEntity> 
which is basically a SPARQL DESCRIBE.

I really encourage you to write a Linked Data application that delivers 
what's shown above. As I already told you, there's stuff to find out 
about cache invalidation schemes and presumptions. Just attempt it, that 
will save a lot of time .

>   If you could send an SPARQL
> DESCRIBE query to the resource, you'd be fine, right?

See my comments above, why speculate when you can actually implement the 
SPARQL DESCRIBE or its equivalent?

>
> That sounds something that one should get the LDP group to specify.

Once again, that has nothing to do with the definition of a WebID which 
currently has an unnecessary notice about hash based HTTP URI 
preferences over hashless URIs. Just remove the notice since its an 
utterly unnecessary implementation detail.
>
> 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.

See my comments, none of your arguments, especially without actual code, 
justify the unilateral insertion of the HTTP URI preference notice in 
the current WeBID spec. Remove that and we are set. Keep it there, and 
you will only end up changing it later.

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