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?

Yes. But I think we should first define something simpler and avoid
proliferation of profiles/dialects. In my prev msg (response to Sandro) I
repeated (and elaborated on) one formal definition of compliance, which
enable exchange and doesn't require profiles.
http://lists.w3.org/Archives/Public/public-rif-wg/2006Dec/0096.html

I am not against profiles per se. I am just saying that they are a
convenience. (It is predicated by the need for vendors to have technical
people who would be able to define profiles correctly.)

> 
> 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 useful in an ideal world. But this just pushes the argument into how
profiles should look like (= a repeat of the current discussion at a
different level)

> 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.

You are right. But this should be called differently.
Conformance should be something like what I described. It sets the bar low
and enables exchange. Then we can also have another notion, probably
"implementing" a RIF dialect. This would mean that there is a
semantics-preserving mapping from the dialect to the rule system.
(There also is a round-trip issue for the mappings from and to the dialect,
but we should leave it for dessert.)

> 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.

Yes, a combination of the notions of "compliance" and "implements" is
probably going to do the trick.


	regards
	  --michael  

> 
> 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 18:41:37 UTC