Dimensional enrichment of statistical linked open data

Dimensional Enrichment of Statistical Linked Open Data Jovan Vargaa, Alejandro A. Vaismanb, Oscar Romeroa, Lorena Etcheverryc, Torben Bach Pedersend, Christian Thomsend aUniversitat Polit`ecnica de Catalunya, BarcelonaTech, Jordi Girona 1-3, Barcelona, Spain bInstituto Tecnol´ogico de Buenos Aires, 25 de Mayo 457, Buenos Aires, Argentina cInstituto de Computaci´on, Facultad de Ingenier´ıa, UdelaR, Ave Julio Herrera y Reissig 565, Montevideo, Uruguay dAalborg Universitet, Selma Lagerl¨ofs Vej 300, Aalborg, Denmark Abstract On-Line Analytical Processing (OLAP) is a data analysis technique typically used for local and well-prepared data. However, initiatives like Open Data and Open Government bring new and publicly available data on the web that are to be analyzed in the same way. The use of semantic web technologies for this context is especially encouraged by the Linked Data initiative. There is already a considerable amount of statistical linked open data sets published using the RDF Data Cube Vocabulary (QB) which is designed for these purposes. However, QB lacks some essential schema constructs (e.g., dimension levels) to support OLAP. Thus, the QB4OLAP vocabulary has been proposed to extend QB with the necessary constructs and be fully compliant with OLAP. In this paper, we focus on the enrichment of an existing QB data set with QB4OLAP semantics. We first thoroughly compare the two vocabularies and outline the benefits of QB4OLAP. Then, we propose a series of steps to automate the enrichment of QB data sets with specific QB4OLAP semantics; being the most important, the definition of aggregate functions and the detection of new concepts in the dimension hierarchy construction. The proposed steps are defined to form a semi-automatic enrichment method, which is implemented in a tool that enables the enrichment in an interactive and iterative fashion. The user can enrich the QB data set with QB4OLAP concepts (e.g., full-fledged dimension hierarchies) by choosing among the candidate concepts automatically discovered with the steps proposed. Finally, we conduct experiments with 25 users and use three real-world QB data sets to evaluate our approach. The evaluation demonstrates the feasibility of our approach and shows that, in practice, our tool facilitates, speeds up, and guarantees the correct results of the enrichment process. Keywords: Linked Open Data, Multidimensional Data Modeling, OLAP, Semantic Web 1. Introduction On-Line Analytical Processing (OLAP) is a wellestablished approach for data analysis to support decision making that typically relates to Data Warehouse (DW) systems. It is based on the multidimensional (MD) model which places data in an n-dimensional space, usually called a data cube. In this way, a user can analyze data along several dimensions of interest. For instance, a user can analyze sales data according to time and location (dimensions). The simplicity of the10 MD model specially fits the business users who navigate and analyze the MD data by means of OLAP operations (typically via a graphical user interface). ∗Corresponding author A large number of MD models in the literature are based on the data cube metaphor [1,2,3]. Historically, DW and OLAP have been used as techniques for data analysis within an organization, using mostly commercial tools with proprietary formats. However, initiatives like Open Data1and Open Government2are pushing organizations to publish MD data using standards and20 non-proprietary formats. Although several open source platforms for business intelligence (BI) have emerged in the last decade, an open format to publish and share cubes among organizations is still missing. The Linked Data [4] initiative promotes sharing and reusing data on the web using semantic web (SW) standards and domain ontologies expressed in the Resource Description 1http://okfn.org/opendata/ 2http://opengovdata.org/ Email address: [email protected] (Jovan Varga) Framework (RDF) as the basic data representation layer for the SW [5], or in languages built on top of RDF (e.g., RDF-Schema [6] and OWL3).30 Two main approaches can be found in the literature concerning OLAP analysis of SW data. The first one consists in extracting MD data from the web and loading them into traditional data management systems for OLAP analysis. The second one explores data models and tools that allow publishing and performing OLAP analysis directly over MD data on the SW. We discuss both approaches in detail in Section 7and in this paper we follow the second one. Statistical data sets on the SW are usually published40 using the RDF Data Cube Vocabulary4(also denoted QB), the current W3C standard. There is already a considerable amount of data sets published using QB. However, as we explain later, QB lacks (among other shortcomings) the structural metadata needed to automate the translation of OLAP operations into the underlying technology storing the MD data. For example, DWs have been typically implemented using relational technology and the definition of a well-formed MD schema allows the automatic translation of OLAP50 operations into SQL queries. To address this challenge, a new vocabulary, denoted QB4OLAP, has been proposed [7]. QB4OLAP allows reusing data already published in QB just by adding the needed MD schema semantics (e.g., the hierarchical structure of the dimensions) and the corresponding instances that populate the dimension levels. Thus, the main task that we address in this paper is the enrichment of an existing QB data set with additional QB4OLAP semantics. Once a data cube is published using QB4OLAP, users will be able60 to operate over it, not only through queries written in SPARQL [8] (the standard query language for RDF), but also by using a high-level OLAP query language [9]. Such a language allows OLAP users to query data cubes directly on the SW, without any knowledge of SPARQL or RDF, since OLAP queries and operations can be automatically translated into SPARQL, taking advantage of the structural metadata provided by QB4OLAP5. In addition, a language like this makes it easier to develop graphic tools, typically used to exploit data cubes.70 Enriching an existing QB data set with QB4OLAP semantics implies a labor-intensive, repetitive, and errorprone task. Thus, it must be performed as automatically as possible. For instance, hierarchical structures of the 3http://www.w3.org/TR/owl2-overview/ 4http://www.w3.org/TR/vocab-data-cube/ 5A prototype is available at http://www.fing.edu.uy/inco/ grupos/csi/apps/qb4olap/ dimensions can be discovered from the source data and metadata, and from external data. Once discovered, the structure must be populated with the members of hierarchy levels. In this paper, we present a method and a tool to facilitate the enrichment process. The method minimizes the user effort, by automatically detecting80 new potential semantics and performing otherwise timeconsuming tasks, leaving to the user the task of providing the MD semantics that cannot be inferred. Contributions. Our main contributions are: •An in-depth comparison between the QB and QB4OLAP vocabularies, outlining the novel benefits of the latter. •Techniques to automate (a) the association between measures and aggregate functions, by means of metadata; and (b) the discovery of dimension hierarchy90 schema and instances, based on an algorithm that detects implicit MD semantics. •A method defining the steps described as SPARQL queries to semi-automatically enrich data already published in QB with dimensional (meta)data compliant with the QB4OLAP vocabulary. •QB2OLAPem, a tool that in an iterative fashion implements the method and the algorithm for the detection of implicit MD semantics. The tool enables the user to semi-automatically produce a QB4OLAP description100 of a QB data cube with minimal manual effort. •An evaluation of our approach based on the experiments conducted with 25 user and the use of three realworld QB data sets. The evaluation shows that our approach is feasible and that, in practice, QB2OLAPem reduces the enrichment time and user efforts and guarantees that the QB4OLAP schema created is correct. The remainder of the paper is organized as follows. Section 2explains the basic concepts used throughout the paper. Section 3discusses the limitations of the110 QB vocabulary, with respect to its capability to represent MD data. This section also presents the QB4OLAP vocabulary, which addresses these limitations. Section 4studies the automation challenges and provides possible solutions for the two most important ones. Section 5describes the proposed enrichment method while Section 6presents the approach evaluation. Finally, Section 7discusses related work and we conclude in Section 8. 2. Preliminaries In this section we present the basic concepts on120 OLAP and SW data models followed by a detailed elaboration on QB based on the running example used throughout the paper. 2 2.1. OLAP In OLAP, data are organized as hypercubes whose axes are called dimensions. Each point in this MD space is mapped into one or more spaces of measures, representing facts that are analyzed along the cube’s dimensions. Dimensions are structured in hierarchies that allow analysis at different aggregation levels. The actual130 values in a dimension level are called members. A Dimension Schema is composed of a non-empty finite set of levels. We denote ‘→’ a partial order on these levels, with a unique bottom, and a unique top, the latter being a distinguished level denoted All, whose only member is called all. We denote ‘→∗’ the reflexive and transitive closure of ‘→’. Levels can have attributes describing them. A Dimension Instance assigns a set of dimension members to each dimension level in the dimension schema. For each pair of levels (lj,lk) in the dimension140 schema, such that lj→lk, a relation (denoted rollup) is defined, associating members from level ljwith members of level lk. In a rollup relationship, ljis called the child level and lkthe parent level. In practice, to guarantee the correct aggregation of the measure values, rollup relations actually become functions. Cardinality constraints on these relations are then used to restrict the number of level members related to each other [10]. A Cube Schema is defined by a set of dimensions and a set of measures, and for each measure a default aggregate150 function is specified. Each dimension is represented by a level, defining the granularity of the cube. The cube composed by the bottom levels of each dimension is called a base cube. All other cubes are called cuboids. ACube Instance, corresponding to a cube schema, is a partial function mapping coordinates from dimension instances (at the cube’s granularity level) into measure values. A well-known set of operations can be defined over cubes [11]. For example, given a cube C, a dimension160 D∈ C, dimension levels ll,lu∈Dsuch that ll→∗lu, and an aggregate function Fagg,RollUp(C,D,lu,Fagg) returns a new cube where measure values are aggregated along D, from the current level llup to a level lu, using Fagg. Analogously, DrillDown(C,D,ll,Fagg) disaggregates previously summarized data, from the current level ludown to a level lland can be considered the inverse of RollUp. Note that we do not need to use the starting levels as parameters of these operations, because we assume that they are applied over the ‘current’170 aggregation level of the cube, thus they would be redundant, since the cube ‘knows’ the current aggregation level for dimension D.Slice(C,D,Fagg) receives a cube C, a dimension D∈ C, and an aggregate function Fagg, and returns a new cube, with the dimension Dremoved from the original schema, such that measure values are aggregated along Dup to level All before removing the dimension, using Fagg. Note that in all cases, Fagg could be omitted if the default aggregate function is used. Finally, given a cube C, and a first order formula180 σover levels and measures in C,Dice(C, σ) returns a new cube with the same schema, and whose instances are the instances in Cthat satisfy σ. For example, given aSales data cube, with dimensions Time and Location, the query “Total sales by region, in December 2015” can be expressed with the following sequence of operations: C1 :=Dice(Sales,Time.month =”12 −2015”); C2 :=Rollup(C1,Location,Location.region). The first operation takes as input the Sales data cube, and produces another data cube C1, whose cells contain only190 sales data corresponding to December, 2015; C1 is then summarized by geographical region. 2.2. RDF and the Semantic Web The basic construct of RDF is a triple, of the (s,p,o) form, where sstands for subject,pfor predicate, and o for object. In general, s,p, and oare resources, identified with internationalized resource identifiers (IRIs). An object can also be a data value, denoted a literal in RDF, or a blank node, typically used to represent anonymous resources. Subjects can also be represented by200 blank nodes. A set of RDF triples is called an RDF graph. An RDF data set is a collection of RDF graphs, comprising one default RDF graph with no name, and zero or more named graphs (a named graph is a graph with a name, typically an IRI or a blank node). Graph names must be unique within an RDF data set. In addition, the RDF Schema (RDF-S) [6] is composed by a set of reserved keywords which define classes, properties, and hierarchical relationships between them. For example, the triple (r, rdf:type, c) ex-210 plicitly states that ris an instance of c, and it also implicitly states that object cis an instance of rdfs:Class. Many formats for RDF serialization exist. In this paper we use Turtle [12]. SPARQL 1.1 [8] is the W3C standard query language for RDF. The query evaluation mechanism of SPARQL is based on subgraph matching: RDF triples are interpreted as nodes and edges of directed graphs, and the query graph is matched to the data graph, instantiating the variables in the query graph definition. The selec-220 tion criteria is expressed as a graph pattern in the WHERE clause. Relevant to OLAP queries, SPARQL 1.1 supports aggregate functions and the GROUP BY clause, a feature not present in previous versions. 3 From here on we assume that the reader is familiar with RDF and SPARQL concepts. 2.3. QB: The RDF Data Cube Vocabulary As mentioned before, QB is the W3C recommendation to publish statistical data and metadata in RDF. QB is based on the main components of the SDMX in-230 formation model [13], proposed by the Statistical Data and Metadata eXchange initiative (SDMX)6for the publication, exchange, and processing of statistical data. The elements with white background in Figure 1depict the QB vocabulary. Capitalized terms represent RDF classes and non-capitalized terms represent RDF properties. Capitalized terms in italics represent classes with no instances. An arrow with black triangle head from class Ato class B, labeled rel means that rel is an RDF property with domain Aand range B. White triangles240 represent sub-classes or sub-properties. The range of a property can also be denoted using “:”. For better comprehension, we next introduce the running example that is used to explain the QB elements and then followed throughout the paper. We use data published by the World Bank7, a financial institution supporting developing countries, basically through loans for strategic projects. Free and open access to data about these countries is provided through the World Bank Open Data (WBOD), that includes a250 collection of indicators8measured for different countries and regions across time. Data are available in tabular, RDF, and many other formats depending on the particular portion of the data set. World Bank Linked Data (WBLD) is a Linked Data data set created from WBOD data via its rdf-ization (where needed) and it is annotated with the QB vocabulary. The WBLD is organized in four subsets, stored in different files, including demographic and financial indicators, projects and operations, and climate data. Additionally, there260 is a VoiD9file which contains metadata that describe the data sets. Moreover, a SPARQL endpoint10 is also available to query the WBLD. Our running example is based on the “Market capitalization of listed companies (current US$)” indicator (CM.MKT.LCAP.CD)11, where market capitalization refers to the share price 6http://SDMX.org 7http://www.worldbank.org 8http://data.worldbank.org/indicator 9http://semanticweb.org/wiki/VoID 10http://worldbank.270a.info/sparql 11http://data.worldbank.org/indicator/CM.MKT.LCAP. CD times the number of shares outstanding. Each indicator is provided as a QB data set, i.e., as an instance of the class qb:DataSet. The schema of a QB data set is specified by means of270 the data structure definition (DSD), an instance of the class qb:DataStructureDefinition. This specification is composed of a set of component properties, instances of subclasses of the qb:ComponentProperty class, representing dimensions,measures, and attributes. Component properties are not directly related to the DSD: the qb:ComponentSpecification class is an intermediate class typically instantiated as RDF blank nodes, that allows specifying additional attributes for a component in a DSD (e.g., a compo-280 nent may be tagged as required (i.e., mandatory), using the qb:componentRequired property). The different components that belong to a component specification are linked using specific properties that depend on the type of the component: qb:dimension for dimensions, qb:measure for measures, and qb:attribute for attributes. Component specifications are linked to DSDs via the qb:component property. Note that a DSD can be shared by different QB data sets (and each QB data set is linked to its DSD) by means of the qb:structure290 property. Example 1below presents the triples that represent the DSD of our running example. Example 1. The DSD of the running example is defined in the file meta.rdf12 and looks as follows. 1@prefix qb: <http://purl.org/linked−data/cube#>. 2@prefix xsd: <http://www.w3.org/2001/XMLSchema#>. 3@prefix sdmx−dimension: <http://purl.org/linked−data/sdmx/2009/dimension#>. 4@prefix sdmx−measure: <http://purl.org/linked−data/sdmx/2009/measure#>. 5300 6<http://worldbank.270a.info/dataset/world−bank−indicators/structure> 7a qb:DataStructureDefinition ; 8qb:component [ 9a qb:ComponentSpecification ; 10 qb:dimension <http://worldbank.270a.info/property/indicator>; 11 qb:order ”1”ˆˆxsd:int], 12 [ 13 a qb:ComponentSpecification ; 14 qb:dimension sdmx−dimension:refArea ; 15 qb:order ”2”ˆˆxsd:int],310 16 [ 17 a qb:ComponentSpecification ; 18 qb:dimension sdmx−dimension:refPeriod ; 19 qb:order ”3”ˆˆxsd:int], 20 [ 21 a qb:ComponentSpecification ; 22 qb:measure sdmx−measure:obsValue ; 23 qb:order ”4”ˆˆxsd:int] . This DSD is composed of three dimensions: <http: //320 worldbank. 270a. info/ property/ indicator> (lines 911), representing an indicator, sdmx-dimension:refArea (lines 13-15) which represents the geographical reference 12http://worldbank.270a.info/data/meta/meta.rdf 4 qb:DataStructureDefinition qb:DataSet qb:Observation qb:Slice qb:SliceKey qb:AttributeProperty qb:MeasureProperty qb:CodedProperty skos:ConceptScheme sdmx:Collection skos:Concept qb:codeList qb:sliceKeyqb:structure qb:dataSet qb:observation qb:sliceStructureqb:slice qb:componentProperty qb:concept qb:ComponentProperty qb:componentProperty qb:subSlice qb4o:LevelMember qb4o:AggregateFunction qb4o:memberOf skos:broader qb:HierarchicalCodeList <<union>> qb:DimensionProperty qb4o:inLevel qb4o:hasHierarchy qb4o:inDimension qb:component qb4o:Cardinality qb:ComponentSpecification qb:componentRequired:boolean qb:componentAttachment:rdfs:Class qb:order: xsd:int qb4o:LevelAttribute qb4o:pcCardinality qb4o:HierarchyStep qb4o:childLevel qb4o:parentLevel qb:dimension qb:attribute qb:measure qb4o:level qb4o:cardinality qb4o:aggregateFunction qb4o:hasAttribute qb4o:isCuboidOf qb4o:OneToOne qb4o:OneToMany qb4o:ManyToOne qb4o:ManyToMany qb4o:Avg qb4o:Count qb4o:Min qb4o:Max qb4o:Sum Class Instance Object property Subclass of Instance of LEGEND qb4o:LevelProperty qb4o:Hierarchy qb4o:inHierarchy qb4o:hasLevel sdmx:Concept sdmx:ConceptRole sdmx:FrequencyRole sdmx:CountRole sdmx:EntityRole sdmx:TimeRole sdmx:MeasureTypeRole sdmx:NonObsTimeRole sdmx:IdentityRole sdmx:PrimaryMeasureRole Figure 1: QB (cf. [14]) and QB4OLAP vocabularies area, and sdmx-dimension:refPeriod (lines 17-19) which represents the time period. The measure of the data set is the generic sdmx-measure:obsValue predicate (lines 21-23). Instances of the running example data set are described in an RDF graph contained in the file CM.MKT.- LCAP.CD.rdf.13 Such instances are called observations in the QB vocabulary. Observations (in OLAP ter-330 minology, facts) are instances of the qb:Observation class and represent points in an MD data space indexed by dimensions. They are associated with data sets (instances of the qb:DataSet class), through the qb:dataSet property. Each observation can be linked to a value in each dimension of the DSD via instances of the qb:DimensionProperty class; analogously, values for each observation are associated to measures via instances of the qb:MeasureProperty class; and instances of the qb:AttributeProperty class are used340 to associate attributes to observations. Example 2below presents the triples of an observation from our running example. Example 2. The triples representing an observation corresponding to the market capitalization for Serbia in 2012 (we do not repeat prefixes previously defined). 13http://worldbank.270a.info/data/ world-development-indicators/CM.MKT.TRAD.CD.rdf 1@prefix property: <http://worldbank.270a.info/property/>. 2@prefix indicator: <http://worldbank.270a.info/classification/indicator/>. 3@prefix country: <http://worldbank.270a.info/classification/country/>.350 4@prefix year: <http://reference.data.gov.uk/id/year/>. 5 6<http://worldbank.270a.info/dataset/world−bank−indicators/ 7CM.MKT.LCAP.CD/RS/2012>a qb:Observation ; 8qb:dataSet <http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>; 9property:indicator indicator:CM.MKT.LCAP.CD ; 10 sdmx−dimension:refArea country:RS ; 11 sdmx−dimension:refPeriod year:2012 ; 12 sdmx−measure:obsValue 7450560827.04874 . 360 Note that each of the RDF properties defined as components of the data set DSD (Example 1) is used here to link the observation with either dimension members or measure values. In particular, the recorded value for CM.MKT.LCAP.CD indicator is linked to the observation via the sdmx-measure:obsValue predicate (line 12), and the semantics of this measure is given by the indicator linked to the observation via the property:indicator predicate (line 9). To give further semantics to the components of a DSD, they may be associated with concepts in an on-370 tology. For this, we can make use of the property qb:concept, to link components in a DSD, with instances of the class skos:Concept defined in the SKOS vocabulary.14 More specifically, this property can be used to link component properties (i.e., dimensions or 14http://www.w3.org/TR/skos-reference/ 5 measures), with standard concepts defined in the SDMX guidelines (e.g., reference area, frequency, etc.) [15]. We illustrate this in Example 3below, to define the dimension sdmx-dimension:refPeriod. Example 3. An excerpt of the triples that define the di-380 mension sdmx-dimension:refPeriod, and associate it with the SDMX concept sdmx-concept:refPeriod (a SKOS concept) are shown below. 1@prefix sdmx−concept: <http://purl.org/linked−data/sdmx/2009/concept#>. 2@prefix sdmx−dimension: <http://purl.org/linked−data/sdmx/2009/dimension#>. 3@prefix qb: <http://purl.org/linked−data/cube#>. 4 5sdmx−dimension:refPeriod a qb:DimensionProperty, rdf:Property ; 6rdfs:range rdfs:Resource;390 7qb:concept sdmx−concept:refPeriod ; 8rdfs:label ”Reference Period”@en ; 9rdfs:comment ”””The period of time or point in time to which the 10 measured observation is intended to refer.”””@en . 11 12 sdmx−concept:refPeriod a sdmx:Concept, skos:Concept ; 13 rdfs:label ”Reference Period”@en ; 14 rdfs:comment ”””The period of time or point in time to which the 15 measured observation is intended to refer.”””@en; 16 skos:inScheme sdmx−concept:cog .400 Linking the dimension sdmx-dimension:refPeriod with the concept sdmx-concept:refPeriod (line 7) allows to give semantics to this dimension. Finally, slices, as defined in QB, represent subsets of observations, not as operators over an existing cube, but as new structures and new instances (observations) in which one or more values of dimension members are fixed. The structure of a slice is defined using a DSD and an instance of the qb:SliceKey class. The class410 qb:Slice allows grouping the observations that correspond to a particular slice (using the qb:observation property) and the structure of each slice is attached using the qb:sliceStructure property. 3. Representing Multidimensional Data in RDF Although appropriate to represent and publish statistical data, QB has a set of limitations when it comes to represent an MD model for OLAP. Thus, in this section we elaborate on these limitations of QB, introduce the QB4OLAP vocabulary that extends QB with the nec-420 essary concepts, discuss some QB4OLAP design decisions, and provide hints about the use of QB4OLAP.15 15Parts of the material in this section have previously appeared in [7,16]. However, the content of [7] have been updated and now refer to newer versions of QB4OLAP. Further, the examples based on WBLD are new. Finally, we remark that [16] is a tutorial on QB4OLAP, produced for the 2015 edition of the Business Intelligence Summer School. 3.1. Limitations of QB Lack of support for an OLAP dimension structure. Although QB allows representing hierarchical relationships between level members in the dimension instances, it does not provide a mechanism to represent an OLAP dimension structure (i.e., the dimension levels and the relationships between levels). That means, QB allows stating that Serbia is a narrower concept than Eu-430 rope, but not that Serbia is a Country, Europe is a Continent, and that countries aggregate to continents. To represent hierarchical relationships between dimension members, the semantic relationship skos:narrower should be used, with the following meaning: If two concepts Aand Bare such that A skos:narrower B,B represents a narrower concept than A(e.g., continent skos:narrower country). Additional information that can be used to build dimension instances is scattered across many graphs. For440 example, we can obtain information about country:RS (Serbia) from the graph in the file countries.rdf.16 Example 4shows the triples that can be obtained about Serbia. Example 4. The triples about the dimension member Serbia, obtained from countries.rdf. 1@prefix skos: <http://www.w3.org/2004/02/skos/core#>. 2@prefix dbpedia: <http://dbpedia.org/resource/>. 3@prefix geo: <http://www.w3.org/2003/01/geo/wgs84 pos#>.450 4@prefix foaf: <http://xmlns.com/foaf/0.1/>. 5@prefix dcterms: <http://purl.org/dc/elements/1.1/>. 6@prefix region: <http://worldbank.270a.info/classification/region/>. 7@prefix income: <http://worldbank.270a.info/classification/income−level/>. 8@prefix lending: <http://worldbank.270a.info/classification/lending−type/>. 9 10 <http://worldbank.270a.info/classification/country>skos:hasTopConcept 11 country:RS . 12 13 country:RS460 14 a skos:Concept, <http://dbpedia.org/ontology/Country>; 15 skos:inScheme <http://worldbank.270a.info/classification/country>; 16 skos:topConceptOf <http://worldbank.270a.info/classification/country>; 17 skos:notation ”RS” ; 18 skos:exactMatch country:SRB ; 19 skos:prefLabel ”Serbia”@en ; 20 property:region region:ECS ; 21 property:admin−region region:ECA ; 22 property:income−level income:UMC ; 23 property:lending−type lending:IBD ;470 24 dbpedia:capital ”Belgrade”@en ; 25 geo:lat ”20.4656”ˆˆxsd:float ; 26 geo:long ”44.8024”ˆˆxsd:float ; 27 foaf:page <http://data.worldbank.org/country/RS>; 28 ... 29 dcterms:created ”2012−02−29T00:00:00Z”ˆˆxsd:dateTime ; 30 dcterms:issued ”2013−11−04T13:37:18Z”ˆˆxsd:dateTime . 31 32 country:SRB skos:exactMatch country:RS ; skos:notation ”SRB” . 480 16http://worldbank.270a.info/data/meta/countries. rdf 6 Some of the triples provide information that can be used to define dimension hierarchies, when producing the QB4OLAP representation. Line 14 states that country:RS is a country as it says that this IRI is of type <http://dbpedia.org/ontology/Country>. Lines 20 and 21 state that Serbia belongs to two different regions17: region:ECS (Europe &Central Asia (all income levels)) and region:ECA (Europe &Central Asia (developing only)), respectively. Lines 22 and 23 provide information about the income level and the type of lending Serbia is eligible for, re-490 spectively.18 We have said that a typical OLAP user explores data, e.g., performing aggregations along dimension hierarchies. For example, she would like to compute the total capitalization by region, income level, or lending type, given that these data are available in the data set, as Examples 1through 4show. However, we can also see that these data are given at the instance level, that means, no hierarchical structure is defined for the refArea dimension. This is because QB does not allow to define500 aggregation paths. Nevertheless, it is clear that from the information available, we could infer and build a dimension hierarchy. A possible structure for a geographical dimension (like refArea) is shown in Figure 2. We can see that there are five levels, namely country (i.e., intial refArea), region,lending-type,income, and, following traditional MD design, a distinguished level All which has only one level member, denoted all. These levels are organized into three hierarchies: a geographical hierarchy country →region →All, a lending type hierarchy510 country →lending-type →All, and an income hierarchy country →income →All. Lack of support for aggregate functions. QB does not provide native support to represent aggregate functions. Many OLAP operations change the granularity level of the data represented in a data cube (e.g., a rollup over the Time dimension from the Month level up to the Year level). This involves aggregating measure values along dimensions, using the aggregate function defined for each measure. These aggregate functions depend on520 the nature of the measure (i.e., additive, semi additive, non additive [10]). The ability to link each measure with an aggregate function is therefore crucial and, although present in OLAP tools, it is not considered in QB. 17http://worldbank.270a.info/classification/region 18These concepts are defined in http://worldbank. 270a.info/classification/income-level and http: //worldbank.270a.info/classification/lending-type. country region lending-type income all Figure 2: Dimension levels and hierarchies with bottom level country. Lack of support for descriptive attributes. In the MD model, the instances (members) of each dimension level usually contain a set of real-world concepts with similar characteristics. Further, the schema of each level is composed of a set of attributes that describe the characteristics of their members (e.g., the level country may530 have the attributes countryName,surface, etc.) and one or more identifiers [10]. QB does not provide a mechanism to associate a set of attributes with a dimension level. This affects the expressiveness and efficiency of some OLAP operations, in particular, Dice, which filters a cube according to a Boolean condition. For example, to obtain a cube containing just data about Serbia, without descriptive attributes we would need to filter such data using the IRI representing Serbia, instead of the proper string. This would not only be unnat-540 ural for a user, but also highly inefficient. Note that the qb:AttributeProperty class, used in QB to associate attributes to observations as mentioned before, differs from descriptive level attributes as defined in QB4OLAP, and cannot be used in the way explained in the example above. Section 3.4 illustrate the use of descriptive attributes in a Dice operation. 3.2. The QB4OLAP Vocabulary QB4OLAP19 extends QB with a set of RDF terms and the rationale behind QB4OLAP includes:550 •QB4OLAP must be able to represent the most common features of the MD model. The features considered are based on the MultiDim model [10]. •QB4OLAP must allow to operate over already published observations which conform to DSDs defined in QB, without the need of rewriting the existing observations. Note that in a typical MD model, observations 19http://purl.org/qb4olap/cubes 7 are the largest part of the data while dimensions are usually orders of magnitude smaller. •QB4OLAP must include all the metadata needed to560 automatically generate SPARQL queries implementing OLAP operations. In this way, OLAP users do not need to know SPARQL (which is the case of typical OLAP users) and even wrappers for OLAP tools can be developed to query RDF data sets directly (we give an example of this in Section 3.4). The elements with gray background in Figure 1depict the QB4OLAP vocabulary. Moreover, original QB terms are prefixed with “qb:”; QB4OLAP terms are prefixed with “qb4o:”. In addition to the QB570 graphical notation, QB4OLAP introduces ellipses representing class instances and dashed arrows representing rdf:type relationships. As already mentioned, dimension hierarchies and levels are first-class citizens in an MD model for OLAP. Therefore, QB4OLAP focuses on their representation and several classes and properties are introduced to this end. QB4OLAP represents the structure of a data set in terms of levels and measures, instead of dimensions and measures (which is the case of QB), thus allowing us to580 specify the granularity level considered for each dimension. Dimension levels are represented in QB4OLAP in the same way that QB represents dimensions: as classes of properties. The class qb4o:LevelProperty represents dimension levels. Declaring it as a subclass of qb:ComponentProperty allows specifying the schema of the cube in terms of dimension levels, using qb:DataStructureDefinition. To represent aggregate functions the class qb4o:AggregateFunction can be used. The property qb4o:aggregateFunction590 associates measures with aggregate functions, and, together with the concept of component sets, allows a given measure to be associated with different aggregate functions in different cubes. Given the structure described above, in QB4OLAP, fact instances (observations) map level members to measure values. It is also worth noting that, in general, each fact is related with at most one level member, for each level that participates in the fact. However, there are cases where this restriction does not hold, yielding so-called many-to-many di-600 mensions [10]; thus, to support these dimensions, the property qb4o:cardinality can be used to represent the cardinality of the relationship between a fact and a level. Example 5shows how the cube in our running example would look like in QB4OLAP (we explain how we came up with this schema in Section 5). Figure 3 presents the definition of the prefixes (not included in the examples so far) that we use in the sequel. 1@prefix classification: <http://worldbank.270a.info/classification/>. 2@prefix dataset: <http://worldbank.270a.info/dataset/>. 3@prefix qb4o: <http://purl.org/qb4olap/cubes#>. 4@prefix year: <http://reference.data.gov.uk/id/year/>. 5 6#QB4OLAP schema and instances 7@prefix schema: 8<http://www.fing.edu.uy/inco/cubes/schemas/world−bank−indicators#>. 9@prefix instances: 10 <http://www.fing.edu.uy/inco/cubes/instances/world−bank−indicators#>. Figure 3: RDF prefixes to be used in the examples Example 5. The new DSD for the running example610 data cube defined using QB4OLAP. 1schema:QB4O CM MKT LCAP CD 2a qb:DataStructureDefinition ; 3qb:component [ qb:measure sdmx−measure:obsValue; 4qb4o:aggregateFunction qb4o:sum ] ; 5qb:component [ indicator:CM.MKT.LCAP.CD ] ; 6qb:component [ qb4o:level sdmx−dimension:refArea ] ; 7qb:component [ qb4o:level sdmx−dimension:refPeriod ] . 8620 9indicator:CM.MKT.LCAP.CD a qb4o:LevelProperty. 10 sdmx−dimension:refArea a qb4o:LevelProperty. 11 sdmx−dimension:refPeriod a qb4o:LevelProperty. 12 sdmx−measure:obsValue a qb:MeasureProperty. 13 14 dataset:CM.MKT.LCAP.CD qb:structure 15 schema:QB4O CM MKT LCAP CD. The DSD is defined in terms of dimension levels such that the dimension properties of the original QB cube are declared as630 instances of qb4o:LevelProperty and considered the lowest levels in the dimension hierarchy. Thus, we avoid rewriting the observations. Readers familiar with OLAP technology may note that indicator:CM.MKT.LCAP.CD refers to the MDX’s Measures dimension. MDX is a de facto standard language for OLAP (see [10] for details). To represent dimension hierarchies the qb4o:Hierarchy class is introduced. The relationship between dimensions and hierarchies is represented via the property qb4o:hasHierarchy640 and its inverse qb4o:inDimension. To support the most common conceptual models, we need to allow declaring that a level may belong to different hierarchies, and that each level may have a different set of parent levels. Also, the relationship between level members may have different cardinality constraints (e.g., one-to-many, many-to-many, etc.). The class qb4o:HierarchyStep allows this by means of the reification of the parent-child relationship between two levels in a hierarchy. Each hierarchy step is linked to650 its two component levels using the qb4o:childLevel and the qb4o:parentLevel properties, respectively, 8 and is attached to the hierarchy it belongs to, using the qb4o:inHierarchy. The qb4o:pcCardinality property allows representing the cardinality constraints of the relationships between level members in this step, using members of the qb4o:Cardinality class, whose instances are depicted in Figure 1. Example 6 illustrates the above. Example 6. The definition of the geographical dimen-660 sion schema:geoDim according to Figure 2. 1schema:geoDim a qb:DimensionProperty ; 2rdfs:label ”Geographical dimension”@en; 3qb4o:hasHierarchy schema:geoHier, schema:lendingHier, 4schema:incomeHier. We now define each hierarchy, declare to which dimension it belongs, and which levels it traverses. We have three hierarchies in our schema, namely schema:geoHier,670 schema:lendingHier, and schema:incomeHier. We just show the first of them, the other ones are analogous. 1schema:geoHier a qb4o:Hierarchy ; 2rdfs:label ”Geographical Hierarchy”@en ; 3qb4o:inDimension schema:geoDim; 4qb4o:hasLevel sdmx−dimension:refArea, schema:region, schema:geoAll. Next, we define the base (i.e., finest granularity) level for the geographical dimension, that means, the one whose instances680 compose the observations, and the upper levels in each hierarchy. Note that the former are defined to be compatible with QB, but as levels instead of dimensions. The example shows only the geographical dimension while construction of other dimensions is analogous where only the All level is added to each of them. 1# Base levels 2sdmx−dimension:refArea a qb4o:LevelProperty; 3rdfs:label ”country level”@en.690 4 5#Upper hierarchy levels 6schema:region a qb4o:LevelProperty; 7rdfs:label ”Geographical regions”@en. 8schema:lendingtype a qb4o:LevelProperty; 9rdfs:label ”Lending type level”@en. 10 schema:income a qb4o:LevelProperty; 11 rdfs:label ”Income level”@en. 12 schema:geoAll a qb4o:LevelProperty; 13 rdfs:label ”All reference areas”@en.700 Finally, the hierarchy steps (i.e., parent-child relationships) are defined. Again, we just show the ones corresponding to the schema:geoHier hierarchy. 1:hs1 a qb4o:HierarchyStep; 2qb4o:inHierarchy schema:geoHier; 3qb4o:childLevel sdmx−dimension:refArea; 4qb4o:parentLevel schema:region; 5qb4o:pcCardinality qb4o:ManyToOne.710 6 7:hs2 a qb4o:HierarchyStep; 8qb4o:inHierarchy schema:geoHier; 9qb4o:childLevel schema:region; 10 qb4o:parentLevel schema:geoAll; 11 qb4o:pcCardinality qb4o:ManyToOne. To represent level attributes, QB4OLAP provides the class of properties qb4o:LevelAttribute, linked to qb4o:LevelProperty via the qb4o:hasAttribute720 property. Instances of this class are used to link level instances with attribute values. Example 7shows the definition of an attribute for the sdmx-dimension:refArea dimension level. Example 7. Definition of a level attribute. 1sdmx−dimension:refArea qb4o:hasAttribute 2schema:capital. 3schema:capital a qb4o:LevelAttribute; 4rdfs:range xsd:string .730 We assume that we add the attribute schema:capital to the sdmx-dimension:refArea dimension level. At the instance level, dimension level members are represented as instances of the class qb4o:LevelMember, which is a sub-class of skos:Concept. Members are attached to the levels they belong to, using the property qb4o:memberOf, which resembles the semantics of skos:member. Rollup relationships between members are expressed740 using the property skos:broader, conveying the idea that hierarchies of level members should be navigated from finer granularity concepts up to coarser granularity concepts. Example 8below shows some examples of dimension members for the dimension schema:geoDim. Example 8. The details for the dimension members corresponding to Serbia. 1country:RS a qb4o:LevelMember ;750 2qb4o:memberOf sdmx−dimension:refArea ; 3skos:broader lending:IBD ; 4skos:broader income:UMC ; 5skos:broader region:ECS ; 6skos:prefLabel ”Serbia”@en . 7 8lending:IBD a qb4o:LevelMember ; 9qb4o:memberOf schema:lending ; 10 skos:broader instance:geoAll ; 11 skos:prefLabel ”IBRD”@en .760 12 13 income:UMC a qb4o:LevelMember ; 14 qb4o:memberOf schema:income ; 15 skos:broader instance:geoAll ; 16 skos:prefLabel ”Upper middle income”@en . 17 18 region:ECS a qb4o:LevelMember ; 19 qb4o:memberOf schema:region ; 20 skos:broader instance:geoAll ; 21 skos:prefLabel ”Europe & Central Asia (all income levels)”@en .770 22 23 instance:geoAll a qb4o:LevelMember ; 24 qb4o:memberOf schema:geoAll ; 25 skos:prefLabel ”Geo ALL”@en . Note that, for attribute instances, we need to link IRIs corresponding to level members, with attribute values. In our example for the geographical dimension: 9 5. Enrichment Method Taking advantage of the QB4OLAP vocabulary and1360 the algorithms introduced in Section 4.3, we now propose a method to enrich an input QB graph24 with additional MD semantics. This method presents a set of detailed enrichment steps. For the sake of comprehension, each step is described as a SPARQL query showing the precise enrichment and transformations. The queries take the specified parameters, use an input QB graph and incrementally create the new QB4OLAP graph by generating the necessary triples. Since this method requires some user actions, the overall enrichment pro-1370 cess is semi-automatized. The method consists of two phases: 1. Redefinition phase which syntactically transforms the input QB graph into QB4OLAP constructs and, given the required input (see Section 4.2), specifies aggregate functions for measures. 2. Enrichment phase which, given a set of required inputs (see Section 4.3), enriches the QB4OLAP graph generated by the redefinition phase with additional MD semantics.1380 For the ease of understanding, this section introduces the main ideas for the enrichment tasks to be accomplished. In addition, Appendix A provides a fully formalized, more general, and detailed enrichment methodology, which is agnostic of the implementation decisions made and further specifies the pre-conditions, post-conditions, and transformations to be conducted by each step in terms of set theory. Thus, the method presented in this section can be considered a possible solution to cover the steps defined by the methodology. In1390 this section, we first introduce some preliminaries for understanding the method. Next, each phase is defined in terms of queries to be performed that taking the input parameters produce the output triples. Finally, we provide some additional considerations. 5.1. Method Preliminaries The method uses two RDF graphs, namely the QB graph (i.e., the set of triples defining the QB cube structure and instances) and the QB4OLAP graph (analogous to the QB graph definition). These graphs are assumed1400 to be compliant with the QB and QB4OLAP vocabularies, respectively. According to the QB and QB4OLAP definitions, we further identify two sets of RDF triples 24For simplicity of presentation, we assume that all triples related to the input QB data set are in a single RDF graph. in each graph: the set of triples describing the QB or QB4OLAP cube schema and the set describing the cube instances. According to the QB definition (see Section 2), the QB cube schema consists of the triples involving the following classes and related properties: the QB dataset25 (i.e., qb:DataSet), struc-1410 ture (i.e., qb:DataStructureDefinition,dimensions (i.e., qb:DimensionProperty), and measures (i.e., qb:MeasureProperty). Following QB’s notation, the cube structure is defined as a set of dimensions and measures via the cube components (i.e., qb:ComponentSpecification). An example of QB cube schema extracted from our running example (see Section 2.3) is presented in Example 9. Example 9. QB cube schema triples. 1420 1<http://worldbank.270a.info/dataset/world−bank−indicators/structure> 2a qb:DataStructureDefinition ; 3qb:component [ qb:dimension sdmx−dimension:refArea ] ; 4qb:component [ qb:measure sdmx−measure:obsValue ] . 5sdmx−dimension:refArea a qb:DimensionProperty . 6sdmx−measure:obsValue a qb:MeasureProperty . 7<http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>a qb:DataSet ; 8qb:structure 9<http://worldbank.270a.info/dataset/world−bank−indicators/structure>. 1430 Lines 1 – 4 relate to the QB cube structure, line 5 to dimensions, line 6 to measures, and line 7 to the dataset. The dataset is related to the cube structure in lines 8 – 9. QB cube instances contain triples related to the QB dimension instances (extracted from the observations with Query 9as explained later) and observations (i.e., qb:Observation). As discussed before, observations represent measure values for the fixed dimension instances determined by the cube structure. An example of QB cube instances is presented in Example 10.1440 Example 10. QB cube instance triples. 1data:world−bank−indicators/CM.MKT.LCAP.CD/RS/2012 2a qb:Observation ; 3sdmx−dimension:refArea country:RS ; 4sdmx−measure:obsValue 7450560827.04874 ; 5qb:dataSet <http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>. Line 1 – 2 define an observation. Line 3 specifies a dimension instance and line 4 defines a measure value of the observa-1450 tion. The observation relates to the cube schema structure indirectly (see lines 7 – 9 of Example 9) via qb:dataSet in line 5. 25Note that in the present section the term “dataset” refers to qb:DataSet. 16 Analogously, we next define the QB4OLAP cube schema and instances. The QB4OLAP cube schema consists of the triples involving the following classes and related properties: •dataset (i.e., qb:DataSet), •structure (i.e., qb:DataStructureDefinition), •dimensions (i.e., qb:DimensionProperty),1460 •measures (i.e., qb:MeasureProperty), •dimension levels (i.e., qb4o:LevelProperty), •dimension level attributes (i.e., qb4o:LevelAttribute), •dimension hierarchies (i.e., qb4o:Hierarchy), •hierarchy steps (i.e., qb4o:HierarchyStep), •predefined set of aggregate functions (i.e., qb4o:AggregateFunction), and •predefined set of possible cardinalities (i.e., qb4o:Cardinality).1470 The QB4OLAP cube instances contain the triples related to the QB4OLAP cube level instances,rollup relationships between child and parent level instances (represented with skos:broader), observations (i.e., qb:Observation), and level attribute values (being literals or IRIs). Examples of the QB4OLAP cube schema and instances are presented below in the method definition. The examples are based on the running example (see Section 2.3). We consider the scenario where the input1480 graph contains implicit MD semantics (e.g., a country is linked to a region but this is not explicitly stated as a rollup relationship since this cannot be described in QB). Other scenarios are discussed in Section 5.4. For the sake of simplicity, we define the steps as SPARQL INSERT queries assuming that from the original input QB graph we build a new QB4OLAP graph (which is implicitly created with the first SPARQL INSERT query). Note that the elements between two ’?’ in the queries represent parameters that should be replaced1490 with the IRI values specified at each step. Moreover, all the examples of the query results follow up on one another. In addition to the prefixes introduced in the previous section, the queries also use the following prefix: 1prefix skos: <http://www.w3.org/2004/02/skos/core#> 5.2. Redefinition Phase Redefinition of a cube schema. We start by building the new QB4OLAP cube schema. We proceed incre-1500 mentally and first we perform a syntactic transformation from QB to QB4OLAP constructs, while the complete QB4OLAP cube schema is formed after the Enrichment phase (see Section 5.3). The QB cube schema triples defining the cube dataset, structure, dimension levels, and measures are added to the QB4OLAP cube schema in the following way. First, dimensions are redefined as levels in the QB4OLAP cube schema. Next, we copy the measures from the QB graph to the QB4OLAP one. Then, we define the new cube schema structure, as-1510 sign to it both levels and measures, and add it to the QB4OLAP cube structure. Finally, we copy the dataset definition to the QB4OLAP cube schema and assign the new cube schema structure to it. This transformation can be performed with Query 5. The inputs for this task are the QB4OLAP graph IRI, the QB graph IRI, the QB dataset IRI, and the new QB4OLAP structure IRI. Query 5. Redefinition of a cube schema. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI,1520 2#?qbGraphIRI? −the input QB graph IRI, 3#?dsIRI? −the data set IRI, and 4#?dsdIRI? −the data structure definition IRI 5 6INSERT INTO ?qb4oGraphIRI? { 7?dsIRI? a qb:DataSet . 8?dsIRI? qb:structure ?dsdIRI? . 9?dsdIRI? a qb:DataStructureDefinition . 10 ?dsdIRI? qb:component ?bl . ?bl qb4o:level ?d . 11 ?dsdIRI? qb:component ?bm . ?bm qb:measure ?m .1530 12 ?d a qb4o:LevelProperty . 13 ?m a qb:MeasureProperty . } 14 FROM ?qbGraphIRI? 15 WHERE { 16 ?dsd a qb:DataStructureDefinition . 17 ?dsIRI? qb:structure ?dsd . 18 ?dsd qb:component ?bl . ?bl qb:dimension ?d . 19 ?dsd qb:component ?bm . ?bm qb:measure ?m . } Thus, at this point, we have obtained the initial1540 QB4OLAP cube schema. An example of a QB4OLAP cube schema is shown in Example 11 which illustrates the result of Query 5. Note that we use the newG namespace for the new QB4OLAP graph. Example 11. Resulting triples of Query 5. 1<http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>a qb:DataSet; 2qb:structure newG:newDSD . 3newG:newDSD a qb:DataStructureDefinition ; 4qb:component [ qb4o:level sdmx−dimension:refArea ] ;1550 5qb:component [ qb:measure sdmx−measure:obsValue ] . 6sdmx−dimension:refArea a qb4o:LevelProperty . 7sdmx−measure:obsValue a qb:MeasureProperty . Lines 1 and 2 illustrate the triples related to the cube dataset. Results in lines 3, 4, and 5 define the new cube schema structure and add a level and a measure as components to it. Line 6 redefines the dimension from Example 9as a QB4OLAP level, while line 7 illustrates the measure from Example 9copied to the new QB4OLAP graph.1560 Specification of an aggregate function. Next, we need to specify an aggregate function per measure. 17 Note that possible aggregate functions are predefined by QB4OLAP. The inputs for this task are the QB4OLAP graph IRI, the QB dataset IRI, and the MAggMap mapping; i.e., the [measure IRI, aggregate function IRI] pair (see Section 4.2). The aggregate function is specified as a triple that relates the aggregate function IRI with the component of the cube schema structure related to the measure. This triple is added to the QB4OLAP cube1570 schema and it can be performed with Query 6. In case of more than one measure, the query should be run for each measure. Query 6. Specification of an aggregate function. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?dsIRI? −the data set IRI, and 3# ?measureIRI? 4# ?aggregateFunctionIRI? −the aggregate function IRI 51580 6INSERT INTO ?qb4oGraphIRI? { 7?comp qb4o:aggregateFunction ?aggregateFunctionIRI? } 8FROM ?qb4oGraphIRI? 9WHERE { 10 ?dsd a qb:DataStructureDefinition . 11 ?dsIRI? qb:structure ?dsd . 12 ?dsd qb:component ?comp . 13 ?comp qb:measure ?measureIRI? . } An example of the updated QB4OLAP cube schema1590 is presented in Example 12. Example 12. Resulting triples of Query 6. 1<http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>a qb:DataSet; 2<http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>qb:structure newG:newDSD . 3newG:newDSD a qb:DataStructureDefinition ; 4qb:component [ qb4o:level sdmx−dimension:refArea ] ; 5qb:component [ qb:measure sdmx−measure:obsValue ; 6qb4o:aggregateFunction qb4o:sum ] .1600 7sdmx−dimension:refArea a qb4o:LevelProperty . 8sdmx−measure:obsValue a qb:MeasureProperty . Line 6 presents the aggregate function that is assigned to a measure by the grouping mechanism via a blank node. In this case, the SUM (i.e., qb4o:Sum) aggregate function. Definition of a dimension. As part of the automatic redefinition, to build QB4OLAP-compliant dimension hierarchies, a new dimension for each initial level needs to be defined. As explained in Section 3, QB4OLAP1610 reuses the qb:DimensionProperty, however with different semantics than in QB: while in the latter a dimension represents a point at a fixed granularity, QB4OLAP considers a dimension to contain points at different level granularities. Therefore, in QB4OLAP, a QB dimension becomes a dimension level (see Query 5) and a dimension represents a set of levels that are hierarchically organized. The inputs for this task are the QB4OLAP graph IRI and the dimension IRI, and it can be performed with Query 7that should be run for each dimen-1620 sion. Query 7. Definition of a dimension. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI and 2# ?dimensionIRI? −the dimension IRI 3 4INSERT INTO ?qb4oGraphIRI? { 5?dimensionIRI? a qb:DimensionProperty . } An example of the triple added to the updated1630 QB4OLAP cube schema is presented in Example 13. Example 13. Resulting triple of Query 7. 1newG:geoDimension a qb:DimensionProperty . The triple presents a dimension for the sdmx-dimension:refArea initial level. Definition of a hierarchy. Once the dimensions are created, we need to create a hierarchy for each dimension. A hierarchy represents the set of hierarchi-1640 cally ordered levels in the dimension. Once created, it needs to be linked with the corresponding dimension and the initial level. Thus, the inputs for this task are the QB4OLAP graph IRI , the hierarchy IRI, the dimension IRI, and the level IRI. This can be performed with Query 8that should be run for each hierarchy. Query 8. Definition of a hierarchy. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?hierarchyIRI? −the hierarchy IRI,1650 3# ?dimensionIRI? −the dimension IRI, and 4# ?levelIRI? −the level IRI 5 6INSERT INTO ?qb4oGraphIRI? { 7?hierarchyIRI? a qb4o:Hierarchy . 8?dimensionIRI? qb4o:hasHierarchy ?hierarchyIRI? . 9?hierarchyIRI? qb4o:inDimension ?dimensionIRI? . 10 ?hierarchyIRI? qb4o:hasLevel ?levelIRI? . } An example of the triples added to the updated1660 QB4OLAP cube schema is presented in Example 14. Example 14. Resulting triples of Query 8. 1newG:geoHierarchy a qb4o:Hierarchy . 2newG:geoDimension qb4o:hasHierarchy newG:geoHierarchy . 3newG:geoHierarchy qb4o:inDimension newG:geoDimension . 4newG:geoHierarchy qb4o:hasLevel newG:region . Line 1 illustrates a new hierarchy being created. Triples in lines 2 and 3 link the hierarchy with a dimension, and to a1670 level in line 4. Populating level members of an initial level. Finally, at the end of the redefinition phase, we populate level members for the initial levels of the QB4OLAP graph schema. The inputs for this task are the QB4OLAP graph IRI, the QB graph IRI, the level IRI, and the QB dataset IRI. This can be performed with Query 9that should be run for each initial level. 18 Query 9. Populating level members of an initial level. 1680 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?qbGraphIRI? −the input QB graph IRI, 3# ?levelIRI? −the level IRI, and 4# ?dsIRI? −the data set IRI 5 6INSERT INTO ?qb4oGraphIRI? { 7?levelMember a qb4o:LevelMember . 8?levelMember qb4o:memberOf ?levelIRI? . } 9FROM ?qbGraphIRI? 10 WHERE { {1690 11 SELECT DISTINCT ?levelMember WHERE { 12 ?o a qb:Observation . 13 ?o qb:dataSet ?dsIRI? . 14 ?o ?levelIRI? ?levelMember . }}} An example of level member triples added to the QB4OLAP graph instances is presented in Example 15. Example 15. Resulting triples of Query 9. 1country:RS a qb4o:LevelMember .1700 2country:RS qb4o:memberOf sdmx−dimension:refArea . Line 1 illustrates a level member extracted from the observations and line 2 links it to the level it belongs to. 5.3. Enrichment Phase Once the cube schema is redefined in terms of QB4OLAP, we next focus on its enrichment with new dimensional concepts to construct richer hierarchies. At this point, we assume that a pre-process to discover potential new levels and level attributes has been carried1710 out. For example, this could be done with the algorithms proposed in Section 4.3. Starting from an initial dimension level we explain the construction of two threelevel hierarchies. This scenario is illustrated in Figure 4. Starting from the refArea level that belongs to the hierarchy H1 we first add a new level - region. For this we need to add the region level to the hierarchy H1, create the hierarchy step S1, add both levels to S1 (refArea as child and region as parent), and add S1 to H1. Then, we add one more level, income-level, on1720 top of refArea. As conceptually the new level belongs to a new hierarchy (i.e., it does not belong to the same rollup path as region), we need to create a new hierarchy H2, create a new step S2, add refArea (as child) and income-level (as parent) to S2, and add S2 to H2. Moreover, H2 needs to be added to the same dimension that H1 already belongs to. This notation is fixed by QB4OLAP. Finally, we create the mandatory All level for the dimension and accordingly link the region and income-level levels to it via two new hierarchy steps1730 S3 and S4 that are created and added to H1 and H2, respectively. The process is as follows. Creating, populating, and linking a new parent level. First, we need to create a new level (e.g., region) ALL Region Ref Area Income level S1S2 S4 S3 H2 H1 Level Step Hierarchy Figure 4: Three-level Hierarchies Construction and add it as a parent level to the child level (e.g., refArea). Moreover, we need to link all the members of the child level with the corresponding members of the new parent level. The inputs for this task are the QB4OLAP graph IRI, the QB graph IRI, the child level IRI, and the new parent level (i.e., property) IRI. This1740 can be performed with Query 10. To build the hierarchy illustrated in Figure 4, the query should be run for both region and income-level levels that are added as parent levels for the refArea level. Query 10. Creating, populating, and linking a new parent level. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?qbGraphIRI? −the input QB graph IRI, 3# ?levelIRI? −the existing level IRI, and1750 4# ?propertyIRI? −the property IRI (i.e., new level) 5 6INSERT INTO ?qb4oGraphIRI? { 7?propertyIRI? a qb4o:LevelProperty . 8?obj a qb4o:LevelMember . 9?obj qb4o:memberOf ?propertyIRI? . 10 ?levelMember2 skos:broader ?obj2 . } 11 WHERE { { 12 SELECT DISTINCT ?obj 13 FROM ?qbGraphIRI?1760 14 WHERE { { 15 SELECT ?levelMember 16 FROM ?qb4oGraphIRI? 17 WHERE { 18 ?levelMember a qb4o:LevelMember . 19 ?levelMember qb4o:memberOf ?levelIRI? . }} 20 ?levelMember ?propertyIRI? ?obj . }} 21 {SELECT ?levelMember2 ?obj2 22 FROM ?qbGraphIRI? 23 WHERE {1770 24 {SELECT ?levelMember2 25 FROM ?qb4oGraphIRI? 26 WHERE { 27 ?levelMember2 a qb4o:LevelMember . 28 ?levelMember2 qb4o:memberOf ?levelIRI? . }} 29 ?levelMember2 ?propertyIRI? ?obj2 . 30 }GROUP BY ?levelMember2 ?obj2 } } 19 An example of triples for two new levels, their level members, and linking of the level members of the new1780 parent levels with the level members of the child level added to the QB4OLAP graph is presented in Example 16. Example 16. Resulting triples of Query 10. 1newG:region a qb4o:LevelProperty . 2region:ECS a qb4o:LevelMember . 3region:ECS qb4o:memberOf newG:region . 4country:RS skos:broader region:ECS . 51790 6newG:income−level a qb4o:LevelProperty . 7income:UMC a qb4o:LevelMember . 8income:UMC qb4o:memberOf newG:income−level . 9country:RS skos:broader income:UMC . Line 1 illustrates the new level definition for the region level. Lines 2 and 3 exemplify a new level member and its linking to the region level, respectively. Then, line 4 links a child level member (i.e., country:RS to the new parent level member (i.e., region:ECS) and this way creating a rollup relationship1800 between them. Finally, lines 6-9 reflect the same definition for income-level. Definition of a hierarchy step in an existing hierarchy. Having a new parent level defined and added to the QB4OLAP graph (both schema and instance parts), we next need to create a hierarchy step that determines the order of these levels in a hierarchy. In this context, we explain two particular cases. The first, simpler, case is to add a new parent level to a level that is either the only level in a hierarchy or that is the last (i.e., coarsest) par-1810 ent level in the hierarchy. The inputs for this task are the QB4OLAP graph IRI, the child level IRI, the new parent level (i.e., property) IRI, the hierarchy IRI, and the hierarchy step IRI. This can be performed with Query 11. To build the hierarchy illustrated in Figure 4, the query should be run for the region level that is added as parent level to the refArea level. Query 11. Definition of a hierarchy step in an existing hierarchy. 1820 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?levelIRI? −the existing level IRI, 3# ?propertyIRI? −the property IRI (i.e., new level), 4# ?hierarchyIRI? −the hierarchy IRI, and 5# ?hsIRI? −the hierarchy step IRI (typically blank node) 6 7INSERT INTO ?qb4oGraphIRI? { 8?hsIRI? a qb4o:HierarchyStep . 9?hsIRI? qb:inHierarchy ?hierarchyIRI? . 10 ?hsIRI? qb4o:parentLevel ?propertyIRI? .1830 11 ?hsIRI? qb4o:childLevel ?levelIRI? . 12 ?hsIRI? qb4o:pcCardinality qb4o:ManyToOne . 13 ?hierarchyIRI? qb4o:hasLevel ?propertyIRI? .} Example triples for creating a hierarchy step in an existing hierarchy are presented in Example 17. Example 17. Resulting triples of Query 11. 1:newHierarchyStep a qb4o:HierarchyStep . 2:newHierarchyStep qb4o:inHierarchy newG:geoHierarchy .1840 3:newHierarchyStep qb4o:parentLevel newG:region . 4:newHierarchyStep qb4o:childLevel sdmx−dimension:refArea . 5:newHierarchyStep qb4o:pcCardinality qb4o:ManyToOne . 6newG:geoHierarchy qb4o:hasLevel newG:region . Line 1 defines the new hierarchy step and lines 2 – 5 link the hierarchy step with its hierarchy, parent level, child level, and cardinality, respectively. Finally, line 6 adds the new parent level to the existing hierarchy. Definition of a hierarchy step while creating a new1850 hierarchy. The second, more complex, case is to add a parent level to a child level that already has a parent level (in one or more hierarchies). In this case, for each hierarchy where there is a parent level, create a new hierarchy. Then, replicate the hierarchy steps and add the corresponding levels such that the child level is the only or the last (i.e., coarsest) parent level in the hierarchy. Finally, add the new parent level to the new hierarchy and create a new hierarchy step with the child level. In case that identical (i.e., duplicate) new hier-1860 archies would be created from different existing hierarchies, only one new hierarchy should be created. Thus, in the context of Figure 4, adding the income-level level as parent to the refArea level (i.e., S2 in H2) can be performed with Query 12. The inputs for this task are the QB4OLAP graph IRI, the QB graph IRI, the child level IRI, the new parent level (i.e., property) IRI, the hierarchy IRI, and the hierarchy step IRI. Note that if there was a longer sequence of levels (and hierarchy steps) to be replicated, Query 12 would need to be extended.1870 Query 12. Definition of a hierarchy step with creating a new hierarchy. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?qbGraphIRI? −the input QB graph IRI, 3# ?levelIRI? −the existing level IRI, 4# ?propertyIRI? −the property IRI (i.e., new level), 5# ?hierarchyIRI? −the hierarchy IRI, and 6# ?hsIRI? −the hierarchy step IRI (typically blank node) 71880 8INSERT INTO ?qb4oGraphIRI? { 9?hierarchyIRI? a qb4o:Hierarchy . 10 ?hierarchyIRI? qb4o:inDimension ?d . 11 ?d qb4o:hasHierarchy ?hierarchyIRI? . 12 ?hsIRI? a qb4o:HierarchyStep . 13 ?hsIRI? qb4o:inHierarchy ?hierarchyIRI? . 14 ?hsIRI? qb4o:parentLevel ?propertyIRI? . 15 ?hsIRI? qb4o:childLevel ?levelIRI? . 16 ?hsIRI? qb4o:pcCardinality qb4o:ManyToOne . 17 ?hierarchyIRI? qb4o:hasLevel ?propertyIRI? .1890 18 ?hierarchyIRI? qb4o:hasLevel ?levelIRI? } 19 FROM ?qbGraphIRI? 20 WHERE { 21 ?h a qb4o:Hierarchy . 22 ?h qb4o:hasLevel ?levelIRI? . 23 ?h qb4o:inDimension ?d . 24 ?d a qb:DimensionProperty . 25 } 20 Example triples for creating a hierarchy step in a new1900 hierarchy are presented in Example 18. Example 18. Resulting triples of Query 12. 1newG:incomeHierarchy a qb4o:Hierarchy . 2newG:incomeHierarchy qb4o:inDimension newG:geoDimension . 3newG:geoDimension qb4o:hasHierarchy newG:incomeHierarchy . 4:newHierarchyStep2 a qb4o:HierarchyStep . 5:newHierarchyStep2 qb4o:inHierarchy newG:incomeHierarchy . 6:newHierarchyStep2 qb4o:parentLevel newG:income−level . 7:newHierarchyStep2 qb4o:childLevel sdmx−dimension:refArea .1910 8:newHierarchyStep2 qb4o:pcCardinality qb4o:ManyToOne . 9newG:incomeHierarchy qb4o:hasLevel sdmx−dimension:refArea 10 newG:incomeHierarchy qb4o:hasLevel newG:income−level . Lines 1 – 3 define the new hierarchy and link it with the existing dimension. Then, lines 4 – 8 create a new hierarchy step and link it with its hierarchy, parent level, child level, and cardinality, respectively. Finally, lines 9 and 10 add both levels to the hierarchy. In any case, when adding a hierarchy step, cycles1920 need to be avoided in the hierarchy definition and this can be achieved following the rationale of Algorithm 1. Definition of the all level and its level member. Finally, the mandatory All level with its all level member must top all the dimension hierarchies. Thus, we first need to add the All level to each dimension. The inputs for this task are the QB4OLAP graph IRI, the All level IRI, and the all level member IRI. This can be performed with Query 13. Query 13. Definition of the all level and its level mem-1930 ber. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?allLevelIRI? −the all level IRI, and 3# ?allLevelMemberIRI? −the all level member IRI 4 5INSERT INTO ?qb4oGraphIRI? { 6?allLevelIRI? a qb4o:LevelProperty . 7?allLevelMemberIRI? a qb4o:LevelMember . 8?allLevelMemberIRI? qb4o:memberOf ?allLevelIRI? .}1940 Example triples for creating the All level and its all level member are presented in Example 19. Example 19. Resulting triples of Query 13. 1newG:geoALL a qb4o:LevelProperty . 2newG:geoALLmember a qb4o:LevelMember . 3newG:geoALLmember qb4o:memberOf newG:geoALL . Line 1 illustrates the new level definition of the all level for1950 the geo dimension. Line 2 defines its level member and line 3 links the member to the level. Linking of the all level member with the lower level members. After creating the All level and its all level member for a dimension, all the coarsest levels of each hierarchy belonging to the dimension, must be linked to the All level. Furthermore, their level members must be related to the all level member. The inputs for this task are the QB4OLAP graph IRI, the All level IRI, and the child level IRI. This can be performed1960 with Query 14. In the context of the hierarchy illustrated in Figure 4, the query should be run for both region and income-level that need to be linked to the All level. Query 14. Linking of the all level member with the lower level members. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?levelIRI? −the child level IRI, and 3# ?allLevelMemberIRI? −the all level member IRI1970 4 5INSERT INTO ?qb4oGraphIRI? { 6?levelMember skos:broader ?allLevelMemberIRI? . } 7FROM ?qb4oGraphIRI? 8WHERE { 9?levelMember a qb4o:LevelMember . 10 ?levelMember qb4o:memberOf ?levelIRI? . } Example triples that link the child level members with the all level member are presented in Example1980 20. Example 20. Resulting triples of Query 14. 1region:ECS skos:broader newG:geoALLmember . 2income:UMC skos:broader newG:geoALLmember . Lines 1 and 2 illustrate linking of the region and income-level level members with the all level member in the geo dimension, respectively. Once the All levels (one per dimension) and their1990 all level member are created and linked, we can use Query 11 to link both region and income-level to the All level. This way we can create the S3 and S4 hierarchy steps in Figure 4. The addition of the All levels for the remaining two dimensions is analogous. Definition of a level attribute and its linking to a level. Additionally to the construction of the dimension hierarchies, the levels may have level attributes that can also be discovered with Algorithm 1. Thus, level attributes can be added to the QB4OLAP graph. The in-2000 puts for this task are the QB4OLAP graph IRI, the QB graph IRI, level IRI, and the attribute IRI. This can be performed with Query 15. Query 15. Definition of a level attribute and its linking to a level. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?qbGraphIRI? −the input QB graph IRI, 3# ?levelIRI? −the child level IRI, and 4# ?propertyIRI? −the property IRI (i.e., the attribute)2010 21 5 6INSERT INTO ?qb4oGraphIRI? { 7?propertyIRI? a qb4o:LevelAttribute . 8?propertyIRI? qb4o:inLevel ?levelIRI? . 9?levelIRI? qb4o:hasAttribute ?propertyIRI? . 10 ?levelMember ?propertyIRI? ?obj . } 11 FROM ?qbGraphIRI? 12 WHERE { 13 {SELECT ?levelMember 14 FROM ?qb4oGraphIRI?2020 15 WHERE{ 16 ?levelMember a qb4o:LevelMember . 17 ?levelMember qb4o:memberOf ?levelIRI? . } } 18 ?levelMember ?propertyIRI? ?obj . } Example triples of a level attribute, its linking with a level, and specifying the value for a level member are presented in Example 21. Example 21. Resulting triples of Query 15. 2030 1skos:prefLabel a qb4o:LevelAttribute . 2skos:prefLabel qb4o:inLevel sdmx−dimension:refArea . 3sdmx−dimension:refArea qb4o:hasAttribute skos:prefLabel . 4country:RS skos:prefLabel ‘‘Serbia’’\@en . Line 1 defines a level attribute and lines 2 and 3 link the level attribute and the corresponding level. Then, line 4 exemplifies the value of the attribute for country:RS. Copying of observations. The output of the previous steps (i.e., queries) is the complete QB4OLAP schema2040 graph and partial QB4OLAP instance graph. To complete the latter one, the observations need to be copied to the QB4OLAP graph. The inputs for this task are the QB4OLAP graph IRI, the QB graph IRI, and the QB dataset IRI. This can be performed with Query 16. Query 16. Copying of observations. 1# INPUT: ?qb4oGraphIRI? −the new QB4OLAP graph IRI, 2# ?qbGraphIRI? −the input QB graph IRI, and 3# ?dsIRI? −the data set IRI2050 4 5INSERT INTO ?qb4oGraphIRI? { 6?oIRI a qb:Observation . 7?oIRI ?prop ?val . } 8FROM ?qbGraphIRI? 9WHERE { 10 ?oIRI a qb:Observation . 11 ?oIRI qb:dataSet ?dsIRI? . 12 ?oIRI ?prop ?val . } 2060 Example triples of a QB observation copied to the QB4OLAP graph are presented in Example 22. Example 22. Resulting triples of Query 16. 1<http://worldbank.270a.info/dataset/world−bank−indicators/ 2CM.MKT.LCAP.CD/RS/2012> 3a qb:Observation ; 4qb:dataSet newG:newDS ; 5property:indicator indicator:CM.MKT.LCAP.CD ; 6sdmx−dimension:refArea country:RS ;2070 7sdmx−measure:obsValue 7450560827.04874 ; Line 1 defines an observation and the rest of the triples link observation with the data set, levels, and measure value for country:RS. 5.4. Additional considerations We want to position our approach with respect to two QB concepts that might be considered relevant in our context, namely qb:AttributeProperty and qb:Slice. The former refers to the attributes de-2080 scribing the observations (e.g., the type of the measure). We consider these attributes as metadata rather than elements of the schema. Our proposal is to capture this information, by means of analytical metadata (e.g., the SM4AM analytical metadata [30]). For instance, different attributes can be defined as instances (via rdf:type) of sm4am:DataProperty and kept as additional metadata. Regarding the latter, qb:Slice, we focus on the base cuboid, without considering higher level cuboids, since they are derivable from the base2090 cuboid. For the creation of the IRIs of the new objects, we recommend to use the W3C best practices.26 A final consideration relates to whether or not the QB4OLAP enrichment should entail the construction of a new graph. For simplicity of presentation, we assume so far that the method steps always build a new graph. Nevertheless, the newly created QB4OLAP data cube schema can be used for the exploration of the existing observations. As the existing QB dimen-2100 sion properties used in the observations are now redefined as QB4OLAP dimension level properties, the new schema that defines dimension structures and includes the aggregate functions for measures can be used to interpret observations and aggregate measure values. Moreover, the existing graph can be changed such that its qb:DataSet points only to the newly defined qb:DataStructureDefinition representing the QB4OLAP data cube schema. 6. Evaluation2110 To evaluate our approach, we have built the tool called QB2OLAP Enrichment Module (QB2OLAPem) that redefines a QB data set in terms of the QB4OLAP vocabulary. The resulting QB4OLAP data set can then be enriched as discussed in the previous section by relating measures with aggregate functions and by discovering new potential dimensional concepts that can then 26http://www.w3.org/2011/gld/wiki/223_Best_ Practices_URI_Construction 22 be used to extend the MD knowledge described in the QB4OLAP data set. To do so, QB2OLAPem follows the steps described in the method. Our tool was used2120 in a set of experiments aimed at validating our approach and in this section we present the results. We first briefly introduce QB2OLAPem. Then, we explain the evaluation setting and rational. Finally, we present the evaluation results for the applicable quality characteristics of the Quality in use and the Product quality models of the ISO/IEC 25000 [31]. 6.1. QB2OLAP Enrichment Module QB2OLAPem is developed in Java using JRE 1.8.0 60, Apache Jena 2.13.0 for working with RDF2130 graphs, SWT27 for the GUI, and Windows 8.1 as OS. It implements the algorithm to discover implicit dimensional concepts from Section 4and the enrichment method from Section 5. The enrichment steps are performed in an iterative and interactive fashion. QB2OLAPem automatically retrieves potentially new dimension levels and level attributes, lists them to the user who can choose the ones of her interest, and automatically enriches the data set based on the user choices. The user can also configure an aggregate function for2140 each measure. QB2OLAPem visualizes the cube structure for the user and enables her to automatically generate the QB4OLAP triples once the enrichment is finished. This way, QB2OLAPem enables user-friendly and (semi-)automatic enrichment of QB data sets with additional QB4OLAP semantics. Furthermore, the output triples produced by QB2OLAPem can be straightforwardly loaded into an SW-based OLAP engine and allow traditional OLAP analysis (i.e., by means of a high-level interface in terms of an MD algebra that auto-2150 matically translates these high-level operators in terms of SPARQL). Thus, it lowers the entry barrier for data analysis on SW data for non-expert users (e.g., traditional OLAP users). For further details, [9] reports on how to connect QB2OLAPem with an OLAP engine. From here on we focus on QB2OLAPem, whose process flow is presented in Figure 5. The figure illustrates three kinds of external processes, as well as the QB2OLAPem internal process flow. The first kind of external process is the user – sys-2160 tem interaction, where the user is guided by the Interface element to iteratively perform the semi-automatic enrichment using the QB2OLAPem GUI. The second kind of external process is the system – SPARQL endpoint interaction where QB2OLAPem queries external 27https://www.eclipse.org/swt/ QB2OLAP Enrichment Module SPARQL ENDPOINT Triplestore Source USER Enrichment Enrichment Parameterization Visualization Triple-generation QUERYING Triple-generation Parameterization GUI RDF triples SPARQL queries QB4OLAP triples 2 1 3 INTERFACE Figure 5: QB2OLAP Enrichment Module Process Flow triplestores to identify implicit potential MD concepts that could be used for the enrichment. The last kind of external process is the generation of the QB4OLAP triples that can then be used in other tools (e.g., an OLAP engine, a SPARQL endpoint, etc.). These three2170 kinds of external processes are coordinated by the QB2OLAPem internal process flow as follows. In the user – system interaction, the user initiates the enrichment process by specifying the SPARQL endpoint, the data set IRI, and possibly additional fine-tuning parameters in the Enrichment Parameterization activity. Then, the Querying element triggers the SPARQL queries to retrieve the RDF triples specifying the initial QB cube structure. This structure is then redefined in terms of QB4OLAP (see Section 5.2). The results are then vi-2180 sualized to the user in the Visualization activity. Moreover, the Querying element also runs the queries to discover candidate enrichment concepts (see Section 4.3). The user can then again set the fine-tuning parameters and optionally restart the process, perform the enrichment in the Enrichment activity, or decide to generate triples in the Triple-generation activity, where she can optionally first set the fine-tuning parameters for triple generation in the Triple-generation Parameterization activity. After each enrichment, the Querying ele-2190 ment again runs the necessary SPARQL queries to discover new candidate enrichment concepts if any. The enrichment process finishes when the user decides to generate the QB4OLAP triples as the final result. The QB2OLAPem GUI is illustrated in Figure 6and more details about the tool can be found in [9]. 6.2. Evaluation Setting and Rational For the evaluation of our approach, we adopt quality characteristics from the Quality Model of the ISO/IEC 25000 – System and Software Quality Requirements2200 and Evaluation (SQuaRE) series of standards [31] that are applicable to our usage scenario. It includes the 23 Figure 6: QB2OLAP Enrichment Module Screenshot Quality in use model and the Product quality model that specify quality characteristics and subcharacteristics for which we define metrics specific for our tool. Table 1 presents the details. The main target group of users for our tool are OLAP practitioners that are well familiar with the data cube abstraction paradigm (see Section 2.1). Typical OLAP users are not proficient in, for example, SQL or2210 other query languages. Instead, they analyze data using graphical user interfaces of different OLAP engines. Such high-level automation is enabled by the definition of a correct MD schema (see Section 2.1), which allows OLAP users to abstract their actions from data manipulation languages (such as SQL or SPARQL) and use high-level interfaces based on an MD algebra not demanding IT expertise [10]. In the same spirit, our tool supports OLAP users to enrich the QB schema with a graphical environment. Thus, more than just analyzing2220 data as in traditional OLAP settings, QB2OLAPem enables OLAP users to participate in discovering interesting analysis perspectives and construct the MD schema according to their requirements /needs. Moreover, although the users with both SW and OLAP skills could perform this manually, our tool lowers the barrier such that the users non-familiar with SW technologies and even non-technical users can perform the enrichment. Therefore, we conduct the experiments with 25 users including 4 OLAP experts, 4 SW experts, and 17 users2230 having some knowledge of both. The expert users are PhD students28 and a master student29 doing research in the OLAP and SW areas. The non-expert users include a PhD student familiar with both areas and students of a UPC-BarcelonaTech master30 that includes a Data Warehousing /OLAP course and a Semantic Web course. All of them had a 20 minutes tutorial in QB / QB4OLAP and some recall on DW /OLAP to facilitate the understanding of the template SPARQL queries provided to perform the manual enrichment as well as the2240 overall objective. For the experiments with the users we consider the running example data set. The users should perform the enrichment according to a predefined scenario. Currently, the alternative to using our tool is that the user manually explores a QB data set, discovers enrichment concepts, and constructs the QB4OLAP graph by using SPARQL while, also manually, storing and defining RDF triples. Thus, we compare this case as an alternative to using the tool for the same tasks. The users2250 are asked to both use the tool and follow a guided tutorial that provides template SPARQL queries to manually perform the enrichment. They are provided with detailed guidelines in both cases. Moreover, the order of the cases is alternated among users. After the enrichment, the users deliver the results and their feedback. Later, for the evaluation of the tool performance, we consider two more data sets from another Linked Data source and of different sizes. All the data sets are 28https://it4bi-dc.ulb.ac.be/ 29http://it4bi.univ-tours.fr/it4bi/ 30http://www.fib.upc.edu/en/masters/miri.html 24 Table 1: Quality Characteristics, Subcharacteristics, and Metrics Model Characteristics Subcharacteristics Metrics Quality in use - The evaluation of the interaction with a system Effectiveness - Accuracy and completeness with which users can enrich a schema / The percentage of users producing (not) complete and (not) sound schemata according to a predefined scenario, both with and without the tool Efficiency - The actions that the user needs to perform to enrich the schema / The number of user actions and time contributing to redefinition/enrichment tasks according to a predefined scenario, and the total number of user actions and total time Satisfaction - How much is the user satisfied with using the tool Usefulness - How useful does the user considers the tool Survey statistics Product quality - The software product quality properties Functional suitability - The functions specified by the tool Functional completeness - Functions that cover the specified tasks The percentage of cases where the user produces a complete schema according to the underlying QB data set and a predefined scenario Functional correctness - Correctness of the tool results The percentage of cases where the user produces a sound schema according to the MD model Performance efficiency - The amount of resources used for the enrichment Time-behavior - The processing time (i) Redefinition time to: a) Retrieve the initial cube structure, b) Retrieve the level members, and (ii) Enrichment time: a) Properties / Level members retrieval time Capacity - The limits of the tool The number of observations (characterizing the data set size) that can be handled by the tool Usability - How much can a tool be used for the enrichment with effectiveness, efficiency, and satisfaction Learnability - Degree to which specified users can learn to use the system with effectiveness, efficiency, and satisfaction Statistics about how many different types of user are able to use all (or partial) tool functions (e.g., redefinition, adding new level, etc.) Operability - The attributes of the system that make it easy to operate and control the enrichment The time that the user takes for performing the actions in the tool 25 i.e., MD cubes that can be dynamically extended both in their schema and their instances, and in which data and metadata can be associated with quality and provenance annotations. To support the second approach mentioned above, the RDF Data Cube vocabulary [14] aims at representing, using RDF, statistical data according to the SDMX information model. Although similar to traditional MD data models, the SDMX semantics imposes restrictions2740 on what can be represented using QB. Etcheverry and Vaisman [7] proposed QB4OLAP, an extension to QB that allows to represent analytical data according to traditional MD models, also presenting a preliminary implementation of some OLAP operators (RollUp, Dice, and Slice), using SPARQL queries over data cubes specified using QB4OLAP. These two approaches have been thoroughly discussed in Sections 2and 3. In [42], Ibragimov et al. present a framework for Exploratory OLAP over Linked Open Data sources, where the MD schema2750 of the data cube is expressed in QB4OLAP and VoID. Based on this MD schema the system is able to query data sources, extract and aggregate data, and build an OLAP cube. The MD information retrieved from external sources is also stored using QB4OLAP. K¨ ampgen et al. [43,44] attempt to override the lack of structure in QB, discussed in Section 3, defining an OLAP data model on top of QB and other related vocabularies, e.g., some proposed ISO extensions to SKOS.37. They propose to represent each level as an in-2760 stance of a class skosclass:ClassificationLevel and organize levels in hierarchies via stating the depth of each level in the hierarchy using the skosclass:depth property. The proposed representation restricts levels to participate in only one hierarchy and does not provide support for level attributes. They also propose a mechanism for implementing some OLAP operators over these extended cubes, using SPARQL queries, but restricting to data cubes with only one hierarchy per dimension.2770 Related to the SKOS extensions mentioned above, and realizing that SKOS is insufficient to represent the needs of statistical classifications and concept management, a new proposal to address those needs was issued, and denoted XKOS.38 XKOS attenpts to capture the main semantic relationships like generalization, specialization, part-of, among other ones, with properties like xkos:generalizes,xkos:generalizes, xkos:isPartOf, respectively. At the time of writing 37http://www.w3.org/2011/gld/wiki/ISO_Extensions_ to_SKOS 38http://rdf-vocabulary.ddialliance.org/xkos.html this paper, this proposal is in a preliminary status.2780 For an exhaustive study of the possibilities of using SW technologies for OLAP, we refer the reader to the survey by Abell´ o et al. [33]. 8. Conclusion The approach presented in this paper opens new possibilities for performing OLAP analysis in Linked Data and SW contexts. After thoroughly elaborating on the significant benefits that QB4OLAP brings in terms of additional schema constructs that are necessary for the state-of-the-art OLAP analysis, we have elaborated on2790 how to, as automatically as possible, introduce these enhancements into an existing QB data set. We have proposed the use of metadata to automate the association between measures and aggregate functions, and the algorithm for the detection of implicit MD semantics to automate the discovery of dimension hierarchy schema and instances, since these are the two most relevant semantic enhancements of QB4OLAP. The enrichment task is formalized in a semi-automatic method that defines steps described as SPARQL queries to cre-2800 ate a new enriched QB4OLAP graph. Moreover, we have presented QB2OLAPem implementing the method and the algorithm for the detection of implicit MD semantics. QB2OLAPem enables the user to enrich a QB data set with minimal user efforts. Finally, the evaluation of our approach using three real-world QB data sets of different sizes demonstrates its feasibility in practice. Furthermore, the experiments conducted with 25 users show that, in practice, QB2OLAPem facilitates, speeds up, and guarantees the correct results of the enrichment2810 process. In the future, we plan to extend our approach to automatically identify the data heterogeneity cases and inspired by [45] explore the possibilities to integrate different QB schemata into a single QB4OLAP schema. Acknowledgments This research has been funded by the European Commission through the Erasmus Mundus Joint Doctorate ”Information Technologies for Business Intelligence - Doctoral College“ (IT4BI-DC) and it has been partially2820 supported by the Secretaria d’Universitats i Recerca de la Generalitat de Catalunya. Alejandro Vaisman was partially supported by PICT-2014 Project 0787, funded by Argentina’s Scientific Agency. 32 References [1] L. I. G´ omez, S. A. G´ omez, A. A. Vaisman, A generic data model and query language for spatiotemporal OLAP cube analysis, in: EDBT, 2012, pp. 300–311. [2] C. A. Hurtado, A. O. Mendelzon, A. A. Vaisman, Maintaining data cubes under dimension updates, in: ICDE, 1999, pp. 346–2830 355. [3] P. Vassiliadis, Modeling multidimensional databases, cubes and cube operations, in: SSDBM, 1998, pp. 53–62. [4] T. Heath, C. Bizer, Linked Data: Evolving the Web into a Global Data Space, Morgan & Claypool Publishers, 2011. [5] R. Cyganiak, D. Wood, M.Lanthaler, Resource description framework (RDF): Concepts and abstract syntax, http:// www.w3.org/TR/2014/REC-rdf11-concepts-20140225/ (2014). [6] D. Brickley, R. Guha, RDF schema 1.1, http://www.w3.org/2840 TR/rdf-schema/ (2014). [7] L. Etcheverry, A. Vaisman, QB4OLAP: A vocabulary for OLAP cubes on the semantic web, in: COLD, 2012. [8] E. Prud’hommeaux, A. Seaborne, SPARQL 1.1 Query Language for RDF (2011). URL http://www.w3.org/TR/sparql11-query/ [9] J. Varga, L. Etcheverry, A. A. Vaisman, O. Romero, T. B. Pedersen, C. Thomsen, QB2OLAP: Enabling OLAP on statistical linked open data, in: ICDE, 2016, In Press. [10] A. Vaisman, E. Zim´ anyi, Data Warehouse Systems: Design and2850 Implementation, Springer, 2014. [11] C. Ciferri, R. Ciferri, L. G´ omez, M. Schneider, A. Vaisman, E. Zim´ anyi, Cube algebra: A generic user-centric model and query language for OLAP cubes, IJDWM 9 (2) (2013) 39–65. [12] D. Beckett, T. Berners-Lee, Turtle - Terse RDF Triple Language (2011). URL http://www.w3.org/TeamSubmission/turtle/ [13] SDMX, SDMX standards: Information model, http: //sdmx.org/wp-content/uploads/2011/08/SDMX_ 2-1-1_SECTION_2_InformationModel_201108.pdf2860 (2011). [14] R. Cyganiak, D. Reynolds, The RDF Data Cube Vocabulary (W3C Recommendation), http://www.w3.org/TR/ vocab-data-cube/ (January 2014). [15] SDMX, Content Oriented Guidelines, http://sdmx.org/ ?page_id=11 (2009). [16] A. A. Vaisman, Publishing OLAP cubes on the semantic web, eBISS 2015, LNBIP 253 (2016) 1–30. [17] M. Jarke, M. Lenzerini, Y. Vassiliou, P. Vassiliadis, Fundamentals of data warehouses, Springer, 2013.2870 [18] A. Y. Halevy, Why your data won’t mix, ACM Queue 3 (8) (2005) 50–58. [19] C. Batini, C. Cappiello, C. Francalanci, A. Maurino, Methodologies for data quality assessment and improvement, ACM Comput. Surv. 41 (3). [20] H. Lenz, A. Shoshani, Summarizability in OLAP and statistical data bases, in: SSDBM, 1997, pp. 132–143. [21] J. Varga, O. Romero, T. B. Pedersen, C. Thomsen, Towards next generation BI systems: The analytical metadata challenge, in: DaWaK, 2014, pp. 89–101.2880 [22] H. Garcia-Molina, J. D. Ullman, J. Widom, Database systems - the complete book (2. ed.), Pearson Education, 2009. [23] O. Romero, D. Calvanese, A. Abell´ o, M. Rodriguez-Muro, Discovering functional dependencies for multidimensional design, in: DOLAP, 2009, pp. 1–8. [24] J. Maz´ on, J. Lechtenb¨ orger, J. Trujillo, A survey on summarizability issues in multidimensional modeling, Data Knowl. Eng. 68 (12) (2009) 1452–1469. [25] O. Romero, A. Abell´ o, A framework for multidimensional design of data warehouses from ontologies, Data Knowl. Eng.2890 69 (11) (2010) 1138–1157. [26] A. Artale, D. Calvanese, R. Kontchakov, M. Zakharyaschev, The DL-Lite family and relations, J. Artif. Intell. Res. (JAIR) 36 (2009) 1–69. [27] M. R. Jensen, T. Holmgren, T. B. Pedersen, Discovering multidimensional structure in relational data, in: DaWaK, 2004, pp. 138–148. [28] T. B. Pedersen, C. S. Jensen, C. E. Dyreson, A foundation for capturing and querying complex multidimensional data, Inf. Syst. 26 (5) (2001) 383–423.2900 [29] F. M. Suchanek, S. Abiteboul, P. Senellart, PARIS: probabilistic alignment of relations, instances, and schema, PVLDB 5 (3) (2011) 157–168. [30] J. Varga, O. Romero, T. B. Pedersen, C. Thomsen, SM4AM: A semantic metamodel for analytical metadata, in: DOLAP, 2014, pp. 57–66. [31] I. ISO, Iec25010: 2011 systems and software engineering– systems and software quality requirements and evaluation (square)–system and software quality models, International Organization for Standardization (2011) 34.2910 [32] O. Romero, A. Abell´ o, A survey of multidimensional modeling methodologies, IJDWM 5 (2) (2009) 1–23. [33] A. Abell´ o, O. Romero, T. B. Pedersen, R. Berlanga, V. Nebot, M. J. Aramburu, A. Simitsis, Using semantic web technologies for exploratory OLAP: A survey, IEEE Trans. Knowl. Data Eng. 27 (2) (2015) 571–588. [34] M. Saleem, A. N. Ngomo, Hibiscus: Hypergraph-based source selection for SPARQL endpoint federation, in: The Semantic Web: Trends and Challenges - 11th International Conference, ESWC 2014, Anissaras, Crete, Greece, May 25-29, 2014. Pro-2920 ceedings, 2014, pp. 176–191. [35] R. Angles, A comparison of current graph database models, in: Workshops Proceedings of the IEEE 28th International Conference on Data Engineering, ICDE 2012, Arlington, VA, USA, April 1-5, 2012, 2012, pp. 171–177. [36] L. Kowalik, Adjacency queries in dynamic sparse graphs, Inf. Process. Lett. 102 (5) (2007) 191–195. [37] P. A. Boncz, O. Erling, M. Pham, Experiences with virtuoso cluster RDF column store, in: Linked Data Management., 2014, pp. 239–259.2930 [38] V. Nebot, R. B. Llavori, Building data warehouses with semantic web data, Decision Support Systems 52 (4) (2012) 853–868. [39] B. K¨ ampgen, A. Harth, Transforming statistical linked data for use in OLAP systems, in: I-SEMANTICS, 2011, pp. 33–40. [40] A. Abell´ o, J. Darmont, L. Etcheverry, M. Golfarelli, J. Maz´ on, F. Naumann, T. B. Pedersen, S. Rizzi, J. Trujillo, P. Vassiliadis, G. Vossen, Fusion cubes: Towards self-service business intelligence, IJDWM 9 (2) (2013) 66–88. [41] A. L¨ oser, F. Hueske, V. Markl, Situational business intelligence, in: BIRTE, 2008, pp. 1–11.2940 [42] D. Ibragimov, K. Hose, T. Pedersen, Z. E, Towards exploratory OLAP over linked open data: A case study, in: BIRTE, 2014, pp. 114–132. [43] B. K¨ ampgen, S. O’Riain, A. Harth, Interacting with Statistical Linked Data via OLAP Operations, in: ESWC (Satellite Events), 2012, pp. 87–101. [44] B. K¨ ampgen, A. Harth, No size fits all - running the star schema benchmark with SPARQL and RDF aggregate views, in: ESWC, 2013, pp. 290–304. [45] P. Jovanovic, O. Romero, A. Simitsis, A. Abell´ o, D. Mayorova,2950 A requirement-driven approach to the design and evolution of data warehouses, Inf. Syst. 44 (2014) 94–119. 33 Appendix A. Enrichment Methodology Here, we provide a fully formalized, more general, and detailed enrichment methodology, which is agnostic of the implementation decisions made. The methodology specifies the pre-conditions, post-conditions, and transformations to be conducted by each step in terms of set theory. The method presented in Section 5is an instantiation of it.2960 The methodology considers the inputs listed below. These inputs can be generated from the outputs of Algorithm 1(i.e., allL,allP,allHS,and allLLA) as follows. We can construct the dimension hierarchies (i.e., build structures like the one in Figure 2) and generate the inputs needed by the methodology by following the detected hierarchy steps (the allHS output of Algorithm 1). Each of these structures is considered a dimension (from here on, dimension structure) that has a name assigned to it, e.g., derived from the initial level name.2970 A bottom-up traversal of the paths in this structure defines the hierarchies. On top of each dimension structure, the All level should be automatically added as the highest granularity level for all hierarchies. Thus, we obtain the inputs required for the enrichment methodology as follows. •NewLevSet, the set of the new level IRIs (e.g., schema:region), generated as the difference between the set of all levels and the set of initial levels. •DimSet, the set of dimension IRIs (e.g.,2980 schema:geoDim), generated to include an element for each dimension structure. •HierSet, the set of hierarchy IRIs (e.g., schema:geoHier), generated for each distinct traversal path in the dimension structures. •LAttSet, the set of new level attribute IRIs (e.g., schema:capital), extracted from the allLLA output of Algorithm 1. •HStepSet, the set of hierarchy step IDs, i.e., IRIs or blank node identifiers (e.g., :hs1), generated for each2990 occurrence of a hierarchy step in hierarchies. •MapLAttribute2L, a mapping of level attribute IRIs to level IRIs (e.g., (schema:capital, sdmx-dimension:refArea)), generated from the allLLA output of Algorithm 1, as pairs of IRIs. •MapH2D, a mapping of hierarchy IRIs to dimension IRIs (e.g., (schema:geoHier,schema:geoDim)), extracted from the dimension structure as pairs of IRIs. •MapH2L, a mapping of hierarchy IRIs to level IRIs (e.g., (schema:geoHier,schema:region)), extracted3000 from the dimension structure as pairs of IRIs. •MapHStep2ParentL, a mapping of hierarchy step IDs to parent level IRIs (e.g., ( :hs1, schema:region)), extracted from the dimension structure as pairs of IRIs. •MapHStep2ChildL, a mapping of hierarchy step IDs to child level IRIs (e.g., ( :hs1, sdmx-dimension:refArea)), extracted from the dimension structure as pairs of IRIs. •MapHStep2H, a mapping of hierarchy step IDs to3010 hierarchy IRIs (e.g., ( :hs1,schema:geoHier)), extracted from the dimension structure as pairs of IRIs. •MapHStep2C, a mapping of hierarchy step IDs to cardinality IRIs (e.g., ( :hs1,qb4o:ManyToOne)), extracted from the dimension structure as pairs of IRIs. •MapChild2Parent, a mapping of child level member IRIs to parent level member IRIs (e.g., (country:RS,region:ECS)), extracted from the data set(s) as pairs of IRIs according to the hierarchy step structures.3020 •MapLInstance2L, a mapping of level member IRIs to level IRIs (e.g., (country:RS, sdmx-dimension:refArea)), extracted from the data set(s) as pairs of IRIs for all levels. •MapLInstance2LAInstance, a mapping of level member IRIs to the level attribute IRI – level attribute value (that is IRI or literal) pairs (e.g., (country:RS, (schema:capital,‘‘Belgrade’’xsd:string))), extracted from the data set(s) based on the MapLAttribute2L mapping as, IRI – a pair of IRIs, or,3030 IRI – an IRI and literal pair, pairs. Taking advantage of the QB4OLAP vocabulary, we next propose a methodology to enrich a QB data set. The methodology defines the steps that need to be performed for the input QB data set in order to produce an output data set that is enriched with QB4OLAP semantics (e.g., dimension hierarchies). The methodology steps are fully automatized considering that the inputs discussed above are provided. Taking into account that the inputs generation involves some user actions, the3040 overall enrichment process is semi-automatized. The methodology steps are: 1. Redefinition of the cube schema. 2. Specification of the aggregate functions. 3. Definition of the dimension hierarchies. 4. Annotation of the cube instances. In this section, we first introduce preliminaries for the formal definition of each step. Then, each step is defined in terms of the input, tasks to be performed, and output that it produces.3050 Appendix A.1. Methodology Preliminaries We first formally define a QB graph. 34 Definition 1. A QB graph Gqb is a set of RDF triples, i.e., an RDF graph, defined as follows. •Gqb =Sqb ∪Iqb, where Sqb and Iqb are sets of triples that define the QB cube schema and instances, respectively. •Sqb =DSqb ∪DSDqb ∪Dqb ∪Mqb, where DSqb, DSDqb, Dqb, and Mqb are subsets of triples that define the cube data set, the cube structure, the cube dimen-3060 sions, and the cube measures, respectively. Following QB’s notation, the cube structure (i.e., DSDqb) is defined as a set of dimensions and measures (in QB terminology, the cube components). •Iqb =DIqb ∪Oqb, where DIqb is the subset of triples that defines all dimension instances, while Oqb is the subset of triples that defines the observations. As discussed before, observations represent measure values for the fixed dimension instances determined by DSDqb related to the data set DSqb.3070 The considered elements of the QB graph are the ones needed in our approach to create a QB4OLAP graph while the other ones are omitted. Triple examples of Sqb that are extracted from the running example (see Section 2.3) are presented in Example 23. Example 23. Sqb triples. 1<http://worldbank.270a.info/dataset/world−bank−indicators/structure> 2a qb:DataStructureDefinition ; 3qb:component [ qb:dimension sdmx−dimension:refArea ] ;3080 4qb:component [ qb:measure sdmx−measure:obsValue ] . 5sdmx−dimension:refArea a qb:DimensionProperty . 6sdmx−measure:obsValue a qb:MeasureProperty . 7<http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>a qb:DataSet ; 8qb:structure 9<http://worldbank.270a.info/dataset/world−bank−indicators/structure>. Lines 1 - 4 belong to DSDqb, line 5 to Dqb, line 6 to Mqb, and line 7 to DSqb. The data set DSqb is related to the cube structure DSDqb in lines 8 – 9 and this triple belongs to DSqb.3090 Triple examples of Iqb are presented in Example 24. Example 24. Iqb triples. 1data:world−bank−indicators/CM.MKT.LCAP.CD/RS/2012 2a qb:Observation ; 3sdmx−dimension:refArea country:RS ; 4sdmx−measure:obsValue 7450560827.04874 ; 5qb:dataSet <http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>. Lines 1 – 5 define an observation Oqb. Line 3 specifies a di-3100 mension instance that belongs to DIqb and line 4 defines a measure value of Oqb. Note that this observation relates to the cube schema structure (i.e., DSDqb) indirectly (see lines 7 – 9 of Example 23) via qb:dataSet in line 5. Analogously, we next define the output QB4OLAP graph Gqb4o in terms of sets of triples. Definition 2. A QB4OLAP graph Gqb4o is defined as follows. •Gqb4o =Sqb4o ∪Iqb4o, where Sqb4o and Iqb4o are sets of triples that define the QB4OLAP cube schema and3110 instances, respectively. •Sqb4o =DSqb4o∪DSDqb4o∪Dqb4o∪Mqb4o∪Lqb4o∪ LAqb4o∪Hqb4o∪HSqb4o∪AFqb4o∪Cqb4o, where the subsets of triples are: –DSqb4o defining the cube data set; –DSDqb4o defining the cube structure; –Dqb4o defining the cube dimensions; –Mqb4o defining the cube measures; –Lqb4o defining the dimension levels; –LAqb4o defining the dimension level attributes;3120 –Hqb4o defining the dimension hierarchies; –HSqb4o defining the hierarchy steps; –AFqb4o a predefined set of aggregate functions; and –Cqb4o a predefined set of possible cardinalities. •Iqb4o =LIqb4o ∪Oqb4o ∪LAIqb4o, where LIqb4o is the subset of triples that defines level instances and rollup relationship instances between child and parent level instances, Oqb4o is the subset of triples that defines the observations, and LAIqb4o is the subset of triples that defines level attribute values.3130 Patterns of triples and examples of QB4OLAP sets are presented below in the methodology step definitions. The examples are based on the running example (see Section 2.3). By using this formalization we define our methodology considering the scenario where the input data set contains implicit MD semantics (e.g., a country is linked to a region) that is not explicitly stated, i.e., without the semantics that this is a rollup relationship in an MD hierarchy between a country level and a region level. Other scenarios are discussed in Section 5.4.3140 Appendix A.2. Redefinition of the cube schema We start by building the new cube schema Sqb4o. For simplicity of presentation, when defining the steps we assume that from the input QB graph Gqb, we build a new QB4OLAP graph Gqb4o. We proceed incrementally and in the first step we build the schema S1 qb4o (the complete cube schema Sqb4o is the output of Step 3). S1 qb4o contains the sets DSqb4o (defining the new cube data set), DSDqb4o (defining the new cube schema structure), Lqb4o (defining the QB4OLAP dimension levels),3150 and Mqb4o (defining the measures). We populate these sets from Sqb, starting from the dimensions in Dqb that are redefined as levels in Lqb4o. Next, we copy the measures from Mqb to Mqb4o. Then, we define the new cube 35 schema structure, assign it both levels and measures, and add it to the DSDqb4o. Finally, we copy the data set definition to DSqb4o and assign the new cube schema structure to it. The details of the step are presented below. Step 1. Redefinition of the cube schema:3160 INPUT: Sqb OUTPUT: S1 qb4o Step 1.1. Redefine input dimensions as levels: •Lqb4o ∪={createLevel(d),d∈Dqb}, where createLevel is a function redefining a dimension d as a level l, i.e., taking as argument a triple defining a qb:DimensionProperty, and producing a triple defining aqb4o:LevelProperty. Triples pattern added to Lqb4o: qbDimensionIRI a qb4o:LevelProperty, where3170 qbDimensionIRI is the existing IRI of the QB dimension redefined as a QB4OLAP level. For instance, a triple related to the running example: 1sdmx−dimension:refArea a qb4o:LevelProperty . Step 1.2. Copy input measures: •Mqb4o ∪={m,m∈Mqb}, where mis a measure triple in Mqb that is added to Mqb4o. These triples are defining instances of the class qb:MeasureProperty.3180 Triples pattern added to Mqb4o: qbMeasureIRI a qb:MeasureProperty, where qbMeasureIRI is the existing IRI of the QB measure copied. For instance, a triple related to the running example: 1sdmx−measure:obsValue a qb:MeasureProperty . Step 1.3. Define the new cube schema structure and add to it levels and measures as components:3190 •DSDqb4o ∪={createDSD()}, where createDSD is a function that creates a new cube schema structure triple, i.e., defining a new qb:DataStructureDefinition. Triples pattern added to DSDqb4o: dsdIRI a qb:DataStructureDefinition, where dsdIRI is the newly defined IRI of the new schema structure definition. For instance, a triple related to the running example: 1newG:newDSD a qb:DataStructureDefinition .3200 •DSDqb4o ∪={createComponent(lm),lm ∈Lqb4o ∪ Mqb4o}, where createComponent is a function that creates a schema structure component (in this case, a blank) node to which a level or measure is related. It receives a triple lm defining a qb4o:LevelProperty or a qb:MeasureProperty and produces a triple cdefining a qb:ComponentProperty. Triples pattern added to DSDqb4o: dsdIRI qb:component [qb4o:level qbDimensi-3210 onIRI]; dsdIRI qb:component [qb:measure qbMeasureIRI]. Here, dsdIRI,qbDimensionIRI, and qbMeasureIRI are the IRIs previously introduced. Note that we include dsdIRI for better understanding. For instance, triples related to the running example: 1newG:newDSD qb:component [ qb4o:level sdmx−dimension:refArea ] ; 2qb:component [ qb:measure sdmx−measure:obsValue ] . Step 1.4. Create the QB4OLAP cube schema:3220 •S1 qb4o =DSqb4o ∪DSDqb4o ∪Lqb4o ∪Mqb4o. Initially, we add to DSqb4o the data set definition triple and the triple linking the data set to the DSD. Then, S1 qb4o represents a union of DSqb4o and the previous sets (i.e., DSDqb4o,Lqb4o, and Mqb4o) with no additional triples pattern. Triples pattern added to DSqb4o: dsIRI a qb:DataSet and dsIRI qb:structure dsdIRI, where dsIRI and dsdIRI are the IRIs of the data set and the new schema structure definition,3230 respectively. For instance, triples related to the running example: 1<http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>a qb:DataSet; 2qb:structure newG:newDSD . Thus, at this point, we have obtained S1 qb4o. Triple examples of S1 qb4o are summed up in Example 25 to illustrate the overall result of Step 1. Note that we use the newG namespace for the new graph Gqb4o.3240 Example 25. Resulting triples of Step 1. 1<http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>a qb:DataSet; 2qb:structure newG:newDSD . 3newG:newDSD a qb:DataStructureDefinition ; 4qb:component [ qb4o:level sdmx−dimension:refArea ] ; 5qb:component [ qb:measure sdmx−measure:obsValue ] . 6sdmx−dimension:refArea a qb4o:LevelProperty . 7sdmx−measure:obsValue a qb:MeasureProperty . 3250 Lines 1 and 2 illustrate the output of Step 1.4. Step 1.3. results in lines 3, 4, and 5 define the new cube schema structure and add a level and a measure as components to it. Line 6 redefines the dimension from Example 23 as a QB4OLAP level (result of Step 1.1.), while line 7 illustrates the measure from Example 23 copied in Step 1.2. Appendix A.3. Specification of the aggregate functions In this step we perform the first QB4OLAP enrichment by specifying an aggregate function for each measure. Note that possible aggregate functions are prede-3260 fined by QB4OLAP. The inputs of this step are S1 qb4o 36 and a mapping MAggMap from a measure m∈Mqb4o to an aggregate function a∈AFqb4o (introduced in Section 4.2). The aggregate function is specified as a triple that relates awith the component of the cube schema structure related to m. This triple is added to DSDqb4o and this enrichment is represented as the updated cube schema S2 qb4o that is the step output. The details of the step are presented below. Step 2. Specification of the aggregate functions3270 INPUT: S1 qb4o,MAggMap OUTPUT: S2 qb4o Step 2.1. Specify an aggregate function for each measure component of the cube schema structure: •DSDqb4o ∪={addAggFunction(getComponent(m), MAggMap(m)),m∈Mqb4o}, where: –getComponent is a function that, given a measure m, returns the schema structure component crelated to it (i.e., mis a triple defining a qb:MeasureProperty and cis a triple defining a qb:ComponentProperty (typically3280 a blank node)). –MAggMap is a mapping function from an input measure m(same as above) to the aggregate function a(i.e., ais a triple defining a qb4o:AggregateFunction (a predefined QB4OLAP aggregate function)). –addAggFunction is a function that links an aggregate function ato the corresponding component c(aand care the ones defined above). Triples pattern added to DSDqb4o: dsdIRI qb:component [qb:measure qbMeasure-3290 IRI; qb4o:aggregateFunction afIRI], where dsdIRI and qbMeasureIRI are the IRIs previously introduced and afIRI is the IRI of the aggregate function. Note that only qb4o:aggregateFunction afIRI is new in the pattern while the rest of the pattern refers to the earlier defined triples. For instance, triples related to the running example: 1newG:newDSD qb:component 2[ qb:measure sdmx−measure:obsValue ;3300 3qb4o:aggregateFunction qb4o:sum ] . Step 2.2. Create new partial cube schema: •S2 qb4o =DSqb4o ∪DSDqb4o ∪Lqb4o ∪Mqb4o.S2 qb4o represents a union of updated DSDqb4o and the DSqb4o, Lqb4o, and Mqb4o sets with no additional triples pattern. Triple examples of S2 qb4o are presented in Example 26. It is a follow-up of the previous example (i.e., Example 25). Example 26. Resulting triples of Step 2.3310 1<http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>a qb:DataSet; 2<http://worldbank.270a.info/dataset/CM.MKT.LCAP.CD>qb:structure newG:newDSD . 3newG:newDSD a qb:DataStructureDefinition ; 4qb:component [ qb4o:level sdmx−dimension:refArea ] ; 5qb:component [ qb:measure sdmx−measure:obsValue ; 6qb4o:aggregateFunction qb4o:sum ] . 7sdmx−dimension:refArea a qb4o:LevelProperty . 8sdmx−measure:obsValue a qb:MeasureProperty .3320 Line 6 presents the aggregate function that is assigned to a measure by the grouping mechanism via a blank node. We use the SUM (i.e., qb4o:sum) aggregate function as an example, while in general it depends on the input mapping (i.e., MAggMap). Appendix A.4. Definition of the dimension hierarchies We now construct the dimension hierarchies. As explained in Section 3, QB4OLAP reuses the qb:DimensionProperty, however with different se-3330 mantics than in QB: while in the latter, a dimension represents a point at a fixed granularity, QB4OLAP considers a dimension to contain points at different granularities. Therefore, in QB4OLAP, a QB dimension becomes a dimension level (see Step 1) and a dimension represents a set of levels that are hierarchically organized. Thus, the final cube schema Sqb4o is created by updating S2 qb4o and adding of additional sets of triples defining the new semantics. For their definition we use certain additional inputs about the structure of dimen-3340 sions (e.g., about new dimension levels and dimension hierarchies). In Section 4we have shown how to compute the inputs to this step. The general process is as follows. First, we update the set of levels Lqb4o obtained in Step 1, with the new levels that will define the dimension hierarchies. These new levels are specified in NewLevSet as a set of IRIs. Each level can have one or more level attributes defined in the LAqb4o set of triples (see Definition 2) added to the final cube schema Sqb4o. They are specified by the3350 input set of IRIs LAttSet. Once we have all the levels and their attributes, we use the input DimSet (a set of dimension IRIs) to create the new set of dimensions Dqb4o in the complete cube schema Sqb4o. Then, the set of hierarchies Hqb4o that represents the hierarchically ordered levels in the dimensions is added to Sqb4o. For this, the input HierSet (a set of hierarchy IRIs) is used. Finally, we add to Sqb4o the set of hierarchy steps HSqb4o that represents parent-child relationships between two levels. For this, we use the input HStepSet, a set of hi-3360 erarchy step IDs. Once levels, level attributes, dimensions, hierarchies, and hierarchy steps are defined, we must correlate them using the QB4OLAP properties. For this, we use the 37 mappings MapLAttribute2L through MapLInstance2L in the input list (see Section 4.3). The MapLAttribute2L mapping associates level attributes with levels (defining both, the “direct” association, and its “inverse”, e.g., telling that a level has an attribute, and that an attribute belongs to a dimension level, respectively);3370 MapH2D links hierarchies with dimensions; MapH2L links hierarchies with levels; MapHStep2ParentL associates a hierarchy step with its parent level, while MapHStep2ChildL does the same with its child level. Then, MapHStep2H associates a hierarchy step with the hierarchy and MapHStep2C links a hierarchy step with its corresponding cardinality. Finally, MapChild2Parent associates child level members with their parent level members while MapLInstance2L associates level members to their levels.3380 The output of this step is the complete cube schema Sqb4o. The details of the step are presented below. Step 3. Definition of the dimension hierarchies INPUT: S2 qb4o,NewLevSet,DimSet,HierSet,LAttIN, HStepSet,MapLAttribute2L,MapH2D,MapH2L, MapHStep2ParentL,MapHStep2ChildL,MapHStep2H, MapHStep2C,MapChild2Parent,MapLInstance2L OUTPUT: Sqb4o Step 3.1. Define new levels: •Lqb4o ∪={createNewLevel(newL),newL ∈3390 NewLevSet}, where createNewLevel is a function that, for each level IRI in NewLevSet, produces the corresponding triple using the qb4o:LevelProperty. Triples pattern added to Lqb4o: lIRI a qb4o:LevelProperty, where lIRI is the IRI of the new level. For instance, a triple related to the running example: 1newG:region a qb4o:LevelProperty . 3400 Step 3.2. Define level attributes: •LAqb4o ∪={createLevelAttribute(attr),attr ∈ LAttSet}, where createLevelAttribute is a function that, for each attribute IRI in LAttSet, produces the corresponding triple using the qb4o:LevelAttribute. Triples pattern added LAqb4o: laIRI a qb4o:LevelAttribute, where laIRI is the IRI of the new level attribute. For instance, a triple related to the running example: 3410 1newG:label a qb4o:LevelAttribute . Step 3.3. Define dimensions: •Dqb4o ∪={createDimension(dim),dim ∈DimSet}, where createDimension is a function that, for each dimension IRI in DimSet, produces the corresponding triple using the qb:DimensionProperty. Triples pattern added Dqb4o: dIRI a qb:DimensionProperty, where dIRI is the IRI of the new dimension. For instance, a triple related3420 to the running example: 1newG:geoDimension a qb:DimensionProperty . Step 3.4. Define hierarchies: •Hqb4o ∪={createHierarchy(hier),hier ∈HierSet}, where createHierarchy is a function that, for each hierarchy IRI in HierSet, produces the corresponding triple using the qb4o:Hierarchy. Triples pattern added Hqb4o:3430 hIRI a qb4o:Hierarchy, where hIRI is the IRI of the new hierarchy. For instance, a triple related to the running example: 1newG:geoHierarchy a qb4o:Hierarchy . Step 3.5. Define hierarchy steps: •HSqb4o ∪={createHStep(hStep),hStep ∈ HStepSet}, where createHStep is a function that, for each hierarchy step ID in HStepSet, produces the3440 corresponding triple using the qb4o:HierarchyStep. Since QB uses blank nodes for representing reification, we follow the same principle and use blank node identifiers for hierarchy steps in the examples. Triples pattern added HSqb4o: hsID a qb4o:HierarchyStep, where hsID is the ID of the new hierarchy step. For instance, a triple related to the running example: 1:newHierarchyStep a qb4o:HierarchyStep .3450 Step 3.6. Associate dimension levels with level attributes: •Lqb4o ∪={linkLevelWithAttr(MapLAttribute2L(la), la),la ∈LAqb4o}, where linkLevelWithAttr is a function that receives a pair (l,la), where lis an instance of qb4o:LevelProperty and la is an instance of qb4o:LevelAttribute, and produces a triple lla telling that the level lhas the level attribute la. MapLAttribute2L is a mapping that, given a level3460 attribute, returns the level to which the level attribute belongs. Triples pattern added Lqb4o: lIRI qb4o:hasAttribute laIRI, where lIRI and laIRI are the IRIs of the level and level attribute, respectively. For instance, a triple related to the running example: 38 1newG:region qb4o:hasAttribute newG:label . 3470 •LAqb4o ∪={linkAttrWithLevel(la, MapLAttribute2L(la)),la ∈LAqb4o}, where linkAttrWithLevel is a function that receives a pair (la,l), where la and lhave the same meaning as above, and produces a triple lal telling that the level attribute la belongs to the level l. Triples pattern added LAqb4o: laIRI qb4o:inLevel lIRI, where laIRI and lIRI are the IRIs of the level attribute and level, respectively. For instance, a triple related to the running example:3480 1newG:label qb4o:inLevel newG:region . Step 3.7. Associate dimensions with hierarchies: •Dqb4o ∪={linkDimWithHier(MapH2D(h),h),h∈ Hqb4o}, where linkDimWithHier is a function that receives a pair (d,h), where dis an instance of qb:DimensionProperty and his an instance of qb4o:Hierarchy, and produces a triple dh telling that the dimension dhas the hierarchy h.MapH2D is a mapping3490 that, given a hierarchy, returns the dimension to which the hierarchy belongs. Triples pattern added Dqb4o: dIRI qb4o:hasHierarchy hIRI, where dIRI and hIRI are the IRIs of the dimension and hierarchy, respectively. For instance, a triple related to the running example: 1newG:geoDimension qb4o:hasHierarchy newG:geoHierarchy . 3500 •Hqb4o ∪={linkHierWithDim(h,MapH2D(h)),h∈ Hqb4o}, where linkHierWithDim is a function that receives a pair (h,d), where hand dhave the same meaning as above, and produces a triple hd telling that the hierarchy hbelongs to the dimension d. Triples pattern added Hqb4o: hIRI qb4o:inDimension dIRI, where hIRI and dIRI are the IRIs of the hierarchy and dimension, respectively. For instance, a triple related to the running example:3510 1newG:geoHierarchy qb4o:inDimension newG:geoDimension . Step 3.8. Associate hierarchies with levels: •Hqb4o ∪={linkHierWithL(h,MapH2L(h)),h∈ Hqb4o}, where linkHierWithL is a function that receives a pair (h,l), where his an instance of qb4o:Hierarchy and lis an instance of qb4o:LevelProperty, and produces a triple hl telling that the hierarchy hhas the level l.MapH2L is a mapping that, given a hierarchy, returns3520 the level(s) it contains. Triples pattern added Hqb4o: hIRI qb4o:hasLevel lIRI, where hIRI and lIRI are the IRIs of the hierarchy and level, respectively. For instance, triples related to the running example: 1newG:geoHierarchy qb4o:hasLevel newG:region . 2newG:geoHierarchy qb4o:hasLevel sdmx−dimension:refArea . Step 3.9. Associate hierarchy steps with the hierar-3530 chy, levels, and cardinalities: •HSqb4o ∪={linkHStepWithH(hs,MapHStep2H( hs)),hs ∈HSqb4o}, where linkHStepWithH is a function that receives a pair (hs,h), where hs is an instance of qb4o:HierarchyStep and his an instance of qb4o:Hierarchy, and produces a triple hsh telling that the hierarchy step hs belongs to the hierarchy h. MapHStep2H is a mapping that, given a hierarchy step, returns the related hierarchy. Triples pattern added HSqb4o:3540 hsID qb4o:inHierarchy hIRI, where hsID and hIRI are the hierarchy step ID and the hierarchy IRI, respectively. For instance, a triple related to the running example: 1:newHierarchyStep qb4o:inHierarchy newG:geoHierarchy . •HSqb4o ∪={linkHStepWithParentL(hs, MapHStep2ParentL(hs)),hs ∈HSqb4o}, where linkHStepWithParentL is a function that receives a pair3550 (hs,pl), where hs is an instance of qb4o:HierarchyStep and pl is an instance of qb4o:LevelProperty, and produces a triple hspl telling that the hierarchy step hs has pl as parent level. MapHStep2ParentL is a mapping that, given a hierarchy step, returns the related parent level. Triples pattern added HSqb4o: hsID qb4o:parentLevel plIRI, where hsID and plIRI are the hierarchy step ID and the parent level IRI, respectively. For instance, a triple related to the running3560 example: 1:newHierarchyStep qb4o:parentLevel newG:region . •HSqb4o ∪={linkHStepWithChildL(hs, MapHStep2ChildL(hs)),hs ∈HSqb4o}, where linkHStepWithChildL is a function that receives a pair (hs,cl), where hs is an instance of qb4o:HierarchyStep and cl is an instance of qb4o:LevelProperty, and produces a triple hscl telling that the hierarchy step hs3570 has cl as child level. MapHStep2ChildL is a mapping that, given a hierarchy step, returns the related child level. Triples pattern added HSqb4o: hsID qb4o:childLevel clIRI, where hsID and 39 clIRI are the hierarchy step ID and the child level IRI, respectively. For instance, a triple related to the running example: 1:newHierarchyStep qb4o:childLevel sdmx−dimension:refArea .3580 •HSqb4o ∪={linkHStepWithC(hs,MapHStep2C( hs)),hs ∈HSqb4o}, where linkHStepWithC is a function that receives a pair (hs,c), where hs is an instance of qb4o:HierarchyStep and cis an instance of qb4o:Cardinality, and produces a triple hsc telling that the hierarchy step hs has cas cardinality. MapHStep2C is a mapping that, given a hierarchy step, returns the related cardinality. Triples pattern added HSqb4o:3590 hsID qb4o:pcCardinality cIRI, where hsID and cIRI are the hierarchy step ID and the cardinality IRI, respectively. For instance, a triple related to the running example: 1:newHierarchyStep qb4o:pcCardinality qb4o:ManyToOne . Step 3.10. Create the complete cube schema: •Sqb4o =DSqb4o ∪DSDqb4o ∪Dqb4o ∪Mqb4o ∪Lqb4o ∪LAqb4o ∪Hqb4o ∪HSqb4o ∪AFqb4o ∪Cqb4o.Sqb4o rep-3600 resents a union of all its subsets with no additional triples pattern. Note that AFqb4o and Cqb4o are predefined by QB4OLAP. As we have already said, the output of this step is the complete cube schema Sqb4o. Triple examples of new triples in Sqb4o are summed up in Example 27. Example 27. Resulting triples of Step 3. 1#Create a level, a level attribute, a dimension, a hierarchy, 2#and a hierarchy step3610 3newG:region a qb4o:LevelProperty . 4newG:label a qb4o:LevelAttribute . 5newG:geoDimension a qb:DimensionProperty . 6newG:geoHierarchy a qb4o:Hierarchy . 7:newHierarchyStep a qb4o:HierarchyStep . 8 9#Link the level and level attribute 10 newG:region qb4o:hasAttribute newG:label . 11 newG:label qb4o:inLevel newG:region . 123620 13 #Link dimensions and hierarchies 14 newG:geoDimension qb4o:hasHierarchy newG:geoHierarchy . 15 newG:geoHierarchy qb4o:inDimension newG:geoDimension . 16 17 #Link the hierarchy and levels, and hierarchy step 18 # with all related instances 19 newG:geoHierarchy qb4o:hasLevel newG:region . 20 newG:geoHierarchy qb4o:hasLevel sdmx−dimension:refArea . 21 :newHierarchyStep qb4o:inHierarchy newG:geoHierarchy . 22 :newHierarchyStep qb4o:parentLevel newG:region .3630 23 :newHierarchyStep qb4o:childLevel sdmx−dimension:refArea . 24 :newHierarchyStep qb4o:pcCardinality qb4o:ManyToOne . Line 3 shows a triple defining a new level, as a result of Step 3.1. Analogously, line 4 shows a triple defining a new level attribute as a result of Step 3.2. Lines 5 and 6, define a dimension and a hierarchy, resulting from applying Step 3.3. and Step 3.4., respectively. Then, line 7 defines a hierarchy step as a result of Step 3.5. Lines 10 – 11 link a level and a level attribute as the product of Step 3.6., and lines 14 – 15 link a3640 dimension and a hierarchy showing the result of Step 3.7. Finally, lines 19 – 20 associate a hierarchy with its levels as results of Step 3.8. while lines 21 – 24 link a hierarchy step and its hierarchy, levels, and cardinality as the triples produced in Step 3.9. Appendix A.5. Annotation of the cube instances Once the new cube schema is defined, we need to link the level members with their schema definitions, i.e., populate the dimension level instances. Moreover, we link the level members with their3650 level attribute instances and copy the observations to the new QB4OLAP graph. The first input of the step is MapChild2Parent that maps child level members to their parent level members. Next input is MapLInstance2L that maps level members to their levels. The MapLInstance2LAInstance input maps level members and level attribute instances. Then, the set of cube instances Iqb =DIqb ∪Oqb, where DIqb defines dimension instances and Oqb defines observations. The last input is the complete new cube schema Sqb4o. The3660 output of the step is the set of new cube instances Iqb4o =LIqb4o ∪Oqb4o ∪LAIqb4o. The details of the step are presented below. Step 4. Annotation of the cube instances INPUT: MapChild2Parent,MapLInstance2L, MapLInstance2LAInstance,Iqb,Sqb4o OUTPUT: Iqb4o Step 4.1. Copy dimension instances from Gqb as base level instances in Gqb4o: •LIqb4o ∪={copyAsLevelInstance(di),di ∈DIqb},3670 where copyAsLevelInstance is a function that receives a triple di representing a dimension instance in QB and returns a triple li defining the subject (i.e., an IRI) of the triple di as a level instance in QB4OLAP, using the qb4o:LevelMember property. Triples pattern added LIqb4o: liIRI a qb4o:LevelMember, where liIRI is the IRI of the level instance obtained from di. For instance, a triple related to the running example: 3680 1country:RS a qb4o:LevelMember . Step 4.2. Add coarser granularity level instances: 40 •LIqb4o ∪={MapChild2Parent(li),li ∈LIqb4o}, where MapChild2Parent is a mapping that, for a given dimension level instance, returns its corresponding parent level member. This object is then defined as a level instance, using the qb4o:LevelMember property. Triples pattern added LIqb4o: liIRI a qb4o:LevelMember, where liIRI is3690 the IRI of the new level instance, returned by MapChild2Parent. For instance, a triple related to the running example: 1region:ECS a qb4o:LevelMember . Step 4.3. Copy observations: •Oqb4o ∪={o,o∈Oqb}, where ois an observation from Oqb that is added to Oqb4o. Triples pattern added Oqb4o:3700 oIRI a qb:Observation,oIRI qb:dataSet dsIRI,oIRI lIRI liIRI, and oIRI mIRI mvalue, where oIRI,dsIRI,lIRI,liIRI, and mIRI are the IRIs of the observation, data set, level, level instance, and measure, respectively, while mvalue is a literal representing measure value. For instance, triples related to the running example: 1<http://worldbank.270a.info/dataset/world−bank−indicators/ 2CM.MKT.LCAP.CD/RS/2012>3710 3a qb:Observation ; 4qb:dataSet newG:newDS ; 5property:indicator indicator:CM.MKT.LCAP.CD ; 6sdmx−dimension:refArea country:RS ; 7sdmx−measure:obsValue 7450560827.04874 ; Step 4.4. Specify the level for each level instance: •LIqb4o∪={linkToLevel(li,MapLInstance2L(li)),li ∈LIqb4o}, where linkToLevel is a function that receives a pair (li,l), where li is an instance of qb4o:LevelMember3720 and lis an instance of qb4o:LevelProperty, and produces a triple lil telling that the level member li belongs to the level l.MapLInstance2L is a mapping that, given a level instance, returns the level it belongs to. Triples pattern added LIqb4o: liIRI qb4o:memberOf lIRI, where liIRI and lIRI are the IRIs of the level member and level, respectively. For instance, a triple related to the running example: 3730 1country:RS qb4o:memberOf sdmx−dimension:refArea . Step 4.5. Specify rollup (i.e., parent–child) relations between level instances: •LIqb4o∪={linkRollUps(MapChild2Parent(li),li), li ∈LIqb4o}, where linkRollUps is a function that receives a pair (pli,cli), where pli and cli are instances of qb4o:LevelMember, and produces a triple pcli telling that cli rolls-up to pli using the skos:broader property. Triples pattern added LIqb4o:3740 cliIRI skos:broader pliIRI, where cliIRI and pliIRI are the IRIs of the child and parent level instances, respectively. For instance, a triple related to the running example: 1country:RS skos:broader region:ECS . Step 4.6. Add level attribute instances: •LAIqb4o ∪={addLevelAttInstance(li, MapLInstance2LAInstance(li)),li ∈LIqb4o}, where3750 addLevelAttInstance is a function that receives li and a pair (la,lai), where li is an instance of qb4o:LevelMember,la is an instance of qb4o:LevelAttribute, and lai is a level attribute value (IRI or literal), and produces a triple lilalai telling that li has an attribute la with the value lai. MapLInstance2LAInstance is a mapping that, for a given dimension level instance, returns its level attribute – level attribute value pair(s). Triples pattern added LAIqb4o:3760 liIRI laIRI laiIRI or liIRI laIRI laiLiteral, where liIRI,laIRI, and laiIRI are the IRIs of the level instance, level attribute, and level attribute value, respectively, and laiLiteral is a literal representing level attribute value. For instance, a triple related to the running example: 1country:RS schema:capital ‘‘Belgrade’’xsd:string . Step 4.7. Create new cube instances:3770 •Iqb4o =LIqb4o ∪Oqb4o ∪LAIqb4o.Iqb4o represents a union of LIqb4o (i.e., the level members), Oqb4o (i.e., observations), and LAIqb4o (i.e., the level attribute instances) with no additional triples pattern. The output of this step is Iqb4o. Triple examples of Iqb4o are summed up in Example 28. This example follows our running example and is an extension of previous ones. Example 28. Resulting triples of Step 4. 3780 1country:RS a qb4o:LevelMember . 2region:ECS a qb4o:LevelMember . 3<http://worldbank.270a.info/dataset/world−bank−indicators/ 4CM.MKT.LCAP.CD/RS/2012> 5a qb:Observation ; 6qb:dataSet newG:newDS ; 7property:indicator indicator:CM.MKT.LCAP.CD ; 8sdmx−dimension:refArea country:RS ; 9sdmx−measure:obsValue 7450560827.04874 ; 103790 11 country:RS qb4o:memberOf sdmx−dimension:refArea . 12 country:RS skos:broader region:ECS . 13 country:RS schema:capital ‘‘Belgrade’’xsd:string . 41