Re: model theory of error

> Michael Kifer wrote:
> > Last Tuesday we were unable to resolve the issue of builtin functions
> > because we could not decide on their semantics. The problem is that builtin
> > functions are partial and are supposed to return an error if given wrong
> > arguments.
> > 
> > One approach we considered was to simulate them using predicates by
> > translating functional expressions into formulas that involve builtin
> > predicates. Unfortunately, this has a problem that occurrences of such
> > functions in the conclusions of rules must have a different translation
> > than the occurrences in rule premises. This was perceived as a problem if
> > we were to consider BLD as a subset of the (future) first-order dialect,
> > since the first-order dialect will not have such a distinction.
> > 
> > I thought a bit about a direct model-theoretic semantics, and there is at
> > least one solution that does not seem too complicated. Comments are welcome.
> > 
> > 1. We need a special constant (not sure if it should be in rif:IRI or
> >    in its own symbol space) of the form rif:error.
> > 
> > 2. The domain of interpretation of any semantic structure will also have a
> >    special distinguished element called _|_.
> > 
> > 3. All semantic structures will be required to interpret rif:error as _|_
> >    (i.e., I_const(rif:error) = _|_)
> > 
> > 4. The builtin functions will be defined so that they will return rif:error
> >    whenever their arguments are of the wrong type.
> > 
> > 5. For predicates, we have two options.
> >    a. The simplest option is to say that a predicate, p(a,b,c,...), is false if
> >       any of its arguments evaluates to _|_ in the interpretation.
> > 
> >    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 _|_.
> > 
> >   The advantage of option (b) over option (a) is that we have an explicit
> >   representation for errors. 
> 
> The handing of truth value E in option b) seems to be very exactly the 
> way SPARQL handles errors in built-ins in FILTER expressions.

SPARQL ended up not having a model theory in the end, and their treatment
of truth values is based on "guts feeling", which is often incorrect.  As I
said, I do not actually favor option (b). My guts feeling is that it would
break somewhere, but by that time we will have wasted too much time on it.

> >   The disadvantage is that it is much more complicated. Many results need
> >   to be ported to account for this new truth value, and I did not check
> >   this carefully. Quite possible that this idea breaks somewhere.
> > 
> >   I think option (b) is too much work for very little gain.
> > 
> > Comments? (esp. if anyone can see whether option (a) breaks somewhere)
> 
> Does that mean you suggest only builtin-functions and no bult-in predicates?

I never indicated something like that.


	--michael  



> Dr. Axel Polleres
> email: axel@polleres.net  url: http://www.polleres.net/
> 
> rdf:Resource owl:differentFrom xsd:anyURI .
>

Received on Saturday, 5 January 2008 17:53:57 UTC