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

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

Received on Monday, 11 January 2010 15:43:53 UTC