Re: comments on working drafts

Thanks for your comments. We will discuss them in the Working Group meetings and then get back to you.

However, I wanted to comment on couple of the points you have raised 

Clarification about ISSUE-57:

    * The second option does NOT require support for *ALL* syntaxes for
      RDF. It just requires support for AT LEAST ONE such syntax. The
      difference is that the syntax does NOT HAVE TO BE Turtle. That is,
      one implementation may decide to support only N-Triples syntax and
      another implementation may support Turtle syntax, and so on. The
      basic idea is that a mapping document must be a valid RDF graph
      that uses the R2RML vocabulary properly. But, the syntax in which
      this RDF graph is expressed is immaterial. Different
      implementations may have support for different syntax(es).

Regarding the question about "Sec 9: Assigning Triples to Named Graphs": 

    * Yes, you need to use R2RML view for the scenario you described.

Thanks,
- Souri.

On RDB Direct mapping

2.2 Foreign keys referencing candidate keys
A syntax using a comma separating the two keys "key1,key2" is mentioned twice in this part of the document, while everywhere else the "#ref-key1.key2" convention is used.

On R2RML :

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.


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.


9 Assigning Triples to Named Graphs:
I'm thinking of a case where using a [rr:template ...] would not suffice to express the graph URI, how could I use a rule to say "if column A == "abcd" then use g:graph1", or more complex regex rules.
Would I have to use a R2RML view if I want to do that?



--
Dominique Guardiola, QUINODE
. http://www.quinode.fr/
. Tel : 04.27.86.84.37
. Mob : 06.15.13.22.27