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

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

From: Sandro Hawke <sandro@w3.org>
Date: Wed, 08 Oct 2003 17:14:30 -0400
Message-Id: <200310082114.h98LEUvU025610@roke.hawke.org>
To: public-sw-meaning@w3.org

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.

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.

    -- sandro
Received on Wednesday, 8 October 2003 17:14:17 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:56:01 UTC