A major part of Open Data concerns statistics such as economic and social indicators. Statistical data are structured in a multidimensional manner creating data cubes. Recently, National Statistical Institutes and public authorities adopted the Linked Data paradigm to publish their statistical data on the Web. Many vocabularies have been created to enable modeling data cubes as RDF graphs, and thus creating Linked Open Statistical Data (LOSD). However, the creation of LOSD remains a demanding task mainly because of modeling challenges related either to the conceptual de nition of the cube, or to the way of modeling cubes as linked data. The aim of this paper is to identify and clarify (a) modeling challenges related to the creation of LOSD and (b) approaches to address them. Towards this end, LOSD experts were involved in an interactive feedback collection and consensus-building process that was based on Delphi method. We anticipate that the results of this paper will contribute towards the formulation of best practices for creating LOSD, and thus facilitate combining and analysing statistical data from diverse sources on the Web.
International organizations, governments, and companies are increasingly
opening up their data for others to reuse [
Linked data has been introduced as a promising paradigm for opening up data
because it facilitates data integration on the Web [
Many vocabularies have been created to enable modeling data cubes as RDF graphs. However, the creation of Linked Open Statistical Data (LOSD) remains a demanding task mainly because of modeling challenges related either to the conceptual de nition of a cube, or to the way of modeling cubes as linked data. The former regards challenges such as the number of measures or the number of units to include in a cube, while the latter is related to the lack of clarity on the way to apply the proposed vocabularies and the lack of specialized standards. All the above modeling challenges are currently addressed by data publishers in an ad hoc manner, and thus they hinder publishing LOSD in a uniform way that would facilitate their wide exploitation.
The aim of this paper is to identify modeling challenges related to the creation of LOSD and approaches to address them. Towards this end, nine LOSD experts were involved in an interactive feedback collection and consensus-building process. The experts indicated and evaluated modeling challenges and approaches to address them. The goal is to build a consensus on the approaches that can be adopted to address LOSD modeling challenges.
The rest of the paper is organized as follows: Section 2 presents the method that was followed, Section 3 presents the state of the art analysis regarding LOSD standards. Section 4 brie y presents the results of the Delphi method. Finally, Section 5 discusses open challenges and Section 6 summarizes the results. 2
The method employed for the LOSD experts involvement is Delphi [
Round 1: Usually the rst round uses an open-ended questionnaire. However, we adopted a common modi cation that uses a structured (aka closed) questionnaire based upon a preparatory phase. The preparatory phase contained: (i) state of the art analysis on the data cube model to identify the main LOSD modeling constructs, (ii) involvement of experts to identify LOSD modeling challenges, and (iii) analysis of LOSD standards to identify approaches related to the modeling challenges. The structured questionnaire asked experts to review, select or rank the initially identi ed approaches related to the modeling challenges. As a result, areas of disagreement/agreement were identi ed. The results included advantages/disadvantages of the publishing approaches as well as other publishing approaches not identi ed at the preparatory phase.
Round 2: The collected feedback of the rst round was organized and a second questionnaire was created. This questionnaire was re-structured to be more comprehensive and incorporated the advantages/disadvantages identi ed at the rst round to provide additional insights to the experts. It also contained approaches of the rst round in which consensus was achieved so that experts can review them. In every question, the experts were asked to state the rationale behind their choice. The result of Round 2 included all the LOSD modeling challenges, an analysis of the approaches related to these challenges, and all the approaches where consensus was achieved.
The selection of appropriate experts is very important in a Delphi study since it a ects the quality of the produced results. Usually, around ten experts are su cient. In our study, we included 9 experts in the area of LOSD: { An expert involved in the creation of the LOSD portals of the Scottish Government (http://statistics.gov.scot) and the UK Department for Communities and Local Government (http://opendatacommunities.org). { An expert involved in publishing of LOSD for the Flemish Government (https://id.milieuinfo.be). { An expert involved in the creation of the LOSD portal for the European
Commission's Digital Agenda (http://digital-agenda-data.eu/data). { An expert involved in the creation of the portal of the Italian National
Institute of Statistics (http://datiopen.istat.it). { An expert involved in the creation of the QB vocabulary. { An expert who created LOSD using data from international organizations such as Eurostat, OECD, IMF and World Bank. { An expert working at National Institute of Statistics and Economic Studies. { An expert working in academia. { An expert working in industry.
The study took place in 2017 and comprised two rounds that lasted two months each. In order to facilitate the process we exploited Mesydel3 an online service that supports Delphi enabling the participation of multiple experts. 3
Statistical data usually concern aggregated data monitoring social and economic
indicators [
A number of linked data standard vocabularies have been proposed to enable
the publishing of data cubes. The QB vocabulary [
publishing data cubes. The core class of the vocabulary is the qb:DataSet that represents a cube, which comprises a set of dimensions (qb:DimensionProperty ), measures (qb:MeasureProperty ), and attributes (qb: AttributeProperty ). Each qb:DataSet has multiple qb:Observation that describe the cells of the cube.
At LOSD it is a common practice to re-use prede ned code lists to populate
the dimension values. For example, the values of the time dimension can be
obtained from the code list de ned by reference.data.gov.uk or the values of
the unit of measure can be obtained from the QUDT units vocabulary4. However,
prede ned code lists does not always exist, so new should be speci ed using the
QB vocabulary or the Simple Knowledge Organization System (SKOS) [
Finally, a UK Government Linked Data Working Group5 has developed a set of common dimensions (timePeriod, refArea, sex, age), measures (obsValue) and attributes ( unitMeasure) that are intended to be reusable across data sets. The de nition of these concepts is based on the SDMX guidelines.
All the above standard vocabularies facilitate the publishing of LOSD. However, in some cases there is lack of clarity on how to apply these standards because they allow the adoption of di erent valid publishing approaches. 4
This section brie y presents the results of the Delphi method. Tables 1 and 2 contain all the identi ed LOSD modeling challenges and the approaches where consensus was achieved among the experts. The following paragraphs elaborate on some challenges and approaches that need further clari cation.
At measure de nition (Ch1), a common property is sdmx-measure:obsValue. However, experts indicated that it should not be used because de ning a measure as sub-property of sdmx-measure:obsValue is redundant. It does not add any additional semantics than de ning the measure as a qb:MeasureProperty.
Regarding the de nition of unit (Ch2.3) the QB vocabulary enables di erent levels, i.e., the qb:DataSet, the qb:MeasureProperty, and the qb:Observation. The level qb:DataSet or the qb:MeasureProperty facilitates the retrieval of units directly from the structure of the cube. While the level qb:MeasureProperty or the qb:Observation enables the de nition of multiple units at one cube. The qb:Observation level enables observation to be re-used at another context since they contain all relevant information. Expert proposed to use a hybrid approach and de ne the unit both at qb:Observation and qb:DataSet if needed.
The QB vocabulary proposes two practices for the de nition of multiple measures per cube (Ch4): i) \multi-measure observations" that de ne multiple qb:MeasureProperty in the cube structure and use all measures in every observation and ii) \measure dimension" that de nes multiple qb:MeasureProperty at the structure, but restrict observations to having a single measure. The rst approach produces smaller in sizes cube but cannot represent multiple units and
eCh1:What property Ap1: A new measure property should be de ned that is not rushould be used to sub-property of sdmx-measure:obsValue. The new measure ens amodel a measure of a ables the annotation with additional properties (e.g., labels, e Mcube? comments).
Ch2.1:Should a Ap2.1: A unit of measure should always be included in the cube. cube include the unit The measure on its own is a plain numerical value and thus unit of the measure? is required to correctly interpret this value.
Ch2.2: What RDF Ap2.2: sdmx-attribute:unitMeasure should always be re-used property should be to de ne units. This property can be used directly to assign used to de ne the values that are not part of a code list (e.g., QUDT). However, unit? when annotation with additional properties (e.g., labels, codeitn list, etc.) is required, then new units that are sub-properties of U sdmx-attribute:unitMeasure should be de ned. Ch2.3:Where should Ap2.3: The unit should be de ned at the qb:Observation. The the unit be de ned? unit can be additionally de ned at the qb:DataSet in order to facilitate the retrieval of the available units in a cube.
Ch2.4:What values Ap2.4: URIs from QUDT should be re-used. If QUDT is not should be used for su cient, then DBpedia or other code lists can be used. the units? sCh3.1: Should one Ap3: One cube with multiple units should be created and the t incube include multi- unit should be de ned at each qb:Observation. Conceptually, it eple units for the same is preferable to have all related units of the same measure in u lipmeasure? the same cube. The unit can be additionally de ned at the t luCh3.2: Where to de- qb:DataSet in order to facilitate the retrieval of the available Mne multiple units? units in a cube.
Ch4: How to Ap4.1: If the data have multiple measures, then it is common model to publish cubes with multiple measures only when measures smultiple are closely related to a single observational event (e.g. sensor remeasures per network measurements). However, the approach to be followed saucube? is up to the data cube publisher. In case of modeling multiple em measures in multiple cubes with one measure each, then Ap2 le (if the measures have one unit) and Ap3 (if the measures have iltpu mAupl4ti.p2l:eIunnciatss)e sohfomuloddebleinfgolmlouwletdip.le measures in one cube then M the measure dimension approach (i.e. observations with a single measure) should be followed and the unit should be de ned in each observation (see Ap 3).
Ch5: What Ap5.1: If a dimension refers to time, geography, or rdf:Properties age, then a new qb:DimensionProperty should be de ned. should be This new qb:DimensionProperty should be also de ned as used for rdfs:subPropertyOf the corresponding SDMX dimension. For exncommon ample, a geospatial dimension of a cube should be de ned as isodimensions? sub-property of sdmx-dimension:refArea. en Ap5.2: If a dimension refers to gender, then sdmxim dimension:sex should be reused provided that the associated D code list addresses the modeling needs, e.g., more notions of sex such as hermaphroditism, transgender, and asexual are not needed. Otherwise, a new dimension should be de ned along with a controlled vocabulary.
Ch6: How to Ap6.1: The rdfs:range of a qb:DimensionProperty should alsassociate a ways be de ned. leudimension to its Ap6.2: If a code list is modelled as skos:ConceptScheme, avvalues? qb:HierarchicalCodeList, or skos:Collection, then it should be .m associated with the qb:DimensionProperty using the qb:codeList iD property. In addition, the object that is related to the rdfs:range property should be set to skos:Concept.
Ch7.1: What values Ap7.1a: In case of a speci c point in time a new dimension should be used in should be de ned. This dimension should be rdfs:subPropertyOf time related sdmx-dimension:refPeriod and have rdfs:range xsd:dateTime. dimensions? Ap7.1b: In case of a period of time, a new dimension should se be de ned. This dimension should be rdfs:subPropertyOf sdmxlau dimension:refPeriod and have rdfs:range the interval:Interval vn class of the http://reference.data.gov.uk, which uses this iso class to de ne years. However, if the approach of http:// en reference.data.gov.uk is not su cient, then new code lists im can be also created and used . dnCh7.2: What val- Ap7.2:In case of a geography or age a new dimension should oues should be used be de ned. This dimension should be rdfs:subPropertyOf the m min geospatial dimen- sdmx-dimension:refArea or sdmx-dimension:age respectively. oCsions? The rdfs:range and/or qb:codeList of this dimension should be Ch7.3: What values de ned as described in Ap6.2. If a code list or reference dataset should be used in age that addresses the modeling needs exists, then it should be related dimensions? re-used. Otherwise, a new code list should be created. eCh8: How to model Ap8: A single value dimension should be always included in all l ignSssiionnglse? value dimen- observations of the cube Ch9.1: How to Ap9.1: A code list should be modelled using SKOS. This is also model a new code suggested by the QB vocabulary. Speci cally, individual code list? values should be modelled using skos:Concept and the overall set of values should be modelled using skos:ConceptScheme or skos:Collection. Always de ne a separate code list for each distinct set of values (e.g., age groups and geographical areas).
Ch9.2: How to Ap9.2: In case of hierarchical data, hierarchical code lists should itsmodel hierarchical be always used to describe them. SKOS should be preferred lestructures in a code when the hierarchies are simple. In case where the hierarchical odlist? levels are fully separated and depth is a meaningful concept then C XKOS is appropriate. Finally, when there is a need to express more relations that are not covered by SKOS or XKOS (e.g., administeredBy in contrast to within) then the QB vocabulary should be preferred.
Ch9.3: Should ag- Ap9.3: Aggregate values (e.g., Total) should be included in a gregate values be in- dimension if the measured variable in this dimension can be cluded as dimension aggregated. The aggregate value should be modelled on the top values? a hierarchy. measures while the second approach enables the de nition of multiple units and multiple measures. Experts proposed the use of the \measure dimension".
The association of a dimension to its potential values (Ch6) can be achieved using two complementary approaches: i) use the property rdfs:range to de ne the class of the values of a qb:DimensionProperty and ii) use the property qb:codeList to associate a qb:DimensionProperty with a code list. Experts proposed to use always the rdfs:range and the qb:codeList when a code list is available.
Some datasets describe a measure using only a single value of a dimension (Ch8) e.g. census data describe measures for a speci c year. The QB vocabulary enables de ning this single value at di erent levels: i) qb:Dataset, ii) qb:Slice and iii) qb:Observation. The rst does not enable future addition of observations with a di erent value for that particular dimension while the second imposes an extra burden of de ning qb:Slices. The last approach is proposed by the experts since it enables the addition of observations with di erent dimension values in the same dataset and the easy re-use of qb:Observations at another context. This approach has, however, the cost of an increased number of triples. 5
During the Delphi process experts indicated a number of open challenges. These open challenges regard, limitations of existing standards, lack of standards and modeling decisions. An important challenge is the de nition of code lists for measures that could be re-used by LOSD publishers. Currently each publisher de nes its own qb:MeasureProperty for the same measure (e.g. p1:unemployment and p2:unemployment ). The de nition of a \standard" code list would enable the publishing of LOSD in a uniform way, thus facilitating the integration and combination of related statistical data from di erent sources. Another challenge is related with the method a measure is calculated. For example, unemployment can be calculated based on di erent methods or di erent base periods. In this case there is a discussion whether to use the same qb:MeasureProperty or not.
Composite measures may be derived from other measures [
A modeling challenge is related to the de nition of multiple measures at a cube. Our study has shown that cubes with multiple measures should be published only when measures are closely related to a single observational event (e.g. sensor measurements). If the measures are independent then they should be modelled at separate cubes. However, there's a large grey area between the two since the "observational event" is not clearly de ned.
Finally, there are some challenges related with the performance of applications that consume LOSD. For instance, the use of the qb:codeList indicates all the potential values of a qb:DimensionProperty. However, it is common to not use all the values at the cube e.g. a code list may contain values for the geography of Europe, but the cube uses only values for Greece. In this case there is no way to retrieve only the used values from the cube structure. They can be only retrieved by demanding SPARQL queries that iterate over all the cube observations. The same case also applies to units of measure. 6
A major part of open data concern statistics. Recently many National Statistical Institutes and public authorities have adopted the linked data paradigm to publish LOSD since it facilitates data integration on the Web. Towards this direction many standard vocabularies have been proposed (i.e., QB, SKOS, XKOS).
The publication of high quality LOSD can be an important primary material for added value services, which can increase government transparency, contribute to economic growth and provide social value. However, the creation of LOSD remains a demanding task because of modelling challenges. These challenges are usually addressed by data publishers in an ad hoc manner thus hindering the publishing of LOSD in a uniform way and lead to the creation of LOSD silos. As a result LOSD from di erent sources cannot be easily integrated and generic software tools cannot be developed.
Towards this direction, experts that directly participate at the publishing of LOSD, are involved through an iterative approach in order to comprehend the modeling challenges, identify relevant publishing approaches and propose ways to address these challenges. The result is a set of proposed approaches that support LOSD publishers to model their data and to apply common standards. However a set of open challenges related with the limitations of existing standards, lack of standards and modeling decisions still remain to be explored.
We anticipate that the analysis of the modelling challenges as well as the proposed approaches presented at this paper will trigger and contribute towards a discussion on the development of best practices for publishing LOSD, facilitating the combining and analysing of linked statistical data from diverse sources.
This paper is an extended abstract of [