- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Thu, 08 Nov 2007 18:59:09 -0500
- To: axel@polleres.net
- Cc: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

> 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