Intelligenza Artificiale 13 (2019) 21–36DOI 10.3233/IA-190023IOS Press

21

Ontology-based data access – Beyondrelational sources

Elena Botoevaa, Diego Calvaneseb,∗, Benjamin Cogrelb, Julien Cormanb and Guohui Xiaob

aDepartment of Computing, Imperial College London, London, U.K.bFaculty of Computer Science, Free University of Bozen-Bolzano, Bolzano, Italy

Abstract. The database (DB) landscape has been significantly diversified during the last decade, resulting in the emergenceof a variety of non-relational (also called NoSQL) DBs, e.g., xml and json-document DBs, key-value stores, and graph DBs.To enable access to such data, we generalize the well-known ontology-based data access (OBDA) framework so as to allowfor querying arbitrary data sources using sparql. We propose an architecture for a generalized OBDA system implementingthe virtual approach. Then, to investigate feasibility of OBDA over non-relational DBs, we compare an implementation ofan OBDA system over MongoDB, a popular json-document DB, with a triple store.This article is an extended and revised version of an article that appeared in the proceedings of the 17th InternationalConference of the Italian Association for Artificial Intelligence (AI*IA) [4].

Keywords: Ontology-based data access, NoSQL, JSON, MongoDB, query optimization

1. Introduction

To cope with the requirements of a variety of mod-ern applications and their differing needs with respectto data management, in the last decade we have wit-nessed a strong diversification in the landscape ofdatabase (DB) management systems (DBMSs). Tra-ditional relational DBMSs now coexist with so-calledNoSQL (“not only” sql) DBs, which redefine the for-mat of the stored data, and how it is queried. Thesenon-relational DBs usually adopt one of four maindata models: (i) Column-oriented DBMSs maintaindata tables similarly to traditional relational DBMSs,but store such tables by column, rather than byrow. This allows for executing queries, which areexpressed in traditional query languages like sql,more efficiently for certain workloads. (ii) graphdatabases organize data in the form of elements (i.e.,the nodes) connected by various relations (i.e., the

∗Corresponding author: Diego Calvanese, Faculty of Com-puter Science, Free University of Bozen-Bolzano, Piazza Domeni-cani 3, 39100 Bolzano, Italy. E-mail: calvanese@inf.unibz.it.

edges), and are equipped with query languages basedon graph navigation, such as sparql. (iii) Key-valuestores represent data as a collection of key-valuepairs, where keys are unique in a collection andare used to access the data. (iv) Document storesorganize the data in documents, which have a hier-archical structure, are accessed via a key, and areencoded in some standard format, such as XML orjson. Typically, they offer ad-hoc, in some cases quiteexpressive querying mechanisms (e.g., the aggre-gation framework of MongoDB), or even requirewriting JavaScript functions (e.g., CouchDB1). Thiswider choice of DBMSs offers the possibility tomatch application needs more closely, allowing forinstance for more flexible data schemas, or more effi-cient (though simple) queries.

As a result, accessing data using native query lan-guages is getting more and more involved for users.In this article, we rely on the ontology-based dataaccess (OBDA) framework as a uniform solution

1http://couchdb.apache.org/

1724-8035/19/$35.00 © 2019 – IOS Press and the authors. All rights reserved

22 E. Botoeva et al. / Ontology-based data access – Beyond relational sources

to this problem. The OBDA paradigm [20, 26] hasemerged as a proposal to simplify access to relationaldata for end-users, by letting them formulate high-level queries over a conceptual representation of thedomain of interest, provided in terms of an ontology.In the classical virtual OBDA approach, data is notmaterialized at the conceptual level (which justifiesthe term “virtual”), and instead queries are translatedautomatically from the conceptual level into lower-level ones that DB engines can directly evaluate. Thetranslation exploits a declarative specification of therelationship between the ontology and the data atthe sources, provided in terms of mapping assertions.This separation of concerns between query formula-tion at the conceptual level and query execution at theDB level has proven successful in practice, notablywhen data sources have a complex structure, and end-users have domain knowledge, but not necessarilydata management expertise [1, 7, 12]. Traditionally,in OBDA, the DB is assumed to be relational, theontology is expressed in the owl 2 ql profile of theWeb Ontology Language owl 2 [17], the mapping isspecified in r2rml [9], and queries are formulated insparql, the Semantic Web query language [13].

Extending the classical OBDA setting to arbitraryDBs requires to generalize some of its components.The first contribution of this work is to present such ageneralized approach that enjoys all benefits alreadyoffered by OBDA. In particular, it allows for hid-ing from the user low-level concerns such as datastorage and direct access to data (using the nativequery language of each data source), and it providesusers with a high-level querying interface, closer toapplication needs. One could argue that OBDA iseven more valuable in the NoSQL case comparedto the relational one, as the gap between these lowand high-level concerns tends to be wider. How-ever, this extension also carries its own challenges,such as handling different data formats, the need formore advanced query optimization techniques due tolower-level query languages, or a possibly increasedneed for post-processing.

A second contribution is to investigate the appli-cability of the generalized OBDA framework in thepractically significant case where the data source isa document store that offers rich querying capabili-ties, so that it is in principle feasible to fully delegatequery answering to the source DB engine. In ourinvestigation, we focus on MongoDB, a document-based DBMS, and one of the most popular NoSQLDBMSs as of today. MongoDB can be queried viaa very expressive language, the so-called MongoDB

aggregation framework, which has a more procedu-ral flavor than sql or sparql, and therefore can becomplex to manipulate. Such a setting appears par-ticularly well-suited for exploiting the added valueoffered by the OBDA paradigm.

Document-based DBMSs can also leverage thedenormalized structure of their data: a document-based DB instance (i.e., a collection of documents)can often be seen as a denormalized version of arelational DB instance (where some joins are pre-computed). Therefore a natural question is whetherOBDA over MongoDB can take advantage of suchstructure in order to answer queries efficiently, whileat the same time offering a more user-friendly querylanguage. As a third contribution of this work, weprovide support for a positive answer. We do soby instantiating the generalized OBDA frameworkover MongoDB as an extension of the OBDA sys-tem Ontop [6], and comparing its performance witha triple store, which does not benefit from such denor-malization. We adopt the triple store Virtuoso [11],using as dataset an instance of the well-known Berlinsparql Benchmark (BSBM) [3].

The rest of the article is structured as follows.In Section 2, we recall the standard OBDA frame-work over relational data sources. In Section 3, weintroduce our proposal for generalizing OBDA toaccess arbitrary DBs, and present the architecture ofa generalized OBDA system. In Section 4, we intro-duce MongoDB, describe our extension of Ontopover MongoDB, and illustrate the generalized OBDAarchitecture with a running example. In Section 5,we evaluate the performance of this system and com-pare it to the triple store Virtuoso using BSBM asdataset. In Section 6, we discuss related work, andwe conclude the article with Section 7.

2. Ontology-based data access

We recall the traditional OBDA paradigm foraccessing relational DBs through an ontology [26].An OBDA specification is a triple P = 〈T ,M,S〉,where T is an ontology modeling the domain of inter-est in terms of classes and properties, S is a relationalDB schema, andM is a mapping consisting of a finiteset of mapping assertions. We note that here we usethe term “ontology” to denote a set of axioms involv-ing only classes and properties, but not mentioningindividuals. In other words, T consists only of theintensional part (typically called TBox) of an ontol-ogy in the sense of owl 2. This choice is motivated

E. Botoeva et al. / Ontology-based data access – Beyond relational sources 23

by the fact that in OBDA, the extensional compo-nent (typically called ABox) is provided by the DBinstance via the mappings, as illustrated below.

To define mapping assertions, we make use of(rdf) term constructors, each of which is a functionf (x1, . . . , xn) mapping a tuple of DB values to anIRI or to an rdf literal. Given a DB schema S and anontology T , a mapping assertion between S and Tis an expression of one of the forms

ϕ(x) � (f (x) rdf:type A), or

ϕ(x, x′) � (f (x) P f ′(x′)),

where A is a class name in T , P is a (data or object)property name in T , ϕ(x) and ϕ(x, x′) are arbitrary(sql) queries expressed overS, and f and f ′ are termconstructors [15, 20]. Mapping assertions allow oneto define how classes and properties in T should bepopulated with values in a DB instance of S and withobjects constructed from such values via the termconstructors.

An OBDA instance is a pair 〈P,D〉, where P =〈T ,M,S〉 is an OBDA specification and D is a DBinstance satisfying S. The semantics of 〈P,D〉 isgiven with respect to the rdf graph M(D) inducedby M and D, defined by

{(f (o) rdf:type A) | ϕ� (f (x) rdf:type A) in M}and o ∈ ans(ϕ,D)

∪{(f (o) P f ′(o′)) | ϕ� (f (x) P f ′(x′)) in M}

and (o, o′) ∈ ans(ϕ,D),

where ans(ϕ,D) denotes the result of the evaluationof ϕ over D. Then, we define a model of 〈P,D〉 tobe simply a model of T ∪ M(D), i.e., a first-orderinterpretation that satisfies all axioms in T and allfacts in M(D). We observe that M(D) provides a setof extensional facts, but such facts are typically keptvirtual, i.e., they are not actually materialized.

Queries are usually formulated in sparql, theSemantic Web query language that allows for formu-lating expressive high-level queries over an rdf graph[13, 19]. Such queries are answered over an OBDAinstance 〈P,D〉 according to the semantics of thechosen sparql entailment regime, considering T asthe ontology, andM(D) as the RDF graph. Typically,in OBDA, the ontology T is expressed in owl 2 ql,and the corresponding entailment regime is that ofowl 2 ql [14]. We denote with ansql(q, 〈P,D〉) theanswers to a sparql query q over an OBDA instance〈P,D〉 according to the owl 2 ql entailment regime.

3. Generalized OBDA framework

In this section, we introduce a generalization of theOBDA framework to arbitrary DBs, and then proposean architecture for a generalized OBDA system.

3.1. OBDA over arbitrary databases

We assume to deal with a class D of DBs, e.g.,relational DBs, xml DBs, or json stores, such asMongoDB. Moreover, we assume that D comesequipped with:

– Suitable forms of constraints, which mightexpress both information about the structure ofthe stored data, e.g., the relational schema infor-mation in relational DBs, and “constraints” in theusual sense of relational DBs, e.g., primary andforeign keys. We call a collection of such con-straints a D-schema (or simply, schema).

– A way to provide a (flat) relational viewto D-schemas and D-instances satisfying suchschemas: for a D-schema S, [[S]] is the corre-sponding relational schema, and for a D-instanceD satisfying S, [[D]] is a relational DB over [[S]].The function [[·]] is called relational wrapper.

– A native query language Q, such that, for aquery ϕ ∈ Q and for a D-instance D, the answerans(ϕ,D) to ϕ over D is defined (and is itself aD-instance).

Now, given an ontology T and a D-schema S, amapping M is a set of classical mapping assertionsϕ� h between [[S]] and T , i.e., ϕ is a sql queryover [[S]]. Then, an OBDA specification is a triple〈T ,M,S〉. This is analogous to the relational case,except that now S is a D-schema (equipped with arelational wrapper) as opposed to a relational schema.An OBDA instance consists of an OBDA specifica-tion 〈T ,M,S〉 and a D-instanceD satisfying S. Thesemantics of such an instance is derived naturallyfrom the relational instance [[D]] corresponding toD via the relational wrapper [[·]].

Note that our assumption that a relational wrapperis available for the class D of DBs is not restrictive inany way, since any form of data can be representedusing relations, independently of how it is structured.Observe also that the source query in a mapping asser-tion in our generalized setting is not a native Q query,but a sql query. Our framework has the advantage ofhaving a uniform and expressive mapping languagethat is independent of D and Q. It does not mean,however, that the concrete user mapping language

24 E. Botoeva et al. / Ontology-based data access – Beyond relational sources

Fig. 1. Query answering in OBDA.

must strictly follow this specification. When it doesnot, the system should only be able to transform usermapping assertions into classical ones.

When referring to OBDA, we typically assume thatit follows the virtual approach, in which materializingthe rdf graph is avoided, and instead (part of) queryanswering is delegated to the DB. In this approach,the query answering process can be depicted as inFig. 1, and consists of 4 main steps: (a) An inputsparql query q is first rewritten with respect to theontology T into qr (according to the semantics ofthe entailment regime, this step only rewrites thebasic graph patterns (BGPs) in q [14]). b The rewrit-ten sparql query qr is translated into one or severalnative queries ψ ∈ Q. When the DB engine does notsupport (efficiently) some sparql operators, multiplenative queries might be required, and the evaluationof the unsupported operators may be postponed to thefinal post-processing step. c The native queries ψ areevaluated by the DB engine to produce D-results rψ. dThe results rψ of all queriesψ are combined and con-verted into the sparql result rq in the post-processingstep. In the generalized OBDA framework the post-processing step may be more involved than in theclassical relational case, mostly due to the fact thatthe DB system may offer limited querying capabili-ties. In particular, some NoSQL DBs do not supportjoins. Another reason for not delegating certain queryconstructs to the DB is efficiency. For instance, in thecase of nested data (e.g., json documents contain-ing arrays), the unnesting (i.e., flattening) of nestedobjects into tuples may produce output objects thatare much larger than the input, and so it may be prefer-able to perform unnesting as a post-processing step,so as to reduce network load between DB and client.

Fig. 2. sparql to native query translation.

For the generalized OBDA framework, we proposeto translate sparql queries to native queries in twosteps (cf. Fig. 2): first translate the input sparql queryto an intermediate query, subject to transformations,and then translate the (transformed) intermediatequery to a native query. The intermediate query lan-guage, denoted iq, is expected to be a more high-levellanguage than Q, and can vary depending on Q, butalso on the considered fragment of sparql. On theone hand, it should at least capture such fragment(e.g., for BGPs, joins are sufficient, while for a frag-ment with property paths, iq should include someform of recursion). On the other hand, iq may includeother operators that are present/expressible inQ (e.g.,an unnest operator for dealing with nested data). Notethat Relational Algebra (RA) as iq is sufficient for thefirst-order fragment of sparql and for relational DBs.Our framework, relying on the use of iq, provides sev-eral advantages: (i) it offers a better support for queryoptimization, since iq, unlike sparql, can take intoaccount the structure of the data, without necessarilybeing as low-level as Q; (ii) the optimization tech-niques devised for iq are independent of Q; (iii) thetranslation from sparql to iq is standard and dependsonly on the mapping (since iq subsumes RA, such atranslation has to extend the well-known translationfrom sparql to RA).

3.2. Architecture of an OBDA system overheterogeneous data sources

We propose an architecture for an OBDA systemable to answer sparql queries over heterogeneousdata sources. This architecture, depicted in Fig. 3, iscomposed of an offline stage, independent from the

E. Botoeva et al. / Ontology-based data access – Beyond relational sources 25

Fig. 3. Proposed architecture for an OBDA system.

input sparql queries, and an online stage, dedicatedto query answering.

The offline stage consisting of steps and ,takes as input the ontology, mapping, and schema,and produces two elements, to be used during theonline stage: the classified ontology, and the sat-urated mapping [21, 23]. The former makes alsoimplied inclusion assertions between classes andbetween properties explicit, while the latter is con-structed by “saturating” the input mapping withthe classified ontology. The saturation is obtainedby adding to the existing mapping assertions addi-tional ones that are derived by combining informationfrom the input mapping and from the ontologyaxioms. For instance, if M contains an asser-tion ϕ(�x)� (f (x) rdf:type A) and T an axiomA subClassOf B, then MT will contain also theassertion ϕ(�x)� (f (x) rdf:type B). Saturating themapping essentially allows us to consider ontologyaxioms already in the offline stage, and avoid (orreduce) their use during query rewriting. In this way,we anticipate to the offline stage operations that oth-erwise would need to be performed in the onlinestage, and this reduces the overall time required forquery rewriting, when multiple user queries need tobe executed over the ontology. We also observe thatthe saturated mapping can be significantly simplifiedfor the online stage, by using query containment-based optimization to remove redundant mappingassertions.

The online stage handles individual sparqlqueries, and can be split into 6 main steps: ① the inputsparql query is rewritten according to the classifiedontology; ② the rewritten query is unfolded w.r.t. thesaturated-mapping, by substituting each triple withits mapping definitions; ③ the resulting iq is sim-plified by applying structural (e.g., replacing join ofunions by union of joins) and semantic (e.g., redun-dant self-join elimination) optimization techniques;

④ the optimized iq is translated into one or multi-ple native queries; ⑤ these are evaluated by the DBengine over the underlying DB (which is not explic-itly shown as input in Fig. 3); and finally, ⑥ the nativeresults are combined and transformed into sparqlresults.

Such an architecture allows for steps , , ①,and ② to be independent of the actual class D of DBs(white boxes in Fig. 3). Steps ③ and ⑥ require animplementation specific to iq (gray boxes), while ④and ⑤ are specific to D (black boxes).

We emphasize that the structural and semantic opti-mization step is crucial for OBDA to work in practice.In particular, unfolded sparql queries often con-tain significantly more joins than actually necessary,since sparql atoms are triples, while data is typi-cally stored in the form of n-ary entities (e.g., n-aryrelations in relational DBs). In the case of OBDAover a document-based DB, these techniques can beextended to take advantage of additional opportu-nities for optimization offered by the structure ofthe DB instance. Some of these optimization tech-niques are illustrated on the example presented inSection 4.4.

4. OBDA over MongoDB

We illustrate the generalized OBDA frameworkby focusing on a specific NoSQL DB, namelyMongoDB,2 a popular and representative instanceof document DBs. First, we introduce the data for-mat and the query language of MongoDB, and webriefly relate them to the nested relational model andnested relational algebra. Then, we describe our pro-totype implementation for answering sparql queriesover MongoDB. Finally, we illustrate the generalized

2https://docs.mongodb.org/manual/

26 E. Botoeva et al. / Ontology-based data access – Beyond relational sources

Fig. 4. A collection Db of two MongoDB documents.

OBDA framework over MongoDB on an exampleinspired by the BSBM benchmark.

4.1. MongoDB

MongoDB stores and exposes data as collectionsof json-like documents.3 A sample collection of twoMongoDB documents consisting of (nested) key-value pairs and arrays, is given in Fig. 4, where eachdocument contains information about a product: itsid, name, and a list of offers, in the form of a jsonarray. Each offer has itself an id, price, year, andvendor (in turn with id, name, and homepage).

In accordance with the generalized OBDA frame-work defined in Section 3, we assume that an inputcollection D of MongoDB documents complies toa schema S. In other words, documents in D areexpected to represent objects of the same type, andthus to follow the same structure.4 So if a field (e.g.,offers or offers.vendor.homepage) has anarray (resp., an object or a constant) as value in onedocument, we assume that in every document thisfield either has an array (resp., an object or a con-stant) as value, or is absent (in which case the valueis considered to be null).

3json (or JavaScript Object Notation) is a format for organiz-ing data in tree-shaped structures. So in spirit it is similar to XML,but it is significantly more lightweight.

4This is not required by MongoDB itself, only by the OBDAframework.

Fig. 5. Relational view [[Db]] of the collection of Fig. 4, followingthe BSBM schema.

Note that in a normalized relational DBinstance, this data would be spread across sev-eral tables. Indeed, our example is inspired bythe e-commerce scenario of the BSBM bench-mark [3], where the data is structured according toa relational schema consisting of multiple tables.Fig. 5 provides the relational view correspondingto this MongoDB collection, with distinct tablesfor products, vendors, and offers (the relational

E. Botoeva et al. / Ontology-based data access – Beyond relational sources 27

schema in the BSBM benchmark is actually morecomplex).

Note also that the json data in Fig. 4 is denormal-ized. In particular, it contains redundant information:the name and homepage of vendor 481 are present3 times. Document-based DBMSs like MongoDBcan take advantage of such redundancy. For instance,retrieving all vendors (with id, name, and home-page) of a given product over an instance of therelational schema of Fig. 5 requires two (potentiallycostly) join operations. But the same request overthe denormalized data does not require any join:the relevant information is already grouped within adocument.

However, query execution can also be penal-ized by redundancy. For instance, a valuefor field offers.vendor.vendorId isalways associated to the same value for fieldoffers.vendor.name. But this type of con-straint cannot be exploited by MongoDB (asof now) for query optimization. Therefore inorder to retrieve the name(s) of vendor 481 forinstance, MongoDB would fetch into memory alldocuments with an occurrence of 481 for fieldoffers.vendor.vendorId, even though onedocument is sufficient in theory. Noticeably, thisproblem could be avoided by choosing a differentdocument structure for the same data, with onedocument for each vendor rather than for eachproduct, but with the drawback that the collectionwould then contain redundant information aboutproducts. In general, the choice of a particulardocument structure is a trade-off, favoring somequeries, and penalizing others, and should be madeaccording to the expected query workload (providedsuch information is available beforehand).

Like relational DBs, MongoDB allows for declar-ing indexes. By default, it creates a unique indexover the (top-level) field id , which serves as theprimary key in a collection. Indexes can drasticallyspeed up query execution. In particular, retrieving a(whole) document by a unique value of an indexedfield (like the values of offers.offerId inFig. 4) can be done very efficiently by looking up thevalue in the index, and then fetching from disk datathat is likely to be contiguous. On the other hand,queries on values with non-unique occurrences (e.g.,the values of offers.offer.vendorId) maybe less efficient, because multiple (non-contiguous)documents may need to be fetched.

MongoDB provides an ad-hoc querying mecha-nism for formulating expressive queries by means

Fig. 6. A MongoDB Aggregate Query (maq).

Fig. 7. A sparql query corresponding to the maq of Fig. 6.

of the aggregation framework.5 A MongoDB aggre-gate query (maq) is a sequence of stages, eachof which takes one or two collections of docu-ments as input, and produces another collection asoutput. This language is powerful, but also morelow-level (less declarative) than some well knownquery languages such as sql or sparql. Becauseof this, maqs can be complex to read and manipu-late. As an illustration, the maq of Fig. 6 retrieves

5https://docs.mongodb.com/manual/reference/operator/aggregation-pipeline/

28 E. Botoeva et al. / Ontology-based data access – Beyond relational sources

Fig. 8. Nested relational view [[Db]]nested of the collection of Fig. 4 (where vendor is abbreviated as v).

Fig. 9. Unnesting the sub-relation offers in the relation of Fig. 8.

Fig. 10. Nesting all attributes but v.vendorId, v.name, and v.homepage in the relation of Fig. 9.

all products offered twice by the same vendor since2016. In comparison, the sparql query of Fig. 7retrieves the same information, but can be more eas-ily understood. The more procedural flavor of maqalso means that the sequence of stages of an maqis closer to its actual execution, whereas relationalDBs/triple stores hide from the user the complexityof query planning (e.g., the ordering of joins). Hence,from a user perspective, OBDA over MongoDBappears indeed as a promising alternative to manuallydevising maqs.

4.2. The nested relational model

Alternatively, a collection of MongoDB docu-ments can be viewed through the nested relationalmodel, an extension of the relational model in whichattributes can be also relation-valued, and not onlyatomic. Relation-valued attributes are called sub-relations. For instance, the MongoDB collection Db

of Fig. 4 can be naturally represented in the nested

relational model as the relation [[Db]]nested in Fig. 8,with a sub-relation for the field offers.6

Nested relational algebra (nra) [25] extends rato operate on nested data. It is of particular interestfor modeling operations on MongoDB collections,since it is equivalent in expressive power to a frag-ment of maq, as has been shown in [5]. nra extendsra with two operators: nest and unnest. Intuitively,unnest flattens a sub-relation by concatenating eachtuple in the sub-relation with the remaining attributesin the parent tuple. Instead, nest creates a sub-relationby partitioning the input relation, such that each ele-ment of the partition agrees on the values of theattributes that are not being nested. As an illus-tration, we first unnest the sub-relation offers,which yields the relation of Fig. 9. Then we nest allattributes except for offer.vendor.vendorId,offer.vendor.vendorName, and offer.

6Notice though that the elements of a MongoDB array areordered, whereas this is not the case of tuples in a sub-relation.

E. Botoeva et al. / Ontology-based data access – Beyond relational sources 29

vendor.homepage into a sub-relation r, whichyields the relation of Fig. 10. As a result, tuples aregrouped by vendor.

4.3. Instantiation of OBDA for MongoDB

We built a proof-of-concept prototype foranswering sparql queries over MongoDB, calledOntop/MongoDB, which extends the Ontop sys-tem [6] and implements the architecture describedin Fig. 3. The current implementation supports thefragment of sparql including BGPs, Filter, Join,Optional, and Union over MongoDB 3.4. In thisimplementation of the virtual OBDA architecture,nra serves as iq, and maq as the native query lan-guage. The system is designed to fully delegate queryexecution to the MongoDB engine,7 thus minimizingthe amount of post-processing required in step ⑥ ofFig. 3.

Ontop/MongoDB takes as input (in additionto the MongoDB database instance) an owl 2 qlontology, a mapping, and a set of constraints.The constraints are user-defined unicity constraints(UCs) or functional dependencies (FDs) that holdover the json documents being queried. Mon-goDB may not be able to enforce such constraints,but they may nonetheless hold over the data.For instance, in the collection of Fig. 4, anFD holds from offers.vendor.vendorId tooffers.vendor.name, meaning that the valueof the former determines the value of the latter. Theseconstraints can be used for query optimization (e.g.,to eliminate redundant joins, as illustrated in Sec-tion 4.4). We also emphasize that it can be verifiedwhether a manually declared constraint actually holdsover the data, by evaluating an appropriate query overthe MongoDB instance. For instance, the maq ofFig. 11 retrieves all sets of values (if any) that vio-late the FD from offers.vendor.vendorId tooffers.vendor.name, in any MongoDB collec-tion with the same schema as the collection of Fig. 4.

Note also that if the MongoDB instance is a denor-malized version of an existing relational DB instance,then UCs and FDs can be directly inferred from keysdeclared in the relational DB schema. For instance,let us assume that the MongoDB collection of Fig. 4is a denormalized version of the relational DBinstance of Fig. 5, and that the attribute vendorIdis declared as the primary key of table vendor.Then the FD from offers.vendor.vendorId

7An exception is the step that builds the returned rdf strings(IRIs and literals) from the constants retrieved from the DB.

Fig. 11. maq retrieving possible violations of the FD fromoffers.vendor.vendorId to offers.vendor.name,based on the schema of the collection of Fig. 4.

to offers.vendor.name must hold over theMongoDB collection.

In step ③, in addition to applying relationaloptimization techniques implemented by Ontop,Ontop/MongoDB also applies techniques specific tonested data, based on the equivalence with nra men-tioned above. In particular, it can take advantage ofthe UCs and FDs just mentioned.

In step ④, Ontop/MongoDB applies the nra-to-maq translation given in [5]. An importantconsideration in this translation process is that onehas to take into account the internal limitationsthat MongoDB puts on the size of in-memoryintermediate results during query evaluation (cur-rently 16 MB for a single document, and 100 MBfor a collection). For example, a naive iq-to-maqtranslation could produce an intermediate resultin which the content of all input documents ismerged into a single document, whose size mightthen exceed the memory limitations. Another keyconsideration is to take advantage of indexes avail-able over the source json collection(s). ThereforeOntop/MongoDB does not apply the translation of [5]directly, but uses an optimized version, which makesthe full delegation of query answering to MongoDBpractically feasible.

4.4. Generalized OBDA by example

We illustrate the generalized OBDA frameworkover MongoDB by elaborating on the running exam-ple inspired by the BSBM benchmark. The OBDAinstance we consider is a pair 〈Pb,Db〉, wherePb = 〈T b,Mb,Sb〉, the database instanceDb is thecollection of documents given in Fig. 4, and Sb is theschema defining the structure of such documents.In addition, Sb contains two manually declaredconstraints, which hold over the data: (i) a UC for the

30 E. Botoeva et al. / Ontology-based data access – Beyond relational sources

Fig. 12. Mapping Mb over the relational view of Fig. 5.

field offers.offerId, meaning that each valueof this field is unique in the whole collection;8 (ii) anFD from the field offers.vendor.vendorIdto the fields offers.vendor.name andoffers.vendor.homepage.

We illustrate the evaluation over this OBDAinstance of the SPARQL query q given in Fig. 7.The example focuses on the steps that are mostrelevant for the generalization of the OBDA frame-work. In particular, we do not illustrate ontologyclassification, mapping saturation, and sparql queryrewriting (respectively, steps ①, , and in Fig. 3),because these are identical to the case of OBDAover a relational database (for a detailed descrip-tion, we refer to [14]). For this reason, we simplifythe example by assuming that T b consists only of avocabulary (i.e., it contains no axiom), so that ontol-ogy classification, mapping saturation, and sparqlquery rewriting do not produce any change on therespective inputs.

Mapping. The mapping Mb is given in Fig. 12. Thesql query ϕ in each mapping assertion is defined overthe relational schema [[Sb]] (corresponding to the DBinstance [[Db]] of Fig. 5). For brevity, we use a set ofRDF triples on the right-hand side of each mappingassertion. In such triples, {a} is a placeholder for thevalue of attribute a in each tuple in ans(ϕ, [[Db]]), ands1{a}s2 stands for the concatenation of s1, {a}, and s2.In our case, since T b is empty, the saturated mappingMb

T b coincides with Mb.Note that the concrete mapping language currently

used by Ontop/MongoDB supports source queriesoverSb (rather than [[Sb]]), i.e., it defines json-to-rdf(rather than sql-to-rdf) mappings. Ontop/MongoDBconverts internally such mapping assertions into sql-

8Recall that MongoDB also enforces an implicit primary keyconstraint on the field id .

to-rdf ones. We only provide the latter here, to keepthe exposition simple.

Unfolding into an iq. The unfolding phase (step ②in Fig. 3) starts with the sparql query qT b , obtainedby rewriting q w.r.t. the ontology T b (since T b isempty, qT b coincides with q in our case). Each triplepattern in qT b is substituted with the correspondingsource sql query in the saturated mapping Mb

T b .This produces an ra query q1, with the guaranteethat for any DB instance D over the schema Sb,ans(q1, [[D]]) = ans(qT b ,Mb

T b (D)). This is in turn

equivalent to ansql(q, 〈Pb,D〉), i.e., computing theanswer to the original sparql query q over the OBDAinstance according to the owl 2 ql entailment regimecan be reduced to evaluating q1 over the relationalview. The resulting query in our running example isgiven in Fig. 13. As is conventional, symbols �, σ,and π respectively stand for inner join, selection, and(possibly complex) projection.

iq optimization. As mentioned in Section 4.3, in ourinstantiation of the generalized OBDA framework,nra serves as the iq language.9 In the iq optimizationphase (step ③ in Fig. 3), Ontop/MongoDB rewritesthe unfolded ra query, expressed over the relationalschema [[Sb]], into a semantically equivalent nraquery over the nested relational schema [[Sb]]nested(corresponding to the DB instance [[Db]]nested ofFig. 8). While doing so, it applies a series of queryoptimization techniques, some of which are nra-specific.

As an illustration, Fig. 14 provides a naive rewrit-ing over [[Sb]]nested of the query of Fig. 13, whereall sub-relations are simply unnested (in orderto “access” their attributes), and no optimiza-tion is applied. Symbol χ stands for unnest, andχofi→( , , , , , ) for unnesting the sub-relation ofi(which counts 6 attributes). The resulting iq requires atotal of 9 unnest operations and 9 binary joins, whoseexecution may be costly.

In comparison, Fig. 15 presents an optimizedrewriting over [[Sb]]nested, which contains no join,and only two unnest operations. A key technique toobtain this optimized rewriting is to identify redun-dant joins based on constraints holding over theschema Sb. For instance, each value of id canappear at most once in a MongoDB collection, there-fore it determines the value of fields name and

9Recall that nra subsumes ra, hence an ra query is also aniq.

E. Botoeva et al. / Ontology-based data access – Beyond relational sources 31

Fig. 13. Unfolding over [[Sb]] of the query of Fig. 7, w.r.t. the mapping of Fig. 12.

Fig. 14. Naive rewriting over [[Sb]]nested of the unfolded query of Fig. 13.

32 E. Botoeva et al. / Ontology-based data access – Beyond relational sources

Fig. 15. Optimized rewriting over [[Sb]]nested of the unfolded queryof Fig. 13.

offers. This makes the join in Fig. 14 betweenthe first three operands unnecessary (all operands arenumbered from 0 to 9, counterclockwise). Similarly,the UC declared for offers.offerId guaranteesthat each value for this field determines the value ofthe other 5 fields in the sub-relation. More interest-ingly, the declared FD guarantees that a value foroffers.vendor.vendorId is always associ-ated to the same value of offers.vendor.name,which makes the join between operands 7 and 9(or 8 and 9) unnecessary. This holds even though asame value for offers.vendor.vendorId mayappear multiple times in the collection. So in thislast case, in order to eliminate the redundant join,Ontop/MongoDB exploits an FD which does not fol-low from a UC. This is an example of nra-specificoptimization, usually not needed for OBDA over rela-tional DBs (assuming the database to be at least inthird normal form).

iq-to-Q translation. In the iq-to-native query trans-lation phase (step ④ in Fig. 3), Ontop/MongoDBrewrites the optimized iq q2, expressed over[[Sb]]nested, into an equivalent maq qm over Sb(i.e., such that for every D satisfying Sb,ans(q2, [[D]]nested) = ans(qm,D)), based on the cor-respondence between nra and (a fragment of) maqestablished in [5].

Since the optimized iq in our running example(Fig. 15) does not contain binary operators, the con-version to maq is relatively straightforward: σ, π,and χ can be directly mapped to the maq operators$match, $project, and $unwind respectively,yielding the maq of Fig. 6.

Fig. 16. Optimized version of the maq of Fig. 6.

Once again, query optimization techniques areapplied by Ontop/MongoDB in order to produce amore efficient maq. These are maq-specific, i.e., theycould not be implemented at the level of iq, andmostly pertain to the translation of binary nra oper-ators (including a dedicated planner).

We nonetheless illustrate one optimization tech-nique that applies to our running example. maq allowsfor prefiltering a collection of MongoDB documents,based on the value of a nested field nf , withoutthe need to unnest the corresponding sub-relationfirst. If nf is indexed, this pre-filter can signifi-cantly reduce the number of required disk accessesduring query execution, fetching only documentsin which some occurrence of nf satisfies the filtercondition.

In our example, assuming that the fieldoffers.year is indexed,10 one can prependa $match stage to the maq, in order to pre-filterproducts with at least one offer in the desired rangeof years (≥ 2016), before unnesting the sub-relation.The resulting maq is given in Fig. 16.

Native query evaluation and post-processing. Theevaluation phase (step ⑤ in Fig. 3) simply consists

10We also assume that this index is optimized for ordering,e.g., is a B-tree.

E. Botoeva et al. / Ontology-based data access – Beyond relational sources 33

in evaluating the optimized maq over the MongoDBcollectionDb. Ontop/MongoDB offers the possibiltyto fully delegate query execution to the source engine,meaning that the results returned by the source DBMScan be immediately converted to sparql solutionmappings.

Full delegation of query execution may not be pos-sible for all DBMSs though, or it may not be desirable,as explained in Section 3.1. This is the reason for thepost-processing phase (step ⑥ in Fig. 16). As a rel-atively basic illustration, Ontop/MongoDB offers asan option to postprocess the construction of IRIs. Inthis case, the last stage of the maq in Fig. 16 will notproject the field "product".11

5. Evaluation

We have carried out an evaluation that aims atdetermining whether OBDA over MongoDB is arealistic solution performance-wise, and in particularwhether it is able to exploit the document structureof MongoDB collections. We focus on answeringqueries over datasets that do not fit into memory. Insuch a setting, a key concern for performance is tolimit disk access, i.e., the number of non-contiguouspages that need to be fetched into memory.

To this end, we compare Ontop/MongoDB to thetriple store Virtuoso [11], which represents a dia-metrically opposite approach to answering sparqlqueries, as far as the data and index structure are con-cerned. Indeed, Virtuoso stores data as quads (i.e.,triples extended with the graph name), and for eachelement of the quads it maintains an extensive indexstructure, which is in particular highly optimizedfor retrieving (multiple) triples sharing a constantvalue.12 In comparison, retrieving all documents fora given value of an indexed field may be inefficient inMongoDB if the value is not unique in the index, asit requires fetching multiple (non-contiguous) docu-ments from disk. Instead, when the value is unique,MongoDB can fetch the whole document contain-ing this value very efficiently, whereas for Virtuosofetching the same data may require multiple diskaccesses.

We expect the evaluation to reflect these dif-ferences, i.e: (i) that Ontop/MongoDB outperformsVirtuoso for queries containing a unique constant in

11Note that the id field is systematically returned by Mon-goDB, therefore it does not need to be explicitly retained by theprojection.

12http://docs.openlinksw.com/virtuoso/rdfperfrdfscheme/

an indexed field, and fetching a single document;(ii) that Virtuoso outperforms Ontop/MongoDB forqueries whose constants have multiple occurrencesin the json collection.

An additional goal of the experiments is to deter-mine whether the cost of query rewriting itself (i.e.,generating the maq) introduces an excessive over-head.

5.1. Dataset and evaluation environment

As dataset we used an instance of the well-known BSBM benchmark [3], which emulates ane-commerce scenario, centered on offered products.The number of products in the instance is 4 mil-lion, giving 1.2 billion rdf triples, whose total size is156 GB.

BSBM also provides a representation of thisdataset as a relational DB instance, composed of10 tables (product, offer, vendor, etc.). Based on therelational schema of this instance, we generated a118 GB collection of json documents containing thesame data. The structure of the documents in thiscollection extends the one of Fig. 4, grouping in eachdocument all information pertaining to a single prod-uct.

The latest version of BSBM comes with 11 queries,numbered from 1 to 12 (there is no query 6 any-more). Among these, 3 were discarded, becausethey contain sparql features not (yet) supported byOntop/MongoDB (Describe queries, bound opera-tor, and variables over predicates). We instantiated10 versions of each of the 8 remaining queries,replacing constant placeholders with values ran-domly sampled from the data. One version of eachquery was set aside for a cold run, and the 8 · 9 otherinstantiated queries were shuffled as a query mix.Execution times reported below are averaged overthese 9 versions.

The systems being compared are Virtuoso v7.2.4(over the rdf triples), and Ontop/MongoDB withMongoDB v3.4.2 (over the json collection). Querieswere executed on a 24 cores Intel Xeon CPU at3.47 GHz, with a 5.4 TB 15k RPM RAID-5 hard-drive cluster. 8 GB of RAM were dedicated to eachsystem (MongoDB and Virtuoso) for caching andintermediate operations. The OS page cache was alsoflushed every 5 seconds, to ensure that each systemcould only exploit these 8 GB for caching. The querytimeout was set to 500 s. For each constant appearingin a query, the corresponding field in the MongoDBcollection was indexed.

34 E. Botoeva et al. / Ontology-based data access – Beyond relational sources

An executable for Ontop/MongoDB is availableonline, together with the sparql queries, mapping,constraints, and both datasets (json and rdf), so thatthe experiment can be reproduced. The generatedmaqs are also provided.13

5.2. Results and analysis

As a first element of answer, we observed thatall maqs generated by Ontop/MongoDB are optimalwith respect to the document structure, in the sensethat no unnecessary join is performed that could bein theory avoided.

Table 1 reports the execution times for both sys-tems. For Ontop/MongoDB, we distinguish queryrewriting time (“rw”), i.e., the time spent generatingthe maq, from its actual evaluation (“eval”) by Mon-goDB. Rewriting time does not depend on the sizeof the data, but only on the query, mapping, ontol-ogy, and constraints, which are less likely to growout of proportion. Still, for some of the cheaper maqs(< 100 ms), this overhead represents the major partof the execution time. This can be partly explainedby the wide range of optimizations performed byOntop/MongoDB. But it is also an aspect to improve,for OBDA over MongoDB to be considered a viablealternative to MongoDB itsef, at least in applicationswith high performance requirements.

We now focus on query evaluation times. For eachof the 9 versions of Query 5, the evaluation eithertimed out, or exceeded MongoDB’s memory limita-tions (see Section 4.3). This is explained by the factthat this query contains an anti-join, which requires a(close to) full collection scan from MongoDB. Forthe 7 remaining queries, we observe a sharp con-trast in performance between the two systems, whichmatches the above expectations. Queries 1 and 4present a very favorable setting for Virtuoso: thesparql BGPs are of limited size (≤ 5 triple patterns),and each of them contains 3 constants. On the otherhand, because none of these constants is unique in thejson collection, the evaluation by Ontop/MongoDBrequires fetching multiple documents from disk. Asexpected, for these two queries, evaluating the sparqlquery with Virtuoso was one order of magnitudefaster than evaluating the corresponding maq withOntop/MongoDB. As for the 5 remaining queries,they all represent a setting where MongoDB canfully benefit from denormalization. First, all 5 queries

13https://www.dropbox.com/sh/nz8dfas5ijpr76y/AACJzxHZUInrHi6Vq3Lk8f8ra?dl=0

require data contained in one document only. Inaddition, they all contain a constant in an indexedfield, where the index is either declared as a unique(Queries 2, 7, 8, and 10), or contain only uniquevalues (Query 12). For each of these queries, the eval-uation was one to two orders of magnitude faster forMongoDB. This confirms that Ontop/MongoDB wasable to generate maqs that take full advantage of thedocument (and index) structure.

6. Related work

The idea of using wrappers to access external datasources dates back to the 90s; see e.g., the Garlicdata integration system [22]. In recent years, severalextensions of the sql language have been proposedfor accessing json data, e.g., sql++ [18]. These querylanguages are either directly supported by the sourceDB engines (e.g., Couchbase14 and AsterixDB15)or by middleware. In the particular case of a Mon-goDB data source, such middleware includes Drill,16

Dremio,17 Studio 3T18, and the MongoDB Connec-tor for Spark19. With such systems, users can queryMongoDB collections as nested tables. sql queriesare automatically translated to (basic) MongoDBqueries, and post-processing is often required to com-pute advanced query constructs. These middlewaresystems differ fundamentally from OBDA systemsin the type of virtual data representation they expose:a representation whose structure is derived directlyfrom the one of the data source in the case of middle-ware systems, and an indirectly mapped RDF graphin the case of OBDA.

Several mapping language proposals already existthat extend r2rml for converting non-relationaldata sources to rdf, e.g., rml [10], xr2rml [16],kr2rml [24], and d2rml [8]. These languages extendthe relational model used in r2rml to more gen-eral cases (e.g., csv, json, and Web Services).The corresponding systems are mostly used fordata conversion; for instance, the implementationMorph-xr2rml also supports sparql query answer-ing by partially materializing the relevant rdf graph.

14http://couchbase.com/15https://asterixdb.apache.org/16https://drill.apache.org/17https://www.dremio.com/18https://studio3t.com/knowledge-base/articles/sql-query/19https://docs.mongodb.com/spark-connector/

E. Botoeva et al. / Ontology-based data access – Beyond relational sources 35

Table 1Execution times (ms) for Ontop/MongoDB and Virtuoso, over the BSBM benchmark

(4 million products). Values are averaged over 9 versions of each query

Query∣∣ 1 2 4 5 7 8 10 12

Ontop/MongoDBrw

∣∣ 26 179 102 NA 417 838 22 35

eval∣∣ 2672 43 3713 NA 53 66 34 40

Virtuoso eval∣∣ 258 308 403 1179 3995 1897 3966 327

Finally, the approach of [2] is comparable in spiritto ours, in that it also aims at delegating query exe-cution to a NoSQL source engine, and relies onan object-oriented (OO) intermediate representation,similar to our “relational view”. A key differencethough is that the mapping is from the ontologyvocabulary to the OO layer, rather than from thesource DB to the ontology vocabulary. The aim is tosimplify the mapping specification, and make it inde-pendent of the underlying source DB. The expres-sivity of such a mapping is thus limited, essentiallymapping OWL classes to (possibly nested) relations.

7. Conclusions

In this article, we have presented a generalizedOBDA framework for arbitrary (not only relational)DBs. It provides a convenient uniform querying inter-face, by means of a high-level vocabulary coupledwith a familiar query language (sparql), as an alter-native to the variety of ad-hoc native query languagesof NoSQL DBMSs. We also propose a practical archi-tecture for a generalized virtual OBDA approach, thatallows for answering sparql queries over arbitrarydata sources.

We have instantiated this framework in the spe-cific case of MongoDB, as an extension (calledOntop/MongoDB) of the OBDA system Ontop, andwe have compared its performance to that of a triplestore. The evaluation we have carried out shows thatOntop/MongoDB is able to generate queries in maq,the native query language of MongoDB, that take fulladvantage of the denormalized structure of the data.

As a continuation of this work, we plan to evaluatethe impact of the different techniques implementedwithin Ontop/MongoDB to optimize the generatedmaqs, using a wider range of queries, but also differ-ent document structures for the same dataset.

References

[1] N. Antonioli, F. Castano, C. Civili, S. Coletta, S. Grossi, D.Lembo, M. Lenzerini, A. Poggi, D.F. Savo and E. Virardi.Ontology-based data access: The experience at the Italian

Department of Treasury. In Proc. of the Industrial Trackof the 25th Int. Conf. on Advanced Information SystemsEngineering (CAiSE), volume 1017 of CEUR WorkshopProceedings, http://ceur-ws.org/, (2013), pp. 9–16.

[2] T.H.D. Araujo, B.T. Agena, K.R. Braghetto and R. Wasser-mann. OntoMongo – Ontology-Based data access forNoSQL. In M. Abel, S.R. Fiorini, and C. Pessanha, editors,Proc. of the 10th Seminar on Ontology Research in Brazil(Onto-Bras) and 1st Doctoral and Masters Consortium onOntologies, volume 1908 of CEUR Workshop Proceedings,http://ceur-ws.org/, (2017), pp. 55–66.

[3] C. Bizer and A. Schultz. The Berlin SPARQL benchmark,Int J on Semantic Web and Information Systems 5(2) (2009),1–24.

[4] E. Botoeva, D. Calvanese, B. Cogrel, J. Corman and G.Xiao. A generalized framework for ontology-based dataaccess. In Proc. of the 17th Int. Conference of the ItalianAssoc. for Artificial Intelligence (AI*IA), volume 11298 ofLecture Notes in Computer Science, (2018), pp. 166–180.Springer.

[5] E. Botoeva, D. Calvanese, B. Cogrel and G. Xiao. Expres-sivity and complexity of MongoDB queries. In Proc. of the21st Int. Conf. on Database Theory (ICDT), volume 98 ofLeibniz Int. Proc. in Informatics (LIPIcs), pp. 9:1–9:22,Dagstuhl, Germany, 2018. Schloss Dagstuhl–Leibniz-Zentrum fur Informatik.

[6] D. Calvanese, B. Cogrel, S. Komla-Ebri, R. Kontchakov, D.Lanti, M. Rezk, M. Rodriguez-Muro and G. Xiao. Ontop:Answering SPARQL queries over relational databases,Semantic Web J 8(3) (2017), 471–487.

[7] D. Calvanese, P. Liuzzo, A. Mosca, J. Remesal, M. Rezkand G. Rull. Ontology-based data integration in EPNet:Production and distribution of food during the RomanEmpire, Engineering Applications of Artificial Intelligence51 (2016), 212–229.

[8] A. Chortaras and G. Stamou. D2RML: Integrating hetero-geneous data and web services into custom RDF graphs. InProc. of the Workshop on Linked Data on the Web (LDOW),volume 2073 of CEUR Workshop Proceedings, http://ceur-ws.org/, 2018.

[9] S. Das, S. Sundara and R. Cyganiak. R2RML: RDB toRDF mapping language. W3C Recommendation, WorldWide Web Consortium, September 2012. Available athttp://www.w3.org/TR/r2rml/.

[10] A. Dimou, M. Vander Sande, P. Colpaert, R. Verborgh, E.Mannens and R. Van de Walle. RML: A generic languagefor integrated RDF mappings of heterogeneous data. InProc. of the Workshop on Linked Data on the Web (LDOW),volume 1184 of CEUR Workshop Proceedings, http://ceur-ws.org/, 2014.

[11] O. Erling and I. Mikhailov. RDF support in the VirtuosoDBMS. In Networked Knowledge – Networked Media, vol-ume 221 of Studies in Computational Intelligence, (2009),pp. 7–24. Springer.

36 E. Botoeva et al. / Ontology-based data access – Beyond relational sources

[12] M. Giese, A. Soylu, G. Vega-Gorgojo, A. Waaler, P. Haase,E. Jimenez-Ruiz, D. Lanti, M. Rezk, G. Xiao, O.L. Ozcepand R. Rosati. Optique: Zooming in on Big Data, IEEEComputer 48(3) (2015), 60–67.

[13] S. Harris and A. Seaborne. SPARQL 1.1 query language.W3C Recommendation, World Wide Web Consortium,March 2013. Available at http://www.w3.org/TR/sparql11-query.

[14] R. Kontchakov, M. Rezk, M. Rodriguez-Muro, G. Xiaoand M. Zakharyaschev. Answering SPARQL queries overdatabases under OWL 2 QL entailment regime. In Proc. ofthe 13th Int. Semantic Web Conf. (ISWC), volume 8796 ofLecture Notes in Computer Science, (2014), pp. 552–567.Springer.

[15] M. Lenzerini. Data integration: A theoretical perspective.In Proc. of the 21st ACM Symp. on Principles of DatabaseSystems (PODS), (2002), pp. 233–246.

[16] F. Michel, L. Djimenou, C. Faron-Zucker and J. Montagnat.Translation of relational and non-relational databases intoRDF with xR2RML. In Proc. of the 11th Int. Conf. on WebInformation Systems and Technologies (WEBIST), (2015),pp. 443–454.

[17] B. Motik, A. Fokoue, I. Horrocks, Z. Wu, C. Lutz andB. Cuenca Grau. OWL Web Ontology Language pro-files. W3C Recommendation,WorldWideWeb Consortium,October 2009. Available at http://www.w3.org/TR/owl-profiles/.

[18] K. Win Ong, Y. Papakonstantinou and R. Vernoux. TheSQL++ query language: Configurable, unifying and semi-structured. CoRR Technical Report abs/1405.3631, arXiv.org e-Print archive, 2014. Available at http://arxiv.org/abs/1405.3631.

[19] J. Perez, M. Arenas and C. Gutierrez. Semantics and com-plexity of SPARQL, ACM Trans. on Database Systems34(3) (2009), 16:1–16:45.

[20] A. Poggi, D. Lembo, D. Calvanese, G. De Giacomo, M.Lenzerini and R. Rosati. Linking data to ontologies, J onData Semantics 10 (2008), 133–173.

[21] M. Rodriguez-Muro, R. Kontchakov and M.Zakharyaschev. Ontology-based data access: Ontopof databases. In Proc. of the 12th Int. SemanticWeb Conf.(ISWC), volume 8218 of Lecture Notes in ComputerScience, (2013), pp. 558–573. Springer.

[22] M. Tork Roth and P.M. Schwarz. Don’t scrap it, wrap it!A wrapper architecture for legacy data sources. In Proc.Of the 23rd Int. Conf. on Very Large Data Bases (VLDB),(1997), pp. 266–275. Morgan Kaufmann.

[23] J.F. Sequeda, M. Arenas and D.P. Miranker. OBDA: Queryrewriting or materialization? In practice, both! In Proc. ofthe 13th Int. Semantic Web Conf. (ISWC), volume 8796 ofLecture Notes in Computer Science, (2014), pp. 535–551.Springer.

[24] J. Slepicka, C. Yin, P.A. Szekely and C.A. Knoblock.KR2RML: An alternative interpretation of R2RML for het-erogenous sources. In Proc. of the 6th Int. Workshop onConsuming Linked Data (COLD), co-located with ISWC,volume 1426 of CEUR Workshop Proceedings, http://ceur-ws.org/, 2015.

[25] J. Van den Bussche. Simulation of the nested relationalalgebra by the flat relational algebra, with an application tothe complexity of evaluating powerset algebra expressions,Theoretical Computer Science 254(1) (2001), 363–377.

[26] G. Xiao, D. Calvanese, R. Kontchakov, D. Lembo, A.Poggi, R. Rosati and M. Zakharyaschev. Ontology-baseddata access: A survey. In Proc. of the 27th Int. Joint Conf.on Artificial Intelligence (IJCAI), (2018), pp. 5511–5519.IJCAI Org.