AS & S review: mapping to RDF graphs

In my view, the process of transformation from abstract syntax 
to RDF graphs is not yet sufficiently explained in the text 
preceding the table.  It becomes more clear when the table is
inspected, but I believe that the text before the table should
make several things more explicit.  I hope that my next comments 
on individual sentences in the current text can help to develop a 
more systematic and complete and explicit description of how the 
translation to triples is specified using
1) an ontology in abstract syntax form
2) the transformation table 
3) the abstract syntax
--
  "The left column of the table gives a piece of syntax (S), the
  center column gives its transformation (T(S)), and the right column 
  gives a node identifier that is the main node of the transformation 
  (M(T(S))), but only for syntactic constructs that can occur as 
  pieces of directives. "
It becomes clear only much later what the main node is introduced for: 
  "When the transformation of a component is used in a node position 
  of an triple, the transformation of the construct is part of the 
  production (but only once per production) and the main node of 
  that transformation should be used for that node of the triple."
It should be added here that the "transformation of the construct"
produces as a kind of side effect other triples in addition to those
of the transformation currently expanded.
Instead of "node position", you can even say "object position" here
because this never happens on a subject position.
  "For many directives these transformation rules call for the 
  transformation of components of the directive using other 
  transformation rules."
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(value1) expands to either T(individualId), T(individual) or 
T(dataLiteral), each of which can be handled using the transformation 
table.

The transformation table uses a special font for "tokens"
like "Annotation", "Imports".  However, this is done only
very incompletely.  This font should be used more often:
- the words "type" and "value" in the two productions
for Individual,
- "allValuesFrom", "someValuesFrom"
- "value" in value restrictions
- (min, max-)cardinality
- in datatypeproperty and objectproperty: super, domain, 
range (several times)
- annotation (twice)

In the three toplevel transformations for class axioms, the right
bracket should be replaced/repaired.

DifferentIndividuals, second transformation: instead of iIDi...iIDj
it should be iID1...iIDn.

RDF Model Theory should become RDF Semantics (twice).

In the sentence with the word RDF Model Theory, replace 
"turn this syntax into..." by 
", to turn this syntax into...".

In the sentence with the word "ellipses" a semicolon should be 
deleted.

typo: namspaces