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

Bottom line: I agree that should not delay RDF/A over this issue, nor
should we attempt to force an immediate answer.  

I do think we have a responsibility to adhere to the TAG's WebArch
guidance and inform the TAG when we find issues in trying to do so.  But
there is no need for this discussion to hold up the RDF/A work or the
SWBP working group.

Personally, I have found Pat's arguments increasingly compelling, even
if I haven't fully grokked them all and I'm still trying to reconcile
them with the WebArch.

David Booth


> -----Original Message-----
> From: Pat Hayes
> 
> >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/2
> 004JanMar/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 Saturday, 4 February 2006 05:06:51 UTC