Re: [PRD] Issues to resolve before publication (et proposed resolutions)

 I fear that we will give the wrong message to the community if we put an editors note on everything,  
in particular, since we do not reference the existing well-known work in production rules research. Just as an example, we never mention the RETE algorithm (Forgy 1982), although it is the basis algorithm for pattern matching in production rule system and variants of these algorithm are implemented by most production rule systems. 

- Adrian

-------- Original-Nachricht --------
> Datum: Fri, 27 Jun 2008 17:26:04 +0200
> Von: Christian de Sainte Marie <>
> An: RIF WG <>
> Betreff: [PRD] Issues to resolve before publication (et proposed resolutions)

> All,
> Based on Gary's, Adrian's and Paul reviews, on-going discussions on the
> mailing lits, my own views on the subject, and the assumptions that
> everybody agrees that we must publish PRD FPWD sooner rather than later,
> and get feedback from the larger community as early as possible, I
> listed a limited number of issues (below) where, I believe, we are close
> to agreement ("issues" in the general sense of the term, not WG formal 
> issues).
> Along the issues, I also listed proposed resolutions that, I believe,
> can be acceptable for everybody.
> I propose that we consider only these issues before before publish the
> FPWD, and I believe that, if everybody set themselves in a conciliatory
> mood, we can freeze PRD FPWD on Tuesday's telecon and publish right
> after (that makes a lot of believes; but remember that this is only a
> FPWD, not a LC).
> Cheers,
> Christian
> ------------------------------ >8
> Issues are listed in no particular order
> "Current versio" refers to [1]. It includes the changes I made, as
> proposed in [2] (in response to Gray's review [3]), ...
> [1]
> [2]
> [3]
> [4]
> #1. Section 1.1: Introduction. I propose that we keep that section as it
> is in the current version, except for typos and blatantly bad english. I
> added an editor's note about the presentation syntax and will open the
> corresponding issue. (Gary, could you check that I got the PS right in
> example 1.2, please?)
> #2. Section 1.3: Running example. I propose that we keep it as in the
> current version. I added a paragraph at the end of the section to clarify
> some of the assumptions (per [4]):
> "The assumption is that a system that consumes a RIF
> document published by Jim knows how to map Jim's published data model
> and specification of fact predicates and functions to/from its own
> underlying data representation. What a consumer is expected to do when
> this is not the case is still under discussion and will be specified as
> a conformance clause in a future version of this document."
> #3. Section Non-standard data types in the spec of Const.
> Proposal: keep as in the current version. As proposed in [2]:
>   * I removed the second sentence (from "They can also..." to the end of 
> the alinea) from the first alinea of the paragraph about symbols with 
> non-standard types, as well as the following alinea;
>   * I changed the last alinea to start with "Dialects and applications
> that extend...";
>   * I added the editor's note.
> As a consequence, I also removed the example 2.1.e (but I would still
> like to understand your comment in [3], Gary).
> #4. Sections (External) and (Atom): Named Arguments
> Uniterm (NAU). I really believe that we should not have them in PRD. But
> I understand that others think we should. I propose that we decide by
> simple majority vote, between the following two options (for FPWD only,
> and we open an issue to keep the discussion open):
>   1. No NAU (in FPWD), that is, leave the draft as it is (in the current
> draft, I commented out the NAU in the PS, as this was easier to do that
> to add them in the XML syntax etc);
>   2. NAU in FPWD, with an editor's note asking for feedback (if this is
> the majority decision, I will uncomment the NAU in the PS, and add them
> in the XML syntax).
> #5. Section (NmNot): tag name? I do not care, but we must choose
> one. I see two options, here again, and I propose, again, that we decide
> by a simple majority vote:
>   1. Keep NmNot, pr PRnot, or whatever other name that is not overloaded
> (but rather meaningless, as a consequence);
>   2. Change for Not.
> In any case, add an editor's note that name may change (I added one in 
> the current draft).
> #6. Section 2.2 (Actions): Assign or not Assign in FPWD? I propose to 
> keep it, now that it has been re-included with Ed: Adrian wants it, Mark
> wants it, I am rather in favor, Gary balances. I added an editor's note 
> in section (Assign) to the effect that this was still under 
> discussion and that the syntax was liable to evolve.
> Gary, I see that you changed the examples: I did not check exactly how, 
> but if we agree on the above solution, you will have to revert that 
> change, right?
> #7. Section 2.3.1 (Rule): Adrian added ATOMIC as a form of RULE, to 
> allow a RULE to be used to represent facts. However, a production rule 
> without a condition is not a fact: it is an unconditional action. I
> propose to revert to the previous version, as in [1], where the "if"
> part can be omitted (meaning ture by default) , to represent rules where
> the action part is intended to be executed for all the bindings of the
> varaibles.
> #8. Section (Forall): Gary does not want the CMP example to be 
> presented with binding patterns. On the other hand, they are included in 
> this version of RIF-PRD because all the mainstream PR languages use 
> them, and there is an editr's note asking for feedback about them and 
> the nested forall: so, providing an example makes sense.
> I propose that we include a small example with patterns, and that the 
> XML rendering of the complete CMP rule be moved to an appendix, where it 
> can be serialized without patterns nor nested Forall, as Gary prefers, 
> with a comment to the  effect that the serialization of a rule is not 
> unique, and that that specific serialization correspond to the PS 
> rendering as stated in 1.3 and 2.5.
> #9. Section 3.3 (Operational semantics of actions):
>   a. Semantics of Assign. I added a transition that defines the 
> semantics of Assign, basically as a set of Retracts followed by an 
> Assert; and I added an editor's note warning that this was unstable;
>   b. Semantics of Execute. I added an example, as suggested by Gary.
> Proposed: leave it as in the current draft.
> #10. Section 3.4.1: matching theory. As I explain in [2], it is needed 
> to take the semantics of datatypes into account. That is mentionned in 
> an editor's note only, out of laziness rather than anything else (and 
> also because it relates to the question of application-specific 
> background knowledge).
> 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).
> I propose that we go by option 1 for the FPWD.
> #11. Section 3.4.2 (PICK) and (fireableINSTANCES): No-repeat. I 
> have not looked at that one yet. I will propose a, hopefully consensual, 
> solution by Monday night (my time).
> If we could agree that these 11 question are the only ones we want to 
> deal with before FPWD, and, further, if we could agree on the proposed 
> solutions or some variation of them, and if we could do that by email 
> before the telecon Tuesday, then, we can essentially freeze PRD for FPWD 
> on Tuesday!
> Cheers,
> Christian

GMX startet Hier findest Du Leute mit Deinen Interessen!
Jetzt dabei sein:

Received on Sunday, 29 June 2008 21:52:27 UTC