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

* Eric Prud'hommeaux <eric@w3.org> [2012-01-24 11:30-0500]
> On Tue, Jan 24, 2012 at 11:11, Juan Sequeda <juanfederico@gmail.com> wrote:
> > Ivan,
> >
> > I've addressed your
> > comments: http://www.w3.org/2001/sw/rdb2rdf/directMapping/LC/Overview.html
> >
> > Comments in-line
> >
> >
> > On Sun, Jan 22, 2012 at 6:27 AM, Ivan Herman <ivan@w3.org> wrote:
> >>
> >> 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'll leave this to Eric
> 
> I'm sort of in between computers right now. Will edit more as soon as
> I can get my conf back up.

done


> >> - 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...)
> >>
> >
> > I'll leave this to Eric

This will be a complex issue which I will take this up in thread
called "LC Status and implementation reports".


> >> - 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.
> >
> >
> > Fine by me. R2RML uses the term "relational database". We should be
> > consistent, so I changed it.
> 
> But the definition we care about is entirely from SQL and has very
> little to do with actual relational database theory.
> I won't stand in the way here, but I think the right answer is actually "SQL".

I haven't heard a response so I guess the consensus is to stick with "relational".


> >> - Section 2.1.
> >>
> >>  SQL example, first table creation: "ID' -> "ID" (double vs. single quote)
> >
> >
> > Done
> >>
> >>
> >>  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 added missing quotes in another example.
> >
> > Not sure about the INSERT statements... somebody?
> 
> I don't think the INSERTs are strictly necessary as the case-folding
> behavior will have the same effect as if there were no case-folding.
> I think we should decide this based on what's more intuitive to the reader.
> What's more intuitive to the reader?

Ted made more comments on this. I'll respond to those sepparately.


> >>  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
> >
> >
> > I only see single quotes in the INSERT statements. Can somebody confirm if
> > this is ok?
> >>
> >>
> >>  There is '.' missing after the @base statements in the Turtle example in
> >> 2.1
> >
> >
> > Done
> >>
> >>
> >>  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.
> >
> >
> > This is a note that I have planned to write with Marcelo. Remember the
> > hundreds of emails on this topic... if I recall, the resolution was to add
> > those two sentences to the spec. Michael, can you confirm?
> 
> I think we can see if there's a note by the time we get to Rec. If
> not, I think the sentences should go.
> 
> >> - Section 2.2
> >>
> >>   SQL example, the PRIMARY KEY(ID) appears (without quotes) in the second
> >> creation statement and with quotes in the first...
> >
> >
> > Done
> >>
> >>
> >>   The '.' is missing after @base in the Turtle example.
> >
> >
> > Done
> >>
> >>
> >>   There is a superfluous ';' character in the Turtle example:
> >> <Department/ID-23> <Department#manager> 8; .
> >
> >
> > Done
> >
> >>
> >>
> >> - 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'm not sure I follow. Does it look like the attached 2.5.png?


> >>   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...
> >
> >
> > I'll leave this to Eric
> 
> The point is exactly to show what happens when you have multi-column
> overlapping keys. Perhaps some text like "this is a complicated
> example intended to show the behavior with respect to multi-column
> overlapping keys" will properly calibrate the reader.
> 
> >> 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.
> 
> At least they're consistent...
> I'll fix this when I get editing again (grrr!).

done.

Also updated Appendix A to offload the definitions of "natural RDF
literal" and "canonical RDF literal" to R2RML. Diffs will be linked
from the "LC Status and implementation reports" thread.


> > I'll leave this to Eric
> >
> >>
> >>
> >> 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.
> >
> >
> > You are right. The font was smaller. I increased it
> >>
> >>
> >> 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 finding this :)
> >
> > We added a built in predicate generateTypedLiteral
> >>
> >>
> >> 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
> >>
> >>
> >>
> >>
> >>
> >
> 
> 
> 
> -- 
> -ericP
> office: +1.617.258.5741
> mobile: +1.617.599.3509

-- 
-ericP

Received on Thursday, 26 January 2012 13:16:57 UTC