HashURI

From W3C Wiki

A HashURI is a URI with a hash mark ("#") in it (technically, a URI with a fragment identifier), specifically one used to denote something which is not a traditional web page.

Use of HashURIs is intended to help WhenBrowsableAndUnambiguousCollide. It is often presented in contrast to SlashURI, via the debate HashVsSlash.

The idea is to use URIs like

http://www.w3.org/1999/02/22-rdf-syntax-ns#type 


to combine

(document URI) # (term introduced in the document) 


This works well for a lot of RDF content. It's very natural (especially with rdf:ID) to introduce a new conceptual thing and name it with the same action.

Web retrieval does approximately the right thing. When you ask for foo#bar, your client asks for a representation of foo and then (depending on the content-type of the result) may try to find something named bar in that result.

Drawbacks?

  1. Some people find "#" unfriendly; some users may not be used to typing it. (EricMiller says this has been a significant issue for some communities considering using RDF. which ones? details?)
  2. It encourages larger pieces of web content; it's not obvious how to break up a listing of 20000 similar objects into reasonable-size web pages, such as with wordnet.
  3. The "#" part is called a "fragment identifier" and has mostly been used to identify points in a document or parts of a document (perhaps abstracted as parts of an XML infoset); using it to come "out of the plane of the document" into the subject matter of the document requires a cognitive leap. Some would call this cognitive leap the Semantic Web. See TimBL's slides from WWW1 in 1994
  4. Using "#" to denote "non-addressable subjects" (in the manner of topic maps subject indicators) makes it impossible to make assertions about parts of documents (e.g. Person A authored Section #3). This must surely be a major show stopper? There are shows that go this way that don't seem to have stopped. hmm... HashSlashDuality
  5. If multiple logical content-types are used at the same URI (either through content negotiation or embedding, as with RDF in HTML) any difference in their fragment semantics causes an ambiguity in meaning for the associated fragment URIs. For example, it might be good for RDF adoption to have a helpful HTML document appear when a user visits a URI like "http://www.w3.org/1999/02/22-rdf-syntax-ns#type". But if that were to happen, then that URI would become ambiguous, identifying an HTML anchor as well as an RDFS Property. (A similar conflict occurs when trying to use XPointer, as when the XML is to be read as RDF.)