Data Integration/Exchange (DI/DE) has seen great developments both in the Databases (DB) and the Semantic Web (SW) areas. ForBackBench has been the first framework that facilitates the comparison of systems from both areas by introducing datasets, converters and algorithms that allow for integration and interaction of diferent query rewriting (OBDA) and forward-chaining (Chase) systems. In this paper, we discuss the most recent developments of the framework, which aim to completely bridge the gap between the DB and SW areas in DI/DE field by integrating RML (and R2RML) ontology materialisation systems. To facilitate translations between mapping languages (R2RML, RML, OBDA) and tuple-generating dependencies (TGDs), we introduce a special language of source-to-source TGDs with built-in functions. We integrate state-of-the-art ontology materialisation systems from SW as well as datasets and scenarios from that area. Our initial experimental results already shed light on the interaction of these areas and the properties of diferent algorithms and systems, exhibiting the merits of our framework.
CEUR ceur-ws.org
Recent years have seen an increase in the demand of systems for data integration and exchange
(DI/DE), a problem extensively studied in the both the Databases (DB) and the Semantic Web
(SW) areas and invaluable for a variety of domains, including biological research, industry, data
marketplaces, and others [
In our previous work [
Although the backward-chaining systems included as part of ForBackBench came mostly from the Ontology-Based Data Access (OBDA) area of SW, the forward-chaining systems came from the state-of-the-art data exchange technologies in the DB domain. In this paper, we close the loop by integrating in ForBackBench state-of-the-art ontology materialisation engines from the SW domain. This brings us a step closer to realising our vision of bridging the gap between the DB and SW areas in DI/DE. Our contributions include the following: • We present end-to-end translation algorithms and implementation between the most common SW mapping languages (OBDA mappings, R2RML, and RML) and TGDs. • We integrate three state-of-the-art ontology materialisation systems into ForBackBench:
Morph-KGC [
To the best of our knowledge, this is the first framework that includes all relevant scenarios, systems and algorithms, paving the way for a versatile platform where one can plug diferent systems to produce a customised end-to-end solution for a DI/DE task.
As part of our extension of the ForBackBench Framework, we aimed to include forward-chaining
systems from the SW community, and to provide complete translation between forward- and
backward-chaining formats. Therefore, we extended the functionality of the Data/Mapping
Generator component that we introduced in [
The problem of SW mapping translation was first introduced in [
Definition 1. For all TGDs of at most arity two, is a Skolem source-to-source TGD if (1) and are over the source schema, (2) , the body, is an SQL query , (3) , the head, is a ChaseBench query, where , the arguments, are concatenation functions of multiple columns of source tables.
For ontology materialisation scenarios we implement two phases: the ofline phase, where we convert OBDA, RML, or R2RML mappings to TGDs (see Example 1) and the online phase, where we generate and load data for the new source tables. The choice of supported mapping languages was guided by the current scope of our framework, which is mostly limited to relational DBs. In the future we aim to support more non-relational mapping languages.
TGDs to Mappings Translation. For each source-to-target (st) TGD mapping (we assume/transform TGDs to have a single head atom), we define a triple map (, , , ) where the TGD head atom translates (via the natural way) into , , and is a generated SQL query reflecting the TGD body. Every mapping language (OBDA mappings, R2RML, or RML) contains a “target” that can be constructed from , , and a logical source in SQL or CSV. Thus we appropriately translate our triple map to a chosen language. We can also support translating back to a mapping language from a scenario that includes both st-TGDs as well as our own Skolem ss-TGDs (thus reverting Example 1), in which case the SQL query is obtained from the Skolem ss-TGDs (since it appears explicitly). If we have Skolem ss-TGDs, we use the namespaces contained in them; otherwise, we invent an example namespace for the final mapping.
Example 1.
OBDA Mapping: mappingId Mapping00643 target ns:employee/{ } /name/{ } source SELECT . as eID, . INNER JOIN ON . = . Translated TGDs:
Σ = { SELECT . INNER JOIN _ Σ = { _
as eID, .
ON . = . → _ _00643( :/ {eID}// {eName}, :/ _ _00643(? , ? ) → (? , ? ).} ns:EmpInfo ns:dept/{ }
as eName, . as eName, . {dName})}
as dName FROM as dName FROM
We are benchmarking materialization systems from DB (RDFox, Rulewerk), materialization systems from SW (Morph-KGC, RMLMapper, and SDM-RDFizer), and query rewriting systems (Rapid, Iqaros, and Ontop). Note that Ontop has two versions: (OntopR2RML) with R2RML mappings and (Ontop) with its native mapping language (i.e., OBDA mappings). Each system and query was run a total of six times, with the first being a ‘cold-run’. We compare loading and chasing (generation of RDF graphs) times for forward-chaining, with loading, rewriting, and unfolding times (the unfolding time includes the conversion of the query to a valid SQL query) for backward-chaining. For DB systems we also include query execution times. All experiments were run on a MacBook Pro M1 chip with a 2.30GHz, 8-core processor, 8GB of memory, and a total of 1TB of disk space.
The SW forward-chaining systems (SDM-RDFizer, RMLMapper, and Morph-KGC) do not have out-of-the-box query answering functionality so we do not include execution times for these; we will extend the framework by including SPARQL query answering as future work. Thus, sometimes it is meaningless to compare an ontology materialisation system with a query rewriting system (that includes execution), especially when the former is faster. Nevertheless, in the GTFS-Madrid-Bench scenario seen below, the benchmarked SW materialisation systems are all slower than query rewriting systems that include execution, which is a very interesting result, pointing out that, possibly, virtual Knowledge Graphs – that do online query answering directly from sources – have not been investigated enough.
Figure 1a shows results for the GTFS-Madrid-Bench scenario [
Figure 1b shows the results of our experiments in the OWL2Bench scenario with again a small data size. Once again, the SW systems present faster loading times but significantly slower chase times except RMLMapper which was slow in loading as well. Query-rewriting systems (Ontop, Rapid, Iqaros) appear to be the fastest in both figures, however in the experiment of Figure 1b, both Rapid and Iqaros timed out after unfolding in Q2 due to a huge rewriting size, while in Q5 Morph-KGC is faster than both. The results, although very preliminary, imply that query-rewriting might be penalised for larger/complex queries, and that forward-chaining systems from both the SW and DB areas are valuable solutions on large datasets and complex queries. We are currently running more experiments.
(a) GTFS-Madrid-Bench Scenario (b) OWL2Bench Scenario
We presented the most recent developments of the ForBackBench framework. We introduced Skolem source-to-source TGDs, as well as translations between mapping languages (R2RML, RML, OBDA) and TGDs. Finally, we integrated state-of-the-art SW ontology materialisation systems into ForBackBench and provided experimental results on a wide range of scenarios.
This work was partially funded by the UKRI Horizon Europe guarantee funding scheme for the Horizon Europe projects RAISE (101093216101058479) and UPCAST (101093216101093216).