Innovations can be introduced to the Web at many different architectural layers. For example:

Often, a given capability could in principle be deployed at any of several different layers. For example, new sorts of content, such as movies, could be made available using new URI schemes and/or with new protocols, but doing so would require updating hundreds of millions of user agents, servers, proxies, and so on to understand these changes to the core mechanisms of the Web. Usually it is preferable to leverage the existing core mechanisms of the Web, such as http-scheme URIs and the HTTP protocol, as these are widely deployed. Indeed, one should usually leverage as many existing layers of the Web's architecture as is practical when introducing new function.

When extending the Web with new formats and functions, use existing URI schemes, protocols, and media types wherever practical.

One way to do this is to use URI-based extensibility within existing media types, as described in the sections below.

Many documents, particularly those that convey machine-readable data or messages, encode information using specifications that are specialized to particular purposes. Such specifications may cover details of particular data formats such as lists of customers or inventory records, results of scientific experiments, listings for television shows, details of university course offerings, information about molecular structures or drug tests, etc. Because of the great variety and number of such formats and their specifications, it's not practical to assume that even most of them will be directly implemented by typical Web user agents. Instead, the Web provides means by which the necessary specifications can be discovered, and to a significant degree implemented, dynamically and automatically. This is done by:

In other words, it should be possible to discover from each Web representation the conventions used to encode it, and particularly in cases where those conventions are not widely deployed, to find within the representations links to specifications, ontologies and/or programs necessary for interpreting the representation. So, just as the Web may be used to dynamically discover a great wealth of resources, it can also be used to dynamically discover the specifications, ontologies, or programs needed to interpret the representations of those resources.

Web representations should link to the information needed to support automatic processing of those representations.

Example: The Atom Syndication Format

The Atom Syndication Format is an XML-based format for syndicating information about blogs and other Web resources. ATOM entries can include <atom:link> elements such as the following:

<entry>
  <title>An interesting picture</title>
  <link rel="enclosure" type="image/jpeg" length="12345"
        href="http://example.org/interestingPic"/>
    <content type="xhtml" xml:lang="en"
             xml:base="http://example.org/">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><[Update: Here's an interesting picture.]</p>
      </div>
    </content>
  </link>
</entry>

The link elements identify external resources, in this case an image/jpeg photograph. Furthermore, each link can carry a rel attribute which specifies the relationship between the linked resource and the ATOM entry that links it. In the example above, the relationship is specified as enclosure which, according to the ATOM specification, indicates that the linked photograph may have been too large for inline processing with the rest of the feed.

What's of interest for this finding is the fact that values of the rel attribute are URIs (actually s, which are the internationalized form of URIs), or else the values can be mapped to URIs. This means that anyone, anywhere can invent a new sort of link relationship, can assign a URI to identify that relationship, and can use that value in the rel attribute. For example:

<entry>
  <title>An interesting picture</title>
  <link rel="http://example.org/SomeNewATOMRelationship"
        type="image/jpeg" length="12345"
        href="http://example.org/interestingPic"/>
    <content type="xhtml" xml:lang="en"
             xml:base="http://example.org/">
      <div xmlns="http://www.w3.org/1999/xhtml">
        <p><[Update: Here's an interesting picture.]</p>
      </div>
    </content>
  </link>
</entry>

Furthermore, anyone doing this can (and indeed should) provide information about that new relationship via HTTP from the assigned URI. For convenience, the ATOM specification also provides that short form names such as enclosure in the first example can be registered with IANA, and ATOM provides a deterministic mapping to a URI for each of these. These URIs are formed by prepending the fixed base URI http://www.iana.org/assignments/relation/ to the short form. Thus, the first example above is in fact using the relationship http://www.iana.org/assignments/relation/enclosure.

This example shows how use of URIs for data values enables distributed assignment of new values. More importantly for this finding, the use of URIs for such values provides the opportunity for information about those values to be discovered dynamically on the Web.

    <div class="vcard">
      <a class="fn org url" href="http://www.w3.org/">World Wide Web Consortium</a>
      <div class="adr">
        <span class="type">Work</span>:
        <div class="street-address">32 Vassar Street</div>
        <span class="locality">Cambridge</span>,  
        <abbr class="region" title="Massachusetts">MA</abbr>  
        <span class="postal-code">02139</span>
        <div class="country-name">USA</div>
      </div>
      <div class="tel">
       <span class="type">Work</span> +1-617-253-2613
      </div>
      <div class="tel">
        <span class="type">Fax</span> +1-617-258-5999
      </div>
    </div>

    <head profile='http://www.w3.org/2006/03/hcard'>

<inventory:inventoryItem 
     xmlns:inventory="http://example.org/inventoryNamespace">
  <inventory:itemNumber>
      87354
  </inventory:itemNumber>
  <inventory:quantityAvailable>
      152
  </inventory:quantityAvailable>
</inventory:inventoryItem>

<rddl:resource
   xlink:role="http://www.w3.org/1999/XSL/Transform"
   xlink:arcrole="http://www.w3.org/1999/xhtml"
   xlink:href="http://example.org/InventoryToBrowsableHTML.xslt"
   xlink:title="Transform Inventory XML to HTML for Browsing">
</rddl:resource>

is a W3C Recommendation for embedding Semantic Web statements into XHTML Web pages (see also ). The following example illustrates how RDFa can integrate HTML into the self-describing Semantic Web:

Mary is exploring the Web using a browser that has been enhanced with capabilities for interpreting RDFa. Her browser knows to look through each XHTML Web page that she browses, picking out information from the RDFa, and helping her to use it. For example, the page might contain the following HTML, which represents a FOAF-based contact listing. (This example is adapted from one in ):

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns="http://www.w3.org/1999/xhtml" 
    version="XHTML+RDFa 1.0"
    xml:lang="en">
  <head>
  <title>FOAF/RDFa Demo</title>
  </head>
  <body>
    <div typeof="foaf:Person" xmlns:foaf="http://xmlns.com/foaf/0.1/"
            about="http://example.org/staff/Alice">
    <p property="foaf:name">
    Alice Birpemswick
    </p>
    <p>
    Email: <a rel="foaf:mbox" href="mailto:alice@example.com">alice@example.com</a>
    </p>
    <p>
    Phone: <a rel="foaf:phone" href="tel:+1-617-555-7332">+1 617.555.7332</a>
    </p>
    </div>
  </body>
</html>

Even though this document is of media type application/xhtml+xml , which is not a member of the RDF family of media types, an RDFa-enabled user agent can extract RDF from this document. This document conveys as RDF a set of semantic Web statements about the Web resource http://example.org/staff/Alice. The predicates are all named with the same base URI http://xmlns.com/foaf/0.1/, for which the shorthand prefix foaf is established in the HTML. Using this syntax, the RDFa carries triples for relationships such as the full name of the contact (http://xmlns.com/foaf/0.1/#name), which is Alice Birpemswick, the e-mail address (http://xmlns.com/foaf/0.1/#mbox) which is mailto:alice@example.com, and so on.

An RDFa-enabled user agent can extract these triples and use them to help Mary work with the data they contain, or to integrate with other Semantic Web information. Indeed RDF is designed for such use because, as discussed above in , Semantic Web triples are inherently self-describing. If a user agent needs more information about the processing of the email triple it can, like Amy's user agent, do an HTTP GET for URI http://xmlns.com/foaf/0.1/, and use the results to get more information. With luck, that information will lead the agent to automatically discover that, in the example, mailto:alice@example.org can indeed be used to send mail to the person named Alice Birpemswick. The browser can then offer Mary the option to send e-mail to Alice, or to add Alice to her address book.

RDFa should be used to make information conveyed in HTML self-describing.

RDFa documents such as the one shown above are self-describing when served using the Content-type application/xhtml+xml. The specification for that media type designates it as a member of the family of application/____+xml media types, and the specification for those types in turn provides for markup to be interpreted based on the namespaces used in the document. Finally, the namespace document for XHTML allows use of XHTML with RDFa. So, taken together, these specifications provide normatively for use of RDFa in documents served with Content-type application/xhtml+xml.

RDFa provides a standard means of encoding RDF information in XHTML documents, but many other XML variants lack that capability. Furthermore, RDFa requires explicit encoding of each triple in the XHTML instance, and that may in some cases be impractical. provides a standard means of extracting triples from a broad range of XML document formats. Each GRDDL-enabled XML document links to a transformation that, when applied to the document, produces RDF triples. Typically, the same GRDDL transformation can be used on entire families of similar XML documents.

For example, assume that Albert uses a GRDDL-enabled user agent to retrieve an XML document containing the following fragment:

<employees xmlns="http://example.org/employeeNS">
  <employee name="Bob Smith">
    <email>BobSmith@example.org</email>
  </employee>
</employees>

Note that, unlike the earlier examples, this is neither in HTML nor in RDF; we can assume that http://example.org/employeeNS is a namespace created by some particular business for use in its own busines documents. Albert's agent has no built in knowledge of this namespace, and so can not do much with it. Now assume that Albert instead retrieves a different document. Most of the markup and data in it is identical to the first, but this document is GRDDL enabled:

<employees xmlns="http://example.org/employeeNS"
              xmlns:grddl="http://www.w3.org/2003/g/data-view#"
              grddl:transformation=
                    "http://example.org/GRDDL_For_employeeNS.xsl>
  <employee name="Bob Smith">
    <email>BobSmith@example.org</email>
  </employee>
</employees>

Albert's user agent is GRDDL aware, so it transforms the <employees> information to RDF using the supplied GRDDL_For_employeeNS.xsl transformation. If Albert is lucky, that transformation produces RDF triples that the agent understands, or that the agent can dynamically discover how to process using the techniques described above in . As in the earlier examples, Albert's user agent offers to send mail to Bob Smith.

GRDDL should be used to integrate XML documents into the self-describing Semantic Web.

Accountability and Grounding Information in the Web

The Web is an important medium for publishing information, and so it is often important to get agreement about what has in fact been published, and by whom. Consider the following example:

Senator Smith alleges that he has been libeled by an article published on the Web, and so the senator files suit against the purported publishers. He produces in court the log of a response to an HTTP GET for URI http://publisher.example.com/oursenator.html:

HTTP/1.1 200 OK
Date: Tue, 22 Oct 2008 02:43:22 GMT
Server: Apache
Content-Type: text/html; charset=utf-8

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
        "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>The problem with Senator Smith</title>
</head>
<body>
  <h1>Senator Smith is a Liar and a Thief!</h1>
  <p>Our senator, Mr. Smith, steals money from children, 
     and he lies on his income tax returns!
  </p>
</body>
</html>

When confronted by the judge, the owners of the Web site attempt to claim that they have not in fact published information about the senator. "Yes", they say, "our server did accept a TCP/IP connection at port 80 and it responded with some bits, but those bits don't mean what you think they mean. They might look to you like HTML, but that's not what we intended. We haven't said anything derogatory about the senator."

In fact, according to the specifications for the Web, the publishers are wrong; those specifications indicate unambiguously that the bits returned are to be interpreted as the UTF-8 encoding of Unicode characters, that those characters are to be interpreted as HTML, and that the text within the HTML is to be read in English. According to the pertinent specifications, the publishers have indeed called the senator a liar and a thief!

How, though, can we know whether these specifications apply at all? Perhaps the publishers could claim that some other specifications applied? Unfortunately for them, the Web is unambiguous on this point as well. Starting with a URI such as http://localnewspaper.example.com/oursenator.html and the specification for URIs , all the applicable specifications for interpreting an http-scheme Web representation can be unambiguously discovered by, recursively, following references to other specifications. Using this specific example to illustrate:

Of course, determining whether Senator Smith has been libeled is beyond the scope of Web Architecture. The architecture does provide the means by which one can determine unambiguously that he has been called a liar and a thief by the owners of site publisher.example.com. In general, it is possible to determine which specifications apply to interactions with resources identified by any particular URI; as explained above, these specifications can be located by recursively following references from the specifications for URIs themselves.

Representations published using HTTP (or other schemes and protocols that are appropriately registered) are thus self-describing not just in the general sense of being interpretable using widely available information, but in the particular sense of having an interpretation that follows from the URI used for access and from the core specifications of the Web. We therefore refer to such representation documents as being grounded in the Web. From the URI referenced and the specification for URIs , the other specifications for interacting with the resource and for interpreting its representations are determined unambiguously. Furthermore, this characteristic implies an important degree of accountability for those who serve information on the Web. As illustrated by the example above, Web architecture settles many important questions relating to what information has been published, and by whom.