Hash and Slash (A Concern About Clickability)

This is a side note to Which URIs should I use in my RDF.

If the URI functions as a normal web address it risks ambiguity as people start to use it to identify a source of web content as well as whatever it was originally intended to identify. (Of course, this is not a problem if the thing itself happens to be a web page or other traditional web resource.) There are two common approaches to addressing this problem, sometimes called "hash" and "slash":

The "hash" approach uses an http: URI with a fragment ID (separated by a "#" character, sometimes pronounced "hash"), like "http://www.w3.org/1999/02/22-rdf-syntax-ns#type". Here the full URI (sometimes called a URI-Ref) identifies an abstract property, while the non-fragment part "http://www.w3.org/1999/02/22-rdf-syntax-ns" identifies the associated web content. A potential drawback of this approach is that because fragment semantics are defined by the MIME content-type of retreived content, content-negotiation cannot safely be used to offer content in RDF along with other MIME types like text/html and application/xml.

The "slash" approach uses http: URIs which, during an HTTP operation, redirect with "302 Found" or "303 See Other" to the associated web content. The redirect (and the resulting change in the URI displayed in a browser's "Address" box) makes it fairly clear that the returned content has its own, separate URI.

Each of these approaches generally works and is deployed. Hash has conflicts with some kinds of content-negotiation; slash requires an extra HTTP round-trip to obtain the associated content. Some people have strong feelings about how URIs and the web are supposed to work which have sometimes make discussions of these issues difficult.