Translation Table Proposal

From RDB2RDF
Revision as of 17:41, 9 August 2011 by Rcygania2 (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

This is a proposal for translation tables in R2RML, proposed as a solution to ISSUE-61.

Rationale

Translation tables have to address two use cases:

1. simple correspondence of database values to URIs

For example, database values 1, 2, 3 correspond to URIs for “indian cuisine”, “thai cuisine” and “italian cuisine”.

2. non-direct correspondence of database values to URIs

For example, database values 1 and 2 translate both to an URI for “asian cuisine” because the URI scheme doesn't distinguish between thai and indian.

The proposal is based on SKOS, because SKOS is designed for expressing controlled vocabularies and code lists, and there are existing tools for creating, managing and publishing such SKOS controlled vocabularies.

The first case can be expressed easily in SKOS: each URI is a skos:Concept; the database value is the value of skos:notation; all concepts are grouped together as a skos:ConceptScheme.

The second case is a bit more tricky. The proposal is to solve this in two steps: 1. make a super-simple concept scheme that directly reflects the values in the database; 2. relate those concepts to the matching concepts from the target concept scheme using the match properties of SKOS, such as skos:exactMatch and skos:broadMatch.

Proposal details

Add a new property rr:translationScheme. It can be used on column-valued term maps or template-valued term maps. It points to a skos:ConceptScheme. The generated RDF terms (zero or more) are URIs that is determined in the following way:

  1. Let v be the value generated by the term map (that is, the value in the column or the value obtained by instantiating the template)
  2. Look up all resources that are in a skos:inScheme relationship with the translation scheme resource
  3. Find the one that has a skos:notation value that matches v. If no resource has that skos:notation value, then it's a data error. (Note: skos:notation values must be unique within a skos:ConceptScheme, that's a constraint imposed by SKOS)
  4. If the resource is an IRI, then add it to the results. (If it is a blank node, don't.)
  5. If the resource has any skos:exactMatch, skos:closeMatch, or skos:broadMatch relationships to other concepts, then add them as well if they are IRIs.

Example 1

This is an example where the database values map directly to URIs.

[] rr:column "cuisine";
    rr:translationScheme <http://chef.example.com/cuisines>.

<http://chef.example.com/cuisines> a skos:ConceptScheme.

<http://chef.example.com/cuisines/indian> a skos:Concept;
    skos:inScheme <http://chef.example.com/cuisines>;
    skos:notation 1.
<http://chef.example.com/cuisines/thai> a skos:Concept;
    skos:inScheme <http://chef.example.com/cuisines>;
    skos:notation 2.
<http://chef.example.com/cuisines/italian> a skos:Concept;
    skos:inScheme <http://chef.example.com/cuisines>;
    skos:notation 3.

Example 2

This is an example where database values don't map directly to URIs, but several DB values may map to the same URI.

[] rr:column "cuisine";
    rr:translationScheme <#db-cuisines>.

<#db-cuisines> a skos:ConceptScheme.

[] a skos:Concept;
    skos:inScheme <#db-cuisines>;
    skos:notation 1;
    skos:broadMatch <http://chef.example.com/cuisines/asian>.
[] a skos:Concept;
    skos:inScheme <#db-cuisines>;
    skos:notation 2;
    skos:broadMatch <http://chef.example.com/cuisines/asian>.
[] a skos:Concept;
    skos:inScheme <#db-cuisines>;
    skos:notation 3;
    skos:exactMatch <http://chef.example.com/cuisines/italian>.