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

Sandro Hawke <sandro@w3.org> wrote:
> 
> > 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.

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.


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


You need to troubleshoot your reasoner. :-) I don't see how this implies
what you are claiming it to imply.

Unfortunately, you continue to stick with hand-waving arguments rather than
trying to make what you want to achieve precise.  In particular, you didn't
address my attempts at defining what you call "conformance" more precisely
and also Frank's arguments.



	--michael  


> 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 Monday, 18 December 2006 13:51:14 UTC