[Fwd: Re: PRD Review]

All, sorry, I see that I sent this to Gary only.



Forwarded message 1

  • From: Christian de Sainte Marie <csma@ilog.fr>
  • Date: Tue, 24 Jun 2008 16:10:37 +0200
  • Subject: Re: PRD Review
  • To: Gary Hallmark <gary.hallmark@oracle.com>
  • Message-ID: <4861005D.1050107@ilog.fr>
Gary Hallmark wrote:
> 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!)

The running example has been rewritten to make it less conspicuous: our 
ta**** ******ce will see it if they use, they wont if they dont.

But, of course, I still do not agree that we should send the message 
that PRD is very similar to BLD (just in case somebody missed it: the 
message I think we should send is that BLD and PRD interoperate 
transparently wherever their semantics agree).

> 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.

Not just modification in the KB. What about:
"Production rules are rules: like logic rules (as covered by RIF-BLD), 
they have a condition, the "if" part, and a conclusion, the "then" part; 
unlike logic rules, where the conclusion is a logical statement, the 
"then" part contain actions, that can have side effects other than 
modifying the knowledge base."

> 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

That sentence was copied from RIF-BLD.

> 1.2.2
> plural?: as a pseudo-schemas


> 1.3
> I worry that this example is "too hard" to give a complete semantics for.

Many real-world rules depend on external data source that are seen as 
balcboxes: that was the idea of the "fox sensor"...

> 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.

Yes, it might contradict the "strict mode" conformance clause in BLD. 
But the conformance clauses of PRD might differ for BLD.

The question of exogeneous datatype may have different implications for 
BLD and PRD.

How do we deal with it in FPWD? Editor's note? Something in the tune of:
"The case of non-standard data types, that is, of constants that do not 
belong or cannot be cast in one of RIF builtin types for interchange 
purposes, is still under discussion in the WG. The WG seeks feedback on 
whether they should be allowed and why."?

> 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 ...

I do not understand the comment: can you clarify, please? This is an 
example. It assumes that Jim specified a datatype DayOfTheWeek and taht 
Tuesday belongs to that datatype.

However, if we remove the paragraph about non-standard data types, that 
example will be removed too, anyway.

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

Yes, it might my command of the english language. It was supposed to 
mean that, contrary to the arguments inan Atom, the arguments in an 
Equal are interchangeable.

I removed that proposition that is not needed anymore (we have 
rif:ordered, and the roles names may change to left+right anyway).

> 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.

It makes sense from an usage point of view.

(Target audience! Taget audience! Target audience!)

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

Right. I corrected that.

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


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

What about:

> 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.

But it is needed to take the semantics of datatypes into account; and it 
is taken from the reference definition (in CIR04). I did not detail that 
and mentionned it in an editor's note only, out of laziness rather than 
anything else (and also because it relates to the question of 
application-specific abckground knowledge).

1. keep the editor's note as it is;
2. add a paragraph in the text re how it takes into account the 
semantics of data types etc, and leave an editor's note saying that this 
might be extended to take application-specific theories into account 
(such as app-specific object models etc).

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

Item 6 takes into account the case where the condition is omitted (and, 
thus, true by default).

Regarding the formatting: yes, if I could align the arrows, that would 
be better. Any idea how I can do that, anybody?

> 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.

My mistake, then: I misunderstood you.

> 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.

I do not get it: can you give me an example?

>  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.

So, that is not a default strategy, right?

What do you suggest: adding an editor's note saying that the semantics 
of no-repetition is still under discussion and that feedback is welcome 
coould help us understand better what is really needed.

Tanx again for the comments.


Received on Friday, 27 June 2008 15:19:49 UTC