Re: definition of natural mapping

On 11 Jan 2012, at 15:38, Eric Prud'hommeaux wrote:
> My proposal is editorial.

I prefer the current R2RML wording.

> Digging into the SQL, I think we can learn that bullet 2, "character string type", covers the six types with the word "CHARACTER" in them. My concearn is for the reader who doesn't dig deeply and wonders if CHARACTER(1) is a "string type".

If they consider it as a non-string type, the result is the same, because vendor extension types are handled in the same way as strings.

> Looking at the SQL 2006 in front of me, I think that bullet 3 covers the rest of the SQL data types. What then does bullet 4 apply to?

Vendor extensions.

Best,
Richard



> 
> 
>>> (E.g. many DBs have native support for XML but we probably don't want to imply that XML is serialized as a (canonicalized?) plain literal.
>> 
>> The spec explicitly states:
>> 
>> [[
>> Note: R2RML processor implementations that handle vendor-specific types or user-defined types beyond the standard SQL 2008 datatypes are expected to do so by behaving as if the table above contained additional rows that associate the SQL datatypes with appropriate RDF-compatible datatypes (e.g., the XML Schema built-in types [XMLSCHEMA2]), and appropriate lexical transformations where required.
>> ]]
>> 
>>> I proposed to strike the line.
>> 
>> The line is backed by a formal WG resolution.
>> 
>>> An alternative would be to refine http://www.w3.org/2001/sw/rdb2rdf/directMapping/LC/#defn-literal_map to say [[
>>> Definition literal map: a mapping from an SQL value with a datatype to:
>>> 
>>> • For row nodes, a canonical RDF literal representation of the column value as defined in points 1-3 in R2RML section 10.2 Natural Mapping of SQL Values.
>>> • For other R2RML natural RDF literal representation of the column value as defined in points 1-3 in R2RML section 10.2 Natural Mapping of SQL Values.
>>> ]] (note the added "points 1-3 in" text).
>> 
>> See above.
>> 
>> Many commenters stated that DM and R2RML should use the *same* mapping and should *not* have random exceptions in weird corner cases. I made an LC comment to that effect. We have a WG resolution that supports this. The WG has spent a *lot* of time crafting a compromise design that makes sense both for R2RML and for the DM and that was – at least at that time – acceptable to everyone. I'd rather not re-open this can of worms.
>> 
>> So can we please stick to the original plan for the DM?
>> 
>> [[
>> 1. when creating literals, use the “natural RDF literal” corresponding to the SQL data value
>> http://www.w3.org/2001/sw/rdb2rdf/r2rml/#dfn-natural-rdf-literal
>> 2. when creating IRIs, use the “canonical RDF lexical form” corresponding to the SQL data value
>> http://www.w3.org/2001/sw/rdb2rdf/r2rml/#dfn-canonical-rdf-lexical-form
>> 3. perhaps add an informative link to this section:
>> http://www.w3.org/2001/sw/rdb2rdf/r2rml/#xsd-summary
>> 4. suggest any editorial changes to section 10 that make integration with the DM smoother or otherwise improve the section
> 
> Yep, I'm making editoral proposals.
> 
> 
>> ]]
>> http://www.w3.org/2001/sw/rdb2rdf/track/actions/174
>> 
>> Thanks,
>> Richard
>> 
>> 
>>> 
>>> -- 
>>> -ericP
>>> 
>> 
> 
> -- 
> -ericP

Received on Wednesday, 11 January 2012 16:32:23 UTC