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: Fri, 09 Nov 2007 05:56:23 +0000
Message-ID: <4733F687.2030406@deri.org>
To: Michael Kifer <kifer@cs.sunysb.edu>
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

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.


> What diff is it going to make?

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


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

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