HTTP URIs, in the web architecture, have been used to denote documents -- "web pages" informally, or "information resources" more formally. However, with the growth of the Semantic Web, which uses URIs to denote anything at all, the urge to use and practice of using HTTP URIs for arbitrary things grew steadily. [...] The result was that one could no longer be sure that an HTTP URI was intended to identify the web page one got when one used the URI in a browser. In fact, there was a danger of confusion is one party used the URI for an abstract concept and another used it for the web page. [...] This whole issue caused, until 2005, a lot of discussion in technical circles, and much heated debate. In June 2005, the TAG resolved the issue as a function of the runtime protocol response. Basically, the argument is that if you have used a URI to get a web page, then you can use the URI to identify the Information Resource which is that web page: For example, the New York Times home page, or this page you are reading now. [...] The TAG resolution effectively extends the range of things one can use HTTP URIs. However, it does not allow one to simply serve a web page at a URI which is used for something else. [...] The W3C Technical Architecture group eventually decided to resolve the architectural problem that if an HTTP response code of 200 (a successful retrieval) was given, that indicated that the URI indeed was for an information resource, but with no such response, or with a different code, no such assumption could be made. This compromise resolved the issue, leaving a consistent architecture.