Can I attempt to broker peace between Ian and Kingsley in this discussion? :-)

Because it seems to me that they are fundamentally agreeing with each other,
though considering different aspects of the problem. Kingsley is taking a very
broad view, Ian is addressing a specific aspect of best practices around Linked
Data in the TimBL design document/HTTP/RDF sense of the word.

Whether it's a mandate or a best practice, it is clear to me that the consensus
of general guidance on the web around Linked Data advocates the httpRange-14
distinction between 200/IR and 303/NIR(maybe) approach. So Ian's attempt to
simplify this to make implementing a best practice approach to Linked Data
easier seems a worthwhile discussion to have.

On the broader scale of Linked Data, I broadly agree with Kingsley that
ultimately the technologies are less important than the concept. But to
implement it in practice, we need to apply at least one technology, and the
HTTP/RDF approach is currently the most widely applied.

I definitely agree with Ian that the 200/303 distinction is complicated to
explain to newcomers and adds an extra layer of effort in implementing Linked
Data. I'm convinced so far by Ian's argument that the sky would not fall in if
we return HTTP 200 together with descriptions of real world things in response
to an HTTP call to their identifier.

After all, it's just a convention that we need to agree on regarding how to
deliver bits of documentation around the web. I don't think it changes any
fundamental points about the semantics of RDF etc.

To try to bring the discussion back to Ian's original point - are there good
reasons that force us to stick with the more complicated 303 approach? If not,
then let's keep life simple and just return HTTP 200 for HTTP URIs of real world
things.

Bill