- 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