[TED] Semantics for errors in RIF

Dear all,

There still seems to be confusion about what semantics for errors we 
agreed on at the face-to-face in Paris.
I already made a summary of the outcome for someone outside of the 
working group.  So, for those who do not recall the discussion and/or 
decision exactly, or those who were not at the face-to-face:

== Built-Ins and Errors ==

The semantics of built-in predicates and functions is defined in the 
usual way in case there are no errors.

Errors can occur in a number of ways, for example:
1- there can be an error in input values of function or evaluation, e.g. 
"a"+1 (addition is not defined for strings) or x/0 (division by zero is 
an error)
2- there can be an error in a built-in predicates, e.g. 
numeric-greater-than("a",0) (numeric comparison is not defined for strings)
3- there can be an error in a non-built-in predicate, resulting from an 
error in a built-in function, e.g. p("a"+0)

For errors in functions (case 1), we chose the following approach: there 
is an element in the domain called "error"; this element does not have a 
syntactical representation.  The return value of every erroneous input 
of a built-in function is "error".

For the cases 2 and 3 the basic problem is to add determined the truth 
value of erroneous tuples, where an erroneous tuple is either a tuple in 
a built-in predicate with erroneous input, or a tuple that contains the 
"error" element.
We considered three approaches:
a- define a truth value "error/undefined" and amend the model theory 
accordingly
b- the truth value of every erroneous tuple is "false"
c- the RIF model theory does not prescribe the truth value of erroneous 
tuples; this is left up to the user

Since we are under time pressure and since we did not know exactly how 
to define a model theory of error (especially quantification will be a 
problem), we discarded option a.

Option b seems reasonable, but breaks as soon as negation is added to 
the language (not greater("a",1) which be true).
Therefore, we went for option c, and recommend using "guards", which are 
built-ins of the form isString, isInteger, etc,  in rule bodies.


Best, Jos
-- 
                          debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw