Generic.html 11.2 KB

Raw Blame History Permalink

<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>

         &lt;link rel="language-specific" href="baz.fr"&gt;


</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>

         &lt;resource uri="baz.fr" vary="type, time"&gt;
                 &lt;meta htp-equiv="content-language" value="Fr"&gt;
         &lt;/resource&gt;

</pre>
    <p>
      So much for the architectural ideas. In practice one would
      use a shorthand form for all this information such as
    </p>
    <pre>
         &lt;specific language="fr" uri="baz.fr"&gt;
 or
         &lt;specific language="fr" ct="text/html" uri="baz.fr.html"&gt;

</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>