Re: definition of natural mapping

Eric and me had a quick chat to try to resolve this, and it looks like we have found a workable compromise.

Section 10.2
http://www.w3.org/2001/sw/rdb2rdf/r2rml/#natural-mapping

There is a Note that begins “R2RML processor implementations that handle vendor-specific types…”

We will add one more sentence to the end of this Note (plus some wording tweaks). It will then read:

[[
Note: R2RML extensions 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. Note however that future versions of R2RML may also normatively add additional rows to this table.
]]

This makes clear that R2RML extensions for vendor-specific types are encouraged, but will always be at risk of being overridden by normative rules for these types in future R2RML versions. Eric's concern was that we should state this explicitly, to prevent a situation where legacy implementations become blockers to future changes.

There may be some additional editorial changes along the lines suggested by Ashok.

All the best,
Richard



On 17 Jan 2012, at 16:17, Richard Cyganiak wrote:

> Eric,
> 
> On 12 Jan 2012, at 19:23, Eric Prud'hommeaux wrote:
>>> The spec also has an informative note that explicitly encourages going beyond this normatively defined behaviour by producing the first variant instead. That would be an R2RML extension. I think all bases are covered…
>> 
>> I can't confidently read that as "instead".
> 
> Yes you can confidently read it as “instead”.
> 
> [[
> 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.
> ]]
> 
> The effect of adding additional rows into the table, as recommended in the Note, is to produce a custom literal *instead* of the plain literal. This is intentional.
> 
>> Plus, it's informative text which is supposed to override the normative point 4 of the definition of a natural RDF literal.
> 
> No. It's informative text that deals with a situation that is not normatively handled. Remember, the normative text does not apply to anything outside of Core SQL 2008.
> 
> The informative text also does not override point #4. Instead, it recommends *extending* the table in §10.2. Again, the table (like the rest of R2RML) is not normative for databases that contain vendor types.
> 
>> I propose that the following achieves the desired effect:
> 
> I don't think so, see below.
> 
>> move point 4 into the "vendor-specific types" note just below (and remove the R2RML-specific clause):
>> [[
>> *Note* The natural rdf literal is defined for SQL 2008 datatypes. The natural rdf literal may-or-should be extended to map vendor-specific datatypes to RDF 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. If there is no appropriate datatype, the value may be <a href="#dfn-cast-to-string">cast to string</a> and expressed as an <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#dfn-plain-literal">RDF plain literal</a>. Future versions of this specification may define mappings for vendor-specific datatypes or datatypes added to the SQL specification.
>> ]]
>> modify the forward reference in §10.1 ¶2 to say
>> [[
>> INTERVAL, Vendor-specific types and types added to future SQL specifications may-or-should be mapped to RDF with extensions to the mapping to natural rdf literal.
>> ]].
> 
> The wording “if there is no appropriate datatype” makes this significantly different. There *is* an appropriate RDF datatype for mapping a vendor-specific SQL datatype that contains XML. Nevertheless, an R2RML extension that decides not to include handling for this vendor-specific type should produce plain literals.
> 
> I don't understand your motivation. Nothing in your proposal changes normative behaviour. If you're seeking a purely editorial change, then please explain the misunderstanding that could be caused by the current wording.
> 
> The speculation about future SQL versions or R2RML versions is unnecessary – you simply say that future R2RML versions may define stuff that is currently undefined in R2RML 1.0. That's redundant because it's trivially true.
> 
>> I expect there to be a discussion about whether may-or-should should be may or should, but let's see if we can first agree on the structure. Since this is not normative, the may or must should not be written as RFC2119 keywords.
>> 
>> I've mocked this up with "should" in <http://www.w3.org/2012/01/§10>.
>> 
>>>>> However, where implementations have no knowledge what an “appropriate mapping” might be for a given type, they should map it to a plain literal – that's the right approach both in DM and R2RML, and it is important that this is explicitly stated.
>>>> 
>>>> I support the intent, so long as we don't have to support a legacy which prevents us from standardizing these types in the future. 
>>> 
>>> Well, at that point you'll have to support the legacy anyways. Implementers will implement *some* behaviour for these types, no matter if we leave the behaviour undefined in the spec now or define a fallback behaviour.
>> 
>> There's a substantial difference between a legacy which was in a spec and a legacy which derives from people extending the spec.
> 
> How is that relevant here? There is no behaviour of vendor types defined in the R2RML spec. It is defined for Core SQL 2008 types only.
> 
>> The SPARQL charter mandated backward compatibility with SPARQL 1.0. The current SPARQL LC is incompatible with vendor-specific extensions to 1.0 around e.g. aggregates, comma-separated SELECTs, BINDs, LETs etc. Being explicit about what's standard and what's a good idea is good for future extensibility and good for consumers who need to know what they can count on and what may change.
> 
> The spec as written *is* explicit about what's standard and what's a good idea. The standard only covers Core SQL 2008 types. Repeating:
> 
> [[
> This specification defines R2RML for databases that conform to Core SQL 2008, as defined in ISO/IEC 9075-1:2008 [SQL1] and ISO/IEC 9075-2:2008 [SQL2].
> ]]
> 
> By analogy: <foo> is not a valid HTML element, but nonetheless the spec says how to handle documents that contain it (treat it like <span> basically). That's a Good Thing, even if you may argue that this creates legacy that might make future addition of a <foo> element harder.
> 
> Richard

Received on Tuesday, 17 January 2012 17:05:42 UTC