Introduction

During the past decade, RML was proposed as an extension to the W3C's R2RML Recommendation for supporting heterogeneous data sources. On its own, RML has been revised by the KG-Construct W3C Community Group.

Nowadays, multiple flavours of [R2]RML exist: W3C's Recommended R2RML specification [1] (R2RML), the RML specification initiated by Dimou [2] (RML io ) and maintained throughout the years on https://rml.io (RML io , v1.1.2 1 ), and a new major revision [3] (RML KGC ), maintained by the W3C Community Group on Knowledge Graph Construction (RML KGC , by KG-Construct). Not all flavours are supported by existing RML engines [4] such as SDM-RDFizer [5], Morph-KGC [6], RMLMapper [7], RMLStreamer [8].

Users with existing RML mappings are limited in the RML engines they can use, since no engine supports all [R2]RML flavours. RML KGC can represent all elements present in R2RML and RML io through translation because each specification is backwards compatible with each other. However, no engine takes advantage of this backwards compatibility to represent the other flavours as RML KGC . Therefore, users must translate all their existing mappings first if they want to use a different engine which supports a newer flavour. Moreover, we do not want to deprecate support for R2RML and RML io flavours in our existing mapping engine RMLMapper2 when adding support for RML KGC . We overcome this problem in RMLMapper by translating all three [R2]RML flavours into RML KGC [3]. By applying our translation, RMLMapper can now read any RML mapping without requiring the user to change them, written in R2RML, RML io , and RML KGC .

Thanks to our translation in RMLMapper, users can still run their existing [R2]RML mappings while the Knowledge Graph Construction community can work towards the standardization of RML as a W3C Recommendation in the future.

Approach

In this Section, we show our translation for R2RML and RML io into RML KGC . This translation is implemented in RMLMapper and automatically applied without any intervention of the user. Therefore, the user does not have to migrate existing [R2]RML mappings into RML KGC immediately.

Translation

We compare the different [R2]RML flavours among each other to establish a translation path towards RML KGC . Tables 1 & 2 list all required translations to translate R2RML and RML io into RML KGC . The biggest translations rely on the removal of R2RML Logical Table in favor of RML KGC Logical Source, the ontology prefixes which are different between flavours, and the access descriptions for data sources. In this work, we cover the RML KGC Core which focus on RDF generation with RML Triples Maps and parts of the RML KGC IO modules used for accessing data sources and targets in RML because they overlap with the R2RML and RML io flavours. Translation is required to avoid implementing all flavours separately in engines such as RMLMapper. In the future, we will expand our work to the other RML KGC modules.

Prefixes Every [R2]RML flavour has its own prefix which allows us to recognize which flavour of [R2]RML was used to create the mapping. Since most of the terms in the ontologies are similar to each other, we translate the prefixes of R2RML and RML io into RML KGC by replacing them with the new prefix. However, some changes in RML KGC require additional transformations which we describe in the next paragraphs.

Literals in rml:source RML io mappings consistently use Literals in the RML io Logical Source's rml:source to describe the path to a file which is used in the mapping as data source. This approach was deprecated in 2015 [9] and replaced by access descriptions such as DCAT [10], SD [11], or D2RQ [12] to access heterogeneous data sources, e.g. files, SPARQL services, or databases. RML KGC drops this deprecated option which requires a transformation when a mapping still uses Literals for rml:source. If we encounter such a case, we replace it by a DCAT access description. If the path to the file is a relative path, we cannot use DCAT since there is no base IRI available to resolve the relative path against. To overcome this problem, an RML KGC Relative Path Source was introduced to handle this case 3 .

rml:query The RML io specification 4 does not indicate how queries must be specified in the case of relational databases or SPARQL services. Over the past decade, an unofficial predicate rml:query was used to address this problem. This way, queries could be specified in the RML io mapping to access such sources. The W3C Community Group on Knowledge Graph Construction incorporated the query property in the iterator, but there is still discussion around this approach 5 . In this work, we do perform this transformation and add the necessary access descriptions for the relational database or SPARQL service if needed.

rr:tableName & rr:LogicalTable R2RML Logical Table and rr:tableName shortcut must be translated completely into RML KGC Logical Source since a Logical Source is an expansion of an R2RML Logical Table . We perform this transformation by moving the query from R2RML

Logical Table into the iterator and adding the access description of the database using the D2RQ ontology 6 . The reference formulation is set to rml:SQL2008Table. For rr:tableName, we also add the access description using the D2RQ ontology, and place the table name as well in the iterator. However, the reference formulation is set to rml:SQL2008Table, allowing RML engines to detect that they receive a table name instead of a SQL query.

Implementation in RMLMapper

Our translation is applied when RMLMapper parses the [R2]RML mappings. Each part of the [R2]RML mapping which is not using RML KGC , is translated internally. This way, the RMLMapper operates on [R2]RML mappings based on the latest RML KGC version. Only for R2RML, the database details needs to be supplied by the user as R2RML does not include the database access information in its mappings. Our implementation in the RMLMapper is written in Java, released as v7.0.0, and available on GitHub7 under the MIT license.

Evaluation

In Star (18 test cases). Each module provides a set of test cases to evaluate the compliance of engines with the specification provided by the module. RML KGC Core has the most test cases because it contains the core functionality for generating RDF using RML KGC mappings, followed by RML KGC IO which focus on accessing various data sources and targets used in RML KGC mappings. The other modules have lower number of test cases, thus engines supporting RML KGC Core and RML KGC IO already have a high coverage of the new RML KGC flavour. We calculate the coverage of each module by dividing the number of passing test cases by the number of test cases per module. The Knowledge Graph Construction W3C Community Group does not provide a detailed description for each test case yet, but it is planned for the future.

Table 3 shows the coverage of RMLMapper with all [R2]RML test cases with and without our approach. Without our translation approach, RMLMapper achieves 0% coverage on the RML KGC test cases of the KGCW Challenge. RMLMapper passes 100% of the R2RML and RML io test cases. We achieve 98,70% coverage for RML KGC Core and 50,75% coverage for RML KGC IO. RML KGC Core has a few test cases where RMLMapper fails to provide the correct output: For

Conclusion

In this paper, we showed our approach for translating R2RML and RML io into the latest RML KGC and evaluated it on the RML KGC test cases. Thanks to our work, users can still execute their existing RML mappings while the community works towards a standardization of RML KGC as a W3C Recommendation. In the future, we aim to support more RML KGC modules besides RML KGC Core and IO, and perform an evaluation of the translation itself since we focus in this work on participating in the KGCW Challenge which only evaluate the generated RDF of each engine.