[Core] Action 657: Review of Core

Below please find my review of the November 25 version of the Core 
document.

General comments: 

This document is a good draft, but could benefit from changes in some 
areas, specifically:
--- Some organizational/structural changes
--- More clarifying remarks
--- More examples
--- More explanation of how certain choices were made

Regarding the latter, I think it would be helpful to have some text 
addressing the following:
--- What were the problems encountered in formalizing an intersection of 
BLD and PRD?
--- How were these problems solved?


Specific comments: 

(Note: these are in order of the document, so minor remarks (e.g., typos) 
sometimes precede substantive remarks.)

Section 1.

It would be a good idea to say early in this section that this document 
assumes familiarity with BLD and PRD. Oddly, you have this at the 
beginning of Section 6 for PRD ("The reader is assumed to be familiar with 
RIF-PRD as described in ...") but it's never said that the reader is 
assumed to be familiar with RIF-BLD.
Better to have one sentence at the end of the first paragraph of Section 
1, such as "This document assumes familiarity with BLD and PRD as 
described in ..."  Then, of course, omit that sentence in Section 6.

This introductory section might also be a good place to have some sort of 
text as I suggested above, explaining what problems were encountered in 
formalizing the intersection of BLD and PRD, and how these problems were 
solved.

Section 2.

It would be good to explain --- even if with just a few appositive phrases 
--- how you define presentation syntax and concrete syntax, and how you 
define normative. As it stands, this is all quite confusing. Is there 
somewhere where "presentation syntax" and "concrete syntax" are clearly 
defined? Is there a common understanding of these terms?  I have seen them 
used before, e.g., in OWL documents, but there are differences: for 
example, the OWL Presentation Syntax clearly states that it's not intended 
to be a normative specification. Do you mean to say here that people 
should write rules in Presentation Syntax because it's less error-prone 
and it's easier to read than XML? And/or do you mean to say that the 
syntax and semantics of BLD were developed in something akin to 
Presentation Syntax, and that the XML specification was developed 
derivative of that? Whatever you mean, you should say it clearly.

Section 2.2: This is an example of where you could explain the choices 
made in constructing Core from BLD and PRD. Both BLD and PRD allow named 
arguments, so why doesn't Core?

Section 2.6:

If EBNF is unable to express all of the well-formedness of Core formulas, 
in particular because it can't express the requirement that symbols appear 
only in one context, then it can't specify Presentation Syntax. It 
specifies a superset of Presentation Syntax. This should be said 
explicitly. It's just not correct to say that this is an EBNF grammar for 
Presentation Syntax. (I made a similar point in my April 15 review of 
FLD.)

Section 3:

The sentence "RIF-Core is a syntactic subset of RIF-BLD and the semantics 
of RIF-Core is identical [to] that of RIF-BLD" is repeated as the first 
sentence of Section 5. It should be eliminated from one of those sections.

Also, this is the only sentence of Section 3. Are there plans to expand 
this section?

Section 5:
The title uses the word "Safety"; the rest of this section uses the word 
"safeness." 
You want to use "safety" throughout: it means what you want to say: the 
condition of being safe.

Normative in 

End of second paragraph of Section 5: "In the absence of the data types 
and built-ins, this [coinciding of logical semantics of BLD and 
operational semantics of PRD] follows from [Vianu97]."
-- Omit the "the" before "data types"
-- Narrow the reference; point to a particular section or theorem of 
[Vianu97]

Section 5.1:
It would be helpful to begin this section would some development of the 
intuition of safety. You do, in the previous paragraph, say that "some 
formulas may be unsafe and cannot be executed under the RIF-PRD 
operational semantics." Giving some examples of this would be helpful and 
would serve to develop the reader's intuition on why safety is important.

The definitions are a bit murky. Examples, both positive and negative, 
would help.

In the first bullet point of the definition, Disjunction should not be 
capitalized.

Section 5.2:

As a consequence of the second bullet point after "In addition: --- that 
is, the bullet point starting "A conformant RIF-Core consumer is .." --- 
if one is a conformant  RIF-BLD consumer, one is not a RIF-Core consumer. 
Is this what you want? It seems somewhat counterintuitive to me.\

Section 6:

As mentioned earlier, The second sentence, expanded to include familiarity 
with BLD, should be moved to the beginning of the document.

Section 6.2:

What do you mean when you say "RIF-BLD allows logic and externally 
specified, fixed-interpretation functions as TERM, whereas  ..."

I would think there must be a typo here: what does it mean to allow logic?

I am assuming this section is incomplete.


Best regards,
Leora

Received on Tuesday, 2 December 2008 15:52:22 UTC