Re: [Fwd: Re: PRD Review]

Gary Hallmark wrote:
>
> 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 
> first...
>>
>>> 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.
>>
>> 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 :-)
>>
>>> 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 ...
>>
>> 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 :-)
>>
>>> 2.1.2.2
>>> 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).
>>
>>> 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.
>>
>> 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 
> arm-wrestle...
>>
>>
>> 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.
http://www.ilog.com/products/jrules/documentation/jrules67/rssamples/rs_smp_rsruleprog2.html
"The default refraction mechanism avoids executing the same rule several 
times on the same object instances, even if the rule conditions are met 
again after a change on an object."

Refaction in JRules is the same as jess/clips/drools no-loop. It's just 
the default is the opposite way around. didn't JRules have a "reset" 
command to allow a rule to refire after a modify? JRules is removing 
technical information from its manuals over time, so it's increasingly 
hard to understand what it's doing. I notice the Conflict Resolution 
tutorial is gone.

So to get JRules to comply with the rest of the world, you'd need to 
insert reset() to get same execution semantics as Jess, Drools, OPSJ. I 
won't say OBR as it's just Jess anyway.

MArk
>>
>> 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?
> Do(Retract(?emp[salary->?salary]) 
> ?emp[salary->func-numeric-multiply(?salary 1.1)]
> :-
> And(?emp#Employee ?emp[salary->?salary] pred:numeric-less-than(?salary 
> 100000))
>
> 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
>>
>>
>>
>>
>>
>


-- 
JBoss, a Division of Red Hat
Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, 
SI4 1TE, United Kingdom. 
Registered in UK and Wales under Company Registration No. 3798903 
Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland)