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

On 18 Dec 2006, at 13:50, Michael Kifer wrote:

[snip]
> There is no need to define dialects for any kind of restrictions.
> All you need is that the target rule system would be able to raise an
> exception and say that it doesn't support something particular in a  
> given
> dialect (like recursion, function symbols, etc.). This is actually  
> easy to
> do using the semantically preserving mappings into dialects.
[snip]

Michael, isn't the need being voiced the need for a canonical way to  
identify these subsets, esp. for the purpose of conformance? I.e., if  
system A spits out a document with recursive rules, it is, of course,  
possible so say, "Hey, this can't be properly consumed by systems B,  
C, and D since they only support RIF Core with recursion free  
rules" (and presumably, one would like to be able to look this up  
instead of trying it with each of systems B, C, and D). But then "RIF  
Core with recursion free rules" effectively becomes a profile. (Same  
with Datalog, same with relational.) It happens to be a profile  
wanted by various vendors of rule systems. Why *not* sensibly name  
such profiles?

Forgetting conformance for a moment, isn't this a useful thing? Even  
for exchange? At least, in the sense that it makes it a little easier  
to specify what you actually can exchange.

It is true that specifying conformance levels encourages users to  
demand, well, conformance. So, I think the problem people have with a  
semantic superset of what they currently handle being a conformance  
target is that that opens them up to people demanding that they  
extend their tools to handed that semantic superset (which, in this  
case, I confess I was surprised that there was an issue).

Now, IIRC, your suggested conformance clause was one way, i.e., to  
conform, you just need to generate rules only in RIF Core:

"""I think systems should be compliant if they provide a semantic- 
preserving
mapping to a RIF dialect (or dialects). That's all. Again, RIF is  
supposed
to be for exchange."""

But I think people were looking for two way conformance, i.e.,
	A system is a conforming RIF dialect foo processor if it can  
generate *or (in principle) consume* documents which are expressed in  
dialect foo.

So, to take the PR example, if I only generate recursion free RIF  
core rules, I'm likely to not be able to consume recursive RIF Core  
rules. But then I'm a conforming RIF Core generator, but not  
processor. But then the conformance level only can tell me that I can  
expect my generated rules to be correctly consumed by a "complete"  
RIF Core processor....though it won't tell me that I can consume them  
correctly! Or which other engines that support the recursion free  
subset can consume my rules.

Cheers,
Bijan.

P.S., All this is pace that, due to implementation choices, bugs,  
etc. it's most likely the case that even for recursion free rules,  
not every system which supports recursion free rules can process all  
recursion free rule sets. So, some weaseling is required.

Received on Monday, 18 December 2006 14:48:26 UTC