- From: Pat Hayes <phayes@ihmc.us>
- Date: Thu, 4 May 2006 14:40:58 -0500
- To: Dan Connolly <connolly@w3.org>
- Cc: public-swbp-wg@w3.org
>On Thu, 2006-05-04 at 01:04 -0400, Booth, David (HP Software - Boston) >wrote: >> Hi Dan, >> >> > From: Dan Connolly [mailto:connolly@w3.org] >> > > From: David Booth >> > . . . >> > > Similarly, if http://weather.example.com/oaxaca identifies a single >> > > resource that is "a periodically updated report on the weather in >> > > Oaxaca"[10], then I don't see how "all of [the] essential >> > > characteristics"[10] of that periodically updated report can be >> > > "conveyed in a message"[10]. >> > >> > Again, it seems to me that we do this routinely. Maybe it >> > takes more than one message and webarch is a bit sloppy here. >> >> But that is the crucial difference! Sure, a *single* weather report can >> be conveyed in a message. But http://weather.example.com/oaxaca is not >> merely identifying a *single* weather report issued at 2005-03-12 >> 23:11:36.236 UTC or any other particular time. It identifies a >> *function* from time to weather reports. I don't know any way to >> transmit "all of [the] essential characteristics"[10] of that particular >> function in a message or even a finite set of messages. >> >> > >> > > Because "information resources" can return different >> > > "representations" >> > > at different times (even if some happen to return the same >> > > representation every time), it seems to me that "information >> > > resources" are by their very nature abstract. >> > >> > Please be careful with your quantifiers. Your argument seems to go >> > from: >> > There are some information that have more than one >> > representation and hence are abstract to >> > All information resources have more than one representation. >> >> Almost. My argument goes from "Some information resources have more >> than one representation and hence are abstract" to "All information >> resources are abstract". Here is the justification. (For clarity, >> I'll avoid the term "abstract" below, and instead speak of "functions >> from time to data", since that is more precise.) >> >> 1. Given: A URI identifies a *single* resource. >> >> 2. Any "information resource" that is intended to be time varying (such >> as the "current weather report in Oaxaca") is obviously a function from >> time to data, as illustrated above. Thus, we know that some >> "information resources" are functions from time to data. > >Actually, in the general case, they may be functions of more that >just time: preferred media type, language, authentication >credentials, even user agent, in some cases. > >> 3. For other "information resources" that are plain Web pages, if those >> Web pages ever change, then those "information resource" must also be >> functions from time to data. > >Well, they must have functions from time to data related to them. >I don't see how you conclude that they are necessarily identical >to those functions. > >> 4. The HTTP protocol and the URI resolution mechanism are such that the >> content associated with a URI *always* has the *potential* of changing. >> Thus, the content associated with a URI is *inherently* changeable over >> time, even if by policy some Web pages are intended to remain constant. > >I don't agree. > >If the IETF says http://www.ietf.org/rfc/rfc822.txt identifies >a piece of text, and not a function from time to data, that's >not just a statement of policy; we have delegated to them the >right to say what the resource _is_. And I don't think they're >contradicting any established norms when they say that it >identifies one piece of text. Seems to me that in cases like this we can just agree to identify a piece of text with any *constant* function from some domain to that piece of text, particularly if the only access anyone can have to the function is to call it and get the value of it, i.e. the text, delivered as a result. Even mathematicians routinely identify constant functions with their values. So whether a web page is 'really' a text or is 'really' a constant function from the set of times (or whatever) to that text seems to me something we can just agree to disagree about, without it mattering. In fact, even the publisher of the text and the reader of the text might disagree about this, without it mattering to either of them. (I think Im agreeing with you here, Dan, right?) > >> 5. I haven't a clue what utility there would be in calling something an > > "information resource" if that thing is never ever intended to return >> some data in a 2xx response to an HTTP GET. >> >> Therefore, by Occam's Razor I conclude: >> >> All "information resources" are functions from time to data. > >Occam's Razor isn't a valid logical inference. It's sometimes appealing, >but never compelling. In this case, I don't find it even appealing. Well, but if I'm right, above, then rather than argue with that position, you should quietly roll your eyes and carry on. Because *anything* can be seen as a constant function from some domain to it. In some ontologies for time and action, you and I are functions from times to people. I'm OK with that, myself, provided none of my salary goes astray. >The more relevant principle is that of minimal constraint. If a >resource owner says their resource is a piece of data, then we >should not constrain them otherwise unless we have really compelling >reasons to do so. > > >> instead of: >> >> Some information resources are functions from time to data, >> while others might merely be constant data. >> >> > . . . I don't think there's any (reasonable) >> > meaning of "words" where the TAG has decided that >> > w:InformationResource has no intersection with it. >> >> If "frog" is a word (i.e., those four letters in sequence), and you >> accept my conclusion above > >I don't. > >> (that w:InformationResources are functions >> from time to data), then "frog" cannot be a w:InformationResource >> because it obviously is not a function from time to data. It is merely >> data. But that is exactly the hair-splitting kind of conclusion I think we should not draw. Sure, it can be a function from time to data, if you like. But if it is a *constant* function to data, then we can treat it as simply *being* data. This much ambiguity, if indeed it even counts as ambiguity, really is harmless. Pat -- --------------------------------------------------------------------- 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 Thursday, 4 May 2006 19:46:02 UTC