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

> I think there is some cross purpose talk here.
> 
> Michael is, of course, correct that you can use a superset of your  
> language's functionality to exchange rulesets written in your  
> language, since that superset can express those rulesets. Any tool  
> consuming rules from your language only has to know the subset of the  
> language that corresponds to your language.
> 
> But that's the point of having a "restrictive", or exact,  
> er.."dialect" (is that the term?) be the object of a conformance  
> level, so that you can say any conforming tool for this dialect can  
> (more or less) handle any ruleset in that dialect *and not  
> (necessarily) more*. (Perhaps, "in principle" is better than "more or  
> less".)
> 
> Let me make this a bit more concrete (er...in an abstract way :)).  
> Let's assume there is a RIF Core that is recursive horn + function  
> symbols. Now it's perfectly true that a production rule system (which  
> supports, lets say, function symbols but not recursion) can use this  
> RIF Core to exchange rules with systems that implement all of RIF  
> Core. So too can a datalog system (with recursion but no function  
> symbols). But the datalog system and the production rule system  
> cannot exchange (arbitrary) rule sets via RIF Core. In fact, to  
> exchange with "like" systems, there has to be something in those like  
> systems that rejects rulesets with function symbols/recursion. They  
> will have it, of course, but it helps to have a name for what they  
> check for.
> 
> But this suggests to me that RIF Core shouldn't be a common subset,  
> but rather that dialects should be able to "extend" RIF Core with  
> restrictions *as well as* extensions. That way, RIF Core can be  
> "natural" (which I do think is nice) but the conformance levels/ 
> dialects can be more exact.
> 
> I think, personally, I'd prefer this because I think it's a bit more  
> flexible and one doesn't have to worry about *really really* getting  
> the intersection right. Having a mechanism for restriction (as well  
> as extension) is a bit messier, but it's also useful in dialects  
> (e.g., one could say that one's tool supports a certain restriction  
> of a common dialect).

I usually hear this kind of "standard subset of a standard" called a
"profile", although I think that term is kind of confusing.  I'm okay
with saying a dialect could, in theory, be formed as a restriction on
some other dialect, even RIF Core.

The problem is that we don't get to define a lot of these dialects
without confusing the market.  We've agreed to define one in Phase 1 and
"a handful" in Phase 2.  This decision was based (I think) on a sense of
how much complexity the market can handle.  I can imagine ten years from
now getting up to more than a dozen dialects, if things are going very
very well for RIF.  I think more than two a year would be a mistake.

So the debate at hand is about the dialect we pick for Phrase 1 (aka,
the RIF Core dialect, aka RIF Core).

We did agree in Montenegro and publish in July that "RIF must not
require rule systems to be changed; it must be implementable via
translators." [1] That seems to imply we need to stick with
non-recursive Horn.

I guess you're saying this: RIF Core might be recursive Horn, and then
in phase 2 we could have a dialect ("RIF Business Core" heh) which is
non-recursive Horn.  Many rule vendors would just have to wait until
then before they could claim compliance.  Hmmmm.   I guess it could
work, but I still lean against it, because I think the market's need for
rules is mostly for simple rules, not for logic programming.

      -- Sandro

[1] http://www.w3.org/TR/rif-ucr/#req-translators

Received on Sunday, 17 December 2006 23:40:33 UTC