- 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