Re: comments on working drafts

Re-sending with the proper email addresses. -- Souri.

Souripriya Das wrote:
> 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
>