R2RML script for Northwind database and generating RDF Linked Data Views

Virtuoso Universal Server
1

In relation to the “R2RML script for Northwind database and generating RDF Linked Data Views” example at [1], I’d appreciate if someone could explain the difference between the graph defined in [2], the target graph IRI in “R2RML Upload” and the default graph name in “R2RML Generate”?

[1] http://vos.openlinksw.com/owiki/wiki/VOS/VirtConductorR2RMLImportNorthwind
[2] http://vos.openlinksw.com/owiki/wiki/VOS/VirtConductorR2RMLImportNorthwindScript

2

difference between the graph defined in [2], the target graph IRI in “R2RML Upload” and the default graph name in “R2RML Generate”?

[1] The Named Graph into which the R2RML is loaded

[2] The Named Graph in the R2RML document is the Graph associated with Virtual Triples generated from the processing of an R2RML document.

RDF Views can be generated via a Wizard (which generates an R2RML document) or by passing an R2RML Document through a built-in Stored Procedure. Either way, the end product includes Triples associated with a Virtual Named Graph that can be optionally synchronized with Triples in a Physical Named Graph.

The Named Graph IRI in the R2RML document is the canonical Named Graph associated with the RDF Views generated from R2RML processing.

I hope this clarifies matters?

Related

3

By going though the " Example importing R2RML script for Northwind database and generating RDF Linked Data Views" ([1] in my first post) I end up with two graphs: the one defined in the R2RML Mapping Document and the one defined in the R2RML import tab:

  • The graph defined in the R2RML document contains the virtual triples
  • The second graph contains triples that seem to describe the mapping itself.

I then deleted the second graph, restart the Virtuoso server and have still the first graph available. so it seems to me the second graph is not really needed at the end of the process. Or am I missing something?

4

The graph name specified in the R2RML document (i.e., rr:graph setting) is what the Virtual Triples get loaded, as must be the case for an R2RML script/document.

The “Target Graph IRI” name specified in the Conductor is the name of the graph Virtuoso loads the R2RML TTL file into prior to the actual Virtual Triples (i.e., RDFView) being created.

Once the Virtual Triples/RDFViews are created they are stored in Virtuoso Quad Map Storage where the virtual mappings are persisted, thus you can then delete the R2RML graph describing the TTL mappings.

Looking at your report, however, I do note what seems to be a bug in the Conductor UI, and probably the source of your confusion/question, in that the “R2RML Generate” page with the “definitions” for the RDFView mapping to be generated, displays the R2RML TTL description graph name as the “Default Virtual Named Graph”, which is incorrect, as it should be the rr:graph name specified in the R2RML TTL document itself (which overrides it anyway). So will get that fixed …

5

I’m not completely sure it is a bug in the GUI, which seems to me to be very flexible, but yes it would be nice if it could read the rr:graph from the R2RML document, if available.

My experience so far with the R2RML VAD is:

Use case 1: create only transient view:

  • The rr:graph in the R2RML document overrides the “Default Virtual Named Graph”
  • an additional graph is created that describes the TTL mappping
  • If no rr:graph is available in the R2RML document, then the graph defined in “Default Virtual Named Graph” is created as virtual graph

Use case 2: Generate RDB2RDF triggers and Enable Data Syncs with Physical Quad Store check boxes selected:

  • The rr:graph in the R2RML document is created as virtual graph
  • an additional graph is created that describes the TTL mappping
  • The “Default Virtual Named Graph” is created as physical graph.

Many thanks for the support

6

Yes, that my #1 and #2 above, but I presented them in the wrong order. Thus, delete the Mappings Graph is something you can do at the end of the process if you choose. Alternatively, it is an archive of mappings that you accumulate over time that is SPARQL- and SQL-accessible like any other data in Virtuoso.

We do have an outstanding issue regarding the Conductor UI for importing R2RML documents that needs to be fixed, as per comments by @hwilliams.