- From: Graham Klyne <GK@NineByNine.org>
- Date: Tue, 17 Dec 2002 11:15:04 +0000
- To: pat hayes <phayes@ai.uwf.edu>
- Cc: jjc@hplb.hpl.hp.com, w3c-rdfcore-wg@w3.org
I'm somewhat relieved we've not been harbouring a fundamental misunderstanding. I've added this as a new issue [1] to the RDF concepts last-call-candidate issue list [2]. #g -- [1] http://www.ninebynine.org/wip/DocIssues/RDF-Concepts/102-SocialMeaning.html [2] http://www.ninebynine.org/wip/DocIssues/RDFConceptIssues-group-lcc.html At 11:02 AM 12/16/02 -0600, pat hayes wrote: >>At 11:12 AM 12/15/02 -0600, pat hayes wrote: >>>... I am currently completely puzzled about this. We seem to have taken >>>a 180-degree turn on this issue in the last week or so, with no >>>discussion (?). This is far more basic and important than getting >>>things like reification right.) >> >>OK, the words need to be better, but I don't think this is a 180-degree turn. >> >>The particular words were an attempt to respond to an issue raised by DanC: >>http://www.ninebynine.org/wip/DocIssues/RDF-Concepts/017-DefiningURIMeaning.html >> >>>>At 11:56 AM 12/14/02 -0600, pat hayes wrote: >>>>>>> There is nothing anywhere in RDF that assumes that a uriref has >>>>>>> anything at all to do with whatever happens when you use that uriref >>>>>>> in an HTTP protocol. >>>>>> >>>>>>Well, there is for example this text in a draft of one >>>>>>of the RDF specs: >>>>>> >>>>>>"The social conventions surrounding use of RDF assume that any RDF URI >>>>>>reference gains its meaning from some defining individual, organization >>>>>>or context. This applies most notably to RDF predicate URI references. " >>>>>> -- >>>>>>http://lists.w3.org/Archives/Public/www-archive/2002Dec/att-0053/00-rc#section-authority >>>>> >>>>>That doesn't refer to HTTP, though, right? The defining authority is >>>>>using the urirefs in names in *its* RDF , same as everyone else. >>>> >>>>Er, well... The next paragraph says: >>>>[[ >>>>These social conventions are rooted in the URI specification [URI] and >>>>registration procedures [URI-REG]. >>> >>>Strike that sentence. It is just plain wrong, even ridiculous. Social >>>conventions were formed millenia ago. Social specification of meaning >>>didn't start when HTTP was invented. >> >>Nor did it end when HTTP was invented, surely? I suspect we're using >>different interpretations here; I regard the meaning assigned to >>character combinations used by teenagers in their mobile phone text >>messages to be a social convention as much as any word-meaning that was >>established millennia ago. By "social convention" I mean something like >>a common understanding derived in part from social processes. > >Me too, which is why that sentence is silly. It seems to say that social >processes were impossible before URIs were invented. > >>What I'm trying to capture here is the idea that there are "social >>conventions" which are in some way bound to technology deployments. > >Seems to me that that is exactly what we should NOT be saying. The whole >point of this stuff, I always thought, was that the 'social' notions of >asserting publicly, referring to, responsibility for lying and being >libellous, making promises, etc, etc, are all *just the same* as they >always have been, that the technology doesnt *change* any of that, it just >provides new ways to do all that old-fashioned stuff. And that RDF is part >of that whole process, and should be understood as being; just because it >is 'formal' doesn't enable users to wriggle out of their normal social >obligations. Now, exactly *how* RDF publication gets treated in this >social way is something that is not in our purview, seems to me: we ought >not to even be trying to do that, that's like declaring how words shall be >used by novelists in the future, or pre-guessing what the Supreme Court is >going to decide. So for example maybe things will pan out so that at some >future date, a new mime type is established and a dialect of RDF defined >to allow 'ironic' RDF which is different in social meaning, but not formal >meaning, from current RDF. We do not want to go on record as saying >anything that would prevent that happening or require the RDF specs to be >re-written if it does. > >> Again, using the mobile phone text message for example: suppose I >> prepare and address a message to a colleague that describes some other >> person as a yob; if I don't select the SEND function, but merely store >> it in my phone, I don't think I have libelled anyone. But if I do select >> the SEND function, things change. And if someone else steals my phone >> and decides to send the message, who is guilty of libel (modulo >> proof)? I think the answers all depend on social conventions, some of >> which concern the use of technology. > >Right, but one wouldn't expect the phone manufacturer to be making >pronouncements about usage and libel law, would you? > >> >>Nothing here has any impact on the formal meaning. So maybe that's one >>thing that needs to be clearer? >> >>Also, my use of the phrase "rooted in" is wrong. "derive in part from" >>maybe? URI scheme registration is, after all, very much a social process. > >I really don't see why we even need to mention URI registration issues at >all here. That seems to be someone else's business, unless we want to say >that how RDF is interpreted depends in some subtle way on URI registration >schemes: in which case, we should say what that way is, as clearly as possible. > >> >> >>>>A URI scheme registration refers to a specification of the detailed >>>>syntax and interpretation for that scheme, from which the defining >>>>authority for a given URI may be deduced. In the case of http: URIs, >>>>the defining specification is the HTTP protocol specification [HTTP], >>>>which specifies how to use the HTTP protocol to obtain a resource >>>>representation from the host named in the URI; thus, the owner of the >>>>indicated DNS domain controls (observable aspects of) the URI's meaning. >>>>]] >>>> >>>>But note: nothing here impacts the formal semantics; this talks about >>>>the social and technical conventions >>> >>>NO!! It ought to be about *social* meaning, not *technical* >>>conventions. There is nothing social about the http protocol >>>specification. If it is a technical convention which influences meanings >>>then it ought to be at least mentioned in the MT. You seem to have >>>sneaked some formal semantics in by the back door here, please take it >>>back out again (or make it precise). >> >>I don't see how this is formal semantics. > >The notion of 'definition' is DIRECTLY concerned with the same notion of >meaning that the formal semantics addresses. If certain pieces of RDF are >considered definitions rather than merely assertions, then we ought to >have that distinction in the MT as clearly and explicitly as possible. And >if, on the other hand, there is in fact no notion of 'definition' in RDF >semantics, then we shouldnt have a whole section of the concepts doc >giving what reads like a dense, technical explanation of what this >nonexistent idea is supposed to mean. > >> How can this be clearer? >> >>To my mind, technical != formal. > >To my mind they are almost identical. Look at the definition of 'formal' >in the glossary. > >> >>>> whereby URIs may gain authoritative meaning or intended interpretation. >>> >>>I read this part of the concepts doc as saying that one uses [URI] and >>>[URI-REG] to *locate the defining authority*, not to *interpret* what >>>the defining authority is saying. If it is saying more than that, it >>>needs either to be removed, or to be re-written more clearly and >>>unambiguously, and corresponding changes made in other documents. >> >>No, it's not saying more than that. In this example, the technical >>mechanism is used to find out what the defining authority is saying (or >>not saying in the case of a non-200 response code), not how to interpret it. >> >>>I would suggest the following minimal revisions in any case, given the >>>discussion in this thread. >>> >>>1. Strike the first sentence. >> >>I thought the relationship to URI scheme registration was an important >>point here. Dan, help? >> >>>2. Avoid the use of the word 'interpretation' in the second sentence (or >>>give an explicit warning note to the effect that this is not the same >>>word as used in the semantics document.) >> >>Yes, I agree, that's confusing. >> >>>3. Remove the phrase 'defining specification', which is misleading in >>>this context. The HTTP protocol does not define the RDF interpretation >>>of http: URIs. ... >> >>Correct. But it does tell you how to get hold of some "definitive" >>information that MAY be expressed in RDF and hence MAY be defining >>according to the RDF interpretation. The same information at a >>different http: URI would not carry the same authority. It was not my >>expectation that "defining specification" would necessarily indicate a >>formal definition, rather one that was authorized. > >By whom? To do what? > >> >>Which suggests to me: s/defining/authorized/. > >That would be better, although I think its inaccurate, since authorization >can be transferred. The intended meaning of owl:imports can be seen as a >kind of transference of authorization, for example. > >In general , this whole issue is a can of worms to get exactly right, so >the less specific we are, the better, seems to me. We should be diluting >the colors here, not painting bold clear strokes. > >Can't we just say that all uris can be traced to their 'owner' using >standard (ie non-RDF-particular) protocols and registration rules, and >that any uses of a uriref in any RDF published by the owner of the uriref >can be taken to be assertions made by the owner, and hence authoritative, >but that the owner is not necessarily responsible for assertions made in >RDF published by others, even if they use the owner's URIs. In other >words, I cannot be held responsible for anything that someone else says >using my vocabulary; but I am responsible for using other people's >vocabulary in ways that reflect their published intended meanings. > >Seems to me that this is about all that we need to say (maybe with some >examples) and that it is potentially dangerous to say more than this. I >would prefer to avoid all references to 'defining' or 'definitive' or >'interpretation' when talking about RDF meanings. > >Pat > > >> >>> (Right?? If this is wrong then we should specify *in the MT* that >>> http: URIs have a particular way of being interpreted. That change >>> would be easy to make and would not affect any of the formal stuff, but >>> it would greatly increase the clarity for readers; assuming that it is >>> true, of course. I am currently completely puzzled about this. We seem >>> to have taken a 180-degree turn on this issue in the last week or so, >>> with no discussion (?). This is far more basic and important than >>> getting things like reification right.) >> >>OK, the words need to be better, but I don't think this is a 180-degree turn. > >OK, I see that it isn't. But the fact that I read it as being one from >your language is what I am now worried about. > >>#g >> >> >>------------------- >>Graham Klyne >><GK@NineByNine.org> > > >-- >--------------------------------------------------------------------- >IHMC (850)434 8903 home >40 South Alcaniz St. (850)202 4416 office >Pensacola (850)202 4440 fax >FL 32501 (850)291 0667 cell >phayes@ai.uwf.edu http://www.coginst.uwf.edu/~phayes >s.pam@ai.uwf.edu for spam ------------------- Graham Klyne <GK@NineByNine.org>
Received on Tuesday, 17 December 2002 06:25:51 UTC