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

>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

Received on Monday, 16 December 2002 12:02:40 UTC