Re: evaluable predicates, general definition

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.

best,
axel

-- 
Dr. Axel Polleres
email: axel@polleres.net  url: http://www.polleres.net/

Received on Thursday, 8 November 2007 23:37:12 UTC