Re: URIs / URLs

Pierre-Antoine Champin wrote:
> 
> Dan,
> 
> one key idea of the not was : *locating* and *identifying* are not the
> same.

The note did not make that clear to me.
"locating" and "identifying" seem to be used synonymously.

> Though, URLs are frequently used to identify resources, either the one
> they locate or another one.

Huh? Each URI identifies exactly one resource.
(URL is an informal synonym for URI, no?)

> This makes them tricky and unreliable as identifiers.

I'm note sure what you mean by 'tricky' but they are quite
reliable, as the statistics I cited show.

> On 06 Apr 2001 08:54:05 -0500, Dan Connolly wrote:
> > I don't see any justification for the claim
> > that namespaces are disjoint from HTTP resources.
> 
> Because it can not be transported over that protocol (bor any protocol:
> it is an abstract thing).

I saw the claim. I did not see (and still do not see) any
justification for the claim.

You continue to speak of resources being transported
via HTTP. In the standard terminology,
resources are accessed, and entities are transported.
If you mean to make up your own terminology altogether,
please explain it more thoroghly. If you mean
to use these terms consistently with their use
in the URI and HTTP specs, you are not.

> A specification of it can, indeed.
> 
> > the system works best when you can use such
> > an identifier to GET a specification/description
> > of the vocabulary.
> 
> The system works better when you know what exactly is identified by an
> identifier.

If I have a thought in my head, there's no way for me to
be sure I've completely communicated it to you. All we
can do is exchange messages until we're reasonably
confident we have a shared understanding (if we
use formal languages, we might be very confident).
Identification in the Web is no different.

In the case of http: URIs, the publisher decides what
they identify; the rest of the world may never know
exactly what the publisher bound some particular
http: URI to; but they may be perfectly happy
to access it and get represenatations of its
state regardless. The system works just fine
this way.
 

> Here, is it the decscriton or the described thing ??

It is the thing that you accessed when you got
the description. (If the description says "this is
a vocabulary of kitchen terminology..." then
it is the described thing; if the description
says "that tree is very fine" then it's
neither the description nor the described thing.)

> There is often no mean to know.

Not so; the resource identified by a URI is always
just that: the resource identified by the URI.

> Note that the description and the described thing are *distinct*, hence
> they need disctinct identifier.

In general, we don't need an identifier for the description.
(sometimes it's useful... in version control systems etc;
but I doubt that's relevant to this discussion.)

> >   "For example, the URI of the type property of RDF is
> >   http://www.w3.org/1999/02/22-rdf-syntax-ns#type. As a
> >   matter of fact, the property itself is not located by that
> >   URL: its description is. "
> >
> > Again, I see no justification for the claim that this
> > identifier doesn't identify a property.
> 
> I did not write that !
> I wrote that the URL does not *locate* the property, but its
> description.

I take 'locate' to mean the same as 'identify' and 'denote'
'designate' and many other synonyms.

> See how the confusion between location and identification is easy...

No, I'm afraid I don't see; I don't see where you have
drawn any distinction between location and identification.

> >   "URLs are transient
> >   That means they may become invalid after a certain period
> >   of time [9]. "
> >
> > That's a fact of life in a distributed system. URNs may
> > become invalid after a period of time too.
> 
> There is no reason why an URN would becom invalid once defined.

Sure there is: trademark dispute, change of specs, etc.

> It may becom obsolete, unused, but one thing is for sure :
> it will never be re-defined (according to URNs requirements).
> This is an interesting property for identifiers.

If URNs ever got to be used in a non-trivial way, all
the same problems around DNS will spring up around URNs.

Saying that URNs are interesting because they'll never
be re-assigned is like saying a computer is secure
because it's turned off.

> 
> > Naming is a social contract, and the http: contract
> > works and the urn: contract doesn't.
> 
> Once again, HTTP work as locators, not as names.

Ah. Argument by assertion. No matter how many times
you repeat your claim, it does not become any
more true.

Unfortunately, there is a sort of mass marketing effect:
people start to believe things that they have heard many
times. So at least on occasion, I feel compelled
to make the counter-claim: HTTP URIs do work as names.

I believe there is plenty of emperical evidence
to support my claim. I ask you again to justify,
not repeat, your claims.


> >   "In the immediate interpretation, a URL identifies the
> >   resource retrieved through it."
> >
> > to be precise: it identifies the resource accessed
> > thru it. In the general case, you can't retrieve
> > a resource, but only a representation of one.
> 
> Right, this is what we call an "instance" of the resource in the note.

In the case I excerpted and several others, you don't use
this "instance" terminology; you refer to that which is
retrieved as the resource itself.

By the way... rather than making up terminology ("instance")
I recommend you use the terms from the ratified specs
("entity"; cf. HTTP 1.1)

> Note that this is why we immediately discarded the immediate
> interpretation.
> 
> One thing might not have been clear in our note :
> we do not reject URLs for what they are good at. The allowed the web to
> become what it is now. I even believe that many application can them to
> identify namespaces, persons, etc.
> 
> The point we wanted to raise is that locating is not the same as
> identifying, and identifying a description is not the same as
> identifying the described thing.

You did not make that point to my satisfaction.

I don't believe that there is a useful distinction to be
made, in network communications protocols, between
locating/identifying.

And there's precious little difference between an identifier
and a description in most languages. (i.e. nouns and noun
phrases are often treated quite similarly.)

> And doing thos approximations must be
> done, if ever, with awareness.
> 
>   Pierre-Antoine Champin

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Sunday, 8 April 2001 21:43:49 UTC