Re: FLD review

Jos, thanks for the comments.
Almost all the comments have been addressed modulo some of the following.

    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.

Agreed - done.

    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.

    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.

    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.

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?

   Section 2.3
   - the abbreviations mentioned here should already be mentioned in the 
     introduction, because they are used throughout the documents

This would disrupt the flow of the text. Instead, the few uses of compact IRIs
that precede their definition were simply expanded to eliminate the issue.

    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

There are now some explanations about it. Basically, this makes it easier
for Harold to maintain the schema in a more modular way.

    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.

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
>

Received on Sunday, 20 July 2008 22:57:00 UTC