Abstractions.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
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
<html xmlns="http://www.w3.org/1999/xhtml"
xmlns:foaf='http://xmlns.com/foaf/0.1/'
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:dc='http://purl.org/dc/elements/1.1/'
xmlns:ical='http://www.w3.org/2002/12/cal/ical#'
xmlns:vcard='http://www.w3.org/2001/vcard-rdf/3.0#'
xmlns:talk='http://www.w3.org/2004/08/Presentations.owl#'
>
<head>
<!--
<rdf:RDF
xmlns:foaf='http://xmlns.com/foaf/0.1/'
xmlns:rdf='http://www.w3.org/1999/02/22-rdf-syntax-ns#'
xmlns:dc='http://purl.org/dc/elements/1.1/'
xmlns:ical='http://www.w3.org/2002/12/cal/ical#'
xmlns:vcard='http://www.w3.org/2001/vcard-rdf/3.0#'
xmlns:talk='http://www.w3.org/2004/08/Presentations.owl#'
>
<rdf:Description rdf:about="">
<dc:title>Layers of Abstractions: Net, Web, Graph</dc:title>
<dc:date>2007-10-23</dc:date>
</rdf:Description>
<foaf:Person rdf:about="http://www.w3.org/People/Berners-Lee/card#i">
<foaf:name>Tim Berners-Lee</foaf:name>
<foaf:homepage rdf:resource="http://www.w3.org/People/Berners-Lee/"/>
<foaf:made rdf:resource=""/>
</foaf:Person>
</rdf:RDF>
-->
<title>Abstractions in Web architecture - Design Issues</title>
<link rel="Stylesheet" href="di.css" type="text/css" />
<meta http-equiv="Content-Type" content="text/html" />
</head>
<body>
<address>
<span rel="foaf:maker" resource="http://www.w3.org/People/Berners-Lee/card#i" typeof="foaf:Person">
<a property="foaf:homepage" href="http://www.w3.org/People/Berners-Lee/">
<span property="foaf:name">Tim Berners-Lee</span>
</a>
</span>
<br />
Date: <span property="dc:date">2007-10-23</span>,
last change: $Date: 2010/06/15 13:54:51 $<br />
Status: personal view only. Editing status: draft.
Written in response to another round of circular discussions
of web architecture.
</address>
<p>
<a href="./">Up to Design Issues</a>
</p>
<hr />
<h1>
Levels of Abstraction: Net, Web, Graph
</h1>
<p style="text-align: center">
<img width="30%" align="left" src="diagrams/layers/link0.png"
alt="link level" />
</p>
<p>
Progress in communications technology has ben characterizsed
by a movement from lower to higher levels of abstraction.
</p>
<p>
When, first, computers were connected by telephone wires,
then you would have to run a special program to make one
connect to another. Then you could make the second connect to
a third, but you had to know how to use the second one. Mail
and news would be passed around by computters calling each
other late at night. Email addresses for a while contained a
list of computers to pass the message through
(timbl@mcvax!cernvax!cernvms)
</p>
<h3>
It's not the wires -- it's the computers
</h3>
<p style="text-align: center">
<img width="30%" align="right" src="diagrams/layers/net.png"
alt="net level" />
</p>
<p>
The ability to use this communication power between computers
wasn't powerfully useful until the Internet. The internet
allowed one to forget about the individual connections. It
was thought of as the "Internet Cloud". Messages went in and
appeared ad another computer, without (when things worked)
one having to worry about how they were broken into packets,
and the packets routed from computer to computer. The Domain
Name System gives computers names, and the TCP and IP
protocols allows a program on one computer to talk to a
program on another computer.
</p>
<p>
This made life very much easier. It takes the wires out of
the picture, and allows the programs to talk as though the
computers were directly connected.
</p>
<p>
Of course, when things went wrong, one did have to do run
diagnostic programs to find out whether the connection has
broken between one's own computer and the WiFi base unit, or
between that and the router, the cable modem, or somewhere in
the middle of the Internet, or at the other end. But that was
the exception.
</p>
<h3>
It's not the computers -- it's the documents
</h3>
<p style="text-align: center">
<img width="30%" align="left" src="diagrams/layers/web.png"
alt="web level" />
</p>
<p>
This power of communication between computers wasn't really
easily usable by normal people until the Web came along. The
realization of the web is: "It's not the computers which are
interesting, it is the documents!" The WWW protocols (URI,
HTTP, HTML) defined how documents could be sent between Web
servers and Web browsers.
</p>
<p style="text-align: center">
<img width="30%" align="right" src="diagrams/layers/web2.png"
alt="web level" />
</p>
<p>
Now the user is apparently in a web of interconnected
documents. She does not have to worry about how the protocols
work underneath, with two exceptions.
</p>
<p>
When things go wrong, she has to be able to figure out
whether it as a problem with her connection to the internet,
with the URI in the link she was following, or an error on
the server end. This involves looking under the hood. But
that is the exception.
</p>
<p>
There is another reason to be aware of what is happening. The
information you are browsing comes from a particular server,
whose name has registered against a particular person or
organization. The trust you put in that information is
related to who that organization is. It is the serving
organization which is responsible for keeping the URIs you
bookmark today alive tomorrow -- and some are better at it
than others. Phishing attacks succeed when people are fooled
into thinking it is an organiztion you trust when it isn't.
</p>
<p>
So the web is just a web of documents, except one one has to
lift the hood for debugging or questions of trust.
</p>
<p>
Note that the connection between the net of computers and the
web of documents is clear in the URI:
</p>
<pre>
http://acme.excample.com/products/machin/truc
_________________
</pre>
<p>
The computer owner name (acme.example.com) is part of the
name of the document. The Acme Example company is responsible
for supporting the document on the web.
</p>
<h3>
It's not the documents -- It's the things
</h3>
<p style="text-align: center">
<img width="30%" align="left" src="diagrams/layers/sweb2.png"
alt="graph level" />
</p>
<p>
The power of the web was still not totally used to its full
potential until the semantic web came along. The Semantic
Web's realization is: <em>It is isn't the documents which are
actually interesting, it is the things they are about!</em>
</p>
<p>
A person who is interested in a web page on something is
usually primarily interested in the thing rather than the
document. There are exceptions, of course -- documents are
certainly interesting in their own right. However, when it
comes to the business and science, the customers, the
products, or the proteins and the genes, are the things of
interest. A good Semantic Web browser, then, shows a user
information about the thing, which may have been merged from
many sources. Primarily, the user is aware of the abstract
web of connections between the things -- this person is a
customer who made this order which includes this item which
is manufactured by this facility ... and so on.
</p>
<p style="text-align: center">
<img width="30%" align="right" src=
"diagrams/layers/graph.png" alt="graph level" />
</p>
<p>
There are again the same two exceptions. When things go
wrong, the user must be able to look under the hood to see
whether the document was fetched OK but had missing data, or
the document was not fetched OK, in which case what was the
underlying web problem.
</p>
<p>
And again, when the user is looking at a bit of data in the
data view, perhaps a point on a map or a cell in a table,
then she must be able to see easily which document that
information came from.
</p>
<p>
Note that the connection between the web of documents and the
web of things is clear in the URI:
</p>
<pre>
http://acme.excample.com/products/machin/truc#part3
_____________________________________________
</pre>The name of the document is part of the name of the thing. A
given thing may have many URIs of course. But when URIS have this
form, it is clear that we are talking about a thing as described by
a given document. This is a gene as defined in the Gene Ontology.
This is a protein as defined in this taxonomy. A citizen as defined
by the Immigration and Naturalization Service glossary. And so on.
<p>
(There are (since 2005) URIS for things which are not
explicitly bound to a document. These require the server to
respond with the name of a suitable document at runtime. This
is more complicated)
</p>
<h2>
Conclusion
</h2>
<p>
The web of things is built on the web of documents, which is
built on the web of computers controlled by Domain Name
owners, which itself is build on a set of interconnected
cables. This is an architecture which provides a social
backing to the names for things. It allows people to find out
the social aspects of the things they are dealing with, such
as provenance, trust, persistence, licensing and appropriate
use as well as the raw data. It allows people to figure out
what has gone wrong when things don't work, by making the
responsibility clear.
</p>
<p>
The value of this architecture is that each layer leverages
the social components of the lower layer's 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>