[BLD] Review (completing ACTION-776)

********* NOTICE **********
My new email address at IBM is: csma@fr.ibm.com
My ILOG email address will not be forwarded after June 8
*****************************

All (and, esp., Core editors),

I reviewed the BLD spec [1] and I found, guess what, that it was not that 
different from the previous version I had read :-)

The short story is: no objection to the publication of BLD as LC draft, 
after a couple edits.

Here below, are my detailled comments, mostly editorial details, some 
suspected typos/errors, and a few (maybe) more substantial comments.

I also corrected a couple obvious typos directly in the document.

This completes ACTION-776.

NB: I did *not* review the XML schema yet.

-------
Section 1. Overview

- 2nd paragraph, line 5, "RIF-BLD is the first of a series...": shouldn' 
that be "RIF-BLD is one of a first series..."?

- Btw, there is no reference to RIF-Core, in the overview, though BLD is 
positionned wrt all the other RIF specs;

- 4th par., line 3, "SPARQL can be partilaly mapped to Datalog (and thus 
to RIF-BLD)": should be "...(and thus to RIF-Core)", after Core is added 
to the picture;

- Last paragraph, "For the interchange ... an RIF-BLD equivalent XML 
syntax is given in this specification": should mention that the XML syntax 
is normative, while the PS in the example is not (and, so, they are not 
"equivalent", strictly speaking).

Section 2. Direct specification...

- 1st par., line 3, "The presentation syntax is normative, but it is not 
intented to be a concrete syntax for RIF-BLD": this sentence is really 
confusing. If it is not a concrete syntax, it should be called an abstract 
syntax, not a presentation syntax. It should say something like: "We 
define both an abstract and an XML syntax.The abstract syntax and the XML 
synatx are normative. To make definitions and explanations easier to read 
and understand we define a lightweight notation that blablabla. That 
notation, or presentation syntax, is not normative."

In the same way, in the next sentence, "It is defined in "mathematical 
english", a special form of english..."; I assume that the "it" that is 
defined in mathematical english is the abstract syntax,  but the 
uninformed reader may well understand that it is the notation, esp. with 
the subsequent remark about leaving details out.

All in all, again, I find the use of the term "presentation syntax" very 
confusing, esp. since the abstract syntax and the notation are often 
confused in the definitions, in section 2 (e.g. "phi :- psy is a formula, 
called rule implication", "an expression of the form 
'Document(directive...)' is a RIF-BLD document formula", etc), or even in 
the title of sections (e.g. section 2.4: RIF-BLD annotations in the 
presentation syntax). This may blur the difference between what is 
normative and what is not (which is not good for adoption).

- Section 2.2, 2nd par.: the definition of base term does not seem to 
exclude atoms (plain or external);

- Example 2 (Terms): the first two examples do not fit in the page width 
(Times roman 12 on A4 paper)

- Section 2.3, par. 2: the definition of an externally defined atomic 
formula does not seems to exclude externally defined frames, equality, 
membership or subclass atomic formulas. As far as I can see, the 
well-formedness conditions (section 2.5) do not exclude them either; 
neither do  the definitions of semantics structures (section 3.2, item 11) 
or truth valuation (section 3.4, item 7). We have a resolution (from 
F2F12) that "The only Externals in BLD (and Core, and PRD) will be 
Predicates and Functions. No external frames, no external equality, etc.". 
The EBNF allows only predicates and functions to be Externals, btw. The 
spec of BLD as a specialisation of FLD does have the restriction as well 
(section 6.3, item 3, 2nd bullet, 4th sub-bullet)

- some definition are more general than required, which might be 
confusing. For instance, the definition of a free variable in an 
"universal rule" (item 4 in the definition of formula, section 2.3) may 
lead one to wonder why it mentions universally or existentially quantified 
formulas, since the only quantified formulas that an universally 
quantified formula can contain, in BLD, are existential.

- Remove Editor's note at the end of section 2.3. That question has been 
resolved;

- Section 2.4 (annotation): it could (should?) be made more explicit that 
the identifier is assigned to the term or formula to which the annotation 
is attached, whereas the slots of the frames are about the object 
identified by their object Id, which can be different from the Id assigned 
to the term/formula that bears the annotation. Same in section 2.6.3 (EBNF 
for annotations).

- I do not understand the Editor's note at the end of section 2.4. But the 
question it raises must be resolved and the note removed.

- Definition of Imported Document, in section 2.5: the locator, loc, is 
not a rif:iri constant, but anyURI (as resolved during F2F13, day 2 [2]

- section 2.6, 1st par. The first two sentences reinforce the 
understanding that the notation that is used from the beginning is the 
(presentation) syntax of BLD. I am pretty sure that, in that context, the 
last bullet in the subsequent list of items will be bewilderingly 
confusing to the reader. Or, maybe, I am the only one who is stupid enough 
to think this is confusing :-)

- Section 2.6: in the EBNF, IRI is not defined. Is that on purpose?

- Section 2.6.1, par. 3: here the confusion between the presentation 
syntax (normative) and the notation (not normative) is complete. Same in 
the first paragraph of section 2.6.2. It would be so much easier to call 
the abstract syntax abstract, and to have the presentation syntax be the 
non-normative notation...

- Same section, next par, "A frame term is a term composed of an object 
Id...": shouldn't that be "...an object identifier..."? Same in the 
paragraph introducing example 3.

- Example 5: the iri assigned to the annotated group is http://sample.org; 
shouldn't the following frame's object identifier be the same iri? What is 
_pd refering to?

- Section 3, 2nd par.: "Recall that the presentation syntax of RIF-BLD 
allows shorthand notation..."; you mean the non-normative notation 
introduced along with the normative presentation syntax, I assume? :-)

(To avoid repreating myself, I will not comment further on the many other 
places in the document where there is a confusion between the normative 
abstract syntax and the non-normative presentation syntax)

- Section 3.2, 1st par.: replace RIF framework by RIF framework for logic 
dialects (here and everywhere it occurs);

- section 3.2, definition of mapping I: shouldn't I(List(t1...tn|t)) be = 
Itail(I(t1)...I(tn), IList(t))? Btw, I do not understand why the comments 
about malformed lists, in section 2.2 (item 4 in the definition of Term) 
and in section 3.2 (item 5 in the definition of semantics structures), 
since it does not seem to make any difference, syntactically nor 
semantically, whether a list is well- or malformed...

- section 4, definition of valid BLD XML document and preceding 
discussion: that notion (validity, as opposed to conformance) is not used 
anywhere else. Shouldn't it be removed?

- section 4, definition of conformance in XML form: that definition, if at 
all useful, should be related to the definition of conformance, section 5; 
maybe even moved there?

- next par., "The XML serialization ... is fully stripped": that is not 
exactly true, since the alternation of class and role tags is not strictly 
enforced everywhere. Maybe that sentence can be weakened, or, even, 
removed?

- section 4, XML condition language, list of elements, items args and 
slot, "...with fixed 'ordered' attribute...":replace "...with 'ordered 
attribue = 'yes'...'; The last sentence in the 3rd par. after the list 
need be corrected in the same way.

- Attributes: qualified or not? In PRD, the ordered attribute always 
occurs qualified, the type attribute does not; in BLD nether occurs 
qualified; and in neither document are the elements names explicitely 
qualified, either. Question: should the attributes be qualified in RIF 
XML, or not (I assume that elements tags are qualified)?

- same list, item Const: is the "type" attribute really optional? For what 
purpose? It is not marked optional in the mapping. If we decide to 
keep/make it optional, PRD should probably be ailgned

- same section, 3rd par. after list: there is a linebreak in the middle of 
the dateTime constant example

- Mapping of the condition language:
  * shouldn't the formula elements be optional, in the And and Or? Ok, it 
is arguable since they are indexed 1...n; but, then, shouldn't there be 
some kind of reminder whether or not n can be 0?
  * the args element should be optional in Atom and Expr; isn't the if 
role element optional as well, in an Implies?

- Mapping of the rule language: the group (and payload element) is 
optional

That's all, folk!

Christian

[1] Specifically, I reviewed that version: 
http://www.w3.org/2005/rules/wiki/index.php?title=BLD&oldid=8547, except 
for the section 4, that I reviewed in today's version: 
http://www.w3.org/2005/rules/wiki/index.php?title=BLD&oldid=9206
[2] http://www.w3.org/2005/rules/wg/meeting/2009-04-16#resolution_7 and 
http://www.w3.org/2005/rules/wg/meeting/2009-04-16#resolution_8

ILOG, an IBM Company
9 rue de Verdun
94253 - Gentilly cedex - FRANCE
Tel. +33 1 49 08 35 00
Fax +33 1 49 08 35 10


Sauf indication contraire ci-dessus:/ Unless stated otherwise above:
Compagnie IBM France
Siège Social : Tour Descartes, 2, avenue Gambetta, La Défense 5, 92400 
Courbevoie
RCS Nanterre 552 118 465
Forme Sociale : S.A.S.
Capital Social : 609.751.783,30 ?
SIREN/SIRET : 552 118 465 02430