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

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

OK so far.

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

Suggestion: lets decide to NEVER make rules that require consistency. 
What we can do is to make rules about what should be done if 
inconsistencies are detected, or about who is responsible for 
clearing up the mess, or whatever. But if we say that its wrong to be 
inconsistent, then the task of being right becomes unmanageably 
complex very quickly.  Its almost impossible to be SURE you are 
avoiding inconsistencies whenever you open your mouth (or your web 
server), even if you want to: and as Peter points out, you may well 
not want to be consistent with everyone.

Pat

>    -- sandro


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes

Received on Thursday, 9 October 2003 09:51:17 UTC