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

On Tue, 2007-06-26 at 17:24 -0500, Pat Hayes wrote:
> >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 
> version.
> 
> >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 
> http://www.w3.org/TR/webarch/
> 
> (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".

I take it to be about naming, but I can
see how it's less than crystal clear.


> (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 
> doesn't.)

Sure it does. It allows me to write
down links to the thing using that name,
to wit: <a href="http://its/name">a label for it</a>.

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

Sure it does. If you tell me the (web standard) name for
some web page, I can take that name and plug it
into various mechanisms to perform operations on it.
e.g. curl/wget , or stick it in a web browser...

Again, I can see how this admits other interpretations
of the identify/access distinction, though...

> (2.2)
> 
> >"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.)

It doesn't say "the design of the web guarantees
that a URI identifies one resource"; rather,
it's saying that the intended design of URIs
is that each one identifies one resource; if you
use them some other way, then you're not using
them as designed.


> >That's reference.
> 
> Ive never read it that way, which IMO was 
> charitable of me since it doesn't make sense read 
> that way.

Sure it does.

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

All of it, to my mind. Most of webarch volume
1 is about information resources, true. We haven't
touched on the semantic web much.

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

perhaps; that's not by design.

>  whereas it often fails to 
> make any sense at all if understood the way you 
> say it should be understood.

I'm fairly confident that the interpretation
I'm suggesting satisfies the text in the document.

I see your point that there are other interpretations,
at least for parts of it...

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

The distinction is quite a bit more subtle than
anything that we thought should be in-your-face
in the hello-world example.


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

The mechanism to associate ftp://abc.example/file
with its referent is to buy the abc.example domain
and run an ftp server that serves up representations
of the resource. Granted, this doesn't completely
pin down the resource, but it does let people publish
stuff that suggests the intended model
and eliminate at least some unwanted interpretations.

It would be sorta awkward and long-winded to
say "... identifiers are associated with representations of
their resources" and it comes down to pretty much
the same thing.

Re "in general," I wonder if you're reading a forall quantifier
that isn't there.

> (BTW, nothing in the document ever says how URIs 
> get associated with resources. NOTHING.

True enough, from a very strict point of view.

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

It's not done in general. It's only done in the
case of available information resources.

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

No; you're reading a "for all" quantifier that
isn't there.

>  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'?

Once we have a representation, we know we're talking
about an information resource.

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

Right; pretty much all of section 3 (Interaction) is about
information resources.

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

ew... indeed, "identify" is used in a completely
different way in...

  "A specification SHOULD provide ways to identify links
  to other resources"

In that bit of text, identify basically means "parse"
or some such.

I'm afraid this is a bit of committee writing showing through.

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

OK, I can see things that suggest that they are muddled.

I still think that with just a little bit of generosity,
you can see a distinction between identification and
access in the text.

>  And of course a long trail of earlier 
> correspondence.

Well, I'm willing to look at individual bits, but
I'd also be happy to leave all that aside.

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

Now you're arguing by assertion. No fun.

>  The idea that 
> if a URI accesses something it must therefore 
> refer to that thing also, is an example of the 
> muddle.

Who said it must? That it does is a design
choice in the web.

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

It's hard to convey my meaning in text...

The access case I meant is when I actually yell your name
in a room where you are, and you turn around and look at me and
perhaps walk over; i.e. I send a message that includes
your name in such a way that you sense and respond to it.

>  (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.)
> 
> Pat
-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/

Received on Tuesday, 26 June 2007 23:28:16 UTC