W3C home > Mailing lists > Public > public-sw-meaning@w3.org > October 2003

Re: what matters is what's said, not what's meant

From: Peter F. Patel-Schneider <pfps@research.bell-labs.com>
Date: Wed, 08 Oct 2003 22:03:45 -0400 (EDT)
Message-Id: <20031008.220345.68535856.pfps@research.bell-labs.com>
To: sandro@w3.org
Cc: public-sw-meaning@w3.org

From: Sandro Hawke <sandro@w3.org>
Subject: what matters is what's said, not what's meant
Date: Wed, 08 Oct 2003 17:14:30 -0400

> Here's the simple, obvious, and wrong approach to URI semantics: for
> each URI (at least for certain URI schemes), someone gets to pick what
> the URI denotes in all RDF interpretations.    I own hawke.org, so I
> get to pick that http://hawke.org/2003/10/8/Taiko denotes one of my
> dogs and http://hawke.org/2003/10/8/Tsuzumi denotes the other.  Now it
> becomes a matter of fact that (given suitable @prefixes):
>     hawke:Taiko owl:differentFrom hawke:Tsuzumi.
> and it is simply false that
>     hawke:Taiko rdf:type owl:Class.
> 
> This approach is is unworkable because it relies on a kind of
> telepathic communication with shared mental precision that doesn't
> really exist.  For something as concrete as my dogs, our intuition
> suggests it would work, but even then it breaks down when you look
> closely enough at what hawke:Taiko really means.  (But I wont try to
> argue this more unless someone actually disagrees.)
> 
> We can fix this by saying it's not that the owner gets to pick what
> the URI denotes in all RDF interpretations, it's that the owner gets
> to make privileged statements using the URI.  More specifically, there
> are several privileged statements associated with a URI: the message
> in which the namer originally introduced the term, the web content the
> host serves right now, what standards bodies say about it, etc.
> 
> So when you use a URI, you are doing so in concert with some body of
> prior uses, which you may or may not know about.  We need some way to
> standardize expectations about which prior uses should be privileged.
> We also need to say how your use should relate to the prior uses when
> we decide should be considered privileged.  "Use implies consent" says
> your use consitutes an assertion of the privileged prior content.
> This ranges of awkward to ridiculous depending how you draw the lines
> about what is privileged.
> 
> How about instead: your use MUST be logically consistent with
> privileged prior uses.  Really we can have strongly-privileged
> corresponding to rfc2119:MUST and weakly-privileged corresponding to
> rfc2119:SHOULD.  I'd like to strongly privilege only known-static
> content -- the original namer's introduction of the term -- and weakly
> privilege the current host content.

I fail to see how requiring uses to be logically consistent with privileged
prior uses is significantly better than use implying consent (read import
here if you like) to privileged prior uses.  In my opinion it is generally
the case that if you don't want to disagree with privileged prior use then
you want to consent to this previous prior use.

To pick on my favourite example, if I want to discuss a particular invoice
and I don't disagree with the statements about that invoice made by the
creator of that invoice, say for example to claim that the invoice is
invalid in some way, then I almost always want to consent to these
statements.

> If there was an inconsistency, users might well be told about it.
> They'd look at your RDF file and some tool would say: "Oh, by the way,
> this file is not consistent with the terms it uses, as they are
> originally/officially/currently defined.  Do you really want to take
> this joker seriously?"  Or something like that.   I'm hoping we'll
> encourage the existence of such tools.

Hmm.  I hope that this sort of value judgement does not become part of the
fabric of the Semantic Web.  

>     -- sandro

peter
Received on Wednesday, 8 October 2003 22:04:00 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:42:15 GMT