Re: ISSUE-66: Translation Scheme as proposed seems too complicated for the simple task of mapping <DB value(s), RDF term>

Souri, Seema,

Thanks for the quick action.

On 30 Aug 2011, at 19:32, Souripriya Das wrote:
> We have uploaded a new version (revision: 1.146) containing the same examples implemented using a new translation scheme that
> 	• is much simpler (does not use SKOS)

I'm not convinced that it is much simpler. It requires around the same number of triples to express the examples. It adds more new vocabulary. In what sense do you see it as simpler?

I read this as implying that the use of SKOS makes the other proposal complicated. But surely there is nothing inherently complicated about SKOS. Did you look into David's proposal here?

http://lists.w3.org/Archives/Public/public-rdb2rdf-wg/2011Aug/0188.html

This is pretty much isomorphic to yours. Reverse the direction of rr:valueMap, and it's identical to yours. SKOS is an existing W3C standard. Why reinvent the wheel here?

> 	• allows DB values to map to any RDF term (IRIs and literals)

Producing literals with a translation table has not been brought up before as a requirement. I feel that this is not a good time to introduce new requirements. I would consider it a possible R2RML 2.0 feature. Adding it to a SKOS-based design would be possible too.

(The motivation for including translation tables in R2RML 1.0 was ISSUE-43, supporting the charter-required re-use of existing *IRIs*.)

Best,
Richard



> The new scheme uses the following new R2RML terms:
> 	• rr:valueMap (range is class rr:ValueMap)
> 	• rr:value (range is xsd:string, really just plain literal)
> 	• rr:term (range is Term Map)
> We have not patched the text around it yet. Also, we can further simplify the mapping via use of some syntactic sugar. We'll do these in a subsequent version.
> 
> Thanks,
> Seema & Souri.
> 
> David McNeil wrote:
>> 
>> 
>> On Tue, Aug 30, 2011 at 12:37 PM, Richard Cyganiak <richard@cyganiak.de> wrote:
>> I take it that you mean to propose to drop the use of SKOS mapping properties?
>> 
>> Yes.
>>  
>> This would lead to almost no simplification in the spec or in implementations. It would simply mean dropping the innermost #3 item in the algorithm [1]. (Plus changing the example, and tweaking the section intro text and the way duplicate notations are detected.)
>> 
>> This would simplify the spec, implementations, and the syntax for doing 1:N mappings.
>> 
>> What is the argument for keeping the SKOS mapping properties?
>> 
>> -David

Received on Tuesday, 30 August 2011 20:01:00 UTC