- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Thu, 3 May 2012 20:01:44 +0100
- To: Juan Sequeda <juanfederico@gmail.com>
- Cc: Michael Hausenblas <michael.hausenblas@deri.org>, "Eric Prud'hommeaux" <eric@w3.org>, Ivan Herman <ivan@w3.org>, W3C RDB2RDF <public-rdb2rdf-wg@w3.org>
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). 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 > > > > >
Received on Thursday, 3 May 2012 19:02:16 UTC