User:Rcygania2/HashVsSlash

The Semantic Web uses URIs as identifiers for things and documents (as opposed to the traditional World Wide Web, which uses URIs just as identifiers for documents). Publishers can choose between two styles of URIs as identifiers for things: hash URIs and slash URIs. Slash URIs must be used in conjunction with 303 redirects.

This page is RichardCyganiak's subjective collection of pros and cons of each approach.

Pro hash

• Easy authoring and publishing just by editing and uploading static files
• Fits well with the explanation: "The Web is about documents. The Semantic Web is about the things inside those documents." This seems like a very sound and marketable explanation of the Semantic Web, and hash URIs reinforce this explanation.

Example: URI for Entity Berlin

Con hash

• There are issues with content negotiation. See IanDavis' blog posts from late 2007, discussion on the TAG list.
• Doesn't work well with large namespaces
• Doesn't work well with documents that describe just one thing -- the #it style is ugly and can't be QName-abbreviated, e.g. as in dbpedia:Berlin

Pro slash

• The URIs of the thing and its describing document can be chosen and evolved independently

Example: URI for Entity Berlin

Con slash

• 303 redirects require an extra HTTP round-trip
• This will never fit truly well into web architecture. At best, it's "mostly harmless". It's a hack.
• When linking to a slashy URI, it's hard to provide metadata about the document describing the thing. With hash URIs, we naturally know the URI of that document. (See sbp's discussion from early January 2008 on the TAG lists)
• Deployment is challenging

Attempted synthesis

Slash URIs are mostly legacy. For everyday RDF publishing, hash URIs are better. Slash URIs may have their place for identifiers that are supposed to outlive the particular documents that describe them, and for very large collections of classes and properties.