From W3C Wiki
Jump to: navigation, search

How do you make a Slash URI which doesn't have problems when browsable and unambiguous collide?

Answer: Use HTTP 303 Redirects.


The server handling responds to all requests with an HTTP "303 Found" redirect. This redirect tells the client software to load the document whose URI is The first URI conceptually remains the URI of the place; the second URI is the URI of an authoritative document about that place.

The idea here is that clients are asking for a representation of something and being told, "I don't have one, but I do have some information about it, over here...."

All known browsers (at least NS4, Mozilla 1.2, IE6, and Opera5) change the displayed URI to the second one, so the HTML-based user has a fairly clear indication of the distinction between the thing and the page about the thing. (NS4 makes the user engage in an explicit See Other click-through with 303 redirects, but not with 302 Found.)

At the second URI, RDF and HTML may both be served (either with embedding or content negotiation) as long as:

  1. fragment identifiers (based at that new URI) are only used with one of the content-types, or
  2. the RDF is not served with a content-type with out-of-the-page fragment semantics


  • There is an extra HTTP round-trip. This means that, for example, a client looking up an ontology must make a request for every term, rather than once for each ontology. The Tabulator RDF browser, for example, has a hack to avoid this, by being pre-programmed with the knowledge of the redirect for common ontologies using slash. The runtime is otherwise unacceptable.
  • Redirects can be confusing to users.
  • Configuring a server to issue redirects can be difficult or impossible in some cases.
  • Each public name requires an explicit step (setting up the redirect), which is more work than just using a term in a document published at a fixed location. (A tool to create an .htaccess file out of rdfs:IsDefinedBy links should be simple enough, but that still requires adding the IsDefinedBy and thinking about what URIs you want to expose to the world.)

How do you offer both RDF and HTML? Some options:

  1. Look at the Accept: header on the original request and redirect to different places. This probably violates the rule of least surprise.
  2. Redirect to the same place, look at the Accept: header there and serve HTML or RDF. This also probably violates the rule of least surprise.
  3. Redirect to some HTML which has embedded RDF. This requires embedding RDF in HTML (e.g., RDFa).
  4. Redirect to some HTML which has a <link> to the RDF as either rel="meta" or rel="alternate".
  5. In a Redirect to some HTML, add a header X-Metadata-Location, which points to the location of the RDF.
  6. Both 4 and 5, so a client just wanting RDF can skip retrieving the HTML.

It's actually possible, although perhaps silly, to do all of these at the same time,