Re: [PRD] ACTION-434: new PRD draft is out

Gary,

Thanx for your comments. I implemented some of them already, and made 
some other additions too. Sandro made a new snapshot [1] (see the 
color-coded diff [2]; there are no diff before section 3.2).

[1] http://www.w3.org/2005/rules/wg/draft/ED-rif-prd-20080523/
[2] 
http://www.w3.org/2005/rules/wg/draft/ED-rif-prd-20080523/diff-since-20080519

There is one mistake that one of your comments made me discover (see 
below) and that I will correct before the F2F (the correction will, 
thus, not be in the snapshot). That's the only modif I will do between 
now and then.

See comments, discussions etc inlined below:

Gary Hallmark wrote:
> 
> I continue to note the difference in presentation style in PRD vs BLD:
> BLD starts with PS syntax and then "derives" the XML from the PS.
> PRD, on the other hand, starts with XML and "derives" the PS.
> Much like choosing to drive on the right vs. the left side of the road, 
> the initial choice is somewhat arbitrary -- but once chosen, it is good 
> for others to adopt a consistent practice!

I beg to disagree: what makes sense for BLD does not necessarily make 
sense for PRD, and many, if not most, implementors will read only one of 
them; so that constraining them to have the same presentation style, 
despite the different audience, is, in my opinion, not really 
meaningful, and might even be counter-productive (The fact that I also 
happen to believe that BLD would be better with the XML syntax specified 
first, is a completely different discussion).

One difference between PRD and BLD is that the semantics of PRD does not 
use the presentation syntax (or almost not), which makes it rather 
redundant in PRD, whereas it is quite essential in BLD.

> [...]
> 
> So, let's reuse the Implies and Forall from BLD and get rid of 
> ConditionalStatement and Pattern. Extend the "then" part of Implies to 
> include retract/remove and possibly other actions (but allow ATOMIC and 
> not require Assert).

I have no objection to use the same name for Implies and Conditional 
statement: my point was only that "implies" sounds strange wrt 
production rules, so that a more neutral name would be better; but the 
intention is, indeed, to have the same name in all dialect (see the 
EdNote in the introduction of section 2.3). Now, if the consensus is 
that Implies is better nonetheless, I do not care that much about the 
name :-)

Re getting rid of Pattern, as you know, I have objections about that. 
So, this is a subject for discussion. This being said, they are 
optional, so that your BLD rules that do not use them are perfectly 
valid PRD (if they are valid PRD beside that). But your comment made me 
notice that there is a rule missing in the transition relation for 
InstantiateRULE: that will be the only additional modification I will 
make before the F2F.

Re representing an assert by its target only (that is, getting rid of 
the Assert element): why not? It makes that particular action stand 
appart syntactically, but I do not see any drawback, of the top of my 
head...

> Also, the ATOMIC needs to support the skolem 
> function "rif:new" to allow "creating" a new frame instance.

Yep, maybe. See discussion about the actions, below.

> I like the fanciful example with chickens and mashed potatoes, but it 
> would be good to use examples from the use cases (maybe the fanciful 
> example should be added).  At least one example (e.g. use case 1) should 
> be shown in both BLD and PRD and should only have to be shown once 
> because the PS and XML syntax should be identical.

That could be in section 4 (compatibility with other RIF dialects)? Or 
we can have a mix of examples; or even get rid of Jim the Hen Handler 
altogether (I know that some people will argue that it makes PRD look 
like it is not a serious spec; it always happen when I use silly names 
silly examples :-)

> The xml just before 2.3.2 contains curies like jim:today -- is this 
> legal or must the full IRI be used?

This is to be discussed. Actually, the whole question of non-builtin 
externals (functions, predicates, data types) have to be discussed, as 
they are more essential to the use of PRD than to that of BLD.

> Semantics:
> 
> I think we are getting close to the point where we can argue about the 
> semantics of our rule engines by relating then to this model, rather 
> than arguing about the model itself.  Very good!

Very good, indeed! Notice, btw, that (with the exception of the 
aggregations, which I left out this time) the model is strictly the same 
as in the previous draft: the only thing that changed is how it is 
described (but I agree that the new presentation is an improvement, of 
course :-)

> There are some issues with your symbols.  They don't all render on IE.  
> Upper-case Gamma isn't very mnemonic for Configuration (ok, they both 
> start with the 3rd letter in some alphabet).  Why use L for the set of 
> actions but alpha for an element of the set?  Suggestion: use the Latin 
> alphabet, e.g. C, c, A, a

You are right, there is no necessity to use greek. I just reused 
Plotkin's notation, there. L is for "labels", bt; I could use A for 
"actions" as well. I did not implement thtose changes yet, but I have no 
problem with them.

> The phrase "as usual" is annoying because I can't check if it is "usual" 
> because your reference links aren't working.

I replaced it everywhere with "as follows" :-)

> Sometimes in your semantic formulas you use ?x and other times just x 
> for quantified variables.  I find ?x distracting following an upside 
> down A or backward E.

I removed the question marks.

> 3.3 semantics for actions
> 
> In [1] I translate the action to assert a new frame of type T and set 
> its "id" property to some value as:
> And( rif:new(T,?id)#T rif:new(T,?id)[id->?id] )
> (In BLD, we have to split this into "then" into 2 rules to remove the And)
> Can we interpret this as adding 2 ground terms to W?

What is "rif:new(T,?id)" (sorry, I did not have the opportunity to look 
at you implementation yet)? If I read your example correctly, it must be 
a logic function: you would have to do that differently in PRD, since it 
does not have logic functions...

But, yes, since we do not accept the shortcut anymore, you would have to 
assert a new object of type T and then assert that that object has value 
xyw for property XYZ (or assert a new object with property XYZ and then 
assert that that object is of type T).

This being said, I am not sure how to assert (= create) a new object, 
see EdNote in section 2.2.1.1. The actions and their semantics have to 
be discussed, anyway (now that we are, maybe, at a point where we can 
discuss the substance instead of the form :-). Adding "rif:new" might be 
the right way to do it.

> 3.4.3 halting
> 
> as I understand it, the following ruleset
> 
> o[x->1]
> Forall ?x (o[y->?x] :- o[x->?x])
> 
> would never halt with your proposed default because the condition is 
> always true.  I think the default should be some kind of fixpoint (i.e. 
> when w' = w)

No, I think that fixpoint would not work for many applications (e.g. the 
apradigmatic rule where you add a discount as a percentage of the value 
of the shopping cart if the customer has gold status).

What I had in mind as the minimal default halting is when there is no 
action *after* taking out the ones that have been implemented already, 
that is, the ones that are determined by rule instances that have been 
continuously verified since their action part was last implemented. That 
is what we call 'refraction' at ILOG.

In that acceptation, your example would stop after the first cycle.

I understand that TIBCO's conflict resolution strategy uses a similar 
device to avoid executing the "same" actions repeatedly. I guess that 
OBR has something similar, although it is not clear from your 
description in [3].

Btw, I modified the formalism so that the system maintains a store (*) 
of the rule instances (that is, same rule set, same rule, same 
substitution for all the variables) that stay over multiple states, so 
that repeating actions from the same instance can be avoided.

(*) Yes, agenda was not a good choice to name that store: too 
overloaded. We will find a more neutral one.

I also got rid of the history, which I did not think we would use in PRD 
v.1 anyway; not beyond what can be done with the new store, at least.

If PICK does that, the simplest halting test is, indeed, when PICK does 
not return an action.

[3] http://www.w3.org/2005/rules/wg/wiki/Conflict_Resolution_Strategies

> Other halting policies:
> - rules can fire at most once (I've heard biztalk does this; also PRR's 
> sequential mode)

Yes (although I would rather put that in the definition of PICK, I 
think). Something that we have to discuss, anyway (the definitions of 
PICK and FINAL that are supported by PRD).

To be discussed also: whether PRD supports several default definition of 
PICK (e.g. 'standard' and 'sequential', like PRR), resp. FINAL. I do not 
think PRD should support user-defined specification of PICK: I would 
rather leave that for extensions. The question might be different for FINAL.

> - no rule can cause itself to re-fire (OBR and Jess have a per-rule 
> declaration for this)

Hmmm... Not sure I understand what you mean: can you give an example?

Cheers,

Christian

Received on Friday, 23 May 2008 14:57:48 UTC