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: Mon, 16 Dec 2002 10:26:33 +0000
Message-Id: <5.1.0.14.2.20021216092905.0451bd90@127.0.0.1>
To: pat hayes <phayes@ai.uwf.edu>
Cc: jjc@hplb.hpl.hp.com, connolly@w3.org, bwm@hplb.hpl.hp.com, w3c-rdfcore-wg@w3.org

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.

What I'm trying to capture here is the idea that there are "social 
conventions" which are in some way bound to technology deployments.  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.

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.


>>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.  How can this be clearer?

To my mind, technical != formal.

>>  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.

Which suggests to me:  s/defining/authorized/.

>   (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.

#g


-------------------
Graham Klyne
<GK@NineByNine.org>
Received on Monday, 16 December 2002 08:11:24 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:54:55 EDT