Re: hash in WebID - cachability problem

On Dec 2, 2012, at 12:25 PM, Henry Story wrote:

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

Suggesting that "it's hard(er) to implement some functionality
when WebID permits non-hash URIs" is not the same as saying "this 
tool does this troublesome thing when WebID uses a hash URIs".


As Nathan says --
> [[
>> 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.
> ]]


Initial RFC 2616 client sequence is --

1. dereference <http://dbpedia.org/resource/Linked_Data>
2. receive 303 to <http://dbpedia.org/page/Linked_Data> 
   (note that intervening machinery doesn't cache this result, 
   and client proceeds to --)
3. dereference <http://dbpedia.org/page/Linked_Data>
4. receive document 
   (note that intervening machinery caches *that*, associated 
   with <http://dbpedia.org/page/Linked_Data>, and *not*
   with <http://dbpedia.org/resource/Linked_Data>)

Future RFC 2616 sequence --

1. dereference <http://dbpedia.org/resource/Linked_Data>
2. receive 303 to <http://dbpedia.org/page/Linked_Data>
3. dereference <http://dbpedia.org/page/Linked_Data>
4. receive 200 OK and previously cached document

The differences under HTTPbis are relatively small.  The 303 
result *might* be cached -- *if* Cache-Control or Expires header
say so -- and so a few machine interactions might be saved, but
the end result will be the same.


Now, in the WebID world, which the above isn't quite...

When I dereference the /page/ URI, I get a document back.
That document could include statements like --

   <http://dbpedia.org/resource/Linked_Data>
      :describedBy
         <http://dbpedia.org/page/Linked_Data>

-- and, depending on my WebID-aware application, and interaction
with the user, and other decisions, I might make note of that -- 
such that in future, my default lookup is not 
<http://dbpedia.org/resource/Linked_Data>, but the document
which I know to describe that entity, i.e.,
<http://dbpedia.org/page/Linked_Data>.


Henry, you said:
"HttpBis requires cache control headers"

That's not accurate.  HTTPbis *allows* Cache-Control and 
Expires headers to be taken into account when decisions are
made about whether or not to cache a 303 result.

Will DBpedia-on-Virtuoso include those headers in future?  

All but guaranteed, once HTTPbis reaches sufficient stability, 
and this update gets high enough on our implementation priority 
list for Virtuoso.

(Note -- "DBpedia" is not the same as "OpenLink", but the public
server face of DBpedia is mostly Virtuoso...)


You also say,
"If the dbpedia folks can't even get these basic engineering 
right..."

by which you're really targeting OpenLink and Virtuoso, of
which fact I'm sure you're aware.

Now let me be clear.  "Basic engineering" means conformance with
today's active standards and specifications.

Today's active standard is HTTP 1.1 -- not HTTPbis.

To my mind, "basic engineering" also includes basic efficiency -- 
i.e., leave out that which is not necessary.  Lighten the load 
you're putting on shared infrastructure as much as you can.

Cache-Control and Expires headers are not relevant to 303s, 
under HTTP 1.1 -- so why would we include these in the traffic 
we put across the net, today?


I think I'm all caught up on this thread now.... 

Ted



--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Senior Support & Evangelism  //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
         10 Burlington Mall Road, Suite 265, Burlington MA 01803
     Weblog   -- http://www.openlinksw.com/blogs/
     LinkedIn -- http://www.linkedin.com/company/openlink-software/
     Twitter  -- http://twitter.com/OpenLink
     Google+  -- http://plus.google.com/100570109519069333827/
     Facebook -- http://www.facebook.com/OpenLinkSoftware
Universal Data Access, Integration, and Management Technology Providers