PRD Review

Overall, I like the edits.  I really would like to see the use of the 
extended Forall minimized (i.e. please remove it from the running 
example -- it is not motivated at all and really detracts from the 
message that we are very similar to BLD!)

details:

1.1
awkard:
Production rules are rules where the part that describes the consequence 
of condition being satisfied specifies actions rather than logical 
statements.
suggested:
Production rules, like logic rules [RIF-BLD], have an "if" part and a 
"then" part.  Production rules can contain actions in the "then" part 
that can modify the knowledge base.

spell: detailled

1.2.1
confusing:
The compact URI notation is not part of the RIF-PRD syntax.
why I'm confused: it is part of RIF-BLD presentation syntax

1.2.2
plural?: as a pseudo-schemas

1.3
I worry that this example is "too hard" to give a complete semantics for.
In particular, the time-varying external function "there is no fox in 
the hen house" is problematic.  In OBR, we discourage users from doing 
such things precisely because of the unpredictability of when such 
functions get called in a rete network.
Let's replace it with a ground fact,
e.g. jim:henHouse[jim:containsFox->true|false]
and a note about how a "real" system would probably use some rule system 
API to arrange for this fact to be added to the KB when a sensor detects 
that a fox enters the hen house.

The rule should be changed to:
    Rule ChickensAndMashedPotatoes:
    Forall ?c, ?p
    If ?c is a chicken and the age of ?c in months is > 8 and
       ?p is a potato and ?p is owned by ?c and
       the weight in decigrams of ?p > (age of ?c)/2 and
       today is not Tuesday and there is no fox in the hen house
    Then mash ?p, increase the grain allowance of ?c by 10%, and
         remove the couple (?c, ?p) from the ownership relation.

Rationale: this is much closer to BLD

2.1.1.1
confusing: symbols with non-standard types
why I'm confused: this seems to be talking about conformance and should 
be reconciled with BLD conformance which
speaks of a "strict mode" which almost contradicts what is said here.

2.1.1.1.e
confusing: type="jim:DayOfTheWeek"
Let's not claim we have a solution for this yet.  Maybe we need to 
introduce some kind of "enum" type.  Or, maybe we
need disjuncts in rule heads and we can axiomitize this:
if ?x # jim:DayOfTheWeek then ?x = "Monday" or ?x = "Tuesday" or ...

2.1.2.2
how does one comply with: order of the side elements "must not be 
preserved"?  That is a bizarre requirement...

2.1.2.3
spell: bollean

2.3.1.2
as everyone knows, I don't really care much for the pattern FORMULA.  I 
would be agreeable to consider moving this to an extended Group element 
for WD2.  I prefer putting it on Group because there are good use cases 
for when a group of rules share a common set of conditions -- e.g. in a 
Decision table.
But can we remove this from WD1 to eliminate some confusion? It just 
makes no sense to arbitrarily split up the conditions for a single rule.

2.4.3.
Need to indicate that the <And> can have 0 or more Frame children.

2.5 Example
This should be much closer to BLD -- remove the SUCH THATs, NOT, etc.
I can give the exact replacement text or edit the wiki if desired...


3.
The example uses the extended Forall, which is just noise that obscures 
the similarity to BLD

3.2
Definition (ruleset instance):
first bullet has trailing </sub>;

3.3
Can you give an example for Eval?  maybe for Eval(jim:mash)

3.4.1.
Can we get rid of the "matching theory T" until we can better define 
it?  Just say x << w means x matches w.

the formatting for the spec of InstantiateRULE(w, r) could be improved.  
List item #6 looks extraneous.

3.4.2.
No-repetition: "unless the instantiation environment has significantly" 
will be hard to pin down.  The ILOG notion of refraction is quite 
different from the no-repeat notion in OBR and Jess.  In OBR the 
strategy is per-rule or per-group and it means "nothing this rules 
actions do can directly refire the rule" although rule A can trigger 
rule B that can trigger rule A, etc.  The way to prevent that in OBR is 
to put rules A and B in the same group and designate the group as no-repeat.

Received on Tuesday, 17 June 2008 07:15:34 UTC