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

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.

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.

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

Received on Tuesday, 12 January 2010 01:35:34 UTC