- From: Dave Reynolds <der@hplb.hpl.hp.com>
- Date: Tue, 01 Jul 2008 12:33:50 +0100
- 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 UTC