# Re: evaluable predicates, general definition

```Michael Kifer wrote:
> Of course, binding patterns should be given in the specification of each
> builtin. But why put what you are suggesting into the definition of a model
> theory?

I never suggested that? Actually, I must then have understood you wrong,
but didn't you ask for a model-theoretic definition of built-ins?

You wrote:
> 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.

Ok, everything that needs to be said in terms of model-thery is that the
interpretation of those predicates is fixed, and that is simple,  is
that what you mean? If so, perfectly fine for me. I just ried to give a
deinition of binding paterns that makes sense, wherever we put it, and
we also seem to agree that we need it somewhere..

> How is it going to change anything?

What is "it"?!? I don't understand.

> Model theory is about entailment.

yes.

> What diff is it going to make?

???? I think we simply don't disagree. So, about exactly what are we
arguing here? :-)

Axel

>>>>>> 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.
>
> In extensions of BLD - maybe. But I am not really sure.
>
>
> 	--michael
>
>
>> best,
>> axel
>>
>> --
>> 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 Friday, 9 November 2007 05:56:49 UTC