Allow mapping of the database to an entire SPARQL dataset including named graphs, instead of just to a single virtual RDF graph. This is an important stepping stone towards R2RML support, since that language supports named graphs.
A possible approach in the D2RQ language would be the addition of two new properties, d2rq:graph and d2rq:graphMap.
d2rq:graph takes an URI as value, and if applied to a property bridge, puts all generated triples into that named graph. If applied to a class map, all property bridges belonging to that class map inherit the value (including the triples generated for d2rq:class).
d2rq:graphMap is a full-blown resource map that produces URIs and can use d2rq:uriPattern, d2rq:condition, d2rq:translateWith and so on.
We might need a “magic” graph URI d2rq:DefaultGraph that indicates the default graph. If no URI is produced (e.g., some value was NULL), then no triple is produced at all. This behaviour would match R2RML.
Internally, this would imply that TripleRelation effectively becomes a QuadRelation, where the fourth element defaults to a FixedNodeMaker with value d2rq:DefaultGraph.
Then, OpGraph in the ARQ-based query engine needs to be properly implemented, which may require quite some head-scratching.
There would be a follow-on opportunity to make graphs that lie inside D2R Server's URI space resolvable, and thus use the feature to create custom RDF documents that contain custom subsets of the database, but that should be a separate issue.
This is the biggest remaining blocker for being able to claim full R2RML compatibility.