View source for SlashRedirection

__NOTOC__
How do you make a [[SlashURI|Slash URI]] which doesn't have problems [[WhenBrowsableAndUnambiguousCollide|when browsable and unambiguous collide]]?

Answer: Use HTTP 303 Redirects.  

Consider: <code><nowiki>http://sws.geonames.org/2950159/ </nowiki></code>

The server handling <code>http://sws.geonames.org</code> responds to all requests with an HTTP "303 Found" redirect. This redirect tells the client software to load the document whose URI is <code>http://sws.geonames.org/2950159/about.rdf</code>.  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:
# fragment identifiers (based at that new URI) are only used with one of the content-types, or
# the RDF is ''not'' served with a content-type with out-of-the-page fragment semantics
#* '''''What does this mean? [[PeterAnsell]]'''''

Drawbacks?
* 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 <code>.htaccess</code> file out of <code>rdfs:IsDefinedBy</code> links should be simple enough, but that still requires adding the <code>IsDefinedBy</code> and thinking about what URIs you want to expose to the world.)

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

# Look at the <code>Accept:</code> header on the original request and redirect to different places.   This probably violates the rule of least surprise.
# Redirect to the same place, look at the <code>Accept:</code> header there and serve HTML or RDF.  This also probably violates the rule of least surprise.
# Redirect to some HTML which has embedded RDF.  This requires [[EmbeddingRDFinHTML|embedding RDF in HTML (e.g., RDFa)]].
# Redirect to some HTML which has a <code><link></code> to the RDF as either <code>rel="meta"</code> or <code>rel="alternate"</code>.
# In a Redirect to some HTML, add a header <code>X-Metadata-Location</code>, which points to the location of the RDF.
# 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,