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

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

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

I do not object if you make it crispier. Also, my original comment was that we
need to actually make this common subset more explicit (no negation, assertions
only).


> >>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 :-)

Well, we can use something else instead of uninterpreted function symbols.  The
problem is that while my formulation might only raise questions, your use of
"logical functions" is terminologically incorrect. These symbols are called
"non-logical (function) symbols" in logic!

Instead of "uninterpreted ..." we could say simply "function symbols".
This is not quite crisp, since builtin functions are also symbols, but people
should understand.


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

Actually more than that - I forgot. You need to define things so that
I(groundatomicformula) = groundatomicformula. This would actually follow if you
define I_C(c)=c for every constant c. But, in addition, this makes it possible to
simplify things in the definition of the mapping I (in the Def of semantic
structures). 
For instance, since predicates are always constant symbols in PRD, there is no
longer a need to write I_P(I(p)) and I_NP(I(p)): I_P(p) and I_NP(p) suffice.
Likewise, the mapping I_= is now the identity on the domain, so I(x=y) is true
iff I(x)=I(y) (instead of having to write I_=(I(x),I(y)).


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

I was trying to be charitable :-)
It was hard to actually understand because things were not explained well
enough. There were undefined symbols, hard-to-remember notation, and
unnecessary complications, as I indicated in my review.

I understand that it might be hard to read FLD as well, but I was trying to
make it easier by addressing everybody's comments. The worst is when things are
left undefined and notation is dense. The reader is usually a better judge.

    
	--michael  



> 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 Wednesday, 3 December 2008 00:51:13 UTC