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

** On Aug 30, 2011, at 02:31 PM, Richard Cyganiak wrote:
*** On 30 Aug 2011, at 18:54, David McNeil wrote:
>>> 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

I expect Richard's scenario to be increasingly common over time,
and the SKOS mapping to be increasingly important and necessary,
and even increasingly *easier* for users.


* On Aug 30, 2011, at 05:16 PM, ashok malhotra wrote:
> 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

I am generally in favor of choice, over restriction, though it
does inevitably complicate matters.

That said, I definitely do not want the SKOS option removed nor
discouraged.  Souri's proposal does appear to me to add more 
"new" than Richard's, while not being significantly simpler.

I see Souri's proposal as essentially limiting one's mapping 
choice to skos:broadMatch (even when skos:exactMatch would be 
more appropriate), while not using that term.

I find the varying levels of correspondence delivered by the 
SKOS Mapping Properties [1] to be important, and thus I'm much 
more inclined toward Richard's proposal than Souri's.  

If there is a strong desire to minimize the needed knowledge of
SKOS, our docs can say that the best *default* mapping property
is skos:broadMatch -- and leave determining the value of mapping 
refinement as an exercise for the user.

Be seeing you,

Ted


[1] http://www.w3.org/TR/skos-reference/#mapping


--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Evangelism & Support         //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
        10 Burlington Mall Road, Suite 265, Burlington MA 01803
                                 http://www.openlinksw.com/weblogs/uda/
OpenLink Blogs              http://www.openlinksw.com/weblogs/virtuoso/
                               http://www.openlinksw.com/blog/~kidehen/
    Universal Data Access and Virtual Database Technology Providers