Re: Brain teaser for non-PK tables

Looks like we have to extend CR till
we have implementations for this corner case. 

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

Received on Thursday, 3 May 2012 15:51:41 UTC