There's a long-standing issue in the RDF community about whether to use URIs like
http://purl.org/dc/elements/1.1/title
or
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
Should the character before the last word be a hash ("#") or a slash ("/")?
The original wiki document pre-dated the 18 June 2005 TAG decision. 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 by some other HTTP method than "200" (eg. by a redirection). This has practical consequences on how URIS are chosen.
We can now look at the pros and cons of using each form.
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 it. This involves control of the web server which many people do not have, or have not learned to do.
- Run time speed: The client looking up the URI just strips of 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. Further fetches will not be necessary at run time.
Advantages of using slash
- With hash, one document, whose URI is the bit up to the hash, has to contain information on
all the things whose URIs are the same before the hash. For a hand-written ontology or data file this is fine, but for a machine-generated system it could be too large.
History
The issues before the TAG decision are explored nearby, starting with WhenBrowsableAndUnambiguousCollide, HashURI, SlashURI, and the TAG issue httpRange-14.
--- 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?
---
(Taken from an email by Patrick to www-rdf-interest)
Unfortunately, those pages seem to be authored by those with a shared viewpoint, despite the occasional comment here and there. E.g. Line 30 above is simply wrong, and misleading.
If you intend to reflect a summary of both sides of this debate, then you should include quite a few references to past threads and/or summarize key points made in those threads. That's not to in any way undervalue the effort you and others have put into producing those wiki pages, only that I do not consider them to be unbiased or to reflect both sides of the debate equally well.