# FLD review

From: Jos de Bruijn <debruijn@inf.unibz.it>
Date: Sun, 20 Jul 2008 11:08:00 +0200
Message-ID: <48830070.7040409@inf.unibz.it>
To: RIF <public-rif-wg@w3.org>
```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

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[])).

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

```
Received on Sunday, 20 July 2008 09:08:53 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:33:52 GMT