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

Michael,

So, while you were drinking vodka, I paused and tried to think instead 
of reacting with my reptilian brain; and (thanx to that very useless 
meeting I have to attend this morning :-) I looked a little bit into 
something I had had in the back of my head all the time and got too 
carried out to consider further...

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")?

Would that lead somewhere?

The intuition is that such an E would allow us to say that a RIF dialect 
does not guarantee any useful meaning if rules retrieved from the format 
are used in a way that is not supported by the dialect.

In the present case, it would allow us to say that BLD does not carry 
any useful meaning as soon as a builtin is applied to an out-of-domain 
argument, thus allowing one implementation to throw an exception, 
another one to add an error fact in a fact base, yet another to continue 
drawing inferences at its own risk (possibly notifying the user that 
these inferences are not necessarily intended by the producer of the 
rules retrieved from RIF) etc.

Would that be a workable direction to explore?

> 4. The builtin functions will be defined so that they will return rif:error
>    whenever their arguments are of the wrong type.

Another question I had in mind (but I am not sure how important it is) 
is: can we do without introducing rif:error? That is, specify directly 
something like:
                           /
                           | I_F(f)(I(t1),...,I(tn)) if all args are ok
     I(f ( t1 ... tn )) = <
                           | _|_ if one argument is of the wrong type
                           \

> Comments? (esp. if anyone can see whether option (a) breaks somewhere)

Ideally, we should specify E in suc a way that extensions (standard or 
user-defined) of BLD could give it stronger semantics, e.g. 
corresponding to options (a) or (b).

Christian

Received on Friday, 11 January 2008 12:57:35 UTC