Re: Brain teaser for non-PK tables

+1 for option 2.  Seems less onerous.   Eric?
All the best, Ashok

On 5/3/2012 12:10 PM, Juan Sequeda wrote:
>
>
> On Thu, May 3, 2012 at 2:01 PM, Richard Cyganiak <richard@cyganiak.de <mailto:richard@cyganiak.de>> wrote:
>
>     On 3 May 2012, at 17:11, Juan Sequeda wrote:
>     > Do you accept eric's proposal (which hasn't been stated yet):
>     >
>     > 1) Leave DM as-is
>     > 2) Add the following to R2RML
>     >
>     >  rr:subjectMap [
>     >     rr:termType rr:RowBlankNode
>     >   ];
>
>     (I'd prefer calling it rr:BlankNode. The absence of rr:column/rr:template/rr:constant indicates the new behaviour.)
>
>     This is a new feature that was never discussed before. It's not just a tweak. No existing RDB2RDF mapping language has anything comparable. How to sensibly implement it, is a somewhat open question, AFAIK. Had this been proposed a few months ago, everyone would have said, “sounds like an R2RML 1.1 feature” and we would have postponed it without complaints.
>
>     The problem at hand is the an incompatibility between two specs, let's call them A and B, in a corner case. Now given these choices:
>
>     1) Add a new and somewhat risky feature to spec A, at a time when we thought we were just about to enter PR. Send all implementers of A back to the drawing board. Delay the WG for an indefinite amount of time, over a barely relevant corner case.
>
>     2) Relax a constraint in spec B to say you SHOULD implement the “correct” behaviour for this corner case, but MAY also implement another not entirely unreasonable behaviour that is compatible with A as it is. Add some alarming language and say: “We expect future versions of A to remove this limitation.” No implementation changes. Go to PR in three weeks.
>
>     To me, 2) makes a lot more sense than 1).
>
>
> I agree with Richard. Option 2 seems more reasonable at the moment.
>
> We already have other issues to address for a R2RML and DM 1.1 version. This could be part of it. I'm not sure how this works in the standardization process, but as a group, we believe this particular issue is a corner case so it's not imperative to include it in the current version of the standard. However, if users complain about this corner case (we then realize that it isn't a corner case), we realize we were wrong from the beginning. I'm guessing this sometimes (usually?) happens in standards, right?
>
>
>     Best,
>     Richard
>
>
>
>     >
>     >
>     > Juan Sequeda
>     > +1-575-SEQ-UEDA
>     > www.juansequeda.com <http://www.juansequeda.com>
>     >
>     >
>     > On Thu, May 3, 2012 at 11:08 AM, Michael Hausenblas <michael.hausenblas@deri.org <mailto:michael.hausenblas@deri.org>> wrote:
>     >
>     > > Were we close to closing R2RML's CR?
>     >
>     > This was the last issue, all other have been resolved in last weeks meeting (see also my comments when I sent out the minutes [1]). Never mind, we're not extending CR but entering a second, rather short LC period.
>     >
>     > Ivan, can you prepare a respective PROPOSAL for next week's meeting please?
>     >
>     > Cheers,
>     >           Michael
>     >
>     > [1] http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2012May/0005.html
>     >
>     > --
>     > Dr. Michael Hausenblas, Research Fellow
>     > DERI - Digital Enterprise Research Institute
>     > NUIG - National University of Ireland, Galway
>     > Ireland, Europe
>     > Tel.: +353 91 495730 <tel:%2B353%2091%20495730>
>     > WebID: http://sw-app.org/mic.xhtml#i
>     >
>     > On 3 May 2012, at 17:04, Eric Prud'hommeaux wrote:
>     >
>     > > * Juan Sequeda <juanfederico@gmail.com <mailto:juanfederico@gmail.com>> [2012-05-03 10:50-0500]
>     > >> Looks like we have to extend CR till
>     > >> we have implementations for this corner case.
>     > >
>     > > Were we close to closing R2RML's CR?
>     > >
>     > >
>     > >> Juan Sequeda
>     > >> www.juansequeda.com <http://www.juansequeda.com>
>     > >>
>     > >> On May 3, 2012, at 10:42 AM, Richard Cyganiak <richard@cyganiak.de <mailto:richard@cyganiak.de>> wrote:
>     > >>
>     > >>> On 3 May 2012, at 16:25, Eric Prud'hommeaux wrote:
>     > >>>> presumes you can create tables, but yeah, conceptually easier query.
>     > >>>
>     > >>> (It looks like most databases have a proprietary method of adding the indexes that doesn't require write access to the DB.)
>     > >>>
>     > >>>> you can even push the symbol generation down:
>     > >>>
>     > >>> Right.
>     > >>>
>     > >>>>> The big remaining question is: How to handle this in R2RML?
>     > >>>>
>     > >>>> Looking for an analog to:
>     > >>>> rr:subjectMap [
>     > >>>>      rr:column "ROWID";
>     > >>>>      rr:termType rr:BlankNode
>     > >>>>   ];
>     > >>>> I'd propose:
>     > >>>> rr:subjectMap [
>     > >>>>      rr:termType rr:RowBlankNode
>     > >>>>   ];
>     > >>>
>     > >>> That's an option. Even keeping rr:BlankNode would work — the absence of an rr:column/rr:template/rr:constant might signal that a fresh blank node must be allocated for each row.
>     > >>>
>     > >>>> Does that complicate things beyond how much a cardinality requirement necessarily complicates things?
>     > >>>
>     > >>> Well, the spec only needs to define the graph generated by the mapping, so in terms of specification it would be a simple enough change.
>     > >>>
>     > >>> The implications for implementers are quite significant though. It's a new feature, the implementation costs are not trivial, no existing implementation does this (AFAIK), so there's a certain amount of R&D required to show that it's implementable.
>     > >>>
>     > >>> Best,
>     > >>> Richard
>     > >
>     > > --
>     > > -ericP
>     > >
>     >
>     >
>     >
>
>