Re: Request for comments: Breaking down the datatype mapping problem (ISSUE-69)

Richard - My responses are inline below.

-David

On Mon, Nov 21, 2011 at 12:29 PM, Richard Cyganiak <richard@cyganiak.de>wrote:

> Hi David,
>
> A few comments, and questions for clarification, inline.
>
> On 21 Nov 2011, at 15:48, David McNeil wrote:
> >> == Should data be C14N'd before used in IRI generation? ==
> Would you say that in this situation, the value MUST be canonicalized
> while building the IRI in the DM?
>

Yes.


>
> >> == Should canonical forms be SQL canonical or XSD canonical? ==
> >
> > We do not think that R2RML needs to define canonical forms for the
> output values.
>
>  Nevertheless, I think the question still stands for the DM: Should it be
> SQL or XSD?
>

I say XSD.


>
> >> == Should unknown vendor-specific types be mapped to plain literals? ==
> >
> > It seems fine for these to be plain literals by default, but we can't
> mandate that because an implementer may provide a way to map a user defined
> type to something other than a plain literal.
>
> The current approach is to have a line in this table here:
> http://www.w3.org/2001/sw/rdb2rdf/r2rml/#natural-value-mapping
>
> [[
> Any other supported SQL datatype => (plain literal)
> ]]
>
> And right under the table it says:
>
> [[
> Note: R2RML processor implementations are expected to augment the table
> with additional rows for mapping vendor-specific datatypes to appropriate
> RDF-compatible datatypes, like the XML Schema built-in types.
> ]]
>
> Is this an acceptable phrasing?
>

I think so. Truly I would have to spend more time puzzling through the spec
to make sure I understand whether "supported SQL datatypes" includes
vendor-specific datatypes. It seems that the "additional rows" you refer to
would replace the final catch-all rule in the translation table for
specific datatypes, right?