Review of the the DM pre CR version (Re: Final round of Direct Mapping spec changes; please review to prepare for CR)

Juan, Eric, Alexandre,

there are some editorial issues for all three of you below:-)

(B.t.w, It is a little bit disturbing that the date still says 20 September 2011 and the copyright statement is set to 2010... (The latter should be changed before publication...). The CVS log made it clear at the end of the document that I am looking at the right document:-))


- I think that for a final review leading to the CR, we should also see the Status of Document session. Or is it so that the Status will only be the boilerplate text for a CR generated by the tools you use for the publication? (I would expect that to be the case, but we should know...)

- First sentence in Section 2. This is really just being knit-picking, and not being a relational database expert: is 'SQL Database' the right term? My understanding is that there is a notion of a Relational Database, and SQL is a query/definition language thereof.

- Section 2.1. 

  SQL example, first table creation: "ID' -> "ID" (double vs. single quote)

  Again my SQL knowledge... at the last telco we decided to put a quote around identifier to get around the character casing problem. Shouldn't ID be in quotes in the argument of PRIMARY KEY(ID) as well (note that the same statement is quoted in the text after the SQL portion where ID is in quotes)? The same question for the INSERT statements. 

  Also, is it intentional that sometimes single and sometimes double quotes are used? If the two are interchangeable, I would propose to be consistent within the examples

  There is '.' missing after the @base statements in the Turtle example in 2.1

  The last paragraph of the section says:

  [[[
  note however that it is not known how to relate the behaviour of the obtained RDF 
  graph with the standard SQL semantics of the NULL values of the source RDB. For 
  a detailed discussion of this issue, see a forthcoming working group note.
  ]]]

  Is this note really forthcoming? At the moment, we do not know whether it will happen. I guess it would be safer not to have a reference to a publication that may not materialize, ie, just remove the last sentence.

- Section 2.2

   SQL example, the PRIMARY KEY(ID) appears (without quotes) in the second creation statement and with quotes in the first...

   The '.' is missing after @base in the Turtle example.

   There is a superfluous ';' character in the Turtle example: <Department/ID-23> <Department#manager> 8; .

- Section 2.5

   SQL example: is there a reason for the tabulation that puts everything but "lead" and "worker" on a deeper level? I guess this is and editorial bug

   I had difficulties understanding the example here. First of all, it may be worth to make it clear that this example refers back to the example in Section 2.2. But the slightly convoluted nature of unique keys, the fact that they overlap (see the table) makes it a little bit difficult to follow.

   I wonder whether it would not help to remove the references to the Department table (at least from TaskAssignments). It does not bring anything at this point to the user, just creates confusion...

A.4 Denotational semantics, using the set-notation, rules [36] and [38]:

     [36] says:

     IRI(UE(R.name) + "/ref-" + (join('.', UE(A.name) + "-" + UE(A.value)) ∣ A ∈ As ))

   is this correct? This rule establishes the URI for a row, but that should not include the 'ref-' string. That is for the reference predicate...

     On the other hand, shouldn't the '#ref-' appear in rule [38] instead? Note that the English description of that rule misses the reference to '#ref-', too.
   
    The same errors seem to appear in the set-builder notation, too.

B. Rules, General remark: I am not sure what is happening, but the fonts used in the formulae in this appendix seem to be different than the ones in the informative section or Appendix A. I am getting old, but I find the formulae much less readable as a result than in the previous sections.

B. Rules, B.2, generating Literal Triples:

    Is there a missing a rule predicate that accounts for the transformation of a cell value into a possibly typed literal value? The way I read the rules in B.2.1 and B.2.2 is that the cell value is taken verbatim as the object of the literal triples which does not seem to be correct. Maybe I miss something, in which case an explanation in the text may be a good idea...

Thanks for all the work!

Ivan

On Jan 20, 2012, at 17:33 , Juan Sequeda wrote:

> All,
> 
> On behalf of the editors, we believe that the Direct Mapping it is ready for CR. 
> 
> The current Editor's draft can be found: http://www.w3.org/2001/sw/rdb2rdf/directMapping/LC/Overview.html
> 
> Cheers
> 
> Juan Sequeda
> +1-575-SEQ-UEDA
> www.juansequeda.com


----
Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
FOAF: http://www.ivan-herman.net/foaf.rdf