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

Mark,

The use of "Forall" might indeed be confusing.

In PRD, "forall ?x if ... then ..." really means: "for each of the 
values to which ?x can be bound, if ... then ...".

If none of your rules have a negation in them, and if all you actions 
are Asserts, then the PRD interpretation of Forall gives you the same 
result as the logical acceptation (modula the operational semantics of 
PRD, of course).

In particular, to link with the "binding pattern" discussion, PRD with 
binding patterns would allow:
"forall ?x (pattern) if ... then ...", meaning "for each of the values 
to which ?x can be bound and that satisfy (pattern), if...then..."

PRD without binding patterns would allow only the logically equivalent:
"forall ?x if (pattern) and ... then ...", eaning "for each of the 
values to which ?x can be bound, if (pattern) and ... then ...".

Cheers,

Christian

Mark Proctor wrote:

> Christian de Sainte Marie wrote:
> 
>> Mark Proctor wrote:
>>
>>>
>>> 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.
>>
>>
>> "Forall" is just a construct to declare rule variables: how can you do 
>> without it?
> 
> Why would you declare your variables separately? No production rule 
> systems makes you do this.
> 
> Forall ?chicken ?potato ?allowance ?age ?weight (
> .....
>        ?chicken#jim:Chicken        // The object bound to ?chicken is a 
> "Chicken" as specified in Jim's object model
> This makes the forall variables superflous information and will cause 
> confusion when we eventually provide support for PR 'forall' element.
> 
> 'forall' in production rules terms is a universal quantifier when the 
> given patterns are true for all data.
> forall( Bus( color == red )
> Makes sure that all the Buses in my system are Red.
> 
>>
>>> 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.
>>
>>
>> Yes, I agree: logical facts and truth maintenance are for a future 
>> version (of this draft, or maybe even of this dialect).
>>
>>> 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.
>>
>>
>> Yes. I proposed "collect" in the very first proto-draft, and a more 
>> general aggregation construct in the second one, but we decided to 
>> keep that for later, as they were only half-backed trials (to say the 
>> least :-)
> 
> agreed, just opening peoples eyes as to how PR provide a lot of high 
> level constructs for stuff, that we should aim to support one day to 
> make PR systems more accessible to users. If we stick with propositional 
> logic only, it'll be hard to convince users of the value.
> 
>>
>> Christian
>>
> 
>

Received on Tuesday, 1 July 2008 14:12:14 UTC