d2rq/d2rq — Issue #110: Named graphs
Author: cygri
Created: 2012-03-06 23:39:25+00:00
State: open
Labels: expressivity, integration, priority, R2RML

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.