Multidimensional enrichment of spatial RDF data for SOLAP

Abstract

Large volumes of spatial data and multidimensional data are being published on the Semantic Web, which has led to new opportunities for advanced analysis, such as Spatial Online Analytical Processing (SOLAP). The RDF Data Cube (QB) and QB4OLAP vocabularies have been widely used for annotating and publishing statistical and multidimensional RDF data. Although such statistical data sets might have spatial information, such as coordinates, the lack of spatial semantics and spatial multidimensional concepts in QB4OLAP and QB prevents users from employing SOLAP queries over spatial data using SPARQL. The QB4SOLAP vocabulary, on the other hand, fully supports annotating spatial and multidimensional data on the Semantic Web and enables users to query endpoints with SOLAP operators in SPARQL. To bridge the gap between QB/QB4OLAP and QB4SOLAP, we propose an RDF2SOLAP enrichment model that automatically annotates spatial multidimensional concepts with QB4SOLAP and in doing so enables SOLAP on existing QB and QB4OLAP data on the Semantic Web. Furthermore, we present and evaluate a wide range of enrichment algorithms and apply them on a non-trivial real-world use case involving governmental open data with complex geometry types.

Keywords

Spatial data warehouses SOLAP spatial RDF data cubes geospatial Semantic Web

1. Introduction

Data warehouses (DWs) and Online Analytical Processing (OLAP) tools and queries are widely used for interactive data analysis. DWs have multidimensional (MD) models and store large volumes of data. MD models locate data in an n-dimensional space and are usually referred to as data cubes. The cells of a cube represent the topic of the analysis and associate observation facts with (numerical) measures that can be aggregated. Spatial data cubes can also contain spatial measures, which can be aggregated with spatial functions. For example, a data cube for farms might have a numerical measure ‘number of animals’ as well as the ‘farm’s coordinates’ as spatial measure. Facts are linked to dimensions, which provide contextual information, e.g., farm production, farm location, and farm livestock. Dimensions are organized into hierarchies with levels, e.g., parish of the farm or herd type of livestock, which allow users to analyze and aggregate measures at different levels of detail. Levels have a set of attributes describing the characteristics of the level members.

In traditional DWs, the location dimension is generally used as a conventional (non-spatial) dimension with alphanumeric data and thus provided with only a nominal reference to places and areas, e.g., parish name. This does not allow for applying spatial operations or truly deriving topological relations between hierarchy levels based on geometric information such as coordinates, which are essential for enabling spatial OLAP (SOLAP) analysis.

By including the geometric information of locations in MD models, we can significantly improve the analysis process (e.g., proximity analysis of locations) with additional perspectives by revealing dynamic spatial hierarchy levels and new spatial level members in SOLAP operations (details and examples in [14,15]). In addition, by using geometric attributes of level members, topological relations between the levels, and levels and facts can be specified implicitly. Such topological relations are essential to correctly aggregate measures between levels with many-to-many (N:M) cardinality relations, for instance.

The Semantic Web (SW) has evolved, from prominently focusing on data publishing to also supporting complex queries, such as interactive analytical queries. Simultaneously, the data available on the SW has evolved from being simple, mostly alphanumerical data, to include complex data types, such as geospatial data. There are many examples of governmental and statistical Linked Open Data (LOD) sets with geographical attributes. However, such datasets are typically not modeled with multidimensional concepts. Thus, they cannot be queried with interactive analytical queries (OLAP). Although in recent years several platforms and tools for Business Intelligence (BI) and data warehouses have emerged [50], there is still a lack of common standards to model and publish (geo)semantic cubes on the SW [15].

More and more statistical datasets using the RDF Data Cube Vocabulary (QB) [48], the current W3C standard, are published on the SW. These datasets have observations and measures, which are well-suited for analytical queries. However, QB lacks the underlying structural metadata for multidimensional models and OLAP operations (Section 6). Well-defined structural metadata is required to translate OLAP queries into SPARQL 1.1 [14,46]. QB4ST [3] is a recent attempt to define extensions for spatio-temporal components to QB. However, it inherits the limitations of multidimensional modeling from QB.

To address the MD modeling challenges of the QB vocabulary, QB4OLAP [7] has been proposed, which reuses QB definitions by adding the required MD schema semantics. A significant number of data sets have already been published using the QB vocabulary. QB4OLAP descriptions of a QB data cube can be generated semi-automatically by adding the necessary MD semantics (e.g., the hierarchical structure of the dimensions) and the corresponding instances to populate the dimension levels. However, existing QB4OLAP annotation techniques [44] only cover non-spatial MD data cube concepts and its operations. Even though such statistical data sets have spatial information, not annotating the spatial MD concepts (e.g., spatial hierarchy levels such as administrative regions) hinders querying the data with interesting spatial OLAP operations. To emerge this need the QB4SOLAP vocabulary was proposed [13], which allows modeling the data cubes fully with both multidimensional and spatial concepts on the SW.

Fig. 1.

Future vision of SOLAP on the SW.

Problem motivation and definition Spatial OLAP (SOLAP) queries are currently not well supported by existing spatial RDF stores and endpoints. Instead, the user would have to a) download the (maybe very large) RDF data, b) map it to a relational schema (e.g., a snowflake schema), c) import it into a traditional spatial data warehouse, d) make all queries and analyses within the traditional spatial DW, and finally e) import and map any results and knowledge back into the original RDF store. This obviously is a slow, labor-intensive, and error-prone process, which furthermore completely locks out the vast majority of users without advanced programming skills.

Luckily, there already exist tools and vocabularies for (spatial) data warehouses on the SW: the QB4SOLAP vocabulary [13], for instance, allows publishing data with spatial multidimensional concepts on the SW and provides high-level SOLAP operators that can be translated into SPARQL [15]. Based on these, GeoSemOLAP [14] enables users to issue SOLAP queries on geo-semantic RDF data without detailed knowledge of SPARQL or RDF.

GeoSemOLAP, however, is restricted to RDF data sets that are already annotated with QB4SOLAP.

Thus, there is a great unmet need for an automated approach to enrich and annotate geo-semantic RDF data from existing endpoints with QB4SOLAP metadata. This is exactly what our proposed RDF2SOLAP enrichment module does (Fig. 1).

Since on-the-fly annotations would require the corresponding heavy spatial operations to be executed repeatedly for each new query, making response times too slow for interactive OLAP querying, we annotate the entire data set in a once-and-for-all fashion.

Contributions In summary, the main contributions of this paper are:

An illustration of the need for QB4SOLAP, i.e., the need to enable fully-fledged data warehouse concepts for geo-semantic RDF data. We further introduce running examples from real-world governmental open data on environment and farming with complex geometry types.

A detailed explanation and comparison of RDF data examples, which are depicted as graphs, and annotated both with QB4OLAP and QB4SOLAP vocabularies, then identifying the required spatial MD metadata and concepts (e.g., spatial hierarchies and topological relations) for SOLAP analysis based on the given comparison.

Hierarchical enrichment algorithms for (1) detecting topological relations at hierarchy steps with direct links between the level members; and (2) discovering topological relations at hierarchy steps (which do not have direct links between the level members).

Factual enrichment algorithms for fact-level relations between fact and level members.

An automated way of re-defining a fact schema after factual enrichment, and association of spatial aggregate functions with spatial measures.

General implementation of our approach for both hierarchical enrichment and factual enrichment processes.

Evaluation of our approach in terms of accuracy and coverage in comparison to two standard environments (RDBMS and GIS tool).

Paper organization The remainder of this paper is organized as follows. Section 2 defines the preliminary concepts used throughout the paper with a running use case example. Section 3 presents the system architecture for the MD enrichment process. Section 4 defines the RDF2SOLAP enrichment algorithms with necessary helper functions and formalization of (spatial) RDF data. The Appendix presents the implementation details along with interesting examples and discusses the challenges and implemented solutions. Section 5 presents the qualitative and performance evaluation with comparison baselines. Finally, Section 6 discusses related work and Section 7 concludes the paper with an outlook to future work.

2. Preliminaries

In this section, we explain the preliminary concepts of spatial data warehouses and SOLAP (Section 2.1) and how to deploy them on the Semantic Web (Section 2.2) using the QB4SOLAP vocabulary.

2.1. Spatial data warehouses and SOLAP

Data cubes and spatially extended cube concepts Data warehouses (DW) are based on a multidimensional model that models data in an n-dimensional space – often referred to as a data cube. A cube schema defines the structure of a cube with MD concepts. The cells of the cube represent (observation) facts with a set of attributes called measures. Facts are linked to dimensions, which are the axes of an MD space and provide perspectives to analyze the data. Dimensions are organized into hierarchies, which allow users to aggregate measures at different granularities along the levels of a hierarchy. Hierarchies are composed of levels, which have a set of attributes describing the characteristics of the level members. Each level member is defined by its attributes and attribute values.

Cube members are MD concepts that are defined at the instance level and composed of level members, attributes of level members, partial order on level members, and fact members. A hierarchy step between levels (a child level and a parent level) defines a set of roll-up relations, where each relation relates a child level member to a parent level member. These roll-up relations define a partial order between level members with a cardinality relation. The cardinality (1:1, 1:N, N:1, N:M) describes the number of members in one level that can be related to a member in the other level for both child and parent levels.

Spatial data warehouses (SDW) extend a DW by storing geometries such as point, line, and polygon in the values of spatial measures and values of level attributes for spatial dimensions. The spatially extended MD schema of an SDW has spatial dimensions, spatial hierarchies, spatial levels [29], spatial hierarchy steps, and topological relations (in addition to cardinality relations) between spatial levels for each spatial hierarchy step [13]. Topological relations are Boolean spatial predicates that specify how two spatial objects are related to each other, e.g., within, intersects, touches, crosses and etc. [6]. Similar to conventional DWs, facts of an SDW can be associated with numeric measures, which are using aggregation functions such as SUM, AVG, etc. A fully extended spatial MD schema of an SDW should also define spatial measures, which have geometries and spatial aggregate functions. Spatial aggregate functions aggregate two or more spatial objects and return a new spatial object. Union, Intersection, ConvexHull, and Minimum-BoundingRectangle (MBR) are example of spatial aggregate functions. For a detailed explanation of SDW concepts we refer the reader to [42].

Fig. 2.

GeoFarmHerdState – parish, farm, and drainage area instances.

Fig. 3.

GeoFarmHerdState – conceptual MD schema of livestock holdings data (spatial concepts).

OLAP and spatial OLAP operations DWs are commonly used to store large volumes of data for decision support with On-Line Analytical Processing (OLAP) operations. Spatial OLAP (SOLAP) integrates the features of OLAP tools and geographical information systems (GIS) [38]. SOLAP enables advanced analytical processing by taking the spatial information in the cube into account.

For example, a spatial data cube of livestock holdings in farms (referred to as GeoFarmHerdState in the rest of this paper) defines the farm location as a spatial measure, which is linked to the observation facts. In order to derive perspectives and relations on the state of the farms’ livestock holdings (herds), spatial levels are defined: parishes and drainage areas. A sample set of the corresponding spatial data cube members are given in Fig. 2. The spatial MD concepts of the data cube are defined in the conceptual schema in Fig. 3, which depicts a simplified version of the GeoFarmHerdState spatial data cube without its non-spatial dimensions (see [12] for further details the GeoFarmHerdState cube). The cube has two spatial dimensions: FarmDim and ParishDim. The latter has a spatial hierarchy (Geography) with two spatial levels: Parish and DrainageArea. FarmDim on the other hand does not have a spatial hierarchy, despite its spatial (base) level: Farm.

The GeoFarmHerdState cube has spatial fact members for farms within a time frame and different kinds of measures, i.e., numeric measures: NumberofAnimals in the farm and NitrogenReduction potential of the farm land/soil, spatial measures: FarmLocation (Fig. 3).1

Non-additive measures are also numeric measures, which are given in percentages or classified in numbers, therefore they cannot be meaningfully summarized by all aggregate functions i.e., SUM. However, depending on the semantics, other aggregate functions can be associated with them, e.g., AVG NitrogenReduction potential, MAX NitrateClass.

To evaluate SOLAP operations, spatial levels such as Parish and DrainageArea are used to aggregate measures at different levels of detail. Due to the polygon geometry of the spatial level members, there are two different roll-up relations for the hierarchy step between the Parish and DrainageArea levels, where a parish can be completely contained within a drainage area or a parish and a drainage area can intersect.

For example, parish “Oue” is within drainage area “Mariager Inderfjord”. Thus, all the farms that are within “Oue” are also within “Mariager Inderfjord”. Whereas, parish “Astrup” intersects with drainage areas “Mariager Inderfjord” and “Langerak”. Therefore, some farms that are within “Astrup” are within “Mariager Inderfjord”, while the rest of the farms are within “Langerak”. Figure 2 displays a sample set of Parish and DrainageArea level members.

The possible roll-up relations for the example above are depicted in Fig. 4 with black and red arrows representing the topological relations within and intersects. Blue arrows show the topological relation contains, which are drill-down (inverse operation of roll-up) relations from DrainageArea level to Farm level.

Topological relations between levels and facts can be implicitly specified through the geometry attributes of their instances (level members and fact members). The relations between spatial levels enable processing spatial roll-up and drill-down through range queries with spatial predicates [8]. In terms of cardinality, there is an N:M relationship between level members since a parish may intersect with more than one drainage area and vice versa. This induces the problem of computing measures incorrectly when a roll-up operation goes through an N:M relationship, which actually is the case between the Parish level and the DrainageArea level. For example, we would like to aggregate the measure NumberOfAnimals, from Parish level to the DrainageArea level with a roll-up query. In such a roll-up query, we might falsely aggregate the number of animals in farms that are contained within the parish, but not contained within the drainage area, since the parish intersects with another drainage area. In order to refine such an analysis, SOLAP operations are required, where a (spatial) drill-down should be applied to the lowest granularity – from Parish level members to GeoFarmHerdState fact members, and then a spatial roll-up (with within predicate) can be applied from fact members (Farm instances) to DrainageArea level members. This would prevent falsely aggregating the number of animals from the farms that are (spatially) disjoint to the corresponding drainage area.

Fig. 4.

Hierarchy example for SOLAP.

Fig. 5.

Hierarchy steps in QB4OLAP before multidimensional enrichment.

2.2. QB4SOLAP: Spatial RDF data cube vocabulary for SOLAP operations

There is an increasing amount of Linked Open Data (LOD) on the Semantic Web containing spatial information and numerical (statistical) data. This led to new opportunities for OLAP over spatial data using semantic web technologies and standards. Datasets on the SW use a standardized format: RDF (Resource Description Framework).2

²
https://www.w3.org/TR/rdf11-primer/

In order to enable SOLAP operations on the Semantic Web, a comprehensive vocabulary is needed, i.e., annotation of the spatial hierarchy steps with topological relations. QB4SOLAP [15] is a vocabulary that allows the definition of cube schemas and cube instances in RDF. The QB4SOLAP vocabulary is an extension of QB4OLAP [7] capturing the semantics of spatial MD concepts (i.e., spatial hierarchy steps) that are essential for SOLAP operations. The QB4SOLAP vocabulary V1.3 is available on our project website3

https://extbi.cs.aau.dk/QB4SOLAP

as well as via a persistent URL.4

⁴

https://w3id.org/qb4solap#

A comprehensive foundation of spatial data warehouses on the Semantic Web can be found in [15], which includes detailed definitions with semantics of spatial MD concepts both at the schema level and instance level using QB4SOLAP.

In the following, we depict an example of a hierarchy step from gfs:Parish child level to gfs:drainageArea parent level (Fig. 5). In the figure, we prefix the schema elements (attributes, levels, etc.) of the (GeoFarmHerdState) cube with gfs: and instance data from the cube with gfsi:. The left-center part of Fig. 5 shows the hierarchy structure _:hs, between gfs:parish and gfs:drainageArea levels at the schema level with the QB4OLAP vocabulary. QB4OLAP objects, classes, and properties are prefixed with qb4o:. The levels (gfs:parish and gfs:drainageArea) are linked to the instances of level members (e.g., gfsi:parish_8648, gfsi:water_3710 and etc.) by qb4o:memberOf property. The polygon geometry attributes are highlighted in blue boxes, on the top and the bottom of the figure. The coordinates recorded in the geometry attributes can be used to derive the topological relation between the level members by applying spatial boolean predicates (e.g., instersects?, within?) on the polygon geometries of the parish and drainage area level members.

However, QB4OLAP does not support annotating the topological relations that might exist between the level members at a hierarchy step. QB4OLAP uses only skos:broader property from SKOS (Simple Knowledge Organization System) [30] semantic relations for capturing the roll-up relations at hierarchy steps. The roll-up relations with skos:broader property are highlighted in red boxes in Fig. 5. The skos:broader property does not describe the nature of the roll-up relation with topological relations for spatial hierarchies. Therefore, QB4OLAP cannot capture the topological relations in a hierarchy step from Parish level to DrainageArea level or between these levels’ members.

Fig. 6.

Spatial hierarchy steps in QB4SOLAP after multidimensional enrichment.

On the other hand, QB4SOLAP can define topological relations both at the schema level and the instance level. In Fig. 6, we prefix QB4SOLAP objects, classes, and properties with qb4so: and highlight them in green lines. The left-center part of the figure shows the spatial hierarchy structure :_shs, which has a QB4SOLAP property qb4so:pcTopoRel with two QB4SOLAP class instances qb4so:Within and qb4so:Intersects. This means that when we compare the geometry attributes of parish level members and drainage area level members, we discover two different topological relations (within and intersects) for all the (spatial) hierarchy steps between the parish and drainage area levels. And these relations are annotated at the schema level on the left-center part of Fig. 6.

Similarly, gfs:parish and gfs:drainageArea levels are linked to the instances of level members (e.g., gfsi:parish_8648) by qb4o:memberOf property. The explicit topological relations between each level member along a spatial hierarchy step are depicted in the figure with qb4so:intersects or qb4so:within predicates, which are highlighted in green boxes (e.g., gfsi:parish_8648intersects with gfsi:water_159 and gfsi:water_3170 etc.).

In conclusion, QB4SOLAP enables SOLAP operations by defining the semantics of spatial MD concepts both at the schema level and instance level. These semantics are essential for SOLAP operations, and they are defined as extensions to the QB4OLAP vocabulary.

3. System architecture

The importance of SOLAP to get accurate results in operations over spatial data warehouses is explained in Section 2.1. However, the RDF data cubes (with spatial attributes) on the Semantic Web are not always annotated with vocabularies that allow users to formulate SOLAP queries. In this section we present an overview of the MD enrichment flow from RDF QB to QB4OLAP data cubes and QB4OLAP to QB4SOLAP data cubes. Thus, users can query the RDF data cubes with SOLAP queries.

Fig. 7.

Multidimensional enrichment process.

A multidimensional enrichment process flow is illustrated in Fig. 7 with three main architectural layers: Interface, Enrichment Modules, and SPARQL Endpoints. The architectural layers in the figure are denoted in horizontal rectangles. The first layer facilitates user interaction with the enrichment modules (i.e., QB2OLAPem) and third party tools (i.e., GeoSemOLAP). In each layer, processes are given in right angle boxes, modules and tools are given in rounded corner boxes. Third party tools and modules are annotated in dashed lines. Arrows in the figure represents the interaction between processes and the modules.

Our main contribution in this paper is the RDF2SOLAP enrichment module, which is the core of the second layer. The RDF2SOLAP enrichment module operates on QB4OLAP triples that either already exist in the original data or have been generated by the QB2OLAPem enrichment module [44]. QB2OLAPem allows users to enrich an RDF QB dataset with QB4OLAP concepts and returns a graph of QB4OLAP triples.

The internal process flow of the RDF2SOLAP enrichment module consists of three phases: hierarchical enrichment, factual enrichment, and triple generation. The hierarchical and factual enrichment phases iteratively perform the enrichment algorithms explained in Section 4. Hierarchical enrichment phase and factual enrichment phase can run independently from each other in parallel. Factual enrichment phase additionally can suggest an enriched fact schema definition, which depends on the spatial relations found at the instance level enrichment for factual and hiearchical enrichment phases. Both of these enrichment phases allow interaction with external SPARQL endpoints to enhance the enrichment process via potential spatial and multidimensional concepts that could be retrieved externally. The third phase is the triple generation, which creates QB4SOLAP triples that can be used in third party tools such as GeoSemOLAP. GeoSemOLAP allows users without knowledge of RDF and SPARQL to query with SOLAP operations by interactively formulating the queries using a GUI with interactive maps [14].

The third layer (SPARQL endpoints) allows interaction between user and SPARQL endpoint for retrieving QB or QB4OLAP graphs as well as interaction between system and SPARQL endpoints, where the RDF2SOLAP enrichment module queries external triple stores for hierarchical enrichment and factual enrichment.

RDF2SOLAP is implemented in Javascript on the Node.js platform using the N3.js library for parsing the RDF triples in Javascript and the Turfjs library for spatial analysis.5

⁵

N3.js:https://github.com/rdfjs/N3.jsTurfjs:http://turfjs.org/.

4. RDF2SOLAP enrichment algorithms

This section presents the core algorithms of our RDF2SOLAP enrichment module. Our MD enrichment approach builds upon QB4OLAP triples that either already exist in the original data or have been generated by the QB2OLAPem enrichment module [44] as depicted in Fig. 7. QB4OLAP defines only the non-spatial multidimensional semantics of RDF data, whereas QB4SOLAP enriches the MD semantics of RDF data with spatial concepts (formalizations and further details can be found in [15]). Nevertheless, in the following we briefly introduce basic notations.

The basic construct of RDF is a triple $t = (s, p, o)$ consisting of three components; s is the subject, p is the predicate, and o is the object. RDF triples are defined over $T = (I \cup B) \times I \times (I \cup B \cup L)$ , where $I$ is the set of IRIs (Internationalized Resource Identifiers), $B$ is the set of blank nodes, and $L$ is the set of literals. An object value can be a literal (i.e., string, spatial literal,6

⁶
Spatial literals are represented as $L_{s}$ .

integer etc.). Subjects and objects can be represented by a blank node for anonymous resources. Predicates are always represented by IRIs. A set of RDF triples is referred to as an RDF graph

G

. We use superscript notation to represent the type of a graph: schema graph

G^{S}

and instance graph

G^{I}

. An instance graph has entities from a use-case dataset as a set of RDF triples. The schema graph describes the structure (schema) of the dataset recorded in the instance graph. We use subscript notation to represent the MD concepts in RDF terms as a graph. For example,

G_{A (l m)}^{I}

is the RDF instance graph for attributes of level members – in the use case example this graph corresponds to the set of triples in Listing 2, Lines 3–6 or Lines 9–13 and Lines 17–22.

G_{HS (h)}^{S}

is the RDF schema graph for hierarchy steps – in the use case example this graph corresponds to the set of triples in Listing 1.

We define function $id (x) : G \to I$ , which given an MD element x returns its identifier $I$ from graph $G$ . Similarly, we use superscript notation to indicate the type of the identifier from the schema graph ( $G^{S}$ ) and instance graph ( $G^{I}$ ), e.g., ${id}^{S} (a)$ for a schema identifier of a level (gfs:parish in Listing 2, Line 2 or in Listing 1, Line 2) and ${id}^{I} (l m)$ for an instance identifier of a level member (gfsi:parish_8648 in Listing 2, Line 1 or Line 8).

The MD enrichment process in RDF2SOLAP runs in two phases (hierarchical enrichment phase and factual enrichment phase), which are explained in the following.

4.1. Hierarchical enrichment phase

The hierarchical enrichment phase is built around spatial levels and their level members forming the spatial hierarchy of a dimension. Thus, by identifying the spatial relations between spatial levels and their level members, we can find the spatial hierarchy steps and the possible topological relations for these hierarchy steps.

Each spatial hierarchy corresponds to a path of roll-up relationships between the child level and parent level: each of these roll-up relationships corresponds to a spatial hierarchy step (Section 2.1). An example of a (spatial) hierarchy with QB4SOLAP is given in Listing 1. Line 4 extends the QB4OLAP schema definitions by enriching the hierarchy step with the possibility to annotate the spatial hierarchy steps with topological relations (see Section 2 for details and Section 2.2 for examples).

Listing 1.

Spatial hierarchy structure in QB4SOLAP

Listing 2 shows the GeoFarmHerdState spatial level members from Parish and Drainage Area levels. Lines 1–7 (Listing 2) represent the QB4OLAP annotation of a child level member from Parish level before multidimensional enrichment (with skos:broader), which is depicted in Fig. 5. Lines 8–14 represent the QB4SOLAP annotation of the same Parish level member after the multidimensional enrichment with topological relations (depicted in Fig. 6). Lines 15–22 represent the annotation of a parent level member from the Drainage area level, which remains the same before and after multidimensional enrichment since the hierarchy steps are defined with bottom-up relationships from child level to parent level and the roll-up relations and thus also the topological relations are annotated at the child level members of the hierarchy step.

Listing 2.

GeoFarmHerdState level members, attributes, and spatial roll-up relations

We exploit QB4OLAP semantics, such as non-spatial hierarchy steps and levels as a starting point to find the spatial hierarchy steps. We distinguish two cases:

Case 1: Finding explicit spatial hierarchy steps for QB4OLAP levels, with skos:broader roll-up relations between their child-parent level members by detecting spatial hierarchy steps in Section 4.1.2. For this case we assume that level members have direct skos:broader relations as depicted in Fig. 5 and Listing 2, Line 7 with skos:broader property.

Case 2: Finding implicit spatial hierarchy steps from QB4OLAP levels without direct roll-up relations through the skos:broader property. In this case, we assume that the level members are only defined by the qb4o:memberOf property as shown in Listing 2, (Line 2) but do not have the skos:broader roll-up relation as given in Line 7. In this case, it is still possible to discover spatial hierarchy steps by finding spatial (topological) relations between level members through their attributes as explained in Section 4.1.3.

4.1.1. Spatial helper functions

To address the cases explained above, we need two spatial helper functions; for retrieving spatial attribute values (Algorithm 1, getSpatialValues), and for relating spatial attributes (Algorithm 2, relateSpatialValues).

Algorithm 1 (getSpatialValues) The first helper function gets an input graph of attributes of level members $G_{A (l m)}^{I}$ and returns a set of spatial attribute values $V_{s (a)}$ . For example, the function could receive Lines 3–6 from Listing 2 as input. In the algorithm, Lines 3 and 4 check the values $v_{a_{i}}$ of each attribute ${id}^{S} (a_{i})$ (e.g., gfs:parishName, gfs:ParishArea, etc.) If the value is a type of geo:SpatialLiteral (e.g., the POLYGON geometry value linked to the gfs:parishPolygon attribute), then the value is incrementally added to the output set $V_{s (a)}$ 7

⁷
Note that a level member might have the polygon geometry type for the parish borders and the point geometry type for the parish center, therefore a set of spatial values is required.

in Line 5.

Algorithm 1

$getSpatialValues (G_{A (l m)}^{I})$ : $V_{s (a)}$

Algorithm 2

$relateSpatialValues (v_{a_{c}}, v_{a_{p}})$ : ${topoRel}_{i}$

Algorithm 2 : (relateSpatialValues) The next helper function is designed based on Table 1, w.r.t. the geometry values of the child-parent level members and based on the structure of a hierarchy step. We prepared Table 1 with topological relations based on DE-9IM.8

⁸

DE-9IM (Dimensionally Extended Nine-Intersection Model) is a topological model that describes spatial relations of two geometries in two dimensions [6].

We consider only the three simple geometry types, point, line, and polygon as the spatial attribute values of child-parent level members in roll-up relations, excluding complex geometry types, such as multi-polygon, multi-point, etc. The possible topological relations that can occur in a spatial hierarchy step with a roll-up relation from child level to parent level are marked with check sign (✓) in the table. Topological relations, such as contains and covers, are not hierarchically applicable since a spatial child level member cannot contain or cover a spatial parent level member. For these relations, we mark the complete rows with minus sign (−) in the table, since they are not hierarchically applicable. Similarly, we mark the complete columns of line-point, polygon-point, and polygon-line roll-up relations with the minus sign (−) since these are also not hierarchically applicable. This is because we assume that in the instance data, a parent level member should always have a spatial attribute of a geometry type of the same or higher dimensionality of its child level member (a point is 0-dimensional, a line is 1-dimensional and a polygon is 2-dimensional).

Table 1

Topological relations for hierarchy steps (✓: hierarchically and topologically applicable, ×: topologically not applicable, −: hierarchically not applicable)

Topological relations		Roll-up relations

	Child level	Point (pt.)			Line (ln.)			Polygon (po.)

	Parent level	pt.	ln.	po.	pt.	ln.	po.	pt.	ln.	po.
within		×	✓	✓	−	✓	✓	−	−	✓
contains		−	−	−	−	−	−	−	−	−
intersects		✓	✓	✓	−	✓	✓	−	−	✓
touches		×	×	×	−	✓	✓	−	−	✓
overlaps		×	×	×	−	✓	✓	−	−	✓
crosses		×	×	×	−	✓	✓	−	−	×
coveredBy		×	×	×	−	×	✓	−	−	✓
covers		−	−	−	−	−	−	−	−	−
equals		✓	×	×	−	✓	×	−	−	✓

For example, a child level member with a spatial attribute of line geometry can only have parent level member(s) with spatial attributes of line or polygon geometries but not point geometry. We mark the topologically not applicable relations with cross sign (×) according to the DE-9IM model (e.g, a line cannot overlap a polygon).

Fig. 8.

Simplifying topological relations.

In Fig. 8, we depict the hierarchically and topologically applicable topological relations from Table 1. We simplified them by generalizing the possible relations, e.g., if a line touches or crosses another line at one point, they are both classified as intersects in Fig. 8(d). The most general relations are underlined in Fig. 8 for each pair of geometry types (Fig. 8(a), (b), (c), (d), (e), and (f)).

In Algorithm 2relateSpatialValues, we only consider these general topological relations that have a higher probability to satisfy the corresponding spatial predicates. For example, the topological relation intersects has the highest probability to satisfy from the DE-9IM matrix [6]. We generalize similar spatial predicates to ones that have higher probability to occur in a 2-dimensional space. For example, relations, such as a line overlaps (along the border of) a polygon, can be generalized to the relation – a line crosses a polygon at a minimum two points, which can later be generalized to the relation – a line intersects a polygon at a (minimum) single point as in Fig. 8(e). Similarly, a line touches a polygon at a single point can be generalized to the relation – a line intersects a polygon at a (minimum) single point.

The topological relation coveredBy requires an area of a geometry, therefore it is applicable only in line-polygon and polygon-polygon relations (Fig. 8(e) and 8(f)). For reasons of simplicity, we choose to generalize them as the within topological relation. In the algorithm, we also prioritize to check the topological relations based on the compared geometry types. If the spatial attribute values to relate are point and polygon geometry types, as in Fig. 8(c), it is more likely that a point is within a polygon than a point intersects a polygon in the instance data.

Therefore, we initially check for a more probable relation in the algorithm. For example, for the point-polygon relations case in Algorithm 2, Line 10: initially, the within spatial predicate is checked in the if statement (Line 11), then the intersects spatial predicate is checked in the else if statement (Line 13). After checking all the possible combinations of spatial attribute values in a switch case, a topological relation is returned from the algorithm (Line 30).

Now that we have introduced spatial helper functions, we present the main algorithms for finding the spatial hierarchy steps in the following.

4.1.2. Detecting spatial hierarchy steps

Algorithm 3 (detectSpatialHS) corresponds to case 1 (see the beginning of Section 4.1) and finds the explicit spatial hierarchy steps for QB4OLAP levels with skos:broader roll-up relations between child-parent level members. Intuitively, Algorithm 3 works as follows. Given instance graphs of attributes of level members $G_{A (l m)}^{I}$ and roll-up relations of the hierarchy steps $G_{RU (h s)}^{I}$ between level members (using skos:broader), the key principle is to first retrieve pairs of child-parent level members based on the given input relationships $G_{RU (h s)}^{I}$ . Then, spatial values are extracted (getSpatialValues) and finally the spatial relationship is verified (relateSpatialValues). The output $G_{RU (s h s)}^{I}$ is then a graph of detected and verified hierarchy steps.

As an example, let us consider Listing 2: given Lines 1–6 ( $G_{A}^{I} (l m)$ ), Line 7 ( $G_{R}^{I} U (h s)$ ), and Lines 15–22 ( $G_{A}^{I} (l m)$ ) as input, Algorithm 3 produces Line 14 ( $G_{R}^{I} U (s h s)$ ) as output.

Formally, Algorithm 3 works as follows:

Algorithm 3

$detectSpatialHS (G_{RU (h s)}^{I}, G_{A (l m)}^{I})$ : $G_{RU (s h s)}^{I}$

Algorithm 3 (detectspatialHS) The input variables for Algorithm 3 are the instance graphs of attributes of level members $G_{A (l m)}^{I}$ and roll-up relations of the hierarchy steps $G_{RU (h s)}^{I}$ between the level members. The RDF graph formulation of the attributes of the level members $A (l m)$ is: $G_{A (l m)}^{I} = ⋃_{i = 1}^{p} {({id}^{I} (l m) {id}^{S} (a_{i}) v_{a_{i}}) ∣ l m ⇝ v_{a_{i}}}$ . Here, we denote by $l m ⇝ v_{a_{i}}$ that a level member $l m$ has value $v_{a_{i}}$ for attribute $a_{i}$ (e.g., Listing 2, Lines 3–6, Lines 9–13, and Lines 17–22). The RDF graph formulation of the roll-up relations $RU (h s)$ is: $G_{RU (h s)}^{I} = ⋃_{i = 1}^{k} {({id}^{I} (l m_{c}) skos:broader {id}^{I} (l m_{p})) ∣ l m_{c_{i}} ⊑ l m_{p_{i}}}$ . Here, we denote by $l m_{c_{i}} ⊑ l m_{p_{i}}$ the partial order between level members, where a child level member $l m_{c_{i}}$ rolls up to a parent level member $l m_{p_{i}}$ 9

⁹

We use subscript c and p to distinguish values for child and parent level members.

(e.g., Listing 2, Line 7).

The output of Algorithm 3 is the instance graph of roll-up relations for the detected spatial hierarchy steps $G_{RU (s h s)}^{I}$ (e.g., Listing 2, Line 14). In Line 2, initially the output graph is initialized as an empty set. Next, in Line 3 we create two temporary graphs: $G_{A (l m_{c})}^{I}$ and $G_{A (l m_{p})}^{I}$ as empty sets,10

¹⁰

Remark: a set of RDF triples is referred to as an RDF graph.

to keep triple patterns separately in two graphs for attributes of child and parent level members. We also create two temporary sets:

V_{s (a_{c})}

and

V_{s (a_{p})}

for keeping the spatial attribute values from the child and parent level members, and initialize them as empty sets in Line 3. A set of spatial attribute values is defined over spatial literals

L_{s}

V_{s (a)} = {v_{a_{1}}, \dots, v_{a_{i}}, \dots, v_{a_{n}} ∣ 1 ⩽ i ⩽ n \land v_{a_{i}} \in L_{s}}

In the foreach loop in Line 4, we go through the elements of the input graphs $G_{A (l m)}^{I}$ and $G_{RU (h s)}^{I}$ that are fulfilling a specific criteria, which is having an explicitskos:broader relation between child and parent level members.

In Line 5, while iterating through the foreach loop, we assign the set of triples of child level members and their attributes to the temporary graph $G_{A (l m_{c})}^{I}$ . This temporary graph is given in Line 6 as an input to the helper function getSpatialValues (Algorithm 1), which finds the spatial attribute values from the given graph, and returns a set of spatial attribute values (i.e., $V_{s (a_{c})}$ ) that are found in the input graph. The output of the helper function ( $V_{s (a_{c})}$ ) keeps the spatial attribute values of the child level member ${id}^{I} (l m_{c})$ .

Next in Line 7, if $V_{s (a_{c})}$ is not empty and has some spatial values of ${id}^{I} (l m_{c})$ , we populate the next temporary graph $G_{A (l m_{p})}^{I}$ with its parent level ${id}^{I} (l m_{p})$ and attributes of the parent level in Line 8.

Similar to Line 6, Line 9 calls the helper function getSpatialValues with the input graph $G_{A (l m_{p})}^{I}$ and the output of the function is assigned to the temporary set $V_{s (a_{p})}$ . If this set is also not empty (Line 10), we go through the pairs of values ( $v_{a_{c}}, v_{a_{p}}$ ) of the child-parent level members (Line 11), which are selected from the temporary graphs $G_{A (l m_{c})}^{I}$ and $G_{A (l m_{p})}^{I}$ .

In this loop, we call the next helper function relateSpatialValues (Algorithm 2), where the input is the spatial value pairs. The output value of this function is the topological relation between the corresponding child and parent level members, and it is assigned to the initially created temporary variable ${topoRel}_{i}$ (Line 12). If this value is not null (checked in Line 13), relateSpatialValues function returns a topological relation (Line 12) that is satisfied as shown with a check-mark (✓) from Table 1.

Finally, the output graph for spatial hierarchy steps $G_{RU (s h s)}^{I}$ is incrementally generated by adding the triple pattern with the topological relation (Line 14) and the output graph for the detected spatial hierarchy steps is returned (Line 15).

Algorithm 4:

$discoverSpatialHS (G_{D}^{S}, G_{H (d)}^{S}, G_{L (h)}^{S}, G_{LM (l)}^{I}, G_{A (l m)}^{I})$ : $G_{RU (s h s)}^{I}$ .

4.1.3. Discovering spatial hierarchy steps

Algorithm 4 (discoverSpatialHS) corresponds to case 2 (see the beginning of Section 4.1) and finds the implicit spatial hierarchy steps for QB4OLAP levels that do not have direct (skos:broader) roll-up relations. In this algorithm, we have to handle the situation where there are no explicit hierarchy steps between level members. Therefore, we benefit from schema graphs capturing dimensions, hierarchies, and levels by iterating through the RDF triples and compare the spatial attribute values of the level members to find the $G_{RU (s h s)}^{I}$ topological relations within the same dimension.

Intuitively, Algorithm 4 works very much like Algorithm 3, the main difference being that in the absence of a direct link between the members, we need to find it first. Hence, we find pairs of level members exploiting information about dimensions, hierarchies in dimensions, and levels in hierarchies, which is provided by QB4OLAP. The detected pairs are then treated in a similar way as the child-parent level member pairs in Algorithm 3.

As an example, let us consider Listing 2: given Lines 1–6 ( $G_{A}^{I} (l m)$ ) and Lines 15–22 ( $G_{A}^{I} (l m)$ ) as input, Algorithm 4 produces Line 14 ( $G_{R}^{I} U (s h s)$ ) as output.

Formally, Algorithm 4 works as follows:

Algorithm 4 (discoverSpatialHS) The input variables for Algorithm 4 are the schema graphs of dimensions $G_{D}^{S}$ , hierarchies of the dimensions $G_{H (d)}^{S}$ , levels of the hierarchies $G_{L (h)}^{S}$ , the instance graphs of level members of levels $G_{LM (l)}^{I}$ , and attributes of level members $G_{A (l m)}^{I}$ . Each dimension $d \in D$ has a set of hierarchies $H (d)$ , which is shown in the RDF graph formulation for a dimension $d \in D$ as: $G_{d}^{S} = ⋃_{h \in H (d)} {({id}^{S} (d) qb4o:hasHierarchy {id}^{S} (h))}$ . Each hierarchy $h \in H (d)$ belongs to a dimension d and has a set of levels $L (h)$ , which is shown in the RDF graph formulation for a hierarchy $h \in H (d)$ as: $G_{h}^{S} = {({id}^{S} (h) qb4o:inDimension {id}^{S} (d))} \cup ⋃_{l \in L (h)} {({id}^{S} (h) qb4o:hasLevel {id}^{S} (l))}$ . Each level l has a set of level members $LM (l) = {l m_{1}, \dots, l m_{y}}$ , which is shown in the RDF graph formulation for a level member $l m \in LM (l)$ as: $\begin{array}{l} G_{l m}^{I} = {({id}^{I} (l m) qb4o:memberOf {id}^{S} (l))} . \end{array}$ Each level member $l m$ has a set of attributes $A (l m)$ . The RDF graph formulation of attributes of level members $G_{A (l m)}^{I}$ is already given in Section 4.1.2. In Listing 2, examples of a triple pattern for level members and attributes of level members are given in Lines 1–6, Lines 8–13 and Lines 15–22, without explicit roll-up relations (Line 7).

The output of Algorithm 4 is the instance graph of roll-up relations for the discovered spatial hierarchy steps $G_{RU (s h s)}^{I}$ (e.g., Listing 2, Line 14). In Line 2, the output graph is initialized as an empty set. And a temporary variable ( ${topoRel}_{i}$ ) for keeping the discovered topological relations is initialized as null. In Line 4, we create two temporary graphs: $G_{A (l m_{n})}^{I}$ and $G_{A (l m_{k})}^{I}$ as empty sets similar to Algorithm 3. We also create two temporary sets: $V_{s (a_{n})}$ and $V_{s (a_{k})}$ for storing spatial attribute values and initialize them as empty sets in Line 3.

To discover the spatial hierarchy steps, we need to get the attributes of all the level members from the instance graph ( $G_{A (l m)}^{I}$ ) and compare their spatial attribute values in pairs, where the pairs of level member attributes should be coming from two different levels in the same dimension hierarchy. Therefore, before getting the attributes of the level members, we need to classify the level members as they are grouped in different levels of a dimension hierarchy.

To achieve that, we use the schema definitions readily available in QB4OLAP, by looping through in Algorithm 4, in nested loops of dimensions in Line 5, hierarchies in the dimension (Line 6), levels in the hierarchy (Line 7). This helps us to determine the levels in a dimension hierarchy, where we can get level pairs from the same hierarchy (Line 8).

Now, while looping through the level pairs, we can identify the level members via the qb4o:memberOf property (Line 9). We get a pair of level members, where each level member should come from a different level, then we iterate through that pair of level members (Line 10).

Then, we get the triple patterns for the attributes of the level members from the each of the level member in the pair, and iterate through those pairs of the triple patterns (Line 11). While iterating through the triple patterns, we insert them to the temporary graphs $G_{A (l m_{n})}^{I}$ and $G_{A (l m_{k})}^{I}$ (Line 12), which are created earlier as empty sets in Line 4. So, we can filter the spatial values from the triple patterns kept in the temporary graphs by calling the helper function getSpatialValues (Algorithm 1), with those input graphs $G_{A (l m_{n})}^{I}$ and $G_{A (l m_{k})}^{I}$ (Line 13).

Next, we call the helper function getSpatialValues (Algorithm 1) twice, with the input graphs $G_{A (l m_{n})}^{I}$ and $G_{A (l m_{k})}^{I}$ . The outputs of the each (helper) function call are assigned to the temporary sets $V_{s (a_{n})}$ and $V_{s (a_{k})}$ correspondingly (Line 13). If these sets are not empty (Line 14), it means that getSpatialValues identified spatial values in the triple patterns of the input graphs.

Then, we iterate through the spatial value pairs retrieved from the each of the sets (Line 15). In this loop, we call the next helper function relateSpatialValues (Algorithm 2), where the input is the spatial value pairs. The output value of this function is the topological relation between the corresponding level members, and it is assigned to the initially created temporary variable ${topoRel}_{i}$ (Line 16).

Finally, if this ${topoRel}_{i}$ value is not null (Line 17), the output graph for the spatial hierarchy steps $G_{RU (s h s)}^{I}$ is incrementally generated by adding the triple pattern with the topological relation (Line 18) and the output graph for the discovered spatial hierarchy steps is returned in Line 19.

4.2. Factual enrichment phase

The factual enrichment phase is built around the observation facts and their spatial attributes a.k.a spatial measures and fact-dimension relations (Section 2.1).

Listing 3.

GeoFarmHerdState fact schema definition in QB4SOLAP

In QB4OLAP facts are linked to the dimensions at the lowest granularity level, which is the base level of the dimensions. For example, the GeoFarmHerdState cube has two spatial base levels linked to the cube: Parish level and Farm level. The GeoFarmHerdState cube also has a spatial measure listed in the cube: FarmLocation (Fig. 3). In QB4OLAP, a fact schema defines the structure of a cube with the qb:DataStructureDefinition property (Listing 3, Line 1). Base levels (Lines 2 and 4) and measures (Line 6) are given as qb:components of the fact (Listing 3). The cardinality relationship between the base level and the fact can also be represented with qb4o:cardinality in QB4OLAP as given in Lines 2 and 4 in Listing 3.

On the other hand, with QB4SOLAP we can also represent fact-level topological relations that are similar to the topological relations between the child-parent levels at the hierarchy steps. Fact-level topological relations are given in spatial fact schema with blue in Lines 3 and 5 (Listing 3). QB4SOLAP also extends the (cube) schema with spatial aggregate functions, which are defined over spatial measures as highlighted in blue (Listing 3, Line 7).

Listing 4.

GeoFarmHerdState fact member with base levels and measures

An example of an observation fact (fact member) at the instance level is given in Listing 4. A fact member is a qb:Observation (Line 1), which is related to the base levels (Line 2) with respect to the data structure definition (DSD) of the fact schema, and has a set of measures (Lines 3, 4) where some measures (Line 4) might have spatial values (Listing 4). To define a QB4OLAP fact schema, first, we need to enrich the fact members by annotating with topological relations as highlighted with blue in Line 5. We can derive topological relations between fact members and the (base) level members by comparing the spatial measures of the fact members and spatial attributes of the (base) level members with Boolean spatial predicates. The links between fact members and base level members are already given explicitly in Line 2 (Listing 4). However, these links are simple references between the fact and base level members, which do not describe the nature of the topological relation. By applying Boolean spatial predicates on fact and level members, we can find the exact topological relations, i.e., if a fact member intersects with the level member or if a fact member is within the level member. We explain how to detect these explicit fact-level (topological) relations in Section 4.2.1.

Moreover, there might also be some missing links between the (observartions) fact members and the corresponding base level members. For this case we need to find all the base level members that are spatial and derive the links between the spatial measure values and spatial attribute values (of the base level members) by using Boolean spatial predicates. We explain how to discover fact-level (topological) relations, which are not explicitly linked between observation fact and base level members in Section 4.2.2.

There are also cases where we would like to establish a direct (topological) relation between the fact members and higher granularity (parent) level members, which are not at the base level of the dimension. Using the example depicted in Fig. 4 we explained that wrongly aggregating the measures (i.e., double counting) becomes a problem when we roll-up between the levels that have many-to-many (N:M) cardinality relations (as in Parish and Drainage Area levels). Therefore, it is necessary to drill-down to the lowest granularity (fact members) and find the direct relation between the observation fact members and the corresponding level members of the higher level in many-to-many cardinality relations.

In order to prevent this problem, we address the issue in our algorithm to discover and annotate the fact-level (topological) relations that are between the observation fact members and level members of a higher level in an N:M cardinality relation in Section 4.2.2. For example, such a relation is given in green in Line 6 (Listing 4) that shows a topological relation between an observation fact member (farm state) and a higher level – not a base level – member (drainage area).

Finally, in Section 4.2.3 we explain how to define a data structure definition (DSD) of spatial fact schema using a QB4OLAP fact schema and the spatial fact member instances derived in the previous two algorithms.

4.2.1. Detecting explicit fact-level relations

In this section, we present an algorithm for detecting explicit fact-level topological relations between observation fact members and base level members where there is a direct reference between the fact member and the base level member. To derive these topological relations we need to get the spatial attributes of fact members (spatial measures) and base level members.

Algorithm 5

$detectFactLevelRelations (G_{FM (F)}^{I}, G_{A (l m)}^{I}) : G_{FM (F_{s})}^{I}$

Algorithm 5 (detectFactLevelRelations) The input variables for Algorithm 5 are the instance graphs of fact members $G_{FM (F)}^{I}$ , level members $G_{LM (l)}^{I}$ , and attributes of level members $G_{A (l m)}^{I}$ .

Every fact member $f_{i} \in FM$ has an IRI ${id}^{I} (f_{i})$ and defined as a qb:Observation. The RDF graph formulation of a fact member $f_{i}$ is: $\begin{array}{l} G_{f_{i}}^{I} = & ⋃_{l_{j} \in L (f_{i})} {({id}^{I} (f_{i}) {id}^{S} (l_{j}) {id}^{I} (l m_{j}) ∣ f_{i} ⇝ l m_{j}} \\ \cup ⋃_{m_{k} \in M (f_{i})} {({id}^{I} (f_{i}) {id}^{S} (m_{k}) v_{m_{k}} ∣ f_{i} ⇝ v_{m_{k}}} . \end{array}$ Here, we denote by $f_{i} ⇝ l m_{j}$ that a fact member $f_{i}$ has an explicit link to a level member $l m_{j}$ (e.g., Listing 4, Line 3). Note that we denote by $l m ⇝ v_{a_{i}}$ that a level member $l m$ has value $v_{a_{i}}$ for attribute $a_{i}$ (Section 4.1.2), which is used in Algorithm 5 (Line 12) to get the attribute values of the linked level members. Moreover, we denote here by $f_{i} ⇝ v_{m_{k}}$ that a fact member $l m$ has value $v_{m_{k}}$ for measure $m_{k}$ (e.g., Listing 4, Lines 5 and 6). The RDF graph formulation of the other input variables are: attributes of level members $G_{A (l m)}^{I}$ and level members $G_{LM (l)}^{I}$ are already given, respectively, in Sections 4.1.2 and 4.1.3.

The output of Algorithm 5 is the enriched instance graph of fact members with topological relations $G_{FM (F_{s})}^{I}$ . In Line 2, we initialize the output graph as the input graph of fact members (without topological relations) so that we can gradually enrich it with the detected topological relations (Line 22). Initially, the topological relation variable ${topoRel}_{i}$ is set to null. We also create two temporary graphs: $G_{A (l m_{j})}^{I}$ and $G_{A (f_{i} m_{k})}^{I}$ as empty sets to keep triple patterns separately in two graphs for attributes of level members and (measures of) fact members. We also create two temporary sets: $V_{s (m_{k})}$ and $V_{s (a_{i})}$ for keeping the spatial values from the fact and level members, and initialize them also as empty sets in Line 3.

In the first foreach loop (Line 4 and 5) we retrieve the observation fact members from the input graph of fact members, which corresponds to Line 1 in Listing 4. Getting the fact members allows us to access each of their measures in Line 6 and level members in Line 7 (Algorithm 5). In the next foreach loop (Line 9) we match each measure-level member pair, where we can already retrieve the measure values from the input graph of fact members $G_{FM (F)}^{I}$ (Line 10) and through the input graph for attributes of the level members $G_{A (l m)}^{I}$ (Line 11 and 12), we can retrieve the attribute values. In Line 13, we assign the set of triples for measure attributes of fact members to a temporary graph $G_{A (f_{i} m_{k})}^{I}$ created earlier in Line 2. This temporary graph is given as an input to the helper function getSpatialValues (Algorithm 1) in Line 14 (Algorithm 5). The helper function returns the spatial attribute (measure) values of the fact members, which are kept in the temporary set $V_{s (m_{k})}$ . If this set is not empty (checked in Line 15) and has some spatial measures of fact member ${id}^{I} (f_{i})$ , we repeat the same procedure for retrieving the spatial attribute values of level member ${id}^{I} (l m_{j})$ in Lines 16 and 17. If the output set for spatial attribute values $V_{s (a_{i})}$ is also not empty (Line 18), then we go through the pairs of spatial values $(v_{m_{k}}, v_{a_{i}})$ in Line 19. In this loop, we call the next helper function relateSpatialValues (Algorithm 2), where the input is the spatial value pairs. The output value of this function is the topological relation between the corresponding fact and level members, which is assigned to the variable ${topoRel}_{i}$ (Line 20).

Algorithm 6:

$discoverFactLevelRelations (G_{FM (F)}^{I}, G_{LM (l)}^{I}, G_{A (l m)}^{I}, G_{D}^{S}, G_{H (d)}^{S}, G_{HS (h)}^{S}) : G_{FM (F_{s})}^{I}$

4.2.2. Discovering implicit fact-level relations

In this section, we present an algorithm for discovering fact-level (topological) relations, where there are no direct links between the fact and level members. This algorithm handles the following situations: 1) Finding the topological relations between observation facts and base level members; 2) Finding the topological relations between observation facts and parent level members in an N:M cardinality relation. In both cases there are no direct links between the observation facts and level members. Therefore, we benefit from (QB4OLAP) schema graphs of dimensions, hierarchies, and levels for iterating through the RDF triples to distinguish the base level members, and find the parent level members, when there is an N:M cardinality relation between the levels of a hierarchy at a hierarchy step.

Algorithm 6 (discoverFactLevelRelations) The input variables at the schema level for Algorithm 6 are the schema graphs of dimensions $G_{D}^{S}$ , hierarchies of the dimensions $G_{H (d)}^{S}$ , levels of the hierarchies $G_{L (h)}^{S}$ , and hierarchy steps of the hierarchies $G_{HS (h)}^{S}$ . The RDF graph formulations of the schema level input variables (dimensions $G_{H (d)}^{S}$ , hierarchies $G_{H (d)}^{S}$ , and levels $G_{L (h)}^{S}$ ) are already given in Section 4.1.3. Therefore, we only explain the structure of a hierarchy step in the schema graph. Each hierarchy step $h s_{i}$ is defined in the schema graph $G_{HS (h)}^{S}$ as a blank node $_{:hs}_{i} \in B$ . Each hierarchy step is linked to a hierarchy ${id}^{S} (h)$ with the qb4o:inHierarchy predicate and has a child level ${id}^{S} (l_{c})$ , a parent level ${id}^{S} (l_{p})$ , and a cardinality relation ${id}^{S} (card)$ , which are provided with qb4o:childLevel, qb4o:parentLevel, and qb4o:pcCardinality predicates in Line 6.

The input variables at the instance level are the instance graphs of fact members $G_{FM (F)}^{I}$ , level members of levels $G_{LM (l)}^{I}$ , and attributes of level members $G_{A (l m)}^{I}$ . We have already explained the RDF graph formulations of the instance level input variables (fact members $G_{FM (F)}^{I}$ , level members $G_{LM (l)}^{I}$ , and attributes of level members $G_{A (l m)}^{I}$ ) in Section 4.2.1.

The output of Algorithm 6 is the enriched instance graph of fact members with the topological relations $G_{FM (F_{s})}^{I}$ . In Line 2, we initialize the output graph as the input graph of fact members (without topological relations) so that we can gradually enrich it with the detected topological relations (Line 22). Initially, the topological relation variable ${topoRel}_{i}$ is set to null. We also create two temporary graphs: $G_{A (l m_{j})}^{I}$ and $G_{A (f_{i} m_{k})}^{I}$ as empty sets to keep triple patterns separately in two graphs for attributes of level members and (measures of) fact members. We also create two temporary sets: $V_{s (m_{k})}$ and $V_{s (a_{i})}$ for keeping the spatial values from the fact and level members and initialize them also as empty sets in Line 3.

To find the topological relations between observation facts (with spatial measures) and base level members (with spatial attributes), first, we need to find all the base levels since there is no direct link between the fact and level members. To achieve this in Algorithm 6, we use the schema definitions readily available in QB4OLAP. In Line 4, we iterate through the nested loops of dimensions to get the hierarchies and in Line 5 we iterate the nested loops of hierarchies to get the hierarchy levels. To find the base level of a hierarchy, we have to iterate through the hierarchy steps, where each hierarchy step describes a child level, a parent level and a cardinality relation between the levels (Line 6). If a level ${id}^{S} (l_{n})$ has never been assigned as a parent level with qb4o:parentLevel predicate in any of the hierarchy steps in a hierarchy h from the schema graph $G_{HS (h)}^{S}$ , then $l_{n}$ is the base level of a hierarchy h (Line 7).

Thus, we can retrieve the level members of level $l_{n}$ from the instance graph level members $G_{LM (l)}^{I}$ (Line 8). In the next foreach loop we can pair the level members from the instance graph $G_{LM (l)}^{I}$ , and observation facts from the instance graph of fact members $G_{FM (F)}^{I}$ (Line 9). We can retrieve a set of attributes (measures) for fact members from the fact members graph (Line 10), and a set of attributes for level members from the instance graph $G_{A (l m)}^{I}$ (Line 11).

Then, in the next foreach loop in Line 12, we get the triple patterns with each measure values of the fact member and attribute values of the level member in pairs. While iterating through the (pair of) triple patterns, we insert each member of the pair to the temporary graphs for measures of fact members $G_{A (f_{i} m_{k})}^{I}$ and attributes of level members $G_{A (l m_{j})}^{I}$ (Line 13), which are created earlier as empty sets in Line 3. Then, we can filter the spatial values from the triple patterns kept in the temporary graphs by calling the helper function getSpatialValues (Algorithm 1), with those input graphs $G_{A (f_{i} m_{k})}^{I}$ and $G_{A (l m_{j})}^{I}$ (Line 14). We call the helper function getSpatialValues (Algorithm 1) twice, with the input graphs $G_{A (f_{i} m_{k})}^{I}$ and $G_{A (l m_{j})}^{I}$ , where the outputs of the each (helper) function call are assigned to the temporary sets $V_{s (m_{k})}$ and $V_{s (a_{i})}$ correspondingly (Line 14). If these sets are not empty (Line 15), it means that getSpatialValues identified spatial values in the triple patterns of the input graphs.

Then, we iterate through the spatial value pairs retrieved from the each of the sets (Line 16). In this loop, we call the next helper function relateSpatialValues (Algorithm 2), where the input is a spatial value pair. The output value of this function is the topological relation between the corresponding level members, and it is assigned to the initially created temporary variable ${topoRel}_{i}$ (Line 17). If this ${topoRel}_{i}$ value is not null (Line 18), the output graph for the spatial fact members is incrementally enriched by adding the triple pattern with the topological relation (Line 19).

To find the topological relations between the observation facts and parent level members in an N:M cardinality relation, we check in Line 20 that if level ${id}^{S} (l_{n})$ is assigned as a parent level in a hierarchy step with qb4o:parentLevel predicate and the hierarchy step entails an N:M relation with qb4o:ManyToMany predicate. If that is the case, we repeat the same steps from Lines 8 to 19.

Finally, the output graph for the spatial fact members with discovered fact-level (topological) relations is returned in Line 22.

4.2.3. Defining spatial fact DSD

In this section, we present an algorithm for re-defining the fact schema data structure definition (DSD) by enriching the DSD with fact-level topological relations. An example of a fact schema in QB4OLAP is given in the black-colored lines of Listing 3 (for now please ignore Lines 3, 5 and 7). We re-define the spatial fact schema to QB4SOLAP (Listing 3 Lines 1–7) by using the enriched fact members that are generated via Algorithms 5 and 6.

Algorithm 7:

$defineSpatialFactDSD (G_{FM (F_{s})}^{I}, G_{F}^{S}) : G_{F_{s}}^{S}$

Algorithm 7 (defineSpatialFactDSD) The input variables for Algorithm 7 are the instance graph of spatial fact members $G_{FM (F_{s})}^{I}$ and schema graph of QB4OLAP fact schema $G_{F}^{S}$ . Spatial fact members in the instance graph $G_{FM (F_{s})}^{I}$ must be annotated with QB4SOLAP or can be generated by using Algorithms 5 and 6 from QB4OLAP fact members. A QB4OLAP fact schema $G_{F}^{S}$ has (base) levels and measures of the cube as qb:components and defines the fact-level cardinality relation with qb4o:cardinality predicate, aggregate functions on (numerical) measures with qb4o:aggregateFunction predicate.11

¹¹

In QB4OLAP, qb4o:AggregateFunction class has only instances (e.g., qb4o:Avg, qb4o:Sum functions) for numerical measures. QB4SOLAP extends this class with a subclass qb4so:SpatialAggregateFunction, which has instances of spatial aggregate functions (e.g., qb4so:ConvexHull, qb4so:Union) for spatial measures [13,15].

The output of Algorithm 7 is the enriched fact schema graph $G_{F}^{S}$ annotating the fact-level relations with QB4SOLAP topological relations and measures with spatial aggregate functions.

In Line 2, we initialize the output graph as the input schema graph so that we can gradually enrich it with QB4SOLAP schema annotations (Lines 5 and 15). Initially, an aggregate function variable ${aggFunc}_{i}$ is created and set to $null$ (Line 2).

The first foreach loop iterates through the fact members graph $G_{FM (F_{s})}^{I}$ and finds each fact member $f_{i}$ by using the triple pattern $({id}^{I} (f_{i}) rdf:type qb:Observation)$ . The second foreach loop gets every distinct topological relation ${topoRel}_{i}$ of the fact member $f_{i}$ (Line 4). Then the output schema is annotated with the identifier of these topological relations (Line 5). Next, we get every measure $v_{m_{k}}$ of the fact member $f_{i}$ (Line 6), and check if it is a spatial measure (Line 7). If it is a spatial measure, we find the geometry type with geoType function (Line 8). We have appointed the corresponding spatial aggregate functions (Lines 10, 12, and 14) with regard to the geometry type of the spatial measure (Lines 9, 11, and 13). Finally, the output schema $G_{F_{s}}^{S}$ is annotated with the identifier of these spatial aggregate functions (Line 15) and returned (Line 16).

4.3. Implementation choices

When implementing the algorithms presented in this section, we had to make some implementation choices both in technical as well as strategical aspects that we would like to briefly comment on. Further details regarding the implementation of the algorithms themselves are available in the Appendix. As mentioned earlier, RDF2SOLAP is implemented in Javascript on the Node.js platform using the N3.js library for parsing the RDF triples in Javascript and the Turfjs library for spatial analysis. Details of our approach, endpoints, and datasets can be found on our project page.12

¹²
Project Page: http://extbi.cs.aau.dk/RDF2SOLAP.

The code repository for the whole implementation can be found on GitHub.13

¹³

RDF2SOLAP Repository: https://github.com/lopno/rdf2solap.

To answer the question: “Can this approach be reasonably implemented on top of triple stores by directly using Web and Semantic Web technologies?”, we have come across a number of challenges, where specific choices had to be made.

For example, we chose to store RDF data in a well-established triple store (Virtuoso Open Source) that supports many geometry data types (i.e., POLYGON, MULTIPOLYGON). Even though Virtuoso supports several shape types (e.g., POLYGON, MULTIPOLYGON, etc.), it has a limited number of spatial Boolean functions available as built-in functions from the DE9DIM model (see Table 1). Therefore, we have also decided to use a third party Javascript library for spatial analysis, which is called Turfjs⁶. This way, we can ensure that RDF2SOLAP can be used on top of any triple store since the Javascript library provides us with the spatial analysis capabilities and a flexible development environment, independent from the choice of the triple store.

We are working with multi-part POLYGON data (for drainage areas and parishes), which means that, when several polygons are grouped by unique (parish or water) URIs they can compose a MULTIPOLYGON for a single parish or drainage area instance. From the implementation point of view, we had to implement a bounding box function for multi-part POLYGON data, in order to call the spatial Boolean functions (within and intersects) between the correct parish and drainage area instances, then annotate the topological relations between their unique URIs. If triple stores already provided overall support of complex spatial data types, spatial indices, and a complete support of built-in spatial functions, decoupling the triple stores during development of RDF2SOLAP would not have been necessary. We could then directly have used the spatial capabilities of the triple stores that were required for developing RDF2SOLAP. However, to the best of our knowledge, a third party spatial analysis library was needed to fully implement our RDF2SOLAP (spatial) multi-dimensional enrichment algorithms described in Section 4.

5. Experimental evaluation

The section is structured as follows. We describe experimental settings in Section 5.1. Then we compare development time between our approach and the baseline, followed by a comparison of the runtimes and the annotation quality. Finally, we summarize our findings in Section 5.5.

5.1. Experimental setup

The rationale for developing RDF2SOLAP is to be able to enrich and annotate existing spatial RDF data with spatial and multi-dimensional metadata while staying within the RDF environment. This upgrades the spatial RDF data to allow SOLAP querying directly in SPARQL. The alternative would be to export the spatial RDF data to relational format, do the enrichment with relational/GIS tools and perform the SOLAP on the resulting relational data, thus loosing all the advantages of having the data in RDF in the first place. Doing the enrichment purely within the RDF environment is expected to come at a cost as support for spatial and multidimensional data in the RDF/SW stack is still less mature; this will however improve over time. Thus, our goal is just to demonstrate that we can do this in a pure RDF environment with adequate performance in terms of runtime and annotation quality (which may vary). In return, RDF2SOLAP provides a solution that is both flexible and general for all data sets. We then compare our general solution to the alternative baseline, which is spending long development times on hand-crafting specialized enrichment solutions using RDBMSes and GIS for each new data set.

We used the common Virtuoso version 07.20.3217 on Linux (x86_64-ubuntu-linux-gnu), Single Server Edition as triplestore. We implemented RDF2SOLAP on the Node.js platform, running on a Macbook Pro 14.3 with one Intel Core i7 2.8GHz 4-core CPU 256KB L2 cache, 6MB L3 cache, and 16GB RAM. All test cases are in the GitHub repository so the experiments can be repeated. Each experiment was run in a single process. For the baseline implementation, we used a leading GIS tool and a leading RDBMS (we cannot write the names due to license restrictions, but they can be supplied on demand). These were running on a Windows 10 Enterprise server with 4 Intel Core i7 2.9GHz CPUs and 32GB memory, i.e., considerably more powerful hardware. We use both the GeoFarmHerdState data set described above and the GeoNorthwind data set from [15].

We now describe how the RDBMS and GIS baselines were implemented. Since the GIS tool and the RDBMS cannot process RDF data in native format, we first have to extract and prepare the data for loading into them. The preparation time is part of the development time discussed below. Doing this preparation requires that the developer has basic knowledge of the domain, extraction of RDF data with SPARQL queries, writing SQL queries, and knows how to use the RDBMS and GIS tools. We extracted the spatial level members (farms states, parishes, and drainage areas) from our RDF endpoint in CSV format. To load the data into the GIS tool and RDBMS we use the relational schema defined by QB4SOLAP. In the GIS tool we saved CSV data layers (for each level; farm states, parishes and drainage areas) and converted these into native GIS format (shape files). Then, we run the Join Attributes By Location function, which is a built-in data management function. We run this function as a batch process, for parishes-drainage areas (Alg. 4), farm states-parishes, and farm states-drainage areas (Alg. 6). We load the WKT data (spatial attributes of level and fact members) in the CSV files into the GIS tool and a relational geo-database, with the same decimal precision for the coordinates. We extract topological relations between the child and parent members by using spatial joins in the GIS tool and built-in spatial functions in the RDBMS. Overall, most of the time was spent on data extraction, preparation, and load, caused by having to convert data from its existing RDF format. None of these tasks are needed if the enrichment is done entirely within an RDF environment, like in RDF2SOLAP.

5.2. Development time comparison

We now compare the time required to develop enrichment solutions for spatial RDF data with RDF2SOLAP to using the RDBMS and GIS baselines. Here, it is important to keep in mind that RDF2SOLAP has general algorithms that use existing metadata and annotations to work for any spatial RDF data set, requiring only a few minutes of configuration, while a new baseline enrichment solution has to be implemented for each new data set, requiring literally (repeated) days of development time. Of course, there was a onetime development cost for RDF2SOLAP. However, this cost is already paid and will not be repeated, unlike the case for the baselines.

The development times for RDF2SOLAP, and the RDBMS and GIS baselines for the one-time step of General Algorithms (only RDF2SOLAP) and the GeoFarmHerdState data set, are given in Table 2. One day corresponds to 8 hours. All development was carried out by the first and fourth author who both have significant experience in all the used tools and platforms, and also recorded the development times for RDF2SOLAP and GeoFarmHerdState. The RDF2SOLAP configuration times for each data set were also recorded by the first author. We find these development times realistic and comparable. As GeoNorthWind is only included to demonstrate that RDF2SOLAP can generalize to other data sets, we have not implemented the baseline enrichment solutions for GeoNorthWind. Thus, we have not reported RDBMS and GIS development times in the table. However, realistic estimates would be in the same range as for GeoFarmHerdState, i.e., one or more days.

Table 2
Development times

RDF2SOLAP RDBMS GIS

General algorithms 1.4 days (one-time) N/A N/A

GeoFarmHerdState 5 min (config) 1.3 days 2 days

GeoNorthWind 10 min (config) N/A N/A

	RDF2SOLAP	RDBMS	GIS
General algorithms	1.4 days (one-time)	N/A	N/A
GeoFarmHerdState	5 min (config)	1.3 days	2 days
GeoNorthWind	10 min (config)	N/A	N/A

Table 3

Input, output, and runtimes for RDF2SOLAP algorithms on GeoFarmHerdState

		INPUT			OUTPUT

		NumberOf child members	NumberOf parent members	NumberOf explicit relations	NumberOf topological relations		Run times (in seconds)
Section 5.2	Alg. 3	parishes: 2,180	drainageAreas: 134	2,683	intersects	636	29 s
	Alg. 3	parishes: 2,180	drainageAreas: 134	2,683	within	2,046	29 s
	Alg. 5	farmStates: 40,039	parishes: 2,180	39,800	within	39,334	7 s
Section 5.3	Alg. 4	parishes: 2,180	drainageAreas: 134	NONE	intersects	1,088	2,622 s
	Alg. 4	parishes: 2,180	drainageAreas: 134	NONE	within	3,392	2,622 s
	Alg. 6	farmStates: 40,039	parishes: 2,180	NONE	within	39,998	1,920 s
	Alg. 6	farmStates: 40,039	drainageAreas: 134	NONE	within	39,845	525 s

From the table, we can see that RDF2SOLAP allows to enrich and annotate new spatial RDF data sets with just minutes of effort, since the enrichment process is done automatically after retrieving the input parameters to the enrichment algorithms from the endpoint. In comparison, each new data set requires one or more days of (repeated) development effort for the baseline RDBMS and GIS enrichments.

5.3. Runtime comparison

Having established that RDF2SOLAP requires up to 2 orders of magnitude less development time for a new data set, we now investigate whether it can do the enrichment with reasonable runtimes, and compare its runtimes to those of the baseline implementations. Both the total runtimes (in minutes) and the subtotals (in seconds, for accuracy) for the different algorithms are reported. The GeoFarmHerdState runtimes are seen in Tables 3 and 4.

Alg. 3 and 5 (to detect explicit topological relations) are only implemented in the RDBMS since the GIS tool does not support the foreign key joins of explicit (skos:broader) relations which are needed for these two algorithms. In order to implement the needed topological relations in RDF2SOLAP, we had to use theturf.js library running on a node.js server, where the RDF data is parsed into JSON format, since these relations were not supported by the triplestore. This meant that we could not take advantage of spatial indexing in the triplestore.

To understand the size of the input and output of the algorithms for GeoFarmHerdState, we report these along with corresponding RDF2SOLAP runtimes in Table 3. The input parameters and numbers for each algorithm are shown in Table 3 under the INPUT column(s). The input datasets to the algorithms are 2,180 parish members, 40,039 farm state members, and 134 drainage area members. The OUTPUT columns show the number of topological relations found and run times of the algorithms. In this section, we only focus on the runtime, the annotation quality is evaluated later.

Table 4
GeoFarmHerdState runtimes (f.s. = farm states, p. = parishes, d.a. = drainage areas)

RDF2SOLAP RDBMS GIS

Alg. 3 (p. – d.a.) 29 s <1 s N/A

Alg. 4 (p. – d.a.) 2,622 s 43 s 45 s

Alg. 5 (f.s. – p.) 7 s <1 s N/A

Alg. 6 (f.s. – p.) 1,920 s 95 s 72 s

Alg. 6 (f.s. – d.a.) 525 s 48 s 41 s

Total 85 m 3 m $>$ 2.5 m

	RDF2SOLAP	RDBMS	GIS
Alg. 3 (p. – d.a.)	29 s	<1 s	N/A
Alg. 4 (p. – d.a.)	2,622 s	43 s	45 s
Alg. 5 (f.s. – p.)	7 s	<1 s	N/A
Alg. 6 (f.s. – p.)	1,920 s	95 s	72 s
Alg. 6 (f.s. – d.a.)	525 s	48 s	41 s
Total	85 m	3 m	$>$ 2.5 m

In Table 3, we can see that most expensive algorithm is Alg. 4 (discoverSpatialHS), which runs in 2,622 seconds. The algorithm takes parishes and drainage areas (POLYGON data type) as input instances, and not explicit relations as in Alg. 3 (detecSpatialHS). Alg. 3, given (2,683) distinct explicit relations, checks the corresponding spatial Boolean functions (within and intersects) 2,683 times each. In comparison, Alg. 4 calls (within and intersects) 134 × 2,180 = 292,120 times each. Similarly, Alg. 6 is slower than Alg. 5 since the former does not use explicit relations. However, it is much faster than Alg. 4 since this calls the spatial Boolean functions between farm states (POINT data type) and parishes and drainage areas (POLYGON data type).

From the GeoFarmHerdState runtimes, we see that Alg. 4 and 6 use the most time, in particular for RDF2SOLAP. However, the total RDF2SOLAP runtime of 85 minutes is very reasonable and well within the requirements for practical use: a user wanting to analyze a new data set (which usually does not happen several times a day) can simply spend a few minutes on configuration and then let RDF2SOLAP run in the background for the next 1.5 hours. Especially for non-developer RDF users, this is a much better value proposition than first spending one or more days on technical development in the baseline tools.

For GeoNorthWind, the baselines were not implemented (see above) so only RDF2SOLAP runtimes are reported, see Table 5. For this smaller data set, RDF2SOLAP completes in just 26 seconds, making it usable even in interactive mode.

Table 5

GeoNorthWind runtimes

Hierarchy step	Algorithm	RDF2SOLAP
Customer-city (point-polygon)	Alg. 3	2 s
Customer-city (point-polygon)	Alg. 4	7 s
Supplier-city (point-polygon)	Alg. 3	<1 s
Supplier-city (point-polygon)	Alg. 4	<2 s
City-state (polygon-polygon)	Alg. 3	1 s
City-state (polygon-polygon)	Alg. 4	13 s
Total		26 s

In summary, the runtime comparisons show that, even though RDF2SOLAP is slower than the hand-crafted baselines, it still has a runtime performance that is more than adequate for its intended use case.

5.4. Annotation quality comparison

We now compare RDF2SOLAP to the RDBMS and GIS baseline tools in terms of annotation quality. Specifically, we report the number of the topological relations found by each algorithm/step in each tool, and relate these to accuracy and coverage. The numbers are given in Table 6.

Table 6
Number of topological relations found by each tool (f.s. = farm states, p. = parishes, d.a. = drainage areas)

Tools

GIS RDBMS RDF2SOLAP

Alg. 3: (p. – d.a.) intersects N/A 1,897 636

within N/A 785 2,046

Alg. 4: (p. – d.a.) intersects 2,556 2,802 1,088

within 1,039 785 3,392

Alg. 5: (f.s. – p.) within N/A 39,334 39,334

Alg. 6: (f.s. – p.) within 39,805 39,984 39,998

Alg. 6: (f.s. – d.a.) within 39,441 39,845 39,845

		Tools
Alg. 3: (p. – d.a.)	intersects	N/A	1,897	636
within	N/A	785	2,046
Alg. 4: (p. – d.a.)	intersects	2,556	2,802	1,088
within	1,039	785	3,392
Alg. 5: (f.s. – p.)	within	N/A	39,334	39,334
Alg. 6: (f.s. – p.)	within	39,805	39,984	39,998
Alg. 6: (f.s. – d.a.)	within	39,441	39,845	39,845

As mentioned earlier, Alg. 3 and Alg. 5 were not implemented in the GIS tool due to its lack of support for explicit relations between parent-child members; thus these numbers are reported as N/A. We thus only tested the discovery of implicit topological relations (discoverSpatialHS and discoverFactLevelRelations) by utilizing its spatial join functionality to emulate the results for Alg. 4 and Alg. 6.

For the RDBMS tool, we tested both detect and discover topological relations, where we used joins on unique IDs if they were present (drainage area foreign key in parishes, parish foreign key in farm states), and with spatial joins by using the STWithin, STIntersects, and STOverlaps built-in functions.

We now compare results for each algorithm in the different tools. For Alg. 3, RDF2SOLAP reports only a third of the intersecs relations but almost three times as many within relations, as the RDBMS tool. This is due to generalizing the multi-part POLYGON data as bounding boxes in RDF2SOLAP (due to restrictions in our spatial library), in the spatial RDBMS, multi-part POLYGON data is processed in its original format, yielding better quality. Interestingly, the total number of intersects+within relations for the two tools are exactly the same, namely 2682. This suggest that RDF2SOLAP can get the same annotation quality as the RDBMS tool when better spatial support become available in the RDF environment.

Similar results are seen for Alg. 4. Here, the GIS and RDBMS results are similar, but not identical, showing that perfect annotation quality is not a given, even with traditional tools. Again, RDF2SOLAP finds fever intersects relations and more within relations (again due to the bounding box generalization), and again the total number of relations found by the 3 tools are very similar. This indicates that RDF2SOLAP can achieve the same annotation quality with better spatial RDF support.

For Alg. 5, the RDF2SOLAP and RDBMS results are identical. This perfect annotation quality can be achieved since the within relations are found between points and polygons which can be done exactly by the library.

For Alg. 6, the results found by the 3 tools for (farm states-parishes) are very close, with RDF2SOLAP differing 0.5% from the GIS tool and 0.04% from the RDBMS tool. For (farm states-drainage areas), the RDF2SOLAP and RDBMS results are identical, while the GIS result differs by 0.01%. Thus, the annotation quality for all 3 tools is near-perfect.

Similar results were found for GeoNorthWind. For Hierarchy Step 1, there are 89 correct within relations. Of these, Alg. 3 found 75 of them correctly, while Alg. 4 found 91 relations (the 89 correct and 2 extra incorrect). For Hierarchy Step 2 there are 28 correct within relations: Alg. 3 found 24 of them correctly, while Alg. 4 found all 28 of them correctly. For Hierarchy Step 3, we do not have the correct ground truth since this requires the GIS and RDBMS baselines to have been implemented.

RDF2SOLAP’s problems with POLYGON-POLYGON relations could have been prevented if we had been able to use multi-part POLYGON and MULTIPOLYGON data in its original form instead of generalizing them to bounding boxes. However, We encountered both performance and formatting problems while loading MULTIPOLYGON data to Virtuoso, which led to missing data in the triplestore for drainage areas. Even if the MULTIPOLYGON data was could be successfully loaded, Turf.js is not able to handle POLYGON-MULTIPOLYGON within relations. We thus had to make a trade-off and implement the POLYGON-POLYGON relations with generalized bounding boxes.

In summary, the annotation quality of RDF2SOLAP is near-perfect for the spatial relations that are well supported in the RDF environment. There are some problems with polygon-to-polygon relations, but these are caused by limitations in our spatial library. When better spatial RDF support becomes available, we are confident that RDF2SOLAP will provide near-perfect annotation quality for all cases.

5.5. Experimental summary

In summary, we have seen that RDF2SOLAP provides orders of magnitude less development time for new data sets (minutes versus days), and, while slower than the RDBMS and GIS tools, has adequate runtimes for its intended use case. For some algorithms, its annotation quality is near-perfect, while for others, it will be when better spatial RDF support becomes available.

6. Related work

Utilizing DW/OLAP technologies on the Semantic Web with RDF data makes RDF data sources more easily available for interactive analysis. As summarized by Abelló et al. [1], related work has studied OLAP and data warehousing possibilities on the Semantic Web (SW) in general. Our work, however, is centered around spatial OLAP (SOLAP) and spatial data warehouses (SDW) on the Semantic Web, which is not yet a comprehensively studied research topic. We focus on performing spatial OLAP analysis directly over multi-dimensional data published on the Semantic Web. Therefore, we review the related work with relevant approaches classified under the following titles: (1) data modeling and representation (on the SW for multi-dimensional and spatial data), (2) metadata enrichment and MD analysis (OLAP-like analysis over RDF data).

Data modeling and representation The RDF Data Cube (QB) vocabulary [48] is the W3C recommendation to publish statistical data and its metadata in RDF. Thus, QB is commonly used to publish raw or already aggregated multidimensional data sets. However, QB lacks the underlying metadata for multidimensional models and OLAP operations. The set of MD concepts, such as, hierarchy levels along a cube dimension, semantics of the relationships between levels, semantics and definitions of aggregate functions are missing in QB vocabulary, are essential in an MD schema to enable OLAP analysis. Therefore, Kämpgen et al. define an OLAP data model on top of QB by using SKOS [30] extensions14

¹⁴
http://www.w3.org/2011/gld/wiki/ISO_Extensions_to_SKOS

to support multi-dimensional hierarchies [26,27]. However, the proposed model has some limitations on levels to exist only in one hierarchy. The OLAP operations are made available on the data cubes with the proposed model but restricting the cubes with only one hierarchy per dimension. Etcheverry et al. propose QB4OLAP [7] as an extension to the QB vocabulary, which supports modeling a complete MD data cube and querying the cube with OLAP operations on the Semantic Web. Modeling of MD data on the Semantic Web motivated the publication of datasets from several domains (e.g., statistical data sets from EuroStat and World Bank data, AirBase air quality data, and many other environmental and governmental open data) as RDF data cubes [47].

The need of fully multi-dimensional semantic data warehouses (where OLAP operations are enabled in SPARQL) made the QB4OLAP vocabulary prominent. Therefore, RDF data cubes from statistical and environmental domains [10,12,43] are published with an extended QB vocabulary. Moreover, semantic Extract-Transform-Load (ETL) tools automate and ease the process of annotating and publishing open data with QB4OLAP on the Semantic Web [5,31,32]. Therefore, we can see more and more multi-dimensional datasets annotated with QB4OLAP on the Semantic Web.

These multi-dimensional semantic modeling approaches and querying with OLAP on the Semantic Web lead us to find ways for modeling, publishing, and querying spatial data warehouses in particular since modeling and querying spatial data bring new challenges. QB4SOLAP [13] – a spatial extension to a fully multi-dimensional QB4OLAP vocabulary emerges the need of modeling and publishing geo-semantic data warehouses on the Semantic Web.

Modeling and publishing (non multi-dimensional) spatial data on the Semantic Web has been a focus by many communities and research groups. Some of the efforts for standardizing and aligning vocabularies to describe spatial data (e.g., locations, geometries, etc.) are GeoSPARQL [34] by the Open Geospatial Consortium (OGC), Basic Geo (WGS84 lat/long) Vocabulary by W3C Semantic Web Interest Group [4], NeoGeo Vocabularies by GeoVocab working group [40], INSPIRE Directive metadata on the Semantic Web [35], and GeoNames Ontology [45] among many others.

These standards have been commonly used in a wide range of projects. Government Linked Data (GLD) working group listed some of these geo-vocabularies as standards to publish governmental linked data sets [20]. Andersen et al. re-use some of these vocabularies for publishing governmental and spatial data on the Semantic Web [2]. LinkedGeoData is a big contribution to the Semantic Web, which interactively transforms OpenStreetMap data to RDF data [41]. The GeoKnow project focuses on linking geospatial data from heterogeneous sources [39]. More recent works by Kyzirakos et al. to transform geospatial data into RDF graphs using R2RML mappings [28] and geo-semantic labelling of open data [33] by Neumaier et al. show that spatial data on the Semantic Web will keep growing. However, none of these standards considers the MD aspects of spatial data for geo-semantic data warehouses.

Large volumes of spatial data on the Semantic Web yield a need for advanced modeling and analysis of such data. As mentioned earlier, QB4SOLAP [13] remedies this need. Aggregate functions, cardinality relationships, and topological relations are rich sources of knowledge in spatial data cubes in order to query with spatial OLAP operations in SPARQL [15].

QB4ST [3] is a recent attempt to define extensions for spatio-temporal components to RDF Data Cube (QB). However, it has the inherent limitations of QB to support OLAP dimensions with hierarchies, levels, and aggregate functions. Lack of OLAP hierarchies and aggregate functions in QB4ST hinders to define and operate with topological relations at hierarchy steps or spatial aggregate functions on spatial measures, which are essential MD concepts for SOLAP operators. These spatial MD concepts in geo-semantic data warehouses are defined together with SOLAP to SPARQL query mappings in [15].

Metadata enrichment and MD analysis Increasing popularity of RDF data cubes and MD OLAP cubes on the Semantic Web raised interest in tools and frameworks that can ease the annotation and querying of MD data on the Semantic Web from existing RDF sources.

Ibragimov et al. present a framework for exploratory OLAP over Linked Open Data (LOD), where the MD schema of the data cube is annotated with QB4OLAP [22]. Based on this MD schema, they propose a system that is capable of querying data sources, extracting and aggregating data to build OLAP cubes in RDF [23] and querying in a federated setup [21]. Similarly, Gallinucci et al. propose an exploratory OLAP approach, namely iMOLD by interactively MD modeling of linked data [11]. Their approach allows users to enrich RDF cubes with aggregation hierarchies through a user-guided process. During this interactive process, the recurring modeling patterns that express roll-up relationships between RDF concepts are recognized in the LOD, then these patterns are translated into aggregation hierarchies to enrich the RDF cube. Varga et al. enables OLAP analysis with the QB2OLAP tool in [43] over statistical data published with QB vocabulary, by applying dimensional enrichment steps described thoroughly in [44]. The proposed enrichment steps allow users to enrich a QB dataset with QB4OLAP concepts such as fully-fledged dimension hierarchies. However, none of these frameworks and approaches supports spatial data warehouses and SOLAP operations.

In this paper, we propose a framework, where OLAP cubes in RDF can be enriched with spatial MD concepts from the QB4SOLAP vocabulary by employing RDF2SOLAP enrichment algorithms over QB4OLAP triples. This allows users to query MD cubes with SOLAP operators in SPARQL. Optionally, users can utilize GeoSemOLAP [14] tool on top of QB4SOLAP data sets, which helps users formulate SOLAP queries in SPARQL.

7. Conclusion and future work

Motivated by the need to conciliate MD/OLAP RDF data cubes and spatial data on the Semantic Web as geo-semantic data warehouses, we have presented a number of contributions in this paper. As a first attempt to enrich RDF data cubes with spatial concepts, we have shown that the QB4SOLAP vocabulary yields the need for fully-fledged spatial data warehouse concepts (that is built on top of non-spatial QB4OLAP and RDF Data Cube (QB) vocabularies), by demonstrating the running use case examples from real world governmental open data sets from various domains (i.e., environment, farming) with complex geometry types. We introduced running use case examples annotated both with QB4OLAP and QB4SOLAP vocabularies, in RDF triples and formalized the RDF triples as parameters to use in the enrichment algorithms. Second, we have built our conceptual architecture in relation to existing semantic (spatial) OLAP tools (e.g., on top of the QB2OLAPem enrichment module and at the back-end of GeoSemOLAP). Third, we have provided hierarchical enrichment algorithms for two cases that cover finding explicit hierarchy steps with direct links between the level members and finding implicit hierarchy steps (without direct links between the level members) by comparing geometry attributes of the level members. We have defined and deployed the necessary algorithms as spatial helper functions for finding spatial attributes and comparing these attributes to derive topological relations. Fourth, we have presented the factual enrichment phase for both implicit and explicit fact-level relations between the fact and level members. Moreover, we have presented how to re-define the fact schema after the factual enrichment phase in an automated manner. Re-defining the fact schema also includes finding the spatial measures and associating them with spatial aggregate functions. In the end, we have implemented all the algorithms that are designed for both hierarchical enrichment and factual enrichment processes, then we presented the details of our implementation.

Finally, we have evaluated our approach and its accuracy as well as the implementation with the underlying technologies by comparing the number of topological relations found in the RDF2SOLAP framework (between the level members in spatial hierarchies and between the level members and the fact members, respectively, during the hierarchical enrichment phase and the factual enrichment phase) against two different non-SW environments. We have presented the experimental set-up and our comparison baselines and concluded our evaluation with technical lessons learned.

In conclusion, RDF2SOLAP facilitates the spatial enrichment of RDF data cubes and fills an important gap in our vision of SOLAP on the Semantic Web despite of the challenges and restrictions in supporting complex spatial data types with the current state of the most common triple stores [18,19,24].

Several directions are interesting for future research: creating a comprehensive benchmark by implementing the RDF2SOLAP enrichment algorithms on different platforms and testing on different use cases, deriving spatial hierarchy levels and level member instances from external geo-vocabularies and extending our approach in QB4SOLAP, GeoSemOLAP and RDF2SOLAP to handle highly dynamic spatio-temporal data and multi-dimensional analytical queries [25]. Another line of future work would be runtime optimizations for scalable querying of spatial data warehouses [9] exploiting specifics of Linked Data Management [16,17]. Moreover, it is also important to develop query optimization techniques for OLAP queries on semantic DW/RDF data, similar to the ones developed for cubes and XML data [36,37,49]. Furthermore, to achieve scalable querying and runtime optimization, new research directions can be taken with binary serialization of the QB4SOLAP RDF data such as header dictionary triples (HDT), which is a compact data structure that can be compressed and kept in-memory, thus it enables high performance (and also concurrent) querying.

Footnotes

Acknowledgements

This research is partially funded by the European Commission through the Erasmus Mundus Joint Doctorate Information Technologies for Business Intelligence (EM IT4BI-DC), the Danish Council for Independent Research (DFF) under grant agreement no. DFF-8048-00051B, Aalborg University’s Talent Programme, and the Poul Due Jensen Foundation.

Implementation details

In this section, first we provide the details on how the algorithms from Section 4 are implemented to generate spatially enriched RDF triples with QB4SOLAP (Sections A.1, A.2, A.3, and A.4). Afterwards, we discuss our implementation choices in Section 4.3 and present the results of applying the algorithms on the use case data (GeoFarmHerdState) in Section 5 (Table 3).

References

Abelló,

Romero,

T.B.

Pedersen,

Berlanga,

Nebot,

M.J.

Aramburu and

Simitsis, Using semantic web technologies for exploratory olap: A survey, IEEE Transactions on Knowledge and Data Engineering27(2) (2015), 571–588. doi:10.1109/TKDE.2014.2330822.

A.B.

Andersen,

Gür,

Hose,

K.A.

Jakobsen and

T.B.

Pedersen, Publishing Danish Agricultural Government data as semantic web data, Semantic Technology8943 (2014), 178–186. doi:10.1007/978-3-319-15615-6_13.

Atkinson, QB4ST: RDF data cube extensions for spatio-temporal components, W3C Working Group, 2017, https://www.w3.org/TR/qb4st/.

Brickley, Basic geo (WGS84 lat/long) vocabulary, W3C Semantic Web Interest Group, 2003, https://www.w3.org/2003/01/geo/.

R.P.

Deb Nath,

Hose and

T.B.

Pedersen, Towards a programmable semantic extract-transform-load framework for semantic data warehouses, in: Proceedings of the 18th International Workshop on Data Warehousing and OLAP, 2015, pp. 15–24. doi:10.1145/2811222.2811229.

M.J.

Egenhofer and

Herring, A mathematical framework for the definition of topological relationships, in: Fourth International Symposium on Spatial Data Handling, 1990, pp. 803–813. doi:10.1080/02693799108927841.

Etcheverry,

Vaisman and

Zimányi, Modeling and querying data warehouses on the semantic web using QB4OLAP, in: Data Warehousing and Knowledge Discovery, Vol. 8646, Springer, 2014, pp. 45–56. doi:10.1007/978-3-319-10160-6_5.

Gaede and

Günther, Multidimensional access methods, ACM Computing Surveys (CSUR)30(2) (1998), 170–231. doi:10.1145/280277.280279.

Galárraga,

Ahlstrøm,

Hose and

T.B.

Pedersen, Answering provenance-aware queries on RDF data cubes under memory budgets, in: The Semantic Web – ISWC 2018, Springer International Publishing, Cham, 2018, pp. 547–565. doi:10.1007/978-3-030-00671-6_32.

10.

Galárraga,

K.A.M.

Mathiassen and

Hose, QBOAirbase: The European air quality database as an rdf cube, in: International Semantic Web Conference (Posters, Demos & Industry Tracks), 2017.

11.

Gallinucci,

Golfarelli,

Rizzi,

Abelló and

Romero, Interactive multidimensional modeling of linked data for exploratory olap, Information Systems (2018). doi:10.1016/j.is.2018.06.004.

12.

Gür,

Hose,

T.B.

Pedersen and

Zimányi, Enabling spatial OLAP over environmental and farming data with QB4SOLAP, in: Semantic Technology, Vol. 10055, Springer, 2016, pp. 287–304. doi:10.1007/978-3-319-50112-3_22.

13.

Gür,

Hose,

Zimányi and

T.B.

Pedersen, Modeling and querying spatial data warehouses on the semantic web, in: Semantic Technology, Vol. 9544, Springer, 2015, pp. 1–20. doi:10.1007/978-3-319-31676-5_1.

14.

Gür,

Nielsen,

Hose and

T.B.

Pedersen, GeoSemOLAP: SOLAP on the semantic web made easy, in: Proceedings of the 26th International Conference on World Wide Web, 2017, pp. 213–217. doi:10.1145/3041021.3054731.

15.

Gür,

T.B.

Pedersen,

Zimányi and

Hose, A foundation for spatial data warehouses on the semantic web, Semantic Web Journal9(5) (2018), 557–587. doi:10.3233/SW-170281.

16.

Harth,

Hose and

Schenkel (eds), Linked Data Management, Chapman and Hall/CRC, 2014. doi:10.1201/b16859.

17.

Hartig,

Hose and

J.F.

Sequeda, Linked data management, in: Encyclopedia of Big Data Technologies,

Sakr and

A.Y.

Zomaya, eds, Springer, 2019. doi:10.1007/978-3-319-63962-8_76-1.

18.

Hose and

Schenkel, RDF stores, in: Encyclopedia of Database Systems,

Liu and

M.T.

Özsu, eds, 2nd edn, Springer, 2018. doi:10.1007/978-1-4614-8265-9_80676.

19.

Huang,

S.A.

Raza,

Mirzov and

Harrie, Assessment and benchmarking of spatially enabled RDF stores for the next generation of spatial data infrastructure, ISPRS International Journal of Geo-Information8(7) (2019), 310. doi:10.3390/ijgi8070310.

20.

Hyland and

B.V.

Terrazas, Cookbook for open government linked data, W3C Government Linked Data Working Group, 2011, https://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook.

21.

Ibragimov,

Hose,

T.B.

Pedersen and

Zimányi, Processing aggregate queries in a federation of SPARQL endpoints, in: The Semantic Web. Latest Advances and New Domains – 12th European Semantic Web Conference, ESWC 2015, Portoroz, Slovenia, May 31–June 4, 2015. Proceedings, 2015, pp. 269–285. doi:10.1007/978-3-319-18818-8_17.

22.

Ibragimov,

Hose,

T.B.

Pedersen and

Zimányi, Towards exploratory OLAP over linked open data – a case study, in: Enabling Real-Time Business Intelligence, Springer, 2015, pp. 114–132. doi:10.1007/978-3-662-46839-5_8.

23.

Ibragimov,

Hose,

T.B.

Pedersen and

Zimányi, Optimizing aggregate SPARQL queries using materialized RDF views, in: The Semantic Web: 15th International Semantic Web Conference (ISWC’16), Springer, 2016, pp. 341–359. doi:10.1007/978-3-319-46523-4_21.

24.

Ioannidis,

Garbis,

Kyzirakos,

Bereta and

Koubarakis, Evaluating geospatial RDF stores using the benchmark Geographica 2, 2019, arXiv preprint, https://arxiv.org/abs/1906.01933arXiv:1906.01933.

25.

K.A.

Jakobsen,

A.B.

Andersen,

Hose and

T.B.

Pedersen, Optimizing RDF data cubes for efficient processing of analytical queries, in: COLD, 2015, http://ceur-ws.org/Vol-1426/paper-02.pdf .

26.

Kämpgen and

Harth, No size fits all – running the star schema benchmark with SPARQL and RDF aggregate views, in: Extended Semantic Web Conference, Springer, 2013, pp. 290–304. doi:10.1007/978-3-642-38288-8_20.

27.

Kämpgen,

O’Riain and

Harth, Interacting with statistical linked data via OLAP operations, in: The Semantic Web: ESWC 2012 Satellite Events, Vol. 7540, Springer, 2012, pp. 87–101. doi:10.1007/978-3-662-46641-4_7.

28.

Kyzirakos,

Savva,

Vlachopoulos,

Vasileiou,

Karalis,

Koubarakis and

Manegold, GeoTriples: Transforming geospatial data into RDF graphs using R2RML and RML mappings, Journal of Web Semantics52 (2018), 16–32. doi:10.1016/j.websem.2018.08.003.

29.

Malinowski and

Zimányi, Representing spatiality in a conceptual multidimensional model, in: Proceedings of the 12th Annual ACM International Workshop on Geographic Information Systems, GIS’04, ACM, New York, NY, USA, 2004, pp. 12–22, http://doi.acm.org/10.1145/1032222.1032226 . doi:10.1145/1032222.1032226.

30.

Miles and

Bechhofer, SKOS Simple Knowledge Organization System namespace document, W3C Recommendation, 2009, https://www.w3.org/TR/skos-reference/.

31.

R.P.D.

Nath,

Hose,

T.B.

Pedersen and

Romero, SETL: A programmable semantic extract-transform-load framework for semantic data warehouses, Information Systems68 (2017), 17–43. doi:10.1016/j.is.2017.01.005.

32.

R.P.D.

Nath,

Hose,

T.B.

Pedersen,

Romero and

Bhattacharjee, SETLBI: an integrated platform for semantic business intelligence, in: Companion of the 2020 Web Conference 2020, Taipei, Taiwan, April 20–24, 2020, 2020, pp. 167–171. doi:10.1145/3366424.3383533.

33.

Neumaier and

Polleres, Geo-semantic labelling of open data, SEMANTiCS 2018 – 14th International Conference on Semantic Systems, Procedia Computer Science (2018). doi:10.1016/j.procs.2018.09.002.

34.

Open Geospatial Consortium, GeoSPARQL: A geographic query language for RDF data, W3C Recommendation, 2014.

35.

Patroumpas,

Georgomanolis,

Stratiotis,

Alexakis and

Athanasiou, Exposing INSPIRE on the semantic web, Web Semantics35(P1) (2015), 53–62. doi:10.1016/j.websem.2015.09.003.

36.

Pedersen,

Pedersen and

T.B.

Pedersen, Integrating XML data in the TARGIT OLAP system, in: Proceedings. 20th International Conference on Data Engineering, IEEE, 2004, pp. 778–781. doi:10.1109/ICDE.2004.1320045.

37.

Pedersen,

Riis and

T.B.

Pedersen, Query optimization for OLAP-XML federations, in: Proceedings of the 5th International Workshop on Data Warehousing and OLAP (DOLAP’02), ACM, 2002, pp. 57–64. doi:10.1145/583890.583899.

38.

Rivest,

Bédard,

M.-J.

Proulx,

Nadeau,

Hubert and

Pastor, SOLAP technology: Merging business intelligence with geospatial technology for interactive spatio-temporal exploration and analysis of data, ISPRS Journal of Photogrammetry and Remote Sensing60(1) (2005), 17–33. doi:10.1016/j.isprsjprs.2005.10.002.

39.

Rojas,

Giannopoulos and

J.J.L.

Daniel Hladky, Managing geospatial linked data in the GeoKnow project, in: The Semantic Web in Earth and Space Science. Current Status and Future Directions, Vol. 20, IOS Press, 2015, p. 51. doi:10.3233/978-1-61499-501-2-51.

40.

J.M.

Salas and

Harth, NeoGeo vocabulary specification, GeoVocab Working Group, 2012, http://geovocab.org/doc/neogeo/.

41.

Stadler,

Lehmann,

Höffner and

S.A.

Linkedgeodata, A core for a web of spatial open data, Semantic Web3(4) (2012), 333–354, https://dl.acm.org/doi/10.5555/2590208.2590210 . doi:10.3233/SW-2011-0052.

42.

Vaisman and

Zimányi, Spatial data warehouses, in: Data Warehouse Systems, Springer, 2014, pp. 427–473. doi:10.1007/978-3-642-54655-6.

43.

Varga,

Etcheverry,

A.A.

Vaisman,

Romero,

T.B.

Pedersen and

Thomsen, QB2OLAP: enabling OLAP on statistical linked open data, in: 32nd IEEE International Conference on Data Engineering, 2016, pp. 1346–1349. doi:10.1109/ICDE.2016.7498341.

44.

Varga,

A.A.

Vaisman,

Romero,

Etcheverry,

T.B.

Pedersen and

Thomsen, Dimensional enrichment of statistical linked open data, in: Web Semantics: Science, Services and Agents on the World Wide Web, Vol. 40, Elsevier, 2016, pp. 22–51. doi:10.1016/j.websem.2016.07.003.

45.

Wick and

Vatant, Geo names ontology, GeoNames, 2012, http://www.geonames.org/ontology.

46.

World Wide Web Consortium, SPARQL query language for RDF, W3C Recommendation, 2008, https://www.w3.org/TR/sparql11-query/.

47.

World Wide Web Consortium, Data cube implementations, 2011, https://www.w3.org/2011/gld/wiki/Data_Cube_Implementations.

48.

World Wide Web Consortium, The RDF data cube vocabulary, W3C Recommendation, 2014, https://www.w3.org/TR/vocab-data-cube/.

49.

Yin and

T.B.

Pedersen, Evaluating XML-extended OLAP queries based on physical algebra, Journal of Database Management (JDM)17(2) (2006), 85–116. doi:10.4018/jdm.2006040105.

50.

Zimanyi, Advanced Data Warehouse Design: From Conventional to Spatial and Temporal Applications. Data-Centric Systems and Applications, Springer, 2008. doi:10.1007/978-3-540-74405-4.

Multidimensional enrichment of spatial RDF data for SOLAP

Abstract

Keywords

1. Introduction

2.1. Spatial data warehouses and SOLAP

2 https://www.w3.org/TR/rdf11-primer/

6 Spatial literals are represented as L s .

7 Note that a level member might have the polygon geometry type for the parish borders and the point geometry type for the parish center, therefore a set of spatial values is required.

4.2. Factual enrichment phase

4.2.3. Defining spatial fact DSD

12 Project Page: http://extbi.cs.aau.dk/RDF2SOLAP.

5.1. Experimental setup

5.2. Development time comparison

Table 2 Development times RDF2SOLAP RDBMS GIS General algorithms 1.4 days (one-time) N/A N/A GeoFarmHerdState 5 min (config) 1.3 days 2 days GeoNorthWind 10 min (config) N/A N/A

6. Related work

14 http://www.w3.org/2011/gld/wiki/ISO_Extensions_to_SKOS

Footnotes

Acknowledgements

Implementation details

References

²
https://www.w3.org/TR/rdf11-primer/

⁶
Spatial literals are represented as $L_{s}$ .

⁷
Note that a level member might have the polygon geometry type for the parish borders and the point geometry type for the parish center, therefore a set of spatial values is required.

¹²
Project Page: http://extbi.cs.aau.dk/RDF2SOLAP.

Table 2
Development times

RDF2SOLAP RDBMS GIS

General algorithms 1.4 days (one-time) N/A N/A

GeoFarmHerdState 5 min (config) 1.3 days 2 days

GeoNorthWind 10 min (config) N/A N/A

¹⁴
http://www.w3.org/2011/gld/wiki/ISO_Extensions_to_SKOS