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


OK,lets try that. I want to make a hypertext link 
to Julius Caesar. So I write this:

<a href="http://Julius Caesar">The great Roman emperor</a>

Well, that was easy. Now, do I have a hypertext link to J.C.?

Remember, what you and the cited text say is that 
HAVING A NAME enables the creation of the link. 
You didn't say that name had to do anything other 
than refer, and my name does refer to J.C.. BUt I 
don't think I have a hyperlink to him (in fact, I 
don't quite know how anyone could set up a 
hyperlink to the actual guy himself.)

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

Sure, if you can access it, then you maybe can 
perform operations on it. But that is exactly my 
point: you are here using the 'name' to access 
it, not to refer to it. LIke the TAG writings, 
you keep sliding back and forth between reference 
and access. You use referential language but you 
think in terms of access.

Stick to names and reference for a second. If ALL 
you can do to something is refer to it - which is 
in general all that having a name for it does 
enable you to do -  then your chances of being 
able to perform operations on that referent are 
zero. The referent might not even exist.

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

But you CANNOT POSSIBLY use them that way (if all 
you have available is descriptions of 
them,anyway, which is the usual case when using 
referring names.) So this seems like damn silly 
advice/design.

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

The distinction between real weather and a 
weather report is subtle? Get real. The document 
itself uses it later without any need to 
explicate the subtlety.

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

That doesn't associate it with the resource, in 
general: it associates it with a source of 
representations of the resource. Now, there are 
things which can be defined as sources of 
representations (in a suitable sense) of 
themselves, which indeed if I recall correctly is 
pretty much the exact definition of a 'resource' 
in Roy Fielding's thesis and also corresponds to 
what Engelbart was talking about. But such things 
- FTP and HTTP and in general xxTP endpoints, in 
fact - exist only as computational entities 
physically attached to the Web. Most things in 
heaven and earth are not definable as sources of 
representations of themselves: and for those, 
there is no mechanism for associating them with a 
URI.

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

BUt it is there. The document insists that 
resources can be anything and that resources 
should be identified by URIs. OK, you have now 
got that universal quantifier to deal with. Thats 
exactly what Im complaining about.

>
>>  (BTW, nothing in the document ever says how URIs
>>  get associated with resources. NOTHING.
>
>True enough, from a very strict point of view.

STRICT?? For goodness sake, talking about names 
and how they refer isn't being strict, its just 
using normal English. If y'all choose to use that 
terminology, you should expect to have to live 
with the consequences.

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

See above. It IS there, given what the rest of the document says.

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

?? Now you are contradicting what you said 
above.(**here***) Why is a representation 
necessarily of an information resource? (And 
where in the document is that specified?) But if 
it must be, what about all the resources that 
aren't information resources? They have to have 
associated URIs as well, according to Webarch.

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

Well, it doesn't SAY that anywhere. Grumble, 
mutter. But more importantly, the real issue isnt 
about what kinds of thing it is about, so much as 
the nature of the relationship between the URI 
and those things. So, for example, do the 
following thought experiment. Imagine that the 
sun hiccups and sends out a blast of 
neutrogravitinos or something which totally fries 
every silicon chip on the planet, so that the 
internet completely ceases to function. All the 
resources still exist, and they still have their 
URIs, and the URIs still *refer to* their 
resources in exactly the way they did when the 
Web went out. So if indeed the URI-to-resource 
relationship were simply one of reference, then 
*nothing would have changed*. This applies to the 
information resources just the same, if all we 
have been doing is to refer to them. But of 
course the Web would not work as usual, right? 
Why not??

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

Yes, I wasn't complaining about that one.

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

Well, that happens, I agree.

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

I would have to be generous enough to overlook 
several clearly emphasized assertions as mere 
hyperbole. And honestly, with the best will in 
the world, I can't make ALL of it make sense with 
any single interpretation of 'identify'.

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

Well, I did send y'all a very very long email 
commenting on the earlier draft where I actually 
traced the changes in meaning that I could see. 
It gets kind of tiring after a while, I admit.

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

Ah, I see. Well, OK, I see your point. There is a 
critical difference, though, in that it depends 
on my being able to interpret the utterance as 
referring to me.

>
>>   (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/


-- 
---------------------------------------------------------------------
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 Wednesday, 27 June 2007 21:53:50 UTC