RE: [PRD] PRD Review By Example

Hello,

I put some comments below, in the text.

Changhai

-----Original Message-----


 Gary Hallmark wrote:
> 
> Issue 1: We must state that all "initial facts" in the ruleset RS (here, 
> p:A(0)) are removed from RS and become the initial working memory 
> w<sub>0</sub>

[CSMA]
We did not specify constructs to represent initialisation yet. I do not know if we need them, but, indeed, this is a question to be raised and resolved. So, I suggest adding the sub-issue:

Issue 1': Does PRD need constructs for ruleset initialisation? That is, is that something that is commonly used enough in PR languages that we choudl have it in PRD?

Now, regarding that question of initial facts, all we can have in terms of initialisation, in a RIF-PRD document, at this stage, are ground assertions (actions) with empty (and thus always true) conditions, and these should be handled just like regular rules. 

If we want them to be fired first, it is for the conflict resolution strategy (PICK) to say so.

So, my understanding of Gary's proposed Issue 1 is that it is really equivalent to sub-issue 1'.

[CK]
JRules does not support initial facts. In general, the Java program which calls JRules engine should add the initial facts.

But it seems reasonable to put initial facts in PRD. We need a specific construct for that. This is better than adding a rule without conditions, which is always difficult to interpret in terms of semantics.

[GH]
> Issue 2: INSTANTIATE returns a set of Inst(R). This is undefined.
> I guess it is a pair (rule-id, consistent-substitution), and that 
> furthermore it must return *all* such pairs.

[CSMA]
Resolved. I had just not finished the job of moving things around cleanly.

[CK] I'd like to know why "consistent substitutions"? Can we just write "substitutions"?

[GH]
> Issue 3: picked(c) from my new PICK specification should be changed to 
> mean the rule instance picked
> from the prior configuration to arrive at the current configuration. And 
> the transistion system that calls PICK must
> save the returned rule instance as picked(c').

[CSMA]
Ok. I'd like to comment on that one too, but I feel I really should read your PICK email first :-)

[CK] Does this issue means that PICK should return one single rule instance? I agree that PICK should return one single instance. 

[GH]
> Issue 4: extractActions seems a bit underspecified as to how it 
> "grounds" the actions in the rules,
> which may have variables. Also, its argument should be a single rule 
> instance, not a list.
> I guess it is supposed to "plug in" the substitutions, so
> s = {p:A(1)}

[CSMA]
Yes, the spec of extractActions is a bit light. The input is an orderet set of rule instances and not a single instance, because we have not decided yet if PICK returns always a single instance, or whether there are case where it returns a list. So, I suggest splitting the issue in two:

Issue 4: extractActions needs be specified more completely.

Issue 4': does PICK always return a single rule instance? That is, is it useful to have PRD prepared to handle conflict resolution strategies that select more than one rule instance to be fired?

[CK]
Christian, PICK should return one single instance. But we could add other strategies, such as for example sequential strategy, where PICK can return any number of rule instances. During the F2F meeting, we said that rules are to be kept independent; we add the rule execution information in specific tags. I'm going to send some comments in a separate document on the operational semantics.

[GH]
> Issue 5: And(...) is undefined. We must define the PS before the 
> semantics if we use the PS in the semantics.

[CSMA]
I do not understand: "And" is defined in the section about conditions. It is issue, specifically?

> Also, this And takes a set as its first argument. I'll replace the set 
> with its member:

Right, some sloppiness in the spec, indeed.

> ({p:A(0)}, p:A(1), w') →RIF-PRD if and only if, for every ground formula 
> φ in W,
> w' |= φ if and only if And(p:A(0) p:A(1)) |= φ
> 
> w' = {p:A(0) p:A(1)}
> 
> Note: w' is not uniquely determined. E.g. w' = {And(1=1 p:A(0) p:A(1))} 
> is ok, too. I guess this is fine.

I do not understand why it is not uniquely determined? Either 1=1 is something that is entailed by And(p:A(0) p:A(1)) or it is not. If it is entailed, it is in w', if it is not entailed, it is not in w'. Isn't that correct?

Of course, w is not only p:A(0) and p:A(1): it also contains all the ground tautologies that follow from the specification of the condition language, and all the ground facts that follow from the definition of the data types, builtins and, generally, all the external knowledge.

So, it is really And(w, f), T |= phi, where T represents any addtional theory that is used by the system (including, typically, the classification theory that is provided by an object model).

You did not want such additional theories to be mentionned in the spec of pattern matching, in the previous version of the document. But, maybe, it is now time to include it back, as we are closer to be able to represent references to these theories (as XML schema, per your action)?

> Issue 6: PICK is ill-defined.

Hmmm... I would not even say that it is defined :-)

There is barely a skeleton for a spec, in the current version. Needs flesh to be working, and input to decide what that flesh must be: very good that you sent that PICK email, indeed. It may also be interesting to have a look back in my initial proposal, that did not make it to the FPWD (and although it is flawed).

And the input from others in the group is highly welcome! I remind you that PICK will be the core subject of our discussions next week in Orlando...

Cheers,

Christian