W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: Is 303 really necessary?

From: Kingsley Idehen <kidehen@openlinksw.com>
Date: Thu, 04 Nov 2010 10:13:30 -0400
Message-ID: <4CD2BF8A.1040302@openlinksw.com>
To: Ian Davis <me@iandavis.com>
CC: public-lod@w3.org
On 11/4/10 9:22 AM, Ian Davis wrote:
> Hi all,
> The subject of this email is the title of a blog post I wrote last
> night questioning whether we actually need to continue with the 303
> redirect approach for Linked Data. My suggestion is that replacing it
> with a 200 is in practice harmless and that nothing actually breaks on
> the web. Please take a moment to read it if you are interested.
> http://iand.posterous.com/is-303-really-necessary
> Cheers,
> Ian

Q: Is 303 really necessary?

A: Yes, it is.

Why? Read on...

What's the problem with having many options re. mechanics for 
associating an HTTP based Entity Name with a Descriptor Resource Address?

We shouldn't be narrowing options for implementing the fundamental 
essence of Linked Data -- hypermedia based data representation. Of 
course, we can discuss and debate individual, product, or organization 
preferences etc.. But please lets not push these as mandates. We should 
never mandate that 303's are bad, never. Its an implementation detail, 
no more no less.

The only thing that should be mandatory re. Linked Data is this:  HTTP 
based Entity Names should Resolve to structured Descriptors that are 
Human and/or Machine decipherable.

Ironically, bearing in mind my comments, we do arrive at the same 
conclusion, but in different ways. I phrase my conclusion as: heuristics 
for implementing HTTP based Entity Names that Resolve to structured 
Descriptor Resources shouldn't dominate the Linked Data narrative, 
especially as comprehension of the fundamental concept remains mercurial.



Kingsley Idehen	
President&  CEO
OpenLink Software
Web: http://www.openlinksw.com
Weblog: http://www.openlinksw.com/blog/~kidehen
Twitter/Identi.ca: kidehen
Received on Thursday, 4 November 2010 14:14:00 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC