W3C home > Mailing lists > Public > www-tag@w3.org > January 2010

Re: usage of 'resource' vs 'representation' in HTML 5, CSS, HTML 4, SVG, ...

From: Pat Hayes <phayes@ihmc.us>
Date: Mon, 11 Jan 2010 21:43:02 -0600
Cc: Dan Connolly <connolly@w3.org>, "www-tag@w3.org" <www-tag@w3.org>
Message-Id: <D6E915AE-23F8-4EBB-A5B3-A4381363EF10@ihmc.us>
To: Martin J. Dürst <duerst@it.aoyama.ac.jp>

On Jan 11, 2010, at 7:34 PM, Martin J. Dürst wrote:

> Hello Pat,
> I'm not sure if you misunderstood me, but I didn't really want to  
> claim that numbers don't exist. I mainly wanted to point out, with a  
> hopefully much clearer example, that the argument about whether  
> resources exist or not (which Ian brought up) isn't really helpful  
> in deciding whether the term should be used or not.

Ah, then we entirely agree. Sorry if my philosophical feathers got  
prematurely ruffled.

> So what I'm saying is "Even if you [take a nominalistic viewpoint  
> and] claim that numbers don't 'exist', this doesn't mean that it  
> doesn't make sense to talk about numbers. So even if you claim that  
> resources don't 'exist', this doesn't mean that it doesn't make  
> sense to talk about resources."
> Regards,    Martin.
> P.S.: I haven't done philosophy of mathematics, so I have never  
> thought about this too deeply, but if I had to, I'd probably  
> strongly tend towards thinking that numbers DO exist.

It really is VERY hard work being a nominalist mathematician :-)


> On 2010/01/12 0:42, Pat Hayes wrote:
>> On Jan 11, 2010, at 1:30 AM, Martin J. Dürst wrote:
>>> Hello Dan, dear TAG,
>>> On 2009/12/10 13:55, Dan Connolly wrote:
>>>> The clock has started on this issue in the HTML WG; proposals are  
>>>> due
>>>> January 16, 2010
>>>> http://lists.w3.org/Archives/Public/public-html/2009Dec/0256.html
>>>> I'm thinking out loud a bit here...
>>>> I'm sympathetic to this viewpoint:
>>>> "the confusion is caused by trying to reference something that  
>>>> doesn't
>>>> exist. There is no such thing as what you call a "resource" --  
>>>> it's an
>>>> abstract concept that has no correspondance to the real world. It  
>>>> is
>>>> unnecessary and makes talking about our infrastructure more
>>>> complicated."
>>>> -- http://lists.w3.org/Archives/Public/public-html/2009Sep/ 
>>>> 1133.html
>>> I was reading this a few weeks ago, and didn't feel comfortable  
>>> with it.
>>> Recently, I think I found a way to explain why. Consider the  
>>> following
>>> text:
>>> "the confusion is caused by trying to reference something that  
>>> doesn't
>>> exist. There is no such thing as what you call a "number" -- it's an
>>> abstract concept that has no correspondence to the real world."
>>> Indeed numbers don't exist in the real world. I can have five  
>>> oranges
>>> or five apples, or hold up five fingers, but "five", what's that?  
>>> Can
>>> you show me "five"? No. It will always be "five something".
>> Martin, you really should not be trying to do philosophy of  
>> mathematics
>> in a forum like this. The point of view you are (very loosely)
>> expounding here is called 'nominalism'. It is one point of view,  
>> but by
>> no means obvious or widely accepted. In my own view, like that of  
>> most
>> working mathematicians, numbers *do* exist. I cannot SHOW you five,  
>> of
>> course, because it is not physical; nevertheless, it does exist. (I
>> would say, OF COURSE numbers exist in the real world. If they did  
>> not,
>> equations would have no solution - because to have a solution  
>> means, a
>> solution (which is a number assignment to the variables of the  
>> equation)
>> *exists* - but they do; ergo, numbers exist.) And numbers can  
>> certainly
>> be referred to. In fact, IMO - admittedly more controversial -
>> nonexistent things can be referred to: you know who I mean by the  
>> name
>> "Sherlock Holmes", for example.
>> The problem with nominalism, by the way, is similar to that of
>> atmospheric corrosion: it is very hard to stop it, once you start  
>> it up.
>> Numbers don't exist in the real world... so, do programs exist? After
>> all, a program file is just a binary file, which is nothing but a
>> sequence of bits. Isn't the program itself just an imaginary
>> abstraction? And what about those 'bits', aren't they *really*, in  
>> the
>> *real* world, just electrical patterns in very small circuits? All  
>> you
>> have argued here, in fact, is that there is a level of abstraction  
>> from
>> the ultimate physical reality that you happen to be personally
>> comfortable with (roughly, system-level programming, involving  
>> files and
>> addresses), and you have decided is 'real'; anything above that is  
>> not
>> 'real' for you. But your choice of 'real' is just as arbitrary as
>> everyone else's. By my lights, your reality is way down in the weeds.
>> When I read a web page, I am thinking about the weather in Oaxcala,  
>> not
>> about files and addresses.
>> Pat Hayes
>>> Nevertheless, I guess most people agree that "five", and numbers in
>>> general, are immensely useful, even if they don't exist in the real
>>> world.
>>>> Meanwhile, the translation impact suggests otherwise:
>>>> http://lists.w3.org/Archives/Public/public-html/2009Sep/1136.html
>>> That talks about the issue of translating the term "resource".
>>> There's also the issue of language negotiation.
>>> http://httpd.apache.org/docs/2.2/, for example, looks different  
>>> for me
>>> in Opera (where the top language in Accept-Language is English)  
>>> and in
>>> Safari (where it's Japanese). Yet it's the same URI, and the same
>>> resource (the top page of Apache HTTP Server Version 2.2  
>>> documentation).
>>>> Ian points out usage that suggests "a resource is a bag of bits"
>>>> in HTML 4, CSS, SVG etc.
>>>> http://lists.w3.org/Archives/Public/public-html/2009Sep/1132.html
>>>> Roy Fielding dismisses those as "just examples," but I think it's
>>>> a bit more subtle than that... I think the webarch view of those  
>>>> usages
>>>> is that typically, a URI identifies
>>>> pretty much a file... the kind whose contents change over time,  
>>>> not the
>>>> contents of the file at any one time. So to say '<xyz.html>  
>>>> identifies
>>>> an HTML file' is not to say that it identifies a bag/sequence of  
>>>> bits,
>>>> but rather that it identifies a resource whose representations  
>>>> have mime
>>>> type text/html .
>>>> But as I say, I'm sympathetic to the position that (outside of the
>>>> Semantic Web) this
>>>> abstraction just makes talking about all this stuff more  
>>>> complicated.
>>>> Meanwhile, Ian also says:
>>>> This is actually intended to refer to "bag of bits". It  
>>>> identifies a
>>>> bag of bits in the same way that a telephone number identifies a
>>>> person. Sure, if you call a number at different times you might  
>>>> end up
>>>> with different people, but you're still using a phone number to
>>>> identify a person, you just don't know which one until you try to  
>>>> use
>>>> the phone.
>>> Well, that's true in some cases (where you use the phone number to
>>> "identify" several people living there), but in many cases, it's
>>> actually not true. There's definitely the very frequent case that  
>>> you
>>> have a phone number identifying (for yourself) a single person, but
>>> where you're not sure you'll get him/her, or somebody else from the
>>> family (who exactly you don't really care). There's also the case  
>>> that
>>> the phone gets answered by a (to you) complete stranger or somebody
>>> you wouldn't expect (and therefore wouldn't identify by that phone
>>> number) because that (to you) complete stranger happened to visit  
>>> and
>>> e.g. was asked to pick up the phone and tell you that the phone's
>>> owner is just washing the dishes or whatever, and will call back  
>>> soon.
>>>> I find that usage of "identify" very unappealing. I think normal  
>>>> usage
>>>> of "identify"
>>>> is unambiguous. If I say "In this game, teams are identified by
>>>> color" and
>>>> then told you that blue identifies team X and a different team Y,  
>>>> you'd
>>>> consider that nonsense.
>>> Yes indeed.
>>> Regards, Martin.
>>>> I wonder about some terminology that just relates URIs with byte
>>>> sequences,
>>>> without going thru the intermediate concept of resources, and yet
>>>> doesn't
>>>> use "identify" in this confusing sense.
>>>> Something like:
>>>> A URL is a key typically used to retrieve a page from the Web; more
>>>> generally,
>>>> it is used as an address in the Web, whether to find documents,
>>>> mailboxes,
>>>> services, applications, etc.
>>>> "navigation marker" also appeals to me, though I'm not sure  
>>>> there's any
>>>> specific place
>>>> in the HTML 5 spec to talk about it that way.
>>>> So "find" in place of "identifiy". Somewhat ironic... "find" is a
>>>> synonym for "locate"...
>>>> so maybe...
>>>> A URL is a key, typically used to locate a Web page; more  
>>>> generally,
>>>> it is
>>>> used to locate mailboxes, services, applications, etc.
>>>> (footnote: I try to tow the party line where the standard term is  
>>>> 'URI'
>>>> rather than 'URL',
>>>> but only out of duty/burden/obligation; somewhere between RFC2396  
>>>> in '98
>>>> and 3986 in '05, I tried to convince TimBL and the TAG that it's  
>>>> pushing
>>>> water uphill to try
>>>> to get the community to learn 'URI' rather than just going with  
>>>> the flow
>>>> and using 'URL',
>>>> but I couldn't make the sale. I'm reasonably happy to see  
>>>> arguments on
>>>> both sides examined
>>>> in some detail in the context of working out IRI interop stuff.)
>>>> But maybe not... I think the analogy with files suggests that  
>>>> 'locate'
>>>> raises
>>>> the same issues as 'identify'; that is: filenames name files... or
>>>> identify files... or
>>>> locate files; in any case, when you open a file, edit it, and  
>>>> save it
>>>> back, it's
>>>> still the same file, and the filename identifies/names/locates/ 
>>>> refers to
>>>> the file,
>>>> not its contents at a given time. This analogy works with  
>>>> variables in a
>>>> program, too:
>>>> x = 1
>>>> y = 2
>>>> x = y + 2
>>>> There's just one variable called/named x; the name 'x' doesn't  
>>>> refer to
>>>> 1 nor to 3, but rather to
>>>> the place in memory that holds 1 at first and then 3.
>>>> I guess it's only in very informal glosses that you can skip from  
>>>> the
>>>> URL to the sequence-of-bytes
>>>> without referring to the notion in between... though 'retrieve'  
>>>> does
>>>> seem to get around it.
>>>> Filenames can be used to retrieve sequences of bytes... variable  
>>>> names
>>>> can be used
>>>> to retrieve values. 'retrieve' doesn't generalize to mailto: and  
>>>> POST so
>>>> well, but as Ian
>>>> pointed out somewhere in the thread, the HTML 5 spec doesn't need  
>>>> that
>>>> generalization.
>>>> One specific case that the terminology showed up in the HTML 5  
>>>> spec was
>>>> around
>>>> caches, I think; in that case, it's clear to me that the simplest  
>>>> way to
>>>> talk about
>>>> it is to talk about caching responses... or the content of response
>>>> messages.
>>>> Something like that.
>>>> I hope to look at a few specific cases of HTML 5 spec text, but  
>>>> it's
>>>> late here and
>>>> I already spent a lot more time on this message than I intended  
>>>> to...
>>> --
>>> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
>>> #-# http://www.sw.it.aoyama.ac.jp mailto:duerst@it.aoyama.ac.jp
>> ------------------------------------------------------------
>> IHMC (850)434 8903 or (650)494 3973
>> 40 South Alcaniz St. (850)202 4416 office
>> Pensacola (850)202 4440 fax
>> FL 32502 (850)291 0667 mobile
>> phayesAT-SIGNihmc.us http://www.ihmc.us/users/phayes
> -- 
> #-# Martin J. Dürst, Professor, Aoyama Gakuin University
> #-# http://www.sw.it.aoyama.ac.jp   mailto:duerst@it.aoyama.ac.jp

IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Tuesday, 12 January 2010 03:44:10 UTC

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