Re: hash in WebID - cachability problem

On 2 Dec 2012, at 16:36, Kingsley Idehen <kidehen@openlinksw.com> wrote:

> On 12/2/12 7:02 AM, Henry Story wrote:
>> kidehen: neither Linked Data, WebID nor the AWWW are about Tabulator or any other product for that matter. There's no news about the challenges posed to the Tabulator extension and Firefox combo. That's too solution specific to be used as an argument about staying with AWWW and TAG findings re., standards that affect other Web-scale Linked Data endeavors.]
> 
> The record, it should read:
> 
> kidehen: neither Linked Data, WebID nor the AWWW are about Tabulator or any other product for that matter. There's no news about the challenges posed to the Tabulator extension and Firefox combo. That's too solution specific to be used as an argument *against* staying with AWWW and TAG findings re., standards that affect other Web-scale Linked Data endeavors .
> 
> I'll correct the Wiki doc.

Thanks Kingsely. I do agree with you that the point you are responding to above has
to be filled out in more detail.

But now I wonder how that fits with  Ted Thibodeau's position on the KeyChain [1]. If 
I take your argument above and replace Tabulator by OSX Keychain bug
( as shown in this picture http://tinyurl.com/cpbpcqe  ) we get the following:

>  neither Linked Data, WebID nor the AWWW are about the KeyChain or any other product for that matter. There's no news about the challenges posed to clicking on the SAN of the Apple OSX Keychain. That's too solution specific to be used as an argument *against* staying with IETF findings re., standards that affect other Web-scale Linked Data endeavors .


Assuming that the clicking on the OSX keychain SAN URI is not more important than the Tabulator
Project, as far as Linked Data goes, then it seems that your argument above (which I think is a good
one - and which TimBL needs to address  in more detail than I was able to do) requires you
to apply that argument back to your OSX keychain. 

Henry


[1] see http://www.w3.org/2005/Incubator/webid/wiki/WebID_Definition/hash#Arguments_Against_Proposal_1
namely:
[[
Ted Thibodeau

	• The Keychain Access.app in Mac OS X takes any SAN that includes a #, and visually presents it correctly. But when you click on that URI (the textual string of which you cannot select and copy), your browser loads the URI with %23 in place of the # -- e.g., Keychain Access.app displayshttp://twitter.com/TallTed#this locally, but when I click it, my browser (observed with both Firefox and Safari; no reason to think any other would behave differently) tries to load http://twitter.com/TallTed%23this -- which correctly 404s. Now, this is clearly a bug in Mac OS X and/or Keychain Access.app -- but this is a very widely deployed tool which demonstrates the folly of forcing a particular URI pattern for WebID. (This is an argument against both MUST and SHOULD for hash-URI.)
]]

Kingsley added a picture of this KeyChain
 https://dl.dropbox.com/u/11096946/WebID/keychain-http-hash-versus-slash-uri-issue-interop-showcase.png


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

Social Web Architect
http://bblfish.net/