W3C home > Mailing lists > Public > public-rif-wg@w3.org > April 2008

Re: Review of RIF-FLD, version of April 14, 2008

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Wed, 16 Apr 2008 23:16:29 -0400
To: Leora Morgenstern <leora@us.ibm.com>
Cc: public-rif-wg@w3.org
Message-ID: <12859.1208402189@cs.sunysb.edu>

Hi Leora,

Thanks much for your comments. There is always room for improvement :) I
put the required fixes into the wiki, but unfortunately they did not make
it into the published draft.

> 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. 

Please check if the new version is satisfactory.

> p. 7,  item 8. in 2.1 :
> There should be some discussion of rules vs. material implication. 

I added a parenthetical remark. Please see if sufficient.

> 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.

I am not sure I understood you here, but I added examples in that
place. See if this makes things better.

> 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. 

I added a short example. Hope it makes this 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?

Yes. I added a note to clarify this.

> 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.

Done, please see.

> 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.

This would be an overkill. The motivation was hidden in the word
"succinct".  EBNF is really redundant, but redundant != useless.  We
believe it is useful because it is a very succinct overview of a
not-too-big superset of the language. I put in a better wording now.

I would not fight for EBNF, if too many people will find it useless,
but I think I should not be worried about EBNF's fate.

> 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.

I do not understand. There is only one ex, example 3, in that section. This
ex is also written in the presentation syntax, not just in XML. I do not
think there is much value presenting it in a textbook logic syntax, if this
is what you meant.

> 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.

But being too serious about it may be worse :-)

Seriously, I do not think it is that bad. The translation is not actually
unsound -- it is just not precisely what was written (implied by, not
equivalent).  In any case, I added an apology for the imperfect

> What, in any case, do you mean by "mathematical English"?

Something like this?

See: you did not even suspect that you are fluent in yet another language!

If you need more info, google it.

Received on Thursday, 17 April 2008 03:17:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:50 UTC