Re: S&AS Review: Sections 1 to 4

From: herman.ter.horst@philips.com
Subject: S&AS Review: Sections 1 to 4
Date: Wed, 26 Mar 2003 15:08:56 +0100

> OWL - Semantics and Abstract Syntax
> Version of 20 March 2003
> 
> 
> Section 2 abstract syntax
> 
> Suggestion to end next sentence with colon instead of dot,
> otherwise there is a little confusion about the list that follows
> this sentence:
> >The other built-in XML Schema datatypes are problematic for OWL, and 
> >should not be used. 

Changed.

> Section 2.1 Ontologies
> 
> Suggestion to change next sentence
> >Names of ontologies are used in the abstract syntax to carry the meaning 
> >associated with publishing an ontology on the Web.
> as
> "... associated with an ontology published on the Web."

Not changed.   Names do not carry the meaning of an ontology, instead they
carry the meaning of publishing an ontology.

> In the new version one has to read rather much text before one
> is able to use the directive production for annotations, since
> only near the end of this section possibilities are defined for
> annotation / ontology properties.  I believe that clarity would be
> much improved by including these possibilities
> in the two productions as follows, and to move these two productions
> immediately next to the first two productions (for ontology 
> and directive):
> 
> annotationPropertyId ::= owl:versionInfo | ... | URIreference
> ontologyPropertyId ::= owl:Imports | ... | owl:incompatibleWith

I believe that this change in its entirety would not improve the
readability of the subsection.  However, making the list of
annotationPropertyIDs explicit would be useful, and has been done.

> Section 2.2 Facts
> 
> For the production 
>    type ::= classID | restriction
> there would seem to be two possibilities to go further
> with 'restriction', where, of course, only one is legal.
> I believe that it would help the people reading this from paper
> to follow the line containing the word 'restriction' of this
> production with the imperative addition:
> "see Section 2.3.1.2"

Done.

> The productions for lexicalForm and languageTag just say
> "as in RDF". 
> This has a strong disadvantage, namely that the reachability
> of the mapping rule for oneOf(v1,...,vn) (in Section 4)
> cannot be checked from this document alone.
> I believe that it would be helpful if the description
> of the abstract syntax is made somewhat more self-contained here, 
> by replacing
> "as in RDF" by the only slightly longer:
> "as in RDF, a unicode string in normal code C"

Done.

> respectively
> "as in RDF, a language identifier"

Done, except used ``an XML language tag'' for compatability with XML.
(I've commented to the RDF Core WG that they are using the wrong wording.)

> Section 2.3.1.3
> 
> >These properties can also be given domains and ranges. 
> Request: make this sentence more explicit,
> as it is not clear what 'these' refers to. (The preceding
> sentence speaks of two different kinds of properties, and
> the sentence before that has another 'these properties')

Changed to 
	Data-valued and individual-valued properties

> typo: annotataion

Fixed.

> Section 3.1
> 
> General remark: the 
> 
> Several comments on the new treatment of datatypes:
> 
> In view of the definition of the function ER in four parts,
> I believe that not only VDP, VIP, VAP should be assumed to be
> pairwise disjoint, but VDP, VIP, VAP and VOP should be assumed
> to be pairwise disjoint.

Agreed.  This required a bit of reordering at the start of the section to
define VOP early enough.

> In the definition of datatype theory, the definition of L2V
> needs to be made more specific, because of its use later:
> I suggest the following text"
> "..., L2V maps each d in D to a map from L(d) to V(d)."
> Without this addition, it is not sufficiently clear that the 
> later occurrence of L2VT(NT(d))(l) is well-defined.

OK, change made.

> Moreover, I think it would be best to keep the letter d 
> for elements of D, as in the RDF Semantics document,
> and to replace later on the same page
> the uri's referring to elements of D by d', as in NT(d').

Done.

> Next sentence: for clarity introduce two times "the set of":
> "the set of Unicode strings" and "the set of pairs ...".

Done.

> Since there is no disjointness condition on VI in relation to
> other vocabulary sets, I think that the two lines defining
> the function S need to be merged:
> s: VI union VC union ... -> R

OK.

> The last sentences of this section extend S to literals,
> in terms of L.
> Therefore, I think that in the last two bullets in the list
> in this section S needs to be replaced by L, in the
> expressions S("l"^^d).

Right.

> The third bullet (counting from the end) could then be deleted
> since it is then implied by the second bullet (from the end).

This is not implied.  The third-last condition requires that all typed
literals (even ones like "1.5"^^xsd:integer) map into the value space (here
integers). 

> >Note that ... causes an inconsistency.
> Consistency is formally defined later, differently, 
> and I believe that here another word should be chosen.
> ('Note that' suggests that the reader could draw the
> conclusion.)

Changed to

Note that there are no interpretations that can satisfy all the
requirements placed on ...

> Section 3.2
> 
> Suggestion to add to header of table
>  "value of" 
> for clarity:
> Interpretation (value of EC)

done

> restriction(p value(i)) resp. v:
> add: "i an individual" resp. "v a literal"

Done, except individual ID instead of individual.

> The name axiom interpretation table should be improved,
> since also facts are interpreted there.

Done, twice.

> In this table, the datatype axiom interpretation speaks of
> "VS", which should be something else, since VS was never
> mentioned before.

Changed to LV<sub>T</sub>, which should have been done before.

> (Observation: the abstract semantics tables look
> more complicated than before because of the annotations.
> Note that annotations seem to be semantically correspond
> to values: for each annotation fragment in the EC extension
> table there is a completely similar value fragment,
> with a completely similar semantics, and vice versa.)

Agreed.  Annotations make the semantics much more ugly.  Are you proposing
to remove them?  (I hope :-)

> Section 3.4
> 
> "An collection ..." should be "A collection ..."
> 
> Section 4
> 
> Many occurrences of "RDF Model Theory" instead of "RDF Semantics",
> also elsewhere in the document

Fixed.

> The sentence with the word "ellipses" has an incorrect semicolon
> before the ellipses.

Fixed.

> A very small error in the mapping table:
> The first line in T(annotation...) should not end with a dot.

Actually it should.  The periods need to be removed from where this
translation is used. Done.

> It seems that the following cited sentence needs clarification
> and correction.
> Main point (also expressed in an earlier review):
> I believe that the text explaining the mapping table
> does not yet make sufficiently clear that in the mapping 
> process triples can be produced as a kind of side effect, and 
> that in that case the main nodes and not the T(syntax fragment)'s
> are used for substitution.

I am uncertain what extra to add here.

> Further remarks about the sentence inline:
> >When the transformation of a component is used as the 
> >subject or object of a triple, 
> Not only subject or object, also predicate.
> See the productions for individual : T(pID1) etc.

Changed.

> >even an optional triple, 
> >the transformation of the construct 
> "component" instead of "construct" would be clearer here.

Changed.

> >is part of the production 
> >(but only once per production)
> This addition might be deleted: if a triple is generated
> twice, it enters only once, since an RDF graph is a 
> set of triples.

The parenthetical remark is needed, otherwise extra blank nodes could be
generated, for example.

> >and the main node of that transformation should be used for 
> >that node of the triple. 
> Here "node" would need replacement, in view of the possibility
> of predicates I mentioned earlier.

Hmm. 

Changed to

	For many directives these transformation rules call for the
	transformation of components of the directive using other
	transformation rules.  When the transformation of a component is
	used as the subject, predicate, object of a triple, even an
	optional triple, the transformation of the component is part of the
	production (but only once per production) and the main node of that
	transformation should be used in the triple.


> >From my earlier review I copy the following request
> for further clarification in the text before the mapping table:
> 
> It is not made clear that not only one needs other transformation
> rules (from the same table), but one also needs to go back to the
> abstract syntax in Section 2 to do other transformations before one
> can exploit other transformations from the same table.

I don't understand the problem here.  I don't think that Section 2 defines
any transformations at all.

> It would be helpful to give a brief example with the first production 
> where these subtilities play a role, which is the first production for
> Individual:
> Here the abstract syntax shows that T(type1) expands to 
> T(description) which in turn expands, again by means of the abstract
> syntax, to T(one of six possibilities), each
> of which can be handled using the transformation table.
> T(v1) expands to either T(individualId), T(individual) or 
> T(dataLiteral), each of which can be handled using the transformation 
> table.

I believe that this does not need any further explanation.

> Suggestion to replace what is just before the mapping table:
> >; this node is referred to as O below
> by:
> "; in both cases, this main node is referred to as O below"
> Otherwise, the second mapping rule is incomprehensible.

Done.

> (By the way,
> I note that the printing/viewing problem that the document
> had with Internet Explorer 6.0 still exists.)

If you have some method for translating from HTML to PDF (or whatever) I
can run the document through it and make a version that can be viewed using
other techniques.  I'm not particularly interested in fixing problems with
IE 6.0.  (I note that Mozilla doesn't do a great job of rendering the
document in some places, particularly when rendering in print form.)

> Herman ter Horst

I have just made a new version of the document (26 March) with these
changes.

peter

Received on Wednesday, 26 March 2003 13:37:50 UTC