- From: Leora Morgenstern <leora@us.ibm.com>
- Date: Tue, 19 Feb 2008 08:37:50 -0500
- To: public-rif-wg@w3.org
- Message-ID: <OFA9500C8A.0E8232DA-ON852573F4.004A2B51-852573F4.004AE043@us.ibm.com>
Review of RIF Basic Logic Dialect Working Draft --------------------------------------------------------------------- Overall comment: Harold and Michael have done an excellent job in presenting a clear, concise specification and explanation of BLD. Below are some comments, corrections, and suggestions for clarification. I've tried to write these comments from the point of view of someone who would be coming to this document with a reasonable background in FOL and understanding of the general aims of the RIF group but without any knowledge of the details of the RIF group's activities. Comments go in order of the document, so flagging of grammatical or spelling errors sometimes precede more substantive comments. p. 3, Section 1, 4th par: "However, it is envisioned that this fragment [the Condition Language] will have a wider use in RIF." A wider use than what? The rest of RIF? This should be clarified. p. 4, Section 2.0.1, discusion of bi_atomic. The choice of the term bi_atomic to represent atomic formulas for built-in predicates is somewhat unfortunately, since the "bi" prefix usually denotes "two." Why not use the term builtin_atomic, or at least, b_i_atomic ? p. 6, top of page, first full sentence. "Compared to RIF-FLD, terms (both positional and with named arguments) have significant restrictions." It would be good to briefly explain the reason for these restrictions. A few words (e.g., " ... in order to retain the compact form of BLD syntax") could suffice; or, a pointer to a longer explanation. p. 6, middle of page, discussion of supported symbol places. In general, the discussion and presentation of symbol spaces were the least clear part of this document. Since this is the first place where symbol spaces are introduced, it would be useful to give a brief explanation of the notion of a symbol space. p. 7. The middle of the page reads: "in order to make this document self-contained, we will now define the synax of RIF-BLD with no references to RIF-FLD --- expcept for Symbol Spaces whose definition we do not duplicate here." This is probably the most awkward sentence in this document, possibly because it reflects the difficulties in the general presentation of Symbol Spaces. A better phrasing might be: "In order to make this document as self contained as possible, we define the syntax of RIF-BLD, for the most part, with no references to RIF-FLD. An exception is the notion of Symbol Spaces. The discussion of Symbol Spaces in this document depends on the definition given in the RIF-FLD document, which in turn references several existing W3C documents and standards." p. 9, 3rd line of Section 2.0.5: "Equality, membership, subclass, and frame terms are also atomic formula." should read "Equality, membership, subclass, and frame terms are also atomic formulas." (That is, add "s" to "formula") p. 9, 1rst line of Section 2.0.6 "So far, the syntax of RIF-BLD was specified" should read ""So far, the syntax of RIF-BLD has been specified" (That is, replace the past tense with the present perfect tense.) p. 9. 2nd line of Section 2.0.6 "Tool developers, however, prefer the more formal EBNF notation." should read "Tool developers, however, may prefer the more formal EBNF notation." That is, add the word "may," because in fact, you don't know that all tool developers prefer the more formal EBNF notation. Or at least add the word "generally" or "usually." p. 10, line 9 "This is done on purpose, since RIF's presentation syntax" should read "This is done intentionally, since RIF's presentation syntax" p. 10, 2nd line of Section 2.0.6.1 "It is supposed to be a common part of a number of RIF dialects" should read "It is intended to be a common part of a number of RIF dialects" p. 10, EBNF grammar: There really needs to be an explanation of SYMSPACE at this point. It would be useful to at least cursorily explain that because different symbols can be used for different contexts / by different groups, it is important to specify in what context a particular symbol is being used. pp. 11-19: The examples are very useful. However, I believe the examples would be made still more useful if they would be preceded by a statement of the rules in some first-order logic syntax. This would highlight the machinery that is necessary in order to put the rules in BLD form. No comments on Section 2.0.8 (on translation): this was all very clear. p. 27. Section 3.0.4, paragraph on the semantics of the Subclass operator. I found this paragraph puzzling. It seems to just enforce that transitivity of subclass holds. But surely the semantics of subclass go beyond this: there are relations that are transitive that are not subclass. Regards, Leora
Received on Tuesday, 19 February 2008 13:38:15 UTC