Re: Proposal for the datatype mapping

On 22 Nov 2011, at 15:02, David McNeil wrote:
>> 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”.
> 
> I like the idea, "canonical natural" strikes me as confusing words. I will ponder what I might propose as an alternate label for this. 

Ok, yes, the label can certainly be improved.

>> 4. When generating IRIs in R2RML, the output SHOULD be the canonical natural RDF literal
> 
> I take this to mean: when generating IRIs from SQL values, the string representation used for the SQL values in the IRI SHOULD conform to the lexical value of the "canonical natural RDF literal" for the SQL value. Is that what you mean? 

Yes.

>> 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.
> 
> And if the mapping author does not explicitly convert non-string columns to string, the R2RML processor will implicitly convert them, and perhaps not use the "canonical natural RDF literal" form and therefore different R2RML processors may produce different IRIs for the same mapping and data. Just re-iterating what I think you are saying to make sure I understand the proposal. 

Yes. Or, re-phrasing it once more (and combining it with point #4):

Mapping authors SHOULD explicitly convert non-string columns to string using an R2RML view when generating IRIs. If they don't do this, then the R2RML processor will implicitly convert the column. When doing so, the processor SHOULD produce the canonical form, but this is not strictly required. When the mapping author doesn't convert to string, and the R2RML processor doesn't use the canonical form, then we have a situation where different processors may generate different forms, resulting in different IRIs from the same mapping and data and potential interoperability problems. This is acceptable because not all authors may care, and those who do can work around it.

Best,
Richard

Received on Tuesday, 22 November 2011 15:19:20 UTC