Re: Brain teaser for non-PK tables

* 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 16:05:32 UTC