A Foundation for Spatio-Textual-Temporal Cube Analytics (Extended Version)

Mohsin Iqbal

Aalborg University

Matteo Lissandrini

Aalborg University

Torben Bach Pedersen

Aalborg University

Large amounts of spatial, textual, and temporal data are being produced daily.
This is data containing an unstructured component (text), a spatial component (geographic position), and a time component (timestamp).
Therefore, there is a need for a powerful and general way of analyzing spatial, textual, and temporal data together.
In this paper, we define and formalize the Spatio-Textual-Temporal Cube structure to enable combined effective and efficient analytical queries over spatial, textual, and temporal data.
Our novel data model over spatio-textual-temporal objects enables novel joint and integrated spatial, textual, and temporal insights that are hard to obtain using existing methods.
Moreover, we introduce the new concept of spatio-textual-temporal measures with associated novel spatio-textual-temporal-OLAP operators.
To allow for efficient large-scale analytics, we present a pre-aggregation framework for exact and approximate computation of spatio-textual-temporal measures.

Our comprehensive experimental evaluation on a real-world Twitter dataset confirms that our proposed methods reduce query response time by 1-5 orders of magnitude compared to the No Materialization baseline and decrease storage cost between 97% and 99.9% compared to the Full Materialization baseline while adding only a negligible overhead in the Spatio-Textual-Temporal Cube construction time.
Moreover, approximate computation achieves an accuracy between 90% and 100% while reducing query response time by 3-5 orders of magnitude compared to No Materialization.

§ INTRODUCTION

Due to the increased usage of mobile devices and advancements in accurate geo-tagging, more and more geo-tagged data is being produced <cit.>.
In particular, social media platforms like Twitter and Facebook are some of the main sources of geo-tagged data, usually in the form of posts, comments, and reviews (e.g., Figure <ref>).
This type of data contains spatial, textual, and temporal (STT) information.
As a result, STT data analysis is becoming increasingly important <cit.> since it allows to extract new insights regarding customer satisfaction, user-generated content shared online, and brand reputation <cit.>.

STT data contains information regarding topics discussed w.r.t. time and location, hence presenting an invaluable link between user opinions and the real world.
For example, STT data can help us analyze an advertisement campaign to identify the best locations for ad placements.
Traditionally, this information is accessed through spatial keyword-queries <cit.>, e.g., to retrieve topics within a certain location, or identify in which locations some topic is discussed.
However, keyword or topic search are point-wise search tasks. Instead, there a significant need to provide more extensive analytics analogous to traditional OLAP-style analytics.
An example STT query is “find the top-k trending hashtags aggregated by topic within a user-defined region (i.e., polygon) around Paris this month".

The traditional data cube model is one of the most widely used tools to analyze structured data.
Since their introduction, data cubes have been extended to analyze different types of data, like sales <cit.>, locations <cit.>, time-series <cit.>, and text <cit.>, but separately.
In particular, some works propose OLAP operators to analyze either textual data <cit.> or spatial data <cit.>.
However, no previous work proposed a unified model and set of operators enabling integrated and joint analysis of STT data.
Moreover, as we propose to jointly analyze STT dimensions together with other dimensions, we are also able to define novel families of measures that have not been studied before, namely spatio-textual and spatio-textual-temporal measures.
These measures, as we show later, allow to produce more advanced analytics instead of, e.g., simple keyword frequency.

Geo-tagged tweet: An example of a STT object

In this paper, we introduce the Spatio-Textual-Temporal Cube (STTCube) to analyze STT data.

Adding spatial, textual, and temporal support to a traditional data cube is not straight-forward due to the presence of $n$$-$$n$ relationships in textual hierarchies and because existing families of measures cannot support joint and integrated analysis involving spatial, textual, and temporal dimensions, e.g., finding the trending keywords grouped by regions, defined by geometry shapes, over a time interval (Section <ref>).
Hence, we introduce new families of measures and OLAP operators that extract combined insights from STT dimensions and measures.
STTCube provides specialized spatio-textual and spatio-textual-temporal measures such as Top-k Dense Keywords within an area and Top-k Volatile Keywords within an area that deliver the integrated aggregates over STT data.
Moreover, a set of analytical operators, namely STT slice, dice, roll-up, and drill-down are proposed.
This results in a data model able to support spatio-textual-temporal OLAP (STTOLAP) operators.
Furthermore, we propose Partial Exact Materialization (PEM) and Partial Approximate Materialization (PAM) methods for efficient exact and approximate computations of STT measures, respectively.
Among other things, we also provide a systematic set of solutions to handle $n$$-$$n$ relationships in textual hierarchies.

In this work, we present the following contributions:

* We extend the standard cube model to add support for spatial, textual, and temporal dimensions and hierarchies and spatio-textual and spatio-textual-temporal measures (<Ref>).

* We propose a set of analytical operators (STTOLAP) over spatio-textual-temporal data (<Ref>).

* We introduce keyword density and keywords volatility as prototypical spatio-textual and spatio-textual-temporal measures (<Ref>).

* We propose a pre-aggregation framework (STTCube materialization) for efficient, exact ((PEM)) and approximate ((PAM)), computation of the proposed spatio-textual-temporal measures (<Ref>).

* We propose techniques for processing spatio-textual-temporal objects and the construction of the STTCube (<Ref>).

* We evaluate the pre-aggregation framework's (PEM and PAM) query response time, storage cost, and accuracy by comparing it with the No STT Cube, Full Materialization, and No Materialization baselines.
Our pre-aggregation framework provides 1-5 orders of magnitude improvement in query response time and a 97% to 99.9% reduction in storage cost with an accuracy between 90% and 100% (<Ref>).

§ RELATED WORK

OLAP and the Data Cube <cit.> are used heavily in business intelligence to obtain insights over the historical, current, and future state of business.
With the emergence of web and social media, an immense amount of unstructured data is being produced, which must be included in the analytical process.
Table <ref> summarizes the state of the art on spatial, textual, and temporal analytics by listing the properties and gaps in the current methods.

The Text-Cube <cit.> allows OLAP-like queries on text data by providing dimensions and hierarchies for terms.
Moreover, it supports the computation of two information retrieval (IR) measures: inverted index and term frequency.
EXODuS <cit.> processes semi-structured document stores (i.e., JSON) using a schema-on-read approach to allow exploratory OLAP on text.
Text OLAP <cit.> extends traditional OLAP to support textual dimensions and  keyword-based top-k search <cit.>.
Yet, all these approaches lack support for spatial and temporal data and the advanced measures and operators required for spatio-textual-temporal analytics.

For spatial data, GeoMiner <cit.> proposes a cube structure for mining characteristics, comparisons, and association rules from geo-spatial data and Spatial cube <cit.> allows to perform spatial OLAP on the semantic web.
Yet, these solutions focus on spatial data only and lack support for textual and temporal data.

There are solutions that combine more than one component of data, e.g., spatio-temporal <cit.>, into the same model but do not provide combined STT analytics.
Among those, the contextualized warehouse <cit.> combines traditional OLAP with a textual warehouse.
This allows the user to provide some keywords, select a market (country or region), retrieve documents matching the keywords as context, and then analyze the facts related to those keywords and documents.
Similarly, Topic Cube <cit.> extends the functionality of a traditional cube and combines probabilistic topic modeling with OLAP by introducing the topic hierarchy.
TwitterSand <cit.> and StreamCube <cit.> exploit textual and spatial information to gain insights by clustering twitter hashtags and tweets in a region, respectively.
STT data is also analyzed to extract events and topics information in TextStreams <cit.> and TopicExploration <cit.>.
Finally, SocialCube <cit.> tries to capture human, social, and cultural behavior by performing linguistic analysis (sentiment analysis) over tweets.
All these approaches focus on the unstructured nature of text along with spatial and temporal data but they do not provide Integrated STT analytics, for example, they do not provide the ability to compute aggregate spatial, textual, temporal, and spatio-textual-temporal measures over spatial, textual, and temporal dimensions and hierarchies.

Spatial top-k keyword-queries <cit.> answer only point-wise queries and do not support aggregation functions or hierarchies.
Thus, they do not support more complex OLAP-style analytical tasks, which we do.
There are methods that solve a very specific task for a specific type of data <cit.>.
These methods are fundamentally different from STTCube because STTCube provides a generic framework for a wide range of STT analytics over different kinds of STT data sources, including, but not limited to, geo-tagged tweets.
Also, STTCube can take advantage of the improvements suggested over other cubes, e.g., Nanocubes <cit.> and DICE <cit.>, making it a powerful tool for OLAP-style STT analytics.

Our summary of related work in Table <ref> shows that no existing method provides integrated support for STT data, unlike STTCube.
To the best of our knowledge, a proper formalization of a data cube model for STT data able to support complex analytics for STT objects at scale is missing.
In particular, no previous method studies dimensions, hierarchies, and measures that allow processing STT data jointly.
Furthermore, the main novel challenge for STT-OLAP is handling $n$$-$$n$ relationships inside the STT dimensions effectively since $n$$-$$n$ relationships do not allow traditional pre-aggregation techniques to be used.
Moreover, arbitrary temporal ranges with multiple levels of granularity adds complexity to STT measures computations.
As a remedy, we propose STTCube which enables the joint and integrated analysis of STT objects by introducing new sets of measures, spatio-textual and spatio-textual-temporal measures, to gain in-depth insights using STTOLAP operators.

§ SPATIO-TEXTUAL-TEMPORAL CUBES

Here, we define the STTCube, an extension of the traditional data cube to allow storage and analysis of STT objects.
Data cubes are used to model and analyze multi-dimensional data.

Definition 1 (Data Cube).
An n-dimensional data cube $\mathcal{CS}_{dc}$ is a tuple $\mathcal{CS}_{dc}$$=$$(D, M, F)$, with a set of dimensions $D$$=$$ \{d_1, d_2, \cdots,$ $d_n\}$, a set of measures $M$$=$$\{m_1, m_2, \cdots, m_k\}$, and a set of facts $F$.
A dimension $d_i$$\in$$D$ has a set of hierarchies $H_{d_i}$.
Each hierarchy $h$$\in$$H_{d_i}$ is organized into a set of levels $L_h$.
Each level $l$$\in$$L_h$ contains a set of members and has a set of attributes $A_l$.
Each attribute $a$$\in$$A_l$ is defined over a domain.
Each measure $m$$\in$$M$ is a function defined over a domain which can return either a single value or a complex object.
The domain of a dimension $d_i$ is denoted by $\delta\left(d_i\right)$

Spatio-Textual-Temporal (STT) Objects
An STT object records place (geo-coordinates or location where it was created), text (a review, or a user comment), and time (when it was created).
Social networks with geo-tagged micro-blog posts are typical STT data sources (e.g., the geo-tagged tweet in Figure <ref>).

Definition 2 (STT object).
A spatio-textual-temporal object is a tuple $obj_{st}$$=$${\langle}$$\lambda, \varphi, \tau$$\rangle$ where $\lambda$, $\varphi$, and $\tau$ represent the location, text, and time components, respectively.

The Location is represented as the latitude and longitude pair $\lambda$$\in$$\left( \mathbb{R}\times\mathbb{R}\right)$.
The Text is an ordered list $\varphi$$=$${\langle}w_1, w_2, \dots, w_n{\rangle}$ where $w_i$$\in$$\mathcal{W}$ is a string and is called a Term.
Among all Terms, keywords are a user-defined subset of important Terms $W_k$$\subseteq$$\mathcal{W}$.
For instance, the user can decide that hashtags  (terms starting with $\#$) have special meaning and are a special type of keyword.
Time specifies a precise instant (a timestamp) to some resolution (e.g., seconds).
Table <ref> contains examples of STT objects with their location, a set of keywords extracted from the text, and timestamp.

§.§ The STTCube Schema

For analytical processing of STT objects we propose to model them as an STTCube.
An STTCube $\mathcal{CS}_{sttc}$$=$$($$D, M, F$$)$ is a data cube (Definition 1) with three special dimensions, namely Location, Text, and Time that is $D = \{d_{Location}, d_{Text}, d_{Time}, d_{4}, \dots, d_{n}\}$.
An STTCube stores STT objects as facts modeling their spatial, textual, and temporal features in the corresponding dimensions.
Figure <ref> shows a 3-dimensional STTCube built on the sample dataset in Table <ref> where each row represents one fact (i.e., the members of $F$) with dimensions $D$$=$$\{d_\textit{Location}, d_\textit{Text}, d_\textit{Time}\}$.
Domains for the respective dimensions are

\begin{align}
\delta\left(d_\textit{Location}\right) &= \left\lbrace \textit{(57.016, 09.991)}, \textit{(56.187, 10.171)}, \dots\right\rbrace \nonumber\\
\delta\left(d_\textit{Text}\right) &= \left\lbrace\textit{apple}, \textit{Fruit}, \textit{\#love}, \dots \right\rbrace \nonumber\\
\delta\left(d_\textit{Time}\right) &=  \left\lbrace \textit{11:12:13 20-10-2019}, \textit{11:18:23 24-10-2019}, \dots\right\rbrace \nonumber
\end{align}

Hence w.r.t. Definition 2, the dimensions capturing $\lambda$, $\varphi$, and $\tau$ are the spatial, textual, and temporal dimensions, respectively.

Dimension Hierarchy.
A hierarchy is spatial, textual, or temporal if it contains spatial, textual, or temporal levels, respectively.
In Figure <ref>, the Location dimension is a spatial dimension with a spatial hierarchy going from $\lambda$ to City, Region, and Country and the Text dimension is a textual dimension aggregating $\varphi$ into the Term, Theme, Topic, and Concept levels.
Similarly, Time is a temporal dimension.
Hierarchy steps $HS_h$$=$$\{hs_1, hs_2, hs_3, \dots, hs_n\}$ define the mechanism of moving from a lower (child) level to an upper (parent) level and vice versa.
A hierarchy step $hs_i$$=$$(l_\downarrow, l_\uparrow, car-$ $dinality)$$\in$$HS_h$ entails that members of a child level $l_\downarrow$ can be aggregated together if they correspond to the same member at the parent level $l_\uparrow$ and that this correspondence between children to parent members has the given $cardinality$$\in$$\{1$$-$$1, 1$$-$$n, n$$-$$1, n$$-$$n\}$.
For instance, the step from Date to Month has an $n$$-$$1$ cardinality, while Term to Topic has an $n$$-$$n$ cardinality (e.g., the Carrot Term correspond both to the Gardening and Food Topics, while the Food Topic has as child members not only Carrot but also Apple).

Level Attributes.
As mentioned earlier, a level $l$ is associated with a set of attributes $A_l$$=$$\{a_1, a_2, \dots, a_n\}$ and has a set of members $l$$=$$\{l_1, l_2, \dots, l_3\}$.
Attribute values describe the different characteristics of each member from that level.
Spatial, textual, and temporal levels are then usually characterized by spatial, textual, and temporal attributes.
For instance, at the City level, member Aalborg has the Boundary attribute whose value is the polygon defining the boundary of Aalborg.
An example of a textual attribute is Sentiment which captures the polarity of the associated textual member.

Similarly, an integer value representing the number of days in a specific month is a temporal attribute.

§.§ Managing STT Hierarchies

We now describe the STTCube's dimensions and hierarchies.

Spatial Dimensions.
Spatial information can be analyzed at different levels and granularities.
It is important to note that facts in an STTCube are composed only by geographical points (i.e., each tweet or user post is associated with a coordinate, not with shapes or polygons).
Points can be aggregated either within a predefined spatial grid or based on semantic information.

Grid-Based Hierarchy.
Here, the geographic area being analyzed is divided into small equal size cells with a predefined resolution, e.g., $1$$\times$$1\,km^{2}$.
At the lowest level, each latitude and longitude point is assigned to the cell they fall in.
To analyze data at a coarser granularity, neighboring cells are combined into a larger cell at the parent level (e.g., $3$$\times$$3\,km^2$).
This hierarchy can be built automatically, without the need for any meta-data.

Semantic-Based Hierarchy.
Here, data is analyzed in a predefined taxonomy, e.g., an administrative division.
Therefore, we move within the taxonomy, e.g., from the Location to the City level, from the City level to the Region level, and so on up to the All level.
This hierarchy requires each object coordinate to be associated with a member in the lowest level in the hierarchy (usually in a pre-processing step) and requires the taxonomy information to build the entire hierarchy.

Textual Dimensions.
Hierarchies in the textual dimension move from specific concepts to general ones.
This follows a generic taxonomic structure connecting more specific terms to more general ones (i.e., hypernyms) <cit.>.
In particular, Terms are the base level which are grouped into Themes, Themes into larger categories called Topics, and Topics in turn grouped into Concepts.

Differently from most hierarchies, the members in the levels of a textual hierarchy are typically in an $n$$-$$n$ relationship.
Hence, when moving between textual levels we need to decide how measure values get aggregated.

Below we propose a set of aggregation techniques to address this issue.

Replication-Based Hierarchy.
This is a common approach where each member of a child level is aggregated into all the parent members. Hence, its value is effectively replicated.
This approach leads to a counting problem when parent levels are further aggregated.

For example, the first data instance in Table <ref> will be part of two Themes: 1) Fruits because it contains Term $\{$apple and fruit$\}$ and 2) Emotion because of Term $\{$#love$\}$.

Majority-Based Hierarchy.
If a fact can be mapped to more than one parent member, then that fact will be part of the parent member which has the most representation (e.g., in terms of frequency).
This scheme avoids double counting of facts in parent members.
In case of ties, some tie-breaking heuristic or a user-defined criterion can be employed instead, e.g., the first fact in Table <ref> will be part of only the Fruits Theme  because it has the two representative Term $\{$apple, fruit$\}$, as compared to Emotion having only one Term $\{$#love$\}$.

Custom Hierarchy.
In general, other user-specified criteria and rules can be defined to establish how child-parent level steps will be aggregated in case of ambiguities.
For instance, a domain-specific importance score can be assigned to the hierarchy members during the STTCube construction.
In this way, facts will be part of only the parent member with the highest importance.

Temporal Dimensions.
Similarly, temporal dimensions allow to analyze STT objects at different levels of granularity w.r.t. time and has the following two temporal hierarchies: $\tau \rightarrow Day \rightarrow Month \rightarrow Quarter \rightarrow Year \rightarrow all$ and $\tau \rightarrow Second \rightarrow Minute \rightarrow Hour \rightarrow all$.

Here, the first contains a hierarchy of Date aggregated by the temporal levels Day, Month, Quarter, and Year (total 5 levels including All), whereas the second is a hierarchy for TimeOfDay having 4 levels in total.

§.§ Spatial, Textual, and Temporal Measures

As defined earlier, an n-dimensional STTCube has a set of measures $M$$=$$\{m_{1}, m_{2}, m_{3}, \dots ,m_{k}$$\}$, which permit to analyze STT objects by computing values at different levels of granularity.
For instance, the STTCube in Figure <ref> models Location, Text, and Time with Fact Count as a measure (i.e., Fact Count$\in$$M$).
In practice, it maintains the count of STT objects at given spatial, textual, and temporal aggregation levels.
Measure values at different levels in the hierarchies are obtained by applying an aggregation function over the STT objects.
Examples of aggregation functions are SUM, COUNT, MIN, MAX, and AVG.
The STTCube in Figure <ref> uses COUNT as an aggregation function.
For example, it reports that on September, 20th at AAU Bus Terminal the Term apple was mentioned in 2 facts.

A measure is spatial if it is defined over a spatial domain.
A spatial measure is then computed over a collection of spatial values (e.g., geographical points, or geometry shapes like polygons).
A spatial measure can be a simple value, e.g., the (numeric) area of the convex hull of multiple shapes, or a complex spatial object, e.g., the polygon representing the convex hull itself.
A measure is textual if it is defined over a textual domain, and can be either a simple numeric value or a complex textual object.
Analogously, a measure is temporal if it is defined over a temporal domain,
A measure is spatio-textual if it is defined over a spatial and textual domain and is a combination of spatial and textual measures.
Finally, a measure is spatio-textual-temporal if it is defined over a spatial, textual, and temporal domain and is a combination of spatial, textual, and temporal measures.
Below, we propose a list of spatio-textual and spatio-textual-temporal measures to be used as part of STTCube to analyze STT objects effectively.

Top-k Keywords within an Area
is a spatio-textual measure which returns a list of tuples ${\langle}\xi,\overrightarrow{kw}{\rangle}$ consisting of a geometry shape $\xi$ representing a geographical area and the list of top-k most frequent keywords $\overrightarrow{kw}$$=$${\langle}w_1,w_2,\dots,w_k{\rangle}$ in that area.
Analogous to previous measures, It can also be computed at different levels of aggregation, so that it can return the top-k keywords for each City or each Region.

Keyword Density
is a spatio-textual measure which returns a list of tuples ${\langle}\xi_i, w_j, \rho_{ij}{\rangle}$ consisting of a geometry shape $\xi_i$ representing a geographical area, a keyword $w_j$, and its density $\rho_{ij}$ in the area $\xi_i$.
The density $\rho_{ij}$ of a keyword $w_j$ over an area $\xi_i$ is
computed as $\rho_{ij}=\frac{\textit{freq}({\xi_i,w_j})}{\textit{SurfaceArea}(\xi_i)}$, in which freq$({\xi_i, w_j})$ is the frequency of the keyword $w_j$ in the area $\xi_i$ (i.e., the number of objects located within $\xi_i$ in which $w_j$ appears) and SurfaceArea is the surface area of $\xi_i$.
For example, if we have two Regions $r_1$, $r_2$ with SurfaceArea$(r_1)$$=$$10$$m^2$, SurfaceArea$(r_2)$$=$$100$$m^2$, and the term Apple with frequency $5$ and $30$ in $r_1$ and $r_2$, respectively (see Figure <ref>),
then, keyword densities are $\rho_1$$=$$0.5$, $\rho_2$$=$$0.3$ for $r_1$ and $r_2$, respectively.

Top-k Dense Keywords within an Area
is a spatio-textual measure which returns a list of tuples ${\langle}\xi_i, \overrightarrow{kw}{\rangle}$ computing the keyword density as described in the measure above, but in this case, it returns the top-k keywords $\overrightarrow{kw}$$=$${\langle}w_1,w_2,\dots,w_k{\rangle}$ with the highest density.

Keyword Volatility
is a spatio-textual-temporal measure (becomes textual-temporal If no region is specified) which returns a list of tuples ${\langle}\xi_i, w_j, T_k, \Delta\rho_{ijk}{\rangle}$ consisting of a geometry shape $\xi_i$ representing a geographical area, a keyword $w_j$, a time interval $T_k$, and its change in density $\Delta\rho_{ijk}$ in the area $\xi_i$ over the time interval $T_k$ (divided into $k$ equal intervals).
The change in density $\Delta\rho_{ijk}$ of a keyword $w_j$ in an area $\xi_i$ over a time interval $T_k$ is
computed as $\Delta\rho_{ijk}$$=$$\frac{\sum_{z=1}^{k}|\rho_{ij_{_z}} - \rho_{ij_{_{z-1}}}|}{k}$, where $\rho_{ij_{_z}}$ represents the density of the keyword $w_j$ in the area $\xi_i$ at a specific time instance $T_{k_z}$.
Furthermore, the change in density computation formula can be updated depending on the analysis requirements, e.g., it can be changed to weighted density (assign different weights to each interval in $T_k$) or to rate of change computation using linear regression <cit.>.

Top-k Volatile Keywords within an Area
is a spatio-textual-temporal measure which returns a list of tuples ${\langle}\xi_i, \overrightarrow{kw}{\rangle}$ computing the keyword volatility as described above, but in this case, it returns the top-k volatile keywords $\overrightarrow{kw}$$=$${\langle}w_1,w_2,\dots,w_k{\rangle}$ with the highest change in density.

Distributive, Algebraic, and Holistic Measures.
There are three types (also known as additivity) of measures: distributive, algebraic, and holistic, depending on whether it is possible to compute the value of a measure at a parent level directly from the values at the child level <cit.>.
For distributive and algebraic measures, this is possible.
For instance, the Fact Count at the State level can be computed by summing up the Fact Counts at the City.
Keyword Density is instead an algebraic measure.
We can compute the higher-level aggregate values of this measure if we store for each child level both the frequency of each keyword and the SurfaceArea.
The Top-k Keywords, the Top-k Dense Keywords, and Top-k Volatile keywords within an area measures, instead, are holistic, since the value at a parent level cannot be computed directly from the values at the child level, but it is necessary to recompute them directly from the base facts every time.

Consider the computation of Top-3 Dense Keywords within an Area in Figure <ref> given the two Regions $r_1$ and $r_2$ with SurfaceArea $10 m^2$ and $100 m^2$, respectively, and the computation at the parent level $r_3$$=$$r_1$$\cup$$r_2$ (grayed-out rows are not part of the computed measure value).
The values in the top-3 for the members $r_1$ and $r_2$ at the child level are not sufficient to compute the correct densities for region $r_3$.
Both, some of the computed density (in column $\rho_{Top-3}$, while the correct values are reported in $\rho_{all}$) and consequently the final ranking, would be wrong.
For instance, the keyword Strawberry would not have been returned (if computed algebraically) because it is neither in the top-3 for $r_1$ nor $r_2$.
To compute the correct response, either we have to store all the aggregate values for each possible cell or we have to reprocess all the facts covered by the query.
When dealing with large datasets these approaches are not feasible.
Hence, in Section <ref> we provide a framework for the computation of an exact and approximate solution with accuracy guarantees.

§.§ STTOLAP Operators

A data cube allows different OnLine Analytical Processing (OLAP) operators to group, filter, and analyze cells and subsets of cells at different levels of granularity and under different perspectives.
Those operators are known as Slice, Dice, Roll-Up, and Drill-Down <cit.>.
We extend the basic OLAP operators to STT-OLAP operators, i.e., for spatial, textual, and temporal dimensions, hierarchies, and measures (Handing of $n$$-$$n$ relationships is explained in Section <ref> and <ref>).
In general, an OLAP (and STTOLAP) operator OP accepts as input a cube $C'$, some parameters params and outputs a new cube $C''$, i.e., OP$(C'$, params$)$$=$$C''$.
In this way, a new OLAP operator can be applied to $C''$.
Among all cubes, we distinguish the initial or base cube $C$ as the cube containing all the original information at the base level.

§ STTOLAP OPERATORS

A data cube allows different OnLine Analytical Processing (OLAP) operators to group, filter, and analyze cells and subsets of cells at different levels of granularity and under different perspectives.
Those operators are known as Slice, Dice, Roll-Up, and Drill-Down <cit.>, and they take as input a cube and produce as output another cube.
In the following, we extend the basic OLAP operators to STTOLAP operators, i.e., for spatial, textual, and temporal dimensions, hierarchies, and measures.
In general, an OLAP (and STTOLAP) operator OP accepts as input a cube $C'$, some parameters params and outputs a new cube $C''$, i.e., OP$(C'$, params$)$$=$$C''$.
In this way, a new OLAP operator can be applied to $C''$.
Among all cubes, we distinguish the initial or base cube $C$ as the cube containing all the original information at the base level.
In the following, we generally assume every OLAP operator OP to have access to $C$ since some operators need access to the base cube $C$ to produce the desired result.

§.§ STT-Slice

Slice operates over the current data cube $C'$ and takes as a parameter a dimension member $v_i$ in a specific level $l_i$ and dimension $d_i$.
It keeps only cells in $C'$ corresponding to $v_i$ and finally removes dimension $d_i$.
An example of the slice operator is “slice location dimension on user-defined polygon representing Aalborg”.

STT-Slice. operator is defined as STTSlice$($$C_{stt}',v_{i}$$)$$=$$C_{stt}''$.
It takes an n-dimensional STTCube $C_{stt}'$ and a member $v_i$ of the level $l_i$ of the spatial, textual, or temporal dimension $d_{Location}$, $d_{Text}$, or $d_{Time}$, respectively, and produces a resulting cube $C_{stt}''$ with $n-1$ dimensions, i.e., it returns measure values aggregated at level $l_i$ only for the member $v_i$ and removes the respective dimension.
The member $v_i$ could be an object in the taxonomy of a semantic-based hierarchy (e.g., Aalborg as a dimension member in $l_{City}$) or could be a grid cell at some granularity level.
Similarly, $v_i$ could be a specific Theme or Topic for the textual dimension and a specific day or month for the temporal dimension.

§.§ STT-Dice

While the slice operator selects and removes a single dimension, the dice operator produces a new cube whose cell contents have been filtered based on a set of conditions (complex predicates, queries covering several cells) but without removing any dimension.
That is, it produces a resulting cube with the same number of dimensions but based on facts that satisfy the provided set of conditions.
Such conditions can use a combination of spatial, textual, temporal, and general-purpose functions.
These functions can perform different computations, e.g., they combine more than one object and return a new single aggregated object, or compare two objects and return a Boolean value, or they can produce a numeric value based on some computation.

The STT-Dice operator selects only cell(s) that satisfy the provided spatial, textual, or temporal logical conditions.
Given a STTCube $C_{stt}'$ and a set of logical conditions COND$_i$, the STTDice is represented as
$STTDice(C_{stt}',\textit{COND}_i) = C_{stt}''$ where COND$_i$ is a set of atomic or compound spatial, textual, or temporal logical conditions.
For instance, it can return only the cell(s) that intersect with the polygon describing a custom region of interest and containing at least $n$ observations, the cell containing only objects whose relevance score with the topic Food is above $0.7$ and that contain at least $10$ terms, or the cells that discuss a specific topic in May 2020.

§.§ STT-Roll-Up

The Roll-Up operator aggregates measure values along a hierarchy by moving from a child level to a parent level.
This allows to move the analysis to a coarser granularity.
An example of this operator is “Roll-Up from City to Country”.

The STT-Roll-Up operator groups facts by aggregating the measure values of all child members that belong to the same parent member in a spatial, textual, or temporal hierarchy.
Given a STTCube $C_{stt}'$, a child level $l_{i\downarrow}$ and a target parent level $l_{i\uparrow}$ (identifying a hierarchy step function $hs_i$ in the spatial, textual, or temporal dimensions), the STTRollUp operator defined as
STTRollUp$(C_{stt}',l_{i\downarrow},l_{i\uparrow}) = C_{stt}''$
produces a new STTCube that has the same number of dimensions and for each measure $m{\in}M$, the aggregation function associated with $m$ is used to create an aggregated measure value for it at the higher parent level.
For instance, when we Roll-Up from City level to the Region level, Fact Count values get summed to compute the new total.
Similarly, “Roll-Up to Topic level from Theme level” groups facts by aggregating the measure values of all Themes that belong to the same Topic and “Roll-Up to Quarter level from Month level” groups facts by aggregating the measure values of all Months that belong to the same Quarter.

§.§ STT-Drill-Down

The inverse of the Roll-Up is the Drill-Down operator which shows data at finer granularity by dis-aggregating measure values along a hierarchy.
An example of the Drill-Down operator is “Drill-Down to City level from Region level”.
For this operation, the base cube is required as we cannot uniquely dis-aggregate measure values knowing only the values at the parent level.

Given an STTCube $C_{stt}'$ at a non-base level $l_{i\uparrow}$ for the spatial ($d_{Location}$), textual ($d_{Text}$), or temporal ($d_{Time}$) dimension and a target child-level $l_{i\downarrow}$ (identifying a hierarchy step function $hs_i$), the STTDrillDown operator SDrillDown$(C_{stt},C_{stt}',$ $l_{i\uparrow},l_{i\downarrow})$$=$$C_{stt}''$ produces a new STTCube at finer granularity computing dis-aggregated measure values along the selected spatial, textual, or temporal hierarchy, respectively.

For instance, STT-Drill-Down can move from the Region level to the City level dis-aggregating the Fact Count of each Region in the counts for each City in that Region.
“Drill-Down to Term from Theme” following the inverse textual hierarchy step Term$\leftarrow$Theme and “Drill-Down to Day from Year” following the inverse temporal hierarchy step Day$\leftarrow$Year are examples of STT-Drill-down operators for textual and temporal dimension, respectively.

§ CUBE MATERIALIZATION

Cube materialization is the process of pre-aggregating measure values at different levels of granularity in the cube to compute query responses from pre-aggregated results instead of the raw data, and hence improve query response time for STTOLAP operators <cit.>.
In a data cube, a cuboid is a collection of level members and associated measure values for a unique combination of dimension hierarchy levels. Each unique combination is represented by a separate cuboid.
For instance, if we request the Fact Count for the State of Denmark and have stored Fact Count at the Region level, we can avoid accessing the raw data and compute the aggregation from much fewer rows.
This is an example of partial materialization, i.e., the actual cuboid at the State level, containing the answer to the query was not materialized, but the system was still able to exploit the cuboid for Region.

What to materialize and how much to materialize depends on the trade-off between query response time and storage cost.
Full Materialization (FM) is obtained by pre-computing measure values for all combinations of levels in all hierarchies.
This approach requires huge storage but achieves the best query response time since every operation can just look up already pre-computed results.
At the other extreme, No Materialization (NM) only materializes the base cuboid and does not require any extra space, but will require aggregated measure values to be recomputed from the base cuboid every time, hence incurring much slower response times.
A middle-ground solution is to partially materialize the cube, i.e., to materialize only some of the possible cuboids.
In this strategy, some queries will be able to exploit pre-aggregated values at the current level, while other queries can exploit pre-aggregated values at lower levels for distributive or algebraic measures.

§.§ Cost Model

The core of the proposed partial materialization approach depends on the trade-off between the storage cost of materializing any particular cuboid and the actual benefit that the materialization of the cuboid provides.
To evaluate this benefit, we have to estimate the (run time) cost of a query.
To devise a cost model for this estimation, we performed a micro-benchmark which confirmed that the running time is directly proportional to the data size (the number of rows). Hence we can use the following linear cost model for benefit calculation[Due to space restrictions, the details and figures of the cost model experiments are available in <Ref>.]

$$\textit{Benefit}(c) = \sum_{c' \in \textit{descendants}(c) \cup \{c\}} \textit{cost}(c')-\textit{size}(c)$$

§.§ Partial Exact Materialization

We propose an exact partial materialization technique for pre-computing the spatio-textual and spatio-textual-temporal measure values.
To answer an STT query for these measures we materialize two other distributive measures, namely Keyword Frequency $f$ and SurfaceArea $a$.
Then, since Keyword Density $\rho$ and Keyword Volatility $\Delta\rho$ are algebraic measures, they can be computed from the values of Keyword Frequency $f$ and SurfaceArea $a$.
Finally, Top-k Dense Keywords and Top-k Volatile keywords are holistic but for an exact solution we materialize Top-ALL and hence, compute it from the materialized measure values (Figure <ref>).

font=scriptsize, skip=0pt
Greedy  Materialization

$(B$, $, K)$
Budget $B$, STTCube , desired top-k $K$
Partially Materialized STTCube
Candidates$\leftarrow\{$$V$$\in$$| {\neg}V.$isMaterialized$\}$
$\overline{V}\leftarrow \max_{{V} \in \textit{Candidates}} \textit{Benefit}({V})$
.materialize$(\overline{V}, K)$

We adopt the chosen linear cost model (Section <ref>) and extend the greedy algorithm approach <cit.> to our task (Algorithm <ref>).
Additionally, and different from <cit.>, Algorithm <ref> accepts an input parameter $K$ and materializes only the top-K measures values in each cuboid.
For instance, for $K=10$, it will materialize the top-$10$ keywords in each cuboid.
Then, any top-k query, with $k{\leq}K$, for a materialized cuboid will return the pre-computed answer.

Algorithm <ref>, given a size budget $B$ (measured in rows, cuboids, or GB), proceeds until the size of the current cube is as large as possible within the budget (Line 6).
At each step, it selects among all the non-materialized cuboids (Line 3) the one with the highest benefit (Line 4) and  materializes it (Line 5).
The difference between the exact (PEM) and approximate (PAM) materialization using Algorithm <ref> is the value of $K$.
When $K$$=$$\infty$ the full sorted list of measure values will be stored so that all top-k queries can be answered for that cuboid.
We set $K$$=$$\infty$ and $K$$=$$n$ (to materialize only top $n$ measure values) for PEM and PAM, respectively.

Query rewriting.
Finally, as in <cit.>, after STTCube materialization, queries are still formulated in terms of the base cuboid but rewritten by the system to be evaluated over the smallest cuboid.

§.§ Partial Approximate Materialization

As a result of the materialization performed by Algorithm <ref>, when querying a non-materialized cuboid, we can directly exploit values in the cuboid's materialized ancestors when computing all distributive and algebraic measures.
On the other hand, for holistic measures, we have to perform some additional computation.
For instance, as mentioned earlier, to compute the value for the Top-k Dense Keywords in an area we can exploit the pre-computed Keyword Density values, but then we need to perform the top-k selection.
That is, if the top-k for the current view is not materialized, we cannot exploit the materialized top-k of the ancestor views without incurring the risk of returning the wrong result.

Yet, it is possible to exploit the top-k computation in some materialized cuboid to retrieve an approximate top-k and estimate the result's accuracy <cit.>.
In practice, for the Top-k Dense Keywords within an area, given a target k for the top-k computation, when materializing a cuboid, we materialize the top-k+1 most dense keywords for that cuboid (i.e., set $K$=$k$+$1$ in Algorithm <ref>).
Then, to compute the top-k dense keywords for a descendant cuboid by exploiting a materialized ancestor cuboid, we determine which members of the list are guaranteed to be correct.

Algorithm <ref> implements this computation for Top-k Volatile Keywords within an area.
It receives as input the set $\Phi$$=$$\{{\langle}\xi_1, \overrightarrow{kw_1},$ $T_1{\rangle},$$ {\langle}\xi_2, \overrightarrow{kw_2}, T_2{\rangle}, \dots, {\langle}\xi_n, \overrightarrow{kw_n}, T_n{\rangle} \}$ of lists of top-K (i.e., k+1) dense keywords in a specific area with respective time stamps, time interval $T_x$ divided into x equal-sized interval (e.g., day or month), and the value for $k$.
The output is the ranked list of top-k volatile keywords in the area $\xi$ that is composed by the merging of the areas $\xi_1,\xi_2,\dots,\xi_n$.
It computes the SurfaceArea of the merged area $\xi$ (lines 2).
Then it merges all the aggregated keyword frequencies (line 10) and change in keyword frequencies (line 11) for each time instance in $T_x$(line 7) in respective dictionaries $\overline{kw}$ and $\Delta f$ (lines 4-13) by getting each keyword in each list (line 8) and the corresponding frequencies (line 9).
If a keyword is not found in the $\overline{kw}$, $\Delta f$, or $prev_{_f}$ dictionary then its value is considered to be zero.
Moreover, it keeps track of the upper-bound $\epsilon$ frequency for keywords outside the current materialized ranking for possible error reporting (line 13).
Once all frequencies and changes in frequencies are merged, we compute the top-k volatile keywords using the aggregated values (line 14).
Finally, by comparing the value of $\epsilon$ with the frequencies of keywords in the aggregated top-k, we report how many positions in the current ranking are guaranteed to be exact (line 15).
In the best case, the frequency of the keyword at position $k$ will be at least $\epsilon$ and thus the computed top-k is guaranteed to be correct.

§ STTCUBE CONSTRUCTION

Here, we describe the proposed approach for constructing an STTCube.
Algorithm <ref> takes a collection $\mathcal{X}$ of STT objects to be analyzed, a textual taxonomy $\mathcal{T}$ with semantic information about the terms, themes, topics, and concepts, and a geographical taxonomy $\mathcal{G}$ for cities, regions, and countries.
Standard date functions are used for the temporal dimension processing.

Moreover, it also receives as input the parameters $B$ and $K$ as the budget and number of top-K keywords for the partial materialization.

Algorithm <ref> constructs the STTCube in an incremental way, it initializes an empty cube (line 2), and then the corresponding spatial, textual, and temporal dimensions (lines 3-5) as well as the Fact Table (line 6).
If the cube is already constructed, i.e., the cube is being updated instead of constructed for the first time, then Algorithm <ref> loads the existing STTCube (lines 2-6) and updates it with new information.
In particular, the spatial dimension has the grid-based hierarchy and the hierarchy with the base level at each object's Location (i.e., the geographical point), and then the levels City, Region, Country, and All (5 levels in total).
The textual dimension, instead, has the hierarchy build from the base level Term, and then Theme, Topic, Concept, and All (5 levels in total).
Finally, the temporal dimension contains the Date and TimeOfDay hierarchies mentioned in Section <ref>.

Once the basic structure is prepared, Algorithm <ref> loops through each STT object in $\mathcal{X}$ (lines 8-13).
In this loop, it extracts and initializes from each STT object the base-level members for each dimension.
Then, once the base level data has been extracted, it proceeds with building the various dimension hierarchies starting from the existing base-level members and exploiting the provided spatial and textual taxonomies (lines 8-12).
Once the dimension hierarchies are built, the STT object itself is then inserted in the fact table of the STTCube (line 13) so that each fact is linked to the lowest (base) level members in the respective dimensions.
In this step (line 13), the fact measure values are also computed (e.g., the keyword count).
As the last step (line 14) Algorithm <ref> executes the (partial) materialization procedure.

Spatial Hierarchies Construction.
In our proposed STTCube the base level for the spatial hierarchies is the Location present in the raw data, i.e., the longitude and latitude points.
Hence, we use Military Grid Reference System (MGRS) for grid-based hierarchy and  when building the semantic-based hierarchy, individual points are linked to the respective cities using the information in the available geographical taxonomy $\mathcal{G}$, or to a special member for points that link to unknown locations.
Therefore, this corresponds to the step function from Location to City.
The spatial taxonomy $\mathcal{G}$ is also used to generate the spatial hierarchy step functions for the higher levels.

Textual Hierarchies Construction.
The unstructured nature of the text makes it a challenging task to convert it into a dimension of a cube.
In Algorithm <ref>, the  function (line 11) implements the following steps: (1) splits the text into individual words, (2) removes stop words, and (3) converts the remaining words to their base form (e.g., “works” and  “working” have the same base form “work”).
The final processed text is used to populate the Term base-level in the textual dimension.
This implements the base step function in the textual hierarchies, and links every fact to one or more Terms, hence it has an $n$$-$$n$ cardinality.
Moreover, while constructing the higher levels, using the semantic taxonomy $\mathcal{T}$ (e.g., WordNet), each STT object is linked to one or more Themes, and similarly for Topics, and Concepts.

§ EXPERIMENTAL EVALUATION

Now, we report on the performance of STTCube analysis.
In particular, we compare the different materialization strategies for STTCube and No STTCube (NC) implementations, in terms of query response time (QRT) and storage cost.
NC answers the queries by computing the query response from base data without constructing the STTCube.
NC stores pre-processed text, lemmatized text after removal of stop and invalid words, along with the geographical location, longitude and latitude point, and timestamp.
Specifically, NC uses user-defined functions for text (for retrieving individual terms) and location processing (e.g., identification of the city a particular longitude, latitude point belongs to) and built-in functions for timestamp.
Further, NC filters on location and timestamp for the queried area and time and performs a series of joins, e.g., 4 joins for Concept level, to retrieve information for the requested textual level.
Finally, it groups results on the textual and temporal columns, computes the STT measure values, and performs the top-k selection.
Also, we compare QRT and hierarchy construction time for different combinations of hierarchy schemes.
Moreover, we also report on the accuracy of PAM and demonstrate the advantage in performance when compared to PEM.
Lastly, we compare QRTs for different spatial and textual hierarchy schemes, showing that combinations of Grid-based spatial and Majority-based textual (GM) hierarchy scheme achieves the fastest QRTs among all hierarchy combinations.

Experimental Setup.
We evaluate the STTCube on a real-world Twitter dataset containing 125 million tweets collected over six weeks.
Each tweet contains the tweet location, text, and time.
We implemented the STTCube in a leading commercial RDBMS, called RDBMS-X as we cannot disclose the name.
The proposed design is realized using a snowflake schema to avoid redundancy in the dimension data.

We implemented the Pre-Processing (PP) component, where the whole raw dataset is parsed and the relational tables are populated, in Java (v11).
All tests are run on a Windows Server machine with 2 Intel Xeon 2.50GHz CPUs and 16GB RAM.

We extracted the taxonomy for the spatial dimension from GeoNames <cit.>.
For the City level, we considered all the cities having $population > 1000$ and for the Region level, we use administrative divisions information available in the GeoNames dataset.
We use the reverse geocoding process to find the city name for the Location coordinates.

For the textual dimension, as a taxonomy for Terms, Themes, Topics, and Concepts, we use the widely used WordNet <cit.>.
We use the direct HYPERNYM link of WordNet to decide the parent member for a Term, Theme, and Topic.
If a term is present in WordNet and has a super-class (HYPERNYM) then the super-class becomes the parent of the term. Otherwise, it becomes its own parent (this avoid unbalanced hierarchies and UNKNOWN values in the hierarchy).
For text pre-processing –tokenization, lemmatization, and stop word removal– we use the Stanford Core NLP library <cit.>.
We implemented the temporal dimension using the standard Date and Time functions supported in RDBMS-X.

We implemented the semantic-based and grid-based hierarchy schemes for the spatial dimension, replication-based and majority-based hierarchy schemes for the textual dimension (Section <ref>), and Date hierarchy for the temporal dimension.

Spatial, Textual, and Temporal Levels Members. The base levels contain $40.1$ million unique Location Points and $9.8$ million unique Terms.
The GeoNames taxonomy contains $132K$ cities, divided into $4K$ administrative divisions (regions) for $247$ countries.
Among those, we have tweets for $104K$ cities, $3.8K$ regions, and $246$ distinct countries.
In the textual hierarchy, terms are grouped into $23.8K$ Themes, $19.4K$ Topics, and $17.6K$ Concepts.
Furthermore, the temporal dimension spans over $37$ days.
Finally, for PAM we materialize $K$$=$$31$ densest keywords.

We implemented Keyword Density, Keyword Volatility, Top-k Dense Keywords within an area, and Top-k Volatile Keywords within an area as prototypical STT measures.
We compare (PEM) and  (PAM) strategies with the following three baselines.
No STTCube (NC): is the traditional RDBMS setup with all textual, spatial, and temporal functions implemented as built-in or user-defined functions.
NC is the traditional solution one would go for without the STTCube.
No Materialization (NM): constructs the STTCube and minimizes the storage cost by only materializing the base cuboid and computing all query responses from it.
Full Materialization (FM): minimizes the QRT by materializing every cuboid in the STTCube. With this approach queries are answered through a lookup in the pre-computed cuboid.
These three baselines are at the extreme ends of the space-time trade-off and are usually infeasible for large datasets.

We perform experiments on five different sizes of datasets using nine different STT queries.
Each STT query, described in Table <ref>, targets a different level of spatial, textual, and temporal granularity.
Each query requests either dense or volatile keywords with a range of time which is used for volatile but not used for dense keywords queries.
We execute each query ten times with randomly generated parameters for each method and report mean and standard deviation.

Query Response Time.
For Top-k Dense and Top-k Volatile Keywords within an area measures, we compare the QRT of PEM and PAM methods with the NC, NM, and FM baselines.
For Keyword Density and Keyword Volatility, no approximate solution is possible so we only compare PEM with NC, NM, and FM.
As the Majority-based textual hierarchy scheme does not process Terms (Section <ref>), we only evaluate five out of nine queries requesting Theme, Topic, and Concept for it (Figures <ref>e—<ref>h).

Furthermore, we cannot evaluate PAM for Q9 as no approximate solution is possible for it.

We plot results in Figures <ref>a—<ref>h for 100% (125M) of data, as the results are similar for smaller data sizes.
Each row in Figure <ref> shows the QRTs for one particular combination of spatio-textual hierarchy schemes.
Specifically, Figures <ref>a—<ref>d show the QRTs for the Grid-based spatial and Replication-based textual (GR) hierarchy combination for all measures.
Similarly, Figures <ref>e—<ref>h show QRTs for Grid-based spatial and Majority-based textual (GM) combinations[Due to space constraint we have omitted the figures for Semantic-based spatial hierarchy (can be found in Appendices <Ref>) as we observed similar results].

Figure <ref> has queries on the x-axis and QRTs in msec on the y-axis (note: log scale).
Figure <ref> confirms that NC is $1$$-$$5$ orders of magnitude slower than NM.
Specifically, regardless of the spatial hierarchy scheme, it is $1$$-$$2$ and $3$$-$$5$ orders of magnitude slower than NM for Replication-based and Majority-based textual hierarchy, respectively.
The Majority-based textual hierarchy scheme achieves faster QRTs because it does not process individual Terms but directly links Theme to the fact, hence, drastically reducing the number of rows to process (from millions to thousands).
Furthermore, NM is $1$$-$$4$ and $3$$-$$5$ orders of magnitude slower than PEM and PAM, respectively, for all measures and combinations of hierarchy schemes.
PEM is on average six times slower than FM which achieves its fast QRTs at the expense of a highly increased storage cost (Figure fig:MemoryComparison).
PAM achieves near-optimal QRTs because it materializes only the K densest keywords in the cuboid, hence it has much fewer rows to process.
QRTs for Q9 for Top-k Volatile Keyword within an area and Top-k Dense Keywords within an area measures for all combinations of hierarchy schemes are the worst for PAM (same as NM) because it requests ALL keywords' densities instead of top-k which cannot be computed from the approximate pre-aggregated information.
To generate a response for Q9, we have to process all detail data directly from the base facts.
In comparison, PEM and PAM materialize a subset of views (also a subset of rows for PAM) and use the pre-aggregated measure values in those views to efficiently generate a response for a query instead of processing base facts, thus improving the overall QRT.
NC is the slowest of all ($1-5$ orders of magnitude slower than the slowest STTCube NM) because it has to process the complete dataset for computing each query response, and cannot take advantage of the STTCube optimizations for STT measures.
Among all the hierarchy scheme combinations, GM has the fastest QRTs mainly because of Majority-based which drastically reduces the row count by linking the Theme directly to each Fact instead of individual Terms, whereas, GR has the slowest QRTs due to Replication-based having far more rows to process than Majority-based textual hierarchy.
Furthermore, Grid and Semantic-based spatial hierarchies have similar QRTs.

Figure <ref> shows the scalability of PEM and PAM over growing data sizes for different combinations of hierarchy schemes and confirms that the QRTs are almost constant as the data grows.
This is because the sizes of materialized views do not increase a lot as the data grows.
Only new dimension members, e.g., new cities or topics, increase the size of materialized views, but only by a small fraction.
Figures <ref>f—<ref>j confirm that the GM hierarchy combination results in the fastest QRTs, i.e., all QRTs $<$ 100 msec.
On the contrary, Figures <ref>a—<ref>e show that GR yields the slowest QRTs, with QRT as high as 400 msec.
Figure <ref> confirms that PAM consistently achieves the fastest QRTs (mostly $<$ 100 msec with few a bit over 100 msec) regardless of hierarchy schemes.
Figure <ref> shows that PEM and PAM scale linearly w.r.t. data size.

Storage Cost.

We now compare the storage cost for FM, PEM, PAM, and NM.
We do not compare NC's storage cost because it does not construct STTCube, and hence does not materialize anything.
We only show the storage cost for up to 20 million because FM takes an unfeasible amount of time (shown in Figure fig:PPCC) while for the other methods and over the larger datasets we observe the same trend.
We use the number of rows in a view as its storage cost.
The base cube's storage cost is always needed.
Besides that, every additional materialized view adds to the storage cost, as displayed in Figure fig:MemoryComparison, that shows the storage cost of NM, PAM, PEM, and FM over growing data sizes.

The materialization of the STTCube using PEM and PAM only adds 13%  and 0.1% to the storage cost of the base cube, respectively.
Whereas, using FM increases the storage cost by more than an order of magnitude.
PEM reduces the storage cost by only materializing a subset of views (four views) and still achieves 2-5 orders of magnitude improvement in QRT (Figures <ref>).
PAM further reduces the storage cost by only materializing a subset of rows in a view (top-k) and gains an additional order of magnitude improvement in QRT.
On the other hand, FM materializes all views in a cube, i.e., 500 ($5\times5\times5\times4$) views in our case, which makes the view materialization storage cost much higher (one order of magnitude) than the base cube itself, as shown in Figure fig:MemoryComparison.
Figure fig:MemoryComparison confirms that our proposed methods PEM and PAM reduce the storage cost between 97% and 99.9% compared to FM.

Views Selection for Materialization.
Our proposed methods PEM and PAM are partial materialization methods that materialize only a subset of the cuboids.
Hence, an important trade-off to be understood is between the number of cuboids to materialize, the corresponding storage cost, and the gain in query response time achieved.
We empirically evaluate the benefit gained (improvements in QRT for all dependent cells which can be answered using this view) against the cost of materializing the view (Algorithm <ref>).

We consider the base cube as a necessary view to be materialized and consider its benefit as zero.
Figure fig:ViewsVsBenefit shows that materializing three cuboids ((Day, City, Term), (Day, Location, Theme), and (Day, Region, Term)) on top of the base cube gain the most benefit after which we do not get a significant advantage of materializing further cuboids.
The reason is that the materialized cuboids are already small enough, so the benefit of materializing any descendant cuboid is small.
Hence, materializing 4 cuboids represents the best trade-off between QRT and storage cost.

Pre-Processing and Cube Construction.
Here, we report the time for the construction of  STTCube.
Construction of an STTCube is divided into two steps: 1) Pre-Processing (PP) of base facts (spatio-textual-temporal objects) and population of the relational tables and 2) materialization of views.
Further, the materialization of views can be done either using FM, PEM, or PAM.
In Figure fig:PPCC, we have data sizes on the x-axis and time in minutes on the y-axis (note: log scale).

FM is the most time consuming among all and adds significant overhead on top of PP time and does not scale.
On the contrary, PEM and PAM time is negligible compared to the FM time.
Hence, with PEM and PAM STTCube construction time scales linearly.
To evaluate STTCube's ability to handle updates, we performed several updates of 4M tweets each (PP_INC line in Figure fig:PPCC).
Experiments confirm that STTCube handles updates efficiently by only processing the new STT objects and updating the respective dimensions and measures.

Furthermore, we compare the different hierarchy schemes w.r.t. their construction time.
Figure fig:PPCC_ALL shows the hierarchies' construction time for different hierarchy schemes.

It is evident from Figure fig:PPCC_ALL that, among all, the Replication-based textual hierarchy scheme takes the longest to construct because for each single spatio-textual-temporal object it has to process each individual Term and construct hierarchy for it.
Whereas, for all other schemes, for each spatio-textual-temporal object only one hierarchy instance is processed.
Figure fig:PPCC_ALL confirms that all of the hierarchy schemes are constructed in linear time w.r.t. data size, allowing STTCube to support multiple hierarchy schemes.

Given that PAM efficiently computes the approximate measure values, it becomes necessary to evaluate its accuracy.
To evaluate the accuracy of PAM, we use NM's results as ground truth.
Our evaluation result in Table tab:accuracy confirms that it achieves high accuracy.
Specifically, it is 100% for 6 out of 8 queries, and 90-97% for 2.
Queries with 90-97% accuracy request as many keywords as are materialized and the risk of having wrong results near the border (bottom of the top-k list) is higher.

QRT of STTOLAP Operators.
Our proposed materialization strategies (PEM and PAM) improves the QRTs for STTOLAP operators.
To demonstrate this, we perform a series of STTOLAP operations and measure their QRT for different materialization strategies.
Figure fig:STTOLAP shows the QRTs for multiple STTOLAP operations for different materialization strategies.
We have STTOLAP operators on the x-axis (RU, D, S, and DD represents STT Roll Up, Dice, Slice, and Drill Down operators, respectively) on QRT in msec on the y-axis.
It is evident that NM is on average 3-5 orders of magnitude slower than PEM which is one order of magnitude slower than PAM.
Furthermore, PAM achieves near-optimal QRTs, just a fraction higher than FM.
These experiments confirm that STTCube's materialization methods (PEM and PAM) improves STTOLAP operators' QRTs by materializing only a subset of cuboids.

Top-K Value Estimation.
Here, we study the relationship between QRT and the value of materialized $K$.

We create seven different STTCube materialization versions using 10, 20, 50, 100, 200, 500, and 1000 as the value of $K$.
Next, we use the Gamma distribution to generate 100 random numbers, to be used as top-k values, in the range of 1 and 1000.
We chose the Gamma distribution because it resembles a common long-tail distribution for top-k values.

We execute each query for all the 100 generated top-k values over all seven materialization versions.
Figure fig:TopKAnalysis shows the QRT for all queries over different materialization versions.

For $K$$=$$10$ and $20$ the median value is the same as the box top, hence not visible in the plot.
It is evident from Figure fig:TopKAnalysis that a larger value of materialized $K$ achieves faster QRTs (lower median value) because almost all the queries are answered using the pre-computed measure values.

But, in the case of smaller $K$, all the queries requesting $k$$>$$K$ need to be answered using the non-pre-computed measure values from the base cuboid.
Hence, resulting in slower QRTs (higher median value).
A larger value of $K$ such as $1000$ is not recommended because 1) there will be very few queries requesting a larger top-k and 2) it will require more storage cost (Figure fig:MemoryComparison).
Specifically, between $K$$=$$50$ and $100$ and $K$$=$$100$ and $200$ QRT decrease by 35% and 0% but storage increase 250% and 200%, respectively.
Hence, these experiments confirm that choosing a value between 20—50 for $K$ in our current experiments settings is a near-optimal choice.

§ CONCLUSION AND FUTURE WORK

In this paper, we defined and formalized the Spatio-Textual-Temp-oral Cube (STTCube) structure to effectively perform STTCube analytics.
We introduced STT hierarchies, spatio-textual and spatio-textual-temporal measures, and STTOLAP operators to analyze STT data together.

For efficient, exact and approximate, computation of STT measures, we proposed a pre-aggregation framework able to provide faster response times by requiring a controlled amount of extra storage to store pre-computed measure values.

We observed how the partial materialization provides 1 to 5 orders of magnitude reduction in query response time, with between 97% and 99.9% reduced storage cost compared to full materialization techniques.
Moreover, the approximate materialization provides accuracy between 90% and 100%, while requiring considerably less space compared to no materialization techniques.

In future work, we plan to enhance STTCube with additional STT measures and distributed implementation.

#1     #1#1#1     #1     #1     #1     #1#1          #1#1

Accessed: 2020-09-09.

[Almaslukh, Magdy, Aly, Mokbel, Elnikety, He,
Nath, and ArefAlmaslukh et al2019]
authorpersonA. Almaslukh, personA. Magdy,
personA. M. Aly, personM. F. Mokbel,
personS. Elnikety, personY. He, personS.
Nath, and personW. G. Aref. year2019.
Local trend discovery on real-time microblogs with
uncertain locations in tight memory environments.
journalGeoInformatica (year2019).

[Azabou, Khrouf, Feki, Soulé-Dupuy,
and VallèsAzabou et al2016]
authorpersonM. Azabou, personK. Khrouf,
personJ. Feki, personC. Soulé-Dupuy, and
personN. Vallès. year2016.
Analyzing textual documents with new OLAP
journalAICCSA (year2016).

[Cao, Chen, Cong, Jensen, Qu, Skovsgaard, Wu,
and YiuCao et al2012]
authorpersonX. Cao, personL. Chen,
personG. Cong, personC. S. Jensen,
personQ. Qu, personA. Skovsgaard, personD.
Wu, and personM. L. Yiu. year2012.
Spatial Keyword Querying.
journalER (year2012).

[Chen, Cong, Jensen, and WuChen
et al2013]
authorpersonL. Chen, personG. Cong,
personC. S. Jensen, and personD. Wu.
Spatial Keyword Query Processing: An Experimental
journalPVLDB (year2013).

[Chen, Dong, Han, Wah, and WangChen
et al2002]
authorpersonY. Chen, personG. Dong,
personJ. Han, personB. W. Wah, and
personJ. Wang. year2002.
Multi-dimensional Regression Analysis of
Time-series Data Streams.
journalVLDB (year2002).

[Chouder, Rizzi, and ChalalChouder
et al2019]
authorpersonM. L. Chouder, personS. Rizzi,
and personR. Chalal. year2019.
Exploratory OLAP over Doc Stores.
journalIS (year2019).

[Cong, Feng, and ZhaoCong
et al2016]
authorpersonG. Cong, personK. Feng,
and personK. Zhao. year2016.
Querying and mining geo-textual data for
exploration: Challenges and opportunities.
journalICDEW (year2016).

[Cong and JensenCong and Jensen2016]
authorpersonG. Cong and personC. S.
Jensen. year2016.
Spatial Keyword Queries and Beyond.
journalSIGMOD (year2016).

[Ding, Zhao, Lin, Han, Zhai,
Srivastava, and OzaDing et al2011]
authorpersonB. Ding, personB. Zhao,
personC. X. Lin, personJ. Han,
personC. Zhai, personA. Srivastava, and
personN. C. Oza. year2011.
Efficient Keyword-Based Search for Top-K Cells in
Text Cube.
journalTKDE (year2011).

authorpersonC. Fellbaum.
WordNet: An Electronic Lexical Database.
journalMIT Press (year1998).

[Feng, Zhang, Zhang, Han, Wang, Aggarwal, and
HuangFeng et al2015]
authorpersonW. Feng, personC. Zhang,
personW. Zhang, personJ. Han, personJ.
Wang, personC. Aggarwal, and personJ. Huang.
STREAMCUBE: Hierarchical spatio-temporal hashtag
clustering for event exploration over the Twitter stream.
journalICDE (year2015).

[Gray, Bosworth, Lyaman, and
PiraheshGray et al1996]
authorpersonJ. Gray, personA. Bosworth,
personA. Lyaman, and personH. Pirahesh.
Data cube: a relational aggregation operator
generalizing GROUP-BY, CROSS-TAB, and SUB-TOTALS.
journalICDE (year1996).

[Gür, Pedersen, Zimanyi, and HoseGür
et al2017]
authorpersonN. Gür, personT. B. Pedersen,
personE. Zimanyi, and personK. Hose.
A foundation for spatial data warehouses on the
Semantic Web.
journalSemantic Web (year2017).

[Han, Koperski, and StefanovicHan
et al1997]
authorpersonJ. Han, personK. Koperski,
and personN. Stefanovic. year1997.
GeoMiner: A System Prototype for Spatial Data
journalSIGMOD (year1997).

[Harinarayan, Rajaraman, and
UllmanHarinarayan et al1996]
authorpersonV. Harinarayan, personA.
Rajaraman, and personJ. D. Ullman.
Implementing data cubes efficiently.
journalSIGMOD (year1996).

[Jayachandran, Tunga, Kamat, and
NandiJayachandran et al2014]
authorpersonP. Jayachandran, personK.
Tunga, personN. Kamat, and personA. Nandi.
Combining User Interaction, Speculative Query
Execution and Sampling in the DICE System.
journalICDE (year2014).

[Jensen, Pedersen, and ThomsenJensen
et al2010]
authorpersonC. S. Jensen, personT. B.
Pedersen, and personC. Thomsen.
booktitleMultidimensional Databases and Data
publisherMorgan & Claypool Publishers.

[Kenney and KeepingKenney and
authorpersonJ. F. Kenney and personE. S.
Keeping. year1962.
Mathematics of Statistics, Part 1, chapter 15.
journalvan Nostrand (year1962).

[Knijff, Frasincar, and HogenboomKnijff
et al2013]
authorpersonJ. D. Knijff, personF.
Frasincar, and personF. Hogenboom.
Domain taxonomy learning from text: The subsumption
method versus hierarchical clustering.
journalDKE (year2013).

[Lieberman, Samet, Sankaranarayanan, and
SperlingLieberman et al2007]
authorpersonM. D. Lieberman, personH.
Samet, personJ. Sankaranarayanan, and personJ.
Sperling. year2007.
STEWARD: Architecture of a Spatio-textual Search
journalGIS (year2007).

[Lin, Ding, Han, Zhu, and ZhaoLin
et al2008]
authorpersonC. X. Lin, personB. Ding,
personJ. Han, personF. Zhu, and personB.
Zhao. year2008.
Text Cube: Computing IR Measures for
Multidimensional Text Database Analysis.
journalICDM (year2008).

[Lins, Klosowski, and ScheideggerLins
et al2013]
authorpersonL. Lins, personJ. T. Klosowski,
and personC. E. Scheidegger. year2013.
Nanocubes for real-time exploration of
spatiotemporal datasets.
journalTVCG (year2013).

[Liu, Tang, Hancock, Han, Song, Xu, and
PokornyLiu et al2013]
authorpersonX. Liu, personK. Tang,
personJ. Hancock, personJ. Han, personM.
Song, personR. Xu, and personB. Pokorny.
A Text Cube Approach to Human Social and Cultural
Behavior in the Twitter Stream.
journalSBP (year2013).

[Magdy, Abdelhafeez, Kang, Ong, and
MokbelMagdy et al2020]
authorpersonA. Magdy, personL. Abdelhafeez,
personY. Kang, personE. Ong, and
personM.F. Mokbel. year2020.
Microblogs data management: a survey.
journalThe VLDB Journal (year2020).

[Manning, Surdeanu, Bauer, Finkel, Bethard, and
McCloskyManning et al2014]
authorpersonC. Manning, personM. Surdeanu,
personJ. Bauer, personJ. Finkel, personS.
Bethard, and personD. McClosky.
The Stanford CoreNLP natural language processing
journalACL (year2014).

[Othman, Belkaroui, and FaizOthman
et al2016]
authorpersonR. Othman, personR. Belkaroui,
and personR. Faiz. year2016.
Customer Opinion Summarization Based on Twitter
journalWIMS (year2016).

[Pat and KanzaPat and Kanza2017]
authorpersonB. Pat and personY. Kanza.
Where's Waldo?: Geosocial Search over Myriad
Geotagged Posts.
journalSIGSPATIAL (year2017).

[Pérez-Martínez, Berlanga-Llavori,
Aramburu-Cabo, and PedersenPérez-Martínez et al2008]
authorpersonJ. M. Pérez-Martínez,
personR. Berlanga-Llavori, personM. J. Aramburu-Cabo,
and personT. B. Pedersen. year2008.
Contextualizing Data Warehouses with Documents.
journalDSS (year2008).

[Sankaranarayanan, Samet, Teitler, Lieberman,
and SperlingSankaranarayanan et al2009]
authorpersonJ. Sankaranarayanan, personH.
Samet, personB. E. Teitler, personM. D. Lieberman,
and personJ. Sperling. year2009.
TwitterStand: News in Tweets.
journalSIGSPATIAL (year2009).

[Simitsis, Baid, Sismanis, and
ReinwaldSimitsis et al2008]
authorpersonA. Simitsis, personA. Baid,
personY. Sismanis, and personB. Reinwald.
Multidimensional content eXploration.
journalPVLDB (year2008).

[Skovsgaard, Sidlauskas, and JensenSkovsgaard
et al2014]
authorpersonA. Skovsgaard, personD.
Sidlauskas, and personC. S. Jensen.
Scalable top-k spatio-temporal term querying.
journalICDE (year2014).

[Walther and KaisserWalther and
authorpersonM. Walther and personM.
Kaisser. year2013.
Geo-spatial Event Detection in Twitter Stream.
journalECIR (year2013).

[Wang, Cao, and YuWang et al2020]
authorpersonS. Wang, personJ. Cao, and
personP. Yu. year2020.
Deep learning for spatio-temporal data mining: A
journalTKDE (year2020).

[Yu, Xu, Wang, and NiYu
et al2019]
authorpersonD. Yu, personD. Xu,
personD. Wang, and personZ. Ni.
Hierarchical Topic Modeling of Twitter Data for
Online Analytical Processing.
journalIEEE Access (year2019).

[Zhang and HanZhang and Han2019]
authorpersonC. Zhang and personJ. Han.
Multidimensional Mining of Massive Text Data.
journalDMKD (year2019).

[Zhang, Zhai, Han, Srivastava, and OzaZhang
et al2009]
authorpersonD. Zhang, personC. X. Zhai,
personJ. Han, personA. Srivastava, and
personN. Oza. year2009.
Topic Modeling for OLAP on Multidimensional Text
journalStat. Anal. Data Min.

[Zhao, Chen, and CongZhao
et al2016]
authorpersonK. Zhao, personL. Chen, and
personG. Cong. year2016.
Topic Exploration in Spatio-Temporal Document
journalSIGMOD (year2016).

[group style=group size=5 by 4,horizontal sep=1cm,
ylabel=QRT (ms),
legend pos= north west,
legend columns = -1,
xlabel style=yshift = 3,
ylabel style=yshift = -5,
xtick pos=left,
ytick pos=left,

label style=font=,
legend style=nodes=scale=0.7,

[xlabel style=align=center,xlabel=(a) SR - Keyword Density
coordinates (25,1.5)(50,3.200000047683716)(75,1.600000023841858)(100,1.600000023841858)(125,1.5);
coordinates (25,6.300000190734863)(50,7.699999809265137)(75,6.300000190734863)(100,6.300000190734863)(125,6.5);
coordinates (25,87.5)(50,154.6999969482422)(75,196.8999938964844)(100,254.70001220703125)(125,293.79998779296875);
coordinates (25,3.200000047683716)(50,1.5)(75,3.0999999046325684)(100,1.600000023841858)(125,3.0999999046325684);
coordinates (25,48.5)(50,48.5)(75,50.0)(100,50.0)(125,51.599998474121094);
coordinates (25,39.0)(50,37.5)(75,37.5)(100,40.599998474121094)(125,37.5);
coordinates (25,12.5)(50,15.600000381469727)(75,18.799999237060547)(100,21.899999618530273)(125,25.0);
coordinates (25,81.30000305175781)(50,123.4000015258789)(75,89.0)(100,115.69999694824219)(125,126.5);
coordinates (25,76.5999984741211)(50,104.69999694824219)(75,81.19999694824219)(100,103.0999984741211)(125,96.80000305175781);

[legend to name=QRTTrendLegendApp,xlabel style=align=center,xlabel=(b) SR - Top-k Dense Keywords
within an Area (PEM), yticklabels=, ylabel=]
coordinates (25,3.299999952316284)(50,7.599999904632568)(75,6.400000095367432)(100,6.900000095367432)(125,6.900000095367432);
coordinates (25,9.399999618530273)(50,7.800000190734863)(75,9.300000190734863)(100,9.300000190734863)(125,10.899999618530273);
coordinates (25,49.43999938964844)(50,64.30999755859375)(75,47.35)(100,54.10999755859375)(125,61.10999755859375);
coordinates (25,4.800000190734863)(50,4.699999809265137)(75,4.699999809265137)(100,4.699999809265137)(125,6.199999809265137);
coordinates (25,53.099998474121094)(50,50.0)(75,53.20000076293945)(100,51.5)(125,53.099998474121094);
coordinates (25,40.70000076293945)(50,40.599998474121094)(75,39.099998474121094)(100,40.599998474121094)(125,40.599998474121094);
coordinates (25,18.799999237060547)(50,21.899999618530273)(75,21.899999618530273)(100,28.100000381469727)(125,26.600000381469727);
coordinates (25,61.0)(50,82.80000305175781)(75,59.29999923706055)(100,75.0)(125,76.5);
coordinates (25,133.0)(50,134.3000030517578)(75,106.30000305175781)(100,120.30000305175781)(125,197.3000030517578);

[xlabel style=align=center,xlabel=(c) SR - Top-k Dense Key-
words within an Area (PAM), yticklabels=,  ylabel=]
coordinates (25,3.200000047683716)(50,3.0999999046325684)(75,4.699999809265137)(100,3.0999999046325684)(125,4.699999809265137);
coordinates (25,7.800000190734863)(50,8.0)(75,9.399999618530273)(100,9.399999618530273)(125,9.399999618530273);
coordinates (25,81.19999694824219)(50,101.9000015258789)(75,86.0)(100,79.69999694824219)(125,90.5999984741211);
coordinates (25,3.0)(50,4.699999809265137)(75,3.200000047683716)(100,3.0999999046325684)(125,3.200000047683716);
coordinates (25,46.900001525878906)(50,50.0)(75,50.0)(100,50.0)(125,50.0);
coordinates (25,37.5)(50,39.099998474121094)(75,39.099998474121094)(100,39.099998474121094)(125,40.70000076293945);
coordinates (25,7.800000190734863)(50,6.300000190734863)(75,6.199999809265137)(100,6.300000190734863)(125,6.300000190734863);
coordinates (25,7.800000190734863)(50,7.800000190734863)(75,7.900000095367432)(100,7.800000190734863)(125,7.900000095367432);

[xlabel style=align=center,xlabel=(d) SR - Top-k Volatile Key-
words within an Area (PEM), yticklabels=,  ylabel=]
coordinates (25,6.300000190734863)(50,7.800000190734863)(75,7.800000190734863)(100,7.900000095367432)(125,9.399999618530273);
coordinates (25,14.0)(50,12.5)(75,14.0)(100,14.0)(125,15.300000190734863);
coordinates (25,205.1000061035156)(50,242.6000061035156)(75,251.5)(100,275.0)(125,264.1000061035156);
coordinates (25,7.800000190734863)(50,7.800000190734863)(75,6.199999809265137)(100,9.399999618530273)(125,7.800000190734863);
coordinates (25,98.4000015258789)(50,100.0)(75,98.80000305175781)(100,103.19999694824219)(125,101.5999984741211);
coordinates (25,79.69999694824219)(50,78.0999984741211)(75,76.5999984741211)(100,78.0999984741211)(125,76.5);
coordinates (25,21.899999618530273)(50,23.5)(75,18.700000762939453)(100,21.799999237060547)(125,20.299999237060547);
coordinates (25,40.599998474121094)(50,43.79999923706055)(75,39.099998474121094)(100,45.400001525878906)(125,40.70000076293945);
coordinates (25,121.9000015258789)(50,112.5)(75,107.9000015258789)(100,115.69999694824219)(125,126.5999984741211);

[xlabel style=align=center,xlabel=(e) SR - Top-k Volatile Key-
words within an Area (PAM), yticklabels=,  ylabel=]
coordinates (25,6.199999809265137)(50,6.199999809265137)(75,6.300000190734863)(100,6.199999809265137)(125,6.300000190734863);
coordinates (25,12.5)(50,10.899999618530273)(75,12.5)(100,11.0)(125,11.100000381469727);
coordinates (25,155.0)(50,162.1999969482422)(75,176.60000610351562)(100,162.5)(125,167.1999969482422);
coordinates (25,6.199999809265137)(50,4.699999809265137)(75,4.599999904632568)(100,4.699999809265137)(125,4.699999809265137);
coordinates (25,95.30000305175781)(50,95.30000305175781)(75,95.30000305175781)(100,100.0)(125,93.69999694824219);
coordinates (25,75.0)(50,75.0)(75,73.4000015258789)(100,76.5999984741211)(125,79.69999694824219);
coordinates (25,14.0)(50,15.600000381469727)(75,11.0)(100,14.100000381469727)(125,12.5);
coordinates (25,14.0)(50,14.100000381469727)(75,10.899999618530273)(100,12.399999618530273)(125,12.5);

[xlabel style=align=center,xlabel=(f) SM - Keyword Density
(PEM), ymax=200, ymin=-10]
coordinates (25,4.699999809265137)(50,6.300000190734863)(75,6.199999809265137)(100,6.300000190734863)(125,6.300000190734863);
coordinates (25,25.1999969482422)(50,45.39999389648438)(75,90.6000061035156)(100,150.0)(125,178.1000061035156);
coordinates (25,46.900001525878906)(50,58.0)(75,48.20000076293945)(100,50.0)(125,46.900001525878906);
coordinates (25,37.5)(50,39.099998474121094)(75,37.5)(100,35.900001525878906)(125,39.0);
coordinates (25,79.69999694824219)(50,106.19999694824219)(75,79.69999694824219)(100,95.30000305175781)(125,98.5);

[xlabel style=align=center,xlabel=(g) SM - Top-k Dense Keywords
within an Area (PEM), ylabel=, yticklabels=, ymax=200, ymin=-10]
coordinates (25,6.400000095367432)(50,10.5)(75,10.600000381469727)(100,11.0)(125,10.0);
coordinates (25,25.1999969482422)(50,40.5)(75,110.8999938964844)(100,143.79998779296875)(125,190.6000061035156);
coordinates (25,50.0)(50,54.70000076293945)(75,50.0)(100,51.599998474121094)(125,53.099998474121094);
coordinates (25,37.5)(50,39.20000076293945)(75,39.0)(100,39.099998474121094)(125,37.5);
coordinates (25,89.0999984741211)(50,121.9000015258789)(75,96.9000015258789)(100,111.0)(125,114.0);

[xlabel style=align=center,xlabel=(h) SM - Top-k Dense Key-
words within an Area (PAM),  ylabel=, yticklabels=, ymax=200, ymin=-10]
coordinates (25,6.300000190734863)(50,7.800000190734863)(75,7.900000095367432)(100,7.800000190734863)(125,9.300000190734863);
coordinates (25,84.30000305175781)(50,100.0)(75,79.69999694824219)(100,85.9000015258789)(125,84.4000015258789);
coordinates (25,46.900001525878906)(50,48.400001525878906)(75,50.29999923706055)(100,50.0)(125,50.0);
coordinates (25,39.099998474121094)(50,39.0)(75,39.099998474121094)(100,40.599998474121094)(125,39.099998474121094);

[xlabel style=align=center,xlabel=(i) SM - Top-k Volatile Key-
words within an Area (PEM),  ylabel=, yticklabels=, ymax=200, ymin=-10]
coordinates (25,12.5)(50,10.899999618530273)(75,14.0)(100,14.100000381469727)(125,12.5);
coordinates (25,86.8999938964844)(50,99.6000061035156)(75,151.60000610351562)(100,160.8999938964844)(125,154.6999969482422);
coordinates (25,93.80000305175781)(50,96.69999694824219)(75,98.5)(100,98.9000015258789)(125,98.4000015258789);
coordinates (25,73.4000015258789)(50,75.0)(75,78.0999984741211)(100,76.5999984741211)(125,75.0);
coordinates (25,146.89999389648438)(50,120.30000305175781)(75,131.1999969482422)(100,132.8000030517578)(125,120.30000305175781);

[xlabel style=align=center,xlabel=(j) SM - Top-k Volatile Key-
words within an Area (PAM),  ylabel=, yticklabels=, ymax=200, ymin=-10]
coordinates (25,10.899999618530273)(50,9.5)(75,9.399999618530273)(100,9.300000190734863)(125,9.399999618530273);
coordinates (25,170.0)(50,182.8000030517578)(75,160.89999389648438)(100,156.3000030517578)(125,156.3000030517578);
coordinates (25,93.69999694824219)(50,92.19999694824219)(75,90.5999984741211)(100,92.19999694824219)(125,90.5999984741211);
coordinates (25,75.0)(50,75.0)(75,73.4000015258789)(100,73.4000015258789)(125,75.0999984741211);

[ xlabel style=align=center,xlabel=(a) GR - Keyword Density
(PEM), ymax=400]
coordinates (25,6.199999809265137)(50,6.300000190734863)(75,7.800000190734863)(100,7.0)(125,7.800000190734863);
coordinates (25,4.699999809265137)(50,9.399999618530273)(75,9.600000381469727)(100,9.399999618530273)(125,9.399999618530273);
coordinates (25,144.6999969482422)(50,156.39999389648438)(75,239.1999969482422)(100,220.89999389648438)(125,252.0);
coordinates (25,7.900000095367432)(50,9.399999618530273)(75,12.5)(100,12.5)(125,16.899999618530273);
coordinates (25,76.5)(50,43.79999923706055)(75,46.900001525878906)(100,74.0)(125,64.5);
coordinates (25,54.70000076293945)(50,77.69999694824219)(75,29.700000762939453)(100,32.79999923706055)(125,31.200000762939453);
coordinates (25,16.200000762939453)(50,18.799999237060547)(75,21.200000762939453)(100,20.100000381469727)(125,23.600000381469727);
coordinates (25,78.19999694824219)(50,117.30000305175781)(75,139.1999969482422)(100,160.6999969482422)(125,185.39999389648438);
coordinates (25,102.5999984741211)(50,163.89999389648438)(75,203.1999969482422)(100,217.10000610351562)(125,249.0);

[xlabel style=align=center,xlabel=(b) GR - Top-k Dense Keywords
within an Area (PEM), yticklabels=, ylabel=, ymax=400]
coordinates (25,9.399999618530273)(50,12.5)(75,12.800000190734863)(100,15.600000381469727)(125,15.5);
coordinates (25,3.200000047683716)(50,11.699999809265137)(75,12.300000190734863)(100,14.100000381469727)(125,14.100000381469727);
coordinates (25,180.5)(50,205.89999389648438)(75,297.0)(100,280.29998779296875)(125,284.3999938964844);
coordinates (25,11.0)(50,12.899999618530273)(75,15.600000381469727)(100,17.200000762939453)(125,15.600000381469727);
coordinates (25,79.0)(50,43.70000076293945)(75,60.900001525878906)(100,65.5999984741211)(125,82.0999984741211);
coordinates (25,58.599998474121094)(50,80.19999694824219)(75,38.70000076293945)(100,32.79999923706055)(125,37.29999923706055);
coordinates (25,20.299999237060547)(50,38.70000076293945)(75,23.399999618530273)(100,29.700000762939453)(125,23.399999618530273);
coordinates (25,50.0)(50,83.5)(75,97.80000305175781)(100,102.0999984741211)(125,128.10000610351562);
coordinates (25,118.69999694824219)(50,151.8000030517578)(75,195.10000610351562)(100,205.89999389648438)(125,297.1000061035156);

[xlabel style=align=center,xlabel=(c) GR - Top-k Dense Key-
words within an Area (PAM),  ylabel=, yticklabels=, ymax=400]
coordinates (25,7.900000095367432)(50,7.800000190734863)(75,6.199999809265137)(100,7.800000190734863)(125,6.300000190734863);
coordinates (25,4.599999904632568)(50,10.899999618530273)(75,14.0)(100,14.0)(125,14.0);
coordinates (25,70.30000305175781)(50,39.099998474121094)(75,51.5)(100,50.0)(125,46.79999923706055);
coordinates (25,4.599999904632568)(50,6.199999809265137)(75,6.199999809265137)(100,4.699999809265137)(125,6.300000190734863);
coordinates (25,72.69999694824219)(50,42.20000076293945)(75,47.20000076293945)(100,60.900001525878906)(125,54.70000076293945);
coordinates (25,50.0)(50,87.5)(75,26.600000381469727)(100,27.600000381469727)(125,32.79999923706055);
coordinates (25,7.800000190734863)(50,6.300000190734863)(75,6.400000095367432)(100,8.0)(125,6.199999809265137);
coordinates (25,4.599999904632568)(50,7.800000190734863)(75,6.199999809265137)(100,6.300000190734863)(125,6.199999809265137);

[xlabel style=align=center,xlabel=(d) GR - Top-k Volatile Key-
words within an Area (PEM),  ylabel=, yticklabels=, ymax=400]
coordinates (25,87.5)(50,112.5)(75,107.9000015258789)(100,133.3000030517578)(125,148.5);
coordinates (25,76.5)(50,101.80000305175781)(75,120.30000305175781)(100,120.30000305175781)(125,123.30000305175781);
coordinates (25,250.60000610351562)(50,261.3999938964844)(75,294.20001220703125)(100,359.29998779296875)(125,378.20001220703125);
coordinates (25,12.5)(50,12.5)(75,18.600000381469727)(100,15.399999618530273)(125,12.5);
coordinates (25,130.0)(50,84.4000015258789)(75,87.5)(100,102.0)(125,97.5);
coordinates (25,17.0)(50,16.200000762939453)(75,28.200000762939453)(100,28.100000381469727)(125,31.200000762939453);
coordinates (25,17.200000762939453)(50,20.200000762939453)(75,17.200000762939453)(100,17.200000762939453)(125,17.399999618530273);
coordinates (25,26.5)(50,29.299999237060547)(75,34.0)(100,30.700000762939453)(125,32.29999923706055);
coordinates (25,122.0999984741211)(50,111.5999984741211)(75,98.80000305175781)(100,102.69999694824219)(125,100.4000015258789);

[xlabel style=align=center,xlabel=(e) GR - Top-k Volatile Key-
words within an Area (PAM),  ylabel=, yticklabels=, ymax=400]
coordinates (25,55.900001525878906)(50,54.599998474121094)(75,56.599998474121094)(100,53.599998474121094)(125,58.900001525878906);
coordinates (25,46.599998474121094)(50,63.099998474121094)(75,54.099998474121094)(100,57.099998474121094)(125,57.400001525878906);
coordinates (25,174.5)(50,144.39999389648438)(75,114.4000015258789)(100,126.19999694824219)(125,119.0);
coordinates (25,7.900000095367432)(50,9.399999618530273)(75,7.800000190734863)(100,7.800000190734863)(125,9.399999618530273);
coordinates (25,94.0)(50,62.400001525878906)(75,62.599998474121094)(100,63.400001525878906)(125,67.19999694824219);
coordinates (25,12.5)(50,14.0)(75,23.399999618530273)(100,25.0)(125,21.899999618530273);
coordinates (25,10.899999618530273)(50,10.600000381469727)(75,10.899999618530273)(100,10.899999618530273)(125,10.899999618530273);
coordinates (25,12.800000190734863)(50,10.899999618530273)(75,9.5)(100,10.899999618530273)(125,10.899999618530273);

[xlabel style=align=center,xlabel=Data Size in Millions
(f) GM - Keyword Density
(PEM), ymax=100, ymin=-10]
coordinates (25,3.0999999046325684)(50,9.399999618530273)(75,7.800000190734863)(100,9.300000190734863)(125,9.399999618530273);
coordinates (25,26.5)(50,39.099998474121094)(75,39.099998474121094)(100,39.099998474121094)(125,39.099998474121094);
coordinates (25,36.0)(50,46.599998474121094)(75,45.29999923706055)(100,48.400001525878906)(125,43.70000076293945);
coordinates (25,36.79999923706055)(50,40.79999923706055)(75,40.599998474121094)(100,40.599998474121094)(125,40.0);
coordinates (25,26.600000381469727)(50,24.200000762939453)(75,24.200000762939453)(100,36.29999923706055)(125,42.099998474121094);

[xlabel style=align=center,xlabel=Data Size in Millions
(g) GM - Top-k Dense Key-
words within an Area (PEM),  ylabel=, yticklabels=, ymax=100, ymin=-10]
coordinates (25,3.0999999046325684)(50,15.399999618530273)(75,16.399999618530273)(100,19.700000762939453)(125,16.299999237060547);
coordinates (25,25.0)(50,43.5)(75,42.20000076293945)(100,43.70000076293945)(125,41.900001525878906);
coordinates (25,36.0)(50,45.400001525878906)(75,46.79999923706055)(100,45.29999923706055)(125,46.900001525878906);
coordinates (25,36.0)(50,39.099998474121094)(75,42.20000076293945)(100,42.20000076293945)(125,42.20000076293945);
coordinates (25,26.600000381469727)(50,37.5)(75,48.400001525878906)(100,37.5)(125,39.099998474121094);

[xlabel style=align=center,xlabel=Data Size in Millions
(h) GM - Top-k Dense Key-
words within an Area (PAM),  ylabel=, yticklabels=, ymax=100, ymin=-10]
coordinates (25,4.699999809265137)(50,10.899999618530273)(75,11.0)(100,11.0)(125,9.399999618530273);
coordinates (25,26.600000381469727)(50,40.599998474121094)(75,39.599998474121094)(100,40.79999923706055)(125,39.099998474121094);
coordinates (25,36.099998474121094)(50,48.400001525878906)(75,45.900001525878906)(100,45.5)(125,45.0);
coordinates (25,34.400001525878906)(50,40.599998474121094)(75,41.099998474121094)(100,52.70000076293945)(125,40.599998474121094);

[xlabel style=align=center,xlabel=Data Size in Millions
(i) GM - Top-k Volatile Key-
words within an Area (PEM),  ylabel=, yticklabels=, ymax=100, ymin=-10]
coordinates (25,7.800000190734863)(50,14.100000381469727)(75,15.600000381469727)(100,15.699999809265137)(125,15.699999809265137);
coordinates (25,50.0)(50,76.5)(75,76.5999984741211)(100,75.0)(125,79.69999694824219);
coordinates (25,70.4000015258789)(50,90.5999984741211)(75,93.80000305175781)(100,92.30000305175781)(125,93.69999694824219);
coordinates (25,65.5999984741211)(50,76.5999984741211)(75,81.30000305175781)(100,81.4000015258789)(125,79.69999694824219);
coordinates (25,45.29999923706055)(50,73.4000015258789)(75,75.0)(100,73.5)(125,73.4000015258789);

[xlabel style=align=center,xlabel=Data Size in Millions
(j) GM - Top-k Volatile Key-
words within an Area (PAM), ylabel=, yticklabels=, ymax=100, ymin=-10]
coordinates (25,6.300000190734863)(50,10.899999618530273)(75,9.399999618530273)(100,10.899999618530273)(125,10.899999618530273);
coordinates (25,51.599998474121094)(50,73.5)(75,68.80000305175781)(100,71.9000015258789)(125,73.5);
coordinates (25,67.0999984741211)(50,89.0)(75,89.0999984741211)(100,89.0)(125,90.69999694824219);
coordinates (25,65.5999984741211)(50,76.5999984741211)(75,68.69999694824219)(100,68.5999984741211)(125,73.4000015258789);

font=footnotesize, skip=0pt
QRT Vs Data Size

[group style=group size=4 by 4,horizontal sep=0.2cm,
symbolic x coords=Q1,Q2,Q3,Q4,Q5,Q6,Q7,Q8,Q9,
/pgf/bar width=2pt,
ymode = log,
xtick pos=left,
ytick pos=left,
ylabel=QRT (ms),
ylabel style=yshift = -5,
label style=font=,
tick label style=font=,

legend columns=-1,
legend entries=NC, NM, PEM,PAM, FM,
legend to name=namedApp,
ytick=1,100,10000, 1000000, 100000000,10000000000

[xlabel style=align=center,xlabel=(a) SR - Keyword Density]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,23740685.50) +- (4774.829489,4774.829489)
(Q2,25876672.40) +- (1727.549432,1727.549432)
(Q3,25113094.30) +- (7694.707117,7694.707117)
(Q4,25857860.50) +- (18853.73591,18853.73591)
(Q5,25333594.50) +- (28178.91091,28178.91091)
(Q6,25970812.00) +- (24835.24947,24835.24947)
(Q7,24874984.20) +- (28346.77387,28346.77387)
(Q8,47674031.59) +- (6210.67282,6210.67282)
(Q9,49709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,100520.50) +- (4774.829489,4774.829489)
(Q2,109511.40) +- (1727.549432,1727.549432)
(Q3,142325.30) +- (7694.707117,7694.707117)
(Q4,134468.50) +- (18853.73591,18853.73591)
(Q5,100499.50) +- (28178.91091,28178.91091)
(Q6,117461.00) +- (24835.24947,24835.24947)
(Q7,129966.20) +- (28346.77387,28346.77387)
(Q8,102412.59) +- (6210.67282,6210.67282)
(Q9,156923.00) +- (2770.7346,2770.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,3.70) +- (0.02594067,0.02594067)
(Q2,7.10) +- (0.662705391,0.662705391)
(Q3,196.80) +- (1.84452761,1.84452761)
(Q4,3.60) +- (0.2,0.2)
(Q5,51.10) +- (3.65436347,3.65436347)
(Q6,40.50) +- (0.152235366,0.152235366)
(Q7,12.80) +- (0.724196625,0.724196625)
(Q8,82.50) +- (2.57994887,2.57994887)
(Q9,94.90) +- (0.502352616,0.502352616)
+[pattern=crosshatch dots, error bars/.cd, y dir=both,  y explicit] coordinates
(Q1,7.80) +- (0.53622915,0.53622915)
(Q2,7.20) +- (0.871779789,0.871779789)
(Q3,8.90) +- (0.26728529,0.26728529)
(Q4,6.00) +- (0.483239697,0.483239697)
(Q5,5.90) +- (0.412023651,0.412023651)
(Q6,4.70) +- (0.410394159,0.410394159)
(Q7,4.80) +- (0.095445115,0.095445115)
(Q8,16.60) +- (0.280624847,0.280624847)
(Q9,16.91) +- (0.2661,0.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(b) SR - Keyword Volatility]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,46740685.50) +- (4774.829489,4774.829489)
(Q2,50876672.40) +- (1727.549432,1727.549432)
(Q3,50113094.30) +- (7694.707117,7694.707117)
(Q4,50857860.50) +- (18853.73591,18853.73591)
(Q5,50333594.50) +- (28178.91091,28178.91091)
(Q6,50970812.00) +- (24835.24947,24835.24947)
(Q7,48874984.20) +- (28346.77387,28346.77387)
(Q8,94674031.59) +- (6210.67282,6210.67282)
(Q9,98709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,153834.50) +- (4774.829489,4774.829489)
(Q2,152397.40) +- (1727.549432,1727.549432)
(Q3,190232.30) +- (7694.707117,7694.707117)
(Q4,195695.50) +- (18853.73591,18853.73591)
(Q5,195750.50) +- (28178.91091,28178.91091)
(Q6,100358.00) +- (24835.24947,24835.24947)
(Q7,195314.20) +- (28346.77387,28346.77387)
(Q8,188698.59) +- (6210.67282,6210.67282)
(Q9,191331.00) +- (2770.7346,2770.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,12.30) +- (2.32594067,2.32594067)
(Q2,17.10) +- (2.662705391,2.662705391)
(Q3,294.80) +- (14.84452761,14.84452761)
(Q4,9.60) +- (4.2,4.2)
(Q5,103.10) +- (30.65436347,30.65436347)
(Q6,82.50) +- (6.152235366,6.152235366)
(Q7,21.80) +- (9.724196625,9.724196625)
(Q8,42.50) +- (2.57994887,2.57994887)
(Q9,128.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,7.80) +- (1.53622915,1.53622915)
(Q2,15.20) +- (0.871779789,0.871779789)
(Q3,23.90) +- (5.26728529,5.26728529)
(Q4,7.00) +- (1.483239697,1.483239697)
(Q5,10.90) +- (2.412023651,2.412023651)
(Q6,12.70) +- (2.410394159,2.410394159)
(Q7,15.00) +- (1.095445115,1.095445115)
(Q8,15.60) +- (1.280624847,1.280624847)
(Q9,25.91) +- (2.2661,2.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(c) SR - Top-k Dense Keyowrds,x=0.45cm]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,23740685.50) +- (4774.829489,4774.829489)
(Q2,25876672.40) +- (1727.549432,1727.549432)
(Q3,25113094.30) +- (7694.707117,7694.707117)
(Q4,25857860.50) +- (18853.73591,18853.73591)
(Q5,25333594.50) +- (28178.91091,28178.91091)
(Q6,25970812.00) +- (24835.24947,24835.24947)
(Q7,24874984.20) +- (28346.77387,28346.77387)
(Q8,47674031.59) +- (6210.67282,6210.67282)
(Q9,49709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,152860.50) +- (4774.829489,4774.829489)
(Q2,152870.40) +- (1727.549432,1727.549432)
(Q3,132325.30) +- (7694.707117,7694.707117)
(Q4,128368.50) +- (18853.73591,18853.73591)
(Q5,102740.50) +- (28178.91091,28178.91091)
(Q6,107590.00) +- (24835.24947,24835.24947)
(Q7,139966.20) +- (28346.77387,28346.77387)
(Q8,104915.59) +- (1212.67282,1212.67282)
(Q9,158530.00) +- (1770.7346,1770.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,8.30) +- (0.32594067,0.32594067)
(Q2,12.10) +- (0.662705391,0.662705391)
(Q3,336.80) +- (14.84452761,14.84452761)
(Q4,5.60) +- (0.2,0.2)
(Q5,54.10) +- (3.65436347,3.65436347)
(Q6,42.50) +- (6.152235366,6.152235366)
(Q7,31.80) +- (9.724196625,9.724196625)
(Q8,84.50) +- (12.57994887,12.57994887)
(Q9,161.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,4.80) +- (0.53622915,0.53622915)
(Q2,11.20) +- (0.871779789,0.871779789)
(Q3,90.90) +- (15.26728529,15.26728529)
(Q4,4.00) +- (0.483239697,0.483239697)
(Q5,53.90) +- (5.412023651,5.412023651)
(Q6,41.70) +- (2.410394159,2.410394159)
(Q7,9.00) +- (1.095445115,1.095445115)
(Q8,6.60) +- (1.280624847,1.280624847)
(Q9,158530.91) +- (27456.2661,27456.2661)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,18.80) +- (1.53622915,1.53622915)
(Q2,4.20) +- (0.871779789,0.871779789)
(Q3,8.90) +- (1.26728529,1.26728529)
(Q4,4.00) +- (0.483239697,0.483239697)
(Q5,14.90) +- (0.412023651,0.412023651)
(Q6,16.70) +- (2.410394159,2.410394159)
(Q7,9.00) +- (1.095445115,1.095445115)
(Q8,35.60) +- (1.280624847,1.280624847)
(Q9,37.91) +- (12.2661,12.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(d) SR - Top-k Volatile Keyowrds,x=0.45cm]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,46740685.50) +- (4774.829489,4774.829489)
(Q2,50876672.40) +- (1727.549432,1727.549432)
(Q3,50113094.30) +- (7694.707117,7694.707117)
(Q4,50857860.50) +- (18853.73591,18853.73591)
(Q5,50333594.50) +- (28178.91091,28178.91091)
(Q6,50970812.00) +- (24835.24947,24835.24947)
(Q7,48874984.20) +- (28346.77387,28346.77387)
(Q8,94674031.59) +- (6210.67282,6210.67282)
(Q9,98709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,128360.50) +- (4774.829489,4774.829489)
(Q2,153970.40) +- (1727.549432,1727.549432)
(Q3,190232.30) +- (7694.707117,7694.707117)
(Q4,195695.50) +- (1883.73591,1883.73591)
(Q5,195750.50) +- (2818.91091,2818.91091)
(Q6,100358.00) +- (2483.24947,2483.24947)
(Q7,195314.20) +- (2834.77387,2834.77387)
(Q8,188698.59) +- (6212.67282,6212.67282)
(Q9,191331.00) +- (2770.7346,2770.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,9.30) +- (2.32594067,2.32594067)
(Q2,15.10) +- (2.662705391,2.662705391)
(Q3,284.80) +- (14.84452761,14.84452761)
(Q4,7.60) +- (4.2,4.2)
(Q5,106.10) +- (30.65436347,30.65436347)
(Q6,79.50) +- (6.152235366,6.152235366)
(Q7,21.80) +- (9.724196625,9.724196625)
(Q8,41.50) +- (62.57994887,62.57994887)
(Q9,121.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,7.80) +- (1.53622915,1.53622915)
(Q2,10.20) +- (0.871779789,0.871779789)
(Q3,173.90) +- (15.26728529,15.26728529)
(Q4,6.00) +- (1.483239697,1.483239697)
(Q5,96.90) +- (5.412023651,5.412023651)
(Q6,82.70) +- (2.410394159,2.410394159)
(Q7,12.00) +- (1.095445115,1.095445115)
(Q8,14.60) +- (1.280624847,1.280624847)
(Q9,191331.91) +- (2770.2661,2770.2661)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,5.80) +- (1.53622915,1.53622915)
(Q2,4.20) +- (0.871779789,0.871779789)
(Q3,8.90) +- (1.26728529,1.26728529)
(Q4,5.00) +- (1.483239697,1.483239697)
(Q5,14.90) +- (5.412023651,5.412023651)
(Q6,16.70) +- (2.410394159,2.410394159)
(Q7,9.00) +- (1.095445115,1.095445115)
(Q8,35.60) +- (1.280624847,1.280624847)
(Q9,37.91) +- (2.2661,2.2661)

[xlabel style=align=center,xlabel=(a) GR - Keyword Density]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,23740685.50) +- (4774.829489,4774.829489)
(Q2,25876672.40) +- (1727.549432,1727.549432)
(Q3,25113094.30) +- (7694.707117,7694.707117)
(Q4,25857860.50) +- (18853.73591,18853.73591)
(Q5,25333594.50) +- (28178.91091,28178.91091)
(Q6,25970812.00) +- (24835.24947,24835.24947)
(Q7,24874984.20) +- (28346.77387,28346.77387)
(Q8,47674031.59) +- (6210.67282,6210.67282)
(Q9,49709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,521634.50) +- (4774.829489,4774.829489)
(Q2,540838.40) +- (1727.549432,1727.549432)
(Q3,527922.30) +- (7694.707117,7694.707117)
(Q4,534950.50) +- (18853.73591,18853.73591)
(Q5,524286.50) +- (28178.91091,28178.91091)
(Q6,550146.00) +- (24835.24947,24835.24947)
(Q7,530517.20) +- (28346.77387,28346.77387)
(Q8,533639.59) +- (6210.67282,6210.67282)
(Q9,545861.00) +- (2770.7346,2770.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,7.70) +- (0.02594067,0.02594067)
(Q2,9.50) +- (0.662705391,0.662705391)
(Q3,245.80) +- (1.84452761,1.84452761)
(Q4,12.60) +- (0.2,0.2)
(Q5,57.10) +- (3.65436347,3.65436347)
(Q6,39.50) +- (0.152235366,0.152235366)
(Q7,23.80) +- (0.724196625,0.724196625)
(Q8,176.50) +- (2.57994887,2.57994887)
(Q9,235.90) +- (0.502352616,0.502352616)
+[pattern=crosshatch dots, error bars/.cd, y dir=both,  y explicit] coordinates
(Q1,7.80) +- (0.53622915,0.53622915)
(Q2,7.20) +- (0.871779789,0.871779789)
(Q3,8.90) +- (0.26728529,0.26728529)
(Q4,6.00) +- (0.483239697,0.483239697)
(Q5,5.90) +- (0.412023651,0.412023651)
(Q6,4.70) +- (0.410394159,0.410394159)
(Q7,4.80) +- (0.095445115,0.095445115)
(Q8,16.60) +- (0.280624847,0.280624847)
(Q9,16.91) +- (0.2661,0.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(b) GR - Keyword Volatility]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,46740685.50) +- (4774.829489,4774.829489)
(Q2,50876672.40) +- (1727.549432,1727.549432)
(Q3,50113094.30) +- (7694.707117,7694.707117)
(Q4,50857860.50) +- (18853.73591,18853.73591)
(Q5,50333594.50) +- (28178.91091,28178.91091)
(Q6,50970812.00) +- (24835.24947,24835.24947)
(Q7,48874984.20) +- (28346.77387,28346.77387)
(Q8,94674031.59) +- (6210.67282,6210.67282)
(Q9,98709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,936666.50) +- (4774.829489,4774.829489)
(Q2,936600.40) +- (1727.549432,1727.549432)
(Q3,967678.30) +- (7694.707117,7694.707117)
(Q4,985563.50) +- (18853.73591,18853.73591)
(Q5,934827.50) +- (28178.91091,28178.91091)
(Q6,528468.00) +- (24835.24947,24835.24947)
(Q7,962511.20) +- (28346.77387,28346.77387)
(Q8,962994.59) +- (6210.67282,6210.67282)
(Q9,971624.00) +- (2770.7346,2770.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,148.30) +- (2.32594067,2.32594067)
(Q2,123.10) +- (2.662705391,2.662705391)
(Q3,378.80) +- (14.84452761,14.84452761)
(Q4,12.60) +- (4.2,4.2)
(Q5,97.10) +- (30.65436347,30.65436347)
(Q6,31.50) +- (6.152235366,6.152235366)
(Q7,17.80) +- (9.724196625,9.724196625)
(Q8,32.50) +- (2.57994887,2.57994887)
(Q9,100.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,7.80) +- (1.53622915,1.53622915)
(Q2,15.20) +- (0.871779789,0.871779789)
(Q3,23.90) +- (5.26728529,5.26728529)
(Q4,7.00) +- (1.483239697,1.483239697)
(Q5,10.90) +- (2.412023651,2.412023651)
(Q6,12.70) +- (2.410394159,2.410394159)
(Q7,15.00) +- (1.095445115,1.095445115)
(Q8,15.60) +- (1.280624847,1.280624847)
(Q9,25.91) +- (2.2661,2.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(c) GR - Top-k Dense Keyowrds,x=0.45cm]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,23740685.50) +- (4774.829489,4774.829489)
(Q2,25876672.40) +- (1727.549432,1727.549432)
(Q3,25113094.30) +- (7694.707117,7694.707117)
(Q4,25857860.50) +- (18853.73591,18853.73591)
(Q5,25333594.50) +- (28178.91091,28178.91091)
(Q6,25970812.00) +- (24835.24947,24835.24947)
(Q7,24874984.20) +- (28346.77387,28346.77387)
(Q8,47674031.59) +- (6210.67282,6210.67282)
(Q9,49709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,533300.50) +- (4774.829489,4774.829489)
(Q2,511283.40) +- (1727.549432,1727.549432)
(Q3,540069.30) +- (7694.707117,7694.707117)
(Q4,532869.50) +- (18853.73591,18853.73591)
(Q5,523274.50) +- (28178.91091,28178.91091)
(Q6,530968.00) +- (24835.24947,24835.24947)
(Q7,531803.20) +- (28346.77387,28346.77387)
(Q8,535825.59) +- (6210.67282,6210.67282)
(Q9,549068.00) +- (2770.7346,2770.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,13.30) +- (0.32594067,0.32594067)
(Q2,14.10) +- (0.662705391,0.662705391)
(Q3,303.80) +- (14.84452761,14.84452761)
(Q4,15.60) +- (0.2,0.2)
(Q5,59.10) +- (3.65436347,3.65436347)
(Q6,40.50) +- (6.152235366,6.152235366)
(Q7,35.80) +- (9.724196625,9.724196625)
(Q8,117.50) +- (12.57994887,12.57994887)
(Q9,250.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,6.80) +- (0.53622915,0.53622915)
(Q2,10.20) +- (0.871779789,0.871779789)
(Q3,50.90) +- (15.26728529,15.26728529)
(Q4,6.00) +- (0.483239697,0.483239697)
(Q5,53.90) +- (5.412023651,5.412023651)
(Q6,29.70) +- (2.410394159,2.410394159)
(Q7,7.00) +- (1.095445115,1.095445115)
(Q8,5.60) +- (1.280624847,1.280624847)
(Q9,549068.00) +- (2770.7346,2770.7346)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,7.80) +- (0.53622915,0.53622915)
(Q2,7.20) +- (0.871779789,0.871779789)
(Q3,8.90) +- (0.26728529,0.26728529)
(Q4,6.00) +- (0.483239697,0.483239697)
(Q5,5.90) +- (0.412023651,0.412023651)
(Q6,4.70) +- (0.410394159,0.410394159)
(Q7,4.80) +- (0.095445115,0.095445115)
(Q8,16.60) +- (0.280624847,0.280624847)
(Q9,16.91) +- (0.2661,0.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(d) GR - Top-k Volatile Keyowrds,x=0.45cm]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,46740685.50) +- (4774.829489,4774.829489)
(Q2,50876672.40) +- (1727.549432,1727.549432)
(Q3,50113094.30) +- (7694.707117,7694.707117)
(Q4,50857860.50) +- (18853.73591,18853.73591)
(Q5,50333594.50) +- (28178.91091,28178.91091)
(Q6,50970812.00) +- (24835.24947,24835.24947)
(Q7,48874984.20) +- (28346.77387,28346.77387)
(Q8,94674031.59) +- (6210.67282,6210.67282)
(Q9,98709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,936666.50) +- (4774.829489,4774.829489)
(Q2,936600.40) +- (1727.549432,1727.549432)
(Q3,967678.30) +- (7694.707117,7694.707117)
(Q4,985563.50) +- (18853.73591,18853.73591)
(Q5,934827.50) +- (28178.91091,28178.91091)
(Q6,528468.00) +- (24835.24947,24835.24947)
(Q7,962511.20) +- (28346.77387,28346.77387)
(Q8,962994.59) +- (6210.67282,6210.67282)
(Q9,971624.00) +- (2770.7346,2770.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,148.30) +- (2.32594067,2.32594067)
(Q2,123.10) +- (2.662705391,2.662705391)
(Q3,378.80) +- (14.84452761,14.84452761)
(Q4,12.60) +- (4.2,4.2)
(Q5,97.10) +- (30.65436347,30.65436347)
(Q6,31.50) +- (6.152235366,6.152235366)
(Q7,17.80) +- (9.724196625,9.724196625)
(Q8,32.50) +- (62.57994887,62.57994887)
(Q9,100.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,58.80) +- (1.53622915,1.53622915)
(Q2,57.20) +- (0.871779789,0.871779789)
(Q3,119.90) +- (15.26728529,15.26728529)
(Q4,9.00) +- (1.483239697,1.483239697)
(Q5,67.90) +- (5.412023651,5.412023651)
(Q6,21.70) +- (2.410394159,2.410394159)
(Q7,10.00) +- (1.095445115,1.095445115)
(Q8,10.60) +- (1.280624847,1.280624847)
(Q9,971624.00) +- (2770.7346,2770.7346)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q1,7.80) +- (1.53622915,1.53622915)
(Q2,15.20) +- (0.871779789,0.871779789)
(Q3,23.90) +- (5.26728529,5.26728529)
(Q4,7.00) +- (1.483239697,1.483239697)
(Q5,10.90) +- (2.412023651,2.412023651)
(Q6,12.70) +- (2.410394159,2.410394159)
(Q7,15.00) +- (1.095445115,1.095445115)
(Q8,15.60) +- (1.280624847,1.280624847)
(Q9,25.91) +- (2.2661,2.2661)

[xlabel style=align=center,xlabel=(i) SM - Keyword Density, symbolic x coords=Q2,Q23,Q3,Q35,Q5,Q56,Q6,Q69,Q9, /pgf/bar width=3pt]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,25876672.40) +- (1727.549432,1727.549432)
(Q3,25113094.30) +- (7694.707117,7694.707117)
(Q5,25333594.50) +- (28178.91091,28178.91091)
(Q6,25970812.00) +- (24835.24947,24835.24947)
(Q9,49709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,2490.40) +- (7.549432,7.549432)
(Q3,1490.30) +- (4.707117,4.707117)
(Q5,1540.50) +- (8.91091,8.91091)
(Q6,2627.00) +- (5.24947,5.24947)
(Q9,2327.00) +- (7.7346,7.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,7.90) +- (0.662705391,0.662705391)
(Q3,188.80) +- (1.84452761,1.84452761)
(Q5,50.10) +- (3.65436347,3.65436347)
(Q6,40.50) +- (0.152235366,0.152235366)
(Q9,117.90) +- (0.502352616,0.502352616)
+[pattern=crosshatch dots, error bars/.cd, y dir=both,  y explicit] coordinates
(Q2,7.20) +- (0.871779789,0.871779789)
(Q3,8.90) +- (0.26728529,0.26728529)
(Q5,5.90) +- (0.412023651,0.412023651)
(Q6,4.70) +- (0.410394159,0.410394159)
(Q9,16.91) +- (0.2661,0.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(j) SM - Keyword Volatility, symbolic x coords=Q2,Q23,Q3,Q35,Q5,Q56,Q6,Q69,Q9, /pgf/bar width=3pt]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,50876672.40) +- (1727.549432,1727.549432)
(Q3,50113094.30) +- (7694.707117,7694.707117)
(Q5,50333594.50) +- (28178.91091,28178.91091)
(Q6,50970812.00) +- (24835.24947,24835.24947)
(Q9,98709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,4613.40) +- (7.549432,7.549432)
(Q3,3683.30) +- (4.707117,4.707117)
(Q5,3688.50) +- (8.91091,8.91091)
(Q6,4773.00) +- (5.24947,5.24947)
(Q9,4726.00) +- (7.7346,7.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,15.10) +- (2.662705391,2.662705391)
(Q3,154.80) +- (14.84452761,14.84452761)
(Q5,104.10) +- (30.65436347,30.65436347)
(Q6,76.50) +- (6.152235366,6.152235366)
(Q9,142.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,15.20) +- (0.871779789,0.871779789)
(Q3,23.90) +- (5.26728529,5.26728529)
(Q5,10.90) +- (2.412023651,2.412023651)
(Q6,12.70) +- (2.410394159,2.410394159)
(Q9,25.91) +- (2.2661,2.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(k) SM - Top-k Dense Keyowrds, symbolic x coords=Q2,Q23,Q3,Q35,Q5,Q56,Q6,Q69,Q9, /pgf/bar width=3pt,x=0.45cm]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,25876672.40) +- (1727.549432,1727.549432)
(Q3,25113094.30) +- (7694.707117,7694.707117)
(Q5,25333594.50) +- (28178.91091,28178.91091)
(Q6,25970812.00) +- (24835.24947,24835.24947)
(Q9,49709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,2500.40) +- (7.549432,7.549432)
(Q3,2389.30) +- (4.707117,4.707117)
(Q5,2411.50) +- (8.91091,8.91091)
(Q6,2637.00) +- (5.24947,5.24947)
(Q9,2211.00) +- (7.7346,7.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,11.10) +- (0.662705391,0.662705391)
(Q3,228.80) +- (14.84452761,14.84452761)
(Q5,50.10) +- (3.65436347,3.65436347)
(Q6,39.50) +- (6.152235366,6.152235366)
(Q9,136.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,7.20) +- (0.871779789,0.871779789)
(Q3,84.90) +- (15.26728529,15.26728529)
(Q5,48.90) +- (5.412023651,5.412023651)
(Q6,37.70) +- (2.410394159,2.410394159)
(Q9,2211.00) +- (7.7346,7.7346)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,7.20) +- (0.871779789,0.871779789)
(Q3,8.90) +- (0.26728529,0.26728529)
(Q5,5.90) +- (0.412023651,0.412023651)
(Q6,4.70) +- (0.410394159,0.410394159)
(Q9,16.91) +- (0.2661,0.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(l) SM - Top-k Volatile Keyowrds, symbolic x coords=Q2,Q23,Q3,Q35,Q5,Q56,Q6,Q69,Q9, /pgf/bar width=3pt,x=0.45cm]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,50876672.40) +- (1727.549432,1727.549432)
(Q3,50113094.30) +- (7694.707117,7694.707117)
(Q5,50333594.50) +- (28178.91091,28178.91091)
(Q6,50970812.00) +- (24835.24947,24835.24947)
(Q9,98709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,4613.40) +- (7.549432,7.549432)
(Q3,3683.30) +- (4.707117,4.707117)
(Q5,3688.50) +- (8.91091,8.91091)
(Q6,4773.00) +- (5.24947,5.24947)
(Q9,4726.00) +- (7.7346,7.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,15.10) +- (2.662705391,2.662705391)
(Q3,154.80) +- (14.84452761,14.84452761)
(Q5,104.10) +- (30.65436347,30.65436347)
(Q6,76.50) +- (6.152235366,6.152235366)
(Q9,142.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,9.20) +- (0.871779789,0.871779789)
(Q3,162.90) +- (15.26728529,15.26728529)
(Q5,93.90) +- (5.412023651,5.412023651)
(Q6,76.70) +- (2.410394159,2.410394159)
(Q9,4726.00) +- (7.7346,7.7346)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,15.20) +- (0.871779789,0.871779789)
(Q3,23.90) +- (5.26728529,5.26728529)
(Q5,10.90) +- (2.412023651,2.412023651)
(Q6,12.70) +- (2.410394159,2.410394159)
(Q9,25.91) +- (2.2661,2.2661)

[xlabel style=align=center,xlabel=(e) GM - Keyword Density, symbolic x coords=Q2,Q23,Q3,Q35,Q5,Q56,Q6,Q69,Q9, /pgf/bar width=3pt]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,25876672.40) +- (1727.549432,1727.549432)
(Q3,25113094.30) +- (7694.707117,7694.707117)
(Q5,25333594.50) +- (28178.91091,28178.91091)
(Q6,25970812.00) +- (24835.24947,24835.24947)
(Q9,49709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,18794.40) +- (7.549432,7.549432)
(Q3,16903.30) +- (4.707117,4.707117)
(Q5,17903.50) +- (8.91091,8.91091)
(Q6,19761.00) +- (5.24947,5.24947)
(Q9,19214.00) +- (7.7346,7.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,4.90) +- (0.662705391,0.662705391)
(Q3,37.80) +- (1.84452761,1.84452761)
(Q5,48.10) +- (3.65436347,3.65436347)
(Q6,40.50) +- (0.152235366,0.152235366)
(Q9,23.90) +- (0.502352616,0.502352616)
+[pattern=crosshatch dots, error bars/.cd, y dir=both,  y explicit] coordinates
(Q2,7.20) +- (0.871779789,0.871779789)
(Q3,8.90) +- (0.26728529,0.26728529)
(Q5,5.90) +- (0.412023651,0.412023651)
(Q6,4.70) +- (0.410394159,0.410394159)
(Q9,16.91) +- (0.2661,0.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(f) GM - Keyword Volatility, symbolic x coords=Q2,Q23,Q3,Q35,Q5,Q56,Q6,Q69,Q9, /pgf/bar width=3pt]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,50876672.40) +- (1727.549432,1727.549432)
(Q3,50113094.30) +- (7694.707117,7694.707117)
(Q5,50333594.50) +- (28178.91091,28178.91091)
(Q6,50970812.00) +- (24835.24947,24835.24947)
(Q9,98709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,21269.40) +- (7.549432,7.549432)
(Q3,19903.30) +- (4.707117,4.707117)
(Q5,18903.50) +- (8.91091,8.91091)
(Q6,20081.00) +- (5.24947,5.24947)
(Q9,21001.00) +- (7.7346,7.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,15.10) +- (2.662705391,2.662705391)
(Q3,79.80) +- (14.84452761,14.84452761)
(Q5,93.10) +- (30.65436347,30.65436347)
(Q6,79.50) +- (6.152235366,6.152235366)
(Q9,73.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,15.20) +- (0.871779789,0.871779789)
(Q3,23.90) +- (5.26728529,5.26728529)
(Q5,10.90) +- (2.412023651,2.412023651)
(Q6,12.70) +- (2.410394159,2.410394159)
(Q9,25.91) +- (2.2661,2.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(g) GM - Top-k Dense Keyowrds, symbolic x coords=Q2,Q23,Q3,Q35,Q5,Q56,Q6,Q69,Q9, /pgf/bar width=3pt,x=0.45cm]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,25876672.40) +- (1727.549432,1727.549432)
(Q3,25113094.30) +- (7694.707117,7694.707117)
(Q5,25333594.50) +- (28178.91091,28178.91091)
(Q6,25970812.00) +- (24835.24947,24835.24947)
(Q9,49709469.00) +- (2770.7346,2770.7346)
(Q9,19078.00) +- (7.7346,7.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,18794.40) +- (7.549432,7.549432)
(Q3,17794.30) +- (4.707117,4.707117)
(Q5,16794.50) +- (8.91091,8.91091)
(Q6,19778.00) +- (5.24947,5.24947)
(Q9,19078.00) +- (7.7346,7.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,6.10) +- (0.662705391,0.662705391)
(Q3,40.80) +- (14.84452761,14.84452761)
(Q5,45.10) +- (3.65436347,3.65436347)
(Q6,39.50) +- (6.152235366,6.152235366)
(Q9,37.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,4.20) +- (0.871779789,0.871779789)
(Q3,37.90) +- (15.26728529,15.26728529)
(Q5,46.90) +- (5.412023651,5.412023651)
(Q6,40.70) +- (2.410394159,2.410394159)
(Q9,19078.00) +- (7.7346,7.7346)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,7.20) +- (0.871779789,0.871779789)
(Q3,8.90) +- (0.26728529,0.26728529)
(Q5,5.90) +- (0.412023651,0.412023651)
(Q6,4.70) +- (0.410394159,0.410394159)
(Q9,16.91) +- (0.2661,0.2661)

[ylabel=, yticklabels=, xlabel style=align=center,xlabel=(h) SM - Top-k Volatile Keyowrds, symbolic x coords=Q2,Q23,Q3,Q35,Q5,Q56,Q6,Q69,Q9, /pgf/bar width=3pt,x=0.45cm]
+[pattern=horizontal lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,50876672.40) +- (1727.549432,1727.549432)
(Q3,50113094.30) +- (7694.707117,7694.707117)
(Q5,50333594.50) +- (28178.91091,28178.91091)
(Q6,50970812.00) +- (24835.24947,24835.24947)
(Q9,98709469.00) +- (2770.7346,2770.7346)
+[pattern=north east lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,21269.40) +- (7.549432,7.549432)
(Q3,19903.30) +- (4.707117,4.707117)
(Q5,18903.50) +- (8.91091,8.91091)
(Q6,20081.00) +- (5.24947,5.24947)
(Q9,21001.00) +- (7.7346,7.7346)
+[pattern=north west lines, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,15.10) +- (2.662705391,2.662705391)
(Q3,79.80) +- (14.84452761,14.84452761)
(Q5,93.10) +- (30.65436347,30.65436347)
(Q6,79.50) +- (6.152235366,6.152235366)
(Q9,73.90) +- (8.502352616,8.502352616)
+[pattern=crosshatch, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,10.20) +- (0.871779789,0.871779789)
(Q3,73.90) +- (15.26728529,15.26728529)
(Q5,90.90) +- (5.412023651,5.412023651)
(Q6,73.70) +- (2.410394159,2.410394159)
(Q9,21001.00) +- (7.7346,7.7346)
+[pattern=crosshatch dots, error bars/.cd, y dir=both, y explicit] coordinates
(Q2,15.20) +- (0.871779789,0.871779789)
(Q3,23.90) +- (5.26728529,5.26728529)
(Q5,10.90) +- (2.412023651,2.412023651)
(Q6,12.70) +- (2.410394159,2.410394159)
(Q9,25.91) +- (2.2661,2.2661)

font=footnotesize, skip=0pt
QRTs for spatio-textual-temporal measures for different combinations of hierarchy schemes over 125 Million of Data

§ LATTICE EXAMPLE

Consider a simple lattice of cuboid for a cube with 3 dimensions (Figure <ref>), each with a single 2-level hierarchy, namely with base levels Location (L) with $14$M rows for the spatial dimension,  Term (T) with $2$M rows for the textual dimension, and Date (D) with $37$ rows for the temporal dimension, each of which can be then rolled up to the all level ($\star$) with only one row.
Each node in the lattice is associated with two values, first, the number of rows in the cuboid, and second a flag (T/F) to mark if the current cuboid is materialized.
At the top of the lattice, we have the base cuboid (which is always materialized) with Date, Location, and Term (DLT) containing in this example all rows ($100$M).
If we Roll-Up the spatial dimension from Location to All we obtain a new cuboid (DT) with $4$M rows.
The cuboid DLT is referred to as the ancestor of the cuboid DT.
If the cube is partially materialized, i.e., not all cuboids are materialized, and the cuboid DT is materialized, then to obtain the Fact Count for every Date and Term, the cuboid DT with $4$M rows would contain the answer already pre-computed without the need to compute such an answer from the base cube DLT with $100$M rows.
Moreover, when the cuboid T is not materialized, we can still compute the Fact Count for every Term from the cuboid DT by accessing only 4M values instead of the $100$M in DLT.

§ COST MODEL

The core of the proposed partial materialization approach depends on the trade-off between the storage cost of materializing any particular cuboid and the actual benefit that the materialization of the cuboid provides.
To evaluate this benefit, we have to estimate the (run time) cost of a query.
To devise a cost model for this estimation, we performed a micro-benchmark which confirmed that the running time is directly proportional to the data size (the number of rows). Hence we can use the following linear cost model for benefit calculation
we selected a set of representative queries (Q1—Q9, details in Table <ref>) for the aforementioned spatio-textual-temporal measures and measured the runtime of these queries on increasing data sizes.
The micro-benchmark (Figure <ref>) confirmed that the running time is directly proportional to the data size (the number of rows), i.e., it confirms that we can use the Linear Cost Model <cit.> and the associated benefit calculation.
Then, to model the dependency relationships among all the possible cuboids we use the lattice framework <cit.> (Figure <ref>).
Hence, to compute the benefit of materializing a particular cuboid $c$, we need to compare the cost of answering queries at all levels of granularity (i.e., for the current cuboid $c$ and all its descendants in the lattice) with the current set of materialized cuboids against the cost when $c$ is also materialized.

$$\textit{Benefit}(c) = \sum_{c' \in \textit{descendants}(c) \cup \{c\}} \textit{cost}(c')-\textit{size}(c)$$

For instance, assume the lattice in Figure <ref> and that only the base cuboid (DLT) with $100$M rows is materialized.
If we consider DT with $4$M rows, we have that, if materialized, queries against the cuboids D, T, $\star$, and DT itself can be answered through it (with a cost of $4$M), while without materializing DT, we will need to compute the answer against DLT (with a cost of $100$M).
Hence, materializing DT will achieve a benefit of $(100 - 4) * 4 = 384$M.
Whereas, materializing LT with $96$M rows does not achieve a significant benefit ($(100 - 96) * 4 = 16$M).