- From: Leora Morgenstern <leora@us.ibm.com>
- Date: Tue, 15 Apr 2008 07:59:08 -0400
- To: public-rif-wg@w3.org
- Message-ID: <OF0578A2F5.A871C217-ON8525742C.0041A9A8-8525742C.0041D610@us.ibm.com>
Attached please find my comments on RIF-FLD, version of April 14, 2008. Comments are divided into general comments, specific comments, and issues relating to clarity and writing style. General comments: ============== Overall, this is a clear, good introduction to FLD. There are some parts, such as the discussion of signatures, that are not as clear as they could be. In several sections, there should be more motivation; discussion of how certain elements were introduced to enable and facilitate rules interchange would be helpful. There should also be more examples. This can certainly be published as a first working draft, but it would be good if the issues pointed out could be addressed in future versions. Specific comments: =============== Section 1, page 3, first paragraph: "It is a logic in which both syntax and semantics are described through a number of mechanisms that are commonly used for various logic languages, but are rarely brought all together." It would be helpful to have a brief explanation of why you are all bringing all these mechanisms together --- because the basic framework must be broad enough to accommodate many different types of logic languages, because various sophisticated mechanisms are needed to facilitate translation into a common framework. p. 7, item 8. in 2.1 : There should be some discussion of rules vs. material implication. p. 7, end of section 2.1: "A dialect might support all of these formulas or it might impose various restrictions. For instance, the formulas allowed in the conclusion and/or premises of implications might be restricted, certain types of quantification might be prohibited, classical or default negation (or both) might not be allowed, etc." It would be very helpful here to have some examples. Even pointing to just BLD in this context (what does BLD have or not have?) would be useful. p. 10, Section 2.4, definition of positional term. "For instance, the above definition allows variables everywhere." This is rather muddled. You want to say explain straight out the distinction between positional terms and terms with named arguments. It's odd: of course, when you are defining terms in a regular logic, without terms with named arguments, it's sufficient to just give the general definition for positional terms without further explanation. However, once you do introduce terms with named arguments, you need to specifically explain what's going on with the standard terms. p. 12, Section 2.5. I found the discussion of external schemas confusing. It would be helpful to have an example of how you anticipate these being used. This was an issue that I found came up several other times in this document. There are certain elements which appear to have been introduced based on how you expect the RIF to be used. But these elements aren't motivated, and aren't illustrated by example. It will probably be quite a bit of work to do so. That is, the articulation of these examples is time consuming and will probably bring us several problems. But it really needs to be done to make this document clearer. p. 12, discussion of coherence for sets of external schema: It would be helpful to discuss the intuition behind coherence. As it is written, I thought you might be characterizing sets of schema in which terms were unambiguous? p. 14: The discussion of the coherence of a set of signatures is not as clear as it could be. Again, a discussion of intuitions and motivation, as well as some examples, would help. Example 1 on pp. 17-18 was clear and helpful. Perhaps this example could be extended to address coherence. I got what you were getting at with Example 2. I think the choice of Hamlet for this example is a mistake; see my detailed comments on this further down. p. 19, section on EBNF grammar: This is a problematic section. You say "The syntax of RIF-FLD relies on the signature mechanism and is not context-free, so EBNF does not capture this syntax precisely." Well, more accurately, EBNF therefore doesn't capture the syntax. You say that the "EBNF grammar defines a strict superset of RIF-FLD." This is true. So what you really want to do is the following: 1. Define the superset-of-RIF-FLD class of languages that doesn't pay attention to signatures. 2. Present the EBNF for that. 3. Point out, as you already have, that therefore, the "EBNF grammar defines a strict superset of RIF-FLD." Otherwise you have a set of languages on the one hand, and an EBNF on the other hand, and neither one matches the other. pp. 30--32, section on examples in XML serialization. a. The example formalizations should first be presented in standard logic syntax, rather than just presenting them in XML. They would be much more readable and useful that way. b. Also: I realize that using whimsical examples like your "translations" from Hamlet is common when trying to explain logic. I've seen this frequently done in logic textbooks. I think it's unfortunate, especially in a document of this sort, for two reasons: First --- and I speak here as someone whose primary research interest is representing commonsense knowledge in formal logic --- it teaches people to construct terrible axiomatizations. You know that "Something is rotten in the state of Denmark" cannot really be translated as you have done in your example, by saying that there exists something rotten that is in the state of Denmark. (The meaning is that there is internal corruption in the entity that comprises the *political* state. This is not trivial to formalize correctly) But someone reads this example, and the next thing you know, that person constructs an ontology of things, and one subclass is of rotten things, and another subclass is of things that don't love walls and send the frozen-ground-swell under them, and all our formalizations degenerate into silliness. Second --- because the example formalizations don't really capture the natural language, they're harder to understand. Sometimes it really is better to be boring and humorless. Some sentences about pens of my aunt on the table would be fine. Even better would be simple examples from business, e.g., "Corporation X introduced a new plasma-screen TV in 2003. Sales topped $Y." Issues related to clarity, writing style, typos, etc. ====================== p. 4, halfway down the page: "These terms are common in most languages." I think you mean "These terms are common *to* most languages." p. 5, 2nd par in Signatures bullet: "For instance, the signature associated with a symbol, p, might allow p to appear ..." This should read: "For instance, the signature associated with a symbol p might allow p to appear ..." If you include the commas around the first instance of "p", you are saying that p is the signature. As I understand it, however, p is the symbol. p. 5, bottom of page: "Roughly speaking, a set of formulas, G, logically entails another set of formula, g, ..." a. You can leave out the commas around G or g. They don't change the meaning here, but they're unnecessary clutter. (And, I think, an actual error according to grammarians and style manuals.) b. "Roughly speaking" should be omitted. There's nothing rough or approximate about what you're saying. It's clear that this is the natural language description rather than a formal presentation. p. 6, top of page: a. "If I makes G true, then I also makes g true." "makes true" is an odd locution. Perhaps "If G is true under I, then g is also true under I." b. "Almost all known logics define entailment in this way." Delete the word "known". What are unknown logics, precisely? p. 19, top line: "Up to now, we used mathematical English ..." ==> "Up to now, we have used mathematical English" What, in any case, do you mean by "mathematical English"? p. 20, middle of page, item 5. "each dialect is must define" ==> "each dialect must define" p. 21, a few lines down: "such as the well-founded negation" omit "the" p. 27, bottom line: "The two most common theories of intended semantic structures are the so called well-founded models [GRS91] and stable models [GL88]." "so called" should be omitted. I've seen this locution frequently, but it may not be the best expression here. "So called" in English often has a connotation of illicit use, as if "well-founded" and "stable" are aliases for some other types of models trying to sneak in. (I have a feeling this locution may have crept in from an inaccurate translation from some other language.)
Received on Tuesday, 15 April 2008 12:09:16 UTC