TermResource.html
10.3 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
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
<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>
A Short History of "Resource" - Design Issues
</title>
<link rel="Stylesheet" href="di.css" type="text/css" />
<meta http-equiv="Content-Type" content="text/html" />
</head>
<body>
<address>
Tim Berners-Lee<br />
Date: 2009/08/02, last change: $Date: 2009/08/05 20:36:28
$<br />
Status: Personal view only. This was sent as an email in a
discussion on the TAG list. There had been a lot of
discussion of this of course in the TAG, and in the AWWSW
task force, and a proposal to start a new task force in this
space.
</address>
<p>
<a href="./">Up to Design Issues</a>
</p>
<hr />
<h1>
A Short History of "Resource" in web architecture.
</h1>
<p class="asbstract"></p>
<p>
There has been a lot of confusion from a wide varying uses
use of this term for various different historical reasons,
leading to uses which are sometimes ambiguous and in places
inconsistent. This article attempts to shed light on the
issue.
</p>
<p>
Historically, URIs were used to point to thinks like web
pages and files and movies, on the web, useful documents, or
"online resources" in the sense of useful things out there.
FTP. Gopher and HTTP sites served up various types of online
resources. People got used to http://example.com/ being a web
page and http://example.com/#contact being an anchor within
it.
</p>
<p>
The Online Information community, into whose domain the web
stuff was put for standardization at the IETF, referred to
these things like web pages as resources, and changed the
original "D" for "Document" in "UDI" to "R". Some felt that
resource was more appropriate term, maybe because "document"
wasn't wide enough to include things like movies.
</p>
<p>
Now the URI spec actually allowed URIs for completely
different things, such as telephone end points, and wisely
the URI spec does not make any arbitrary constraint on what a
resource should be, especially a resource denoted by a URI in
a new scheme to be invented.
</p>
<p>
Meanwhile, the HTTP spec was polished and elaborated
basically as a document delivery system, plus other methods
for updating documents, plus POST. (POST started historically
as a way of introducing a new web page y posting it to a
list, just as in NNTP. It then almost immediately got used as
a catch-all extension method. I will ignore it in this
overview).
</p>
<p>
There was no real definition of what a resource or document
was -- maybe because it seemed obvious. The HTTP spec did not
even specify whether the URI denoted a person or a document
about them, it just explained that the thing returned
representation of the resource.
</p>
<p>
Roy's REST work then came along to formalize HTTP as REST and
declared that a resource was a time-varying mapping between
URI and representation. That was good enough for HTTP. It
didn't have enough for the AWWW, when it came along, to be
able to describe how the web worked.
</p>
<p>
In fact, the AWWW document, to explain how to use the web
properly, had to add in a bunch of stuff about the social
expectations -- things like, yes, the mapping from URI to
representation is a function of time, but not just any old
one -- a random function is not typically very useful. There
are expectations about it can change with time. Persistence,
consistency, with various common patterns which allow the web
to be a useful medium. The AWWW decided to use the term
"Information Resource" for a thing like a web page which
contains information, and "Resource" for any old thing at
all.
</p>
<p>
So HTTP and the REST work of was done very much in this space
of document delivery, editing and update. There was no
philosophical need to talk about what he URI denoted (the
person, the web page about the person) until RDF came along,
when there was an immediate need.
</p>
<p>
When RDF was first developed, it was motivated by the need
for data about resources very much in the online information
sense: data about documents, or 'metadata'. In fact it was
designed to be able to describe anything, but many early
users of RDF referred to it as metadata technology. RDF used
the word "resource" rather awkwardly in fact as it turned
out. In the beginning, many of the things being described
were documents, and so the online information meaning of
resource made sense. But in fact in RDF the resource was
allowed to be anything at all. A class, rdf:Resource even
used the term as the universal class of all things. A little
later, the Web Ontology Language decided to use Thing for
that.
</p>
<p>
RDF came along in what I think was a neat way. It used
completely existing web protocol extension devices to
introduce a new system which was fundamentally different from
the old HTTP+HTML one. The HTML web was a hypertext model,
which pages and anchors. The RDF model was a knowledge
representation one of arbitrary things. It did this by using
the fact that a new language can define whatever it likes as
what a local identifier denotes. A graphic language might use
local identifier to denote lines and points. HTML used local
identifiers to identify hypertext anchors. RDF used them to
identify arbitrary concepts, people, whatever.
</p>
<p>
The web architecture gave all these languages a common way of
building a global identifier for the thing denoted by a local
identifier in a given document. The semantics of the hash
sign are defined web-wide to mean that "a#b" can be used to
denote whatever is denoted by "b" in the document denoted by
"a".
</p>
<p>
Worked a treat. At the beginning of the century, people
played around and gave all kinds of things URIs like
"http://example.com/ foo.rdf#color". Some of us did lots of
work and made all kinds of systems which exchanged and
integrated data in this way.
</p>
<p>
Two snags occurred, as the years passed. One was that a bunch
of RDF users got the fact that it was good to use HTTP URIs,
but didn't get the fact that you should put the foo.rdf
online so that people can look up what #color means in it.
And as they didn't do that, they didn't actually bother with
the "#" at all. The second fly in the ointment was that some
people wanting to use RDF for large systems found that they
didn't want to use the "#". This was sometimes because the
number of things defined in the same file was too low (like
1) or too large (like a million) and it was difficult to
divide up the information into middle-sized chunks. Or they
just didn't like the "#" because it looks weird. But for one
reason or another people demanded the right to be able to use
http://example.net/people/Pat to denote Pat rather than a web
page about Pat.
</p>
<p>
This potentially led to huge failures in the whole RDF world,
with systems already built which just used
"http://example.net/people/ Pat" to identify the document
whether you like it or not. I among others pushed back
against using non-hash URIs for arbitrary things his but
eventually gave in.
</p>
<p>
So in response to this, the HTTP protocol was, in fact,
changed.
</p>
<p>
The spec wasn't changed. The spec editors were not brought on
board to the new model. The spec was interpreted. The TAG
negotiated in a way a truce between the existing HTTP spec,
RDF systems, and people who wanted to use HTTP URIs without
"#" to identify people. That truce was HTTPRange-14, which
said that yoiu don't <i>a priori</i> know that a hashless HTTP URI
denoted a document, but if the server responded with a 200
then you did, and you had a representation of the document.
If you did a get on one of these new URIs which identified
things were not documents (people, RDF properties, classes,
etc) them the server must not return 200, it can return 303
pointing to a document which explains more.
</p>
<p>
So the HTTP protocol was, effectively, changed. The HTTP
protocol as extended now allows HTTP to be used not only for
Documents but for arbitrary Things. It extends the set of
things which you can ask a web server about from documents to
anything. It isn't a very bad design, nor very beautiful.
Other designs would have worked, but that one was the only
one which didn't have major problems for some community. It
could be extended, but basically it works. It would be very
expensive to reverse it in terms of systems which have been
deployed.
</p>
<p>
It is also very expensive to go on debating it as though it
is an open issue. It is reasonable to try to make the
documents more consistent.
</p>
<p>
Anyway, that is a simplified version of the history of all
this as I saw it.
</p>
<p>
I would like to see what the documents all look like if
edited to use the words Document and Thing, and eliminate
Resource. That's my best bet as to two english words which
mean as close as we can get to what we want. Note however
that the web is a new system, a design in which new concepts
are created, so we can't expect english words to exist to
capture exactly the concepts. So we take those nearby and
abuse them as little as we can as far as we can tell at the
time, and then write them in initial caps to recognize that
that is what we have done
</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>