- From: Larry Masinter <masinter@adobe.com>
- Date: Fri, 19 Jun 2009 20:05:59 -0700
- To: www-tag <www-tag@w3.org>
The relationship between URIs and resources is intrinsically ambiguous. To ask the question of how many resources are identified by a single URI is like asking how many angels can be identified by a single pin. URIs by themselves do not "denote"; they are used by applications or agents to denote or identify. For example, * XML applications use URIs in xmlns attributes to identify namespaces. * Hypertext applications such as web browsers use URIs to identify which network resource should be contacted during the interaction with the hypertext and how that contact is to be made. * Semantic Web applications use URIs to denote concepts. I use "denote" as term related to, but different from, "identify". Concepts do not form a set, and cannot. Concepts cannot be counted, because to count them, you would have to identify them. There is no 'equality' for concepts. I believe the question asked by httpRange-14 is ill-formed, because it is based on the presumption that "denotation" is a function, when it is not. I think somehow linking the HTTP response code returned by a server as a way of changing the denotation of a URI used -- well, it's ineffective, misleading, bad design. I'd normally be reluctant to bring this up -- not a good use of W3C TAG time in my opinion -- but I believe acknowledging the ambiguity may be fundamental to making progress on some of the metadata and security issues before the TAG. Metadata because metadata itself consists of assertions about media resources in which the identity and scope of the metadata assertion is itself a fundamental ambiguity. The various means of associating metadata with resources being discussed each carries its own model of what is being described as well as the identity of the describer. Security because trust is based on the presumption of (sufficient) agreement about the meaning (denotation) of the terms, and disagreement about that results in trust being broken. Larry -- http://larry.masinter.net
Received on Saturday, 20 June 2009 03:15:44 UTC