- From: Juan Sequeda <juanfederico@gmail.com>
- Date: Wed, 14 Dec 2011 15:29:35 -0500
- To: Richard Cyganiak <richard@cyganiak.de>
- Cc: Souripriya Das <souripriya.das@oracle.com>, public-rdb2rdf-wg@w3.org
- Message-ID: <CAMVTWDzhEjsbNg1PNYPbg7yY63Mnmyo0G0tz6DC3wooOcwo86w@mail.gmail.com>
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 > > > >
Received on Wednesday, 14 December 2011 20:30:32 UTC