From: kifer@cs.sunysb.edu (Michael Kifer)
To: Gary Hallmark <gary.hallmark@oracle.com>
Cc: W3C RIF WG <public-rif-wg@w3.org>
Subject: Re: [TED] Action-188, ISSUE: production rule systems have "difficulty" with recursive rules in RIF Core 
In-Reply-To: Message from Gary Hallmark <gary.hallmark@oracle.com> 
   of "Fri, 15 Dec 2006 16:56:02 PST." <45834422.2070305@oracle.com> 
Date: Sun, 17 Dec 2006 12:29:07 -0500
Message-ID: <20138.1166376547@cs.sunysb.edu>
Sender: kifer@cs.sunysb.edu


> I haven't heard of anyone seriously wanting a RIF SQL dialect.  AFAIK, 
> Oracle is interested in something for interchange of business rules, 
> both PR and ECA.

I hereby declare that I am interested (seriously) in the possibility of
exchanging SQL through RIF (not necessarily with another SQL system).

SQL is common, so according to your logic the core should be limited to
relational algebra. Q.E.D.?


	--michael  

> Michael Kifer wrote:
> 
> >>>This would be a ridiculous and unjustified restriction.
> >>>
> >>>The core is for exchange. There is no requirement for any concrete
> >>>system to properly include the core. (Don't confuse concrete systems with
> >>>RIF dialects.)
> >>>      
> >>>
> >>I'm not sure where the disagreement or misunderstanding here is.
> >>
> >>My understanding fits with what Gary said, that RIF Core is a dialect
> >>and it's a part of every RIF dialect, so every rule engine using RIF
> >>must implement RIF Core.    
> >>    
> >>
> >
> >I think that this requirement makes no sense and, furthermore, is meaningless.
> >Suppose people want to exchange aggregate-free subsets of SQL 1992 through RIF.
> >Does it mean that RIF core should be limited to relational algebra?
> >Or does it mean that we will kick them out even though they can perfectly
> >use RIF core to exchange their stuff (preserving semantics etc.) we will
> >somehow stop them until they implement full RIF Core?
> >
> >(Note that different SQL vendors have various deviations from SQL 1992
> >(even though most of them claim to support it!), so such an exchange is not
> >completely out of question.)
> >
> >	--michael  
> >
> >  
> >
> >>We'll need some normative Conformance text at some point, something a
> >>bit like:
> >>   http://www.w3.org/TR/owl-test/#consistencyChecker
> >>
> >>We could say something like (as a rought first cut):
> >>
> >>     A "RIF Core Rule Engine" is a rule engine which can perform sound
> >>     and complete reasoning on any rule set which can encoded in one or
> >>     more RIF Core documents.  It must be able to answer all queries
> >>     against the deductive closure of the ruleset, where a query is
> >>     equivalent to a RIF Core anticedent, and to answer a query means to
> >>     provide every matching set of bindings to the variables in the
> >>     anticedent. 
> >>
> >>At the moment, unless some new information comes along, I'm inclined to
> >>agree that we need to leave recursive Horn rules out of the core.
> >>
> >>My understanding is that recursive Horn rules are also a problem for
> >>prolog.  As with rete systems, there are lots of clever and effective
> >>ways of dealing with this problem (I was once an enthusiastic XSB user),
> >>but my sense is that they are still kind of cutting edge instead of the
> >>kind of dirt simple we want in RIF Core.  With non-recursive rules, one
> >>can do the trivial mapping to prolog or rete rules and any halfway
> >>decent engine will be a sound and complete reasoner for RIF Core rules.
> >>I think that's what we want.
> >>
> >>We could go another step back for RIF Core, all the way to datalog, but
> >>I think non-recursive terms are still quite useful (eg for defining
> >>uncle), so I'd rather not do that.
> >>
> >>   -- Sandro
> >>
> >>    
> >>
> >
> >
> >  
> >
> 
>