Re: Back to HTTP semantics

Pat Hayes wrote:
> On Jun 15, 2009, at 12:18 PM, Williams, Stuart (HP Labs, Bristol) wrote:
>
>   
>> Hello Jonathan,
>>
>>     
>>> -----Original Message-----
>>> From: Jonathan Rees [mailto:jar@creativecommons.org]
>>> Sent: 15 June 2009 17:17
>>> To: Williams, Stuart (HP Labs, Bristol)
>>> Cc: Pat Hayes; David Booth; AWWSW TF
>>> Subject: Re: Back to HTTP semantics
>>>
>>> On Mon, Jun 15, 2009 at 10:56 AM, Williams, Stuart (HP Labs,
>>> Bristol)<skw@hp.com> wrote:
>>>       
>>>> the meme that RDF interpretration of URI are constrained
>>>>         
>>> by what might be called the Web natural interpretation is not
>>> original to me. Whilst I can understand and appreciate the
>>> denial that you mention in RDFMT with respect to the
>>> formalism presented there in - leaving interpretation
>>> unconstrained by the web itself - I think there are many who
>>> see interpretation implicitly constrained in that way when
>>> one joins the logical system RDF with the pragmatics of the
>>> web. Eg. If in RDF one were to use http://www.w3.org as a
>>> reference to my left foot, there would be an inconsistency in
>>> the total system even that were not so from the RDF
>>> interpretation alone.
>>>
>>> I was not talking about memes or implicit constraints, which are a
>>> different matter. This is sort of like saying people should only use
>>> the C programming language for programming computers. It's  
>>> empirically
>>> mostly true, and why would you want to use it for any other reason?  
>>> So
>>> what's the problem?
>>>
>>> If you can find a *normative* statement explicitly connecting RFC2396
>>> "identification" to RDF "interpretation" I'll give you 10 quid (next
>>> time I see you).
>>>       
>> I think that your £10 is safe :-).
>>
>> I think that for some people (principally from a web background),  
>> the connection is so obvious that it hardly needs stating
>>     
>
> Which is a large part of the problem. That obviousness of the non- 
> obvious has been the single most corrosive influence on TAG-level  
> theorizing, IMO. It lies behind almost all the large conceptual  
> mistakes that we are still trying to deal with, such as conflating  
> naming and accessing under the single term 'identification', and then  
> getting that muddled idea further muddled up with notions of identity,  
> or (God help us) Platonic ideals.
>
> <noise>Grrrrrr.</noise>
>
>   
:-)... I'll take my due share of the received 'grrr...ing'.
>> ; whilst for others it is obvious to neatly (and explicitly)  
>> decouple a formal RDF interpretation form a "web-interpretation"  
>> rendering not particular significance to the choice of using URI as  
>> a naming system.
>>     
>
> AAaaargh.  URIs are NOT a naming system. Programming identifiers are  
> NOT names. If someone declares "a" to be a real and writes "a :=  
> 43.27", that does not give a name to a number, nor even to a container  
> of a number.  (If "a" names anything, it would probably be a  
> continuant, a second-order function from states to state-state  
> functions; but even that sense of naming is really little more than a  
> metaphor.)
Ok...point taken, though I feel compelled to ask what for you would 
characterise a naming system - eg. it seems to me that DNS might well 
fail to pass muster under this scrutiny.
>  When I was asked to invent a model theory for RDF, I asked  
> about this quite explicitly and carefully, and got an unequivocal  
> answer. RDF is not a programming system, with a semantics suited to  
> such a system. RDF is not about identifiers with values in states, and  
> functions on those states, or about containers and file systems and  
> network traffic. RDF is supposed to be a general descriptive logic.  
> Weak, but general. It has to have a logical semantics, which talks  
> about what names denote. I asked: how does the use of URIrefs to be  
> names restrict or qualify what those names denote? And again, the  
> explicit answer from Tim and DanC and others was, none.
Oh that's interesting... because think that they might have been 
answering what at least sounds to me like a different question - 
roughly, "are there any kinds of think that cannot be named using 
(http?) URIRefs" ie a question about classes of things rather than about 
individuals.

>  There are no  
> constraints: A URIref can refer to anything at all.
Again whilst I wouldn't want to put words in mouths I take that as being 
an answer about the class of things a URI could name...

I think that once a URI had been used to designate a particular thing, 
you might have got a very different answer about your freedoms to have 
it designate something else ("Cool URIs..." and all that). I suppose 
deep down due to changes in DNS name ownership or sheer perverseness, we 
can peel the URI 'name' label off the jar and stick it on something else 
- but I believe that the intent of Web Architecture is that you don't do 
that - that it is a bad thing to do.
> At one early stage  
> I actually suggested that we say normatively, as part of the  
> semantics, that URIs denote Web pages (or whatever), and that idea was  
> immediately squashed like a bug. What URIrefs refer to, which the RDF  
> semantics was supposed to address, has got **nothing at all** to do  
> with Web pages or containers or files, etc..
>   
Wow... not a conversation I was involved with... I can see that from the 
pov of generating a model theory as you did, that makes life less 
complicated - leaves interpretation unconstrained by this ill-defined 
web thing - but it does surprise me for web things that have been 
blessed with (stable?) URIs.
>> I suspect that few from the GOFW world will have picked up on the  
>> explicit denial in RDFMT that Pat referred us to.
>>     
>
> Well, someone would have to be very dense to have read the MT document  
> and not had this made pretty clear. But then I suspect that very few  
> people in the GOFW world have, or ever will, read the RDF MT :-)
>   
Well I wasn't going to be so direct as to make that claim....
> Pat
>   
Stuart

Received on Monday, 15 June 2009 21:10:18 UTC