PRD review, part 2

2.2.

For PRD conditions, I think equals, member, and subclass are builtins 
(not actual data in WM) and have a "fixed interpretation" as far as the 
rules are concerned (the rules can't change the interpretation).  In my 
PR system, we have something called the datamodel that provides these 
interpretations.  The datamodel is typically used by many rules/rulesets.
WM contains ground COMPOUND Uniterms  and ground COMPOUND (basic) frames.

I find the semantics hard to understand.  The semantics in the simpler 
case of no quantifiers (save for an enclosing forall) and only ground 
uniterms in WM should be something fairly easily understood.  For example:

The semantics is based on filtering a set of tuples T using the rule 
condition (the filter rejects tuples for which the condition evaluates 
to false).  The set of tuples is formed as follows.
Mark the first occurrence of each variable in the rule condition.  The 
first occurrence of a variable must be in a uniterm. (proof: in our 
simplified case here, all other COMPOUNDs are builtin, and therefore 
only accept bound variables.) 
Mark the uniterms containing marked variables.  Each marked uniterm Ri 
defines a set of tuples Ti (Ti is the set of ground facts stored in 
working memory as ground facts of Ri).  T is just the cartesian product 
of the Ti.  Rule actions *may* execute on each tuple of T that passes 
the filter.

Exists, naf, and aggregate filter (or aggregate) the set of tuples 
formed from variables declared within their scope.

A tricky thing to specify is in what order are the tuples of T processed 
by rule actions, and what happens when those actions do something like 
remove a ground fact that is a constituent of T.

3.

Many PR systems have "truth-maintenance".  This is sort of like a rule 
head that gets asserted if the rule condition is true, but then gets 
retracted should the rule condition later become false.  An action named 
"Conclude" might capture this.

3.1.1.1.

I can see asserting a ground uniterm or ground frame with class 
membership, but not in general asserting that two arbitrary objects are 
equal or in a subclass or class membership relationship.  At least, not 
in any PR system I know of.
E.g. assert(1=2) would simply assert(false) in my system, because = is a 
builtin, not a logical.

asserting nested frames does make sense, I think, because business 
objects that one might reason on are often tree structured.

3.1.1.2.

The only 2 things I care about removing (retracting) is frame instances 
by oid and ground uniterms.

3.1.1.3.

I don't know what this is for.  It doesn't seem like it would work for 
any case other than a target that is a frame oid.  How would it differ 
from just an assert?

3.1.1.4.

seems like there are 2 use cases here:
1. builtins with side-effects are kept out of rule conditions and can 
only be in rule actions.  But what builtins are we talking about, other 
than assert, remove, etc.?
2. modularity: common sequences of actions can be factored into a "user 
defined builtin" and invoked from several rule actions.  But you'd have 
to create a way to define and interchange the user defined builtin.

3.1.1.5.

In my PR system, assign to a frame slot (aka a java bean property) is 
not the same as removing and asserting (or just re-asserting) the 
frame.  Assert will activate rules whose conditions reference *any* 
frame slot, whereas assign will activate rules whose conditions 
reference the assigned slot.

3.2.2.

I think the semantics of actions should talk about what they do to the 
ground facts (uniterms and frames) in WM.

4.1.

There should be some nontrivial intersection of PRD and BLD rules with 
exactly the same syntax and semantics (even though the semantics is 
written down differently, test cases should give the same answers).  
Otherwise, I think we will have failed...

5.1.2.

I think we need to adjust the syntax so that no transformations are needed.

-- 


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

Received on Saturday, 16 February 2008 00:10:38 UTC