- From: Graham Klyne <gk@ninebynine.org>
- Date: Fri, 27 Feb 2004 19:23:03 +0000
- To: "Hammond, Tony (ELSLON)" <T.Hammond@elsevier.com>, uri@w3.org
At 13:54 27/02/04 +0000, Hammond, Tony (ELSLON) wrote: >Might it be impertinent to suggest that these document represent a legacy >view on the function of fragment identifiers in URIs? Er, yes, I think you're right about the legacy viewpoint. >The INFO case may be instructive wrt the roll of media types since there are >no representations that can be retrieved and hence, apparently, no media >type that can be associated with the fragment identifier (unless there be >some null media type). In the work on RDF, we (mea culpa) used the artifice of a notionally retrievable RDF representation to explain the use of fragids as part of RDF identifiers. This kind-of breaks down in the face of a URI for which there is no retrievable representation. I think my problem here is that I don't believe there's any such thing. Some time ago, thinking about URLs and URIs, I came to the conclusion that any locator can be used as an identifier (obvious, I think), and given a suitable infrastructure, any identifier can be used as a locator. Nothing since has served to shake my confidence in this view, though I haven't always been able to convince others of it's correctness. So even if you assert that the resource identified by a given URI has no retrievable representation, I think it's fairly trivial to construct an environment in which there *is* a retrievable representation for what that URI denotes (unless its denotation is so obscure as to defy having any reasonable representation, but that doesn't seem very useful to me). In such an environment, I'm not sure that it is at all meaningful to employ a fragment identifier at all. (Reminds me of: "Doctor, it hurts when I do <this>". "Then don't do <this>".) (Which I think is the point of Martin's message at: http://lists.w3.org/Archives/Public/uri/2004Feb/0146.html ) #g ------------ Graham Klyne For email: http://www.ninebynine.org/#Contact
Received on Friday, 27 February 2004 14:31:29 UTC