W3C home > Mailing lists > Public > www-tag@w3.org > June 2009

Re: Splitting vs. Interpreting

From: Xiaoshu Wang <wangxiao@musc.edu>
Date: Thu, 18 Jun 2009 12:12:19 -0400
Message-ID: <4A3A6763.2030406@musc.edu>
To: Pat Hayes <phayes@ihmc.us>
CC: "Sean B. Palmer" <sean@miscoranda.com>, "david@dbooth.org" <david@dbooth.org>, "www-tag@w3.org" <www-tag@w3.org>
Pat Hayes wrote:
>
> On Jun 18, 2009, at 9:36 AM, Xiaoshu Wang wrote:
>
>> Sean B. Palmer wrote:
>>> Sorry, looks like I had an old address on file for you.
>>>
>>> ---------- Forwarded message ----------
>>> From: Sean B. Palmer <sean@miscoranda.com <mailto:sean@miscoranda.com>>
>>> Date: Tue, Jun 16, 2009 at 8:23 PM
>>> Subject: Splitting vs. Interpreting
>>> To: David Booth <dbooth@hp.com <mailto:dbooth@hp.com>>
>>> Cc: www-tag@w3.org <mailto:www-tag@w3.org>
>>>
>>> You write about ambiguous and specific references here:
>>>
>>> http://dbooth.org/2007/splitting/
>>>
>>> When I worked on EARL in 2002, we had to solve httpRange-14, and we
>>> did it in a practical way which your splitting document reminds me of.
>>>
>>> We might want to evaluate a tool of some kind in EARL, say the W3C
>>> Validator. But then we didn't know whether validator.w3.org was the
>>> tool itself or a page about the tool. That's httpRange-14 in a
>>> nutshell, before it was “solved” with the 303 hack.
>>>
>>> So what we did was this:
>>>
>>> <http://validator.w3.org/> earl:tool _:Validator .
>>>
>>> The clever bit is that the earl:tool property says: if the subject is
>>> a Document (i.e. an IR), then the object is the Tool described by that
>>> document; whereas if the subject is a Tool, then the object is simply
>>> the same thing as the subject.
>>>  
>> The solution is cleaver only because it pushes the ball to someone 
>> else.  But it does not solve any problem at all.  Whoever is to 
>> deploy the resource is still burdened with the impossible question: 
>> is what s/he is about to deploy is a Document or not because she 
>> needs the answer to know if s/he should 200 or 303.  Or she needs  
>> The real issue is that TAG, for whatever reason that I cannot 
>> understand, refuses to acknowledge such a simple truth:  what you get 
>> from a URI is NOT what a URI denotes.
>
> But why not? Seems to me that the absoluteness of your negative 
> judgement here is just as wrong as the naive positive judgement. The 
> very power of descriptive logics arises from their being 
> topic-neutral: they can describe, their names can refer to, anything 
> at all. And I see no reason to *exclude* 'what you get from a URI' 
> from that universe of possible referents.
What I am saying is: they are different, individually but not 
universally. This is the problem -- I think the core of all 
philosophical and logic argument -- the distinction between individuals 
and universals. 

Universally, you can do anything you want with a your URI.  But you 
*define* it to be that way, not because there is something 
*intrinsically* different in that way.  This is the gist, as far as I 
can understand, what makes Wittgeinstein to say that "meaning is use".  
The use of a symbol, which a URI is, is defined a priori to make a 
distinction but not assigned to some a priori distinction.

We can, for instance, define the term "document" to denote a thing that 
has no mass, as Stuart once suggested, that is fine because it has an 
*object* criteria so the *definition* is pragmatic.  But to think in the 
reverse, i.e., to find something intrinsic to a thing which we can call 
them document is *always* a waste of time.  Try to find any, I do mean 
*any*, concept, and see if you can find a clear definition.  You don't 
because there is always an exception.  That is what Russel tried to 
suggest -- to avoid build class so to avoid contradiction.  But then 
there is still a Russell's paradox. 

>
>> We never know what a URI denotes -- it is our purpose to share that 
>> knowledge.  But the sharing is achieve from sharing what we get from 
>> the URI.
>
> I agree the two roles are distinct, but one and the same thing might 
> be both the shared thing and the topic of the content represented in 
> that shared thing. And in this case, we *can* know what the URi denotes.
No.  We always communicate through symbols.  They never share.
> In fact, this is how referents are attached to things in daily life, 
> by explicit ostention. I pass you a book, and I say "read this, you 
> will enjoy it". My referential word "this" is attached to the actual 
> book by the causal nexus of my utterance being linked to the act of 
> passing the actual book.
Sure, this only establish the relationship between "this" and the 
"book".  It says nothing about what "the book" means to you or to me.  
In this case, what you meant "this" is the content of the book but not 
the physical signals, such as light or the mass, that transmitted to me, 
right? So, what is the "this" that you are passing me?
> What http-range-14 says is just like this, in a Web setting. If you 
> toss a URI at me and I pass you back a 200-coded reply, I am in effect 
> saying "/This/ entity involved in the this transaction, here and now, 
> is what you are asking about; it is the thing that the name you just 
> used refers to".
This is my point: what is the actual entity that is involved in the 
transaction?  Is it the byte-stream that you received or what the URI 
denote?

Xiaoshu
>
> Pat
>
>> *Document* is what we get from a URI but *resource* is not.  I have 
>> argued this in the past as well as in the upcoming paper at IR-KR2009 
>> (http://ir-kr.okkam.org/workshop-program/ir-kr-ijcai-09-program).
>>
>> Once we understand the above distinction.  The remedy is simple.  We 
>> need to solve it *syntactically* by using a URI convention to denote 
>> what is we get from a URI, which I have proposed in another 
>>  manuscript to ISWC 2009 (which fate I don't know).
>>
>> Xiaoshu
>>
>>> And as you can imagine, this is extensible to interpreting ambiguous
>>> resources in all kinds of ways. Now the TAG finding says that it's
>>> removed a certain level of ambiguity, but there are other ambiguities
>>> one might want to resolve when a page 303s and then still doesn't
>>> define carefully what's at the end of it. So the EARL method is much
>>> more practical.
>>>
>>> You might also want to think a bit harder about statements such as
>>> “there is no architectural need for Person and IR to be considered
>>> disjoint”. Consider if you were using Facebook and it started
>>> conflating people with groups and games and so on. But of course
>>> people break the rules of the web until they matter, and since there's
>>> no Semantic Web User Agent this rule doesn't matter.
>>>
>>> I'm not saying that the TAG finding should be canned because you can
>>> use the kind of interpretation properties that I've described as a way
>>> around it. The point is rendered moot by various architectural
>>> problems. But you ought to compare the 2002 and 2009 architectural
>>> solutions carefully.
>>>
>>>  
>>
>>
>>
>>
>
> ------------------------------------------------------------
> IHMC                                     (850)434 8903 or (650)494 3973   
> 40 South Alcaniz St.           (850)202 4416   office
> Pensacola                            (850)202 4440   fax
> FL 32502                              (850)291 0667   mobile
> phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
>
>
>
>
Received on Thursday, 18 June 2009 16:12:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:14 GMT