Re: My review of RIF-Core document

Changhai Ke wrote:
> Attached is my review of RIF-Core document, in WORD tracking changes mode:

Thanks very much for your review. I believe I have addressed all your 
points, which seemed mostly editorial.

Using Word track changes made it easy to spot the editorial suggestions 
but makes it hard to report on how they have been handled. I have noted 
all the changes below but my paraphrases of your suggestions will only 
make sense if read in conjunction with your Word document.

Jos - I made one small change to your section (the discussion of the 
example, see below), please check I've not broken anything.

Dave

** Section 1

 > CK1: make a sentence here

Done

 > s/subset/specialization/

Done

 > CK2 Not clear. Can we put this in simpler words

Replaced:
   "constructions in the syntactic intersection of RIF-PRD and RIF-BLD 
which would not reach a stable fixed-point under RIF-PRD semantics."

with
   "rule sets in the syntactic intersection of RIF-PRD and RIF-BLD which 
would not terminate under RIF-PRD semantics."

 > s/perceived/judged/

Done

** Example 1

 > delete/rather than store them/

Done

 > s/text/phrase/

Done

 > Rephrasing of second to last para

Done

 > s/as RIF-Core is derived from these documents via syntactic 
restrictions/as RIF-Core is closely related to them./

NOT done. I think the existing phrasing is more useful.

** Section 1

 > insert/and only XML/

Done

** Section 2.1

 > insert/(subclass)/

Done

 > [what is Argnames for?]

Named argument uniterms, Done.


** Section 2.3

 > s/restrictions/modifications/

Done

 > delete/either/

Done

 > remove double negative

Done

 > s/frame formulas/frame constructs/

NOT done, "frame formulas" are well defined things in the spec. whereas 
"frame constructs" are not.

** Section 2.5

Section already substantially changed as result of other reviews.

** Section 2.6

 > s/overview/view/

Done

 > s/cannot be so expressed/cannot be expressed/

That would change the meaning. Instead I've put
/cannot be expressed in EBNF/

 > s/in its/divided into/

Done

** Section 6 (was 5)

 > s/are also syntactically RIF-PRD documents/are also valid RIF-PRD 
documents/

Done, I put /are also syntactically valid RIF-PRD documents/

 > Correct spelling of labelled/labelling in para starting "The tree 
corresponding ..."

Done

 > s/ground/grounded/

Done.

** Safeness example in 6.1 (was 5.1)

 > s/have/conclude/

Done

 > Not clear, do we need to prove that ?z is also bound?

Rephrased to move the reference to binding patterns next to the 
discussion of the first component and point out that ?z is bound:

[[[
  Forall ?x ?y ?z ?u (ex:p(?x) :- Or(
    And( ex:q(?z) External(pred:iri-string(?x ?z))))
    And( ?x=?y ?y=?u ex:q(?u)))

One can verify that this formula is safe, in the following way: the only 
variable appearing in the conclusion of the rule is <tt>?x</tt>; 
<tt>?x</tt> is safe in the first component of the disjunction, because 
it appears in the atomic formula <tt>pred:iri-string(?x,?z)</tt>. We 
have that <tt>(u,b)</tt> is a valid binding pattern for 
<tt>pred:iri-string</tt>, and <tt>?z</tt> is bound by virtue of 
<tt>ex:q(?z)</tt> and so <tt>?x</tt> is bounded as well.  We then 
conclude that <tt>?x</tt> is also safe in the second component, because 
<tt>?u</tt> is in the equivalent class of <tt>?x</tt> and appears in 
<tt>ex:q(?u)</tt>. Then, clearly the variables <tt>?z</tt> and 
<tt>?u</tt> are bounded.
]]]

Jos - is that OK for you?

** Section 6.2 (was 5.2)

 > s/over/with/

NOT done. That changes the meaning, conformance is with the 
specification not "with" the safe rules.

 > s/some datalog engines/datalog engines/

NOT done, it is not true of all datalog engines.

** Section 3.2 (was section 6.2)

 > CK5: Why do we speak about "atomic formulas" here?

Deleted.

** Section 3.4 (was section 6.4)

 > CK6: Not clear. What is allowed in annotation in Core? Write this in 
a clear way.

Last sentence already deleted due to other reviews which I think removes 
the confusion.

** Section 3.6 (was section 6.6)

 > CK7 - Note clear.

Already substantially revised due to other reviews. New version shorter 
and clearer.

** Section 7

 > CK8 "Conformant Core producers and consumers are required to support 
only the entailments of closed RIF condition formulas" is not clear

Done.

 > Feature at Risk #3 CK 9: What's strictness? The document has not been 
talking about this so far.

See second bullet point concerning "strict Core" and "run with 
extensions". This is the same text as used in BLD.

Received on Tuesday, 19 May 2009 15:42:46 UTC