RE: What would break, a question for implementors? (was Re: Is 303 really necessary?)

Hi Nathan - thanks for clear answer. I see the point and also the argument for using hash URIs with ontologies.

In practice how I get round this prob is to preload my triple store with the handful of common ontologies I know I'm going to use, so don't need to deref them as I go along.

Cheers

Bill


-----Original Message-----
From: Nathan [mailto:nathan@webr3.org]
Sent: Fri 11/5/2010 1:12 PM
To: bill.roberts@planet.nl
Cc: public-lod@w3.org; Dan Brickley
Subject: Re: What would break, a question for implementors? (was Re: Is 303   really necessary?)
 
bill.roberts@planet.nl wrote:
> Hi Nathan
> 
> I'm not saying you're wrong - but could you explain why it would be a pain for FOAF terms to return 200?  Which kinds of application are dereferencing those terms and relying on a 303 response?
> 
> eg  http://xmlns.com/foaf/0.1/Person currently 303s to http://xmlns.com/foaf/spec/
> 
> What would break if http://xmlns.com/foaf/0.1/Person returned that same content with a status code of 200?
> 
> Just trying to understand the issue

Hi Bill,

Good question :)

If you consider a basic linked data client, with a basic ontology/schema 
awareness, for instance one which shows peoples FOAF profiles and uses 
the nice rdfs:label's for properties rather than "foaf:Person".

It's going to have to GET the ontology, now when it cycles through the 
properties it'll find http://xmlns.com/foaf/0.1/Person and GET it, then 
hopefully cache it against the URL specified in the [content?] location 
of the final request (be that 1 or many requests). When you 200 OK the 
response then the ontology will be stored against 
http://xmlns.com/foaf/0.1/Person so when you hit 
http://xmlns.com/foaf/0.1/knows you need to do another GET, and be 
returned a full ontology again, thus you end up with 40+ requests with 
full responses and 40+ cached versions of the single ontology. Unless 
you code around it in some way, make a provision for FOAF.

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.

The above, together with the deployment for FOAF is a v good reason 
*not* to use slash URIs for ontologies - ask Dan Bri about the FOAF 
rewrite rules for a second opinion on that :p

Hope that explains,

Best,

Nathan