# Re: model theory of error [Yes, proposing one!]

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Wed, 16 Jan 2008 02:04:40 -0500
To: Christian de Sainte Marie <csma@ilog.fr>
Cc: RIF WG <public-rif-wg@w3.org>
Message-ID: <27282.1200467080@cs.sunysb.edu>
```

>
> Michael Kifer wrote:
> >>
> >>What if the new truth value E was such that:
> >>  ~E = E/\F = E/\T = E\/F = E\/T
> >>     = E :- T = E :- F = T :- E = F :- E
> >>     = Forall E = Exists E
> >>     = E
> >>so that as soon as you have an E somewhere, everything becomes E (so,
> >>the intuitive semantics of E is more like "undefined" than "error")?
> >
> > This is not a truth table for undefined (U). With the U value, U/\F=F and
> > U\/T=T.  In any case, it is not very clear what the truth table should
> > really be. In my proposal the only diff with yours was E\/T=T, but I think
> > I made a typo there (do not remember what I was thinking).
>
> No, apparently, what you were thinking is to use a thruth table for
> undefined:

I did not want it to be like undefined, but I do not know what is the right
thing here.

> >    b. This option introduces a new truth value, called E (error) such that
> >       ~E = E, E/\F=F, E/\T=E, E\/F=E, E\/T=T. Then we can say that
> >       p(a,b,c,...) has truth value E if at least of of the args is _|_.
>
> So, we might call option (b) the "undefined" option, and the one
> corresponding to the truth table where everything that touches E becomes
> E: the "error" option.

>From the above table it is obvious that not everything that touches E is E.

> > So, I consider this a risky path given our time constraints.
>
> But we must consider it to make an informed decision, right?

"Consider" means that somebody would do the job of checking the
implications.

With "undefined" the chances that things work out are much higher than with
"error". However, using undefined for builtins is a waste of effort.
Undefined value is used in many cases, including the well-founded
negation. In that case, even if you derive that something is undefined you
cannot claim that there is an error. So, using "undefined" for builtins
looses its rationale completely. Likewise, a 3-valued FOL dialect will be
hosed.

--michael

> >>>Comments? (esp. if anyone can see whether option (a) breaks somewhere)
> >
> > It is not easy to "see" something like that. One needs to check, which is
> > very time consuming.  My crystal ball says that the chances of breakage are
> > over 50%.
>