the weather in Oaxaca

On Apr 9, 2008, at 5:39 PM, Pat Hayes wrote:
> At 2:52 PM -0400 4/9/08, Alan Ruttenberg wrote:
>> On Apr 9, 2008, at 10:25 AM, Pat Hayes wrote:
>>>> I've always had a bit of problem working through thinking of  
>>>> them, though. How about this example from AWWW
>>>>> the resource is a periodically updated report on the weather in  
>>>>> Oaxaca
>>>>>
>>>>
>>>> What are the rigid properties here, and how are they communicated?
>>>
>>> Well, for a report, I'd say that the rigid properties were its  
>>> being a report, which is something analogous to its mime type,  
>>> and the actual symbols (and maybe graphics) in the text of the  
>>> report, ie enough information about them to reconstitute their  
>>> appearance on a surface. Which is pretty much an html document  
>>> with associated jpegs and so forth.

Just noticed another issue with this description  - it doesn't allow  
for the fact that CN can return the report in a different language,  
in which case the appearance of  the symbols might not at all  
resemble other CN available representations.

>>>
>>
>> This would be the properties of what I think of as a static report  
>> or web page. However they don't work for the example I asked for  
>> advice on in at least two ways: 1) The resource is a report that  
>> changes
>
> Ah, I missed that. OK, but I think the same criteria apply. In this  
> case though the rigid property is that it is a periodically updated  
> report. Sorry if this sounds vacuous, but I think its accurate. We  
> have an idea of what a periodically updated report is, so that if  
> we do a refresh and the screen changes we say, its updated, rather  
> than, it changed!

Well, there are lots of ways the screen can change and not all of  
them are what would be considered to be updates to the reports, so I  
don't see how this helps at all.

> Very like the distinction between a static image and a movie, which  
> is just a sequence of static images, after all.

Similarly, I don't think the common definition of movie would allow  
for arbitrary sequences of static images, so again, while evocative,  
I don't see how it helps.

>
>> and 2) It doesn't mention Oaxaca or weather, so if we used these  
>> as the sole criteria then the thing could equally be a soil  
>> acidity report from the most active volcano in the world.
>
> Yes, and I think this is right.

I'm not sure what you are saying is right. Do you mean that the  
architecture described in AWWW would say that a server returning a  
soil acidity report report about some volcano is a valid way to  
respond to a request regarding the resource AWWW names as http:// 
weather.example.com/oaxaca?

> Its arguable whether these are rigid properties. But if you think  
> they ought to be, then we can include them, I'm cool with that. In  
> this case I wouldn't say theres a matter of fact involved.

This isn't a matter of me wanting or not wanting to include  
something. Recall that the question was how to interpret "essential  
characteristics", because understanding these would give us a way to  
know which things weren't information entities. Specifically if  
something's essential characteristics could be conveyed in a message  
then we have an IR, otherwise not.

Here's where I think this is going: In order to understand http:// 
weather.example.com/oaxaca's, we need to have it that being about the  
weather is Oaxaca is a rigid property. The weather in Oaxaca is as  
unconveyable in a message as a person or a piece of cheese or a  
disease or a chemical compound or a galaxy or Sherlock Holmes or a  
dead Roman emperor (apologies to... you).

You argued in a previous message that I was worrying about boundary  
cases, that in most cases we could clearly see which sort of thing  
was an IR and which not. I'm worried that this isn't the case at all,  
that when we look at an example that should be squarely "in" the IR  
camp (it's in the FM, after all), we still have problems figuring out  
which sort of thing it is.

-Alan

Received on Saturday, 12 April 2008 23:33:38 UTC