Re: Comments needed – Re: Lookup table proposal (re ISSUE-72)

Juan,

On 13 Dec 2011, at 15:57, Juan Sequeda wrote:
>> [[
>> Note: R2RML translation schemes are defined using the following properties from the SKOS vocabulary:
…
>> • skos:closeMatch, skos:exactMatch, skos:broadMatch (all treated equivalently in R2RML)
> 
> Why not choose just one, for example skos:exactMatch. 

If I match the database code for “thai” to a re-usable identifier for “thai” then that's skos:exactMatch. If I match the code to a re-usable identifier for “asian” then that's skos:broadMatch. The R2RML processing is the same, but the semantics are quite different. If you manage mappings of multiple bigger code tables to a shared scheme, then this is useful documentation.

Perhaps more importantly, users already familiar with SKOS would wonder why they can only use skos:exactMatch but not skos:broadMatch, and would consider it an error to map “thai” to “asian” using skos:exactMatch.

>> This might be followed by an example like this:
>> 
>> +------+------------------------------------------+
>> | Code | IRI                                      |
>> +------+------------------------------------------+
>> | 1    | http://chef.example.com/cuisines/indian  |
>> | 2    | http://chef.example.com/cuisines/thai    |
>> | 3    | http://chef.example.com/cuisines/italian |
>> +------+------------------------------------------+
> 
> I'm guessing this is not part of the RDB. This is what I want to map to, right?

Yes, exactly.

>> []  rr:column "cuisine";
>>     rr:translationScheme <#cuisineScheme>.
>> 
>> []  skos:inScheme <#cuisineScheme>;
>>     skos:notation 1;
>>     skos:exactMatch <http://chef.example.com/cuisines/indian>.
>> 
>> []  skos:inScheme <#cuisineScheme>;
>>     skos:notation 2;
>>     skos:exactMatch <http://chef.example.com/cuisines/thai>.
>> 
>> []  skos:inScheme <#cuisineScheme>;
>>     skos:notation 3;
>>     skos:exactMatch <http://chef.example.com/cuisines/italian>.
> 

> This notation is different from: http://www.w3.org/2001/sw/rdb2rdf/drafts/translation-tables-DERI2.html

Yes, that proposal is nice and compact, but doesn't work if multiple code tables are mapped to the same concept scheme as Souri pointed out. I have held off on writing a new proposal as it's unclear what features Oracle considers essential and what not.

>> Is there a full example with the entire mapping. Let's say Restaurant Name and Cuisine.
>> 
>> Ex 1:
>> 
>> Restaurant(id, name, cuisine_id)
>> Cuisine(id, cuisine)

I'm going to ignore the Cuisine table. We want to re-use standard identifiers for the different cuisine types, and I assume that those standard identifiers already come with their own labels and descriptions that I can download in RDF. So all I really need is to map the cuisine IDs to the standard identifiers. That's already achieved using the <#cuisineScheme> above, so I'll just use that:

[]  rr:logicalTable [ rr:tableName "Restaurant" ];
    rr:subjectMap [ rr:template "/restaurant/{id}" ];
    rr:class ex:Restaurant;
    rr:predicateObjectMap [
        rr:property ex:name;
        rr:objectMap [ rr:column "name" ];
    ];
    rr:predicateObjectMap [
        rr:property ex:cuisine;
        rr:objectMap [
            rr:column "cuisine";
            rr:translationScheme <#cuisineScheme>;
        ];
    ].

If I really wanted to generate labels for the standard cuisine IRIs from the Cuisine table, then that would be:

[]  rr:logicalTable [ rr:tableName "Cuisine" ];
    rr:subjectMap [
        rr:column "id";
        rr:translationScheme <#cuisineScheme>;
    ];
    rr:class ex:Cuisine;
    rr:predicateObjectMap [
        rr:property ex:name;
        rr:objectMap [ rr:column "cuisine" ];
    ].

>> Ex 2:
>> 
>> Restaurant(id, name, cuisine)

I assume that cuisine contains strings like "thai", "mexican", etc?

Then I'd need a different translation scheme that maps from these strings to the respective IRIs, such as:

   []  skos:inScheme <#cuisineScheme>;
       skos:notation "indian";
       skos:exactMatch <http://chef.example.com/cuisines/indian>.

Other than that it would be pretty similar.

Best,
Richard




> 
> Again, I'm sorry if I'm making you repeat your self. I'm just now getting on track with all of this discussion.
>  
> 
> The major difference between this proposal and the custom vocabulary proposal in my eyes is that the latter uses “rr:” where the former uses “skos:” and then they use slightly different names behind the colon too.
> 
> That was my impression too. :)
>  
> Yes there are differences in expressivity and in the handling of certain corner cases, but those are mostly orthogonal to the question of whether to use terms from the SKOS namespace or terms in the R2RML namespace. If only we could agree on a basic approach, then whatever the approach is, it could be tailored to cover the expressivity and corner cases we consider important…
> 
> I agree 
> 
> That being said, if you want to know more about SKOS then a good start might be this:
> http://www.slideshare.net/fabien_gandon/skos-in-a-nutshell-368338
> 
> Thanks! 
> 
> 
> This covers pretty much everything there is to know about SKOS in 26 slides. It doesn't mention skos:notation – that's a property for a (usually not human-readable) code that uniquely identifies a concept within a concept scheme.
> 
> The SKOS-based proposal uses a concept scheme as a translation table. Each concept represents one possible value in the database (via skos:notation). Each concept is mapped to one or more URIs using the skos:xxxMatch properties. R2RML doesn't care whether it's exactMatch, closeMatch or broadMatch – the processing is the same. 
> 
> Best,
> Richard
>

Received on Tuesday, 13 December 2011 19:24:02 UTC