- From: Leora Morgenstern <leora@us.ibm.com>
- Date: Tue, 2 Dec 2008 10:51:33 -0500
- To: public-rif-wg@w3.org
- Message-ID: <OF09755967.39096276-ON85257513.0056A91F-85257513.00571DEF@us.ibm.com>
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