Re: S&AS Review: Sections 1 to 4

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

It seems that you copied the wrong list into the production.

And - with only the list that you intended to copy into the
production - the reader has to read all of Section 2.1 to find
out how work with imports.  When you also copy the second list
into the production (that is, the list that you copied now
into the wrong place), looking at the productions suffices.
An alternative would be to move the sentences containing these
lists upward to just behind the productions.

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

In that case, the extent of the error is wider than I thought.
I tried to check all the period removals, and believe you missed
one: the Datatype rule has currently one period too many.
Moreover, the next two mapping rules on annotations should
also add a period, to become consistent with the first annotation
rule (with the period).

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

OK

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

Let me try to explain this again.
The table in Section 4 has as first columns S and T(S).
Look again at the first rule for Individual, for example: it contains
T(type1) and T(v1) etc.
If a reader starts looking in this table for 'type' in the
first column, to find T(type1) in the second column, he will
never find it.  Namely, he first has to use the abstract syntax
before the table in Section 4 can be used further.
See, more extensively, below:

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

[...]


>
>> Herman ter Horst
>
>I have just made a new version of the document (26 March) with these
>changes.
>
>peter
>

Herman

Received on Thursday, 27 March 2003 09:50:54 UTC