You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
346 lines
11 KiB
346 lines
11 KiB
<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>
|
|
Web Architecture: Generic Resources
|
|
</title>
|
|
<link href="di.css" rel="stylesheet" type="text/css" />
|
|
<link href="http://www.w3.org/2006/gen/ont" rel="related" />
|
|
<meta http-equiv="Content-Type" content="text/html" />
|
|
</head>
|
|
<body>
|
|
<p>
|
|
<a href="../TheProject.html"><img border="0" alt="W3c" src=
|
|
"../Icons/WWW/w3c_home.gif" width="72" height="48" /></a>
|
|
<!-- Find an icon for Design Issues
|
|
<IMG border=none SRC="../Icons/WWW/arch_48x48.gif" ALT="Design Issues">
|
|
-->
|
|
</p>
|
|
<p>
|
|
<i>This is a statement of achitectural principles behind my
|
|
thinking on web design. This was the thinking behind the
|
|
original HTTP content negotiation of 1992, and the vary=
|
|
fields in the URI: headers for example. It has been behind
|
|
W3C thinking on the OBJECT header for HTML and other issues.
|
|
- TBL, 1996</i>
|
|
</p>
|
|
<p>
|
|
<em>This is an important axiom of web design, which must be
|
|
understood for new designs to use URIs and HTTP properly. -
|
|
TimBL, 2000</em>
|
|
</p>
|
|
<p>
|
|
<a href="Overview.html">Up to Design Issues</a>
|
|
</p>
|
|
<p>
|
|
Axioms of Web Architecture: 3
|
|
</p>
|
|
<hr />
|
|
See also:
|
|
<ul>
|
|
<li>
|
|
<a href="../MarkUp/Resource/Specification">A proposal for
|
|
an HTML "Resource" element</a>
|
|
</li>
|
|
<li>
|
|
<a href="Formats.html">Historical web design note on
|
|
formats</a>
|
|
</li>
|
|
<li>
|
|
<a href="../Protocols/">HTTP overview by W3C</a>
|
|
</li>
|
|
</ul>
|
|
<h1>
|
|
Generic Resources
|
|
</h1>
|
|
<p>
|
|
A URI represents a <b>resource</b>
|
|
</p>
|
|
<p>
|
|
A "resource" is a conceptual entity (a little like a Platonic
|
|
ideal). When represented electronically, a resource may be of
|
|
the kind which corresponds to only one posisble bit stream
|
|
representation. An example is the text version of an Internet
|
|
RFC. That never changes. It will always ha the same checksum.
|
|
</p>
|
|
<p>
|
|
On the other hand, a resource may be <b>generic</b> in that
|
|
as a concept it is well specified but not so specifically
|
|
specified that it can only be represented by a single bit
|
|
stream. In this case, other URIs may exist which identify a
|
|
resource more specifically. These other URIs identify
|
|
resources too, and there is a relationship of genericity
|
|
between the generic and the relatively specific resource.
|
|
</p>
|
|
<p>
|
|
As an example, successively specific resources might be
|
|
</p>
|
|
<ol>
|
|
<li>The Bible
|
|
</li>
|
|
<li>The Bible, King James Version
|
|
</li>
|
|
<li>The Bible, KJV, in English
|
|
</li>
|
|
<li>A particular ASCII rendering of the KJV Bible in English
|
|
</li>
|
|
</ol>
|
|
<p>
|
|
Each resource may have a URI. The authority which allocates
|
|
the URI is the authority which determines wo what it refers:
|
|
Therefore, that authority determines to what extent that
|
|
resource is generic or specific.
|
|
</p>
|
|
<p>
|
|
This model is more of an observation of a requirement than an
|
|
implementation decision. Multilevel gnericity clarly exists
|
|
in all our current life with books and electronic documents.
|
|
Adoption of this model simply follows from the rule that Web
|
|
design should not arbitrarily seek to constrain life in
|
|
general for its own purposes.
|
|
</p>
|
|
<h2>
|
|
Dimensions of genericity
|
|
</h2>
|
|
<p>
|
|
When we discuss electronic resources, an interesting fact is
|
|
that a small number of dimensions of genericity emerge.
|
|
</p>
|
|
<table border="1" cellpadding="2">
|
|
<tbody>
|
|
<tr>
|
|
<td>
|
|
Time
|
|
</td>
|
|
<td>
|
|
A resource may vary with time. For example, "The Wall
|
|
Street Journal" varies with time. Each issue is a
|
|
time-specific resource, which does not change with
|
|
time. Most home pages on the Web change with time, in a
|
|
less periodic way.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
Language
|
|
</td>
|
|
<td>
|
|
When a document is translated, it is useful to be able
|
|
to refer to it either in the generic, or to a
|
|
particular specific translation.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
Content-Type
|
|
</td>
|
|
<td>
|
|
A given resource may have mny ways in which it can be
|
|
represented on the wire, using different
|
|
<tt>Content-type</tt>s (in HTTP terms). As an example,
|
|
an image may be represented in PNG or JFIF format.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td>
|
|
Target medium
|
|
</td>
|
|
<td>
|
|
A given resource may be targetted specifically to a
|
|
specific medium, such as a printer, being displayed on
|
|
laptop screen, being displayed on a cellphone, or being
|
|
projected onto a large screen for an audience. (This is
|
|
currenltly available for selecting CSS stylesheets, but
|
|
is not done at the HTTP content negotiation level)
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>
|
|
The fact that there are such a small number of dimensions
|
|
currently apparent sugests that Web software should handle
|
|
them individually in its interface with the user, even though
|
|
the architecure should handle them as a single concpet.
|
|
</p>
|
|
<h2>
|
|
Derivation
|
|
</h2>
|
|
<p>
|
|
When a document is translated, one of the language-specific
|
|
resources may have been the original source. However, this
|
|
need not always be the case. Specific resources may have been
|
|
derived from unrelated sources, or multiple sources.
|
|
Therefore, though it is interesting to be able to describe
|
|
the "derived-from" relationship, this is <em>not</em> part of
|
|
the genericity relationship. It is not discused further here.
|
|
</p>
|
|
<h2>
|
|
Genericity Metadata
|
|
</h2>
|
|
<p>
|
|
When making statements about resources, genericity leads two
|
|
types of statement. The examples use imaginary HTML elements
|
|
or HTTP headers as illustrations of the meaning.
|
|
</p>
|
|
<h3>
|
|
<a name="Dimensions" id="Dimensions">Dimensions</a>
|
|
</h3>
|
|
<p>
|
|
A statement about the genericity of an object is important
|
|
both for the user, and also for example for a cache manager.
|
|
This statment takes the form of a list of dimensions in which
|
|
the resource for a given URI is generic.
|
|
</p>
|
|
<p>
|
|
One proposal was the <tt>vary</tt> field in the <tt>URI:</tt>
|
|
header in HTTP:
|
|
</p>
|
|
<p>
|
|
<code>URI: http//foo.com/bar/baz vary=time,language</code>
|
|
This is a statement about the relationship between the URI
|
|
and the resource. (See also <a href=
|
|
"NameMyth.html#QoS">Quality of service of names</a>)
|
|
</p>
|
|
<h3>
|
|
Relationships
|
|
</h3>
|
|
<p>
|
|
The other statement which can be made is about a genericity
|
|
relationship between two resources. Typed links provide this
|
|
kind of statement. One proposal was
|
|
</p>
|
|
<pre>
|
|
|
|
<link rel="language-specific" href="baz.fr">
|
|
|
|
|
|
</pre>
|
|
<p>
|
|
which means "This resource is a language specific version of
|
|
this resource identified by baz.fr" This needs to be combined
|
|
in with information about the particualar language.
|
|
</p>
|
|
<pre>
|
|
|
|
<resource uri="baz.fr" vary="type, time">
|
|
<meta htp-equiv="content-language" value="Fr">
|
|
</resource>
|
|
|
|
</pre>
|
|
<p>
|
|
So much for the architectural ideas. In practice one would
|
|
use a shorthand form for all this information such as
|
|
</p>
|
|
<pre>
|
|
<specific language="fr" uri="baz.fr">
|
|
or
|
|
<specific language="fr" ct="text/html" uri="baz.fr.html">
|
|
|
|
</pre>
|
|
<h2 id="Using">
|
|
Using RDF to model this
|
|
</h2>
|
|
<p>
|
|
There is now an RDF ontology for these concepts, <a href=
|
|
"http://www.w3.org/2006/gen/ont">http://www.w3.org/2006/gen/ont</a>.
|
|
The ontology does not describe the target-medium dimension.
|
|
(Please use that instead of the old one desribed here in
|
|
2000-09.)
|
|
</p><!--
|
|
<h2 id="UsingOld">Old ontology RDF to model this</h2>
|
|
<address>
|
|
Added 2000/09
|
|
</address>
|
|
|
|
<p></p>
|
|
|
|
<p>Now that the RDF metadata architecure is developed, we can model genericity
|
|
using a set of properties to represent these relationships. The natural way to
|
|
do this is to define classes for the one-parameter flags such as
|
|
time-invariant, language-invariant, etc and properties such as
|
|
isLangaugeSpecificVersionOf.</p>
|
|
|
|
<table border="1">
|
|
<caption>Classes</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th>Class name</th>
|
|
<th>Significance</th>
|
|
</tr>
|
|
<tr>
|
|
<td>u:TimeInvariant</td>
|
|
<td>The relationship between a representation of this resource and the
|
|
URI will not change over time</td>
|
|
</tr>
|
|
<tr>
|
|
<td>u:LanguageInvariant</td>
|
|
<td>The relationship between a representation of this resource and the
|
|
URI will not change no matter what language is requested.</td>
|
|
</tr>
|
|
<tr>
|
|
<td>u:ContentTypeInvariant</td>
|
|
<td>The relationship between a representation of this resource and the
|
|
URI will not change s a function of content negotiation of MIME
|
|
type</td>
|
|
</tr>
|
|
<tr>
|
|
<td>u:Fixed</td>
|
|
<td>The relationship between a representation of this resource and the
|
|
URI will not change nder any circumstances</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>u:Fixed is a subclass of each of the other three. P3P policies are supposed
|
|
to be in u:Fixed.</p>
|
|
|
|
<table border="1">
|
|
<caption>Properties</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th>Property name</th>
|
|
<th>Significance</th>
|
|
<th>Domain</th>
|
|
<th>Inverse property name</th>
|
|
</tr>
|
|
<tr>
|
|
<td>u:isVersionOf</td>
|
|
<td>A is one of the specific versions of a time-generic resource B</td>
|
|
<td>u:TimeInvariant</td>
|
|
<td>u:hasVersion</td>
|
|
</tr>
|
|
<tr>
|
|
<td>u:isLanguageSpecficVersionOf</td>
|
|
<td>A is one of the specific languages (in the sense of HTTP
|
|
content-langauge) of a langauge-generic resource B</td>
|
|
<td>u:LanguageInvariant</td>
|
|
<td>u:hasLanguageSpecificVersion</td>
|
|
</tr>
|
|
<tr>
|
|
<td>u:isContetntTypeSpecificOf</td>
|
|
<td>A is one of the specific content-type-specific resources (in the sense of HTTP
|
|
Content-type) of a generic resource B</td>
|
|
<td>u:ContentTypeInvariant</td>
|
|
<td>u:hasContentTypeSpecificResource</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p></p>
|
|
|
|
<p>There is no assurance when one of these properties is used that either
|
|
subject or object is not itself invariant. In other words, if one states of
|
|
two identical TimeInvariant resources that one is a version of the other, that
|
|
is consistent. The promise that neither will change can be made later as a
|
|
consistent with an earlier promise that one will not change.</p>
|
|
-->
|
|
<hr />
|
|
<p>
|
|
<a href="../"><img src="../Icons/WWW/w3c_48x48" /></a>
|
|
</p>
|
|
<address>
|
|
<a href="../People/Berners-Lee">(c)Tim BL 1996</a>
|
|
</address>
|
|
</body>
|
|
</html>
|