Re: URIs / URLs

Hello,

	thanks for your comments which show some misunderstanding 
about our note.

At 12:50 -0500 10/04/01, Aaron Swartz wrote:
>I think the major confusion in this document is the mistaken belief that a
>network entity is the same as the resource.

	We certainly, did not give enough echo to the interpretation 
that URL are just here to identify some resource that are not network 
accessible. We should correct this.
	But this was not our main point: the problem is not really to 
decide if what is returned by a URL is a resource or something having 
a more or less remote relation to that resource, but if what the URL 
identify is the former, the latter or something else.
	This has some importance because, for instance, if we take 
the latter interpretation, I do not evaluate the validity of an 
assertion about a resource from what is located by its URL (URL are 
then strict symbols).

Moreover, in his message (Re: URIs / URLs) of 8/04/01,
Dan Connolly wrote:
>Pierre-Antoine Champin wrote:
>  > > 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.

I think that this was the more important point you raised.
And this was, indeed part of our claim.

In fact, there is two points for us:
1) There seems to be a problem of interpretation of what is the 
meaning of a URL. This problem has been made more acute recently when 
people tried to ascribe a semantics to RDF. This is because, 
sometimes one would like that a URL's meaning is the piece of HTML 
returned (when invoked in a correct HTTP client, with all DNS and so 
on working correctly, etc.), and sometime one would like that a URL's 
meaning is something remote from that system stuff (i.e. it is used 
exactly like a symbol). [by the way, you can consider that the first 
is "locating", and the second "naming"].

This problem arise in some of the examples provided in the RDF Recommendation.

This problem does not arise when one uses URLs consistently in one 
way or another. The problem can only arise with the mixing of the two 
interpretations in the same application.

So, you are right, URL works very well as names (for instance in 
namespaces were they are used like simple strings), and they also 
work very well as locators. But not by the same application (or to be 
more precise, for the same purpose).

2) One of the point we made is that URL works fine as names (at the 
world-wide scale) due to the use of IP names (just the way it is used 
for Java packages) and that should be preserved.

>  > 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.

a) I am not sure that the above statement is correct, but I will not 
attempt at demonstrating my limited knowledge of network 
communications protocols.

b) I am afraid that we are trying to go beyond the network 
communications protocols. The network communication protocols, so 
far, did not try to assert statements at a logical level (this is a 
low-profile statement, since I do not want to commit to a particular 
underlying semantics).

However, to be sure that we agree that it is different:
A basic example: "the police has identified the murderer" and "the 
police has located the murderer".
An example closer to us: With an ISBN you can identify an edition of 
a book. You have to use further resources in order to locate an 
instance of that edition.
And of course, with a W3C namespace URL, you identify the namespace 
you refer to (e.g. 'http://www.w3.org/1999/XSL/Transform' and you can 
use correctly XSLT without having to locate anything!).

>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.)

I guess you meant "proper nouns"?
In grammar, a proper noun is basically a noun phrase so. It makes no 
difference.

In semantics, basically, they cannot be treated the same way since 
one is indefinite (w.r.t. some context) and the other definite. Of 
course, one can imagine to design a system able to take any kind of 
description anywhere and to sort them out (just what we do when we 
read:
[http://www.w3.org/People/Connolly/] -wrote-> 
[http://www.w3.org/People/Connolly/]). It is just far more difficult 
and no doubt it will be a breakthrough in natural language processing.

But, back to our preoccupation, if I want the semantic web to tell me 
that (and it is certainly one of what I expect from the SW):

[http://www.w3.org/People/Connolly/] -tells-> 
[iswrong(http://www.inrialpes.fr/exmo/people/Euzenat)]

I want to know if what is wrong is:
- the URL (which should be "euzenat");
- the content of the page (which says that I teach at ENTPE which I 
do not anymore);
- the person described by the page (because I happen to be wrong 
sometimes, and, to the opinion of Dan Connoly 
'http://www.w3.org/People/Connolly/' but not of what is written in 
his web page 'http://www.w3.org/People/Connolly/', especially in the 
case of the note we produced with Pierre-Antoine and Alain).

The question is: how do we make this clear for our tentative semantic 
web applications?

This is under this small light that we tried to bring our 
contribution to the debate.

The bottom line of our arguments was:

[1] Fact: URI can identify almost everything

[2] Fact: URL (mainly http:// and ftp://) are pretty good at naming.

[3] Explanation of [2]: mainly based on a hierarchical decentralized 
organization of names beginning with domain names.

[4] Fact: URL are felt by the layman as identifying web pages (and we 
tried to say, in the note, that this cannot be the case, so we 
proposed alternative interpretations).

[5] Proposal: Do not use URL for identifying anything but network 
accessible resource (the note says retrievable, I come back to 
accessible used in the RFC).

[6] Objection: URL are fine for documenting the identified resource.

[7] Proposal: Use an URN scheme that retain the advantages stressed 
in [3] and that can easily be mapped to an URL identifying and 
locating the documentation.

[8] Objection (DanC): URN do not work.

We have to apologize if it was not clear enough (and eventually made 
this clear in a new version).
----------------------
-- 
  Jérôme Euzenat                  __
                                  /      /\
  INRIA Rhône-Alpes,            _/  _   _   _ _    _
                               /_) | ` / ) | \ \  /_)
  655, avenue de l'Europe,    (___/___(_/_/  / /_(_________________
  Montbonnot St Martin,       /        http://www.inrialpes.fr/exmo
  38334 Saint-Ismier cedex,  /          Jerome.Euzenat@inrialpes.fr
  France____________________/                Jerome.Euzenat@free.fr

Received on Wednesday, 18 April 2001 03:43:13 UTC