Re: Hash vs Hashless URIs

I don't deny the fact that hash URIs have their advantages and I personally
prefer them too for WebID, but I don't see the need to set that in stone
wrt to WebID URIs. Like I said before, who knows what new mechanism will
come out of the TAG or elsewhere 2 years down the road? Mandating hash URIs
means that any kind of innovation in the realm of WebID will be impossible
without breaking the spec.

Can't we agree on the following compromise? => only use hash URIs in the
non-nominative examples. This is leave for innovation down the road, in the
meantime most people can follow the hash routes unless they prefer some
other way.

Does mandating "hash URIs only" provide any advantage in terms of
implementing a WebID verifier? A verifier would still rely on HTTP to
dereference the WebID URI, and follow any redirect if necessary. What are
the advantages from a verifier standpoint? How does it make is simpler than
just any kind of URI?

Steph.

On Mon, Nov 19, 2012 at 6:16 PM, Melvin Carvalho
<melvincarvalho@gmail.com>wrote:

>
>
> On 19 November 2012 23:58, Kingsley Idehen <kidehen@openlinksw.com> wrote:
>
>> All,
>>
>> To understand this old problem please read: http://www.w3.org/TR/2007/WD-
>> **cooluris-20071217/#hashuri<http://www.w3.org/TR/2007/WD-cooluris-20071217/#hashuri>.
>>
>> Important point to note, this matter ultimately becomes a permathread
>> whenever a spec attempts to pick one style over the other.
>>
>> The solution to these kinds of problems stem back to biblical stories,
>> such as the one illustrating the wisdom of Solomon re. splitting a disputed
>> baby in half.
>>
>> HTTP URIs are "horses for course" compliant. It is always best to keep
>> them that way when designing specs for HTTP based solutions.
>>
>
> Thanks
> "Conclusion.Hash URIs should be preferred for rather small and stable
> sets of resources that evolve together. An ideal case are RDF Schema
> vocabularies and OWL ontologies, where the terms are often used together,
> and the number of terms is unlikely to grow much in the future.
>
> Hash URIs without content negotiation can be implemented by simply
> uploading static RDF files to a Web server, without any special server
> configuration. This makes them popular for quick-and-dirty RDF publication.
>
> 303 URIs should be used for large sets of data that are, or may grow,
> beyond the point where it is practical to serve all related resources in a
> single document.
>
> If in doubt, it's better to use the more flexible 303 URI approach.
> "
>
> Will try and digest this a bit more.  I may still be missing something but
> if you have a paradigm of one data item per page and call it #, like
> facebook do, I'm still trying to see the advantage of 303s.  As pointed
> out, facebook is not a small data set.
>
>>
>> --
>>
>> Regards,
>>
>> Kingsley Idehen
>> Founder & CEO
>> OpenLink Software
>> Company Web: http://www.openlinksw.com
>> Personal Weblog: http://www.openlinksw.com/**blog/~kidehen<http://www.openlinksw.com/blog/~kidehen>
>> Twitter/Identi.ca handle: @kidehen
>> Google+ Profile: https://plus.google.com/**112399767740508618350/about<https://plus.google.com/112399767740508618350/about>
>> LinkedIn Profile: http://www.linkedin.com/in/**kidehen<http://www.linkedin.com/in/kidehen>
>>
>>
>>
>>
>>
>>
>


-- 
Steph.