QB4MobOLAP: A Vocabulary Extension for Mobility OLAP on the Semantic Web

: The accessibility of devices that track the positions of moving objects has attracted many researchers in Mobility Online Analytical Processing (Mobility OLAP). Mobility OLAP makes use of trajectory data warehousing techniques, which typically include a path of moving objects at a partic-ular point in time. The Semantic Web (SW) users have published a large number of moving object datasets that include spatial and non-spatial data. These data are available as open data and require advanced analysis to aid in decision making. However, current SW technologies support advanced analysis only for multidimensional data warehouses and Online Analytical Processing (OLAP) over static spatial and non-spatial SW data. The existing technology does not support the modeling of moving object facts, the creation of basic mobility analytical queries, or the deﬁnition of funda-mental operators and functions for moving object types. This article introduces the QB4MobOLAP vocabulary, which enables the analysis of mobility data stored in RDF cubes. This article deﬁnes Mobility OLAP operators and SPARQL user-deﬁned functions. As a result, QB4MobOLAP vocabulary and the Mobility OLAP operators are evaluated by applying them to a practical use case of transportation analysis involving 8826 triples consisting of approximately 7000 fact triples. Each triple contains nearly 1000 temporal data points (equivalent to 7 million records in conventional databases). The execution of six pertinent spatiotemporal analytics query samples results in a practical, simple model with expressive performance for the enabling of executive decisions on transportation analysis. MOs data with more dynamic characteristics. In this study, we enhanced the QB4SOLAP capability to support mobility analysis for MOs data.


Introduction
In this Web 2.0 era, the Semantic Web (SW) plays a significant role in data publishing with an open and interoperable nature. The SW is an extension of the World Wide Web created by the World Wide Web Consortium (W3C) to make Internet data machine-readable, and is also referred to as the Web of Data.
[1]. The SW increased its position with the advanced features of complex queries such as interactive analytical queries [2]. The data availability also increased even for complex data types such as spatial data or temporal data. The representation of geospatial and temporal data on the SW is common and growing significantly [3].
Moving objects (MOs) are objects that change their locations continuously over time. The data produced by MOs have grown significantly with the availability of devices that track the position of moving objects, for example, by using smartphones and GPS [4]. MO data have triggered an interest in mobility data analysis or Mobility Online Analytical Processing (Mobility OLAP), which has been grown steadily year after year. Mobility OLAP has attracted many researchers to create mobility patterns. Mobility OLAP could be implemented, for example, in transportation, tourism, weather forecasting, and network sensor analysis [5].
This research constructs the representation of Mobility DW using the new vocabulary of QB4MobOLAP that allows the concept of Mobility DW to be defined over RDF data. Hence, the Mobility DW could be created and published on the SW. The study also defines the mobility analytics operators so that mobility analytics could be queried using SPARQL. This paper introduces three contributions. First, QB4MobOLAP, a new vocabulary to represent Mobility DW on the SW. QB4MobOLAP extends the most recent OLAP vocabulary version with mobility concepts, including mobility facts and measures. The trajectory, level, dimensions, hierarchy, and mobility aggregation functions are also defined. Second, it introduces an extension of SPARQL query for analytical Mobility OLAP operators and functions. Third, this paper also explains the validation of the vocabulary model, operators, functions, and algorithm for the extension of SPARQL by implementing them in a practical use case.
The remainder of the paper is structured as follows: Section 2 describes related works, Section 3 consists of the material and methods involved, and Section 4 includes the results and discussion, while Section 5 concludes the paper and describes the challenges related to future work.

Business Intelligence on Semantic Web
Business Intelligence (BI) is a platform that may be used to integrate, transform, and present analysis data as a means of decision-making support. BI employs proven technologies to obtain information and knowledge that is relevant to the business. These technologies are Extract Transform Loading (ETL), Data Warehouse (DW), Multidimensional Data (MD), and Online Analytical Processing (OLAP) [11].
Simultaneously, as a concept of sharing data on the Web, SW has attracted many scientists for more than a decade. SW has a great vision of representing data on the web in a computer-readable way and adding semantic annotation. Information on the Web could be effectively enriched, retrieved, and processed by machines or humans. SW technologies open a new integration data model, including transparency data and semantically linked data, using description logic for inference tasks [2]. The directions of BI and SW research have converged and are mutually beneficial. Combining these two technologies makes BI have more exploratory semantic sources available for interactive analytics queries.
The usage of BI technology over the SW begun with external source access to support BI's decision making. These data varied from structured, semi-structured, and unstructured data formats. New terms arose, such as BI 2.0 or On-Demand BI [13], Fusion Cube [14], and Self-Service BI. [15]. BI proposed sophisticated tools to analyze vast amounts of data with outstanding performance. In contrast, the SW-linked data offered an exploratory opportunity for valuable information from big data across the internet and could be used to enrich business analytics with inferencing capability [14,[16][17][18][19][20]. OLAP development using SW is categorized into three types of approaches. The first approach is an integrationbased approach that focuses on data source integration; the second is an analysis-based approach that focuses on analytical processing. The third is a combination of these two approaches [9].
An integration-based approach focuses on extracting, transforming, and loading (ETL) from RDF data sources to DW. Many researchers proposed the use of this approach in their studies. Romero et al. defined a multidimensional concept of DW warehouses originating from single domain ontology representing multiple heterogeneous data sources from many business domains [21]. Niinimaki et al. developed a technique to practice ontology and the mapping of files that connect the data sources from external sources to the ontology. Then, the ETL process was performed according to the ontology and mapping files. OLAP ontology defines measures and dimensions using the Ontology Web Language (OWL) and Resource Description Framework (RDF) [22]. Likewise, Nebot  Semantic DW (SDW). This approach stores the SDW as web resources, domain ontologies, and semantic annotations using XML [23].
Additionally, Jiang et al. proposed a method to handle data heterogeneity to build DW with the integration process's domain ontology, and medical domain ontology played an important role [24]. Likewise, Bergamaschi et al. developed an ETL tool that could support semantic mappings from the data source with inter-attribute definitions to support the DW schema's extraction and transformation process. The tool was implemented to develop DW in the food and beverage logistics area, resulting in an effective method [25].
An analysis-based approach directly focuses on analytical processes for SW/RDF data, without using the ETL process. In this approach, multidimensional data requires vocabulary to model RDF data cubes, dimensions, and measures. The de facto standard of vocabulary for the RDF Data Cube is QB [26]. Kampgen et al. proposed a querying model of statistical Linked Data using common OLAP operations on RDF data cubes. The research also found a set of OLAP query functions and operators using the SPARQL language, and improved the QB vocabulary in order to enhance multidimensional statistical data representations [27].
Moreover, Etcheverry and Vaisman developed Open Cube (OC) vocabulary using RDFS to publish multidimensional cubes on the SW. The OC was developed to support models with dimensions with multiple hierarchies, but OC had the disadvantage that it could not reuse QB vocabulary that had been used before [28]. Ibragimov et al. developed a framework called Exploratory OLAP over RDF sources. This research proposes a system that uses RDF vocabularies to define an OLAP cube with a multidimensional schema. The system intelligently executes the query to extract and summarize data and build a cube based on the vocabulary [19]. Etcheverry et al. developed an extension of QB that models multidimensional data; it is called QB4OLAP. QB4OLAP supports flat hierarchies, and is recursive, ragged, and uses many-to-many relationships in the multidimensional model [29].
Furthermore, Kalampokis et al. developed a new method to speed up query execution using a materialized view of the RDF graph. Their approach involves the physical storage of summarized triples in the system for faster processing of SPARQL queries (MARVEL). Many application tools were built using this approach and were used by governments and in industry, e.g., http://opengovintelligence.eu, accessed on 5 April 2021 [30]. On the other hand, Boumhidi et al. proposed a method for directly querying the cube data modeled by QB vocabulary with an interactive OLAP via MDX to SPARQL mapping without materialization. This research also constructed a formal algebra of OLAP operations on data cubes published as Linked Data [31].
The combination approach fully integrates SW in all layers of the BI. Several researchers proposed this combination approach: Colazzo et al. proposed a bottom-up redesign of the core data analytics concepts and RDF data tools. This design is fitted with Linked Data with a rich semantic and heterogeneous format. This design uses a full RDF warehousing approach, where the data source and the DW are in RDF graph format. This research also defines analytical schema and queries and optimization techniques with schema materialization [32]. Bansal and Kagemann created ETL tools to integrate data from various heterogeneous sources by utilizing semantic data to enrich the integration process [33]. Nath et al. proposed a programmable framework called Semantic ET (SETL) that could support the development of a Semantic Data Warehouse. SETL used TBox and QB4OLAP schema to create Multidimensional data for Semantic and Non-Semantic Data Sources [34]. Our study focuses on developing a vocabulary extension of QB4OLAP vocabulary based on an analytical approach.

Mobility Data Warehouse
Data warehousing technologies are needed to support the efficient collection, integration, storage, and analysis of the mobility pattern, yielding the notion of the Mobility Data Warehouse (DW) [7]. Mobility DW is the heart of mobility analytics, an extension of Business Intelligence (BI) that supports the collection, analysis, and presentation of information over moving object data. A Mobility DW deploys business intelligence by taking advantage of the operations associated with spatiotemporal data types to allow complex queries [7].
Trajectory DW is strongly related to mobility DW. Trajectory DW stores moving object data using base types, spatial types, and trajectories. A number of mobility analysis works that used the trajectory data warehouses (TDW) approach were published. For example, TDW was used for a recommender system for tourists [35], for road traffic analysis [36], and for finding the best location of billboard placement [37]. Further, some researchers added semantic information for TDW, such as for improving nurse productivity [38], mobility analysis [39], and modeling multiple aspect trajectories [8] to support decision making. However, according to the definition in [8], these research studies could not be classified as spatiotemporal DW since they did not support spatiotemporal queries and include moving data types [12].
Vaisman et al. defined the notion of spatiotemporal queries with aggregation extended with spatial and moving data types [10]. Based on this, they implemented Mobility DWs with spatiotemporal query support on MobilityDB, an object-relational DBMS. This implementation claimed to be supporting the spatiotemporal OLAP queries defined in [8]. Our research on this Mobility DW also supports spatiotemporal OLAP queries and moving data types represented on the SW and SPARQL.

Geospatial Semantic Web
The Spatiotemporal Multidimensional Data model on the SW starts from the Spatial SW, commonly referred to as Geospatial SW. The development of Geospatial SW began with finding a new retrieval method for geospatial data built on the semantics of spatial and ontologies developed at the University of Maine [40]. Then, the W3C SW Interest Group standardized Basic Geo Vocabulary using WGS84 as a reference datum [41].
Perry et al. stated that the web has a significant amount of spatial and temporal data, and the technology of SW could potentially make the accessibility and usefulness of data better. Because of SPARQL's inability to query complex spatial and temporal data, Perry et al. proposed a new query language, SPARQL-ST, an extension of SPARQL for complex spatiotemporal queries. This research suggested a formal syntax and semantics and added spatial variables and constructs to manipulate temporal triples in SPARQL-ST, and was applied as a prototype built on top of a commercial DBMS [42]. Their work has many features but is still limited to essential operation for spatiotemporal operations, and is not applied for aggregation and analytical query functions.
Research on spatiotemporal data on the SW has been successfully implemented, such as Linked Geospatial Data in the UK government, followed by the manufacture of geospatial datasets by the Ordnance Survey Company for regions in the UK. These implementations could be accessed using SPARQL Endpoints [6]. Linked data are becoming popular with the advent of Geonames, a dataset in the form of linked data that collects spatial and thematic information for place names in different hemispheres and in various languages. The information stored in it is in the form of latitude, longitude, altitude, and population, and the administrative information is consistent with the 1984 World Geodetic System (WGS84) rules. Furthermore, there is LinkedGeodata, a linked data that is an SW infrastructure converted from OpenStreetMap. This linked data helps integrate and aggregate data related to maps [43] and can be easily queried with SPARQL. This approach attracts many researchers as a promising spatial linked data paradigm, but this approach still does not cover temporal data.
The temporal aspect then entered as a Spatiotemporal SW in the development of YAGO2 ontology, a continuation of YAGO knowledge-based ontology, where entities, events, and facts are combined with space-time information. YAGO2 was developed by automating Wikipedia, GeoNames, and WordNet. At present, YAGO2 contains 447 million facts and 9.8 million entities. YAGO2 uses the SPOTL model data (five tuples), an ex-tension of SPO (3 tuples). Entities on YAGO2 are assigned a period, while the fact is assigned a time point or period [44]. YAGO2 became an excellent way to enrich large spatiotemporal knowledge-based data, but it did not have query functions for its spatiotemporal representation.
Furthermore, a query language, with the addition of geographic features to SPARQL, was developed, namely GeoSPARQL. GeoSPARQL is an SW vocabulary that provides geospatial data representation [45]. GeoSPARQL has two essential parts: an ontology for the storing of geospatial objects and query functions for the processing of relationships between the geospatial entities. The ontology was developed from the OGC standards, which have expressive concepts and terminology. The ontology of the GeoSPARQL is built to be small so that it can be easily understood and attached. The GeoSPARQL ontology has two main classes: Feature and Geometry. A Feature is an entity with spatial attributes. An example of the Feature is a building, statue, palace, lake, etc. Geometry is a shape, for example, a point, line, triangle, hexagon, etc., representing a feature's spatial location. The third class, SpatialObject, is a superclass of both Feature and Geometry. GeoSPARQL became a geospatial RDF standard from W3C for data modeling and querying [46]. GeoSPARQL has some impressive features for geospatial implementation on the SW; this language did not accommodate analytical queries and has no extension for spatiotemporal and mobility data representation and querying.
Another proposal that is similar to GeoSPARQL is the development of stRDF/stSPARQL. The stRDF is a data model with an RDF extension and represents geospatial information that changes over time [47]. stRDF defines spatial and temporal dimensions that have literal spatial and spatial data types. stRDF also uses OGC standards such as WKT and GML for serialization. stSPARQL was developed as an extension query language for SPARQL by adding functions defined in the OpenGIS standard Simple Feature Access. These functions are in the form of basic functions (get, set), basic function access functions (equals, disjoint, intersect, touches, crosses, within, contains, overlaps, and relate), Egenhofer, RCC8, spatial analysis functions, spatial metric functions (distance and area), the spatial aggregate function (union, intersection, and extent). Strabon was then developed as an RDF store that supports semantic geospatial query languages in stSPARQL and GeoSPARQL. Strabon has expressive power in its use of these query languages with the stRDF model data. The testing of performance at strategic scales, for vast volumes of data, yielded good results [47]. stRDF/stSPARQL accommodates significant spatial data representation and query implementations, but it still lacks spatiotemporal data adoption and analytical capabilities.
Zhang et al. proposed a SPARQL extension for modeling and querying a quantitative spatiotemporal relationship. The extension model adds an event model with time and space. The query extension created 30 new query operators that could effectively find the unseen connections between event ontology entities and have excellent performance and effectiveness [48]. This approach comprehensively adds SPARQL functionality, but this approach still does not handle the spatiotemporal analytical query. On the other hand, Gur et al. proposed QB4SOLAP, a generic and extensible vocabulary (meta-model) for spatial DW on the SW. QB4SOLAP extends the QB4OLAP vocabulary with spatial concepts. They also give a formalization of QB4SOLAP. This paper defined critical spatial cube concepts, spatial hierarchies and levels, spatial measures, spatial aggregation functions, and topological relations among spatial dimension and hierarchy level members. They also defined several analytical spatial OLAP operators over QB4SOLAP, these operators' formal semantics, and algorithms to generate spatially extended SPARQL queries [3]. This work provides a significant result in terms of the modeling and querying of spatial analytical data, but it is only limited to spatial data and does not include MOs data with more dynamic characteristics. In this study, we enhanced the QB4SOLAP capability to support mobility analysis for MOs data.

Research Methods
This research constructs a new vocabulary of Mobility DW on the SW that allows the definition of Mobility DW over RDF data and develops mobility query functions in SPARQL. This section explains the notions of mobility data types, operators, OLAP operators, and data sources as base concepts in this study. Hence, the last subsection describes a use case scenario for the evaluation method by implementing mobility DW in the new vocabulary and exploring descriptive, diagnostic, and discovery analysis in SPARQL.

Mobility Data Type
This research explores a new vocabulary to represent MOs on the SW for mobility analysis related to the MO data type for the purpose of query retrieval. The MO data have a data type that consists of spatial and temporal attributes. Spatial attributes describe real-world phenomena consisting of descriptive components presented with traditional data types such as integers, booleans, strings, and dates. Spatial attributes enriched with spatial extent components explain the real world in geometric data types such as Point, Multi Points, Line, Polygon, and Surface (MADS Model). Spatial attributes are stored differently and are often called thematic layers (themes).
Temporal attributes describe time and changes in time that could be defined with time types and temporal types. Guting et al. define temporal types as moving types [49]. Time types represent the time, for instance, timestamp, timestamp with time zone, period, timestamp set, and period set. Temporal types are based on time types. Temporal types include temporal integer, temporal float, temporal points, and temporal geometries. The temporal integer type could represent the evolution of employee salary. Temporal points denote the flight path of an aircraft or tourist. An example of a temporal float is the temperature of the human body.
The combination of spatial and temporal types creates new data types called temporalspatial types [50]. This combination occurs in moving objects, such as pedestrians, trucks, moving clouds, and shrinking agricultural areas that are mostly represented using the point and polygon. Figure 1 shows an example of moving trucks in our use case of an oil palm plantation. These trucks deliver Oil Palm Fruit Fresh Bunches (FFB) from plantations to the Oil Palm Mill (OPM).  Table 1 shows a sample of mobility data that have temporal-spatial types. The data contain the time, the locations of the trucks in longitude and latitude, and the float types   Table 1 shows a sample of mobility data that have temporal-spatial types. The data contain the time, the locations of the trucks in longitude and latitude, and the float types of the truckload values. Our mobile apps captured this data to monitor the truckload and trajectory in the Oil Palm Fruit Plantation [51]. The temporal-spatial types could be extended to represent a field/region that varies in time and space. The spatiotemporal database is then used to store spatial types, temporal types, and temporal-spatial types. This database could store the position of moving objects at any point in time, changing regions continuously, and so on. Although some examples of queries could be solved, such as "When the last truck starting from Alfa Block arrive at Palm Oil Mills?", "How fast the last truck arrived at Palm Oil Mills this morning shift?", this kind of database does not provide a foundation for such complex analytical queries as "What is the average truckload passing the #27 road segment on the Alfa block in the X Company's oil palm plantations this year?" or "What is the total weight of oil palm production carried by company trucks in each plantation block in the third quarter of 2020?". These kinds of queries could be handled efficiently using Mobility DW with mobility operation capabilities. The Mobility DW has extended support for the concept of spatiotemporal data warehouses that contain spatial types, temporal types, and temporal-spatial types of data.
Implementation of the temporal types could be found on MobilityDB [52], as a data type tbool, tint, tfloat, ttext, based on the primitive data types boolean, integer, real and text, respectively. MobilityDB also has temporal-spatial types such as tgeompoint and tgeogpoint, which are based on spatial type points [53]. Because they allow the representation of values that change over time, temporal types are useful in mobility domain applications. Temporal types provide a more natural and simple representation of time-varying value. Additionally, when the values evolve over time, the operations on the base types (such as arithmetic operators and aggregation for integers and floats, and spatial relationships and distance for spatial types) can be intuitively generalized. A temporal type of instance, intuitively, represents a function from time to the base type. An example of temporal types for the representation of the truckload of DeliveryId 323 of Table 1  In summary, Mobility analysis needs temporal-spatial types as mobility data types and a collection of related data types, including primitive types (e.g., boolean, integer, float, text), spatial types (e.g., point, line, region), and time types (e.g., periods, instant, period set).

Mobility Operator
Mobility data types have operators and functions associated with this type. These operators can be classified, including projection to a domain or range, boolean predicates, interaction with a domain or range, spatial operations, temporal operations, the rate of change, mobility aggregation, and lifting function aggregation.
Projection to a domain or range function is a function that is used to define the temporal types. These operations are DefTime, RangeValues, Trajectory, and Traverse. These operations can be defined as: DefTime: moving(α) → periods for α ∈ {boolean, integer, real, text, point, region}. DefTime is a function that gives moving as a constructor function that returns, for a given argument type α, the type whose values are partial functions from instant into α. RangeValues: moving(α) → range(α) for α ∈ {boolean, integer, real, text, point, region}. The RangeValues is a projection of moving values into its range; for example, moving real returns a set of real intervals. The range is a constructor function that returns for an argument type α, the corresponding type whose values are sets of intervals over α. The RangeValues function can be instantiated, for example, to: The Trajectory function is a function that has a moving point or a moving region as a parameter. This function projects into the range (the 2D space). For a moving point, this projection is usually a curve in the 2D plane, and for a moving region, it is a region; line and region are spatial types. For example, the Trajectory function for a moving point, Trajectory(DeliveryPath323), will return the line (−7.7737022 110.4307821, −7.7737022 110.4307821, . . . . . . , −7.7753163 110.4306087), while the Trajectory function for a moving region will return the region. Figure 2 shows another example of the trajectory of two routes, RouteT and RouteS, that intersect at time 8:20. a parameter. This function projects into the range (the 2D space). For a moving point, this projection is usually a curve in the 2D plane, and for a moving region, it is a region; line and region are spatial types. For example, the Trajectory function for a moving point, Trajectory(DeliveryPath323), will return the line (−7.7737022 110.4307821, −7.7737022 110.4307821, ……, −7.7753163 110.4306087), while the Trajectory function for a moving region will return the region. Figure 2 shows another example of the trajectory of two routes, RouteT and RouteS, that intersect at time 8:20.  Temporal Aggregation operations is an operator that takes a temporal integer or real and yields a temporal real. Some temporal aggregation operations are: TWAvg: moving (α) → real Integral/Duration TWStDev : moving(α) → real

√ TVariance
TWMin: moving(α) → real Min(RangeValue(α)) TWMax: moving(α) → real Max(RangeValue(α)) The lifting function is a function that generalizes non-temporal data types to mobility data types. The lifting operation over non-temporal types substitutes its argument types for each time type and returns a temporal type. The operation more than and equal (≥) has lifted versions; for instance, one or both of its parameters can be of the temporal type, resulting in a time boolean.
Aggregation operations can be lifted in the same way. A lifted Avg operation, for example, merges a set of temporal reals to produce a new temporal real in which the average is computed at each instant. Figure 3 depicts a sample of the TAvg and TSum aggregation of the truckload delivery.

Mobility OLAP Operator
Mobility analysis needs OLAP operators for the expression of queries over data cubes. Mobility OLAP enhances the analytical capabilities of OLAP by taking into account the cube's mobility information. These OLAP operators are roll-ups that aggregate measures along a hierarchical structure to obtain data with a coarser granularity. These operators are enriched with the aggregation function and operators, such as mobility aggregation, mobility spatial, and the aggregation lifting function. By selecting an individual instance at a dimension level, the slice operator removes a dimension from a cube. The dice operator reveals which cells in a cube satisfy a specified condition. The Spatial Slice and Spatial Dice enrich the OLAP operators proposed by the QB4SOLAP vocabulary [54]. Some functions enhance the spatial mobility operators: InsideGeometry, AtPeriod, AtTimeStamp, At, etc. Finally, the drill-down operator disaggregates measures along a hierarchical structure to obtain more detailed data. It is the inverse of the roll-up operation. Table 2 shows the mobility functions and operators of mobility data types.

Mobility OLAP Operator
Mobility analysis needs OLAP operators for the expression of queries over data cubes. Mobility OLAP enhances the analytical capabilities of OLAP by taking into account the cube's mobility information. These OLAP operators are roll-ups that aggregate measures along a hierarchical structure to obtain data with a coarser granularity. These operators are enriched with the aggregation function and operators, such as mobility aggregation, mobility spatial, and the aggregation lifting function. By selecting an individual instance at a dimension level, the slice operator removes a dimension from a cube. The dice operator reveals which cells in a cube satisfy a specified condition. The Spatial Slice and Spatial Dice enrich the OLAP operators proposed by the QB4SOLAP vocabulary [54]. Some functions enhance the spatial mobility operators: InsideGeometry, AtPeriod, At-TimeStamp, At, etc. Finally, the drill-down operator disaggregates measures along a hierarchical structure to obtain more detailed data. It is the inverse of the roll-up operation. Table 2 shows the mobility functions and operators of mobility data types.

Use Case Scenario: Oil Palm Fresh Fruit Bunches Transportation
This research utilizes the use case in the transportation of the oil palm fresh fruit bunches (FFB) in Indonesia's plantations. This use case is applied to evaluate or prove the concept of the QB4MobOLAP Vocabulary and its query function. The palm plantation wants to minimize transportation time, cost, and loading/unloading time to increase the quality of the fresh fruit by means of Mobility OLAP in order to find descriptive, diagnostic, and discovery information. Figure 4 depicts the FFB transportation process from harvesting until Palm Oil Mill (POM). Fruit harvesting is the first step of the crucial phase in the FFB transportation process. The fruit is then collected into the Fruit Collection Point (FCP) using such technology as the net system or the grabber system, or is collected manually. After being collected, the Fresh Fruit Bunch (FFB) will be transported to the POM according to the following steps: loading to the truck, thrilling to the POM, entering and queueing in the factory gate, weighing, and unloading into the loading ramp, and finally, the FFB will be processed in the POM. This cycle takes time and significantly affects the quality of the palm oil, especially when the fruit has bruised.

Use Case Scenario: Oil Palm Fresh Fruit Bunches Transportation
This research utilizes the use case in the transportation of the oil palm fre bunches (FFB) in Indonesia's plantations. This use case is applied to evaluate or p concept of the QB4MobOLAP Vocabulary and its query function.
The palm plantation wants to minimize transportation time, cost, and load loading time to increase the quality of the fresh fruit by means of Mobility OLAP to find descriptive, diagnostic, and discovery information. Figure 4 depicts the FF portation process from harvesting until Palm Oil Mill (POM). Fruit harvesting is step of the crucial phase in the FFB transportation process. The fruit is then collec the Fruit Collection Point (FCP) using such technology as the net system or the system, or is collected manually. After being collected, the Fresh Fruit Bunch (F be transported to the POM according to the following steps: loading to the truck, to the POM, entering and queueing in the factory gate, weighing, and unloading loading ramp, and finally, the FFB will be processed in the POM. This cycle tak and significantly affects the quality of the palm oil, especially when the fruit has b

Use Case Scenario: Oil Palm Fresh Fruit Bunches Transportation
This research utilizes the use case in the transportation of the oil palm fresh fruit bunches (FFB) in Indonesia's plantations. This use case is applied to evaluate or prove the concept of the QB4MobOLAP Vocabulary and its query function.
The palm plantation wants to minimize transportation time, cost, and loading/unloading time to increase the quality of the fresh fruit by means of Mobility OLAP in order to find descriptive, diagnostic, and discovery information. Figure 4 depicts the FFB transportation process from harvesting until Palm Oil Mill (POM). Fruit harvesting is the first step of the crucial phase in the FFB transportation process. The fruit is then collected into the Fruit Collection Point (FCP) using such technology as the net system or the grabber system, or is collected manually. After being collected, the Fresh Fruit Bunch (FFB) will be transported to the POM according to the following steps: loading to the truck, thrilling to the POM, entering and queueing in the factory gate, weighing, and unloading into the loading ramp, and finally, the FFB will be processed in the POM. This cycle takes time and significantly affects the quality of the palm oil, especially when the fruit has bruised.   h utilizes the use case in the transportation of the oil palm fresh fruit Indonesia's plantations. This use case is applied to evaluate or prove the 4MobOLAP Vocabulary and its query function. antation wants to minimize transportation time, cost, and loading/uncrease the quality of the fresh fruit by means of Mobility OLAP in order e, diagnostic, and discovery information. Figure 4 depicts the FFB transfrom harvesting until Palm Oil Mill (POM). Fruit harvesting is the first l phase in the FFB transportation process. The fruit is then collected into on Point (FCP) using such technology as the net system or the grabber ected manually. After being collected, the Fresh Fruit Bunch (FFB) will the POM according to the following steps: loading to the truck, thrilling ring and queueing in the factory gate, weighing, and unloading into the d finally, the FFB will be processed in the POM. This cycle takes time affects the quality of the palm oil, especially when the fruit has bruised. cenario: The business process of FFB transportation.
ws an example of the MultiDim logical model of Mobility DW for Oil ortation analysis. The design has a Delivery Fact Table that has mobility ensions. The Fact Delivery has five measures. Route t( ) is a measure of ruck positions at any point in time. The Load t() is an integer type measover time. The trajectory is a spatial type of measure represented by a ) measure, as a temporal point type, allows deliveries to be aggregated along the dimensions. For example, a similar route could be merged into a single route; the route could be a union and an intersection, etc. Thus, a query such as "give me the total distance of trajectory by TruckOwner" or "give me the total truckload that passes road segment X in February" could be answered. A query such as "give the average of fruit loading time by month and plantation block", where fruit loading time has been computed using a spatial operator within a radius, could be computed. These queries are examples of a spatial roll-up function. The delivery fact has a relationship with five dimensions, Truck, Date, and Plantation, where the latter is a spatial dimension related to the fact through many-tomany relationships. The truck dimension is composed of two levels with a one-to-many relationship. Spatial attributes or levels have an associated geometry (point, line, or region), which are indicated by symbol 13 of 27 unction and aggregation operators of mobility types (adapted from [50]

Use Case Scenario: Oil Palm Fresh Fruit Bunches Transportation
This research utilizes the use case in the transportation of the oil palm fresh fruit ches (FFB) in Indonesia's plantations. This use case is applied to evaluate or prove the cept of the QB4MobOLAP Vocabulary and its query function. The palm plantation wants to minimize transportation time, cost, and loading/unding time to increase the quality of the fresh fruit by means of Mobility OLAP in order ind descriptive, diagnostic, and discovery information. Figure 4 depicts the FFB transtation process from harvesting until Palm Oil Mill (POM). Fruit harvesting is the first of the crucial phase in the FFB transportation process. The fruit is then collected into Fruit Collection Point (FCP) using such technology as the net system or the grabber tem, or is collected manually. After being collected, the Fresh Fruit Bunch (FFB) will ransported to the POM according to the following steps: loading to the truck, thrilling he POM, entering and queueing in the factory gate, weighing, and unloading into the ding ramp, and finally, the FFB will be processed in the POM. This cycle takes time significantly affects the quality of the palm oil, especially when the fruit has bruised.  The Route t( ) measure, as a temporal point type, allows deliveries to be aggregated along the dimensions. For example, a similar route could be merged into a single route; the route could be a union and an intersection, etc. Thus, a query such as "give me the total distance of trajectory by TruckOwner" or "give me the total truckload that passes road segment X in February" could be answered. A query such as "give the average of fruit loading time by month and plantation block", where fruit loading time has been computed using a spatial operator within a radius, could be computed. These queries are examples of a spatial rollup function. The delivery fact has a relationship with five dimensions, Truck, Date, and Plantation, where the latter is a spatial dimension related to the fact through many-tomany relationships. The truck dimension is composed of two levels with a one-to-many relationship. Spatial attributes or levels have an associated geometry (point, line, or region), which are indicated by symbol , and respectively. and The Route t( ) measure, as a temporal point type, allows deliveries to be aggregated along the dimensions. For example, a similar route could be merged into a single route; the route could be a union and an intersection, etc. Thus, a query such as "give me the total distance of trajectory by TruckOwner" or "give me the total truckload that passes road segment X in February" could be answered. A query such as "give the average of fruit loading time by month and plantation block", where fruit loading time has been computed using a spatial operator within a radius, could be computed. These queries are examples of a spatial rollup function. The delivery fact has a relationship with five dimensions, Truck, Date, and Plantation, where the latter is a spatial dimension related to the fact through many-tomany relationships. The truck dimension is composed of two levels with a one-to-many relationship. Spatial attributes or levels have an associated geometry (point, line, or region), which are indicated by symbol , and respectively. month and plantation block", where fruit loading time has been computed using a spatial operator within a radius, could be computed. These queries are examples of a spatial rollup function. The delivery fact has a relationship with five dimensions, Truck, Date, and Plantation, where the latter is a spatial dimension related to the fact through many-tomany relationships. The truck dimension is composed of two levels with a one-to-many relationship. Spatial attributes or levels have an associated geometry (point, line, or region), which are indicated by symbol , and respectively. The Plantation and FruitCollectionPoint dimensions are spatial dimensions. These dimensions share a geographical hierarchy where geometry is associated with each level in both dimensions. The FruitCollectionPoint Dimension has topological constraints that indicate an FCP in the Plantation Block, and the Plantation Block is contained in Plantation Afdeling and creates a parent-child relationship.

QB4MobOLAP Vocabulary
In this section, the mobility data cubes in the RDF representation are defined. The definition uses the FFB Transportation DW as an example, the logical schema of which is given in Figure 6. The QB4MobOLAP Vocabulary allows the defining of cube schemas and cube instances as RDF triples. QB4MobOLAP extends the QB4OLAP Vocabulary with mobility concepts to support Mobility OLAP operations directly over RDF data with SPARQL queries. Figure 6 shows the proposed QB4MobOLAP Vocabulary. The gray backgrounded rectangle is an extension vocabulary class, subclass, and object property from QB and QB4OLAP. These classes could be used to represent the mobility cube class. The Plantation and FruitCollectionPoint dimensions are spatial dimensions. These dimensions share a geographical hierarchy where geometry is associated with each level in both dimensions. The FruitCollectionPoint Dimension has topological constraints that indicate an FCP in the Plantation Block, and the Plantation Block is contained in Plantation Afdeling and creates a parent-child relationship.

QB4MobOLAP Vocabulary
In this section, the mobility data cubes in the RDF representation are defined. The definition uses the FFB Transportation DW as an example, the logical schema of which is given in Figure 6. The QB4MobOLAP Vocabulary allows the defining of cube schemas and cube instances as RDF triples. QB4MobOLAP extends the QB4OLAP Vocabulary with mobility concepts to support Mobility OLAP operations directly over RDF data with SPARQL queries. Figure 6 shows the proposed QB4MobOLAP Vocabulary. The gray backgrounded rectangle is an extension vocabulary class, subclass, and object property from QB and QB4OLAP. These classes could be used to represent the mobility cube class. QB4MobOLAP extends the built-in function QB4OLAP, which is represented with the classes qb4mob:MobilityTemporalAggrFunction and qb4mob:MobilitySpatialAggrFunction in the vocabulary. The qb4mob:MobilityTemporalAggrFunction class has the instances qb4mob:TAvg, qb4mob:TCount, qb4mob:TMin, qb4mob:TMax, and qb4mob:TSum. The qb4mob:MobilitySpatialAggrFunction class has the instances qb4mob:TCentroid, qb4mob:TUnion, qb4mob:TConvexHull, qb4mob:TIntersect, and qb4mob:TMBR. The QB4MobOLAP also introduced the class qb4mob:MobilityObject to represent mobility data types. The qb4mob:MobilityObject has the subclasses qb4mob:MobilityBase to store temporal types and qb4mob:MobilityGeometry to store temporal-spatial types, as described in Section 3. The qb4mob:MobilityBase has the subclasses qb4mob:MobilityInteger and qb4mob:MobilityDecimal, and the qb4mob:MobilityGeometry has the subclasses qb4mob:MobilityPoint, qb4mob:MobilityCurve, and qb4mob:MobilitySurface. qb4mob:TCentroid, qb4mob:TUnion, qb4mob:TConvexHull, qb4mob:TIntersect, and qb4mob:TMBR. The QB4MobOLAP also introduced the class qb4mob:MobilityObject to represent mobility data types. The qb4mob:MobilityObject has the subclasses qb4mob:MobilityBase to store temporal types and qb4mob:MobilityGeometry to store temporal-spatial types, as described in Section 3. The qb4mob:MobilityBase has the subclasses qb4mob:MobilityInteger and qb4mob:MobilityDecimal, and the qb4mob:Mobili-tyGeometry has the subclasses qb4mob:MobilityPoint, qb4mob:MobilityCurve, and qb4mob:MobilitySurface.

Multidimensional Data Cube Definition in QB4MobOLAP
The QB4OLAP vocabulary modeled a multidimensional data cube in RDF terms. Multidimensional models are typically interpreted as data cubes, with cube cells corresponding to observational facts that are central to MD analysis. Facts have a set of properties called measures, which have aggregate functions that can be defined. To provide alternative analytic viewpoints, a data cube has n dimensions (with the attribute of contextual information) on a multidimensional space, where each dimension might have hierarchies with levels. Users can aggregate measures (of facts) at multiple levels of detail by using levels (of dimensions) (also known as granularity). Dimensions and facts are tied to the structure to assist this analysis at various detail levels. Levels also include attributes that describe the basic features of the members of the level.
These MD concepts (cube elements) and their roles and relationships are annotated at the schema level in RDF triple format using the QB4OLAP Vocabulary. Schema level (RDF) cube elements correspond to tables and columns (of tables) in an MD. Fact members

Multidimensional Data Cube Definition in QB4MobOLAP
The QB4OLAP vocabulary modeled a multidimensional data cube in RDF terms. Multidimensional models are typically interpreted as data cubes, with cube cells corresponding to observational facts that are central to MD analysis. Facts have a set of properties called measures, which have aggregate functions that can be defined. To provide alternative analytic viewpoints, a data cube has n dimensions (with the attribute of contextual information) on a multidimensional space, where each dimension might have hierarchies with levels. Users can aggregate measures (of facts) at multiple levels of detail by using levels (of dimensions) (also known as granularity). Dimensions and facts are tied to the structure to assist this analysis at various detail levels. Levels also include attributes that describe the basic features of the members of the level.
These MD concepts (cube elements) and their roles and relationships are annotated at the schema level in RDF triple format using the QB4OLAP Vocabulary. Schema level (RDF) cube elements correspond to tables and columns (of tables) in an MD. Fact members with measure values and level members with attribute values are instance-level MD concepts annotated at the instance level with QB4MobOLAP Vocabulary. These instance level (RDF) cube elements correspond to the actual data rows/records annotated in triple format with QB4MobOLAP.
An RDF triple t is made up of three parts: the subject (s), the predicate (p), and the object (o), which is defined as triple (s,p,o) ∈ t = (I ∪ Bn) × I × (I ∪ Bn ∪ L), where I is the set of IRIs, Bn is the set of blank nodes, and L is the set of literals. The Cube Schema (CS), with element x defined as CS(x) ∈ (I ∪ Bn ∪ L), yields a set of triples T and is denoted by (x rdf:type ex:Property).
MD Schema. A data structure definition (DSD) contains information about the schema of a data set (i.e., a cube, an instance of the class qb:DataSet). The DSD can be applied to a variety of data sets. A data set's DSD includes dimensions, levels, measures, and attributes, in addition to component properties. As CS = DSD, the DSD is defined by a conceptual MD cube schema CS, which includes a collection of dimension types D, a collection of measures M, and a collection of fact types as CS = (D, M, F). The following definitions apply to the cube schema elements: Attributes. An attribute a ∈ A = {a 1 , a 2 , . . . , a n } has a domain a:dom in the cube schema CS with a set of triples t a ∈ T where t a is represented as (a rdf:type qb:AttributeProperty; rdfs:domain xsd:Schema). Levels. A level l ∈ L = {l 1 , l 2 , . . . , l n } consists of a set of attributes A l , which is defined by a schema l(a 1 : dom 1 , . . . , a n : dom n ), where l is the level, and each attribute a is defined over the domain dom. For each level l ∈ L in the cube schema CS, a set of triples tl ∈ T, is represented as (l rdf:type qb4o:LevelProperty; qb4o:hasAttribute a). Relevant levels for FFB DW examples are the Plantation level and the Afdeling level, described in example 1. Afdeling is an area in a plantation that is larger than a block. An afdeling has many blocks. Hierarchies. A hierarchy h ∈ H = {h 1 , h 2 , . . . , h n }, in the cube schema CS, is specified with a set of triples t h ∈ T, and represented as (h rdf:type qb4o:HierarchyProperty; qb4o:hasLevel l; qb4o:inDimension D). h ∈ H is specified as h = (Lh, Rh) for each hierarchy, where Lh is a hierarchy level. Lh is a subset of Ld levels of the dimension D where Lh ⊆ Ld ∈ D and Ld is the dimension level. A hierarchy has a roll-up relation between its level, denoted by Rh, Rh = (Lc, Lp, c) where Lc and Lp are child and parent levels, respectively, and c is Cardinality, c ∈ {1 − 1, * − 1, 1 − *, * − *}, where * is many. For instance, Rh = (Afdeling, Plantation, *−1) shows that the roll-up relation between the child level Afdeling to the parent level Plantation is many-to-one, which means that plantation could have many afdelings. Relevant hierarchies for FFB DW examples include PlantationGeography, which is described in example 2.  . An example of a fact instance f with its relation to measure values and dimension levels is a sale transaction from customer "Anton" (dimension level value), for a product "Digital Camera" (another dimension level value), with a unit price of "1000" (measure value) Malaysian Ringgit, and a sales amount of "2" (another measure value) units. The fact member and dimension level customers have one-to-many relationships, which means that the same customer can make multiple sales. The aggregate function can be specified to measure unit price as "Average/Avg", and the sales amount can be specified as "Sum".

Defining Spatiotemporally Enhanced MD Data in QB4MobOLAP
Spatial Attributes. Spatial attributes are specified on a domain level. Each attribute with a geometry domain (sa: domgeo ∈ A) is a member of the geo:Geometry class and is referred to as a spatial attribute, which is represented in the cube schema CS as (sa rdf:type qb:AttributeProperty; rdfs:domain geo:Geometry). In the instances, each spatial attribute type (point, polygon, line, etc.) is assigned using the predicate rdfs:range. Spatial Levels. In the cube schema CS, a spatial level ls ∈ L is defined by a set of triples t ls ∈ T and represented as (ls rdf:type qb4o:LevelProperty; qb4o:hasAttribute a, as; geo:hasGeometry geo:Geometry). Spatial levels must be geo:Geometry class members and may have spatial attributes. Example 4 shows the Plantation level as a spatial level with spatial attributes. Spatial Hierarchies. Two or more spatial levels l s relate to each other to create a spatial hierarchy h s ∈ H. The spatial hierarchy step describes a roll-up relation between the spatial levels. QB4SOLAP introduces topological relations, T r , in addition to cardinalities in the roll-up relation that are encoded as R = (L c , L p , c, T r ) for the spatial hierarchy steps. Let t shs ∈ T be a set of triples to represent a hierarchical step for spatial levels in hierarchies, which is given with a blank node: _sh hs ∈ B and encoded as (:_shhs rdf:type qb4o:HierarchyStep; qb4o:childLevel slhci; qb4o:parentLevel slhpi; qb4o:cardinality c; qb4so:hasTopologicalRelation Tr) where slhci ∈ Lc, slhpi ∈ Lp. For example, a spatial hierarchy is "geography", which should have spatial levels (e.g., FruitCollectionPoint, Block, Afdeling, and Plantation) with the roll-up relation Rh = (Block, Afdeling, manyto-one, within), which also specifies that the child-level Afdeling is "within" the parent level Plantation.
Spatial Dimensions. Dimensions are considered spatial if they contain at least one spatial hierarchy. More than one dimension can share the same spatial hierarchy and spatial levels as that hierarchy.
Spatial Measures. A Spatial measure sm ∈ M is specified by a set of triples t sm ∈ T and represented as (sm rdf:type qb:MeasureProperty; rdfs:subPropertyOf sdmx-measure: obsValue; rdfs:domain geo:Geometry) in the cube schema CS. Spatial measures are represented by a geometry that uses geometry serialization standards in OGC schemas. For example, a spatial measure is a trajectory that contains a list of coordinates of locations, which is given as a line geometry type and is associated with an observational fact of the trajectory of delivery.
Mobility Measures. A mobility measure mm ∈ M is specified in the cube schema CS by a set of triples t mm ∈ T and encoded as (mm rdf:type qb:MeasureProperty; rdfs:subPropertyOf sdmx-measure:obsValue; rdfs:domain qb4mob:MobilityBase/MobilityGeometry). The class of the numeric value is given with the property rdfs:domain, and rdfs:range assigns the values from the class qb4mob:MobilityBase/mobilityPoint, i.e., the temporal integer, temporal float, temporal point, temporal polygon, etc., at the instance level. Mobility measures are represented by a mobility base/geometry. These mobility measures use schema extension of OGC schemas with temporal natures that change over time.
Mobility Facts. Mobility facts F m have mobility/spatiotemporal natures that are related across several dimensions, either spatial or temporal. The mobility fact cube has mobility measures (m m ), as its members make it possible to aggregate mobility measures with the aggregation functions M agg . Representation of a complete mobility fact cube at the schema level in RDF is given by a set of triples t fs ∈ T and encoded as (fs a qb:DataStructureDefinition; qb: component [qb: measure ms, sdmx-measure:obsValue; qb4mob:aggregate-functionMAF]). QB4MobOLAP extends the built-in functions of QB4OLAP with mobility aggregation functions, which are added with the class qb4mob: MobilityTemporalAggrFunc or qb4mob:MobilitySpatialAggrFunc. An example of a mobility fact instance f m with its relation to measuring values and dimension levels is a truck route delivery of some fruits (ffb:Route), which are created routes with coordinate points of the location that change by time. The cardinality of the dimension level truck and fact member is one-to-many, where a truck could have some delivery routes. Specification of the mobility aggregate function for route (coordinate points by time) can be specified as the "Time Centroid/TCentroid" route of locations.

Defining MD Data Instance in QB4MobOLAP
The previous sub-chapter has shown that the data cube schema can be represented using QB4MobOLAP in the RDF format. This sub-chapter will explain the representation of the Delivery cube instance using QB4MobOLAP. The notation Graph Instance (GI) represents the RDF Graph of the data cube instance. The notation ffbi: is used for the prefix of GI, and the subgraph that refers to the specific instance with the index i is denoted by GI (i).
Level Members. A level l has a set of level members LM (l) ={lm 1 ,..., lm y }. Each level member lm i has a unique IRI idI (lm i ) ∈ I, linked in the cube instance graph GI with the qb4o:LevelMember predicate. A level member is related to its level by the qb4o:memberOf property. The RDF graph formulation of the level members LM (l) is represented as GI LM(I) = {(id (l mi ) rdf:type qb4o:LevelMember)} ∪ {(id (lmi) qb4o:memberOf id (l))} Definition of Level Members' attributes. A level member has an attribute set l m = {a 1 , a 2 , . . . ., a p }, which is used to describe the characteristics of the level member. Each attribute a i is linked to the level member with the identifier id (a i ). Fact Members. A fact F has a set of data members FM (F) = {f 1 , f 2 , . . . , f t }, which are the instances of the data cube. Each fact f i ∈ FM has a unique IRI id (f i ) ∈ I, which is linked in the cube instance graph GI with the qb:Observation predicate. A fact member f i is related to a set of dimension level L(f i ) = { l 1 , l 2 , . . . ., l r }and has a set of measure M(m i ) = { m 1 , m 2 , . . . ., m r }. Each dimension level l j is linked to level member with the identifier id-S (l j ) and each measure m k is linked to the level member with the identifier id-S(m k ). Dimension values and measure values are associated with a fact F. Dimension values are denoted by f → v(d i ) and measure values denoted by f → v(m j ). The value of v(d i ) ∈ I, is the identifier of a level member in LM (l j ). The value of every measure m j is a literal such that v(d i ) ∈ L. The RDF graph formulation of the fact members FM (F) is represented as: The RDF representation example below shows the fact member of FFB DW using the above definition. Note that the fact member and corresponding level members relating to dimensions are given with the prefix ffbi:. idS (aID) is a surrogate key that links the fact member with the corresponding dimensions.

Querying the Fresh Fruit Bunch for Transportation and Production Analysis
To evaluate or give proof of concept regarding how to implement mobility data cube concepts on the SW, and express queries for transportation and production analysis, the Fresh Fruit Bunch (FFB) data warehouse was explored. The FFB DW was built to support factory executives and farmers' cooperation to analyze the transportation, loading/unloading, or even plantation productivity. The analysis aimed to reduce the transportation time to the POM to minimize the FFB quality loss, maximize the road support for effective FFB transportation, and maximize plantation productivity.
The queries are executed using the SPARQL, GeoSPARQL, and SPARQL function extensions for mobility queries that were developed in this research. These queries gather descriptive, diagnostic, and discovery analysis to know the event and phenomenon and the reason behind the event from the DW encoded in QB4MobOLAP vocabulary. The queries combine typical OLAP operations, such as roll-up, slice, spatial slice, temporal slice, and dice, with spatial and temporal operations on MOs.
The FFB DW contains 8826 triples consisting of approximately 7000 fact triples with nearly 1000 temporal data points each. In conventional data storage, the triple is equivalent to approximately 7 million records. The RDF graph is published using the GraphDB server on the Windows platform with a Pentium Core i5 8th generation with 16GB RAM computer. The server can be accessed at http://lod.if.fti.uajy.ac.id:7200/sparql, accessed on 10 June 2021.
Query#1: Give the average distance traveled by each truck per month in Q3 2019. Table 3 shows the experimental results for the six queries after five executions. Queries were executed many times to ensure optimal cache usage. It was shown that the Mobility DW on the SW has a convenient, simple model and expressive performance (below 3 s for regular OLAP query, below 1 min for spatiotemporal OLAP query with spatial slice combination, and approximately 2 min for OLAP query with extensive spatial slice combination). The spatial operations made the queries take a longer time. The usage of mobility fact measures in the DW adds query expressiveness and prevents extensive joining, as was the case for the previous segment trajectories proposal. Developing a detailed performance analysis as a comprehensive set of experiments is outside the scope of this paper and is planned in future work.

Conclusions and Future Works
This paper studied and provided a proof-of-concept of mobility modeling for the enhancement of multidimensional data cubes using RDF Semantic Web. This research presents the representation of Mobility DW with an extended mobility data type, specified user-defined mobility functions, and implemented the concept and functions in the new QB4MobOLAP vocabulary and SPARQL, respectively. QB4MobOLAP is an extension of QB4OLAP-the de facto standard Vocabulary for RDF Cube, which allows users to publish Mobility DW in the RDF format with mobility facts and measures that can be analyzed while taking into account contextual dimensions that are not restricted in pre-aggregate measures, as is the case for traditional DW representation. Integrating these mobility measures in DW realizes the notion of spatiotemporal queries defined in [55].
Users can publish Mobility multidimensional RDF data using the QB4MobOLAP Vocabulary. Thus, users can query from RDF endpoints using SPARQL's Mobility OLAP operators. The essential Mobility OLAP operations were defined to support users in mobility analysis, and these include Mobility Row Aggregation, Mobility Spatial Aggregation, Lifting Function Aggregation, Spatial Operation, and Temporal Operation. The evaluation of the vocabulary and operations was provided by implementing a real-world mobility query for FFB transportation analysis that illustrated the comprehensive set of queries and the execution performance.
Future works will be conducted to extend and optimize the implementation of the query operators in SPARQL, which is still limited in this research. For non-technical users, the SPARQL query language is complex. So, the challenge is also to provide high-level Mobility OLAP operators to help non-technical users.
Author Contributions: I.W. wrote the paper and code, S.K.B., N.A.E. and D.B.S. gave in-depth reviews and revised the paper. All authors have read and agreed to the published version of the manuscript.
Funding: This research did not receive any external funding.