The database landscape has been significantly diversified during the last decade, resulting in the emergence of a variety of non-relational (also called NoSQL) databases, e.g., XML and JSON-document databases, key-value stores, and graph databases. To facilitate access to such databases and to enable data integration of non-relational data sources, we generalize the well-known ontologybased data access (OBDA) framework so as to allow for querying arbitrary databases through a mediating ontology. We instantiate this framework to MongoDB, a popular JSON-document database, and implement a prototype extension of the virtual OBDA system Ontop for answering SPARQL queries over MongoDB.
Accessing data using native query languages is getting a more and more involved task
for users, as databases (DBs) increase in complexity and heterogeneity. The
OntologyBased Data Access (OBDA) paradigm [
As envisioned by Stonebraker and Cetintemel [
We consider fixed countably infinite sets C of DB values, and ED of elements built over C, e.g., named tuples, trees, or XML documents. We assume to deal with a class D of DBs, where each DB in D is a finite subset of ED, e.g., relational DBs, MongoDB, or XML DBs. Moreover, we assume that D comes equipped with: – Suitable forms of constraints, which might express both information about the structure of the data in DBs of D, e.g., the schema information in relational DBs, and “constraints” in the usual sense of DBs, e.g., primary and foreign key constraints for relational DBs. We call a collection of such constraints a D-schema. – A query language QD , such that, for each query q 2 QD and for each instance
D 2 D, the answer ans(q; D) of q over D is defined, and is itself a DB in D. – A relational wrapper [[ ]]D , which is a function transforming a QD -query q into a new query [[q]]D that takes a DB in D and returns a relation over C (i.e., a relation in first normal form)1. The role of the wrapper is to present ans(q; D) as a relation, by actually computing a query that retrieves from D what can be considered as the relational representation of ans(q; D). In particular, when q is the identity query, [[q]]D is the query computing the relational view of a DB D 2 D.
Having these building blocks at hand, we now define D-mapping assertions and their semantics. We start by introducing the notion of variable-to-RDF-term map, which is a generalization of the RDF-term template in relational OBDA. We say that f (x1; : : : ; xn) is an RDF term constructor if it is a (partial) function f : Cn ! I [ L, where I is the set of IRIs and L is the set of RDF literals. Then, a variable-to-(RDF)term map (for variable ?X) has the form ?X 7! f (x1; : : : ; xn). In the following, x1;:::;xn denotes the standard projection operator of relational algebra. Definition 1. A D-mapping assertion m is an expression q K h where: – q is a QD -query, called source query; – h is an RDF triple pattern, called target, of the form (?X1 rdf:type A) or (?X1 P ?X2), where A is a class name, and P is a property name; – K is a set of variable-to-term maps, one for each variable ?Xi appearing in h. The mapping assertion m is safe if for each ?Xi 7! f (x1; : : : ; xn) in K, we have that the function x1;:::;xn [[q]]D is well-defined.
A D-mapping M is a finite set of D-mapping assertions.
Notice that, the mapping assertion m is safe if and only if, for each variable-to-term map ?Xi 7! f (x1; : : : ; xn) used by m, the wrapper [[ ]]D , when applied to the source query q of m, returns a query producing a relation whose attributes contain x1; : : : ; xn. Definition 2. Let D be a class of DBs, m = q K h a D-mapping assertion, and D 2 D. The RDF graph m(D) generated by m from D is defined as follows: – When h = (?X1 rdf:type A), then
m(D) = (f (v) rdf:type A) j K = f?X1 7! f (x)g; v 2 x([[q]]D (D)) . 1 Discussing the specific form and properties of wrappers is outside the scope of this paper. – When h = (?X1 P ?X2), then m(D) = (f1(v1) P f2(v2)) j K = f?X1 7! f1(x1); ?X2 7! f2(x2)g; v1 2 x1 ([[q]]D (D)); v2 2 x2 ([[q]]D (D)) : For a D-mapping M, the RDF graph M(D) is defined as Sm2M m(D).
Now, an OBDA specification for D is a triple hT ; M; Si, where T is an ontology, S is a D-schema, and M is a D-mapping. An OBDA instance for D consists of an OBDA specification hT ; M; Si for D and an instance D 2 D satisfying S. The semantics of such an instance is derived naturally from the semantics of D-mapping assertions. 3
In this section we instantiate the generalized OBDA framework to MongoDB, a popular DB that stores collections of semi-structured JSON-style documents. A sample document consisting of (possibly nested) key-value pairs and arrays is given below. { "_id": 4, "awards": [ { "award": "Rosing Prize", "year": 1999, "by": "Norwegian Data Association" }, { "award": "Turing Award", "year": 2001, "by": "ACM" }, { "award": "IEEE John von Neumann Medal", "year": 2001, "by": "IEEE" } ], "birth": "1926-08-27", "contribs": ["OOP", "Simula"], "death": "2002-08-10", "name": {
"first": "Kristen", "last": "Nygaard" } }
This instantiation relies on work in [
We start by introducing a compact notation for MongoDB mapping assertions, which we also use to specify type constraints. We consider two extensions of paths called array paths. An array index path is a path where a key is followed by any combination of keys and ‘#’, separated by dots. An array element path is the concatenation of an array index path with ‘.[#]’. Intuitively, for (simple) paths p1 and p2, any of the array paths p1.#.p2, p1.#, or p1.[#] imply that p1 must point to an array. Moreover, the path p1.#.p2 (e.g., awards.#.year) is used to access the value of the path p2 inside the array pointed to by p1, while p1.# (e.g., awards.#) is used to denote the indices and p1.[#] (e.g., contribs.[#]) to denote the single elements of such an array. Hence, the presence of ‘#’ or ‘[#]’ requires that the path preceding it points to an array, whereas a path that does not end with ‘#’ or ‘[#]’ must point to atomic values. We use extended paths to refer both to normal paths and to array paths.
The source queries we consider are a restricted form of MUP queries and can be
represented as a pair (C; '), where C is a collection name and ' is a criterion constructed
using extended paths. Let K be a set of variable-to-term maps ?X 7! f (p1; : : : ; pn),
where each pi is an extended path. Then, a MongoDB mapping assertion is an
expression of the form (C; ') K h, where the variables in h constitute the domain of K.
Given a MongoDB mapping M, we can extract from it the MongoDB schema SM (a
set of type constraints), and then define a relational wrapper [[ ]]MongoDB for the source
queries in M (see [
We built a prototype implementation for answering SPARQL queries over MongoDB
as an extension of the state-of-the-art OBDA system Ontop [
Architecture of Ontop. Query answering (QA) in Ontop under the OWL 2 QL
entailment regime involves an offline and an online stage:
sStPrAinRgQL 1 SpPaArsRinQgL SPARQL Q 2 Rewriting RSPeAwRriQttLenQ0T 3w.rU.t.nmfoaldpipnigngs RA q1 4Struocpttuirmali/zsaetmioanntic
fiOlnetology Opnatroslionggy ii T claOsnstiofilcoagtiyoniii COlaFssFifiLedINTE coTMm-Mappiaplpaipntiigonngiv MMTSacphpeimnga MS Manaaplpyisnisg i fiMleapping RA q2
rSePsAuRltQL 8 proPcoessts-ing rNeastuilvtes 7 Evaluation qNuaetirviees 6 quReAry-ttora-nnsaltaivtieon RA q3 5 DNeocrmomalpizoastiitoionn/
The offline stage (highlighted in gray) takes as input the mapping and the ontology
files and produces three entities used by the online QA stage: the classified ontology,
the DB schema (extracted from the mapping file), and the T-mapping, constructed
by ‘compiling’ the classified ontology into the input mapping [
Implementation for MongoDB. We observe that steps ii – iv and 1 – 4 are independent of the actual class D of DBs, while steps i and 5 – 8 require specific implementations according to D. Therefore, our prototype implements the latter five components. The current implementation supports MongoDB 3.2 and is able to return sound and complete answers to the subset of SPARQL queries that (i) correspond to BGPs with filters consisting of comparisons, and (ii) can be translated into MUPG queries. 4
We are currently working on providing support for (most of) SPARQL 1.0. In the future we want to explore the tradeoff between delegating all of query processing to MongoDB vs. a fine-grained decomposition of the input query together with post-processing to combine the results of the sub-queries. We will test our techniques on real-world largescale use-cases, so as to assess the practical feasibility of OBDA over MongoDB.