Re: Uniform access to descriptions

At 7:52 PM +0100 4/8/08, Xiaoshu Wang wrote:
>Pat Hayes wrote:
>>At 5:54 PM +0100 4/8/08, Xiaoshu Wang wrote:
>>>Stuart,
>>>>Wrt to that resolution... a 303 response means *nothing*... if 
>>>>you happen to follow the redirection and find something useful 
>>>>about the thing you originally inquired of, that you trust and 
>>>>are prepared to stick in your reasoning engine, then you win - if 
>>>>not, of itself, the redirection has told you nothing/means 
>>>>nothing.
>>>>
>>>>200 tells you that the response convey as representation of the 
>>>>(state of?) referenced thing.
>>>>
>>>If this is what TAG accepts, i..e, 200=*representation of* as 
>>>oppose to "resource of".  I have no problem and would be happy 
>>>with it.  My perception is that TAG is recommending either 
>>>explicitly or implicitly the latter viewpoint.
>>
>>Gentlemen, please both of you speak very slowly and carefully at 
>>this point, as a precise understanding here is critical.
>>
>>Stuart, did you mean that the response conveys/ a/ representation/ 
>>in the webarch sense/ of the referenced thing? It would be helpful 
>>if every time the word 'represent' and its cognates are used in 
>>this very special sense, such usage were explicitly flagged, as it 
>>can very quickly lead to incomprehension when understood more 
>>broadly (as it is almost everywhere else in the English-speaking 
>>world.)
>>
>>(Xiaoshu: from which it follows that in this case, the referenced 
>>thing in question must be something that/ has/ a 
>>webarch-representation; so, in this case, it/ cannot/ be some other 
>>kind of thing that cannot, by virtue of its very nature, have such 
>>a (webarch-)representation; so, to refer to such things - such, as 
>>we now might say,/ non-information resource things/ - requires 
>>something other than a 200 response. Thus goes the http-range-14 
>>logic, as I understand it. Note that in order to follow this, all 
>>we need to know is that there are things which (a) cannot have a 
>>representation in the webarch sense but (b) that we might wish to 
>>refer to with a URI. Their exact nature need not be specified, but 
>>I believe that the language of 'information resource' boils down to 
>>an attempt to characterize this category of [/things that cannot be 
>>webarch-represented by a byte stream/]. And, centrally important, 
>>not having a representation in the webarch sense does/ not/ mean 
>>not having any kind of representation, being unrepresentable, or 
>>not being describable. The webarch sense of 'representation' is 
>>very specialized and narrow.)
>Pat, as I have detailed argued here 
>http://dfdf.inesc-id.pt/tr/web-arch.  There can have only one 
>consistent interpretation, that is: there is no so-called 
>"information resource".

The key issue is not what is an information resource, but what isn't. 
So, in your document you ask, what makes the claim "A person is not 
an information resource" true? And it seems to me that this at least 
has a clear answer: because a person is not something whose essential 
characteristics can be conveyed in a message. So the conclusion you 
reach about my infamous self-describing reference to myself being 
wrong if we accept http-range-14, is indeed correct.

OK, I take your point: that you don't disagree with me here, but 
instead take the view that nothing satisfies the TAG criterion for an 
information resource, at least as stated by them: "its essential 
characteristics can be conveyed by a message"; so the entire 
discussion is moot, since by the published criterion, according to 
http-range-14, no http request should ever return a 200 code. Which 
is ridiculous, etc.. But here, I simply disagree with you. At best, I 
think what you have shown in http://dfdf.inesc-id.pt/tr/web-arch is 
that the published definition of 'information resource' is faulty. 
Perhaps so: along with a lot of other people, I also don't like it. 
But surely the intention of the TAG was reasonably clear. When a 
browser accesses something we informally call a 'web site' and gets a 
'web page' back to display to its user, clearly said 'page' is a 
reasonably close facsimile (which is, again informally, what 
webarch-representation seems to mean, most of the time) of something, 
and moreover that something has a number of familiar properties: it 
is located on its server, it can respond to http requests, it might 
well have been written in HTML, and so on. We all know this and also 
know, in a pre-philosophical sense, what is being spoken about. We 
also know that it is very hard to give a single definitive 
characterization of these things that we can engage with over the 
internet, partly because the technology keeps changing under our feet 
and extending the possibilities in new ways. Nevertheless, without 
splitting hairs about the exact boundaries of this elusive concept, 
we can all recognize and largely agree on a number of clear-cut 
example and non-example cases. Webpages and jpeg images are examples. 
HTML documents are examples. Non-electronic physical objects and 
abstract or fictional entities are clearly non-examples. The TAG 
bravely, or perhaps foolishly, tried to give an actual definition: 
but rather than seize on this and use it to attack the intention 
seems, even if its good philosophy, not to be the most useful way to 
proceed. Better to take the intention and use it to attack the 
definition :-)

>In this sense, any HTML page is abstract with respect to the web. 
>What is concrete to the web is the "representation" of the resource.

Not in the webarch sense of 'representation'. Those 'representations' 
are transient entities which exist only as they move across the 
physical Web in an http (or xxxtp) response message. They are like 
the photons of the Web: we become aware of them only when they have 
already ceased to exist, by causing changes to our relatively static 
data structures.

>Or we can take TBL's viewpoint.  To make all slash URI as an 
>information resource.

The URIs aren't the information resources themselves: the i.r.'s are 
what are denoted by the slash URIs. And that's not really an 
architectural decision: its more of a rule of semantic 
interpretation. And I (now) think that its the only practical rule to 
adopt in this case, if we have to have any rules at all. And all the 
rest of the decision follows from that.

>  This again gives IR a syntactic definition, which is O.K. and 
>usable.  But the reality that many hash URI are used in a way that 
>will make TBL's position difficult to accept.

? Really? But it seems to me that this position is entirely agnostic 
about the meaning of hash URIrefs. Which indeed is one of its 
strengths.

Pat

>
>I don't mind either way but I do mind the current way, which offers 
>no help but only create confusion.
>
>Xiaoshu


-- 
---------------------------------------------------------------------
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
http://www.ihmc.us/users/phayes      phayesAT-SIGNihmc.us
http://www.flickr.com/pathayes/collections