Re: [Fwd: Re: PRD Review]

Christian de Sainte Marie wrote:
> 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).
I'm a big fan of measurable criteria and one thing I can measure is the 
degree of similarity between PRD and the rest of the RIF documentation 
suite, and I think we are not scoring as well on this metric as we should. 
>> 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."
I like shorter sentences. 

Production rules can contain actions in the "then" part that can modify 
the knowledge base or the environment.
>> 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"...
yes, but we won't be solving all the world's problems, at least not at 
>> 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."?
and maybe ask them how to do it as well :-)

This is an issue for DTB.  If we allow user-defined types (other than 
frames) then it should be available for FLD dialects as well.  I think 
we deal this issue by removing it from FPWD.  You can't just put an 
editor's note on everything.   Makes it look like the editor is 
reluctant to change anything :-)
>> 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.
yes, remove it.  I think maybe I already did :-)
>> 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!)
if you don't have any measurable criteria, then we may as well 
> 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).
the semantics of datatypes is given in DTB.  We need to figure out how 
to "import" that into PRD. 
> Options:
> 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?
?emp[salary->func-numeric-multiply(?salary 1.1)]
And(?emp#Employee ?emp[salary->?salary] pred:numeric-less-than(?salary 

In OBR and Jess, the above rule will give every employee with salary 
less than 100000 a 10% raise
only if no-repeat (metadata attached to the rule) is true.  If no-repeat 
is false, then the above rule will keep increasing employees' salaries 
by 10% until every employee earns at least 100000.
>>  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.
that's an editor's note I can live with :-)
> Tanx again for the comments.
> Christian

Received on Friday, 27 June 2008 20:27:04 UTC