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

On 30 Aug 2011, at 18:54, David McNeil 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?

I'm assuming a case where there are let's say 100 DB codes in a translation scheme. Maintaining the mapping between these codes and the URIs inside the mapping file doesn't seem very desirable. One wants to have that in a separate file.

The current design reduces the problem of mapping between DB codes and external URIs to the problem of mapping between two SKOS concept schemes. There's tool support for that.

At the same time, it still supports very compact expression of small 1:1 (and 1:N, after the change) mappings.

Scenario:

1. Write R2RML mapping without the cuisine translation scheme
2. Find an existing cuisine taxonomy published as SKOS on the web
3. Export the VENUE.CUISINE property to SKOS
4. Use a SKOS editor to map between them, save result as cuisine-mappings.ttl
5. RDF-merge cuisine-mappings.ttl with the main R2RML file into a complete file
6. Start R2RML processor with that merged file

Best,
Richard

Received on Tuesday, 30 August 2011 18:32:14 UTC