Franck Ravat

Jiefu Song

Olivier Teste

Cassia Trojahn

Dos Santos

Efficient querying of multidimensional RDF data with aggregates: Comparing NoSQL, RDF and relational data stores

Keywords: statistical RDF data, graph aggregation, NoSQL, data analytics

published or not. The documents may come

Introduction

Classically, data analytics focuses on business data managed by a decision support system, with data being mostly stored in relational databases or structured files. In the era of Big Data [START_REF] De Vasconcelos | Business analytics and big data[END_REF][START_REF] Gandomi | Beyond the hype: Big data concepts, methods, and analytics[END_REF], business analytics must evolve constantly. In particular, with the increasing amount of RDF data being made available on the Linked Open Data (LOD) cloud, the need of considering this kind of data source is more than ever evident. This, however, involves not only dealing with the heterogeneity of representations and granularities, but also dealing with large volume of data.

While data analytics process largely benefits from multidimensional models (supporting, for example, Online Analytical Processing (OLAP) analysis [START_REF] Ravat | Algebraic and graphic languages for OLAP manipulations[END_REF] and reporting [START_REF] Schulz | On the relevance of reports-integrating an automated archiving component into a business intelligence system[END_REF]), these models have been largely studied in the database community and maturity on optimising multidimensional querying has been mostly reached.

In the Semantic Web, exploiting such multidimensional views on RDF data has received attention over the last ten years and a growing number of RDF data sources relying on such view has being published on the Linked Open Data1 . These data cube models2 answer the need of analysing statistical RDF data from different perspectives and levels of granularity [START_REF] Etcheverry | Modeling and Querying Data Warehouses on the Semantic Web Using QB4olap[END_REF].

However, querying multidimensional data generates high workloads on RDF triple stores. Despite the different efforts on optimising native RDF triple stores [START_REF] Pérez | Semantics and complexity of sparql[END_REF][START_REF] Neumann | x-rdf-3x: Fast querying, high update rates, and consistency for rdf databases[END_REF][START_REF] Tsialiamanis | Heuristics-based query optimisation for sparql[END_REF][START_REF] Ingalalli | Querying RDF data using A multigraph-based approach[END_REF], the scalability of SPARQL queries (the standard language for querying RDF graphs) is still limited owing further development and optimization [START_REF] Wang | ASPG: generating OLAP queries for SPARQL benchmarking[END_REF]. Different proposals have addressed querying traditional relational data on the top of SPARQL (the well-known Ontology-based Data Access [START_REF] Calvanese | Ontop: Answering SPARQL queries over relational databases[END_REF]), where the problem is shifted to the translation of SPARQL to SQL rather than to the performance of the data store itself. In parallel, a number of new data management systems, broadly known as NoSQL databases, have being proposed, offering a performing alternative to SPARQL engines. Such systems have emerged as an infrastructure for handling large amounts of data outside the RDF space [START_REF] Cudré-Mauroux | Nosql databases for rdf: An empirical evaluation[END_REF].

Different works have addressed the follow-up question on how the performance of NoSQL engines perform compared to RDF engines [START_REF] Hernández | Querying Wikidata: Comparing SPARQL, Relational and Graph Databases[END_REF][START_REF] Cudré-Mauroux | Nosql databases for rdf: An empirical evaluation[END_REF][START_REF] Bouhali | Exploiting RDF Open Data Using NoSQL Graph Databases[END_REF]. While most of them scale more gracefully than the RDF stores, the findings in these works also point out weaknesses of NoSQL engines in dealing with complex SPARQL queries involving several joins or containing complex filters on large volume of data [START_REF] Cudré-Mauroux | Nosql databases for rdf: An empirical evaluation[END_REF]. As stated in [START_REF] Hernández | Querying Wikidata: Comparing SPARQL, Relational and Graph Databases[END_REF], NoSQL engines like Neo4j could better isolate queries such that one poorly performing query does not cause a domino effect and benefit from better query algorithms.

With a focus on a particular kind of data (statistical RDF data) which requires specific treatments for facilitating the data analytics processes, one raised question is how triple stores performance would compare with that of relational and NoSQL data stores, when exploiting aggregates (i.e. summarised numeric values with grouping conditions and aggregation functions). For instance, suppose that we want to calculate the SO2 rate by country for a given year. If the data are modelled according to cities without aggregates, this analysis requires a query parsing all triples related to the SO2 rate by city before computing onthe-fly an average for each country. Contrary, including both detailed data and pre-computed aggregates, the analysis consists in a simple projection of SO2 rate for each country. Computing aggregates implies an overload in the data store by the addition of new data into the data store. Hence, the query performance intrinsically depends on the data store. Our hypothesis here are a) aggregating data and b) taking advantage of relational optimisations and NoSQL performances would better scale than triple stores when dealing with large amounts of data. Differently from graph summarisation [START_REF] Chen | Graph olap: Towards online analytical processing on graphs[END_REF][START_REF] Zhao | Graph Cube: On Warehousing and OLAP Multidimensional Networks[END_REF][START_REF] Ghrab | A framework for building olap cubes on graphs[END_REF][START_REF] Liu | A graph summarization: A survey[END_REF], which mostly focus on structurally grouping vertices or edges, our aggregation strategy is based on creating new vertices whose content results from calculating numeric values from a set of vertices through aggregation functions. Moreover, while works have studied the problem of aggregating RDF data in RDF triple stores like [START_REF] Kämpgen | No Size Fits All -Running the Star Schema Benchmark with SPARQL and RDF Aggregate Views[END_REF], to the best of our knowledge, this problem has not been addressed using property-graph and column NoSQL systems. This has been addressed in other NoSQL engines such as MongoDB document-oriented [START_REF] Botoeva | Obda beyond relational dbs: A study for mongodb[END_REF].

The contributions of this paper can be summarised as follows:

• we propose a conceptual model to represent statistical RDF data with aggregates according to a multidimensional structure. This model is generic enough to serve as a basis for representing graph-like multidimensional data with aggregates;

• we present a designing process that takes as input well-known multidimensional RDF data and produces a conceptual graph enriched with precomputed aggregates;

• we propose a set of rules for converting the logical model into different data representations (RDF, NoSQL graph-property and column, and relational representations);

• we propose a benchmark composed of 24 queries for querying aggregated and non-aggregated data together with the translation of them in different languages (SQL, SPARQL, Cypher and CQL) 3 ;

• we compare the performance of querying data with and without aggregates on a real-world RDF datasets containing 81.92 millions triples.

To the best of our knowledge, this is the first systematic study of aggregated graph data including conceptual modelling, translation rules and experimental evaluation on RDF triple stores, property-graph, column NoSQL and relational engines.

The remainder of the paper is organised as follows. Section 2 summarises the related work. Section 3 introduces our conceptual multidimensional model. Section 4 describes the designing process of Multidimensional Graph from statistical RDF data. Section 5 presents different logical and physical implementations of a conceptual Multidimensional Graph. Section 6 describes the querying of Multidimensional Graph with and without pre-computed aggregates. Section 7 presents the experimental results. Finally, Section 9 concludes the paper and discusses future work.

Related Work

This section presents the main proposals on the different aspects related to our work (i) managing RDF data on relational and NoSQL data stores, (ii) optimising RDF storage and querying; (iii) graph summarisation and RDF aggregates; and (iv) multidimensional analysis over RDF data.

Relational and NoSQL databases for managing RDF data. A large body of literature has focused on Ontology-based Data Access (OBDA) as a way of querying relational databases via ontologies and SPARQL queries. The reader can refer to [START_REF] Xiao | Ontology-based data access: A survey[END_REF] for a survey on these approaches. This involves dealing with the different aspects of translating SPARQL queries into SQL queries, as stated in [START_REF] Xiao | Efficient handling of sparql optional for obda[END_REF]. In these works, however, the performance of triple-stores is not at all addressed. In the perspective of comparing the performance of different RDF data management solutions, [START_REF] Schmidt | An experimental comparison of rdf data management approaches in a sparql benchmark scenario[END_REF] have shown that a triple store built on top of a column-store DBMS is competitive, with no approach scaling up to millions of RDF triples, and no approach competing with a purely relational model. In parallel, various works have also investigated the different aspects of using NoSQL databases to manage RDF data. In [START_REF] Cudré-Mauroux | Nosql databases for rdf: An empirical evaluation[END_REF], the performance of NoSQL bases (HBase, Couchbase and Cassandra) is evaluated. While most NoSQL systems scale more gracefully than RDF stores, complex SPARQL queries involving several joins, on large volumes of data, or containing complex filters perform poorly on NoSQL systems. In [START_REF] Hernández | Querying Wikidata: Comparing SPARQL, Relational and Graph Databases[END_REF], the authors compare the performance of triple stores, relational and graph databases for querying Wikidata.

Two SPARQL triple stores (Virtuoso and Blazegraph), one relational database (PostgreSQL), and one graph database (Neo4J) have been evaluated. They show that NoSQL could better isolate queries such that one poorly performing query does not cause a domino effect and benefit from better query algo-rithms. In [START_REF] Michel | Integrating heterogeneous data sources in the Web of data[END_REF], using NoSQL MongoDB for RDF data integration is addressed.

A set of transformation rules is applied to translate MongoDB documents to SPARQL. A SPARQL query is transformed into a pivot abstract query based on the xR2RML mapping of the target database to RDF. In [START_REF] Thakkar | Killing Two Birds with One Stone -Querying Property Graphs using SPARQL via GREMLINATOR[END_REF], the Gremlinator system translates SPARQL queries to path traversals for executing graph pattern matching over graph databases. It provides the foundation for a hybrid use of RDF triple stores and property graph such as Neo4J, Sparksee and Ori-entDB. Combining different data stores has been further developed in [START_REF] Sun | Sqlgraph: An efficient relational-based property graph store[END_REF]. The proposal combines relational storage (for adjacency information), with JSON storage (for vertex and edge attributes), for storing property graphs. The query translation mechanism translates a subset of Gremlin queries into SQL queries.

The proposed system outperformed Titan and Neo4j property graph systems, on query performance.

RDF storage and SPARQL query optimisation. While performance has been addressed in the works described above, mostly on the the perspective of the data and data storage, complementary work has addressed the optimisation of the querying mechanisms themselves. In that perspective, Characteristic Sets (CS) have been introduced as a way to provide estimations for join cardinalities for a better optimization of queries. In [START_REF] Neumann | Characteristic sets: Accurate cardinality estimation for rdf queries with multiple joins[END_REF], optimisation of SPARQL queries with multiple joins relies on the notion of CS as a way for helping estimating the cardinality of general queries. In [START_REF] Meimaris | Extended characteristic sets: Graph indexing for sparql query optimization[END_REF], an indexing scheme for RDF data that explores the inherent structure of triples and that relies on Extended Characteristic Set (ECS) has been proposed. ECS are used to classify triples based on the properties of their subjects and objects, with the objective of improving query processing for conjunctive queries. In [START_REF] Meimaris | Double chain-star: an rdf indexing scheme for fast processing of sparql joins[END_REF], the notion of CS has been extended to address the chain-star joins by reducing pairs of chain-star patterns that typically involve multiple self-joins. In [START_REF] Yuan | Triplebit: A fast and compact system for large scale rdf data[END_REF] a system optimising both storing and accessing RDF data has been proposed. In terms of storage, it reduces both the size of stored RDF data and the size of its indexes, using a bit matrix storage structure and an encoding-based compression method for storing huge RDF graphs. In terms of querying, a query plan generation algorithm aims at generating an optimal execution plan for a join query, reducing the size of intermediate results. In [START_REF] Bornea | Building an efficient rdf store over a relational database[END_REF], the RDF storage and query evaluation mechanisms rely on relational representations. For storing, the approach takes advantage of indexing, compressing and scalability of native relational stores and an entity-oriented mechanism for converting RDF data to relational data. For querying optimisation, the approach is based on a specialised structure, called a data flow, that captures the query inter-relationships given the sharing of common variables or constants of different query components. The data flow and cost estimations are then used to establish the order with which to optimise the query components.

In [START_REF] Peng | Adaptive distributed rdf graph fragmentation and allocation based on query workload[END_REF], the optimisation approach relies on distributed systems. The workload of fragmentation and allocation of distributing RDF datasets is addressed, with a focus on the reduction of the communication cost during SPARQL query processing. Based on frequent access patterns expressing the characteristics of the workload, vertical, horizontal, and mixed fragmentation strategies have been proposed. Experiments have shown the performance improvement on the results of fragmentation and allocation over large RDF datasets. Finally, in [START_REF] Husain | Heuristics-based query processing for large rdf graphs using cloud computing[END_REF], the strategy for managing RDF large datasets is based on on distributed file systems and injecting reasoning within RDF query processing. They propose an algorithm to generate query plans, and use Hadoop's MapReduce framework to answer the queries. In fact, reasoning can be exploited for pre-compute and materialise implicit triples or to compute the implicit triples on the fly [START_REF] Kaoudi | Triples in the clouds[END_REF]. The proposed approach has shown good results when compared to Jena, BigOWLIL and RDF3X systems.

Graph summarisation and aggregates in RDF. Graph summarisation has been extensively studied in the literature [START_REF] Liu | A graph summarization: A survey[END_REF]. Two main categories of approaches can be distinguished: (1) aggregation approaches [START_REF] Tian | Efficient aggregation for graph summarization[END_REF][START_REF] Wu | Graph summarization for attributed graphs[END_REF], which rely on strategies for grouping the graph nodes into groups based on diverse functions (e.g., similarity of values of attributes, relationships to adjacent nodes, application of aggregation functions, etc.); and (2) structural approaches [START_REF] Campinas | Introducing rdf graph summary with application to assisted sparql formulation[END_REF][START_REF] Zneika | Summarizing linked data RDF graphs using approximate graph pattern mining[END_REF][START_REF] Cebiric | Query-oriented summarization of rdf graphs[END_REF] which rely on extracting a schema representing a summary of the graph, in general, based on equivalence relations of nodes. The approach we propose here falls into the former. This is the same for the work in [START_REF] Tian | Efficient aggregation for graph summarization[END_REF], which produces a summary graph of K-groups by grouping nodes based on user-selected node attributes and relationships. This approach, however, is limited to graphs describing entities characterised by the same set of attributes. Our approach is not limited to this kind of graphs, given that RDF graphs are heterogeneous by nature. In the second category, [START_REF] Zneika | Summarizing linked data RDF graphs using approximate graph pattern mining[END_REF] summarise graphs following a top-K approximate RDF graph pattern strategy, aiming at guiding the user in the formulation of his queries. A similar approach is adopted in [START_REF] Campinas | Introducing rdf graph summary with application to assisted sparql formulation[END_REF], where summarising relies on a generic graph model defining the notion of node collections i.e., set of nodes sharing similar characteristics. In [START_REF] Khatchadourian | Explod: Summary-based exploration of interlinking and rdf usage in the linked open data cloud[END_REF], graphs from the LOD cloud are summarised, focusing on the distribution of classes and properties across LOD sources. The summaries are based on a mechanism that combines text labels and bisimulation contractions. The labels assigned to RDF graphs are hierarchical, enabling summarisation at different granularities. In [START_REF] Diao | Dagger: Digging for interesting aggregates in RDF graphs[END_REF] 'interesting insights' in (generic) RDF graph are automatically identified by the systems as RDF aggregate queries. The system ranks such insights and plots the most interesting ones as bar charts, and shows them to the user. Finally, hybrid approaches are proposed in [START_REF] Zhao | Graph Cube: On Warehousing and OLAP Multidimensional Networks[END_REF][START_REF] Wu | Graph summarization for attributed graphs[END_REF], which take into account both attribute aggregation and structure summarisation of graphs. These works rather focus on topological summarisation of graph aiming at helping users to extract and understand main characteristics of a graph. Other works on RDF summarization include LODeX [START_REF] Benedetti | A visual summary for linked open data sources[END_REF], ABSTAT [START_REF] Spahiu | ABSTAT: ontology-driven linked data summaries with pattern minimalization[END_REF] and SchemEX [START_REF] Konrath | Schemex -efficient construction of a data catalogue by stream-based indexing of linked data[END_REF]. LODeX is a tool that produces a representative summary of a LOD source. Similarly to [START_REF] Khatchadourian | Explod: Summary-based exploration of interlinking and rdf usage in the linked open data cloud[END_REF], the summary reports statistical and structural information regarding the LOD dataset (number of instances of classes and attributes). Contrary to them, we apply aggregation on the values of properties. Under a different view, SchemEX extracts a concise LOD schema with a structure to be used as an index, where schema extraction means to abstract RDF instances to RDF schema concepts that represent instances with the same properties. Finally, ABSTAT takes the RDF data summarisation problem as to provide a compact but complete representation of a dataset, where every relation between concepts that is not in the summary can be inferred. It adopts a minimisation mechanism based on minimal type patterns. In [START_REF] Joshi | Alignment aware linked data compression[END_REF], the the focus is the removal of semantic and contextual redundancies in linked data, with two techniques that compress RDF datasets begin introduced. The first, Logical Linked Data Compression compresses a dataset by generating a set of new logical rules from the dataset and removing triples that can be inferred from these rules. The second one, Contextual Linked Data Compression compresses datasets by performing schema alignment and instance matching followed by pruning of alignments based on confidence value and subsequent grouping of equivalent terms. Depending on the structure of the dataset, the first technique was able to prune more than 50% of the triples.

On the perspective of data materialisation, [START_REF] Goasdoué | View selection in semantic web databases[END_REF] addresses the problem of selecting a set of RDF views to be materialised in the database, minimising both query processing, such that workload queries can be answered based solely on the recommended views, with no need to access the database. The view selection is modelled as search space in a space of states, where each state models a candidate view set together with the rewriting of the workload queries based on these views. They take into account as well the implicit tuples, by saturating the database with them. Finally, [START_REF] Meimaris | Computational methods and optimizations for containment and complementarity in web data cubes[END_REF] addresses the problem of identifying and analysing instance relationships in multidimensional data (i.e., RDF Data Cube sources) and injecting them into the query mechanism. They compare their strategies to traditional query-based and inference-based solutions, with their proposal providing better scalability.

Multidimensional analysis over RDF data. Proposals on this topic mainly address different aspects of analytical queries over RDF data. In [START_REF] Wang | ASPG: generating OLAP queries for SPARQL benchmarking[END_REF], the proposal maps typical OLAP operations to SPARQL and a tool named ASPG automatically generates OLAP queries from real-world Linked Data. The works in [START_REF] Gür | Geosemolap: Geospatial olap on the semantic web made easy[END_REF][START_REF] Ravat | Designing Multidimensional Cubes from Warehoused Data and Linked Open Data[END_REF] focus on generating SPARQL queries based on OLAP analysis, requiring datasets being described in QB or QB4OLAP vocabularies. In [START_REF] Etcheverry | Efficient analytical queries on semantic web data cubes[END_REF], a high-level query language (COL) that operates over cubes is proposed. Using the metadata provided by QB4OLAP, COL queries are translated into SPARQL, exploiting SPARQL query optimisation techniques. To address also performance, the approach in [START_REF] Ravindra | Optimization of complex SPARQL analytical queries[END_REF] is based on a refactoring of analytical queries expressed in the relational-like SPARQL algebra based on a set of logical operators. This refactoring enables parallel evaluation of groupings and aggregations, particularly beneficial for scale-out processing on distributed cloud systems. Contrary to these works, we address the performance of analytical queries exploiting materialisation of aggregates. In [START_REF] Jindal | Graph analytics using vertica relational database[END_REF], graph analytics (graph queries involving full scans, joins, and aggregates) are expressed in relational databases. Translation logical query plans of graph queries into relational operators. query optimisation techniques to tune the performance of graph queries, including considering updating vs replacing the nodes table on each iteration, incremental evaluation of queries, and eliminating redundant joins. In [START_REF] Ordonez | Comparing columnar, row and array dbmss to process recursive queries on graphs[END_REF], the focus is on the impact of query optimisation of recursive queries on large graphs with different shapes and densities, comparing columnar, row and array DBMSs. The performance on three fundamental relational operators has been analysed (join, projection and, selection). While a columnar DBMS with tuned query optimisation outperforms row and array systems, regardless of their shape, density and connectivity, there is no clear best system between the row and array DBMSs.

Discussion. Contrary to the works on OBDA, the study here concentrates on how other kinds of data stores scale when dealing with aggregates in RDF data. Moreover, none of the above-mentioned approach has systematically studied the efficiency of queries computing observation values according to different attributes at different granularity levels organised in different dimensions. While the performance of RDF triple stores have been largely studied, as discussed below, here we state that one can take advantage of the performance of relational (as for OBDA) and NoSQL engines for better dealing with larger RDF datasets.

As [START_REF] Cudré-Mauroux | Nosql databases for rdf: An empirical evaluation[END_REF][START_REF] Hernández | Querying Wikidata: Comparing SPARQL, Relational and Graph Databases[END_REF], we address the evaluation of NoSQL systems as Neo4j (differently from [START_REF] Michel | Integrating heterogeneous data sources in the Web of data[END_REF]) for storing RDF data, but here we focus on a specific kind of data (multidimensional statistical data). While they have pointed out some weakness of these systems, we argue here that materialising aggregates can provide better querying performance. As [START_REF] Thakkar | Killing Two Birds with One Stone -Querying Property Graphs using SPARQL via GREMLINATOR[END_REF], we consider both storage supports (triple stores and NoSQL databases) but do not combine them together. This is what has been done in [START_REF] Sun | Sqlgraph: An efficient relational-based property graph store[END_REF]. Differently from the works on query optimisation and storage, we do not deal with the different optimising mechanisms. These are complementary works to our study that has to be taken into account in the future. With respect to graph summarisation, unlike most proposals, our approach differs from those by nature, since it works on aggregating numeric values within vertices and not on reducing the graph. Differently from works exploiting reasoning for query optimisation or graph summarisation, we do not exploit yet this mechanism.

As [START_REF] Goasdoué | View selection in semantic web databases[END_REF], where RDF views are materialised in the database, minimising query processing our idea is to materialise aggregations and query the dedicated graph, reducing the number of comparisons to be done in the query time. Here, we analyse the performance of this approach in several data stores. Close to ours, in particular in multidimensional analysis, [START_REF] Kämpgen | No Size Fits All -Running the Star Schema Benchmark with SPARQL and RDF Aggregate Views[END_REF] compares the performance of SPARQL and of ROLAP SQL queries and measures the gain of RDF aggregate views that materialise parts of the RDF data cube. While RDF aggregate views show the capability to optimise query execution, yet, overall still take six times longer for pre-processing and not nearly reach the performance gain of aggregate tables in ROLAP. Here, we could observe that globally the aggregates can have a positive impact in the querying performance. It is important to note, however, that our experiments compared to [START_REF] Kämpgen | No Size Fits All -Running the Star Schema Benchmark with SPARQL and RDF Aggregate Views[END_REF] have not been executed on the same basis. On one hand, we propose a new conceptual modelling solution to include pre-computed aggregates in a multidimensional graph. On the other hand, we base our experiments on a new technical environment including triple stores, NoSQL databases and relational databases.

Conceptual modelling

Our objective is to propose a conceptual multidimensional model for modelling statistical RDF data. The proposed model is characterised as follows:

(i) it should be independent of a specific storage structure (e.

M = {e M i } 1≤i≤|M| is the set of measure values, A = {e A j } 1≤j≤|A| is the set of attribute values, G = {e G k } 1≤k≤|A| is the set of aggregates • E ⊆ V × V is a set of edges such that E = E M A ∪ E AA ∪ E M G ∪ E AG ∪ E GG .
E M A is an edge between a measure value e M i and an attribute value e A j , E AA is an edge between two attribute values e A i and e A j , E M G is an edge between a measure value e M i and an aggregate e G i , E AG is an edge between an attribute value e A j and an aggregate e G i , E GG is an edge between two aggregates e G i and e G j

The relationships between different types of vertices and edges are presented in Figure 1. The formal representation of this multidimensional graph is as follows:

• V = M ∪ A ∪ G where M = {e M 1 , e M 2 , e M 3 }, A = {e A 1 , e A 2 , e A 3 , e A 4 , e A 5 , e A 6 , e A 7 }, G = {e G 1 , e G 2 , e G 3 , e G 4 } • E = E M A ∪ E AA ∪ E AG where E M A = {(e M 1 ,
D i AA are disjoints; ∀i ∈ [1..d], j = i ∈ [1..d], D i AA ∩ D j AA = ∅.
Attributes within a multidimensional graph can be organised according to analysis axes (i.e. dimensions) :

Definition 2. A dimension is defined by (D i AA , i ) where Attributes associated together through binary relations form one or several aggregation paths (i.e. hierarchies) within a dimension. A measure can be summarised along a hierarchy by zooming in (drilling down) or zooming out (rolling up).

Example. In the previous example, the multidimensional database is composed of one dimension with one hierarchy of four granularities (city, region, country and geography), such as It is worth noticing that our proposed model is situated at the conceptual level. We introduce a generic modelling solution independent of any implementation environment. Our proposed model can be freely implemented in any data store, for instance in a RDF triple stores through QB and QB4OLAP vocabularies, or in a relational database through relations. We apply the multidimensional modelling principles to our proposed model to make a distinction between raw statistical RDF data and pre-computed aggregates through two types of vertices M and G. Specifically, the raw data vertices M are directly deduced the from data source. Since QB or QB4OLAP which do not require including pre-computed aggregates, not all datasets include all possible aggregates. Unlike these previous solutions, our proposed model systematically browses all the raw data and discovers all possible aggregates. These aggregates are computed before analyses and materialised through aggregate vertices G to accelerate multidimensional analyses.

• D Geography AA = {e A 1 , e A 2 ,

Designing a Multidimensional Graph from statistical RDF data

Based on the conceptual modelling of a multidimensional graph, we propose a designing process to pre-compute and materialise aggregates from statistical RDF data (cf. Figure 3). Contrary to the work from [START_REF] Bouakkaz | Textual aggregation approaches in olap context: A survey[END_REF] that proposes textual aggregations for OLAP analysis, here we focus on numeric aggregation. Our design process begins with converting statistical RDF data without aggregates at the physical level into the conceptual Multidimensional Graph (arrow 1).

During this step, aggregates are computed and combined with original data in a conceptual Multidimensional Graph.

Translating algorithm

In

g i ∈ G, G ⊆ V ;
create an edge E M G between m i and g i . ;

create an edge E AG between each attribute ag i in the grouping conditions and g i . ;

create an edge E GG between related aggregate vertices g i and g j , such as there exists an attribute ag i associated with g i and an attribute ag j , ag i D k ag j ;

end

Use Case

In order to illustrate the feasibility of our proposed translating process, in this section we describe a use case based on a real-world dataset named QBOAir- OLAP context, they can be implemented through materialised views; in a multidimensional OLAP system, they can be implemented through cubes; in the RDF context, they can be implemented through new specific triples.

Logical and physical implementation

The second aim of our approach is to transform a conceptual Multidimensional Graph including both original data and aggregates into different logical and physical implementations (RDF, property-graph, column and relational models at logical and physical levels (cf. Figure 5)). In the case of an RDF model, we have defined an underlying RDF vocabulary supporting the translation of our Multidimensional Graph model into the corresponding RDF representation. Note that a pre-computed aggregate can be represented as a 445 qb:Observation and its related edges can be represented through predicates (e.g., Figure 6).

MG to property-graph representation

In order to transform a conceptual Multidimensional Graph into a propertygraph representation, we define the following set of mapping rules.

MG to column-oriented data store

A column-oriented data store manages data by columns rather than by rows like in relational DBMS. More precisely, a column-oriented data store manages each database table column separately, with attribute values belonging to the same column stored contiguously, and densely packed [START_REF] Abadi | Column-oriented database systems[END_REF]. For our experimental assessments, we use the Cassandra data store. This data store is based on the following concepts. A keyspace closely corresponds to a relational database. A column family is a container for an ordered collection of rows, each of which is itself an ordered collection of columns [START_REF] Hewitt | Cassandra: The Definitive Guide, 1st Edition[END_REF]. A column is the basic component defined by a name, a value, and a timestamp. A partition key correspond to a primary key in a relational database.

Our objective is to translate all the components of a multidimensional graph into a keyspace. In Cassandra, the primary key concept is different from relational databases. A key is used for grouping and organising data into columns and rows. The order in which columns are defined for the primary key matters and it is possible to have a key composed of multiple columns.

Note that only the first column of the primary key is considered the partition key and the rest of columns are clustering keys. The tables are implemented through CQL queries.

MG to relational DBMS

Our objective is to implement all the components of the multidimensional graph through relational tables. For the raw data, all the nodes of M (Measures) are implemented through a fact table. The primary key of the fact table is composed of the URI of the subject. All the nodes of A (Attributes) are implemented through different tables and each table represents an aggregation level (the primary key is the URI of the subject and the foreign key is the URI of the predicate related to the following level). In Figure 7, we can identify one fact table related to the observations and 6 tables for the dimensions related to the attributes.

For the aggregated data, all the nodes G (Aggregates) are implemented through different tables. Each tuple in an aggregate table corresponds to an aggregate vertex. A set of aggregate vertices sharing the same attributes are grouped in one aggregate table according to the lattice shown in Figure 4 (b) (excluding the lowest one representing the levels of raw data). The final schema is composed of 7 tables implementing raw data (cf. Figure 7(a)) and 23 materi- alized views implementing pre-computed aggregates (e.g., the three materialized views in figure 7(b)).

Multidimensional Graph Querying

From the previous discussion (Section 3), we highlight the differences between our approach (graph aggregation) and graph summarisation. Specifically, For instance, in a relational data store (cf. During its execution, only 2.3 million tuples are involved (i.e. 0.0055% of the first query in Figure 8). The same principle applies to all the other data stores. 1. We first present the data model and the query language of the different data stores used in this paper. Second, we provide an empirical comparison to evaluate the capacity of each data store to implement and query graph data.

Specifically, implementing a graph in a column-oriented data store is complex, since using nested column structure to manage graph data requires a careful choice of design solutions. In the same manner, querying graph data involving a long path in relational and column data stores needs advanced skills in the corresponding querying languages.

Experimental evaluation

In this section, we present our experimental evaluation on querying statistical RDF data using the aggregate-based model described above. We aim at studying the benefits of graph aggregation for querying efficiency according to different scenarios:

1. querying multidimensional graphs without aggregates, using Jena TDB2 and Virtuoso triple stores;

2. querying multidimensional graphs with pre-computed aggregates, using Jena TDB2 and Virtuoso triple stores; different data stores at the physical level.

It is worth noticing that we rely on the default tuning of each data store without any customised optimisation technique. By doing so, our objective is to avoid introducing any bias during analyses and find out the best native implementation for querying pre-computed aggregates.

Benchmark queries. We propose 24 queries covering a large range of operations during statistical RDF analyses. (cf. Figure 9). Specifically, the first 12 queries involve all data ranging from the most detailed granularity to the most general granularity, while the last 12 queries extract a sub-set of data according to a selection criteria on different vertex of different granularities. Specifically, queries Q1 and Q13 involve only original data without computing aggregated measure values. It takes the same form in both orig. and ag. datasets. Queries Q2-Q12 (without selection conditions) and Q14-Q24 (with selection conditions)

involve aggregated measures values upon different granularities on different analysis axes. They (i) compute aggregated values on-the-fly according to some grouping conditions and an aggregation function in orig. datasets and (ii) directly extract pre-computed and materialised aggregates in ag. datasets. For the selection and range queries, Table 7.1 shows the selectivity i.e., how many triples/observations are retrieved). Each query has been run on the original data, without the filtering conditions and with the filtering conditions (i.e., for the query 16, calculating the number of cities of interest with respect to the number of cities in the data store). Each query has been written with SPARQL (Jena and Virtuoso triple stores), SQL (MySQL and PostgreSQL relational databases), CQL (Cassandra NoSQL) and Cypher (Neo4j NoSQL database).

In fact, different SPARQL query benchmarks exist, as for instance, the Berlin SPARQL [START_REF] Bizer | The berlin SPARQL benchmark[END_REF], which aims at comparing the performance of RDF stores with the performance of relational database management systems; the LUBM dataset 7 , dedicated to OWL benchmarking (querying, reasoning, etc.); the Evo-Gen Benchmark [START_REF] Meimaris | The evogen benchmark suite for evolving RDF data[END_REF], for benchmarking of versioning RDF systems (temporal querying, queries on changes, longitudinal queries across versions, etc); or still the SPB benchmark (Semantic Publishing Benchmark) [START_REF] Kotsev | Benchmarking RDF query engines: The LDBC semantic publishing benchmark[END_REF], a set of queries expressing the requirements each RDF store needs to address in order to satisfy in real use cases (aggregations, join ordering, complex filter conditions, etc.).

While these benchmarks cover aggregation queries, as we propose here, their RDF datasets are not expressed in the dedicated vocabulary for representing statistical RDF data. Our motivation for constructing our own dataset is that is dedicated to the multidimensional view and original data is modelled as a 650 data cube using QB4OLAP.

Technical environment and evaluation metrics. The hardware configuration is as follows: OS MAC OS 10.12.5, 2 x 2,4 GHz Quad-Core Intel Xeon, 48 GB 1066 MHz DDR3, 1TB SATA Disk. We willingly choose a RAM with enough space to integrate all the datasets to avoid the different impacts of disk 655 I/O when dealing with different sizes of datasets. In this case, the only influence factor consists of the dataset size. For each query, we record its execution time (in millisecond) in both implementations, for ten runs. We clear the querying engine's cache before each execution, so that a previously executed query does not serve as warm-up run for the following one. In this way, during each query execution, data are read from a secondary storage instead of system cache. The final execution time of a query corresponds to the mean time of all runs.

Experimental results

In the following the results of our experiments are detailed by different kinds of queries.

Results per query. In a first analysis, we focus on the performance of each of the 24 queries for the largest dataset (D5) (Figure 10). For the overall results discussed in the following subsections, we present the results per dataset. As we would expect, the best performance for most queries have been reported for the ag. datasets, with the the worst performances were observed for the orig.

datasets. For the best cases, while relational databases outperform the other data stores, for most worst cases Cassandra (queries Q2-Q12, as detailed below)

is the one that performs poorly. For queries Q23 and Q24, in particular, the worst performance was observed for Jena (57600ms in the ag., for Q23, and 3422447ms in orig. for Q24). In fact,

DS5 dataset).

For query Q13 which contains only selection conditions without any grouping condition, its execution is greatly influenced by pre-computed aggregates in Jena TDB2 and Virtuoso. Notably, from DS1 to DS5, the gap is widened nearly 40 times in Virtuoso. The greatest gap (up to 2913 ms) of Q13's runtime is found in dataset DS5 of Virtuoso (with an absolute runtime of 7492ms in orig.

DS5 dataset and 10405ms in ag. DS5 dataset). For the other data stores, the behaviour is similar than Q1, were the biggest differences are observed for D5

with Cassandra (-21296.4, with an absolute runtime of 171726ms in the orig.

and 150429.6ms in the ag.).

Overall, Neo4j and Cassandra are the least affected by the materialisation of aggregates. For Neo4j there is practically no difference (max. 45 ms) while querying without summarising data before and after adding pre-computed aggregates, with or without selection condition. For Cassandra, a positive impact of the aggregation is observed.

Querying aggregated numeric values without selection condition. The second part of the experiments focuses on the impact of graph aggregation over queries Q2-Q12 which summarise data according to different grouping conditions without selection.

As shown in Figure 13 Querying aggregated numeric values with selection condition. In the third part of our experiments, we study if queries with selection conditions are efficiently computed in datasets with aggregates. We analyse the runtime of queries Q14-Q24 in all datasets with and without aggregates. From Figure 14, we can observe that all data stores, pre-computed aggregates allow decreasing the execution time of queries with selection conditions. As observed for the first group of queries, overall runtime increases with the increasing in the volume of the datasets (with exception of Neo4j ag, Cassandra orig. and MySQL orig.). Among all data stores, for the largest dataset the lowest average runtime is recorded in relational databases with aggregates (Postgres and MySQL, respectively). Table 4 shows the gain in terms of runtime for queries Q14-Q24 (with condition). We can observe that overall the gain is more important for this group of queries with respect to the first one. As observed above, all data stores benefit from the aggregation (no negative gain). Again, relational databases are the stores that better benefit from the aggregation, with MySQL with a gain of 100% for the largest dataset (from 1784.5ms to 0.7ms).

Discussion

Synthesis of results

With the increasing amount of statistical RDF data made available on the LOD cloud, there is a clear need for manipulating this kind of data taking advantage from multidimensional models as a way of facilitating the data analytic tasks. However, from the conceptual modelling point of view, existing work focuses rather on detailed data at the lowest levels of granularity. Consequently, querying efficiency based on such modelling solutions is low when detailed data should be summarised on-the-fly according to different levels of granularity on different analysis axes. Moreover, from the implementation point of view, existing work mainly focuses on optimising native RDF triple stores. Our work is a fist attempt to address the problem of querying aggregated data using different data stores.

In particular, the results of our experiments are opposite to what the authors of [START_REF] Kämpgen | No Size Fits All -Running the Star Schema Benchmark with SPARQL and RDF Aggregate Views[END_REF] have observed: provided that aggregates are properly modelled in an RDF dataset, we highly recommend pre-computing aggregates in statistical RDF datasets to reduce query execution time. In our empirical evaluation, our findings were that pre-computing aggregates is a promising approach to improving querying performance in large RDF datasets.

In terms of findings, more specifically: i) pre-aggregates improve the performance of all data stores; ii) relational databases outperform all other data stores;

iii) Neo4j NoSQL is more recommended than Cassandra NoSQL for manipulating multidimensional data, as it scales better for larger datasets; iv) Neo4j

NoSQL performs better than Jena TDB2 and Virtuoso triple stores. This evaluation was based on a conceptual model with aggregates allows for representing aggregates independently of its implantation in different data stores. This theo-retical model allows for the implantation of aggregates for further exploration in practical scenarios as well as the exploitation of it in further experimentations involving additional data store systems.

Theoretical contributions

Our theoretical contributions can be seen from different levels.

Implications for practice

From the practical point of view, our study is carried out in a systematic manner by using different types of data stores based on large amounts of realworld data.

It is worth noticing that short runtime (a few milliseconds) is always obtained with pre-computed aggregates. Meanwhile, the execution of correspond-ing queries based on detailed data without pre-computed aggregates takes several seconds even minutes. In another word, even though the amount of RAM is considerably larger than the dataset volume, on-the-fly computing of aggregate from detailed data is still not recommended for its low efficiency. Correspondingly, with pre-computed aggregates, a query can be significantly simplified (cf. section 6.) The query becomes quite easy to handle (notably in Neo4j and relational data store): it contains only simple operations (projection) and the volume of data involved in this query become so small that a data store can produce the result immediately.

Pre-computing aggregates is not only an efficient technique to deal with large amounts of statistical RDF data but also a scalable solution. In fact, as we can see from our experiments, even though data volume increases rapidly (by 21 times), the average query runtime in all three data stores with aggregates does not increase exponentially.

We can also notice that the execution of the same query does not take the same time in different data stores. Thus, the choice of data stores impacts the querying efficiency. Among all types of data stores studied during our experiments, we recommend relational databases to manage statistical RDF data enriched with aggregates.

Limitations and Future Research Direction

A first limitation of our study concerns the data stores. We have not include all potential systems for all data stores types. For instance, among the RDF data stores, we can further study the performance of Strabon, GraphDB, and Stardog. Among the relational databases, we can complete our study with more mature DBMS, such as Oracle, SQL Server and DB2. Among the graph and column data stores, we also intent to implement the Multidimensional Graph in OrientDB, and HBase. Meanwhile, our future study must include data of larger scale (e.g., exceeding memory limits). A long-term research direction could include in our study cloud data management systems [START_REF] Senyo | Cloud computing research: A review of research themes, frameworks, methods and future research directions[END_REF], such as Neptune and Cosmos. By doing so, our objective is to go through a hybrid approach for dynamically dispatching the query according to their type and previous characterised performance of the data store (i.e., taking the best of each data store).

A second limitation of our study is that it does not include any query optimisation technique, which we believe can further improve querying efficiency.

Furthermore, while our experimental evaluation in this paper consists of a horizontal comparison of different data store with native tuning during multidimensional analyses, a future direction of our research consists in applying specific optimisation techniques (indexing, query plan, hint etc.) to each data store and further investigate the impact of them in the querying process. The objective is to study in a vertical manner the best performance that each data store can reach when dealing with analytic queries on statistical RDF data.

Another research direction would be improving the RDF modelling vocabulary of our Multidimensional Graph model. In the line of the work of [START_REF] Calvanese | Ontop: Answering SPARQL queries over relational databases[END_REF], the objective would be to support ontology-based data access to enable SPARQL querying over other data stores than RDF triple stores. For that, we will propose R2RML mappings for translating the original schemes to our ontology.

Conclusion

The primary aim of this paper was to improve the efficiency of complex queries involving data from different granularity levels. To that extent, we have proposed an approach for querying large volume of statistical RDF data, relying on pre-aggregation strategies. The proposal covers from a high level conceptual modelling solution to an implementation in different data stores with real-world large datasets. From the theoretical point of view, we have contributed to a novel multidimensional modelling solution coupled with a design and an implementation processes. This modelling solution allows for representing both detailed data and pre-computed aggregates. From the practical point of view, we have illustrated through experiments that pre-computed aggregates reduce query execution time in all data stores. The performance of analytic queries on relational databases with aggregates outperforms RDF triple stores, with a good performance of Neo4j NoSQL.

  g. triple store, DBMS, etc.), (ii) it should represent data in the graph form and (iii) it should include different aggregation levels useful for multidimensional analyses. To do so, we introduce a conceptual multidimensional model based on the concepts of graph structure and aggregates. In this section, we present the model named Multidimensional Graph and illustrate it through an example. A multidimensional graph enriches classical conceptual graph modelling with pre-computed aggregates. It contains individuals organised according to three multidimensional concepts, namely numeric indicators (measures), descriptive properties (attributes) and summarised numeric indicators with grouping conditions and an aggregate function (aggregates). Definition 1. A multidimensional graph is a bipartite graph composed of measures, attributes and aggregates. It is defined as (V, E) where • V is a set of vertices such that V = M ∪ A ∪ G, where M is a set of vertices corresponding to measures, A is a set of vertices corresponding to attributes (parameters) and G is a set of vertices corresponding to aggregates.

Figure 1 :

 1 Figure 1: Relationships between different types of vertices and edges

Figure 2 :

 2 Figure 2: Example of multidimensional graph

Figure 3 :

 3 Figure 3: Designing process of Multidimensional Graph from physical level to conceptual level.

base 5 .Figure 4 :

 54 Figure 4: QBOAribase dataset.

Figure 5 :

 5 Figure 5: Logical and physical implementations of a conceptual Multidimensional Graph.

Figure 6 :

 6 Figure 6: An example of aggregate in RDF model

450 1 . 4 . 5 .

 145 A dimension vertex dim is transformed into (dim) -[:a] -> (:'qb:DimensionProperty') 2. An attribute vertex att is transformed into (a) (lst) -[:a] -> (:'skos:ConceptSchema'), (lst) -[:'skos:hasTopConcept'] -> (att) or (b) (lst) -[:a] -> (:'qb:HierarchicalCodeList'), (lst) -[:'qb:hierarchyRoot'] -> (att) or (c) (level) -[:a] -> (:'qb4o:LevelProperty'), (level) -[:'qb4o:inDimension'] -> (dim), (att) -[:'qb4o:inLevel'] -> (level) 3. An edge E AA is transformed into a standard relationship [:'skos:narrower'] or a customized relationship [:'e_aa'] such as: (lst) -[:a] -> (:'qb:HierarchicalCodeList'), (lst) -[:'qb:parentChildProperty'] -> (e_aa) An edge E M A is transformed into a relationship [:dim] whose label corresponds to the identifier of a dimension, such as: (a) (dim) -[:a] -> (:'qb:DimensionProperty'), (m) -[:a] -> (:'qb:Observation'), (m) -[ :dim] -> (att) or (b) (dim) -[:a] -> (:'qb:DimensionProperty'), (level) -[:a] -> (:'qb4o:LevelProery'), (level) -[:'qb4o:inDimension'] -> (dim), (att) -[:'qb4o:inLevel'] -> (level), (m) -[:a] -> (:'qb:Observation'), (m) -[:dim] -> (att) An aggregate vertex agg i is transformed into (agg i :'qb:Observation' { 'MDGraph:value' : value, 'MDGraph:dim1Name' : 'att1Name', ..., 'MDGraph:dimNName' : 'attNName'}), (agg i ) <-['aggDim1' : 'MDGraph:dim1'] -(att1), ... (agg i ) <-['aggDimN' : 'MDGraph:dimN'] -(attN), (agg i ) -[:'MDGraph:GG'] -> (agg j ) ... (agg i ) -[:'MDGraph:MG'] -> (m i : 'qb:Observation')

Figure 7 :

 7 Figure 7: Relational implementation of the conceptual Multidimensional Graph.

545

  instead of grouping and then reducing vertices and edges in a graph as the graph summarisation does, we aggregate numeric values within measure vertices according to values of attribute vertices from different analysis axes (dimensions) on different granularities (analytical levels) prior to querying. All pre-computed are materialised in a Multidimensional Graph to help reducing the volume of 550 data involved in queries involving aggregates during analyses.As a matter of fact, querying aggregated values in a Multidimensional Graph is not carried out in the same way as in original statistical RDF dataset without pre-computed aggregates. In original statistical RDF dataset, a query computes aggregates on-the-fly according to some grouping conditions and an aggregation function. In a Multidimensional Graph, aggregated measure values are precomputed and can directly be extracted from the data store. In this way, a Multidimensional Graph allows avoiding computing aggregates data on-the-fly from detailed data.

Figure 7 )

 7 , a decision-maker wants to carry out an analysis of average SO2 by city, component and year. Without a Multidimensional Graph, the decision-maker should write the SQL query as shown in Figure 8(a) to compute average SO2 by city, by component and by year from the detailed data. With a Multidimensional Graph, the decisionmaker can directly extract pre-computed aggregated value through the SQL query, as shown in Figure 8(b).

Figure 8 :

 8 Figure 8: Querying with and without pre-computed aggregate in a relational data store.

Figure 9 :

 9 Figure 9: Benchmark Queries

Figure 10 :

 10 Figure 10: Execution time (ms) of each query for the dataset D5.

Figure 11 :

 11 Figure 11: Execution time (in ms) of query Q1 with and without pre-computed aggregates.

Figure 12 :

 12 Figure 12: Execution time (in ms) of query Q13 with and without pre-computed aggregates.

Figure 13 :

 13 Figure 13: Average execution time (in ms) of queries Q2-Q12 in datasets of different volumes.

Figure 14 :

 14 Figure 14: Average execution time (in ms) of queries Q14-Q24 in datasets of different volumes.

First, we formalise

  the concept of aggregates for statistical RDF data. The objective is to represent and materialise pre-computed summarised observation values according to different granularity levels on different analysis axes to avoid on-the-fly computing of detailed data during querying. Second, based on the proposed concept of aggregate, we apply the multidimensional modelling principles to represent statistical RDF data. Our proposed modelling solution makes a distinction between raw statistical RDF data and pre-computed aggregates. It relies on the concepts of bipartite graph composed of measures, attributes and aggregates. It is a a generic modelling solution which can be freely implemented in different data stores. Third, we present a design process to convert statistical RDF data without aggregates at the physical level into the conceptual Multidimensional Graph. During the conversion, the process automatically enriches the Multidimensional Graph by all possible aggregates. Forth, we introduce a transformation process from a conceptual Multidimensional Graph including both original data and aggregates into different logical and physical implementations (RDF, property-graph, column and relational data stores).

  order to convert original RDF data into a conceptual Multidimensional Graph and enrich original data with all possible aggregates, we depict an algovalues of m i according to the related attributes on each dimension 2 A D 1 ×...×A Dn , where A D i ⊆ A is the set of related attribute vertices on D i , such as ∀a j ∈ A D i , a j is associated with m i through one E M A edge or through a set of E AA edges and one E M A edge ;

	Algorithm 1: Designing a MG based on original statistical RDF data
	input : Original RDF data
	output: Conceptual aggregate multidimensional graph
	foreach dimension ?dim in original RDF data, such as ?dim a
	qb:DimensionProperty. do
	create a dimension D i in the multidimensional graph;
	if there exists ?dim qb:codeList ?lst then
	identify each attribute ?att within ?dim , such as
	• ?lst skos:hasTopConcept ?att. or
	• ?lst qb:hierarchyRoot ?att.
	rithm which (a) takes a statistical RDF dataset in QB or QB4OLAP vocabulary
	as input and (b) produces a conceptual Multidimensional Graph including orig-
	inal data and aggregates at output (cf. algorithm 1).
	Algorithm 1 first identifies attributes on each dimension according to QB
	(lines 3 and 4) and QB4OLAP (line 6) vocabularies and creates attribute vertices

else identify each attribute ?att within?dim (?level a qb4o:LevelProery. ?level qb4o:inDimension ?dim), such as ?att qb4o:inLevel ?level ; end foreach identified attribute ?att in original RDF data do create an attribute vertex a i such as a i ∈ A, A ⊆ V ; end create an edge E AA between ?att and ?attUp, such as • ?attUp skos:inSchema ?lst; skos:narrower ?att. or • ?lst a qb:HierarchicalCodeList; qb:parentChildProperty ?p2c. ?attUp skos:inSchema ?lst; ?p2c ?att. end foreach measure ?m in original RDF data, such as ?m a qb:Observation do create an measure vertex m i such as m i ∈ M , M ⊆ V ; identify attribute ?att on dimension ?dim (?dim a qb:DimensionProperty) associated with ?m, such as • ?m ?dim ?att. or • ?level a qb4o:LevelPropery; qb4o:inDimension ?dim. ?att qb4o:inLevel ?level. ?m ?dim ?att. create an edge E M A between ?att and ?m ; end foreach measure m i ∈ M do calculate aggregated create an aggregate vertex g i such as

  E M A edges are created to associate an attribute vertex e A j with a measure vertex e M i . Relationships between attribute vertices are represented through 2.43 × 10 5 E AA edges.

	Then, Algorithm 1 completes the intermediate conceptual Multidimensional
	Graph with pre-computed aggregates G by rolling up on different dimensions at
	different granularities (cf. steps 17-23). To perform the group-by aggregation,
	attribute vertices are used. All 24 combinations of attribute vertices that can
	be used in group-by aggregation as well as their relationships can be found in
	figure 4(b).

Note that the first type of aggregate Station, Sensor, Year corresponds to the original data, while the 16 th types of aggregate compute measure values according to three distinct granularities, namely City, ALL_SE and ALL_Y (1.62× 10 6 vertices and 3.23×10 6 edges). Consequently, the obtained Multidimensional Graph contains pre-computed aggregates represented by 3.57 × 10 10 aggregate vertices, 1.045 × 10 11 E AG edges, 7.63 × 10 10 E M G edges and 3.57 × 10 10 E GG edges. The final conceptual Multidimensional Graph contains different types of vertices. Original raw data are modelled through M and A vertices, while precomputed aggregates are represented through G vertices. These vertices can be implemented in different technical environments. For instance, in a relational

Table 1 :

 1 Similarities and differences across the compared systems.

	Relational databases	MySQL PostGreSQL	Relational Relational	SQL SQL	medium medium	complex complex
	NoSQL	Neo4j Cassandra	Property Graph Column	Cypher CQL	easy complex	easy complex
	RDF triplestore	Jena TDB Virtuoso	RDF RDF	SPARQL SPARQL	easy easy	easy easy
			Model	Query language	Graph implementation	Graph querying

Table 2 :

 2 QBOAirbase datasets of different volumes

	Dataset	Included	Size(GB)	No.	No.
		countries		Observations	Triples
	DS1	England	0.7	147256	1876222
	DS2	England, France 2.5	489035	6331624
	DS3	England, France,	4.6	891632	11631570
		Spain
	DS4	England, France,	7.7	1497442	19343025
		Spain, Germany
	DS5	All countries	15	2842759	36920734
	7. querying multidimensional graphs without aggregates, in Neo4j database;
	8. querying multidimensional graphs with pre-computed aggregates, in Neo4j
	database;
	7.1. Material and methods
	Datasets. We built five datasets based on the QBOAirbase dataset. Each
	dataset includes data related to one or several European countries and weights
	from 0.7GB (about 4.14 million RDF triples) to 15GB (over 81.92 million RDF
	triples). (cf. Table 2). The obtained logical representations are implemented
	at the physical level in different data stores: Jena TDB2 (v.3.6.0), Virtuoso
	(v.7.2.4.2), Cassandra (3.11.2), MySQL (8.0.11), PostgreSQL (10.4) and Neo4j
	(v.3.3.5). Our experiments are carried out in 60 datasets: 5 different data
	volumes (DS1 -DS5) × 2 implementations (with and without aggregates) × 6

Table 3 :

 3

%selectivity: how many triples/observations are retrieved.

  , overall, the average execution time in most data stores increases as the dataset size becomes larger. From DS1 to DS5, in the orig. datasets, the execution time increases by 8.87 times for Jena, 3.80 for Virtuoso, 9.98 for Neo4j, 8.90 for Cassandra, 33.33 for MyQSL and 40.61 for PostGres. For the ag., this runtime decreases for all data stores: 4.38 for Jena, 6.14 for Virtuoso, 0.94 for Neo4j, 19.14 for Cassandra, 12.44 for MyQSL and 21.13 for PostGres. While Virtuoso is less affected by the increasing data volume of datasets without aggregates, Neo4j is less affected with the ag. datasets.Cassandra is the most affected with the increasing of the datasets for both orig. and ag.. Overall, the shortest average runtime is observed for PostGres with the largest for Cassandra.

Table 4 :

 4 Gain after aggregation for DS1 et DS5.

			Jena	Virtuoso Neo4j Cassandra MySQL Postgres
	Without	DS1	66.4%	50.2%	87.8%	87.8%	99.7%	98.8%
	Condition	DS5	83.4%	19.6%	98.8%	73.7%	99.8%	99.4%
	With	DS1	92.1%	84.6%	86.0%	94.9%	99.8%	97.0%
	Condition	DS5	95.7%	95.6%	98.8%	87.3%	100.0%	99.5%

https://www.w3.org/2011/gld/wiki/Data_Cube_Implementations

https://www.w3.org/TR/vocab-data-cube/

https://github.com/iblid/queries

?lst a qb:HierarchicalCodeList; qb:parentChildProperty ?p2c.

http://qweb.cs.aau.dk/qboairbase/

https://www.eea.europa.eu/data-and-maps/data/airbase-the-european-air-quality-database-2

swat.cse.lehigh.edu/projects/lubm/

Acknowledgements

We warmly thank Tianyuan LIU who loaded the datasets in Cassandra, MySQL and PostGres. The authors have been partially supported by the French CIMI Labex project IBLiD (Integration of Big and Linked Data for On-Line Analytics).