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

On Tue, Dec 13, 2011 at 7:41 AM, Richard Cyganiak <richard@cyganiak.de>wrote:

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

Why not choose just one, for example 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?


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

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

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)

Ex 2:

Restaurant(id, name, cuisine)

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