Re: model theory of error

On Jan 10, 2008, at 10:25 AM, Christian de Sainte Marie wrote:

> Just a small clarification (!), after reading Dave's comment.
>
> Christian de Sainte Marie wrote:
>> How do commonly used implementations of basic logic rule languages  
>> (e.g. various implementations of Prolog, datalog, whatever) handle  
>> the case of evaluated functions or predicates when some argument  
>> is out of there domain of definition?
>
> My point is that, if the most usual ways to handle this kind of  
> errors pratically (that is, in computer implementations), are  
> amenable to one and the same model theoretic semantics, then it is  
> ok for RIF to specify it (well, there are always the costs/benefits  
> to be considered, of course, but that's a different question).
>
> Option (b) feels more likely, in that case, but my feeling may not  
> be the most relevant in that matter :-)
>
> But if they are not amenable to a single model theoretic semantics  
> of error, then we should consider not giving a model theoretic  
> semantics to error in RIF.

To make this concrete (and to check my understanding). There are two  
possibilities on the table: (a) (aim for falsity on error, which I  
personally like and is good for OWL) and (b) which involves new truth  
values blah blah but is, potentially, a better fit for SPARQL and for  
things like SPARQL Rules. But (b) is hard with a lot of risk, so  
Michael proposed picking (a), which is simple and well understood.

But, Christian points out, that means we force SPARQL rules (and any  
other system that doesn't conform with (a), like, perhaps, prolog  
with exceptions? which are....I think?...in ISO prolog?) to be  
incompatible with RIF documents that contain built in functions. So,  
if I translate my OWL rules (using (a)) to a system that handles  
error like (b), I will get different answers to my queries in each  
system. And, in fact, the second system will be *wrong* with respect  
to RIF, thus should reject all RIF documents with builtins to be safe.

Christian is asking how likely this scenario is? If it is very  
likely, then RIF should make it easier to opt out of choice (a)  
without being forced to avoid built-ins. The simplest way to handle  
this is to support builtins systactically but say that their semantic  
on error is implementation dependent. (Though, you could still  
provide (a) as a default...why not?)

Christian, have I captured your concern?

Cheers,
Bijan.

Received on Thursday, 10 January 2008 11:31:05 UTC