Re: Review of RDF mapping

Here is a summary of the changes made.

peter

> 
> Hi,
> 
> below is the outcome of my review of the RDF mapping. In general, this
> is a well-written, clear document, and I didn't see any serious
> technical problems. 

Thanks.  :-) 

> In fact, most of my comments are trivial or
> cosmetic.

> - "datatype" is a single word in Syntax, so perhaps it should be here as
> well

Fixed in the one place "data type" shows up.

> - Section 2.1, in the first paragraph, it says that the mapping T
> produces RDF(O): this seems to be confusing. Can't we say that T
> produces T(O)? Should it be mentioned explicitly that T is defined
> recursively? And should there be an explanation of "Main Node of T(S)"
> (where is it used/what is it good for?) -- especially since T(S) might
> *not* produce any triple, but only a single node ?

Augmented the discussion and changed RDF(O) to T(O).  In some sense,
RDF(O) is better, but T(O) is historical and shorter.   There is now a
short discussion of recursive invocation and the role of the main node
of T.

> - in Table 1,
> --- there are 2 lines for translating "Ontology (..)" statements: could
> we have a little comment in each line like "For ontologies with a
> URI"/"For ontologies without a URI"?

There are quite a few places where different constructs with the same
"keyword" are translated differently, including Declaration and
cardinality restrictions.   I don't see this as any different.

> - in Section 2.2, can we rephrase "let ax' be the axiom that is
> equivalent to ax but that contains no annotations" with "let ax' be the
> axiom that is obtained from ax by removing all annotations' (or be more
> precise re. 'equivalent')?

Done.

> - in Section 3,
> 
> --- could we make it more clear when "any matched triple is removed"?
> E.g., can have a special indicator in the tables to show which are
> "destructive"? Or at least indicate it always in the title or before a
> the table?

Each removal is now before the table(s), in a separate paragraph (almost
always), and using similar wording.  I also regularized other wordings
related to removal and correctness.

> --- I found "The rules from the following sections are not allowed to
> redefine the value of any of these functions for some x." for 2 reasons:
> (1) they *are* redefined because they change these functions from "=
> epsilon" to something else, and (2) shouldn't it be "for any x." at the
> end?

Changed to:
* The rules from the following sections are not allowed to *redefine*
(i.e., change after the initial definition) the value of any of these
functions for any ''x''.

> --- can we add "{...}" after "Possible conditions on the pattern are
> enclosed in curly braces" (it would help to find this sentence!) and
> replace "Possible" with "Additional"? And the same for square brackets
> and [...]

Done.

> --- Table 2 is repeated from Table 1 -- can this be made clear so that
> the reader doesn't have to check how they differ?

The intent of the two tables is different, as they go in different
directions.  

> - the beginning of Section 3.1 seems contradictory: if G contains no
> "whose predicate is rdf:type and object is owl:Ontology, then the
> ontology header is Ontology( ... )." seems to indicate that the absence
> of such a triple is fine, whereas "if no such pattern can be matched in
> G, or ..., the graph G is rejected as invalid." indicates that this
> absence leads to rejection?!

Note the "otherwise" in the paragraph!

> - "tiple" in Table 3

Changed to "grog".  :-)

> - in Table 5, doesn't the second case need a condition {and *:x rdf:type
> owl:ObjectProperty is not in G}? And similar for the others?

Added a comment before the table to indicate that this particular
matching process stops when no changes are made to G.

> - can the columns of Table 8 be swapped to fit in with the other tables?

Done.

[...]

> - Section 3.5
> --- contains a "patters"

What, you don't like Gilbert and Sullivan.  :-)

peter

Received on Tuesday, 9 September 2008 12:51:15 UTC