Re: Uniform access to descriptions

At 11:01 AM +0100 4/9/08, Xiaoshu Wang wrote:
>Pat Hayes wrote:
>>At 10:28 PM +0100 4/8/08, Xiaoshu Wang wrote:
>>>Pat Hayes wrote:
>>>>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 
>>>> 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 
>>>Sure, we can take an informal definition.  But the issue becomes 
>>>serious when the TAG intend to invoke such logic.  That is: if _:x 
>>>HTTP-200 => _:x a webarch:IR.  The question was raised with good 
>>>intention because if without such logic, what is the point of 
>>Fair enough.
>>>Then, here is the dilemma: If I publish something in RDF, I must 
>>>worry if something is an IR or not.  Because in logic, a single 
>>>contradiction will invalidate the entire theory.
>>Not on the main path, but I disagree with you here also. Logic 
>>basically gives up when faced with an inconsistency, but that does 
>>not imply that one inconsistency makes the entire theory useless. 
>>There are many ways to isolate or ignore contradictions which can 
>>be deployed in practice. But still, I agree we should try to get it 
>>right wherever possible.
>>>  Hence, I must know precisely the definition of IR in order to 
>>>ensure that my data won't (unnecessarily) lead to such 
>>>contradiction. But I cannot do that with the current definition.
>>But you can in many (most?) cases. Here's what you do. You have a 
>>URI and something in mind you want it to denote. Now, give that URI 
>>to a browser and see what happens. If you get a 404, the URI is 
>>yours to command. If you get a 303 then its still yours, but it 
>>would be good manners to make it denote something connected with 
>>the result of the 303 somehow. If you get a 200, then you ask 
>>yourself the following question: is/ whatever sent me this 
>>response/ the very thing I have in mind that I want my URI to 
>>denote? If the answer is yes, go ahead. If not, use a different URI 
>>or (if you can) alter the response it returns when GETted.
>How do I judge that *many(most)*.  The web - and semantic web - is 
>essentially want to take care of one thing - that is to make the 
>meaning of ad hoc communication as clear as possible.  This 
>ambiguous many(most) is, in fact, resulted from the ambiguous 
>definition of IR, isn't that so?

Actually no, it results from the fact that the Web has randomness in 
it. And such scruffiness is inherent in any artifact this big, and 
nothing can be done about it, so we need to work with it rather than 
complain about it.

>Let's me use this analogy, when you received a mail (or email, such 
>as this), do you judge its content by *how* it is delivered to you? 
>I don't know about you, but I don't.

Neither do I. Did I say anything to suggest otherwise? But if someone 
types hypertext which says "For more information, see <a 
href="">this</a>. " then I usually take it 
that the writer is referring to the web page at the end of the link. 
Don't you? And that is all that http-range-14 says.

>>My point is that this is all that http-range-14 really/ requires 
>>you to actually do/. You can ignore the metaphysics and the 
>>confusion and the definition-soup and so on.
>>>Then, since I can always be accused wrong regardless of my best intension,
>>Well, you can be accused, but it seems to me that the above 
>>algorithm also gives you a good defense. Remember, you never have 
>>to justify a claim that something is an information resource, only 
>>that it isn't.
>If I don't know what is an IR, how do I judge what it isn't?  This 
>is essentially what Tim responded to my question.  He said: well !IR 
><> non-IR.  Then, what is the intersection of IR and non-IR.  This 
>is not an answer, this is to avoid answer and then it is useless, 
>don't you think so?

No. The world is full of cases of concepts which have clear examples 
and non-examples but which are very hard to specify near their edges, 
so very hard to give exact definitions for. Colors are the 
often-cited canonical example. There are reds which everyone will 
agree are red and blues which everyone will agree are non-reds, but 
near the red/orange boundary nobody will agree, even with themselves 
from day to day. Natural concepts often resist precise definitions. 
That doesn't stop them being extremely useful, however.

>>>  what is the point for me to use 303 instead of 200?  The latter 
>>>is cheaper and easier. If eventually, everyone has felt the same 
>>>dilemma that I felt and choose 200 anyway, then by public verdict, 
>>>httpRange-14 becomes useless.
>>Well, true, but I don't see that happening, in fact. My own private 
>>conclusion is that http-range-14 makes sense, but the moral I draw 
>>from it is to never, under any circumstances, use an unhashed URI 
>>to denote anything but a webpage or a deliverable document of some 
>>kind. Which is a kind of conformity by avoidance, but much simpler 
>>to satisfy than trying to mess around with 303 codes.
>Use *unhashed URI* is what TBL proposed.  As I said before, it can 
>work.  But it works is not by answering httpRange-14 or the 
>definition of IR, but by - as you said - *conformity by avoidance*. 
>This again showed how bad the definition of IR is.  httpRediction-57 
>is the same thing to *conformity by avoidance*.  My solution is to 
>simply ignore it because we cannot hide forever.
>If we take TBL's view + httpRange-14, then any "slash URI" cannot be 
>discussed with "hash URI". Unless, we give IR a syntactic 
>definition, i.e., any resource denoted by a URI ended with a slash. 
>But this again makes any 200->IR irrelevant, right?
>>>On the other hand, if we don't invoke the earlier introduced 
>>>logic, what is the point of httpRange-14?
>>See above.
>>>>>In this sense, any HTML page is abstract with respect to the 
>>>>>web.  What is concrete to the web is the "representation" of the 
>>>>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.
>>>It is!  What is parsed in your browser is the *representation* of 
>>>the resource denoted by that URI, which is always abstract w.r.t. 
>>>to the web-architecture.
>>My browser is/ sent/ a representation, but it then creates 
>>something else in my RAM which I get to view and store away for 
>>later. Or at least that is my understanding of the official story 
>>about webarch-representations.
>>>  We always understand reality from its representation. What I 
>>>perceived you is not you but your representation in my brain.
>>Well now we are doing real philosophy, but that is wrong. My 
>>perception (of, say, a tree I am looking at) is maybe constituted 
>>by representations in my brain, but what I/ perceive/ is the actual 
>>tree. We cannot, in fact, perceive our own mental representations: 
>>if we could, cognitive science would be a lot easier than it in 
>>fact is.
>>>  When you dereference, you 
>>>didn't get that resource, you get a *representation* or 
>>>*description* of that resource.
>>Not a description, but a webarch:representation of it, yes. But I 
>>got that/ from/ the actual resource. It was the resource that sent 
>>it to me. (If there hadn't been a resource there to send it, I 
>>wouldn't have got it; just as if there hadn't been a tree to bounce 
>>photons off, I wouldn't have my mental representation of the tree.) 
>>And it is the resource which sent me the representation that (in 
>>the case of a 200 code, according to http-range-14) the URI 
>>denotes, not the representation that it sent.
>Not really.  Let's me give you this example.  Take two colors Red 
>and Green as an example. Can you give me a proof that what I 
>*called* Red is actually what you perceived Green and vice versa? 
>In other words, if you can distinguish model 1 from model 2?
>Model 1: Green(xiao:Red= pat:Green) Red(xiao:Green=pat:Red)
>Model 2: Green(xiao:Red= pat:Red) Red(xiao:Red=pat:Red)
>If you cannot, it therefore proves that the actual reality (such as 
>Green and Red) is always unknown and is in the eye of beholder.  But 
>does what reality actually is matter?  It does NOT.  What matters is 
>*the consistency* between our descriptions about the same reality.

We really are having a philosophical disagreement here. This would 
take too long. Suffice it to say I disagree with your conclusion. 
Reality is, well, real, and it does matter. Your argument above is 
faulty, by confusing green as a descriptor of qualia with green as a 
descriptor of light.

>>>Just remind you that there are a few mime-type for 
>>> (text/plain, 
>>>text/html, image/svg+xml, image/jpeg, and image/gif).  This is an 
>>>area that TAG hasn't been able to address yet.  But again, it can 
>>>be consistent if we assume that a URI always denote an abstract 
>>>resource and *representation* is what you get.
>>Im not sure what you mean by 'abstract resource'. For example, I am 
>>pretty sure that I am myself not very abstract at all.
>Abstract means there is always something potentially unknown about 
>the resource.  What we get - a description (or representation) - 
>could be an asymptotically close one but never the one.

Ah, I see. A rather unfortunate word to use for this idea, but never 
mind. Seems to me that IRs are precisely those that are not abstract 
in this sense. The plurality of mime types just makes them more 
complicated to fully represent, but they can be 'fully' represented, 
is the point.



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

Received on Wednesday, 9 April 2008 13:54:21 UTC