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

On Tue, Dec 13, 2011 at 2:23 PM, Richard Cyganiak <richard@cyganiak.de>wrote:

> 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>;
>        ];
>    ].
>
>
But where is  <#cuisineScheme> described? I assume that should be somewhere
as the subject.

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