Re: [PRD] a RIF-PRD strawman

Christian,

Thank you very much for getting the ball rolling on this issue.

My overall comment is that the proposed syntax diverges too far from BLD 
(at least for a first attempt) and that the semantics is still very 
unclear, but that's not surprising because of the mix of operational 
semantics in the introductory sections with the model-theoretic BLD 
semantics that have been more or less cut-and-pasted from BLD.

I think a more modest proposal would be to start with BLD, add assert, 
retract, and "call builtin" actions, and remove function symbols (so 
Uniterms are always predicate symbols).

You propose:

 Ruleset      ::= Rule*
  RULE         ::= ' FORALL ' Var* [' ( ' BINDINGMODE ' ) '] ' SUCH THAT ' PATTERN* ' IF ' CONDITION ' THEN ' ACTION*
  BINDINGMODE  ::= "collect"

I prefer

 Ruleset  ::= RULE*
  RULE     ::= ' Forall ' Var+ ' ( ' RULE ' ) ' | Implies | ACTION
  Implies  ::= CONDITION ' -> ' ACTION*

I understand that "collect" is nice to support aggregation, but I'd 
rather this be a special builtin that also worked for BLD.

Actions:

Modify probably only makes sense for frames.

I think the only thing you can execute is a builtin.  Need to adopt BLD 
syntax for builtins, if/when we have one.

Conditions:

The notion of pattern and slot test expressions is a quaint relic from 
CLIPS that I'd rather not carry forward.
I don't see why classification should be different for PRD v. BLD.
I would just add "Not" and remove nested Uniterms (function symbols):

  CONDITION      ::= 'And' ' ( ' CONDITION* ' ) ' |
                     'Or' ' ( ' CONDITION* ' ) ' |
                     'Exists' Var+ ' ( ' CONDITION ' ) ' |
                     ATOMIC | Not
  ATOMIC         ::= Uniterm | Equal | CLASSIFICATION | Frame
  Uniterm        ::= Const ' ( ' (TERM* | (Const ' -> ' TERM)*) ' ) '
  Equal          ::= TERM '=' TERM
  CLASSIFICATION ::= TERM ' # ' TERM | TERM ' ## ' TERM
  Frame          ::= (TERM | CLASSIFICATION) ' [ ' (TERM ' -> ' (TERM | Frame))* ' ] '
  TERM           ::= Const | Var 
  Const          ::= LITERAL '^^' SYMSPACE
  Var            ::= '?' VARNAME
  Not            ::= 'Not' '(' CONDITION ')'

Semantics:


A big issue here is agreeing what the semantics are (regardless of how 
we write it down).
E.g.

p(a) -> assert(q(a))
assert(p(a))
retract(q(a))

Do the above 3 rules entail q(a)?  Does the order of the rules matter?



Christian de Sainte Marie wrote:
>
> All,
>
> I just uploaded my (much awaited :-) PRD strawman on the wiki [1] ([2] 
> for the more readable TR form).
>
> It has still no examples in it, nor an XML syntax (that one will be 
> easy to derive from BLD's); and, generally, many things are still 
> missing, including a section on BLD and PRR compatibility (but I 
> designed it with BLD and PRR compatibility in mind, so, that should 
> not be too difficult either).
>
> But I hope that it clear enough to make sense without them (hmmm... 
> Yes, I know: I do not have a strong record there... :-)
>
> [1]http://www.w3.org/2005/rules/wg/wiki/PRdialect
> [2] 
> http://burns.w3.org/cgi-bin/wiki_tr?source=http%3A%2F%2Fwww.w3.org%2F2005%2Frules%2Fwg%2Fwiki%2FPRdialect&Go=Go 
>
>
> Disclaimer: this is *not* ILOG's strawman. It has not been endorsed or 
> reviewed in any way by ILOG and it does not represnet ILOG official or 
> unofficial view. Of course, it is influenced by ILOG rule language and 
> engine, since those are the ones I know best: but I do not even know 
> them that good (actually, I certainly know BLD and PRR better than I 
> know IRL :-)... I am not even sure that ILOG will like it (I certainly 
> hope, and I think, they will, and the other vendors too; but I did not 
> check yet). So, again no particular ILOG hat on my head, here. Not 
> sure that it is fitting for a chair to submit a strawman, but if it 
> is, I am comfortable to submit this with my chair's hat on. If not, 
> consider my chair's hat is off (and so I have no hat at all; and now I 
> got a cold... c'est malin!).
>
> Christian
>
>
>
>

-- 


Oracle <http://www.oracle.com>
Gary Hallmark | Architect | +1.503.525.8043
Oracle Server Technologies
1211 SW 5th Avenue, Suite 800
Portland, OR 97204