Re: Strong Evidence for the Name vs. Location Distinction

On 2002-03-09 20:55, "ext Mark Baker" <distobj@acm.org> wrote:

>> But what if you need the name of both a non-location resource and it's
>> location in the same context?
>> 
>> If the same name can denote a location resource in one context and a
>> non-location resource in some other context, fine. But the SW is
>> one single context and we need a formal distinction between the two.
> 
> Let me provide an example for what I mean by "context".  If I asked a
> cache if it had a copy of a representation of a resource I wanted;
> 
> telnet cache.org 8080
> GET http://site.org/resource-i-want
> Accept: text/html
> 
> then I'm not making use of the locating features of the identifier, I'm
> just using it as an opaque string of characters.

Sorry. I don't buy that. A cache is a context holding proxies for
a locations. And
in that context, the URI still denotes a location, but you are bypassing
the direct retrieval from that location with the proxy location provided
by the cache.

The semantics of the URI is still a location. That "opaque string" is
the name of a location -- actually, a sub-location in the context of
the cache. What your cache is doing is mapping a remote location (with
content) to a local proxy location (with content):

   URL   -> cache/URL

And the resolution process first performs the same mapping to a local
proxy location for retrieval before trying the remote location.

But the URL remains the name of a location. A filename is
just the name of a location. It doesn't name the content. Some filenames
do double duty, and have mnemmonic qualities that reflect the nature
of their content. But filenames are first and foremost the names of
locations (containers) in the filesystem.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com

Received on Tuesday, 12 March 2002 06:36:07 UTC