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

* Juan Sequeda <juanfederico@gmail.com> [2012-01-26 14:01-0500]
> Ivan,
> 
> On Jan 26, 2012, at 8:48 AM, Ivan Herman <ivan@w3.org> wrote:
> 
> > Hey Eric, Juan
> > 
> > everything that I removed means that I agree with your editing and I consider the issue closed...
> > 
> > On Jan 26, 2012, at 14:16 , Eric Prud'hommeaux wrote:
> > [snip]
> > 
> >> 
> >> 
> >>>>> - 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".
> >> 
> > 
> > :-)
> > 
> >>>>> 
> >>>>> 
> >>>>>  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.
> > 
> > Ok. I leave this to Ted then.
> > 
> > [snip]
> > 
> >>>>> 
> >>>>>  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.
> >>> 
> > 
> > O.k, this has to be checked with Michael. I do remember that we had a resolution that you and Marcelo (and Paolo?) would write such a note. But if we leave this text in, that means we cannot publish a Rec until that Note is finished and published. Do you accept that responsibility in your schedule?
> > 
> > If we remove this from the text, you still have a 'moral' obligation of writing the note:-), but at least you do not become a possible bottleneck:-)
> 
> Let's remove the text. I don't have time to write this in the next month. However, I will get it done :)

Noting Marcelo's consent, I have made this edit in R1.17:

s/Additionally, the direct mapping does not generate triples for NULL values; 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.
 /The direct mapping does not generate triples for NULL values/


> Is that ok Michael. 
> > 
> > [snip]
> > 
> >>>> 
> >>>>> 
> >>>>> 
> >>>>> - 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?
> >> 
> > 
> > You have not attached a file to the mail, but I do now... This is on Safari on Mac, the same happens on Firefox on Mac.

Sigh, trying again...


> > [snip]
> > 
> > 
> >> 
> >>>>>   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.
> > 
> > Ok. Maybe so. If we were not at CR I would propose to cut the example into two, a simpler and a more complex ones, but I recognize that this would lead to additional editorial jobs elsewhere (eg, to Juan in Appendix 3), so I let it go...
> > 
> > [snip]
> > 
> > Thanks guys!
> > 
> > Ivan
> > 
> > ----
> > 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
> > 
> > 
> > 
> > 
> > <Screen Shot 2012-01-26 at 14.36.02 .png>

-- 
-ericP