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

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

If you prefer... Done.

>>>   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 ..."

Ok. I added a sentence like that to the next paragraph (following the short description of the cycle).

>>>   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.

They do not mean radically different things, but the focus is slightly different. Except if you object, I will keep by my wording (or try to make is crispier).


>>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.

Because I would think that is is less understandable for a PR audience ("what the hell is an uninterpreted function symbol used to construct a term?"; I can hear them from here :-)


>>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.


Good. We will do that.

> 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.

Easier to read is relative. I find FLD much more difficult to read than PRD.

But, yes, trying to make PRD easier to read is a worthy objective. Implementing your comments is not that difficult is what I meant. Because I understand them; not like the ones about satisfaction etc :-)

Cheers,

Christian

Received on Tuesday, 2 December 2008 18:02:57 UTC