How do you make a SlashURI which doesn't have problems WhenBrowsableAndUnambiguousCollide?
Answer: Use HTTP 303 Redirects.
Consider:
http://sws.geonames.org/2950159/
The server handling http://sws.geonames.org responds to all requests with an HTTP "303 Found" redirect. This redirect tells the client software to load the document whose URI is "http://sws.geonames.org/2950159/about.rdf". 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 represention 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 clickthrough 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 roundtrip. 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 knowldge of the
- redirect for common ontologies using slash. The runtime is otherwise unaccceptable.
- 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 knowldge of the
- 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
and .htaccess 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:
- Look at the Accept: 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 Accept 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.
Redirect to some HTML which has a <link> to the RDF as either rel="meta" or rel="alternate".
- In a Redirect to some HTML, add a header X-Metadata-Location, 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,