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

I don't think it is reasonable to REQUIRE that SKOS be used for the translation.
The user should be able to use SKOS but should be able to use other methods as well
All the best, Ashok

On 8/30/2011 1:30 PM, Souripriya Das wrote:
> Richard,
>
> Clearly we differ in our assessments of simplicity. :-) I'd wait for feedback input from others.
>
> SKOS does a lot of things. It is for thesaurus. It is also an overkill for addressing our simple requirement of many-to-one mapping from DB values to RDF terms.
> (I'd rather not shock a user by by requiring them to understand SKOS for implementing such a simple thing.)
>
> The following looks much simpler to me
>   <http://chef.example.com/cuisines>  rr:valueMap
>     [ rr:value "1" ;
>       rr:term<http://chef.example.com/cuisines/asian>
>     ] ,
>
>     [ rr:value "2" ;
>       rr:term<http://chef.example.com/cuisines/asian>
>     ] ,
>
>     [ rr:value "3" ;
>       rr:term<http://chef.example.com/cuisines/italian>
>     ] .
> compared to
> <#db-cuisines>  a skos:ConceptScheme.
>
> [] a skos:Concept;
>      skos:inScheme<#db-cuisines>;
>      skos:notation 1;
>      skos:broadMatch<http://chef.example.com/cuisines/asian>.
> [] a skos:Concept;
>      skos:inScheme<#db-cuisines>;
>      skos:notation 2;
>      skos:broadMatch<http://chef.example.com/cuisines/asian>.
> [] a skos:Concept;
>      skos:inScheme<#db-cuisines>;
>      skos:notation 3;
>      skos:exactMatch<http://chef.example.com/cuisines/italian>.
> Regarding support for literals, why restrict ourselves if we can avoid the restriction (and then wait for R2RML 2.0)? Consider the following example that is not doable in the SKOS-based scheme:
>   <http://chef.example.com/cuisines>  rr:valueMap
>     [ rr:value "1" ;
>       rr:term<http://chef.example.com/cuisines/asian>
>     ] ,
>
>     [ rr:value "2" ;
>       rr:term<http://chef.example.com/cuisines/asian>
>     ] ,
>
>     [ rr:value "3" ;
>       rr:term "Italian Cuisine"^^<CuisineOfEurope>
>     ] .
> Thanks,
> - Souri.
>
> Richard Cyganiak wrote:
>> 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
>>>>        
>>
>>
>>