- From: Christian de Sainte Marie <csma@ilog.fr>
- Date: Tue, 09 Dec 2008 08:09:10 +0100
- To: Hassan Ait-Kaci <hak@ilog.com>
- CC: rif-wg <public-rif-wg@w3.org>
Hassan,
</chair><PRD editor>
Thanx for the valuable comments. Overall, I agree with them. We (PRD editors) had to make a couple decisions re what we could reasonably do about them before WD2, though.
Below, our reply to your comment, per item (including the simple edits, but it makes easier to check that we replied to everything).
Hassan Ait-Kaci wrote:
>
> 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.
Unfortunate, but most likely true.
This is due to a number of factors, and there is probably not much we can do about it on the very short term. We propose to add a couple editors' notes at strategic places: they will not make things easier to understand, but we hope that they will provide enough background to relieve some of the confusion and perplexity.
> 1. [...] Why can't we use (La)TeX in our Wiki documents? (Sandro?) [...]
Would it help to use LaTeX for the draft, if the final document has to be HTML?
> 2. Examples are too few and far between. The formal presentation should
> illustrate each newly defined formal concept on a simple example.
Right. Unfortunately, it is unlikely that we will have enough time to make that significantly better in the short time left bfore WD2: we will leave that at the bottom of the list, hoping that it will not be a showstopper.
> 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.
Right. We tried to improve that (see detailled comments).
> 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.
I agree, personnaly. This has been a recurring discussion and is unlikely to be solved before PRD WD2 is released (or so I hope. I mean, I hope that we will not have to wait that long for PRD WD2 :-)
Detailled comments:
> - 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.
Done (we used "labeled" throughout).
> - Missing reference "[Ref Plotkin]" (but cited correctly in 2.3.2).
Corrected.
> - Either use "formulas" or "formulae" but not both.
Done (we used "formulas" throughout).
> - Paragraph just before Example 1.2 ends with a semicolon.
Corrected.
> - 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,...".
The intended meaning was rather that they share not only part of their condition languages, but more... The sentence has been changed, based on Michael's and Paul's suggestions, anyway.
> 2 Abstact syntax and Semantics
>
> - Section title should be "Abstract syntax and semantics" (i.e., with
> an "r" in "Abstact" and no capital "S").
That level has been removed.
> 2.1 Conditions
>
> 2.1.1 Abstract syntax
>
> - Missing closing parenthesis in: "a countably infinite set of
> variable symbols Var (disjoint from Const;"
Corrected.
> - 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".
Relations, indeed.
> - Delete "arbitrary".
We rephrased the previous item as: "Relations, including equality, membership and subclass relations."
> - 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.
Changed, following Michael's suggestion, to: "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. RIF-BLD specifies, in addition, a construct to denote uninterpreted function symbols, which RIF-PRD does not require: this is one of two differences between the alphabets used in the condition languages of RIF-PRD and RIF-BLD."
> - Re: RIF-PRD conditions supporting negation - surely you mean
> *ground* negation.
Well, some kind of negation :-)
We changed the sentence to: "The second point of difference is that RIF-PRD does support a form of negation. RIF-BLD does not support negation because... "
Is that better?
> 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:
We used "atomic formula" everywhere in the document, instead, following Michael's suggestion.
"Atomic formula" rather than "atom", because that saves us one definition (that is, that atoms are also atomic formulas" :-)
> - 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.
Yes. The use of frames to represent object is one of the sources of confusion in PRD.
We added an editors' note: "Objects are commonly used in PR systems. In this draft, we reuse frame, membership, and subclass formulas (from RIF-BLD) to model objects. We are aware of current limits, such as difficulty expressing datatype and cardinality constraints. Future drafts will address that problem. We are interested in feedback on the merits and limitations of this approach."
Does it help?
> - 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."
Done. Thanx.
> - 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.
Remnant of earlier drafts and earlier organisations of the document, inherited from even earlier versions of BLD (was: Core).
In addition, I find "Atoms/Terms" less confusing "Terms/Base terms" (ok, that is only me).
Third, the PS and XML syntax use Atomic/Term, so, using them in the abstract syntax makes the mapping more immediate.
Whether or not being similar to BLD is a better argument than the latter two is open to discussion. However, the use of Atoms/Terms is too pervasive in the document, and changing would not be practical that close to publication.
Is it a showstopper?
> 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}."
Done.
> 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.)
Corrected.
> 2.1.1.4 Wellformed Formulas
>
> - Section title should be "Well-formed formulas".
Corrected.
> - 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?
Rewritten: "(only externally defined function can be serialized using RIF-PRD)."
The point is that the previous bullet mentions external and non-external predicates, so, it seemed a good idea to remind the reader that PRD has only external functions.
Or do you think nobody will wonder why fundtions are dealt with any differently from predicates, and we should just drop the parenthesis?
Also, we removed all references to "procedural attachments" etc, and unified the terminology to "externally defined".
> - Quoting: "... Definition (Well-formed formula). A formula \phi\ is
> [...]
>
> - Quoting: "Whenever a formula contains a function term t or an
> [...]
>
> - General comment: This notion of WFF is highly uncommon and deserve
> [...]
I leave that for you, Michael and other cognotienti to debate. We will align PRD to whatever your agree on in the end, if relevant.
Are these showstoppers for PRD WD2? We hope they are not!
>
> - 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?
It should have been "be meaningfully serialised using the RIF-PRD XML syntax." But this is the definition of well-formed, so it is redundant, indeed. So, we dropped it.
> 2.1.2 Semantics of condition formulas
>
> 2.1.2.1 Semantic Structures
>
> - Section title should be "Abstract structures" (no capital "S").
Corrected.
> - Quoting: "(We shall see later that o[a->b a->b] is equivalent to
> [...]
>
> - Quoting: "The operator ## is required to be transitive ... This is
> [...]
>
> - Quoting: "The relationships # and ## are required to have the usual
> [...]
We leave this for Michael, again :-)
> - 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).
Remnant from BLD (that whole section is copied from BLD :-).
Removed.
> - Quoting: "Jumping ahead, we note that duplicate elements in such a
> [...]
>
> - Quoting: "I(External(t)) = I_external(\sigma)(I(s1), ..., I(sn)), if
> [...]
>
> 2.1.2.2 Interpretation of condition formulas
>
> - Quoting: "Existence: TVal_I(Exists ?v1 ... ?vn (\phi)) = t if and
> [...]
Michael?
I like those comments where the editors have only to wait and see :-)
> 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.
Makes sense to me.
However, Adrian rewrote that section, based on Michael's comment, and the part that this comment addresses disappeared.
Adrian's rewriting has to be reviewed, btw (easy to say, when I did not even read it myself yet :-)
> - 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)."
Makes sense, indeed.
Anyway, that definition was also simplified by Adrian.
> 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.
With PRD covering only interpreted (externally defined) functions, a ground term is always equal to a (known) constant.
I corrected the definition and added after it the following sentence: "Notice that since RIF-PRD covers only externally defined interpreted functions, a ground term can always be replaced by a constant. In the remainder of this document, it will always be assumed that a ground substitution assigns only constants to the variables in its domain."
Does it make sense?
> - 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".
Done.
> 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.
It seems that that section still needs to be updated by Adrian, so, we will leave that one open for now.
> 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.
See above.
> 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.
Hmmm. This sentence was meant to make what precedes less frightening, that is, to tell the lay PR-oriented reader that everything that was defined before was only what he was used to, in different words.
We realize that such a warning should rather come before the frightening part than after: we will repair that mistake before WD2 publication if times permit, hoping that it is not a showstopper...
Re the missing reference: would you have one to suggest?
> 2.2 Actions
>
> 2.2.1 Abstract Syntax
>
> - Section title should be "Abstract syntax" (no capital "S").
Corrected.
> - Quoting: "For a production rule language to be able to interchange
> [...]"
>
> 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.
Here, again, the fact that the current version of PRD sits on frames, which are only a (probably inadequate) approximation when used to represent objects, does not help.
We will add an editors' note to explain (i) that this is only a first basic set of actions, and (ii) why they are different from what would be expected as the basic set in a directly object-oriented representation. We are currently drafting that editors' note and we will include it later today or tomorrow (hopefully, before the RIF telecon).
> 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.
Good point. Shouldn't tht rather be in the overview, though?
We will work on both (an introduction in the Oversiew section, and a preamble refering to that intro in the Actions section).
> 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.
I fully agree, of course. I have been told that this was not a tutorial, but I still fully agree with you :-)
We will add examples asap. And informal introductions as well, where useful.
> BTW, I would not "retract" an object, but "remove" it.
A more complete set of the actions that should be covered by PRD, and how they should be labeled, is an open issue (issue-62).
We (the PRD TF) prefered not to address that issue for WD2, though.
> 2.2.1.2 Action variable bindings
>
> - This section will be puzzling to many readers in its current form.
> [...] It is just a form of
> the familiar (let ((?x1 t1) ... (?xn tn)) body) and New(_) is
> (gensym).
That section has been partly rewritten. Hopefully, the new version makes the intent more obvious. And examples will be added asap; but, hopefully, the rewriting makes the intent clear enough that the lack of example is not a showstopper.
> 2.2.1.3 Action blocks
>
> - Quoting: "[...]"
>
> 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 has been rewritten, but the question remains valid. Allowing only atomic actions is a simplification, but the possibility to nest actions/action blocks should definitely considered.
Do you want us to raise an issue to keep track of the question?
> - 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.
Has been rewritten.
> - 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?
Has been rewritten.
> 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.
Good point. That section has been moved to the definition of Rule, and we have to consider whether the BLD-like notation should be allowed anywhere (with the problem you raise) or only for rules that are equivalent under a PRD and a BLD semantics; and whether it should be mandatory or optional. Do you want us to raise an issue?
> 2.2.1.5 Wellformed actions
>
> - Section title should be "Well-formed actions".
>
> - Again: missing motivating examples illustrating why ill-formed actions
> pose problems.
The section has been rewrittent. Hopefully, again, the rewriting makes the intent clear enough that the lack of examples is not a showstopper for WD2 publication.
> 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.)
Blame my poor command of the english language. I replaced implement with perform: does the sentence make sense?
> - 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?
Doesn't it quite obviously, with the restriction that this version has essentially only two actions, and that frame are not exactly object.
> - Quoting: "... 1. for every constant k in W, w |/= c_i#k and ...".
>
> What does this "c_i#k" denote?
This part has been rewritten. Do not the "informal" explanation of the three rules, below, clarify the meaning and intent, at least a little?
> - 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.
I am not quite sure which definition your are talking about, because that has been rather unstable lately. The current one (which is essentially, I think, the first three bullets of the one you did review), seems rather straightforward to me.
Of course, it can certainly be improved and simplified.
Re whether it needs to be based on entailment or whether, e.g. w' = w +/- phi is enough for, e.g., assert/retract, is something I need to understand better (I did not yet really go into Michael's answer to my question). We will use the simple version for WD2 (edits still to be done).
Re "what does all this formalism allow us to do that we couldn't do before - or not as easily?" The objective is to specify the semantics of PRD completely and unambiguously (and in a way that is powerful enough to be extended to future dialects if required) and to specify it in a such a way that it can be compared as easily as possible to that of Core and, more generally, to the BLD/FLD branc hof RIF. I am not aware of another proposal that allowed us to do it before (as easily or not).
Re whether or not we need the formalism: yes, the idea is to be able to prove things, and, essentially, that PRD extends Core. If it allows to prove more, the better, but formally establishing the relationships with the logical side of RIF is the raison d'être of the formalisation (that says nothing wrt the correctness of the proposed formalization; just motivates it).
Re confluence etc: some properties need be proven, indeed (as part of proving that the operational semantics is correct). Is it a showstopper for the publication of WD2?
> 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! ;-)
Very true, indeed. So are also:
"L'enfer est pavé de bonnes intentions."
"On ne fait pas d'omelette sans casser d'oeufs."
"Qui ne tente rien n'a rien."
"La critique est aisée, mais l'art est difficile."
Etc, etc.
> 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.
The sentence has been modified, following Michael's suggestion.
> - 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.)
It does not completely, and it has to be proven yet: by the way, if you want to try...
:-)
We added an editor's note to the effect that this was, at this stage, an unproven approximation, and that this aspect would be more completely addressed in a future version.
> 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.
Yes, it does, basically. But the devil is in the details and I did not check the details yet...
> 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.
Absolutely. Using "Forall" in PRD is misleading; hence the explanation.
Or do you mean that the explanation is misleading?
> 2.3.1.2 Groups
>
> - No motivation. No examples. Just a bare definition. What is a
> "conflict resolution"? What is the priority meant for?
We will beef up the preamble (not done yet). (But I would expect the PR-savvy reader to understand that without any more explanation that the shallow bit of background that is provided in the Overview section).
> 2.3.1.3 Wellformed rules and groups
>
> - Section title should be "Well-formed rules and groups".
it is, isn't it?
> - 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.
Right. Corrected.
> 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".
Corrected.
> - 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.
Aren't you familiar with growing chicken and mashing potatoes? How comes?
:-)
Yes, the example does not make sense anymore (assuming it ever did :-) now that we removed the explanation from the introduction.
The intention is, indeed, to replace it by a more meaningful one.
Hopefully in time for WD2.
> - 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
Corrected. We have to check all the links, anyway...
> - 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.
No, this is what is defined as an instance of a rule in this document. I am not aware of a different acceptation that would be usual enough to be a problem. Pointer?
We made that a "visible" definition, btw, and made the definition simpler, following Michael's suggestion.
> - Quoting: "The idea is that a state, c, is made of a set, w, of ground
> FORMULAe ..."
>
> It should be "formulas".
Corrected.
> - 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.
Ok. Sorry for the headache. We are continuously trying to simplify it. The version on the wiki is already simpler than the one you reviewed, and the version tomorrow will no doubt be better, etc.
That is made possible thank to the fearless reviewers who dare and try read and understand it, and provide feedback.
:-)
No, really, we appreciate the thorough comments. Adn we hope that you are not that disgusted that you will not try and read the remainder (once we will have improved its readability, of course :-)
Cheers,
</PRD editor><chair>
Christian
Received on Tuesday, 9 December 2008 07:10:13 UTC