Re: please read before participating in translation scheme debate [Re: Translating DB values to RDF terms using 1) R2RML views and 2) using R2RML-native translation scheme]

On Wed, Dec 14, 2011 at 3:21 PM, Richard Cyganiak <richard@cyganiak.de>wrote:

> On 14 Dec 2011, at 20:01, Juan Sequeda wrote:
> > Comparing both proposals:
> >
> > Souri:
> >
> > x:myTranslationScheme rr:translationMap
> >   [ rr:toTerm <http://www.nyc.gov> ;            rr:fromTerm <
> http://www.city.New%20York.NY.us> ] ;
> >   [ rr:toTerm <http://www.cityofboston.gov> ;   rr:fromTerm <
> http://www.city.Boston.MA.us> ] ;
> >   [ rr:toTerm <http://www.atlantaga.gov> ;      rr:fromTerm <
> http://www.city.Atlanta.GA.us> ] ;
> >   [ rr:toTerm <http://www.miamigov.com> ;       rr:fromTerm <
> http://www.city.Miami.FL.us> ] ;
> >   [ rr:toTerm <http://www.dallascityhall.com> ; rr:fromTerm <
> http://www.city.Dallas.TX.us> ] ;
> >   [ rr:toTerm <http://www.lacity.org> ;         rr:fromTerm <
> http://www.city.Los%20Angeles.CA.us> ] ;
> >   [ rr:toTerm <http://www.sfgov.org> ;          rr:fromTerm <
> http://www.city.San%20Francisco.CA.us> ] ;
> >   [ rr:toTerm <http://www.seattle.gov> ;        rr:fromTerm <
> http://www.city.Seattle.WA.us> ] ;
> >   [ rr:toTerm <http://www.cityofchicago.org> ;  rr:fromTerm <
> http://www.city.Chicago.IL.us> ] .
> >
> > Richard:
> >
> >   []  skos:inScheme x:myTranslationScheme;
> >       skos:notation <http://www.city.New%20York.NY.us>;
>
> skos:notation are always literals, so if we want to support
> IRI-to-something-else mappings with SKOS it would have to be:
>
>      skos:notation "http://www.city.New%20York.NY.us";
>
> The spec would define that skos:notation values must always be literals,
> regardless of the actual term type (rr:IRI or rr:Literal) that is produced
> by the term map.
>
> (As I said before, I'm opposed to supporting IRI-to-something-else
> mappings, because AFAIK the only use case for this are “partial
> translations” that let untranslated database values pass through unchanged,
> and I'd rather have such partial translations produce no triples for
> untranslated database values.)
>

Ok I see and I agree.

We are translating database values to RDF terms.. so the database values
are going to be literals, not IRIs. So I agree with Richard on this.


>
> >       skos:exactMatch <http://www.nyc.gov>.
> >
> >   []  skos:inScheme x:myTranslationScheme;
> >       skos:notation <http://www.city.Boston.MA.us>;
> >       skos:exactMatch <http://www.cityofboston.gov>.
> >
> > .....
> >
> > So basically
> >
> > rr:translationMap ~= skos:inScheme
> > rr:fromTerm = skos:notation
> > rr:toTerm = skos:exactMatch
> >
> >
> > Souri's proposal would avoid the following repetitive triple
> >
> > []  skos:inScheme x:myTranslationScheme;
>
> It wouldn't even *avoid* the triple. The triple is still there, it's just
> written using the convenient comma syntax in Turtle. That syntax allows
> abbreviation of repetitive triples that have the same s+p but different o,
> like here:
>
>   :Alice foaf:name "Alice"; foaf:knows :Bob, :Charlie, :Dana, :Ed.
>
> So, Turtle has syntactic sugar for repetitive s+p, but not for repetitive
> p+o. Therefore, in Souri's proposal it can be abbreviated; in my proposal,
> where the property points in the other direction, it can't. Unfortunately
> there is no inverse of skos:inScheme defined in SKOS, so there's no way
> around that if we want to use SKOS.
>

I was wondering about that (hence my questions that the <#cuisine> should
be in the subject). Honestly, that does make things a bit weird. I was
expecting things to be the other way around, which confused me. I basically
want to dereference the IRI for that mapping scheme and see what the
translation table is. I guess it can be done and it would be an
implementation detail. Nevertheless, I was confused initially.

I'm now onboard with this discussion but it would be beneficial if more
people would chime in.

Implementation-wise, either proposal doesn't matter. It seems that it's
just a matter of taste.


> > Am I missing something else?
>
> Nope.
>
> Best,
> Richard
>
>
>
> >
> >
> >
> > Best,
> > Richard
> >
>
>