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 23:36:51 +0000
Message-ID: <47339D93.2090101@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:
>>>> 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.

>>>> 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.


Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/
Received on Thursday, 8 November 2007 23:37:12 UTC

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