Re: Problem with Hash based Linked Data URIs

On 16 February 2013 18:29, Henry Story <henry.story@bblfish.net> wrote:

>
> On 16 Feb 2013, at 18:13, Melvin Carvalho <melvincarvalho@gmail.com>
> wrote:
>
>
>
> 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?
>
>
> Thanks Melvin for pushing towards a concrete example. Let us take a very
> unlikely case of
> a Profile with a large number of public keys. So how are 303s not going to
> make things slower?
> Can you show me how you would organise the profile in such a way that the
> 303 is just as efficient as the equivalent # based scheme? My guess is that
> it will always require one HTTP connection more than the equivalent #based
> scheme.
>
> This should be easy to do. Tell me what goes approximately into which
> file, where they are, what gets sent back.
>
> Something like this would be great
>    http://www.w3.org/2012/ldp/wiki/Issue-34_-_Aggregation:_simple_proposal
>
> But I think it should be a lot simpler in this case.
>

Hi Henry, perhaps this is drilling down into too much detail.  I'm not
advocating 303s, merely replying to your request for a case where a profile
may contain multiple triples.

In fact, I'm in favour of # URIs, BUT i dont see any evidence that this
notice will have the desired effect.  Sometimes telling someone not to do
something is the best way to get them to do the opposite, especially with
the hash vs slash debate.

I think the WebID spec will be stronger all round with the notice removed,
as it's one less thing to worry about, all the examples are already # so
it's kind of a tautology.  IMHO, a shorter spec is a better spec.


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