W3C home > Mailing lists > Public > public-rif-wg@w3.org > November 2007

Re: evaluable predicates, general definition

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>

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. 9096, 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:43 GMT