Re: [ALL] Draft message to TAG re httpRange-14

Hi Pat,

The idea behind question (2) was to clarify the meaning of the TAG 
resolution of httpRange-14 [1]. It seems that much of the current 
debate, especially surrounding RDF/A, assumes that the statement given 
in (2) (i.e. that HTTP responses are also assertions) is implied by [1]. 
Why not give the TAG a chance to say: "yes"/"no"/"we're not sure"? If 
the TAG says "yes" and SWBPD-WG says "no" then we at least know where we 
all stand. I think you're argument below would make an excellent basis 
for a SWBPD-WG position.

Perhaps we could simply ask the TAG to 'consider' question (2), and 
leave out question (1)?

Al.


[1] http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html

Pat Hayes wrote:
>> Hi all,
>>
>> Here's another attempt at a draft message to the TAG requesting 
>> clarification on the httpRange-14 resolution, taking into account 
>> David Booth's comments, and trying to be as concise as possible:
>>
>> ---
>>
>> 1. The class of 'information resources'.
>>
>> Could the TAG please coin a URI to denote the class of 'information 
>> resources', and indicate which specifications establish the definition 
>> of this class.
>>
>> Could the TAG also list any named classes it believes to be disjoint 
>> with the class of 'information resources'.
>>
>> (The rest of this message assumes that such a URI has been coined, and 
>> uses the name 'tag:InformationResource' as an abbreviation for this URI.)
>>
>> 2. HTTP interactions as assertions.
>>
>> Is an HTTP response also an assertion?
>>
>> E.g. if an HTTP server receives the following request:
>>
>> GET /foo HTTP/1.1
>> Host: www.example.com
>>
>> ... and issues the following response:
>>
>> HTTP/1.x 200 OK
>>
>> ... is this response equivalent to the assertion that the following 
>> RDF graph (given using Notation 3 syntax) is true:
>>
>> {
>>   <http://www.example.com/foo> rdf:type tag:InformationResource.
>> }
>>
>> ...?
>>
>> ---
>>
>> I think this is all that's needed for the moment, and hopefully gets 
>> to the crux of the matter. If the answer to the second point is 'yes'
> 
> Please, please, do not do this. The risk is too great.
> 
>> , then we can follow up and ask about the meaning of other response codes
> 
> Codes should not be said to have meanings in this sense. This entire 
> discussion is insane.
> 
>> , and of the implications for secondary resources given the 
>> content-types returned; also we can ask more obvious questions such 
>> as: what is the necessity or inherent value in treating HTTP responses 
>> as assertions? What kind of application might find it necessary or 
>> useful to do so? ... But there's no point in asking these questions 
>> until the position on point (2) is known.
> 
> I think you have this exactly the wrong way around. Surely, the 
> appropriate way to move forward here would be to FIRST ask the questions 
> that you say there is no point in asking. What possible value could 
> there be in treating an http response as an assertion? None. What 
> application could make use of it, if it were so treated? So far, none. 
> More to the point, what applications would fail, if it were not so 
> treated? None. So why would the answer matter? Particularly when the 
> question is close to being crazy anyway.
> 
> There are dangers in insisting on an answer. There is every indication 
> that this question raises open research issues which demand a wider set 
> of skills than have been applied to it so far. It seems to me that even 
> posing the question in this form is a symptom of a category error, one 
> which violates a distinction between architectural levels (note that the 
> original version of the thorny question referred to the *range* of http, 
> applying a mathematical/semantic concept to a transfer protocol: there 
> is something wonky right there), and seems to be very close to a 
> confusion of level with metalevel. These are exactly the areas and 
> topics where the TAG's publications and pronouncements have in the past 
> not always been entirely consistent or clear.
> 
> For example, the very fact that the architecture document places such 
> importance on the distinction between 'information resources' and other 
> kinds of resource, means that it misses the basic point. The central 
> distinction that needs to be got clear is not between different kinds of 
> thing, but between different kinds of *relationship* between names and 
> things. The relationship of 'identifying', in the sense in which this is 
> used when discussing network architecture, and the relationship of 
> referring or denoting or naming, are what need to be distinguished, 
> among other reasons because the first indeed must not be ambiguous but 
> the second cannot fail to be ambiguous. The architecture document 
> follows every other publication from the W3C in using the ambiguous word 
> "identifies" for both of these meanings, and thereby cannot fail but be 
> confused and confusing.
> 
> For my sins, I may be partly to blame for this focus in the architecture 
> document on the information-resource/non-information-resource 
> distinction. 
> (http://lists.w3.org/Archives/Public/public-webarch-comments/2004JanMar/1057 
> ) But my only reason for emphasizing this distinction in that long 
> comment was to give rhetorical emphasis to the identify/refer 
> distinction, by pointing out that the first sense of 'identify' simply 
> cannot be applied to a non-information kind of thing. My point was to 
> ask the TAG to carefully distinguish the two senses of "identify". 
> Unfortunately, they seem to have gotten the rhetoric confused with the 
> point. We are now poised on the brink of fixing into stone a global 
> framework in which the semantic relationship between a name/identifier 
> and its referent/resource is determined not by any coherent semantic 
> theory, but by what 'kind' of thing it is. Which of course is 
> nonsensical, because a name can refer to any kind of thing.
> 
>> Hopefully an answer to (2) will enable us to develop a clear position 
>> wrt both RDF/A and PURLs.
>>
>> What do you think?
> 
> I think we are in a terminological and conceptual muddle, and asking the 
> TAG to encapsulate this muddle in a URI naming scheme will only freeze 
> the mud and make it permanent; whereas if we simply leave it alone and 
> let it settle, some clarity may eventually re-appear.
> 
> Suppose that the URI that you request were indeed coined, what utility 
> would it provide? It would be possible to infer that something was not 
> in that class. But that is not an interesting conclusion, since the 
> reality of membership in this class can be tested on the Web itself. So 
> assertions using it are either useless or false: more likely the latter. 
> We will have gone past Russell and Goedel by making possible a whole new 
> category of self-referential paradoxes, allowing the creation of texts 
> which do not assert that they are false or unprovable, but that they are 
> un-transmittable, so that the acts of reading them in a browser or 
> importing them into a reasoner will automatically prove them false.
> 
> The best thing to do, I suggest, is to leave sleeping dogs lie. The 
> current architecture document is confused about this fundamental issue, 
> and eventually the world will figure this out and deal with it. 
> Meanwhile, simply move ahead and systematically ignore this mire of 
> confusion. The possible ambiguity between referring to a thing by using 
> a text, and referring to the text itself, is almost universal in all 
> languages and has apparently never given rise to any practical problems, 
> although it did give logicians minor palpitations for a few years. I 
> predict that it will not give rise to any practical problems on the 
> semantic web either, and that any minor problems that arise can be 
> handled as they do crop up, by a combination of easy software hacks, 
> styles of ontology writing and patterns of usage becoming stable in 
> communities. The result will be that a de facto set of conventions will 
> emerge to distinguish reference from identification, and reference to a 
> text from reference to the text's referent (like the familiar logician's 
> quotation conventions, or the use of italic case, or the 'display 
> paragraph' convention used in literature) and at some future date will 
> become set in stone by a future WG which will have a more informed 
> basis, and a much larger set of use cases, for making such decisions. In 
> the meantime, we will all muddle along reasonably well, I predict. What 
> are the worst things that could happen? If some piece of software 
> concludes that I have nine (or thirteen) letters, I will know what it 
> really meant. If it concludes that "Pat Hayes"^^xsd:string is a person, 
> I will not be offended, and many programs will just quietly conclude 
> that this really means "is the name of a person", without starting an 
> argument. (Really smart programs might even try to look the character 
> string up in a suitable directory.) If it tries to send an email to my 
> website, the internet architecture will robustly inform it of its error. 
> The sky will not fall in any of these cases.
> 
> Let us recognize that text can be used to identify things in all sorts 
> of ways, accept that there will be more of them in use than we are ever 
> going to be able to legislate about, and go ahead to try to provide 
> tools that people might find useful. RDF/A is much too potentially 
> useful for its deployment to be delayed by trying to resolve issues in 
> the philosophy of language.
> 
> Pat Hayes
> 
>>
>> -- 
>> Alistair Miles
>> Research Associate
>> CCLRC - Rutherford Appleton Laboratory
>> Building R1 Room 1.60
>> Fermi Avenue
>> Chilton
>> Didcot
>> Oxfordshire OX11 0QX
>> United Kingdom
>> Email: a.j.miles@rl.ac.uk
>> Tel: +44 (0)1235 445440
> 
> 

-- 
Alistair Miles
Research Associate
CCLRC - Rutherford Appleton Laboratory
Building R1 Room 1.60
Fermi Avenue
Chilton
Didcot
Oxfordshire OX11 0QX
United Kingdom
Email: a.j.miles@rl.ac.uk
Tel: +44 (0)1235 445440

Received on Friday, 3 February 2006 12:38:10 UTC