Re: evaluable predicates, general definition

> Michael Kifer wrote:
> >> Michael Kifer wrote:
> >>>> Michael Kifer wrote:
> >>>>> Model theory of builtin predicates is not a problem. Modes (binding
> >>>>> patterns) are extra-logical. We have to decide what do about them in terms
> >>>>> of our recommendation (e.g., issue an error and abort).
> >>>> Do you think the definition of binding patterns below works?
> >>> What do you mean by "works"? I was talking about a model-theory.  I did not
> >>> find a model-theoretic definition (for binding patterns) in what you wrote
> >>> below.
> >> I meant to say: the fixed interpretation  has to guarantee that for any 
> >> fixed input parameters, a finite and uniquely determined number of 
> >> output tuples is true in any model.
> >>
> >> Would that work?
> > 
> > Why do we need to mention this? Of course, any usable builtin would have
> > this property, but why do we need to say this in the model theory?
> > Does it make any difference for anything?
> 
> well, as you say it makes the difference between usable and unusable.
> and by binding patterns we make it possible to declare how a built-in is 
> usable. I think that makes sense, whether in the model-theory (yes, 
> probbly that declaration doesn't belong there, but I never claimed that) 
> or elsewhere, I don't care. Harold suggested we could write that down 
> similarly or along with the signatures.

Of course, binding patterns should be given in the specification of each
builtin. But why put what you are suggesting into the definition of a model
theory? How is it going to change anything? Model theory is about entailment.
What diff is it going to make?


> >>>> BTW: One thing which is non-standard in the Eiter et al. definition is 
> >>>> that an the extension of a predicate can be input.
> >>>>
> >>>>> Builtin functions present a bigger challenge. They can also have fixed
> >>>>> interpretation as functions, but builtin functions are partial, so they
> >>>>> require special treatment in the model theory, and I am not sure if this
> >>>>> complication is worth the trouble.
> >>>> Would an extra "error" constant value solve that problem?
> >>> Yes. This is what I called a "complication". Once you have this constant,
> >>> you need to explain what would be the truth value of things like
> >>> p(abc,error) and Not p(abc,error), where p/2 is a non-builtin predicate.
> >>> This would require to introduce a multivalued logic already into BLD (since
> >>> neither p(abc,error) nor Not p(abc,error) should be considered as true).
> >>> I do not think we should do it.
> >> yes, indeed, that is one of the ugly things they do in SPARQL FILTERs
> > 
> > ok, good.
> 
> at least, in BLD, we probably don't want this, in extensions, we could 
> define it, e.g. if we wanted to have a language dealing with sparql 
> style filters.

In extensions of BLD - maybe. But I am not really sure.


	--michael  


> best,
> axel
> 
> -- 
> Dr. Axel Polleres
> email: axel@polleres.net  url: http://www.polleres.net/
> 
>

Received on Friday, 9 November 2007 00:00:16 UTC