Re: Brain teaser for non-PK tables

On Thu, May 3, 2012 at 2:01 PM, Richard Cyganiak <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
> >
> >
> > On Thu, May 3, 2012 at 11:08 AM, Michael Hausenblas <
> 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
> > WebID: http://sw-app.org/mic.xhtml#i
> >
> > On 3 May 2012, at 17:04, Eric Prud'hommeaux wrote:
> >
> > > * Juan Sequeda <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
> > >>
> > >> On May 3, 2012, at 10:42 AM, Richard Cyganiak <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
> > >
> >
> >
> >
>
>