Re: FLD review

>     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?
> 
> These are all good points, which should be discussed after the 2nd draft is
> published.

Agreed.

> 
>     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[])).
> 
> The semantics was defined the way it was defined in order to allow dialects
> to reify the equality statements, frames with multiple attribute-value
> pairs, etc. This includes running variables over such statements, etc. If
> we adopt your suggestions then it is unclear how this goal can be achieved.

I did not think about this point.  I'm fine with keeping the definition 
the way it is.

> 
>     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.
> 
> We did not find the uses of compact IRIs  that do not use teletype except
> for the cases when they are links. Teletype font looks strange in links,
> but this might be subjective.

I personally do not find the font strange in links, but this is against 
objective :-)

In any case, there are several cases where they are not links and they 
are not teletype.  Just search the page for "rif:iri" and you will find 
several occurrences (e.g., last paragraph section 2.3, first paragraph 
section 2.9).

> 
> As to the parentheses, the convention is to use teletype when the
> parentheses are part of a formula, and use regular font otherwise.
> Can you point to specific places where these are wrong?

last bullet of the definition in section 2.2.
Then in section 2.9, second last paragraph, there is '?'  That should be 
in teletype.  The last paragraph in section 2.9 should have '(*...*)' 
and teletype.
These are the occurrences I caught.

>     Section 7.2
>     - the schema should refer to the baseline schema by URI, and not local 
>       filename
> 
> This also has to do with the way the schema is maintained. But it is
> acceptable to use a relative URL, since both XML schemas are online 
> at the same site.

It's not really obvious from the text with the location is.
Perhaps it would be good to use an xml:base directive.

I also think the location of the schema should be written in the text. 
Finally, I think schema should be placed on the W3C server.

Best, Jos

> 
> Harold & Michael
> 
> 
> 
> On Sun, 20 Jul 2008 11:08:00 +0200
> Jos de Bruijn <debruijn@inf.unibz.it> wrote:
> 
>> 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
>>

-- 
Jos de Bruijn            debruijn@inf.unibz.it
+390471016224         http://www.debruijn.net/
----------------------------------------------
No one who cannot rejoice in the discovery of
his own mistakes deserves to be called a
scholar.
   - Donald Foster

Received on Monday, 21 July 2008 08:48:35 UTC