W3C home > Mailing lists > Public > public-rdb2rdf-comments@w3.org > November 2011

Re: Editorial comments on R2RML

From: Richard Cyganiak <richard@cyganiak.de>
Date: Mon, 7 Nov 2011 18:01:28 +0000
Cc: Souripriya Das <Souripriya.Das@oracle.com>, Seema Sundara <seema.sundara@oracle.com>, public-rdb2rdf-comments@w3.org
Message-Id: <8FB85394-167B-495F-A8C5-EF681FFE45BC@cyganiak.de>
To: Ivan Herman <ivan@w3.org>
Hi Ivan,

Thanks for your comments! The WG discussed your comments. Our response is below, inline. Please let us know if this response addresses your comments.

On 4 Oct 2011, at 15:54, Ivan Herman wrote:
> Section 7.3
> The example refers to the IRI-safe template value using the following:
> [] rr:subjectMap [ rr:template "http://data.example.com/site/{LOC}" ].
> the IRI-safe version kicks in only if the term is declared to be an IRI. I know that this is defined, later, to be the default case for subject map using a template but it may be worth making this clear in the text (or simply add the extra rr:termType to the example.)

I'd prefer not to add a redundant rr:termType, because it can teach bad habits to authors.

Actually the example below this one is buggy in the LC draft, because it is supposed to create literals, but doesn't have an rr:termType declaration, so the default of rr:IRI would be used. This is fixed in the latest ED:

By default, rr:template generates IRIs. Since the intention here is to create a literal instead, the term type has to be set.

    [] rr:objectMap [
        rr:template "\\{\\{\\{ \\\\o/ {TITLE} \\\\o/ \\}\\}\\}";
        rr:termType rr:Literal;

I think that this makes the role of rr:termType and the generation of IRIs versus literals clear enough in this section, so I hope it addresses your comment.

> Section 7.6, first sentence
> langauge -> language


> Section 9.1 
> (I am not sure the remark should go to this section, though)
> I would expect that if I have:
> [] rr:subjectMap [ rr:termType rr:BlankNode ] ;
> in a triple map, what this means is that each row has a newly generated blank node as a subject. I wonder whether it is worth making this fact explicit in the document, it may not be entirely obvious.

The snippet above is not valid R2RML, in fact. Section 7 states:

A term map must be exactly one of the following:

	 a constant-valued term map,
	 a column-valued term map,
	 a template-valued term map.

And each of these types require an explicit specification to say where the value comes from. So it needs either rr:constant, rr:column or rr:template. In the case of a term map that generates blank nodes, this value will be used to generate the blank node identifier.

Making it work like you suggest would be very hard. It would require automatic determination of a candidate key for the underlying logical table, that is, a set of logical columns that are guaranteed to have unique values in each row. This determination is hard or impossible for some kinds of logical tables (R2RML views, and base tables or views without declared primary key).

> Appendix:
> The previous version of the document had a number of examples that were very helpful. It is a pity to throw them away. Either we should plan for a separate primer document (but I am not sure we will have the energy for that) or we should put those back into the spec document as an (obviously informal) appendix.

The examples have been moved into the test cases document:

This is noted in Section 2 of the R2RML spec:

Further R2RML examples can be found in the R2RML and Direct Mapping Test Cases [TC].

I think that the examples in Section 2 are sufficient and I don't think that adding further general examples as an appendix would improve the spec. All the features that were shown in those extended examples are used and explained in Section 2. If you feel that specific R2RML features lack sufficient examples, then please let us know and we'll consider it. However, I'd prefer to add small and tailored specific examples to the section that explains the feature, or perhaps to Section 2.

Thanks again for the comments!

Received on Monday, 7 November 2011 18:01:58 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:45:16 UTC