Re: semantic paradoxes (was Re: how to handle DAML+OIL syntax in theRDF model theory)

From: Dan Connolly (connolly@w3.org)
Date: 12/03/01


[this conversation has gone somewhat far afield;
let me know if I should stop using joint-committee for it.]

"Peter F. Patel-Schneider" wrote:
> 
> The problem with including meaningful syntax in interpretations is coming
> up with a set of semantic rules that actually work, i.e., don't produce
> paradoxes.

OK; I can see why this concerns you.

This sort of concern about paradoxes has convinced me
that we need to drop "P or not P" from the axioms (er.. axiom schemas)
in whatever logic(s) we use for the Semantic Web.

more related ramblings in...
  http://www.w3.org/DesignIssues/Logic.html


> But when we try to finish this interpretation by determining CEXT(a) we are
> in trouble.  If something is in CEXT(a) then, by the semantic rules for
> complementOf, it has to not be in CEXT(a).  If something is not in CEXT(a)
> then, by the semantic rules for complementOf, it has to be in CEXT(a).

That's the sort of thing that motivates getting rid of "P or not P"...
at least from axioms. I wonder if it allows us to un-answer
questions like this in the semantics.

> There is no way to determine CEXT(a) and thus we have created an
> ill-specified model theory.
> 
> In particular, we have gone from a perfectly good syntactic construct,
> complementOf, that had a perfectly good meaning for reflexive complementOf,
> to an ill-specified model theory.
> 
> Why does this happen?  Well when something is in syntax you can just say,
> by means of the model theory, that there is no way that a construct can
> make sense.  However, when something is in the semantics you don't have
> this liberty because any semantic construct *has* to make sense.
> 
> A similar thing happens, by the way, in axiomatizations.  An axiomatization
> with a similar flaw ends up ends up producing a contradiction from the
> empty set of statements.
[...]

-- 
Dan Connolly, W3C http://www.w3.org/People/Connolly/


This archive was generated by hypermail 2.1.4 : 04/02/02 EST