OVERALL RECOMMENDATION ---------------------- Despite my being familiar with many concepts related to Production Rules and how they are used in actual system, I could not understand the details of some of the RIF-PRD document's formal contents. Publishing this document in its current form is likely to make several readers perplex and wondering. GENERAL COMMENTS ---------------- 1. All in all, the document is well-organized and reads rather well up to a point (see below) - or, should I say, as much as can be allowed by the poor mathematical typesetting Why can't we use (La)TeX in our Wiki documents? (Sandro?) We do so in our internal Wiki at ILOG. That'd be nice since nothing matches (La)TeX's quality for typesetting math and easing its reading and understanding (besides enabling cut-n-paste reuse of (La)TeX formulas from existing (La)TeX documents). See, e.g., http://wiki.scilab.org/howto/use_this_wiki/latex or http://johannes.sipsolutions.net/Projects/new-moinmoin-latex. 2. Examples are too few and far between. The formal presentation should illustrate each newly defined formal concept on a simple example. 3. The section on Actions needs to be elaborated with motivating comments and explanations regard the oddities of some PRD constructs. Its formal contents has yet to be simplified in my view, but I would not make that a condition precluding publication. 4. Perhaps a list of exemplars of actual production rule systems presumed to use the RIF-PRD should be given up front at the outset. In this way, the reader familiar with one of those will be able latch on the basic concepts being discussed and formalized. I strongly suggest giving small simple examples in some of these actual systems to illustrate a concept before giving its formal definition. Following are some detailed comments of what I have read and could understand in the time alloted (2 weeks). I reproduced the entire outine of the RIF-PRD document and entered my comments as I was reading each section from start to finish in sequence. I did not spend much time on the section on XML serialization syntax as it is a catalog of XML constructs representing the abstract syntax. DETAILS ------- 1 Overview - Quoting: "In the section Operational semantics of rules and rule sets, the semantics for rules and rule sets is specified, accordingly, as a label terminal transition system [ref Plotkin]." Should be "a LABELED terminal transition system"? [my capitals] BTW, "labeled" is also spelled "labelled" further below: stick to one consistent spelling. - Missing reference "[Ref Plotkin]" (but cited correctly in 2.3.2). - Either use "formulas" or "formulae" but not both. - Paragraph just before Example 1.2 ends with a semicolon. - Quoting: "RIF-PRD and RIF-BLD share more than part of their condition language,..." This is awkward English - suggestion: "... share a substantial part of their condition language,...". 2 Abstact syntax and Semantics - Section title should be "Abstract syntax and semantics" (i.e., with an "r" in "Abstact" and no capital "S"). 2.1 Conditions 2.1.1 Abstract syntax - Missing closing parenthesis in: "a countably infinite set of variable symbols Var (disjoint from Const;" - Do you mean "relationship(s)" or "relations(s)"? The former is an informal English term, the latter is a mathematical term that denotes a formal logic concept. The is odd since all other terms used in defining the building blocks are formal mathematical terms, except for "relationship". - Delete "arbitrary". - Quoting: "Notice that the production rule systems for which RIF-PRD aims to provide a common XML serialization use only externally specified functions, e.g. builtins. This is one of two points where the syntaxes for conditions in RIF-PRD and RIF-BLD differ, since RIF-BLD specifies, in addition, a construct for serializing the logic functions that logic languages also use." This paragraph is confusing. You simply mean to say that RIF-PRD uses only interpreted functions, while RIF-BLD does too but also uses functional terms based on fixed-arity constructors as is logic programming. - Re: RIF-PRD conditions supporting negation - surely you mean *ground* negation. 2.1.1.1 Terms 2.1.1.2 Atomics - The English word "atomic" is an adjective, not a noun. Why not simply call these constructs "atoms" as they commonly are in Formal Logic? Namely, the enumeration defining this notion should read: 1. Positional atom. [...] 2. Named-argument atom. [...] 3. Equality atom. [...] 4. Membership atom. [...] 5. Subclass atom.[...] 6. Frame atom. [...] 7. External atom. [...] - Frame atoms may not contain frame atoms. (I think this was already pointed out several times by Dave Reynolds.) This is not only odd but also problematic, especially what it is claimed that, "external information sources can be modeled in an object-oriented way via frames". This is not true since the outer object may be cast as a frame, but not the inner objects making its structure. For example, what if the "http://example.com/acme" object has an attribute that is a constructed object? As well, as was mentioned several times before, frames as defined by BLD and PRD are also inadequate for representing OO programming objects since they allow several occurrences of the same attribute name as arguments of a frame (i.e., a frame's arity is a bag not a set as that of named-attribute terms). For this to be possible, it is necessary to use an implicit collecting semantics for combining the values of multiple occurrences of an attribute in a frame as the value of an object's field. - Quoting: "... to represent their argument names. They cannot be constants from Const or variables from Var." "They" of the last sentence is ambiguous. Rephrase that as, "... to represent their argument names, which can neither be constants from Const nor variables from Var." - Regarding "Atomics/Terms" in PRD vs. "Terms/Base Terms" in BLD: why depart from BLD? This is a source of confusion and I see it nowhere justified. 2.1.1.3 Formulas - Quoting: "The function Var(e) that maps a term, atomic or formula e to the set of its free variables is defined as follows: * ... * if f is a condition formula and xi ? Var for i = 1..n, then, Var(Exists x1 .. xn (f)) = Var(f) - {xi}." It should be " ... Var(Exists x1 .. xn (f)) = Var(f) - {xi | i = 1 .. n}." BTW, the notation "x1 .. xn" or "1 .. n" is non standard; why not use normal English punctuation; namely, "x1 ... xn" or "1 ... n"? (This remark applies to all the document.) 2.1.1.4 Wellformed Formulas - Section title should be "Well-formed formulas". - Quoting: "... (remember that only procedurally attached function can be serialized using RIF-PRD)." No - I don't remember. What is a "procedurally attached function"? Has it been defined earlier in this document? What is is remark about? - Quoting: "... Definition (Well-formed formula). A formula \phi\ is well-formed iff: * every constant symbol mentioned in \phi\ occurs in exactly one context. * ..." Question: Does this make sense? What about the constant "a" in a formula such as, e.g., "And(p(a),q(a))"? Doesn't it occur in two separate contexts (namely, those of predicates "p" and "q")? - Quoting: "Whenever a formula contains a function term t or an external atomic formula External(t), t must be an instance of the coherent set of external schemas (Section Schemas for Externally Defined Terms of [RIF-DTB]) associated with the language of RIF-PRD." I looked up the reference section in [RIF-DTB] (http://www.w3.org/2005/rules/wg/draft/ED-rif-dtb-20081125/#app-external-schema) and I read this: "Definition (Coherent set of external schemas). A set of external schemas is coherent if there is no term, t, that is an instance of two distinct schemas in the set. ? The intuition behind this notion is to ensure that any use of an external term is associated with at most one external schema. This assumption is relied upon in the definition of the semantics of externally defined terms. Note that the coherence condition is easy to verify syntactically and that it implies that schemas like (?X ?Y; ?X[foo->?Y]) and (?Y ?X; ?X[foo->?Y]), which differ only in the order of their variables, cannot be in the same coherent set." I am not sure I understand this: what about t = a (i.e., a[foo->a])? I do not see either that, "... it implies that schemas ... which differ only in the order of their variables, cannot be in the same coherent set." Can anyone enlighten me? - General comment: This notion of WFF is highly uncommon and deserve some elaboration and explanation in lay terms. Many a reader (like me) are baffled at this point with so many technical requirements to define such a simple notion. - Quoting: "Definition (RIF-PRD condition language). The RIF-PRD condition language consists of the set of all well-formed formulas that can be serialized using the RIF-PRD XML syntax." This definition does not make any sense to me. What does to "be serialized using the RIF-PRD XML syntax" mean? 2.1.2 Semantics of condition formulas 2.1.2.1 Semantic Structures - Section title should be "Abstract structures" (no capital "S"). - Quoting: "(We shall see later that o[a->b a->b] is equivalent to o[a->b];)". Why should it be so? For example, a collection semantics might interpret this as o[a->list(b,b)]. - Quoting: "The operator ## is required to be transitive ... This is ensured by a restriction in Section Interpretation of condition formulas;" The word "restriction" is not adequate - "requirement" is better. Better yet, a "semantic coherence requirement". (Or even simplier yet for the algebra lover in me, it would suffice to say that the I mappings are morphisms that preserve subclass ordering and class membership.) - Quoting: "The relationships # and ## are required to have the usual property ... This is ensured by a restriction in Section Interpretation of condition formulas;" Same comment as above re: restriction/requirement. - Quoting: "For each external schema \sigma\ = (?X1 ... ?Xn; \tau) in the coherent set of external schemas associated with the language" The link associated to "language" is stale (http://www.w3.org/2005/rules/wg/draft/rif-prd/#def-bld-lang). - Quoting: "Jumping ahead, we note that duplicate elements in such a bag do not affect the value of I_frame(I(o)) -- see Section Interpretation of condition formulas. For instance, I(o[a->b a->b]) = I(o[a->b]);" Again: Why should it be so? Why force a particular collection semantics? We might very well interpret this as o[a->list(b,b)]. - Quoting: "I(External(t)) = I_external(\sigma)(I(s1), ..., I(sn)), if t is an instance of the external schema \sigma\ = (?X1 ... ?Xn; \tau) by substitution ?X1/s1 ... ?Xn/s1. Note that, by definition, External(t) is well-formed only if t is an instance of an external schema. Furthermore, by the definition of coherent sets of external schemas, t can be an instance of at most one such schema, so I(External(t)) is well-defined." The form of the term "t" is nowhere defined - its arguments must be s1, ... sn. 2.1.2.2 Interpretation of condition formulas - Quoting: "Existence: TVal_I(Exists ?v1 ... ?vn (\phi)) = t if and only if for some I*, described below, TVal_I*(?) = t. Here I* is a semantic structure of the form , which is exactly like I, except that the mapping I*_V, is used instead of I_V. I*_V is defined to coincide with I_V on all variables except, possibly, on ?v1,...,?vn." Why so complicated? Why not simply rephrase that as, "Existence: TVal_I(Exists ?v1 ... ?vn (\phi)) = t iff TVal_I(\sigma(\phi)) = t for some variable valuation \sigma\ : Var -> D_ind. 2.1.2.3 Satisfaction of a condition - Quoting: "Definition (Logical entailment). Let \phi\ and \psi\ be formulas. We say that \phi\ entails \psi, written as \phi\ |= \psi\, if and only if for every semantic structure, I, for which both TVal_I(\phi) and TVal_I(\psi) are defined, I |= \phi\ implies I |= \psi." This defines a notion (viz., "entails") using another one (viz. "implies") - but what does "implies" mean? I propose to rephrase this to, "I |= \psi\ HOLDS WHENEVER I |= \phi\ does." Same remark for the paragraph following the above quote. - Quoting: "Definition (Condition Satisfaction). ..." The definition, again, is uselessly wordy and complicated (see same remark above). Especially since this wordy and confusing definition is then followed by the crystal-clear and formally correct: "In other words, a set of ground formulas \phi\ = {\phi_1, ..., \phi_m}m => 1 satisfies a condition formula \psi\ iff \phi\ |= Exists ?v0 ... ?vn (\psi), where {?v0, ..., ?vn}n >= 0 = Var(\psi)." So why not simply replace the text of the definition by: "Definition (Condition Satisfaction). A set of ground formulas \phi\ = {\phi_1, ..., \phi_m}m => 1 is said to satisfy a condition formula \psi\ iff Var(\psi) = {?v0, ..., ?vn}n >= 0 and \phi\ |= Exists ?v0 ... ?vn (\psi)." 2.1.2.4 Matching substitution - Quoting: "Definition (Ground Substitution). A ground substitution is a substitution \sigma\ that assigns only constants to the variables in Dom(\sigma): \forall x \in\ Dom(?), \sigma(x) \in\ Const." This is odd: in Logic, a ground substitution assigns only ground terms to its variables, not only just constants. - In the definition of matching substitution, the second occurence of \psi\ is incorrectly capitalized; and, "if an only if" should be "if AND only if". Again, this definition is overly complicated and confusing. I would rephrase it much more simply and as formally (and as correctly) as: Definition (Matching Substitution). Let \psi\ be a condition formula, and \phi\ be a set of ground formulas that satisfies \psi. We say that \psi\ matches \phi\ with substitution \sigma : Var -> Terms if an only if there is a syntactic interpretation I such that for all ?xi in Var(\sigma), I(?xi) = I(\sigma(?xi)). Such a substitution is necessarily ground because all the \phi_i's are ground. A syntactic interpretation is one where the semantic domain for D_ind is the set of ground terms. Note that I left out the the subscripts for I; i.e., I wrote "I(?xi) = I(\sigma(?xi))" instead of I_V(?xi) = I_C(\sigma(?xi))". This is because they should be clear from the context, and also that I do not agree that it shound be "I_C" (and with this document's definition of ground terms) because for me (contrary to the RIF-PRD document's editors), a ground substitution may map variables to ground terms, not just constants. In the last paragraph starting with "In other words, ...", a reference is missing. Also, I do not understand "in the usual sense of pattern matching algorithms, e.g. [REFERENCE]" - there is no such "usual sense" - which is why we need to make our definitions clear and simple. 2.2 Actions 2.2.1 Abstract Syntax - Section title should be "Abstract syntax" (no capital "S"). - Quoting: "For a production rule language to be able to interchange rules using RIF-PRD, its alphabet for expressing the action part of a rule must, at the abstract syntax level, consist of syntactic constructs to denote: * the assertion of a positional atom, an atom with named arguments, or a frame, membership, or subclass atomic; * the retraction of a positional atom, an atom with named arguments, or a frame; * the addition of a new frame object; * the removal of a frame object and the retraction of the corresponding frame and class atomics; * a sequence of these actions, including local variables and a mechanism to bind a local variable to a frame slot value or a new frame object." At this point the reader has no clue of what an assertion/retraction or an addition/removal is (of what into/from what?), nor what the difference is between the two, nor what justifies that they act on the listed sorts of items and not others. I strongly recommend that the whole section on Actions start with a description of what global structure PR actions act upon (i.e., working memory, agenda, object base, ...) and what sort of items populates such structures. It should be a synopsis describing the abstract architecture common to most PR systems. 2.2.1.1 Atomic actions - Quoting: "Definition (Atomic action). An atomic action can have several different forms and is defined as follows: 1. Assert: If \phi\ is a positional atom, an atom with named arguments, a frame, a membership atomic, or a subclass atomic in the RIF-PRD condition language, then Assert(\phi) is an atomic action. \phi\ is called the target of the action. 2. Retract: If \phi\ is a positional atom, an atom with named arguments, or a frame in the RIF-PRD condition language, then Retract(\phi) is an atomic action. \phi\ is called the target of the action. 3. Retract object: If t is a term in the RIF-PRD condition language, then Retract(t) is an atomic action. t is called the target of the action." Again: asserting/retracting into/from what? No notion of working memory, object or knowledge base has been defined at this stage. Use examples to introduce new notions *before* their giving formal defintions. A good systematic editorial strategy to follow is first to give an informal example, then define the notion formally, then related the just-given formal definition to the example given before it. BTW, I would not "retract" an object, but "remove" it. 2.2.1.2 Action variable bindings - This section will be puzzling to many readers in its current form. Please use an example to motivate the intuitive understanding of the purpose of action variables and their "bindings". Instead of making a forward reference to the yet undefined concept of "action block", a simple example and commenting it would give more sense to the definition following it. BTW, if - as I recommend that it should - the whole section on Actions started with a concrete example and an informal description of its structure and intended semantics, along with references to the subsequent sections in which their are more formally defined, that would give the reader a sense of direction. Basically you should introduce the notion of block and bindings together appealing to familiar notions such as a "let block" in LISP or Scheme (or lambda-calculus for that matter!). It is just a form of the familiar (let ((?x1 t1) ... (?xn tn)) body) and New(_) is (gensym). 2.2.1.3 Action blocks - Quoting: "Definition (Action block). If v1, ..., vn1, n1 >= 0, are variables (sometimes called action variables) and b1, ..., bn2, n2 >= 0, are action variable bindings and a1, ..., an3, n3 >= 1, are atomic actions, 1. if n1 = 0 then Do(a1 ... an3) is an action block. 2. else Do v1 ... vn1(b1 ... bn2; a1 ... an3) is an action block." Question: Why are actions ai's constrained to be *atimic* only? Why disallow nesting of actions that might share common contexts of variables and bindings? - The definition of a "well-formed action block" is baffling, pulled out of a hat, and unmotivated. The reader ponders, "why?" and "where's an example?". Show some ill-formed blocks and explain informally why they should be declared ill-formed. - Quoting: "Definition (Ground atomic action). An atomic action with target t is a ground atomic action (or, simply, a ground action) if and only if Var(t) ? bv, where bv is the set of variables declared in an enclosing action block, if any." Is the ending "if any" needed? A binding may not occur outside a block, right? 2.2.1.4 RIFBLD compatibility - I think this "compatibility" is misleading since the PRD rule: IF \psi\ THEN DO(ASSERT(\phi_1),...,ASSERT(\phi_n)) could then be written: IF \psi\ THEN AND(\phi_1,...,\phi_n) which has a different reading in logic. The former asserts new facts conditionally on the truth of a guard, while the latter tests whether a set of facts hold conjointly conditionally on the truth of a guard. 2.2.1.5 Wellformed actions - Section title should be "Well-formed actions". - Again: missing motivating examples illustrating why ill-formed actions pose problems. 2.2.2 Operational semantics of actions - Quoting: "The effect intended of the ground actions in the RIF-PRD action language is to change the set of conditions that are satisfied before and after each action is implemented." This makes no sense to me. What does "implement an action" mean? (I understand what "performing" an action means though.) - The definition of the "RIF-PRD transition relation" is giving me headaches every time I try to understand it - even with the informal comments following it. Why is this correct as a definition? Coule we have any justification that it does cover the type of PR systems in the RIF family? - Quoting: "... 1. for every constant k in W, w |/= c_i#k and ...". What does this "c_i#k" denote? - This definition is way too complex and impossible to comprehend - at least by this reader. It is so because it is not abstract enough. Basically, the formalism used is describing a particular - nay, peculiar - operational semantics aiming at rigor without motivating that rigor (Is it used in proofs? What sort of proofs? What sort of formal reasoning does this enable? Have you proven these rules to be confluent (Church-Rosser)? Terminating? What are the formal properties of the arrow you are defining (i.e., your labeled-transition relation)? In other words, what does all this formalism allow us to do that we couldn't do before - or not as easily? These are the questions the editors ought to ask themselves because they are indeed those that the readers of their document will ask themselves. Formalizing should *clarify* complex things, not *complexify* simple things. It should not be an exercise for the sake of making things look mathematical; it's only worth is if it gives one confidence that it captures simply and precisely what one can understand intuitively. In other words, it should follow the precept of the well-known maxim: Ce que l'on conçoit bien s'énonce clairement Et les mots pour le dire arrivent aisément. -- Nicolas Boileau Lest some readers may relate to the following quip: Mathematicians are like Frenchmen: whatever you say to them they translate into their own language and forthwith it is something entirely different. -- Johann Wolfgang von Goethe One can only imagine, then, how a French mathematician might have sounded to Goethe! ;-) 2.3 Production rules and rulesets 2.3.1 Abstract syntax 2.3.1.1 Rules - Quoting: "A rule If condition, Then action can be equivalently noted action :- condition, that is, using RIF-BLD logic programming notation." Logic Programming should be capitalized. - Quoting: "A rule If condition, Then action can be equivalently noted action :- condition, that is, using RIF-BLD logic programming notation. Indeed, the normative XML syntax is the same for a conditional assertion in RIF-BLD and for a conditional action in RIF-PRD. The use of RIF-BLD notation is especially useful if the condition formula, condition, contains no negation, and if action is an atomic conclusion or a conclusion block, to emphasize that such a rule has the same semantics in RIF-PRD and RIF-BLD." Does it? Have you proved it? Can you prove it? (See my comment above in Section 2.2.1.4 on RIFBLD compatibility.) Does your (Plotkin-style) formal operational semantics allow you to make such a strong statement formally? Is the semantics of 'do/assert' consistent with that of 'and'? Hard for me to see such a fact from whant I have read. Quoting: "Notice that the notation for a rule with bound variables uses the keyword Forall for the same reasons, that is, to emphasize the overlap with RIF-BLD. Indeed, although Forall does not indicate the universal quantification of the declared variables, in RIF-PRD, but merely that the execution of the rule must be considered for all their bindings as constrained by the binding patterns, the semantics of a RIF-PRD rule with bound variables and the semantics of a RIF-BLD universally quantified rule coincide whenever they have the same RIF XML syntax." This is yet another misleading notation. Forall means something very specify in logic to 9.99999% of the potential readers of these specs. 2.3.1.2 Groups - No motivation. No examples. Just a bare definition. What is a "conflict resolution"? What is the priority meant for? 2.3.1.3 Wellformed rules and groups - Section title should be "Well-formed rules and groups". - Quoting: "Definition (Well-formed rule). A rule, r, is a well-formed rule if and only if it contains no free variable, that is, Var(r) = 0" It should be the empty set symbol not 0. 2.3.2 Operational semantics of rules and rule sets - Quoting: "... determine an action a1, which execution results in a new set of facts w1; ..." Replace "which" by "whose". - Example 3.1: At last an example! (Example 1.1 describes a potential situation that could be modeled with PR's; and Example 1.2 gives a small [but useful] example). However the example is contrived, whimsical, and down-right incomprehensible! It may be funny; however, the point is not to make the readers laugh but rather to make them understand complex issues by illustrating technical concepts with examples using simple situations likely to be familiar to most of them. - Quoting: "In the remainder of this section, as in the section on the operational semantics of actions, ..." The link associated to "operational semantics of actions" is stale: http://www.w3.org/2005/rules/wg/draft/rif-prd/#sect-semactions - Quoting: "For the purpose of this section, an instance of a rule, r \in\ R, is defined as a couple (rid, \sigma), where rid uniquely identifies r and \sigma\ is a ground substitution ..." More precisely, this is a *ground* instance of a rule. - Quoting: "The idea is that a state, c, is made of a set, w, of ground FORMULAe ..." It should be "formulas". - Beyond this point, the level of complexity of so many contrived and ill-motivated definitions makes it very difficult for me to follow and understand the technical intricacies developed. While I understand the purpose (being myself familiar with some PRD systems - at least ILOG JRules - and having also defined a much simpler formal operational semantics of Business Rules - http://wikix.ilog.fr/wiki/pub/Main/HassanAitKaci/ifip07.pdf), I do not understand the useless complexity of this apparatus. IMHO, this is due to mixing of several independent levels at the same time: - rule/group syntax - object model, matching/instantiation - execution architecture (meta-cycle of state transitions) - control/conflict parameters - control/conflict strategies - ... Hence, this reviewer can give no guarantee of consistency nor adequacy of the reviewed formalism because it is too difficult for him to read without suffering a major headache, let alone understand it. 2.3.2.1 Rules instantiation: INSTANTIATE 2.3.2.2 Instances selection: PICK 2.3.2.2.1 Conflict resolution: rif:standardForward 2.3.2.3 Halting test: FINAL 3 XML Syntax - Section title should be "XML syntax" (no capital "S"). - This section was not reviewed in any detail due to its rather mundane contents. 3.1 Notational conventions 3.1.1 Namespaces 3.1.2 BNF pseudoschemas 3.1.3 Syntactic components 3.2 Conditions 3.2.1 TERM 3.2.1.1 Const 3.2.1.2 Var 3.2.1.3 External 3.2.2 ATOMIC 3.2.2.1 Atom 3.2.2.2 Equal 3.2.2.3 Member 3.2.2.4 Subclass 3.2.2.5 Frame 3.2.2.6 External 3.2.3 FORMULA 3.2.3.1 ATOMIC 3.2.3.2 And 3.2.3.3 Or 3.2.3.4 NmNot 3.2.3.5 Exists 3.3 Actions 3.3.1 ACTION 3.3.1.1 ATOMIC_CONCLUSION 3.3.1.2 ATOMIC_ACTION 3.3.1.2.1 Assert 3.3.1.2.2 Retract 3.3.1.3 ACTION_BLOCK 3.3.1.3.1 New 3.3.1.4 CONCLUSION_BLOCK 3.4 Rules and Groups 3.4.1 RULE 3.4.1.1 ACTION 3.4.1.2 Implies 3.4.1.3 Forall 3.4.2 Group 3.5 Nonsemantic carrying constructs - Section title should be "Constructs carrying no semantics". 3.5.1 Document 3.5.2 Metadata 4 Presentation syntax 5 References 6 Appendix: XML Schema for RIFPRD - Section title should be "XML schema" (no capital "S", and no "for RIFPRD"). 7 Appendix: Compatibility with RIFBLD 7.1 Syntactic compatibility between RIFPRD and RIFBLD 7.2 Semantic compatibility between RIF-PRD and RIF-BLD