W3C home > Mailing lists > Public > public-rif-wg@w3.org > August 2008

Re: [Core] binding patterns

From: Axel Polleres <axel.polleres@deri.org>
Date: Wed, 13 Aug 2008 09:42:26 +0100
Message-ID: <48A29E72.4000407@deri.org>
To: kifer@cs.sunysb.edu
CC: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>

Michael Kifer wrote:
> As we discussed (a few months) earlier, binding patterns have no meaning
> outside of a particular evaluation algorithm (procedural semantics). 

I remember well, but as long as this is not contradicting with the 
existing semantics - I guess for core, we can kind of assume a standard 
forward-chaining evaluation procedure, which only makes sense to me with 
binding patterns and safety - I see no problem with this.

> It is
> therefore not clear how to incorporate them in the current spec, which is
> supposed to be independent of the procedural things.

It would be only a part of the core dialect specification, which is just 
a syntactic restriction of BLD with the exact same semantics as BLD.
Would you see a problem with that?

Axel

> michael
> 
> On Tue, 12 Aug 2008 17:31:08 +0100
> Axel Polleres <axel.polleres@deri.org> wrote:
> 
>> (put the subject under a [Core] label.)
>>
>> Binding patterns were mentioned a view times today, I thus try to 
>> reformulate here a definition, which may be a helpful starting point 
>> helpful in this context and which :
>>
>> An external predicate with external schema
>>
>>   ( X_1,....,X_n; pred(X_1,....,X_n) )
>>
>> is  assigned with one or more binding patterns, where a binding pattern 
>> is a vector {in,out}^n:
>>
>> Any external predicate provides a way for deciding the truth value of an 
>> output tuple depending on the extension of a set of input predicates and 
>> terms. External predicates have a fixed interpretation assigned for 
>> their intended domains. The distinction between input and output terms 
>> is made in order to guarantee that whenever all input values of one of 
>> the given binding patterns are bound to concrete values, the fixed 
>> interpretation only allows a finite number of bindings for the output 
>> values such that the predicate evaluates to true, and those finite set 
>> of bindings which can be computed by an external evaluation oracle.
>>
>> If we agree to add something like binding patterns to DTB, I could start 
>> to "collect" the possible binding patterns for the DTB predicates.
>>
>> Side remark: note that external functions don't need binding patterns 
>> (obviously all parameters are 'in' and the only 'out' is the result.)
>>
>> Axel Polleres wrote:
>>> Two pointers here... the notion of strong safety in hex-programs [1,2] 
>>> and Topor's considerations on  safe database queries with arithmetics 
>>> [3] (cudos jos for the latter one)
>>>
>>>
>>> 1. R. Schindlauer. Answer-Set Programming for the Semantic Web. PhD 
>>> thesis, Vienna University of Technology, Dec. 2006.
>>> http://www.kr.tuwien.ac.at/staff/roman/papers/thesis.pdf
>>>
>>> 2.  Thomas Eiter, Giovambattista Ianni, Roman Schindlauer, and Hans 
>>> Tompits. Effective Integration of Declarative Rules with External 
>>> Evaluations for Semantic Web Reasoning. In York Sure and John Domingue, 
>>> editors, Proceedings of the 3rd European Conference on Semantic Web 
>>> (ESWC 2006), Budva, Montenegro, number 4011 in Lecture Notes in Computer 
>>> Science (LNCS), pages 273-287. Springer, June 2006.
>>> http://www.springerlink.com/content/f0x23wx142141v44/
>>>
>>> 3. R. Topor. Safe database queries with arithmetic relations (1991)
>>> Proc. 14th Australian Computer Science Conf 
>>> http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.48.4845
>>>
>>>
>>


-- 
Dr. Axel Polleres, Digital Enterprise Research Institute (DERI)
email: axel.polleres@deri.org  url: http://www.polleres.net/

Everything is possible:
rdfs:subClassOf rdfs:subPropertyOf rdfs:Resource.
rdfs:subClassOf rdfs:subPropertyOf rdfs:subPropertyOf.
rdf:type rdfs:subPropertyOf rdfs:subClassOf.
rdfs:subClassOf rdf:type owl:SymmetricProperty.
Received on Wednesday, 13 August 2008 08:43:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:53 GMT