- From: Axel Polleres <axel.polleres@deri.org>
- Date: Fri, 09 Nov 2007 05:56:23 +0000
- 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. 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