S&AS Review: Sections 1 to 4

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. 


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."

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


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"

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"
respectively
"as in RDF, a language identifier"


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')

typo: annotataion


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.

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.

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').

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

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

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).
The third bullet (counting from the end) could then be deleted
since it is then implied by the second bullet (from the end).

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


Section 3.2

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

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

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

In this table, the datatype axiom interpretation speaks of
"VS", which should be something else, since VS was never
mentioned 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.)


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

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

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

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.
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.
>even an optional triple, 
>the transformation of the construct 
"component" instead of "construct" would be clearer here.
>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.
>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.


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.
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.

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.


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


Herman ter Horst

Received on Wednesday, 26 March 2003 09:11:02 UTC