QB4OLAP: a Vocabulary for Business Intelligence over the Semantic Web

Table of Contents

• 1. Introduction
  • 1.1 Why the QB Vocabulary is not enough to publish OLAP data?
  • 1.2 The QB4OLAP Vocabulary
  • 1.3 RDF and Linked Data
  • 1.4 Audience and scope
• 2. OLAP Data Cubes
  • 2.1 OLAP operators
• 3. An example
• 4. Outline of the vocabulary
  • 4.1 Vocabulary index
• 5. Creating data structure definitions
  • 5.1 Levels and rollup hierarchies
  • 5.2 Measures and aggregate functions
  • 5.3 Examples
  • 5.4 Data structure definition
• 6. Dimension instances and datasets
  • 6.1 Level members and rollup relations
  • 6.2 Observations
• 7. OLAP operators over QB4OLAP
• A. Namespaces used in this document
• B. Vocabulary reference
  • B.1 Levels and Level Members
  • B.2 Aggregate Functions
• C. References

1. Introduction

Business intelligence (BI) comprises a collection of techniques used for extracting and analyzing business data, to support decision-making. As part of the BI machinery, On-Line Analytical Processing (OLAP) tools and algorithms allow querying large multidimensional databases called data warehouses (DW).

Since the mid 90's, DW and BI applications have been built to consolidate enterprise business data, allowing taking timely and informed decisions based on these data. The availability of enormous amounts of data from different domains is calling for a shift in the way DW and BI practices are being carried out. It is becoming clear that the traditional approach, where day-to-day business data produced in an organization is collected, cleansed and consolidated in a DW for data analysis, needs to be revised. We believe that the Semantic Web (SW) will most likely be an scenario where OLAP-style data analysis will be crucial in the near future.

Therefore, SW technologies will be needed to model, manipulate, and share multidimensional data. To achieve this, the definition of a precise vocabulary allowing representing adequately OLAP data on the SW is required. Over these vocabulary, multidimensional models and OLAP operators can be defined. The (W3C candidate) Data Cube vocabulary follows a model initially devised for analyzing statistical data, which does not cover all the needs of a vocabulary oriented to support BI analysis on the SW.

The present work is oriented to cover such need. Concretely, we propose the QB4OLAP vocabulary which adds to QB the capability of representing dimension levels, level members, rollup relations between levels and level members, and associating aggregate functions to measures. The QB4OLAP vocabulary is compatible with QB, in the sense that QB4OLAP cube schemas can be built on top of data cube instances (observations) already published using QB. Existing applications, or applications that do not require OLAP style-analysis, can still use the QB schema and instances. Therefore, the cost of adding OLAP capabilities to existing datasets is the cost of building the new schema, in other words, the cost of building the analysis dimensions. Conversely, cubes built over QB4OLAP from scratch can be transformed into QB cubes in order to be exploited by existing applications supporting the latter. As in the case above, the cube instances remain unchanged.

1.1 Why the QB Vocabulary is not enough to publish OLAP data?

Although QB can define the structure of a cube (via the Data Structure Definition), it does not provide a mechanism to represent an OLAP dimension structure (i.e., the dimension levels and the relationships between levels). However, QB allows representing hierarchical relationships between level members in the dimension instances, using the SKOS vocabulary.

Also, the QB vocabulary does not provide direct support for OLAP operations. In spite of this, OLAP operations can be defined over a structure based on QB, although in a limited way. For example, Roll-Up is not supported since dimension levels are not modeled, neither are the aggregate functions for each measure (the latter also prevents support for the Slice operator). The same issues apply to Drill-down. Finally, Dice is partially supported by QB, given that the FO formula σ can only involve cube measures (again, because of the lack of support of dimension levels) It is worth noting that Slices, as defined in QB, represent subsets of observations. Moreover, they are not defined as operators over an existing cube (as in OLAP), but as new structures and new instances (observations) that may be considered as the application of constraints over an existing dataset.

1.2 The QB4OLAP Vocabulary

The QB4OLAP vocabulary proposes to extend QB in order to support the following concepts, defined in classic MD models for OLAP and not modeled in QB:

1. Dimension structure: the structure of a dimension is defined in terms of levels, which are hierarchically organized through rollup relations.
2. Dimension instances: level instances are called level members, and there is a relation between level members from different levels. In QB4OLAP the relationship between level members (from most specific to more general concepts) is modeled using skos:broader property
3. Aggregate functions: aggregate functions are used to compute measure aggregate values when performing OLAP operations (e.g: Roll-Up)

1.3 RDF and Linked Data

1.4 Audience and scope

2. OLAP Data Cubes

2.1 OLAP operators

A well-known set of operations is defined over cubes. We present some of these operations next. They are based on the recently proposed Cube Algebra [CA].

Roll-Up summarizes data at a higher level in a dimension hierarchy. It receives a cube C , a dimension D ∈ C , a dimension level l_u ∈ D such that l_l →∗ l_u , and a set of aggregate functions f , Roll-Up(C, D, l_u, f) returns a new cube C′ where measures are aggregated along D up to the level l_u. Analogously, Drill-Down disaggregates previously summarized data, and can be considered the inverse of Roll-Up. Note that this requires to store the aggregation path.

Slice receives a cube C,and a dimension D ∈ C, and removes D from the cube. Measure values in the cube are aggregated along dimension D up to level 'All' before removing the dimension, using the aggregate functions associated with each measure.

Dice receives a cube C , and a first order formula σ over measures and levels in C, and returns a new cube C′ such that the elements in C′ are the ones that satisfy σ.

3. An example

In order to illustrate the use of the QB4OLAP vocabulary we present a small example, extracted from StatsWales report number 028727 and Household projections by district, England, 1991-2033, which contains household projections (in thousands) by district in the UK. We want to analyze the household projection (a measure) along the dimensions geographic location and date. Let us call these dimensions geoDim and dateDim, respectively. Dimension geoDim is organized in a hierarchy of levels: Unitary Authority (UA), Government Office Region (GOR) and Country, while dimension dateDim has only one level: year. We can build an OLAP cube householdCS with who dimensions (geoDim and dateDim) and one measure (household). The following table shows a small instance of the cube householdCS.

OLAP operators can be applied to these data. For example, we would like to obtain the total household for each Government Office Region in each year. This corresponds to the application of the Roll-Up operator on the geoDim dimension, up to the GOR level. The aggregate function to compute the values is associated with each measure in the schema definition, in this case the sum function, and it is used to compute the household projection for each GOR. The table below shows the results of applying the Roll-Up operator.

4. Outline of the vocabulary

The following picture shows classes, properties and instances in the QB4OLAP vocabulary (grey background). Classes and properties from QB are also included (white background).

5. Creating data structure definitions

As in QB, QB4OLAP uses the qb:DataStructureDefinition class to define the structure of data sets. While in QB the structure of a data set is defined in terms of dimensions, measures and attributes, in QB4OLAP the structure is defined using levels, measures and attributes. The declaration of the structure of the data set has several benefits, some of them where already presented in [QB]:

• to assist in the integration process of different data sets
• to provide a self-contained description of the contents of the data set, which allows for example to implement client applications and operators
• to enable the verification that the data set instances match the expected structure

eg:geoDim a qb:DimensionProperty. 

eg:unitaryAuthority a qb4o:LevelProperty; 
  qb4o:inDimension eg:geoDim; 
  qb4o:parentLevel eg:governmentOfficeRegion;
  skos:closeMatch adgeo:UnitaryAuthority. 

eg:governmentOfficeRegion a qb4o:LevelProperty; 
  qb4o:inDimension eg:geoDim; 
  qb4o:parentLevel eg:country;
  skos:closeMatch adgeo:GovernmentOfficeRegion.

eg:country a qb4o:LevelProperty; 
  qb4o:inDimension eg:geoDim; 
  skos:closeMatch adgeo:CountryInUk. 

	
eg:dateDim a qb4o:DimensionProperty. 

eg:year a qb4o:LevelProperty; 
  qb4o:inDimension eg:dateDim;
  skos:closeMatch db:Year.

	 
eg:household a qb:MeasureProperty;
  skos:closeMatch db:Household.

eg:householdCS a qb:DataStructureDefinition; 
  qb:component [qb4o:level eg:unitaryAuthority]; 
  qb:component [qb4o:level eg:year]; 
  qb:component [qb:measure eg:household; qb4o:hasAggregateFunction qb4o:sum].

6. Dimension instances and data sets.

ns0:00mc qb4o:inLevel eg:unitaryAuthority; 
 rdfs:label "The Borough of Reading@en"; 
 skos:broader ns1:J. 

ns1:J qb4o:inLevel eg:governmentOfficeRegion; 
 rdfs:label "South East@en" ; 
 skos:broader ns2:921. 

ns2:921 qb4o:inLevel eg:country; 
 rdfs:label "England@en". 

eg:dataset_hh a qb:DataSet; 
  rdfs:label "Household in UK"@en; 
  qb:structure eg:householdCS. 

eg:o1 a qb:Observation; 
  qb:dataSet eg:dataset_hh ; 
  eg:unitaryAuthority ns0:00mc ; 
  eg:year db:2007; 
  eg:household 58.

7. OLAP operators over QB4OLAP

OLAP operators can be implemented over cubes specified using QB4OLAP vocabulary as SPARQL 1.1 queries. Moreover, provided that the vocabulary models all the structural metadata of the cube (namely: levels, level member, their relationship, rollup relations between level members, hierarchical relationships between levels, aggregate functions and their relationship with measures), these SPARQL queries can be automatically generated.

Since OLAP cubes are represented as RDF graphs, and the result of any OLAP operator must be also a cube, OLAP operators have to be implemented as SPARQL CONSTRUCT queries. Below we present, as an example, the SPARQL query that implements the Roll-Up operator which result was presented in Section 3.

CONSTRUCT { 
	?id a qb:Observation . 
	?id qb:dataSet  eg:dataset-hh1 . 
	?id eg:year ?year .
	?id eg:governmentOfficeRegion ?gor . 
	?id eg:household ?sumHhold } 
WHERE{{ 
	SELECT	?gor ?year (SUM(?hhold) AS ?sumHhold) 
    		(iri(fn:concat("http://example.org/hhold#", "hholdGOR","_",
     		fn:substring-after(?gor,"http://example.org/hhold#"),"_",
     		fn:substring-after(?year,"http://example.org/hhold#"))) AS ?id)
	WHERE { 
		?o qb:dataSet  eg:dataset-hh . ?o eg:year ?year .
		?o eg:household ?hhold . ?o eg:unitaryAuthority ?ua . 
		?ua skos:broader ?gor . ?gor qb4o:inLevel eg:governmentOfficeRegion }
	GROUP BY ?gor ?year}}

A. Namespaces used in this document

B. Vocabulary reference

C. References