- From: Alistair Miles <a.j.miles@rl.ac.uk>
- Date: Fri, 03 Feb 2006 12:36:29 +0000
- To: Pat Hayes <phayes@ihmc.us>
- CC: public-swbp-wg@w3.org
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