Re: hash in WebID - cachability problem

On 12/3/12 5:56 AM, Henry Story wrote:
>
> On 2 Dec 2012, at 20:24, Kingsley Idehen <kidehen@openlinksw.com 
> <mailto:kidehen@openlinksw.com>> wrote:
>
>> On 12/2/12 12:25 PM, Henry Story wrote:
>>> 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 picturehttp://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] seehttp://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.appdisplayshttp://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 loadhttp://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
>>>
>>>
>>
>> The problem: interoperability with what exists.
>>
>> Tabulator: an extension for Firefox and Chrome browsers that enables 
>> Linked Data browsing and RWW based CRUD.
>
> We still have to see what the issues are here. It seems that the 
> cacheability problem pointed out by Nathan
> would affect all JavaScript applications, not just tabulator
>
> [[
>
> RFC 2616 says:
> "The 303 response MUST NOT be cached, but the response to the second 
> (redirected) request might be cacheable."
>
> HTTPBis says:
> "A 303 response SHOULD NOT be cached unless it is indicated as 
> cacheable by Cache-Control or Expires header fields."
>
> Of course most tooling will not cache 303s as it's been a MUST NOT for 
> 13+ years.
> ]]
>

You cache data.

User agents don't cache entity names.

Using DBpedia as an example, you don't cache 
<http://dbpedia.org/resource/Linked_Data>, you cache: 
<http://dbpedia.org/page/Linked_Data>, assuming the HTML representation 
of the entity description is what you are interested in. Same applies to 
all the other representations of the description of: 
<http://dbpedia.org/resource/Linked_Data> .

>
>
>>
>> Keychain and Mac Mail: native Mac OS X applications used my Mac OS X 
>> users, by default.
>>
>>
>> Tabulator is used by a microscopic minority of end-users, if one 
>> seeks to be expansive about the Tabulator user profile.
>>
>> Keychain and Mac Mail: used by majority of Mac OS X users.
>>
>> Implications for hash based HTTP URIs:
>>
>> Tabulator developers and users: good experience.
>>
>> Keychain and Mac Mail users: bad experience due to the fact that both 
>> applications convert "#" to %23 when performing HTTP GET operations.
>
> If you cannot wait for the Apple KeyChain bug to be fixed, and you 
> believe that most of your application users go through this action, 
> then just redirect
>
> http://kingsley.idehen.name/dataspace/person/kidehen%23this
>
> to
>
> http://kingsley.idehen.name/dataspace/person/kidehen#this

I am sure you know that we know how to do that.

We are not every other developer or end-user on the Mac OS X platform, 
and I continue to tell yourself and others that my responses have 
nothing to do with our products. Basically, I doubt there is anyone in 
this discussion that's produced anything close to the Linked Data we 
published on the when since inception of the meme, across all 
conceivable formats, using any type of URI.

It isn't about OpenLink Software. It is all about developers and users 
of existing platforms. That's why this is repeatedly tagged as an 
"interoperability" issue.


>
>
>
>>
>> Solution: Don't use SHOULD in the definition of WebID to encourage 
>> developers to develop for hash based HTTP URIs. Instead, in line with 
>> TimBL's own Linked Data meme, use SHOULD for HTTP URIs.
>
> There are better solutions:
>  - send a bug report
>  - redirect the broken url: the user experience will be just right.

See my comments above.

>
>>
>> Benefits:
>>
>> 1. Mac OS X users (a massive installed base) don't encounter 
>> confusing WebID experience when reading emails that have WebID's 
>> included in the body (e.g, a mail indicating one's WebID or where it 
>> is used to denote an entity), ditto when viewing and then clicking 
>> them via Keychain
>>
>> 2. Tabulator developers and users *might* have an inconvenience when 
>> they encounter hashless HTTP URIs, but they are a distinct minority 
>> user profile
>
> If the tabulator issues are related to JavaScript in the browser then 
> this is the vast number of
> applications on the web that are going to have a problem.

Utter speculation.

>
>>
>> 3. Compatibility and consistency with the TimB's own Linked Data meme
>>
>> 4. Compatibility with TAG findings.
>
> The TAG does not set standards on 303 redirection cachability issues.

See my comments about entity names and data.


Kingsley
>
>>
>> -- 
>>
>> Regards,
>>
>> Kingsley Idehen	
>> Founder & CEO
>> OpenLink Software
>> Company Web:http://www.openlinksw.com
>> Personal Weblog:http://www.openlinksw.com/blog/~kidehen
>> Twitter/Identi.ca  <http://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/
>


-- 

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