Re: Hash vs Hashless URIs

On 11/19/12 6:36 PM, Stéphane Corlosquet wrote:
> 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?

+1 .

Again.

Kingsley
>
> Steph.
>
> On Mon, Nov 19, 2012 at 6:16 PM, Melvin Carvalho 
> <melvincarvalho@gmail.com <mailto:melvincarvalho@gmail.com>> wrote:
>
>
>
>     On 19 November 2012 23:58, Kingsley Idehen <kidehen@openlinksw.com
>     <mailto:kidehen@openlinksw.com>> wrote:
>
>         All,
>
>         To understand this old problem please read:
>         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/%7Ekidehen>
>         Twitter/Identi.ca handle: @kidehen
>         Google+ Profile:
>         https://plus.google.com/112399767740508618350/about
>         LinkedIn Profile: http://www.linkedin.com/in/kidehen
>
>
>
>
>
>
>
>
>
> -- 
> Steph.


-- 

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