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
