Re: Production Logic Programs Approach, in a Nutshell: paper now available

Hi Peter,

At 03:57 PM 12/20/2005, you wrote:
>From: Benjamin Grosof <bgrosof@MIT.EDU>
>Subject: Re: Production Logic Programs Approach, in a Nutshell: 
>paper now available
>Date: Tue, 20 Dec 2005 15:45:51 -0500
>
> > Hi Peter,
> >
> > At 10:11 AM 12/20/2005, you wrote:
> > >This bring to mind an interesting issue.
> > >
> > >Should the RIF WG be investigating systems or formalisms that do not have
> > >complete publically-available comprehensible formal definitions?
> > >
> > >My vote would be "NO".
> >
> > Noted :-) .  Do Production Rules (cf. Ilog, Fair Isaac, Jess, etc.),
> > or ECA Rules, qualify?  ;-)
>
>It depends.  Certainly at least one of the various definitions of OPS that I
>can recall counts, as a procedural definition.  Newer production rule
>formalisms could count, in the same, less-than-ideal way.  However appeals to
>code are worthless, in my opinion, and appeals to user documentation 
>are almost
>always worthless, because user documents doesn't generally have sufficient
>formality.
>
> > Production LP is an expressively fairly simple reformulation of
> > several pieces of previous work by me and others
> > (Situated + various other expressive features, cf. RuleML/SWSL) that
> > translates (bidirectionally) a bit more simply to Production Rules
> > (PR) than the previous Situated extension does.
>
>I certainly didn't get that from your paper.  I had a bunch of questions that
>weren't answered in the document, among them was whether actions had to be
>idempotent.  The appeal to sensor KBs seems to be fatally flawed in the
>presence of binding patterns, as well.

Thanks for the questions.  Please send me more of your bunch if it's 
not too much trouble
to write them in an email.  Or you can wait til the next iteration of 
the writeup, maybe they'll be most or all answered by that.

Brief answers to the couple of specific questions you listed:

1. Actions are not idempotent.  Since that's the general case I 
didn't feel (before your question) the need to say that.

In writing a rulebase, however, one can ensure that a given action 
aproc (say, A) will only be triggered at most once per ground 
instance of that aproc, if one desires to do that.
The following condition (a.)&(b.) on the rulebase suffices, for example:
a. In the entire rulebase A appears only in the head of a single rule (say, R).
     Let that rule R's head action literal be A(t) (where t is a 
tuple of terms).
b. The set of free variables in the body of the rule R is the same as 
the set of free variables in t.

2. The binding patterns restrictions on sensors are restrictions 
similar in spirit to other pragmatic safety restrictions
that are found commonly in rule systems, e.g., head-safe or 
negation-safe (or function-free, for that matter).
Whether this sensor-safety condition is met in all rule bodies can be 
determined statically (before run-time), tractably.  Please can you 
explain: what do you view as the fatal flaw, if any?

Wrt why send out notice of the current version of this PLP paper:
A number of people in the RIF group (and outside it) had asked for a 
nutshell version paper about PLP ASAP.

Best,
Benjamin


>By the way, a direct pointer would have been much better.
>
> > I'll be packaging all the formal details about the formalism and the
> > translation to PR, in a self-contained relatively-concise way in the
> > next major iteration of the writeup (which I aim to have in the next
> > few weeks).
>
>Hmm, an announcement couldn't have waited until then?
>
> > I'll look forward to feedback then about comprehensibility :-) .
>
> > Best,
> > Benjamin
>
>peter

________________________________________________________________________________________________
Prof. Benjamin Grosof
Web Technologies for E-Commerce, Semantic Rules, Business Policies, 
E-Contracting, Services, Trust, Financial
MIT Sloan School of Management, Information Technology group
http://ebusiness.mit.edu/bgrosof or http://www.mit.edu/~bgrosof

Received on Tuesday, 20 December 2005 21:54:38 UTC