HashVsSlash
There's a long-standing issue in the RDF community about whether to use slash URIs like —
http://purl.org/dc/elements/1.1/title
— or hash URIs like —
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
That is, should the character before the last word be a hash ("#") or a slash ("/")?
Short answer: slash URIs are generally preferred because they give greater flexibility, but read on for a more detailed explanation and comparative advantages of each approach.
Advantages of using hash
- The information is easy to publish using an editor for RDF files. With slash, the server may need to be set up to do a 303 redirect from the URI for the thing to the URI for the document about the thing. This involves control of the web server which many people do not have, or have not learned. On the other hand, if setting up a 303 redirect is problematic, a hybrid approach can be used, as explained here.
- (Debatable) Run time speed: The client looking up the URI just strips off the right part, and performs a single access to get the document about whatever it is. This will in many cases also give information about other related things, with URIs starting with the same document URI, which the client may or may not need. (This point is not universally accepted as either significant or always true, because it depends on the client.)
Advantages of using slash
- The vocabulary "can be modularised while preserving a single namespace". With hash, one document, whose URI is the everything up to the hash, has to contain information on all the things whose URIs are the same before the hash, i.e., sharing the same namespace. For a small hand-written ontology or data file this is fine, but for a machine-generated system it could be too large.
- "With slash-based namespaces, hashes can be used for other useful things. For instance, there could be a fragment of a term specification that provides usage examples like http://onto.org/Term#example (this is done in schema.org). There could be a section about history (such as a timestamp for when the term was added to the vocab, or version info about the term itself like http://onto.org/Term#history) or metadata (such as an identifier of the entity that created the term http://onto.org/Term#meta, related Github issues and discussions, etc.)." -- https://lists.w3.org/Archives/Public/semantic-web/2022Nov/0024.html
History
When created, this wiki page pre-dated the 18 June 2005 TAG decision about httpRange-14. The TAG resolution takes the pragmatic view that both are OK, so long as resources named with a "/" URI are either "information resources" or respond with some HTTP response code other than "200" (such as a 3xx redirection). This has practical consequences on how URIs are chosen, which this page discusses.
The issues before the TAG decision are explored nearby, starting with WhenBrowsableAndUnambiguousCollide, HashURI, SlashURI, and the TAG issue httpRange-14.
A W3C Interest Group note was published in 2008, discussing how to choose a URI for something on the Semantic Web: Cool URIs for the Semantic Web.
In 2022, on the Semantic Web mailing list, there was a discussion specific to the use of slash IRIs as vocabulary namespaces: Is a trailing slash 'better' than a trailing hash for vocabs namespace IRIs?. Related to namespaces, there is an appendix on the topic in Best Practice Recipes for Publishing RDF Vocabularies (W3C Working Group note, August 2008).
The debate between proponents of hash URIs and those of slash URIs pops up from time to time on different mailing lists. More can be found by searching for keywords such as "hash", "slash", or "httpRange-14" in the semantic-web@w3.org Mail Archives or the public-lod@w3.org Mail Archives.
Before arguing either side, consider the WikiIsNotAboutDebate perspective... Feel free to document patterns that work for you, but if something else works for others, tread lightly, OK?