Post-CR Changes to R2RML

This page lists changes to R2RML that were made for its publication as a 2nd Last Call based on implementation feedback received after its publication as a Candidate Recommendation.

Diff

A color-coded diff of these changes is available.

Normative changes

Here we list changes that modify normative behaviour of implementations. Implementations may have to change.

Map to xsd:hexBinary instead of xsd:base64Binary

Section: 10.2 Natural Mapping of SQL Values, 10.5 Summary of XSD Lexical Forms (Informative)

Binary SQL data values (of datatypes BINARY, VARBINARY and BLOB) were mapped to xsd:base64Binary. This has been changed to xsd:hexBinary because of the better support for manipulation of hexadecimal strings in the SQL standard and popular SQL implementations.

Allow unnamed columns in SELECT clause

Section: 5.2 R2RML Views

In the definition of SQL query, unnamed columns in the SELECT clause (that is, the result of projecting an expression without assigning an identifier) were treated as an error. Now they are merely discouraged: “Any columns in the SELECT list derived by projecting an expression should be named, because otherwise they cannot be reliably referenced in the rest of the mapping.”

Define “R2RML default mapping generators”

Section: 4.4 Default Mappings

The Working Group planned to use the RDB2RDF Direct Mapping as a “default mapping” for R2RML. It turns out that the Direct Mapping as defined cannot be expressed in R2RML in certain corner cases (due to potential cardinality issues in tables that don't have primary keys and do have duplicate rows). In order to explicitly document these corner cases, a section that defines the notion of a “default mapping” and an “R2RML default mapping generator”. Support for this is entirely optional in implementations.

Editorial clarifications to normative sections

Here we list changes that are not intended to modify normative behaviour, but to clarify what the normative behaviour is. Implementations should verify that their interpretation of the specification matched the intent.

Clarify that an arbitrary mapping can exist between term map values and blank nodes

Section: 11 The Output Dataset

The wording in the clause on blank nodes in the term generation rules has been slightly changed, and an explanatory note has been added, to clarify that implementations can (and may in fact have to) define an arbitrary mapping between the values generated by a term map and the generated blank node identifier in the case that blank nodes are generated.

Clarify effect of %-encoding on safety of separators in rr:template

Section: 7.3 From a Template

The definition of string template states that pairs of curlies should be separated by a character or string that cannot occur in any of the values of either column. This concept is now explicitly defined as a “safe separator”, and the wording has been changed to make clear that percent-encoding has an effect on the safety of separators when IRIs are generated. An informative note has been added to point out that IRI sub-delimiters are always safe separators.

Non-normative changes

Here we list changes to purely informative sections, examples, etc.

Examples for IRI-safe percent-encoding

Section: 7.3 From Template

A table of examples for IRI-safe versions of strings was added to aid implementers.