W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2008

Re: RIF Core, and how much is PRD allowed to diverge from BLD [Was: Re: [PRD] Issues to resolve before publication]

From: Mark Proctor <mproctor@redhat.com>
Date: Tue, 01 Jul 2008 13:54:52 +0100
Message-ID: <486A291C.6010301@redhat.com>
To: Christian de Sainte Marie <csma@ilog.fr>
CC: Gary Hallmark <gary.hallmark@oracle.com>, RIF WG <public-rif-wg@w3.org>

Christian de Sainte Marie wrote:
>
> Gary Hallmark wrote:
>> To maximize rule interchange between production rule engines and 
>> logic rule engines, clearly Core should be "as big as possible". 
>
> Yep. Why not equate PRD with BLD? That would indeed mawimize rule 
> interchange between BLD-compatible rule engines. Why do we need PRD, 
> after all?
>
> Of course, that would make useful interchange between PR engines more 
> difficult, and they might choose not to use RIF for that purpose... 
> But who cares?
>
> It is not like we also wanted to maximize utility for PR engines, of 
> course: that would make it a multi-criteria optimization problem, and 
> those are notoriously difficult...
>
>> We can, should, and must decide that now.  I don't even know why I 
>> have to keep arguing this point. 
>
> Did you ever argue it? You repeat it ad nauseam (even menacing to 
> shout it, sometimes :-), and you keep ignoring my arguments in support 
> of a different view (some of which seem pretty sensible to me, though)...
>
> (But maybe that is only my impression. Maybe, as seen from your side, 
> I am the one not listening. Is it the case?)
>
>> The bias to keep BLD and PRD aligned with a large common core should 
>> be so high that the burden of proof is on you to show why NAU  should 
>> not be in Core.  You have provided no such proof.
>
> I have explained why I believe that maximizing the interoperability 
> between PRD and BLD did not mean either blindly aligning PRD on BLD 
> without taking PR specifics into account, nor talking BLD-ese to the 
> PR crowd.
>
> Re the "burden of the proof", a tit for a tat: as you well know, no 
> proof holds against a dogma. As you have erected blind alignment of 
> PRD on BLD as a dogma, the burden is on you to convert me...
>
> :-)
>
>> I am much more interested in making PRD useful for exchange with a 
>> variety of rule engines than I am in tailoring PRD to any one or two 
>> vendors products.
>
> One benefit of tayloring PRD to the mainstream PR engines, including 
> the one or two vendors you have in mind, is that it augments the 
> chances that they will adopt and deploy PRD.
>
> Indeed, the balance is between tayloring PRD to the mainstream PR 
> engines and making it interoperable enough with BLD.
>
> But tayloring PRD to the mainstream PR engines come first, I believe, 
> because, on the one hand, the interoperability has benefits only if 
> PRD and BLD are adopted and deployed; and because, on the other hand, 
> it will be easier to increase the interoperability (in future versions 
> or further dialects) once it has proven its benefits, where, again, 
> adoption and deployement is a prerequisite.
>
> Let me put it otherwise: what is the variety of rule engines you have 
> in mind, besides the mainstream PR engines I have in mind?
If you supported Clips unororded facts (named arguments), except COOL, 
and made "or" and "forall" optional you would be able to target all the 
mainstream engines - Jess, Drools, Clips, JRules, OPSJ. It's really that 
simple. All these engines implement TMS in the same way, but that could 
be excluded from the base PR dialect, as it's an advanced feature only a 
few users use. So I would look to make this subset of Clips my "base" PR 
dialect. At a later date I would then look to make an advanced addition 
on this that looked to support "or", "forall", "collect/accumulate" for 
reason of sets of data, nested accessors, lists/maps, out of working 
memory data. "collect" is an important one that is supported by Jess, 
JRules and Drools (don't know about OPSJ) as it's the only efficient way 
to do cardinality constraints on patterns, and users really struggle 
without it. Jess supports collect via accumulate, accumulate is actually 
far more powerful and generic and collect is a specialised accumulate 
implementation.
>
> Cheers,
>
> Christian
>
>


-- 
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, 
SI4 1TE, United Kingdom. 
Registered in UK and Wales under Company Registration No. 3798903 
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland)
Received on Tuesday, 1 July 2008 12:58:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:50 GMT