Re: [PRD] review of the frozen draft of Nov 25

On Tue, 02 Dec 2008 14:45:54 +0100
Christian de Sainte Marie <csma@ilog.fr> wrote:

> Michael,
> 
> Thanx for the very detailed review. Here below some first replies.
> 
> Michael Kifer wrote:
> > 
> >       Editorial comments
> > 
> >     * The nesting level of sections is 4 - too deep compared to BLD,
> >       which has only a few level-3 sections. I suggest to get rid of
> >       "Abstract Syntax & Semantics" and make "Conditions", "Actions",
> >       and "Production Rules" into top level sections 2, 3, and 4,
> >       respectively.
> 
> Is the nesting level really problematic? The point is that, if we get rid of
> the "Abstract syntax and semantics" and "XML syntax" level, we the
> "Condition", "Actions" and "Production rules" sections repeated twice.

It is an aesthetic issue. Not a show-stopper, but it would improve the
appearance somewhat. 

> Or would it be ok to keep 4 levels in te "XML syntax" section?

Basically, the fewer such deeply nested sections you have - the better.


> >     Specific Comments
> > 
> >    1. Sec 1, above Ex 1.1: /Actions can modify the facts, not only the
> >       knowledgebase/
> > 
> >       Usually facts are considered part of the knowledge base, so this
> >       remark can be confusing to some readers.
> 
> I rewrote that: "Actions can modify the facts themselves, not only extend the
> knowledge." Is that any clearer? 


Ah, this is what you meant... I'd simply write this then:
"Actions can add, delete, or modify facts in the knowledge base."


> >    2. Same page: /2. Conflict resolution/.
> > 
> >       Would be appropriate to briefly explain this notion here.
> 
> Is it the reference to a strategy that is unclear, in the short explanation
> ("select rule instances to be executed, per strategy")? Would "apply
> predefined selection strategy to select rule instances to be executed" be
> better?

No, I meant something like "A conflict resolution strategy determines the rule
to use in the next derivation when several rules are enabled at any particular
point. We discuss these notion in more detail in Section ..."


> >    4. Sentence right after Ex 1.2: /RIF-PRD and RIF-BLD ... in both
> >       dialects./
> > 
> >       This is an awkward and unclear sentence. Please use something like
> >       this instead:
> > 
> >             The condition sublanguages of RIF-PRD and RIF-BLD have much
> >             in common. However, the presentation syntaxes for the rules
> >             are different, largely due to the different traditions in
> >             production rules and logic programing communities.
> >             Nevertheless, XML serializations of these syntaxes, again,
> >             have much in common, so many XML documents are valid in both
> >             dialects and have the same meaning.
> 
> That was not exactly the intended meaning (so, the original sentence was, indeed, unclear). I rephrased that as:
> 
> "The condition languages of RIF-PRD and RIF-BLD have much in common,
> including with respect to their semantics. Although their abstract
> syntax and their semantics for rules are different, due to the
> operational nature of the conclusions in production rules, their is a
> subset for which they are equivalent. For that subset, the XML syntax
> is common, so many XML documents are valid in both dialects and have
> the same meaning."

Hmm. I do not see much difference in the meaning between what you just wrote and
what I suggested. My wording is more direct and easier to understand, I think.
If you feel that the two sentences mean radically different things then
both might be unclear.


> >    6. 2nd sentence after the bullets: /That notation is not ... XML
> >       syntax./
> > 
> >       Please replace with: /This notation is not intended to be a
> >       concrete syntax, and so it leaves out many details. The only
> >       concrete syntax for RIF-PRD is its XML syntax./
> 
> Why not. What is wrong about the original sentence ("That notation is not
> intended to be a concrete syntax and it leaves out many details that
> are not needed for its purpose: the only concrete syntax for RIF-PRD
> is the XML syntax")?

I think your sentence is hard to parse. Do not use long sentences in technical
writing.


> >    7. Next paragraph, last sentence: / This is one of two points ...
> >       languages also use./
> > 
> >       An unclear sentences. Please rephrase.
> 
> Rephrased as: "RIF-BLD specifies, in addition, a construct to denote logic
> functions, 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." Is that better?

How about this, which is more precise and avoids long sentences:

RIF-BLD also allows the use of uninterpreted function symbols to construct
terms, which is not permitted in RIF-PRD. This is one of the differences
between the alphabets of the condition languages of RIF-PRD and RIF-BLD.


> >    8. Sec 2.1.1.2 Atomics: The terms /atomics/ and /atomic/ are awkward
> >       when used as nouns. This often leads to awkward, ungrammatical, or
> >       unclear sentences. Worse yet, it seems to me that /atomics/ and
> >       /atomic formulas/ are the same, so you introduce two terms for one
> >       notion.
> 
> Yes, atomic and atomic formula are the same.  We took that usage of atomic
> from an ealier version of BLD, I guess :-)

No, BLD never used this term. There was a signature name called atomic and
there is a non-terminal in EBNF. But there was never such a notion used as a
noun in the text.

> I corrected that in the whole document (I hope I did not miss too many).

Good.

> >    9. Section 2.1.1.4, well-formed formulas.
> > 
> >       This section was copied from BLD at the time when it had a
> >       problem. The context of individuals was not defined at the time,
> >       and there was an inconsistency in the definition of the context
> >       for the nullary symbols of the form f(). This has now been fixed
> >       in BLD, so please transfer the changes from there.
> 
> Done. Btw, in the BLD def of a well-formed formula, the square is at the end
> of the but last bullet item.

Thanx. Fixed.

> >   10. Section 2.1.2.1, Semantic structures.
> > 
> >       For production rules you need to use Herbrand domains. Otherwise,
> >       the definition of the models would be broken (as it is right now).
> >       PRD uses inflationary semantics for negation, and using general
> >       domains is problematic in this context.
> > 
> >       Since BLD's semantics maps everything into the domain (including
> >       predicate formulas), the domain for PRD's semantic structures
> >       should consist of all terms, all atomic formulas, plus all the
> >       domains for the data types.
> 
> 
> Do you mean that just replacing the sentence "here D is a non empty set of
> elements called the domain of I" by "Here, D is the non empty set of all
> terms, all atomic formulas and the union of all the domains for the data
> types" would do the trick?


Yes (make sure to stress that these are ground terms/atomic formulas).
Also, probably still useful to call D the domain in the above definition.

By the way, concerning today's discussion about the difficulty in making the
changes, the above fix is not the one that is hard to do. I think that the
hardest is to fix the definitions in the section on the operational semantics
so that it would be easier to read.


	--michael

Received on Tuesday, 2 December 2008 17:28:07 UTC