- From: Nathan <nathan@webr3.org>
- Date: Fri, 05 Nov 2010 16:29:14 +0000
- To: Ian Davis <lists@iandavis.com>
- CC: bill.roberts@planet.nl, public-lod@w3.org, Dan Brickley <danbri@danbri.org>
Ian Davis wrote: > On Fri, Nov 5, 2010 at 12:12 PM, Nathan <nathan@webr3.org> wrote: >> However, if you use 303's the then first GET redirects there, then you store >> the ontology against the redirected-to URI, you still have to do 40+ GETs >> but each one is fast with no response-body (ontology sent down the wire) >> then the next request for the 303'd to URI comes right out of the cache. >> It's still 40+ requests unless you code around it in some way, but it's >> better than 40+ requests and 40+ copies of the single ontology. > > But in practice, don't you look in your cache first? If you already > have a label for foaf:knows because you looked up foaf:mbox a few > seconds ago why would you issue another request? to GET an authoritative response? But seriously, because it's the http message responses that are cached, you know the whole linked data follow your nose deference things approach, you just dereference and lean on HTTP Caching, the 303 on properties as done by FOAF doesn't allow this and is very non HTTP friendly, hence causing the problem at HTTP level. The work around and practical measures to circumvent, are do introduce a triple store in tot he equation and hit that first + assume what;s there is correct, or to make a hard coded map of HTTP URIs in your app for FOAF and pretty much ignore HTTP leaning on out of band knowledge, which get's rid of much of the point of using HTTP. Hope that clarifies, Best, Nathan
Received on Friday, 5 November 2010 16:30:34 UTC