BLD review (ACTION 421)

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 

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

"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 


Received on Tuesday, 19 February 2008 13:38:15 UTC