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: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Tue, 01 Jul 2008 12:33:50 +0100
Message-ID: <486A161E.6050504@hplb.hpl.hp.com>
To: "Boley, Harold" <Harold.Boley@nrc-cnrc.gc.ca>
CC: Gary Hallmark <gary.hallmark@oracle.com>, Christian de Sainte Marie <csma@ilog.fr>, RIF WG <public-rif-wg@w3.org>

Boley, Harold wrote:
> Production Rule languages such as the widely used CLIPS
> (http://en.wikipedia.org/wiki/CLIPS) employ predicates
> like car_problem with named arguments.

I wasn't talking about named arguments in general but the specific case 
of "named argument uniterms with the semantics as defined in BLD" which 
is what I took the term "NAU" to stand for.

> CLIPS (Wikipedia rule1 is a "pure production rule"):
> 
> (deffacts trouble_shooting
>     (car_problem (name ignition_key) (status on))
>     (car_problem (name engine) (status wont_start))
>     (car_problem (name headlights) (status work))
>  )

In CLIPS those are "unordered facts" (or deftemplate facts) and I 
believe you can partially match against them. For example you could also 
have a rule:

(defrule rule1
     (car_problem (status wont_start))
      =>
     (assert (car_problem (name suspectedStarter))
  )

and it would still match those facts even though some arguments are missing.

Thus I believe the CLIPS representation corresponds to more closely 
frames in RIF not to NAUs. I would certainly include Frames in core.

My knowledge of CLIPS only comes from checking the online manuals not 
from deep experience so I would be prepared to corrected on this.

Dave

> 
> (defrule rule1
>     (car_problem (name ignition_key) (status on))
>     (car_problem (name engine) (status wont_start))
>      =>
>     (assert (car_problem (name starter) (status faulty))
>  )
> 
> 
> RIF-BLD (simplified, with rule1 as a Horn-like rule):
> 
> (* trouble_shooting *)
> car_problem(name->ignition_key  status->on)
> car_problem(name->engine        status->wont_start)
> car_problem(name->headlights    status->work)
> 
> (* rule1 *)
> car_problem(name->starter       status->faulty) :-
>   And(
>       car_problem(name->ignition_key  status->on)
>       car_problem(name->engine        status->wont_start) )
> 
> 
> -- Harold
> 
> 
> -----Original Message-----
> From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org]
> On Behalf Of Gary Hallmark
> Sent: June 30, 2008 6:35 PM
> To: Dave Reynolds
> Cc: Christian de Sainte Marie; RIF WG
> Subject: Re: RIF Core, and how much is PRD allowed to diverge from BLD
> [Was: Re: [PRD] Issues to resolve before publication]
> 
> 
> I'm sure the word "core" is overloaded and means many things to many 
> people.
> 
> Right now, I'm concerned with an operational meaning, which is literally
> 
> the intersection of BLD and PRD.  The larger this intersection, the 
> better.  I don't care so much for NAU per se, I just use it as an 
> example.  Because it is in BLD, the default should be that it is in PRD 
> as well, unless there is some evidence that it is more difficult for PRD
> 
> than for BLD.  There is no such evidence -- in fact, it is common in PRD
> 
> (Jess and CLIPS have it)
> 
> Dave Reynolds wrote:
>> Gary Hallmark wrote:
>>> To maximize rule interchange between production rule engines and 
>>> logic rule engines, clearly Core should be "as big as possible".  We 
>>> can, should, and must decide that now.  I don't even know why I have 
>>> to keep arguing this point.  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 haven't followed all the ins and outs of all this discussion but 
>> even without PRD I'm not immediately convinced NAU should be in core.
>>
>> They seem relatively uncommon in rule languages. They got in, in the 
>> end, on the grounds that they can be handled at the translation stage 
>> for languages that don't support them. However, the notion of a "Core"
> 
>> suggests some criteria of simplicity and minimality and there needs to
> 
>> be a higher burden of proof that these extra syntactic features have 
>> value in the Core.
>>
>> Dave
> 
> 
Received on Tuesday, 1 July 2008 11:35:32 GMT

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