I would keep discusion of this in the www-tag@w3.org archive, except that the questions and answers are old. For the myth that this is solved by distinguishing between names and addresses, see <http://www.w3.org/DesignIssues/NameMyth> . For the reaon why URIs have to an information resource by any other name, see <http://www.w3.org/DesignIssues/HTTP-URI#argument>.

I'd be interested to know how you justify the statement:

I think the assertion that a URI with a fragment identifier points to a dream or a car is absolutely unassailable. From a specification legalese point of view, that's rock solid.

My reading of RFC 2396 is quite the opposite. It says, at the end of section 4.1:

The fragment identifier if only meaningful when a URI reference is intended for retrieval and the result of that retrieval is a document for which the identified fragment is consistently defined.

In general, I don't see why something which appears to be a reference to a part of or point in a document is any more a candidate to identify a non-network retrievable object than something which appears to reference a whole document.

I think there is a strange, narrow, and counterintuitive path between Scylla and Charybdis that actually works.

a) We first have to plant in our minds that HTTP GET never returns a resource, it always returns a representation of the resource. If you get a 404, that doesn't mean that the resource doesn't exist, it means that no representation can be found.

b) Consequently, doing a GET on my home page does not return my home page; it returns an HTML representation thereof. Documents are just as "off the Web" as Shakespeare is; doing a GET on this does not of course return Shakespeare, and by the same token, doing a GET on this does not return the XML Recommendation.

c) That being so, when we use an URL as a name and attribute properties to that URL, it isn't clear whether we are attributing properties to the resource or the representation. Shakespeare-the-resource has a birthdate and a height in feet and inches; Shakespeare-the-representation has a creation time and a height in pixels. Shakespeare-the-resource had a wife and children; Shakespeare-the-representation has no descendants. All is muddle?

d) Almost but not quite. It now becomes a meta-property of each property whether it applies to resources or representations. The dc:creator property, for example, applies to the resource: it is the person who wrote the document, not the person who made this particular representation by copying it from somewhere else. In this way we escape the trap and go free: it is part of the context of use for each URI whether we are making resource-based or representation-based use of it. The topic-maps folks have always gotten this part right.