From: Michael Kifer <kifer@cs.sunysb.edu>

Date: Thu, 08 Nov 2007 17:52:55 -0500

To: axel@polleres.net

Cc: "Public-Rif-Wg \(E-mail\)" <public-rif-wg@w3.org>

Message-ID: <2168.1194562375@cs.sunysb.edu>

Date: Thu, 08 Nov 2007 17:52:55 -0500

To: axel@polleres.net

Cc: "Public-Rif-Wg \(E-mail\)" <public-rif-wg@w3.org>

Message-ID: <2168.1194562375@cs.sunysb.edu>

> 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? > >> 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. --michael > Axel > > > --michael > > > > > >> Axel > >> > >>> --michael > >>> > >>>> Evaluable predicates: > >>>> > >>>> The most general definition of external predicates (built-ins), I know > >>>> of (in an attempt to write down the definition of Eiter et al. [1] in a > >>>> RIF suitable way): > >>>> > >>>> An evaluable predicate &pred(X_1,....,X_n) is assigned with one or more > >>>> binding patterns, where a binding pattern is a vector {in,out}^n. > >>>> Intuitively, an evaluable atom provides a way for deciding the truth > >>>> value of an output tuple depending on the extension of a set of input > >>>> predicates and terms. Note that this means that evaluable predicates, > >>>> unlike usual definitions of built-ins in logic programming, can not only > >>>> take constant parameters but also (extensions of) predicates as input. > >>>> inputs can not only be terms, but also predicate names (in which case > >>>> the *extension* of the respective predicate is the input.) External > >>>> predicates have a fixed interpretation assigned. The distinction > >>>> between input and output terms is made in order to guarantee that > >>>> whenever all input values of one of the given binding patterns are bound > >>>> to concrete values, the fixed interpretation only allows a finite number > >>>> of bindings for the output values, which can be computed by an external > >>>> evaluation oracle. > >>>> > >>>> > >>>> 1. T. Eiter, G. Ianni, R. Schindlauer, H. Tompits. A Uniform Integration > >>>> of Higher-Order Rea- > >>>> soning and External Evaluations in Answer Set Programming. In > >>>> International Joint Con- > >>>> ference on Artificial Intelligence (IJCAI) 2005, pp. 90–96, Edinburgh, > >>>> UK, Aug. 2005. > >>>> > >>>> > >>>> -- > >>>> Dr. Axel Polleres > >>>> email: axel@polleres.net url: http://www.polleres.net/ > >>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >> -- > >> Dr. Axel Polleres > >> email: axel@polleres.net url: http://www.polleres.net/ > >> > >> > >> > >> > >> > > > > > > > -- > Dr. Axel Polleres > email: axel@polleres.net url: http://www.polleres.net/ > > > >Received on Thursday, 8 November 2007 22:53:06 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:47:48 UTC
*