FLD review

Here with my review of FLD.  In summary, I think it can be published as 
second public working draft.
I also think we are not very far from last call.

Below are my further comments. As far as I'm concerned, they can be 
implemented after publishing the second public working draft.

I have one substantive comment, a few points for discussion, a 
suggestion for simplification (which is editorial), and a few editorial 
comments.

The substantive comment is concerned with the name of the dialects, in 
the Dialect() construct.  It is now required to be an alphanumeric 
string.  I think this is too restrictive.  I think it should at least be 
possible to write IRIs there.  I personally don't think we need to allow 
anything else, but would be fine with this being a Unicode string or a 
constant.


The discussion points are the following:
- the logical connectives in the language do not include material 
implication and equivalence.I do not really understand the rationale for 
including certain connectives and not including others.
- it seems to me that the classical negation is not sufficiently general 
to capture the notion of strong negation in logic programs.  Do we want 
to capture this notion with FLD?


A suggestion for simplification is concerned with the definition of 
semantic structures.  I think it can be simplified in two places:
- I= can be removed: the condition on the interpretation of equality 
atoms in section 3.6 is necessary and sufficient, which means that I= is 
determined by this condition and is thus redundant. the truth valuation 
of equality atoms can be written as follows:
TValI(x = y) = t if I(x) = I(y) and TValI(x = y) = f otherwise.
- Iframe need only be defined for the cases of 0 and 1 property-value 
pairs; the condition on the interpretation of frames with multiple 
attribute-value pairs makes the definition of Iframe on frames with 
multiple attribute-value pairs redundant.the truth valuation of frames 
can then be defined as follows:
TValI(o[a1->v1 ... ak->vk]) = glbt(Itruth(I(o[a1->v1])), ..., 
Itruth(I(ak->vk])))  if k >0.
TValI(o[]) = Itruth(I(o[])).


Further editorial comments:

General:
- when writing compact URIs, parentheses, and variables in the text you 
sometimes  teletype font and sometimes not.  I would suggest always 
using teletype font.

Overview:
- third paragraph, second last sentence: "and also directly" => "and 
directly" (repetition both, also)
- third paragraph, last sentence: I don't think the reference to RIF-BLD 
needs to be repeated here, as it was already mentioned in the previous 
sentence
- the overview of the syntactic framework should mention formulas
- syntactic framework, bullet symbol spaces, first sentence: "used as 
variables, individual" => "used as individual" (variables do not have 
symbol spaces)
- paragraph semantic framework, first sentence: I would suggest to 
always use "semantic structure" and not just "mostly"
- semantic framework, bullet entailment: "Description Logic" => 
"Description Logics" (it is a family of languages)
- paragraph before XML serialization framework problem it seems that 
this belongs to the bullets on entailment, and should thus be indented. 
  Then, not all Description Logics are based on first-order logic, some 
have nonmonotonic extensions(perhaps say "many").  Also, not all logic 
programming languages use default negation (perhaps say "most").

Section 2.1
- bullet 1 says the alphabet can be restricted.  It would be good to 
have some idea as to how it can be restricted.
- Bullet 3 there are several types of external terms; it would be 
worthwhile to mention these here

Section 2.2
- paragraph following the bulleted lists, second sentence: "preceded 
with" => "preceded by"
- last paragraph: Group should be mentioned before Document, because a 
document contains groups

Section 2.3
- the abbreviations mentioned here should already be mentioned in the 
introduction, because they are used throughout the documents
- it is not entirely clear what a "legal symbol" is.  Did you intend to 
define the notion here?  Otherwise, maybe you should call it 
"syntactically valid"
- 2nd last paragraph, first sentence: it is not clear what it means for 
a dialect to include the symbol space.  Did you mean to say that all 
symbols in the symbol spaces are part of the syntax of the dialect?
- last paragraph is redundant with the first sentence of the previous 
paragraph

Section 2.4
- bullet 7, third paragraph: "only predicates can be used" => "only 
predicates and functions can be used"
- 2nd last paragraph, first sentence: "base terms" => "terms" (base 
terms are not defined anywhere)
- last paragraph, when talking about signatures: a forward reference to 
the section about signatures is in order here

Section 2.5
- definition of external schema: better to list here the permitted kinds 
of terms rather thanlisting the exclusions.  For example, you did not 
capture equality terms here.
- paragraph following the bullets: "the same schema" => 
"indistinguishable" (they are not the same)
- definition of coherent set of external schemas: "if there can be no 
term, t, that is an instance of two distinct schemas" => "if there is no 
term, t, that is an instance of two distinct schemas in the set"
- last paragraph: "it important" => "it is important"

Section 2.6
- definition of signature name, first sentence: "finite or countably 
infinite" => "countable" (is shorter)

Section 2.7
- first sentence: "is a set of all" => "is a set of"

Section 2.8
- definition of well formed term, bullet 2, second sub-bullet:  there is 
a ',' too many here
- definition of well formed formula, bullet 8: "or group formulas" is 
redundant here, since group formulas are non-document formulas
- same definition,  bullet  9, 2nd sub-bullet, third sub-sub-bullet: 
"are used as shorthands" => "define shorthands"

Section 2.10
- 1st sentence: "mathematical English" is used here for the first time, 
and I expect that most readers will not understand what it means

Section 3.1
- I did not really understand bullet 1.  It is not really said here what 
the dialects must specify.
- bullet 3: it is not clear what it means for a dialect to support a 
datatype.  I suppose you meant to say "requires implementations to support"

Section 3.8
- second paragraph: "RIF-BLD sets" => "RIF-BLD set of formulas"
- third paragraph: "not" => "Neg"

Section 7
- it should be explained what is meant with a baseline module and a 
skyline module and what the rationale is for splitting the schema into 
these two modules

Section 7.2
- the schema should refer to the baseline schema by URI, and not local 
filename

-- 
                          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