W3C home > Mailing lists > Public > www-tag@w3.org > June 2007

Re: Terminology (was Re: article on URIs, is this material that can be used by the)

From: Pat Hayes <phayes@ihmc.us>
Date: Tue, 26 Jun 2007 17:24:42 -0500
Message-Id: <p06230905c2a733a03887@[]>
To: Dan Connolly <connolly@w3.org>
Cc: noah_mendelsohn@us.ibm.com, Dan Brickley <danbri@danbri.org>, "Henry S. Thompson" <ht@inf.ed.ac.uk>, Tim Berners-Lee <timbl@w3.org>, www-tag@w3.org

>On Tue, 2007-06-26 at 15:20 -0500, Pat Hayes wrote:
>>  There I disagree. Your locution here reveals the essential point.
>>  "the sort of relationship to the resource that we expect for
>>  information resources". WRONG. In fact, I expect to have at least TWO
>>  distinct relationships to information resources. I expect to be able
>>  to access them, using some kind of xxxTP protocol, AND I expect to be
>>  able to refer to them. Referring to them is exactly like referring to
>>  anything else: the same relationship is involved, the same semantic
>>  theories apply, and the same inference processes can be used for
>>  referential languages. When referring, the nature of thing referred
>>  to is almost irrelevant, in fact. The distinction between kinds of
>>  resource matters only because non-information resources can't be
>>  accessed. But if we distinguished between reference (naming) and
>>  access (as we should have been doing since day one and as everyone
>>  did before the W3C - in what is surely one of the most regrettable
>>  mistakes since the founding of the Holy Roman Empire - confused URLs
>>  and URNs into a single category) instead of calling them both
>>  'identify' and insisting that they are the same relation, then we
>>  wouldn't need to be having this damn silly discussion.
>webarch has always distinguished between access
>and reference.

Wow, that is news to me. When webarch was in LC 
mode, I wrote an extended critique of the draft 
in which I asked for this distinction to be made 
clearly, and pointed out a lot of the 
consequences of the confusion. Many of those 
consequences are still in the final published 

>Identification is reference, not access.

OK, lets assume that is what is intended. Now 
tell me how any of the following make sense, with 
that interpretation. All from 

(Section 2) The introduction explicitly cites Engelbart's slogan

'Every Object Addressable --in principle, every 
object that someone might validly want/need to 
cite should have an unambiguous address (capable 
of being portrayed in a manner as to be human 
readable and interpretable). (E.g., not 
acceptable to be unable to link to an object 
within a "frame" or "card.") '

as the definitive preview of its position on 
identification. Engelbart (who was never confused 
on this point) is here referring to access, not 
to reference, as clearly shown by his use of the 
now archaic but admirably clear term "address".

(2.1) "A resource should have a ...URI if another 
party ...to create a hypertext link to it,..." 
How does having a referring name enable one to 
create a hypertext link to the referent? (It 

(continued) "...or perform other operations upon 
it." How does having a referring name allow one 
to perform operations upon the referent? (It 


>"By design a URI identifies one resource."

Thanks. Now, how can a 'design' possibly ensure 
that a referring name only refers to a single 
entity? (It can't: but it can ensure that an 
identifier only *accesses* one thing.)

>That's reference.

Ive never read it that way, which IMO was 
charitable of me since it doesn't make sense read 
that way. But more to the point, what text, 
anywhere in Webarch or indeed in the archived 
email trail which led to it, would lead someone 
to think that this WAS intended to mean 
reference? Nothing in the introductory text of 
the document, including the Oaxaca-weather 
example, requires one to think about anything 
other than 'information resources', and it all 
makes perfect sense if understood to mean access 
rather than reference: whereas it often fails to 
make any sense at all if understood the way you 
say it should be understood. When I read the 
introduction for the first time I looked 
carefully for anything that was clearly an 
example of reference, and it seemed that the 
examples and text had been carefully chosen to 
avoid the topic. In the example and the figure, 
for example, the actual weather over Oaxaca 
(which, one hopes, should be referred to 
*somewhere* in this scenario) plays no role at 

Back to my litany of examples. Still in (2.2)

"URIs are divided into schemes (2.4) that 
define, via their scheme specification, the 
mechanism by which scheme-specific identifiers 
are associated with resources."

What kind of mechanism can associate a referring 
name to its referent? (There is no such 
mechanism, in general.)
(BTW, nothing in the document ever says how URIs 
get associated with resources. NOTHING. The 
relevant section is all about URI ownership, and 
doesn't talk about reference or how to establish 
it at all.)

(3.1) "Agents may use a URI to access the referenced resource"

If this really does mean reference, how is this 
done, in general? What kind of agent can use a 
URI referring to, say, Julius Caesar to access 
J.C.? Taken literally with the interpretation you 
say is correct, this is *obviously* nonsense. A 
child would know it was nonsense.

"Assuming that a representation has been 
successfully retrieved, the expressive power of 
the representation's format will affect how 
precisely the representation provider 
communicates resource state. "

also (3.2)
"A representation is data that encodes information about resource state."

Anything may be referred to. How many kinds of 
thing can be said to have a 'state'? A 
vanishingly small fraction, I suggest. Surely it 
is clear that this prose (indeed, almost all of 
section 3.1) was written under the assumption 
that 'resources' are computational entities, 
which can be accessed by sending bytes across a 
network. None of the makes any sense if a 
'resource' can be, say, a piece of paper or a 
remote galaxy or a long-dead dictator or a prime 
number or a time-period or a fictional character 
in a novel. Yet all of these can be *referred* to.

(4.4) If 'identify' simply means 'refer to', then 
most of section 4.4 has nothing whatever to do 
with the Web: with that interpretation, 
everything it says applies to all uses of 
referring words in every form of human written 
and spoken language ever used. (This message has 
a 'link' to me, for example.) Why exactly is this 
section in this document, then?

>Then, elsewhere,
>"Agents may use a URI to access the referenced resource; this is called
>dereferencing the URI."
>  -- http://www.w3.org/TR/2004/REC-webarch-20041215/#dereference-uri
>What suggests to you that they are muddled?

See above. And of course a long trail of earlier 
correspondence. But just having a single term for 
URLs and URNs is already muddled. The terminology 
of "identify" which has been being used in W3C 
writings for almost a decade now is inherently 
muddled between these interpretations; one can 
see it switching back and forth between them as 
one reads sentences and paragraphs. The idea that 
if a URI accesses something it must therefore 
refer to that thing also, is an example of the 

>OK, perhaps it's a bit confusing that "reference" means identification
>while "dereference" means access.
>And why do you suggest that the same name can't be used
>both ways? Surely "Pat Hayes" is used both ways:
>   Pat Hayes is a hoopy frood.
>   Hey Pat Hayes, come over here!

Those are both referring uses. The access use, if 
you could do it, would be that when you said "Pat 
Hayes", I would be teleported to be standing in 
front of you. (Arguably, an example might be 
where you say to Henry, where is Pat Hayes?, and 
without speaking, Henry comes over and drags me 
back to you by pulling my shirt.)

IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Tuesday, 26 June 2007 22:24:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:16 UTC