From: Jos de Bruijn <debruijn@inf.unibz.it>

Date: Tue, 11 Mar 2008 18:34:23 +0100

Message-ID: <47D6C29F.4070707@inf.unibz.it>

To: RIF <public-rif-wg@w3.org>

Date: Tue, 11 Mar 2008 18:34:23 +0100

Message-ID: <47D6C29F.4070707@inf.unibz.it>

To: RIF <public-rif-wg@w3.org>

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 ShawReceived on Tuesday, 11 March 2008 17:34:47 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:47:49 UTC
*