- From: Stuart Williams <skw@hp.com>
- Date: Mon, 15 Jun 2009 22:09:27 +0100
- To: Pat Hayes <phayes@ihmc.us>
- CC: Jonathan Rees <jar@creativecommons.org>, David Booth <david@dbooth.org>, AWWSW TF <public-awwsw@w3.org>
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