SQL to RDF Mapping: Open-Source Tools & Workflow Guide

Updated October 2026

SQL to RDF mapping turns relational tables into RDF triples using declarative rules. The W3C standard for those rules is R2RML, and its superset RML extends them to files and APIs. In 2026 the actively maintained open-source tools are Ontop for virtual SPARQL endpoints and Morph-KGC, RMLMapper, and SDM-RDFizer for building materialized graphs.

What is SQL to RDF mapping?

SQL to RDF mapping is a rule file that tells software how each row becomes a set of triples. A rule names the source table or query, builds an IRI for each row, assigns a class, and turns columns into properties. Foreign keys become links between entities. The output can be queried with SPARQL, merged with other graphs, and checked against an ontology.

The reason teams do this is meaning. A database knows that customer_id points at another table. It does not know whether that link means ownership, billing, or support history. An RDF graph shaped by an ontology states that explicitly, which matters when several systems each have their own idea of a customer. For a deeper look at the two graph models, see RDF vs labeled property graphs.

Which standard should you use, R2RML, Direct Mapping, or RML?

Use R2RML for relational sources, RML when files or APIs join the picture, and Direct Mapping only as a first draft. All three produce RDF, but they differ in control and scope.

R2RML became a W3C Recommendation in September 2012. Its building block is the triples map, which turns each row of a logical table into zero or more triples. A logical table can be a base table, a view, or an R2RML view defined by rr:sqlQuery. Join conditions link a child column to a parent column, which is how foreign keys become relationships.

The Direct Mapping was published the same day. It generates triples automatically from table and column names, with no configuration. That makes it a useful baseline, but the vocabulary it produces mirrors your schema rather than your business.

RML-Core defines itself as a superset of R2RML that adds other structured formats. It follows the same syntax, so RML mappings are still RDF graphs. Its latest version is a Draft Community Group Report from March 16, 2026, which means it sits outside the W3C standards track. YARRRML is a YAML representation of those rules that a parser converts to RML before execution.

Which open-source SQL to RDF tools are current in 2026?

Ontop, Morph-KGC, RMLMapper, and SDM-RDFizer are the actively maintained choices, and D2RQ should be retired. Each tool below gets one real strength and one documented limit.

Ontop

Ontop translates SPARQL queries over a virtual knowledge graph into SQL that runs on the source database. It reads R2RML or its own shorter mapping format, and it supports RDFS and OWL 2 QL ontologies. Version 5.5.0 shipped on February 14, 2026 under Apache 2.0.

Its strength is database coverage. The guide lists PostgreSQL, MySQL, SQL Server, Oracle, Snowflake, Databricks, BigQuery, Redshift, and DuckDB, plus federators such as Trino and Dremio. The limit is that virtual queries inherit the source database's performance. In March 2026 Digital Science acquired Ontopic, the Ontop company, to pair it with metaphactory. The release did not address the open-source roadmap.

Morph-KGC

Morph-KGC is a Python engine built on pandas that materializes RDF from many sources. It reads R2RML, RML, YARRRML, RML-star, and RML-FNML functions. Sources include MySQL, PostgreSQL, Oracle, SQL Server, SQLite, CSV, Parquet, JSON, XML, and Snowflake, which arrived in release 2.10.0.

Its strength is fit with Python data stacks, since it integrates with RDFLib and Oxigraph. The limit is that it builds graphs rather than serving queries, so you still need a triple store for SPARQL.

RMLMapper and YARRRML

RMLMapper is the Java engine from the team behind RML. It reads databases, CSV, Excel, JSON, XML, SPARQL endpoints, and web APIs, and writes formats such as Turtle, JSON-LD, and HDT. Release v8.1.0 requires Java 21 or newer.

Its strength is broad spec coverage, which makes it a good place to check how a mapping should behave. The documented limit is memory. The README warns that it loads all data in memory, so large tables need a different engine or batching.

SDM-RDFizer

SDM-RDFizer is a Python RML interpreter from TIB built for large graphs. Version 4 added a planning module that orders triples maps and a compression operator that cuts memory use. It reads CSV, JSON, XML, and relational databases under Apache 2.0.

Its strength is scale, with deployments in EU research projects producing billions of triples. The limit is scope, since it executes RML only and has no R2RML or YARRRML front end of its own.

Virtuoso Open Source

Virtuoso Open Source is a multi-model database and SPARQL server licensed under GPLv2. It can expose SQL tables as RDF through Linked Data Views or load triples directly.

Its strength is that one server handles both virtual views and stored triples. The limit is that R2RML is translated into Virtuoso's own view syntax, so debugging happens in a vendor-specific layer.

D2RQ

D2RQ pioneered virtual RDF access to SQL databases and still appears in many tutorials. Its repository was archived on January 3, 2021 and is read-only. Migrate existing D2RQ setups to Ontop, which covers the same pattern with current database drivers.

Commercial options built on the same ideas

GraphDB virtualization embeds Ontop and accepts R2RML or Ontop mappings. Stardog virtual graphs rewrite SPARQL into SQL using its own mapping syntax or R2RML, and can import a virtual graph into local storage. For a full ranking of graph platforms, see the knowledge graph platforms guide.

How do you map SQL tables to RDF step by step?

Profile the schema, pick or design the ontology, write a mapping, validate it, then choose how to serve it. The six steps below work with any R2RML or RML engine.

Step 1. Profile the schema

List the tables that hold real business entities, the junction tables that implement many to many links, and the lookup tables that hold codes. Note which keys are stable business identifiers, such as an email or SKU, and which are surrogate IDs. Check nullable columns and orphaned foreign keys, because both change what your mapping must handle.

Step 2. Generate a baseline

Run an automatic mapping to see the raw shape. Ontop's bootstrap command generates a mapping and ontology from a database schema, following the same idea as the W3C Direct Mapping. Treat the output as an inventory, not a design. Table names like cust_addr_xref are not concepts anyone should query.

Step 3. Design the target ontology

Decide which classes and properties the graph should expose. Reuse existing vocabularies such as schema.org where they fit, and define your own classes where they do not. This step is where business meaning is settled, such as whether a prospect counts as a customer. Our guide on ontology mapping covers aligning several vocabularies.

Step 4. Write the mapping

Each table becomes a triples map with a subject template, a class, and predicate object maps. Here is a corrected R2RML example for a customers table and the orders that reference it.

@prefix rr: <http://www.w3.org/ns/r2rml#> .
@prefix schema: <https://schema.org/> .
@prefix ex: <http://example.com/mapping#> .

ex:CustomerMap a rr:TriplesMap ;
  rr:logicalTable [ rr:tableName "customers" ] ;
  rr:subjectMap [
    rr:template "http://example.com/customer/{id}" ;
    rr:class schema:Person
  ] ;
  rr:predicateObjectMap [
    rr:predicate schema:email ;
    rr:objectMap [ rr:column "email" ]
  ] .

ex:OrderMap a rr:TriplesMap ;
  rr:logicalTable [ rr:tableName "orders" ] ;
  rr:subjectMap [
    rr:template "http://example.com/order/{id}" ;
    rr:class schema:Order
  ] ;
  rr:predicateObjectMap [
    rr:predicate schema:customer ;
    rr:objectMap [
      rr:parentTriplesMap ex:CustomerMap ;
      rr:joinCondition [ rr:child "customer_id" ; rr:parent "id" ]
    ]
  ]

@prefix rr: <http://www.w3.org/ns/r2rml#> .
@prefix schema: <https://schema.org/> .
@prefix ex: <http://example.com/mapping#> .

ex:CustomerMap a rr:TriplesMap ;
  rr:logicalTable [ rr:tableName "customers" ] ;
  rr:subjectMap [
    rr:template "http://example.com/customer/{id}" ;
    rr:class schema:Person
  ] ;
  rr:predicateObjectMap [
    rr:predicate schema:email ;
    rr:objectMap [ rr:column "email" ]
  ] .

ex:OrderMap a rr:TriplesMap ;
  rr:logicalTable [ rr:tableName "orders" ] ;
  rr:subjectMap [
    rr:template "http://example.com/order/{id}" ;
    rr:class schema:Order
  ] ;
  rr:predicateObjectMap [
    rr:predicate schema:customer ;
    rr:objectMap [
      rr:parentTriplesMap ex:CustomerMap ;
      rr:joinCondition [ rr:child "customer_id" ; rr:parent "id" ]
    ]
  ]

@prefix rr: <http://www.w3.org/ns/r2rml#> .
@prefix schema: <https://schema.org/> .
@prefix ex: <http://example.com/mapping#> .

ex:CustomerMap a rr:TriplesMap ;
  rr:logicalTable [ rr:tableName "customers" ] ;
  rr:subjectMap [
    rr:template "http://example.com/customer/{id}" ;
    rr:class schema:Person
  ] ;
  rr:predicateObjectMap [
    rr:predicate schema:email ;
    rr:objectMap [ rr:column "email" ]
  ] .

ex:OrderMap a rr:TriplesMap ;
  rr:logicalTable [ rr:tableName "orders" ] ;
  rr:subjectMap [
    rr:template "http://example.com/order/{id}" ;
    rr:class schema:Order
  ] ;
  rr:predicateObjectMap [
    rr:predicate schema:customer ;
    rr:objectMap [
      rr:parentTriplesMap ex:CustomerMap ;
      rr:joinCondition [ rr:child "customer_id" ; rr:parent "id" ]
    ]
  ]

If you prefer YAML, write the same rules in YARRRML and convert them. If you use Ontop, its native format is shorter, and the CLI converts between it and R2RML in both directions.

Step 5. Validate the output

Materialize a sample and run SHACL shapes against it, such as every order having exactly one customer. Then compare SPARQL counts with the equivalent SQL. A mismatch usually means a join condition is wrong or nulls are being dropped. The Direct Mapping spec itself omits triples for NULL values, so decide on purpose how your mapping treats them.

Step 6. Choose how to serve it

Serve the mapping through a virtual endpoint, materialize it into a triple store, or do both. The next section covers that choice.

Should you virtualize or materialize the graph?

Virtualize for freshness and governance, materialize for traversal speed and reasoning. Most production setups use both, with core entities materialized and long-tail tables left virtual.

GraphDB's documentation is direct about the trade. Its virtual repositories are read-only, and they cannot efficiently run inference or graph traversals. Stardog's docs make the same point from the other side. Materialized data is indexed locally, so it queries faster but may lag when sources change often.

A common pattern is to start virtual while the ontology settles, then materialize the parts people traverse most. Keep the mapping as the single definition of truth for both paths. Moving data into the warehouse first, then mapping from there, also reduces load on production databases.

Which mapping patterns come up most often?

Foreign keys, junction tables, lookup codes, and overloaded columns account for most real mapping work. Each has a standard answer.

Junction tables with extra columns, such as purchase date or quantity, need a decision. You can model the link as its own entity, like a Purchase node. Or you can use statements about statements, which RDF 1.2 formalizes and which reached Candidate Recommendation in April 2026. Morph-KGC already supports RML-star for this. See RDF-star and beyond for the modeling options.

Who should own the mapping and the ontology?

Your company should own both, in open formats, on infrastructure it controls. The mapping and ontology encode what your data means, which is institutional knowledge. R2RML, RML, OWL, and SHACL are all open, so nothing forces that knowledge into one vendor's format.

The hard part is rarely syntax. It is agreeing on definitions, resolving duplicate entities across systems, and keeping mappings current as schemas change. Teams that treat mappings as code, with version control, tests, and review, keep them working. This foundation also improves AI answers, as covered in how ontology powers AI analytics.

Some teams build this with a partner on their existing stack. Galaxy is one such partner, using internal tooling that speeds up ontology, mapping, and entity resolution work. It builds in the open, starting with Filament by Galaxy, and plans to open source more of that tooling.

Frequently asked questions

What is SQL to RDF mapping?

SQL to RDF mapping is a set of declarative rules that turn rows and columns in a relational database into RDF triples. Each rule says how to build an IRI for a row, which class the row belongs to, and which columns become properties. The W3C standard for writing these rules is R2RML, published as a Recommendation in 2012.

What is the difference between R2RML and RML?

R2RML is the W3C Recommendation for mapping relational databases to RDF. RML is a superset of R2RML, maintained by a W3C Community Group, that adds CSV, JSON, XML, and other sources. RML uses the same syntax, so most R2RML mappings carry over. RML-Core is still a Draft Community Group Report rather than a W3C standard.

Is D2RQ still maintained?

No. The D2RQ GitHub repository was archived in January 2021 and is now read-only, so it receives no fixes or new database drivers. It still appears in older tutorials because it was an early, popular tool. For new projects, Ontop covers the same virtual RDF use case with active releases and standard R2RML support.

Which open-source tool should I use for SQL to RDF?

Use Ontop when you want a live SPARQL endpoint over SQL without copying data. Use Morph-KGC when you want to materialize a large graph from SQL and files with a Python workflow. Use RMLMapper when you need the RML reference behavior across many formats and your data fits in memory. Many teams use two of them.

Should I virtualize or materialize my RDF graph?

Virtualize when data changes often, is very large, or must stay in the source database for governance reasons. Materialize when you need fast graph traversals, reasoning, or joins across many sources. GraphDB documents that its virtual repositories are read-only and cannot efficiently run inference or graph traversals, which is the main cost of the virtual approach.

Can I generate R2RML mappings automatically?

Yes, as a starting point. The W3C Direct Mapping turns tables into classes and columns into properties with no configuration. Ontop has a bootstrap command that generates a mapping and ontology from a schema, and Stardog can auto-generate mappings for databases like PostgreSQL. Expect to rewrite most of the output to match your real ontology.

Do SQL to RDF tools support Snowflake and BigQuery?

Ontop lists Snowflake, Databricks, Google BigQuery, AWS Redshift, and DuckDB among its supported systems, alongside federators like Trino and Dremio. Morph-KGC added Snowflake support and also reads relational databases, Parquet, and JSON. Check each tool's current docs before committing, because warehouse support changes faster than the core mapping standards do.

Does SQL to RDF mapping need an ontology?

You can run a mapping without one, but the output will mirror your table names rather than your business. An ontology defines the classes and properties the mapping should target, such as Customer and placedOrder. Without it, two systems with a customers table produce two unrelated sets of triples that still need reconciling later.

How do I validate the RDF produced by a mapping?

Write SHACL shapes that describe what valid data looks like, such as every order having exactly one customer. Run them against a materialized sample after each mapping change. Then compare SPARQL results with the equivalent SQL query, for example counting customers with orders both ways. Mismatches usually point to join conditions or null handling.

What changed in SQL to RDF tooling in 2026?

Ontop 5.5.0 shipped in February 2026, and Digital Science acquired Ontopic, the company behind Ontop, in March 2026. The RML-Core specification received a new Community Group draft in March 2026. RDF 1.2, which formalizes statements about statements, reached W3C Candidate Recommendation in April 2026.