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

Basically, I agree. We cannot find THE semantics because different systems
treat these erroneous situations somewhat differently. So, I am proposing a
simple semantics (simply because we have to give a semantics) and the
compliance clause would say something like what you said above.

	--michael  


> Christian, have I captured your concern?
> 
> Cheers,
> Bijan.
>

Received on Thursday, 10 January 2008 14:54:18 UTC