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

> 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.


That sounds like a reasonable compromise. Not making it explicitly  
depend on SKOS but to provide a default that can be overridden (and  
spec it that way).

Cheers,
	Michael
--
Dr. Michael Hausenblas, Research Fellow
LiDRC - Linked Data Research Centre
DERI - Digital Enterprise Research Institute
NUIG - National University of Ireland, Galway
Ireland, Europe
Tel. +353 91 495730
http://linkeddata.deri.ie/
http://sw-app.org/about.html

On 13 Sep 2011, at 16:34, Ted Thibodeau Jr wrote:

>
> ** 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
>
>
>
>

Received on Tuesday, 13 September 2011 15:40:48 UTC