Re: [TED] Action-188, ISSUE: production rule systems have "difficulty" with recursive rules in RIF Core

I do not think that restricting the core to non-recursive rules will  
be acceptable.
Frank

On Dec 15, 2006, at 4:16 PM, Gary Hallmark wrote:

>
> I don't understand your argument.  I may want to exchange a single  
> "hello world" fact, but it doesn't mean I want to restrict RIF Core  
> to doing just that.
>
> Here is my argument.  Can you point out the fallacy, or if not,  
> accept the conclusion?
>
> RIF Core is a common subset of all RIF Dialects.
>
> There will be a RIF dialect for production rules.
>
> A RIF dialect should capture common and useful language features of  
> important real world rule languages because those are the ones we  
> care about interchanging.
>
> Support for recursive rules is not common among real production  
> rule languages.
>
> Therefore, RIF Core should not include recursive rules.
>
> 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
>>>
>>>
>>
>>
>>
>

Received on Saturday, 16 December 2006 20:40:30 UTC