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

>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


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

Received on Thursday, 2 February 2006 22:28:28 UTC