HTTP-URI2.html
4.54 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content=
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org" />
<title>
What do HTTP URIs Identify? - Design Issues
</title>
<link rel="Stylesheet" href="di.css" type="text/css" />
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii" />
</head>
<body bgcolor="#DDFFDD" text="#000000" xml:lang="en" lang="en">
<address>
Tim Berners-Lee<br />
Date: 2005-06-09, last change: $Date: 2006/10/29 17:19:39
$<br />
Status: personal view only. Editing status: first draft. This
was written when the W3C Technical Architecture group
responded TAG issue HTTPRange-14. This resolves the question
originally addressed in a previous <em><a href=
"HTTP-URI.html">What to HTTP URIs Identify</a></em> note.
</address>
<p>
<a href="./">Up to Design Issues</a>
</p>
<hr />
<h1>
What HTTP URIs Identify
</h1>
<h2>
<a name="Abstract" id="Abstract">Abstract</a>
</h2>
<p>
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 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.
</p>
<h2 id="Introducti">
Introduction
</h2>
<p>
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 Dublin Core project, one of the
first RDF vocabularies, and later Friend of a Friend, and
various others simply used HTTP URIs to identify RDF
Properties. 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. The author
wrote a long <em>Design Issues</em> note about this, <a href=
"HTTP-URI.html">What do HTTP URIs Identify?</a>. The reader
is directed to read that if more detail of the arguments is
needed.
</p>
<p>
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.
</p>
<h3 id="Resolution">
Resolution
</h3>
<p>
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. Of course, it is a general principle of web
architecture that it is useful to serve information to those
that look up a URI. In the case that the URI is not intended
to be used for an information resource.
</p>
<p>
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.
</p>
<hr />
<p>
<a href="Overview.html">Up to Design Issues</a>
</p>
<p>
<a href="../People/Berners-Lee">Tim BL</a>
</p>
</body>
</html>