DM+R2RML implementation feedback: DM cannot be implemented as an R2RML mapping

The Direct Mapping is defined in a way that cannot be expressed as an R2RML mapping because of the IRI character escaping rules chosen for the Direct Mapping. The consequence is that it's impossible to implement the Direct Mapping using a conforming R2RML processor. One needs a custom, non-R2RML-compliant processor, that has a special character escaping mechanism just for the DM. This is a bizarre and unnecessary situation.

Let's assume a database with a table WIDGET having a VARCHAR column called ID as primary key, and containing the value 'A.123' in a record. In the Direct Mapping, this would yield a record IRI such as:


The period '.' is encoded as %2E, as required by the definition of “percent-encode” in the Direct Mapping.

Now one might expect that one should be able to use an off-the-shelf R2RML processor to access a DM-conforming RDF view on a database. I guess one would expect that this R2RML expression yields the IRI above:

    rr:logicalTable [ rr:tableName "WIDGET" ];
    rr:subjectMap [ rr:template "WIDGET/ID-{ID}" ];

But R2RML uses the standard percent-encoding algorithm from RFC3987 (the IRI spec), which yields a different (and prettier) IRI:


This means one cannot use an off-the-shelf R2RML processor to produce a DM-compliant RDF view on the database.

The justification for the non-standard escaping mechanism in the Direct Mapping was something about being able to abbreviate more URIs as prefixed names in legacy versions of SPARQL and Turtle (it's a non-issue for the most recent drafts of these specs).

I do not believe that usability concerns only applying to old versions of these specs are more important than maintaining compatibility with RFC 3987 and between the different specs produced by this WG and hence propose that the DM uses an escaping mechanism that is compatible with R2RML and RFC 3987.


Received on Sunday, 22 April 2012 23:01:20 UTC