Proposal for the datatype mapping

Some quick input for the discussion on the call later today.

I could see us getting consensus around the following design:

1. The spec formally defines two kinds of RDF literals corresponding to a SQL value: the “natural RDF literal” and the “canonical natural RDF literal”. The latter is in XSD canonical form, the former is *any* literal of the same datatype that has the same value as the canonical RDF literal. For example, for a SQL int 7, canonical natural RDF literal would be "7"^^xsd:integer, while "007"^^xsd:integer and "+7^^xsd:integer" would be examples of non-canonical natural RDF literals

2. There is an *informative* section that explains SQL-based recipes for generating both forms.

3. When generating literals in the DM or in R2RML without datatype overrides, the output is defined to be the *any* natural RDF literal. It follows that implementations MAY use the canonical RDF literal.

4. When generating IRIs in R2RML, the output SHOULD be the canonical natural RDF literal, although non-canonical forms are still conforming.

5. It is noted that R2RML mapping authors SHOULD explicitly convert non-string columns to string in an R2RML view when generating IRIs to maximize portability of their mappings.

6. When generating IRIs in the DM, the output MUST be the canonical RDF literal.

7. The behaviour for vendor types remains unchanged: they are converted to plain literals by default, but it is noted that implementations are expected to add custom behaviour.

Action would be on the R2RML editors to update their spec accordingly, and on the DM editors to change their spec to reference the respective terms in the R2RML spec.

(This is closer to Eric's original design than mine, except that literals do not have to be in canonical form, and informative SQL recipes are provided.)

Best,
Richard

Received on Tuesday, 22 November 2011 14:16:40 UTC