Re: Brain teaser for non-PK tables

> 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 16:09:25 UTC