RE: Review DL-Semantics

Hello Markus,

Thanks a lot for your comments -- I really appreciate them. Below are my answers. Please let me know should you have further comments.

Regards,

 Boris

> Update URL to Bernardo's current homepage

Done. I've also updated Ian's and my Web pages as well.

> General minor comment: when denoting tuples with angular brackets, the proper HTML entities would
> be 〈 and 〉, i.e. &lang; and &rang;, instead of < and >. I think this would improve readbility,
> unless there are known browser compatibility issues for these entities. I am aware that this might
> affect other documents, but it seems to be a simple search and replace.

Thanks -- good suggestion. I've made the replacements in the Semantics and the Syntax documents. (Other documents don't use &lt; and &gt; to denote tuples.)

> A similar remark would apply to V_LT as well. But the restrictions imposed by having certain
> literals/literal-facet-pairs only for certain datatypes are syntactic and do not impair the
> statements in this document, so this is not an actual error.
> 
> Taking this viewpoint, however, I wonder why VLT and VFA need to be explicit parts of the
> vocabulary at all. Those components are never used in this document, and D is directly referred to
> in relevant places. If we consider D as such to be part of V, why "copy" some parts of D into V? I
> can see some didactic motivation for having VDT explicit, to emphasise how it differs from NDT. But
> I note that even the definition of this set seems to be dispensable, since it is only used in one
> place, and since the possibility of occurrences of rdfs:Literal follows from the syntax and may not
> need extra emphasis here. Maybe the reduction of V to a 4-tuple could have didactic merrits, or one
> could use a 5-tuple with D as explicit fifth component.

After fixing Michael's and your comments, there is now a clear distinction between V and N, since the former talks about rdfs:Literal as well. I understand that this distinction is rather technical; however, it might make sense to keep the document as it is right now in order to be clear about it.

> The line for ComplementOf( DR ) uses DR for a sub-data-range, while the table header uses DR to
> refer to the whole expression. One of those should change (like in the table for object property
> expressions). Maybe just use D in the header. See also comment for the table below.

and

> As in the previous section, the table should not use CE both as a name for the whole contents of
> the first table cell in each row, and to denote sub-expressions used within this cell. Maybe just
> use C in the table header.

I didn't realize this; thanks. I'd prefer, though, to always stick to the principles given in Section 2.1 for referring to various parts of the syntax. Tow avoid the problems you mentioned, I've actually removed OPE, DR, and CE from the headers altogether.

> I disagree. All other expressions are "guarded" by further premisses such as &lang; ''x'' , ''y''
> &rang; &isin; ''(OPE)<sup>OP</sup>'' so that they are naturally limited to individual elements (as
> opposed to any other things in the world, such as elements from some datatypes value space).

I agree, so I've left the table as is.

> Of course one can view all functions as sets, and it is clear what NLT ⊆ NLT', NFA ⊆ NFA' mean. But
> it might still be more readable to give a "pointwise" comparison here. Or maybe not, I let you
> judge.

You're right. The previous text was a remnant from the times when N_FA and N_LT were not functions.

> Seeing your wiki-text, I also created a simple template {{prime}} that can be used in place of
> <nowiki>'</nowiki>; (just a hint, not a reviewing comment really).

Thanks.

> Section 2.2 states that, for an Interpreation for a datatype map D: "⋅ DT, ⋅ LT, and ⋅ FA are the
> same as in D […]" To meet this requirement, Int' should use ⋅ DT' , ⋅ LT' , ⋅ FA' to be an
> interpretation for D'. Similarly, ⋅ DP cannot be the same in both cases, due to the presence of
> owl:TopDataProperty.

I've fixed several aspects of the proof of this theorem. Please let me know should you have further comments.

Received on Monday, 8 September 2008 09:53:35 UTC