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

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

From: pat hayes <phayes@ai.uwf.edu>
Date: Sun, 15 Dec 2002 11:12:44 -0600
Message-Id: <p05111b24ba225fbc1b08@[]>
To: Graham Klyne <GK@NineByNine.org>, jjc@hplb.hpl.hp.com, connolly@w3.org, bwm@hplb.hpl.hp.com
Cc: w3c-rdfcore-wg@w3.org

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

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

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

I would suggest the following minimal revisions in any case, given 
the discussion in this thread.

1. Strike the first sentence.

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

3. Remove the phrase 'defining specification', which is misleading in 
this context. The HTTP protocol does not define the RDF 
interpretation of http: URIs.  (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.)


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 Sunday, 15 December 2002 12:12:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:19 UTC