RE: [BLD] Review (completing ACTION-776)

Christian,
 
Thanks for your comments. I implemented most of them.
 
In particular, based on yesterday's telecon, I rephrased the preamble of
http://www.w3.org/2005/rules/wiki/BLD#Direct_Specification_of_RIF-BLD_Presentation_Syntax 
so it acts as a paragraph describing the status of the presentation syntax
(Chris' ACTION-810).
 
The comments below are still to be addressed, e.g. by Michael,
require further edits, or require no edits, as indicated.
 
Harold
 
 
- Section 2.2, 2nd par.: the definition of base term does not seem to exclude atoms (plain or external); 
--> Michael
 
- 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.
--> Michael
 
- some definition are more general than required, which might be confusing.
--> The occasional extra generality is already explained w.r.t. FLD instantiation.
 
- 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). 
--> Michael
 
- 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.
--> Michael
 
- Section 2.6.1, par. 3: here the confusion between the presentation syntax (normative) and the notation (not normative) is complete
--> Indeed, "The RIF-BLD presentation syntax ... permits arbitrary Unicode strings in constant symbols, argument names, and variables" appears too unspecific. I had proposed a restriction for legal argument names in a recent telecon.
 
- Example 5: the iri assigned to the annotated group is http://sample.org <http://sample.org/> ; shouldn't the following frame's object identifier be the same iri? What is _pd refering to?
--> These can be different to allow cross-annotation references. The local name _pd can be referred to from other annotations in the same document.
 
- Section 3.2, 1st par.: replace RIF framework by RIF framework for logic dialects (here and everywhere it occurs);
--> Michael
 
- section 3.2, definition of mapping I: shouldn't I(List(t1...tn|t)) be = Itail(I(t1)...I(tn), IList(t))?
--> Michael
 
- section 4, definition of valid BLD XML document and preceding discussion: that notion (validity, as opposed to conformance) is not used anywhere else.
--> Right below, "valid" is used to define "Conformant BLD document".
 
- section 4, definition of conformance in XML form: that definition, if at all useful, should be related to the definition of conformance, section 5; 
--> "Conformant BLD document" is quite different from "conformant BLDΤ,Ε consumer/producer".
Since we would be free to change "Conformant" in "Conformant BLD document", we could find a new word for it,
perhaps something like "Strictly Valid".

- Mapping of the condition language: 
  * the args element should be optional in Atom and Expr; isn't the if role element optional as well, in an Implies? 
--> Since args can be empty, it should not be optional, to avoid having two ways of specifying zero arguments in positional Atom and Expr.
Since unconditional formulas are treated separately, the if role isn't optional in Implies.
 
 
________________________________

From: public-rif-wg-request@w3.org [mailto:public-rif-wg-request@w3.org] On Behalf Of Christian De Sainte Marie
Sent: May 12, 2009 6:03 AM
To: RIF
Subject: [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 <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 <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 <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 <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 <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