From: Axel Polleres <axel.polleres@deri.org>

Date: Thu, 08 Nov 2007 22:31:04 +0000

Message-ID: <47338E28.5020908@deri.org>

To: Michael Kifer <kifer@cs.sunysb.edu>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Date: Thu, 08 Nov 2007 22:31:04 +0000

Message-ID: <47338E28.5020908@deri.org>

To: Michael Kifer <kifer@cs.sunysb.edu>, "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

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? >> 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 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:31:20 UTC

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