W3C home > Mailing lists > Public > www-tag@w3.org > April 2008

Re: Uniform access to descriptions

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Wed, 09 Apr 2008 15:21:52 +0100
Message-ID: <47FCD100.2060104@musc.edu>
To: Pat Hayes <phayes@ihmc.us>
CC: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>, Jonathan Rees <jar@creativecommons.org>, "www-tag@w3.org WG" <www-tag@w3.org>, Phil Archer <parcher@icra.org>

Pat Hayes wrote:
> 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:
>>>> <snip>
>>>>> 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 :-)
>>>> 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 
>>>> httpRange-14?
>>> 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.
I tried to work with it.  But it is the TAG's definition that prevent me 
from working with it.  It is the AWWW and httpRange-14 that is not 
willing to accept the randomness, not my viewpoint, right?
>> 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="http://www.example.org/">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.
Yes, I do too.  But do you re-evaluate what you have read about the 
original post where the <a> is put in by checking if the link comes back 
via a 200 or 303 after you click the link.  I don't, would you?

>>> 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.
Pat, I see the problem now.  We agree on that there is no clear 
distinction for IR.  So, let's don't argue in that direction.

My question is very clear and precise.  Do you agree to invoke such 
logic in the web.

If HTTP(x)=200, x=IR
If HTTP(x)=303, x=?

Here is the multiple choice
(1): Yes. 
   (1a) The distinction between 200-303 is important.  (Then, it is you 
who is trying to make a clear distinction, not me.)
   (1b) The relationship between 303 and 200 is not important.  Hence, 
200 and 303 becomes irrelevant and therefore httpRange-14.

(2).  No.  then, any discussion between 200 and 303 is moot and 
therefore httpRange-14.

Tell me your position.  My position is very clear - that is (2).  
Otherwise, I don't know if you are defending for or against my position.

Received on Wednesday, 9 April 2008 14:22:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:20 UTC