RE: Location vs. names

> -----Original Message-----
> From: ext Pierre-Antoine CHAMPIN [mailto:champin@bat710.univ-lyon1.fr]
> Sent: 08 June, 2001 16:26
> To: Patrick.Stickler@nokia.com
> Cc: www-rdf-interest@w3.org
> Subject: Location vs. names
> 
> 
> Dear Patrick,
> 
> I'm quite interested in that debate, because I entered about the same
> one a few weeks ago by posting
>   
> http://lists.w3.org/Archives/Public/www-rdf-interest/2001Apr/0020.html
> 
> the proposed note was clumsy to some respects (according to 
> the numerous
> comments we got ;-) but the basic ideas were similar to yours.

I haven't finished reading through this yet, but I will. (Jumped
to the second one first).
 
> A problem is that the distinction is absolutely not taken for 
> granted by W3C people.
> Have a look at :
>   http://www.w3.org/DesignIssues/NameMyth.html
> 
> Hence, I guess, the will of the URI WG to make the notion of 
> URL obsolete.

Eh? What? Every identifier that Tim called a "name" in that
paper I would consider a structured address, defining a location
or (as you put it) a point of access to the resource. Those
are not names of the *resource* though they are comprised
of names of computers, disks, directories, etc. etc.

Locations/addresses are often compound structures that include
names, as we like to organize things hierarchically, but that doesn't
mean that the address is a name!

I guess all XPaths are also names! ;-)

I wonder what the KR literature has to say about the name vs. address
"myth".

The explicit distinction between name and location (or
expression/definition/etc.)
is one of the key distinctions between RDF and Topic Maps.

> If I had to argue in favor of the URL/URN distinction :
> 
> - URLs are defined with a mandatory protocol to *access* the resource
>   (note that I wrote *access* and not *retrieve*
>    -- some URLs are not "retrievable", e.g. mailto:)
>   Of course, the protocol may involve external factors,
>   hence a great variability in the "accessing process",
>   but semantically speaking , the same (generic) resource is 
> accessed however.
> 
>   The protocol, however complex defines a "space",
>   and by construction, URLs identify "locations" in that space.
>   What "lies" in that location (the resource) is set by the 
> "owner" of the URL;
>   it is bound by the protocol (what it can do/transport/provide)
>   and by the constraint that the resource be unique -- URLs 
> are *iodentifiers*.
> 
> - URNs are defined outside any mandatory protocol. They are 
> just *names*.
>   The URN scheme specifies how those names are constructed, 
> and what the can name.

I think that it is necessary to define the concept of URL
as indentifying an explicit point (address, location) within 
a given space, as defined by a protocol, by which a concrete
resource can be accessed.

If you simply define it in terms of accessibility, apart from
an explicit point in that space, then a URN that has some
agent to resolve it to some content could arguably satisfy
that definition of a URL.

URLs define a point of access, and identify that point of
access directly and any resource retrievable from/by that
point of access indirectly. URNs define a resource irrespective
of any point of access.

E.g. "My Box" is a name, and "on top of the table" is a location.
The location does not define "My Box" in any way. Nor does "My Box"
signify where it might be located. These are distinct things.

The apparent "myth" that Tim describes seems to me to be an issue
of perspective, in that in one context some string might serve
as a name, but in another context as an address or a component
of an address. 

From the perspective
of "files" on a given machine as identified by its network
and filestructure organization, a URL "http://foo.com/bar/bas.html"
contains the names of a protocol, of a machine, of a directory and
of a file, but it might be the address/location of
a particular expression/encoding of the abstract *resource* "My Thesis".
In one sense, the URL *is* comprised of names, but as a whole it serves
as a location. The URL is not the name of the thesis, nor is the file
name "bas.html". If one of the names comprising that component,
hierarchical location changes, then the location has changed, not the
"name" of the resource located there.

After all, how often do *file* names equal *document* names?! Eh? If
the filename were the actual *name* of the resource, then we wouldn't
need <title> element, would we? Just use the filename!

No?

Patrick

Received on Friday, 8 June 2001 10:08:13 UTC