- From: <dan@dantobias.com>
- Date: Wed, 23 Jan 2002 14:24:17 -0500
- To: Patrick Stickler <patrick.stickler@nokia.com>, URN <urn-ietf@lists.netsol.com>, URI <uri@w3.org>, Tim Kindberg <timothy@hpl.hp.com>
On 23 Jan 2002 at 10:44, Tim Kindberg wrote: > I can always construct a naming context that maps a given > identifier to an (arbitrary) given result, and construct a 'browser' that > acts as a client to that naming context. The fact that we use browsers of a > certain type pointed to certain naming contexts is a convention driven by > the application concerns of the times -- and they may change. However, in theory at least, a URL or URN that is tied to a digital resource always refers to exactly that resource, no matter who is accessing it or for what purpose. The rendering may vary (an HTML page looks very different in Lynx versus in Netscape), other characteristics may be different if content negotiation is used (format, language, etc.), but they're all supposed to be renditions of the same resource, and the "authority" for that resource (e.g., the web designer) controls what data stream is supplied as the resolution of the URI (though the end user's configuration may affect what is perceived at his/her end and what use is made of the data once retrieved). On the other hand, the sorts of physical-object URIs you're talking about here would be "resolved" in highly user-specific ways, leading to widely varied resources, including ones of which the "minter" of the URI doesn't even know about. Scanning the URI of a can of beans will produce very different results for the supermarket manager, a consumer, a warehouse manager, and an environmental protestor. Thus, it is more accurate to regard such resolutions as to objects *linked to* the can of beans, rather than of *resolving* the URI of the can of beans itself, whose only true resolution is the beans inside the can (which one can't retrieve from a browser unless some Star Trek technologies are implemented). -- Dan Dan's Web Tips: http://www.dantobias.com/webtips/
Received on Wednesday, 23 January 2002 14:24:45 UTC