Review of BLD, frozen draft 7 July 2008

Herewith my review of BLD, editor's draft 7 July 2008.
In summary, there is one issue that needs to be resolved before I can 
give my OK for last call publication, as described in [1]. Apart from 
that the document can be published as far as I'm concerned.

I do have some comments; they are all editorial and/or concerned with 
errors in the text.
I structured my comments into three groups: things that I *strongly 
suggest* to implement before publishing last call, regular comments, and 
minor editorial things.

== Strongly suggested to implement before last call ==

* the "fact" in example 1 is not RIF- BLD presentation syntax; it should 
be rewritten to a rule.  This should be updated so that readers don't 
get the wrong impression.
* normative references to DTB and FLD need to be included in section 
8.1, and whenever referring to these documents , a formal reference 
should be used besides or instead of the now used hyperlink
* informational references to SWC and UCR need to be included in section 
8.2 and whenever referring to these documents formal references need to 
be included
* whenever talking about the data types required for RIF , a direct 
hyperlink should be used and the reference to DTB should be included. 
DTB has an anchor called def-required-datatypes.  By the way, DTB does 
not specify data types required for BLD; only datatypes required for RIF.
* in section 2.3, just below the first bulleted lists it is said that 
symbols belonging to the support of the RIF datatypes are individuals. 
However, all symbols belonging to primitive datatypes are individuals. 
Also here a reference to DTB is in order.
* there are still several mentions of "supported data types".  As 
discussed already in several meetings, it is not clear what it means for 
RIF to support a datatype.  Rather, RIF requires implementations to 
support particular datatypes.  So, whenever talking about supported RIF 
datatypes, you should rather talk about "RIF-required datatypes", and 
include a link to the appropriate anchor in DTB (as mentioned above).
* the issues with the BNF I mentioned in [2]
* there is an error in the translation of profiles of imports in XML 
syntax; the translation assumes that they are Unicode strings, but they 
are terms according to the definition in section 2.4.
* annotations should have no bearing on the RIF semantics, as mentioned 
in section 3.3.  However, annotations are part of the presentation 
syntax, so they should be dealt with in the mapping to semantic 
structures, because when reading the current mapping strictly, Tval is 
not defined for any formula that includes annotations.  I would suggest 
to simply remove them before the mapping.
* in the section on logical entailment there is talk of RIF-BLD queries. 
  However, there is no such thing, so this mention should be removed.
* in condition six in the definition of truth valuation (section 3.4), 
it seems to me that the additional condition to ensure conjunctive 
interpretation of attribute value pairs should only be enforced if k>0, 
because otherwise the valuation would always yield true if k= 0.
* the remark at the end of section 6.2 about BLD rule sets always having 
a unique minimal model should be removed, because it is simply not true. 
  Equality of data values in rule heads can lead to the absence of a 
model and the use of negative guards can easily leads to a case of 
multiple minimal models, e.g.:
p(a)
"a"="b" :-And (p(?x) isNotA(?x) isNotB(?x))
such that A and B have disjoint value spaces, as two minimal (or, 
rather, canonical) models, one in which a is interpreted in the datatype 
A, and one in which it is interpreted in B.

== General comments ==

* it seems to me that the specification in 6.2 (the semantics of BLD is 
a specialization of FLD) is not complete, because it does not capture 
the various conditions on semantic structures (e.g., on equality and 
frames) in BLD.
* concerning the section headings: in the subsections of the sections 2 
and 4 I don't think it is necessary to repeat the term RIF-BLD and in 
the subsections of 2 I don't think it is necessary to repeat 
"presentation syntax".  Then, in the headings of section 6 and its 
subsections you sometimes use "RIF Framework" and sometimes "RIF-FLD"; 
probably just one of the two should be used.
* in the first paragraph of the overview, the reference to "Horn Logic" 
goes nowhere and there is no reference for standard first-order 
semantics.  I would suggest to include informational references for 
both.  Then, references to XML schema datatypes and the RDF and OWL 
compatibility document are missing.
* the bulleted lists in the overview (especially the second bullet) 
reads rather awkward, because of the explanatory paragraph written in 
the middle.  I would suggest to write the bullets, in the order that 
they are treated in the two (i.e., direct specification first), and 
include the explanation of the two below the list.
* in example 1 it is not entirely clear what an "English rule" or 
"English fact" is.  It should probably be a "rule written in English", etc.?
* section 2.1, definition of alphabet, last bullet: this is a 
definition, so it should exhaustively enumerate all the auxiliary 
symbols.  Probably it is sufficient to remove the ", such as"
* sentence just above section 2.3: it's unclear what is meant with 
"inference rules underlying first-order logic".  I don't think it's 
appropriate here to talk about inference rules.
* concerning the definition of well- formedness of terms: I think the 
first two bulleted lists in the section are sufficient.  In addition, it 
is hard to understand the following text about inferring kinds of 
symbols, because formulas have not yet been introduced.  Finally, I 
don't think it is appropriate to talk about well- formedness of terms, 
because the well formedness is rather a condition on a set of formulas 
and the use of symbols in that set of formulas.  But, as I said, I don't 
think this well- formedness condition is necessary at all, because it is 
implied by the partitioning of the set of constants.
* reading the first paragraph of section 2.4, it seems that formulas of 
the form External(External(phi))are atomic formulas.  Is this intended?
* section 2.4, definition of quantified rule: there's no real definition 
of what a free variable (or quantified variable) is.  I think it would 
be good to make that explicit
* last paragraph of section 2.5: rather than including her you were 
right, you should include a formal informational reference to a specific 
section in the OWL reference document
* since section 2.6 is informative, rather than normative, I would 
suggest to include "(Informative)" in the section title
* section 2.6: for ease of understanding, I would suggest to first 
include the BNF for rules and then for conditions.  Not only would this 
make the section easier to follow, but the BNF for conditions depends on 
the BNF for rules.
* in section 3.2 it is often unclear whether DTS denotes a set of 
identifiers or a set of datatypes.  Probably it's best to when first 
introducing the symbol to say that you use the same symbol to denotes 
both the set of identifiers and the datatypes identified by these 
identifiers
* section 3.2, paragraph below "the effect of datatypes", second 
sentence: "a symbol space identifier of a datatype": identifiers in DTS 
are  datatype identifiers by definition
* sentence just above section 3.3: "the lexical spaces that do not 
correspond to" => "symbol spaces that are not"
* section 3.3, last sentence: rules do not do reasoning
* section 3.4, second paragraph: it would be worthwhile to also mention 
built-ins here, not just datatypes
* section 3.5, imported document: the definition of D' should be a 
little more precise, e.g.: "t is the location of the XML representation 
of a BLD document D'".
* section 4: I think it would be easier to understand the XML syntax if 
you first present the mapping from the rules and then the mapping from 
condition formulas.  In addition, the mapping in section 4.3 .1 depends 
on the text in section 4.3 .2
* section 4.3.1: the mapping seems ambiguous for predicates and 
functions with named arguments, because an "argument" meta variable can 
be instantiated with a name/value pair
* section 4.3 .3 is somewhat awkward to read, because it is a 
translation of translation tables.  I would rather suggest to integrate 
this translation into the preceding tables.  The tables will be a little 
more verbose, but part of the verbosity can be mitigated by creating an 
additional row for the translation of ID-meta pairs.
* section 4.3.3, first paragraph: it's unclear what Typetag has to do 
with XML class descriptor names, because the table presents a mapping 
from the presentation syntax.
* section 4.3 .3: the delimiters for the metadata "(* *)" are optional 
in the presentation syntax, which is not taken into account here
* section 5, BLD specific clauses: I would suggest to formulate the 
conditions on conformant BLD producer in the same style as consumer
* section 6.1: the numbers in the list seem to be off; it now reads 1, 
3, 5, 7, 9
* section 9.2: the schema inclusion directive should include by IRI, not 
by filename


==Minor editorial comments ==
* the abstract should probably say once "Basic Logic Dialect" before 
using the abbreviation BLD.
* end of the abstract: "in XML schema" => "using XML schema"?
* ideally, the document should choose "datatype", where it now uses 
"data type"
* overview, paragraph below the bulleted list: "this working group" => 
"the RIF working group"
* in the first sentence of section 2 there is mention of the XML syntax; 
however, this syntax is not defined in this section, but much later
* section 2.2, second bullet: there is an unintended line break
* section 2.2, definition item 4: the "if t and s are based terms" 
should probably be moved to the end of the line, so that it is in line 
with the other items in the list
* section 2.4, definition of well formed formula: the beginning solve 
the second sentences of the definitions of conjunction and disjunction 
have different styles.  I would suggest to use the same style for both.
* sentence above the definition of rule implication: "a RIF-BLD rule" => 
"RIF-BLD rules"
* section 2.4, definition of group: the remark "they can be mixed" and 
the second sentence following the definition are redundant.  I would 
suggest to remove one of the two (probably the first one).
* section 3.2, definition of I_C: constants do not denote individuals or 
function symbols, but *are* individuals or function symbols.
* section 3.2: typo in the definition of I(External(t)): I_externsl
* section 4.3 .3: I would suggest to use a different font (not teletype) 
for the $.  In addition, I would suggest to write the symbol when 
introducing its meaning just above the table.
* section 5, first paragraph: "compliance" => "conformance"



[1] http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0098.html
[2] http://lists.w3.org/Archives/Public/public-rif-wg/2008Jul/0103.html
-- 
                          debruijn@inf.unibz.it

Jos de Bruijn,        http://www.debruijn.net/
----------------------------------------------
One man that has a mind and knows it can
always beat ten men who haven't and don't.
   -- George Bernard Shaw