W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > December 2002

Re: Social meanings [was:Re: interpretations, time, and HTTP...]

From: Graham Klyne <GK@NineByNine.org>
Date: Tue, 17 Dec 2002 11:15:04 +0000
Message-Id: <>
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].


[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:
>>>>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. "
>>>>>>  --
>>>>>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.
>>>   (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.
>>Graham Klyne
>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
Received on Tuesday, 17 December 2002 06:25:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:54:03 UTC