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

On 13 Dec 2011, at 05:34, Juan Sequeda wrote:
> I have never looked at SKOS to be honest because I don't have time to thoroughly learn about *another* semantic web standard.
> If we are tackling a semantic web audience that will most probably be familiar with SKOS, then I think we are ok. But if you are tackling a non-semantic web audience and the only reason they are learning R2RML is because their boss told them to export their RDB data as RDF... besides the R2RML learning curve... you are going to make them learn SKOS, assuming they "kinda" know some RDF and SPARQL... this is going to be a pain. This is where all the alphabet soup comes in and is not appealing (and this is my real world experience). 

I tried to address this concern using language like this:

[[
Note: R2RML translation schemes are defined using the following properties from the SKOS vocabulary:

• skos:inScheme
• skos:notation
• skos:closeMatch, skos:exactMatch, skos:broadMatch (all treated equivalently in R2RML)

The presence of other SKOS terms in the mapping graph has no effect on R2RML processing, and no further knowledge of SKOS besides what is presented in this section is required to author R2RML mappings.
]]

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

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

That's all a mapping author really needs to know.

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

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

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 12:42:04 UTC