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

Hi all,

I agree with Pat that the proposed response is not something I am  
comfortable with.  We never intended, as a WG, to open a can of worms  
in this way.  Instead, we intended to suggest clarification on the  
best way ("best practice") to interpret httpRange-14 for Semantic Web  
developers.  Somewhere, we lost sight of that goal.

I do not see the sense in asking the TAG to coin a new URI for  
information resources.  I am also reminded of that assumption that  
RDF is meant to *describe resources*, thus encoding metadata, and  
that there is no distinction between "metadata" and "data".  They are  
both information.

Perhaps paradoxically, I am more comfortable with the idea of HTTP  
interactions as assertions.  Ralph, DavidB and I discussed this in  
light of httpRange-14 in July and August, and I concluded that Web  
servers are making a sort of assertion when choosing to reply in a  
particular manner.  However, if we are not going to resolve the term  
"information resources", then we shouldn't resolve the type of  
assertions being made about them.

My suggestion is to either (a) return to a purely practical, SemWeb- 
oriented discussion of the impact of httpRange-14 or (b) forget about  
taking a position on this issue.  The mail archives hold my position  
on (a) and I am becoming increasingly more comfortable with (b).

Regards,
Dave
(chair hat off)


On 2 Feb2006, at 17:28, 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
>
>
> -- 
> ---------------------------------------------------------------------
> 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 Monday, 6 February 2006 15:18:06 UTC