Re: comments on working drafts

Hi Dominique,

This is an official response from the RDB2RDF Working Group regarding your comments on the R2RML Last Call working draft:
http://lists.w3.org/Archives/Public/public-rdb2rdf-comments/2011Sep/0006.html

First of all, thanks for your comments.

You said:

> ISSUE-57 :
> Asking for any RDF syntax support should be optional.
> Given the availibility of RDF converters and librairies to make Turtle from anyhting, asking for implementations to support all syntaxes is excessive.
> To allow time for adoption and real-life experiments with the vocabulary, the Turtle syntax should be the only mandatory syntax for processors, so that exchange, learning and adoption would not be impaired by syntax-related side questions.

The working group considered this and decided to adopt a design that amounts to the following:

[[
An R2RML processor is a system that, given an R2RML mapping and an input database, provides access to the output dataset.

An RDF graph that represents an R2RML mapping is called an R2RML mapping graph.

An R2RML mapping document is any document written in the Turtle RDF syntax that encodes an R2RML mapping graph.

A conforming R2RML processor SHOULD accept R2RML mapping documents in Turtle syntax. It MAY accept R2RML mapping graphs encoded in other RDF syntaxes.
]]

This means that R2RML implementations SHOULD support Turtle and MAY support other syntaxes. Only mappings expressed in Turtle are officially considered R2RML mapping documents.

You also said:

> ISSUE-66 :
> I read the exchanges and the minutes where the final resolution was taken.
> I think this decision is a pity : if you look from the point of view of future R2RML end-users , translation tables are a common pattern, which is present, for example in most web development frameworks or CMSs.
> Anyone making SQL database knows it's better to use integers columns instead of verbose labels in order to :
> - speed up queries
> - allow the renaming of these columns labels easily
> - avoid typos when these columns are also keys (when there's no foreign key constraint : think of MyISAM, probably one of the most common DB storage)
> 
> The use of SKOS here is a false question : it's true this looks like a "controlled vocabulary" situation, but I'd follow the argument stating that having properties like rr:value, rr:term is simpler for RDF newbies. I mean, a vocabulary choice question should not prevent you to provide this kind of simple feature.
> Allowing the table to be linked elsewhere is important too, but could be added later, as could be more complex mapping techniques.
> But removing this simple tool, a 1:1 code-to-string or code-to-URI table, from being part of the recommandation would send IMHO a bad signal to newcomers , like "hey, they didn't even think of a straightforward way to do that?"
> Having to do pre-queries in a R2RML view just to fetch some labels in a separate table (that perhaps doesn't even exists, the labels list being hardcoded in the application code) is not really an answer.

The working group discussed this at length. Ultimately, the argument that carried the day was that translation tables can be written in pure SQL without too much difficulty, and therefore it is considered acceptable to ship R2RML 1.0 without dedicated support for translation tables.

An example for (very simple) translation using SQL functions was added to the R2RML specification:
http://www.w3.org/2001/sw/rdb2rdf/r2rml/#example-translationtable

Translation tables are one of the issues that would likely be on the table in case a future working group should be chartered to update R2RML towards a version 1.1.

For our internal Last Call housekeeping, can you please let the working group know whether you consider your comment addressed by this response?

Thanks again, and all the best,
Richard

Received on Tuesday, 20 December 2011 19:26:11 UTC