HashSlashDuality

In both sides of the HashVsSlash debate, the choice of GoodURIs either obscures a document section or an RDF Property.

Generalization that URIs with fragment IDs identify anchors as in HTML

Some parties follow the intuitions from HTML and other hypertext systems and generalize so that given a hashless-URI http://example/x and an identifier used in a representation of the corresponding resource, abc then http://example/x#abc refers to a section of the document http://example/x, so GoodURIs for RDF Properties shouldn't take the form foo#bar since RDF Properties are not sections of documents.

Anyone who chooses http://dublincore.example/v#title as a URI for an RDF Property deprives the HTML-generalizing folks from from using it to refer to a section of a document.

This generalization is seen as harmful by some (including TimBL), in that it prevents one from building a new application, such as Semantic Web, on top of the same HTTP infrastructure in the same way as we built the hypertext application on HTTP using HTML.

Generalization that http: URIs without hashes refer to documents

Other parties follow the intuitions from HTTP and generalize from the observation that many URIs of the form http://example/x refer to documents that have representations that you can GET with HTTP, and generalize so that http: URIs without hashes refer to documents.

Anyone who chooses http://dublincore.example/v/title as a URI for an RDF Property deprives the HTTP-generalizing folks from using it to refer to a document.

This generalization seen as useful by some (including TimBL, though his justification seems to just assert the conclusion: It is important that we can continue to use any such URI to refer to the document).

Some question whether using URIs without fragment identifiers to denote only documents is actually "common practice". Perhaps 10 years ago that may have been the case, but in today's web, it's much less clear.

Note this assumes that documents, document sections, and RDF Properties are disjoint. Let's put that to the test of WikiConsensus.