--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/data-cube/Overview.html Mon Mar 11 17:00:19 2013 +0000
@@ -0,0 +1,2938 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+ <title>The RDF Data Cube Vocabulary</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
+
+<!-- <script type="text/javascript" src="respec-ref.js" class="remove"></script> -->
+
+
+<!-- <script type="text/javascript" src="../respec/gld-config.js" class="remove"></script> -->
+
+
+ <style type="text/css">
+.todo { background-color: #fdd; border: 1px solid #800; margin: 1em 0em; padding: 1em; page-break-inside: avoid ; font-style: italic; }
+.todo:before { content: 'TODO: '; }
+.spare-table { border-collapse: collapse; margin-left: 5ex; }
+.spare-table thead { border-bottom: black 1px solid; }
+.spare-table td { padding-left: 1em; padding-right: 1em; }
+.spare-table td + td { border-left: black 1px solid; padding-left: 1em; padding-right: 1em; }
+.spare-table th + th { border-left: black 1px solid; }
+dl.vocab_reference dt { margin-top: 1em; }
+.bordered-table { border: black 1px solid;}
+.bordered-table th { border-bottom: black 1px solid;}
+.bordered-table td { padding-right: 1em; background: #fcfaee }
+table#example-data { border: black 1px solid; border-collapse:collapse; border-spacing: 0; }
+table#example-data td { border: black 1px solid; padding: 3px; text-align: right; }
+ </style>
+<style>/*****************************************************************
+ * ReSpec 3 CSS
+ * Robin Berjon - http://berjon.com/
+ *****************************************************************/
+
+/* --- INLINES --- */
+em.rfc2119 {
+ text-transform: lowercase;
+ font-variant: small-caps;
+ font-style: normal;
+ color: #900;
+}
+
+h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
+h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
+ border: none;
+}
+
+dfn {
+ font-weight: bold;
+}
+
+a.internalDFN {
+ color: inherit;
+ border-bottom: 1px solid #99c;
+ text-decoration: none;
+}
+
+a.externalDFN {
+ color: inherit;
+ border-bottom: 1px dotted #ccc;
+ text-decoration: none;
+}
+
+a.bibref {
+ text-decoration: none;
+}
+
+cite .bibref {
+ font-style: normal;
+}
+
+code {
+ color: #ff4500;
+}
+
+
+/* --- --- */
+ol.algorithm { counter-reset:numsection; list-style-type: none; }
+ol.algorithm li { margin: 0.5em 0; }
+ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; }
+
+/* --- TOC --- */
+.toc a, .tof a {
+ text-decoration: none;
+}
+
+a .secno, a .figno {
+ color: #000;
+}
+
+ul.tof, ol.tof {
+ list-style: none outside none;
+}
+
+.caption {
+ margin-top: 0.5em;
+ font-style: italic;
+}
+
+/* --- TABLE --- */
+table.simple {
+ border-spacing: 0;
+ border-collapse: collapse;
+ border-bottom: 3px solid #005a9c;
+}
+
+.simple th {
+ background: #005a9c;
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+}
+
+.simple th[scope="row"] {
+ background: inherit;
+ color: inherit;
+ border-top: 1px solid #ddd;
+}
+
+.simple td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+}
+
+.simple tr:nth-child(even) {
+ background: #f0f6ff;
+}
+
+/* --- DL --- */
+.section dd > p:first-child {
+ margin-top: 0;
+}
+
+.section dd > p:last-child {
+ margin-bottom: 0;
+}
+
+.section dd {
+ margin-bottom: 1em;
+}
+
+.section dl.attrs dd, .section dl.eldef dd {
+ margin-bottom: 0;
+}
+</style><style>/* --- EXAMPLES --- */
+div.example-title {
+ min-width: 7.5em;
+ color: #b9ab2d;
+}
+div.example-title span {
+ text-transform: uppercase;
+}
+aside.example, div.example, div.illegal-example {
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+}
+div.illegal-example { color: red }
+div.illegal-example p { color: black }
+aside.example, div.example {
+ padding: .5em;
+ border-left-width: .5em;
+ border-left-style: solid;
+ border-color: #e0cb52;
+ background: #fcfaee;
+}
+
+aside.example div.example {
+ border-left-width: .1em;
+ border-color: #999;
+ background: #fff;
+}
+aside.example div.example div.example-title {
+ color: #999;
+}
+</style><style>/* --- ISSUES/NOTES --- */
+div.issue-title, div.note-title {
+ padding-right: 1em;
+ min-width: 7.5em;
+ color: #b9ab2d;
+}
+div.issue-title { color: #e05252; }
+div.note-title { color: #52e052; }
+div.issue-title span, div.note-title span {
+ text-transform: uppercase;
+}
+div.note, div.issue {
+ margin-top: 1em;
+ margin-bottom: 1em;
+}
+.note > p:first-child, .issue > p:first-child { margin-top: 0 }
+.issue, .note {
+ padding: .5em;
+ border-left-width: .5em;
+ border-left-style: solid;
+}
+div.issue, div.note {
+ padding: 0.5em;
+ margin: 1em 0;
+ position: relative;
+ clear: both;
+}
+span.note, span.issue { padding: .1em .5em .15em; }
+
+.issue {
+ border-color: #e05252;
+ background: #fbe9e9;
+}
+.note {
+ border-color: #52e052;
+ background: #e9fbe9;
+}
+
+
+</style><link rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='http://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
+
+<body><div class="head">
+ <p>
+
+ <a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a>
+
+ </p>
+ <h1 class="title" id="title">The RDF Data Cube Vocabulary</h1>
+
+ <h2 id="w3c-working-draft-12-march-2013"><abbr title="World Wide Web Consortium">W3C</abbr> Working Draft 12 March 2013</h2>
+ <dl>
+
+ <dt>This version:</dt>
+ <dd><a href="http://www.w3.org/TR/2013/WD-vocab-data-cube-20130312/">http://www.w3.org/TR/2013/WD-vocab-data-cube-20130312/</a></dd>
+ <dt>Latest published version:</dt>
+ <dd><a href="http://www.w3.org/TR/vocab-data-cube/">http://www.w3.org/TR/vocab-data-cube/</a></dd>
+
+
+ <dt>Latest editor's draft:</dt>
+ <dd><a href="https://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html">https://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html</a></dd>
+
+
+
+
+
+ <dt>Previous version:</dt>
+ <dd><a href="http://www.w3.org/TR/2012/WD-vocab-data-cube-20120405/">http://www.w3.org/TR/2012/WD-vocab-data-cube-20120405/</a></dd>
+
+
+ <dt>Editors:</dt>
+ <dd><a href="http://richard.cyganiak.de/">Richard Cyganiak</a>, <a href="http://www.deri.ie/">DERI, NUI Galway</a></dd>
+<dd><span>Dave Reynolds</span>, <a href="http://www.epimorphics.com/">Epimorphics Ltd</a></dd>
+
+
+ <dt>Contributor:</dt> <dd><a href="http://www.jenitennison.com/">Jeni Tennison</a></dd></dl>
+
+
+
+ <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
+
+
+ <hr>
+</div>
+
+<section id="abstract" class="introductory"><h2>Abstract</h2>
+<p>There are many situations where it would be useful to be able to
+publish
+multi-dimensional data, such as statistics, on the web in such a way
+that it can be linked to related data sets and concepts. The Data Cube
+vocabulary provides a means to do this using the <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/TR/REC-rdf-syntax/">RDF</a>
+(Resource Description Framework) standard. The model underpinning the
+Data Cube vocabulary is
+compatible with the cube model that underlies <a href="http://sdmx.org">SDMX</a> (Statistical Data
+and Metadata eXchange), an ISO standard for exchanging and sharing
+statistical data and metadata among organizations. The Data Cube
+vocabulary is a core foundation which supports extension
+vocabularies to enable publication of other aspects of
+statistical data flows or other multi-dimensional data sets.</p>
+</section><section id="sotd" class="introductory"><h2>Status of This Document</h2>
+
+
+
+ <p>
+ <em>This section describes the status of this document at the time of its publication. Other
+ documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision
+ of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports
+ index</a> at http://www.w3.org/TR/.</em>
+ </p>
+
+ <p>This publication transitions <a href="http://publishing-statistical-data.googlecode.com/svn/trunk/specs/src/main/html/cube.html">previous work</a> on this subject onto the <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation Track.</p>
+
+ <p>
+ This document was published by the <a href="http://www.w3.org/2011/gld/">Government Linked Data Working Group</a> as a Last Call Working Draft.
+
+ This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
+
+
+ If you wish to make comments regarding this document, please send them to
+ <a href="mailto:public-gld-comments@w3.org">public-gld-comments@w3.org</a>
+ (<a href="mailto:public-gld-comments-request@w3.org?subject=subscribe">subscribe</a>,
+ <a href="http://lists.w3.org/Archives/Public/public-gld-comments/">archives</a>).
+
+ The Last Call period ends 08 April 2013.
+
+
+ All comments are welcome.
+
+
+ </p><p>
+ Publication as a Last Call Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership.
+ This is a draft document and may be updated, replaced or obsoleted by other documents at
+ any time. It is inappropriate to cite this document as other than work in progress.
+ </p>
+
+
+ <p>
+ This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the
+ relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.
+ </p>
+
+ <p>
+
+ This document was produced by a group operating under the
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+
+
+
+
+ <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/47663/status" rel="disclosure">public list of any patent disclosures</a>
+
+ made in connection with the deliverables of the group; that page also includes instructions for
+ disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
+ <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the
+ information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
+ 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
+
+
+ </p>
+
+
+
+
+</section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#outline" class="tocxref"><span class="secno">1. </span>Outline of the vocabulary</a><ul class="toc"><li class="tocline"><a href="#index" class="tocxref"><span class="secno">1.1 </span>Vocabulary index</a></li></ul></li><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">2. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#intro-rdf" class="tocxref"><span class="secno">2.1 </span>RDF and Linked Data</a></li><li class="tocline"><a href="#intro-sdmx" class="tocxref"><span class="secno">2.2 </span>SDMX and related standards</a></li><li class="tocline"><a href="#intro-audience" class="tocxref"><span class="secno">2.3 </span>Audience and scope</a></li></ul></li><li class="tocline"><a href="#namespaces" class="tocxref"><span class="secno">3. </span>Namespaces and Document Conventions</a></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">4. </span>Conformance</a></li><li class="tocline"><a href="#data-cubes" class="tocxref"><span class="secno">5. </span>Data cubes</a><ul class="toc"><li class="tocline"><a href="#cubes-model" class="tocxref"><span class="secno">5.1 </span>The cube model - dimensions, attributes, measures</a></li><li class="tocline"><a href="#cubes-slices" class="tocxref"><span class="secno">5.2 </span>Introducing Slices</a></li><li class="tocline"><a href="#example" class="tocxref"><span class="secno">5.3 </span>An example</a></li></ul></li><li class="tocline"><a href="#dsd" class="tocxref"><span class="secno">6. </span>Creating data structure definitions</a><ul class="toc"><li class="tocline"><a href="#dsd-dimensions" class="tocxref"><span class="secno">6.1 </span>Dimensions, attributes and measures</a></li><li class="tocline"><a href="#dsd-cog" class="tocxref"><span class="secno">6.2 </span>Content oriented guidelines</a></li><li class="tocline"><a href="#dsd-example" class="tocxref"><span class="secno">6.3 </span>Example</a></li><li class="tocline"><a href="#dsd-dsd" class="tocxref"><span class="secno">6.4 </span>ComponentSpecifications and DataStructureDefinitions</a></li><li class="tocline"><a href="#dsd-mm" class="tocxref"><span class="secno">6.5 </span>Handling multiple measures</a><ul class="toc"><li class="tocline"><a href="#dsd-mm-obs" class="tocxref"><span class="secno">6.5.1 </span>Multi-measure observations</a></li><li class="tocline"><a href="#dsd-mm-dim" class="tocxref"><span class="secno">6.5.2 </span><span>Measure dimension</span></a></li></ul></li></ul></li><li class="tocline"><a href="#datasets" class="tocxref"><span class="secno">7. </span>Expressing data sets</a><ul class="toc"><li class="tocline"><a href="#dataset-basic" class="tocxref"><span class="secno">7.1 </span>Data sets and observations</a></li><li class="tocline"><a href="#slices" class="tocxref"><span class="secno">7.2 </span>Slices and groups of observations</a></li></ul></li><li class="tocline"><a href="#schemes" class="tocxref"><span class="secno">8. </span>Concept schemes and code lists</a><ul class="toc"><li class="tocline"><a href="#schemes-intro" class="tocxref"><span class="secno">8.1 </span>Coded values for components properties</a></li><li class="tocline"><a href="#schemes-hierarchy" class="tocxref"><span class="secno">8.2 </span>Hierarchical code lists</a></li><li class="tocline"><a href="#schemes-hierarchy-nonskos" class="tocxref"><span class="secno">8.3 </span>Non-SKOS hierarchies</a></li><li class="tocline"><a href="#schemes-aggregation" class="tocxref"><span class="secno">8.4 </span>Aggregation</a></li></ul></li><li class="tocline"><a href="#metadata" class="tocxref"><span class="secno">9. </span>DataSet metadata</a><ul class="toc"><li class="tocline"><a href="#metadata-categorization" class="tocxref"><span class="secno">9.1 </span>Categorizing a data set</a></li><li class="tocline"><a href="#metadata-publishers" class="tocxref"><span class="secno">9.2 </span>Describing publishers</a></li></ul></li><li class="tocline"><a href="#normalize" class="tocxref"><span class="secno">10. </span>Abbreviated and normalized data cubes</a><ul class="toc"><li class="tocline"><a href="#normalize-algorithm" class="tocxref"><span class="secno">10.1 </span>Normalization algorithm</a></li></ul></li><li class="tocline"><a href="#wf" class="tocxref"><span class="secno">11. </span>Well-formed cubes</a><ul class="toc"><li class="tocline"><a href="#wf-rules" class="tocxref"><span class="secno">11.1 </span>Integrity constraints</a></li></ul></li><li class="tocline"><a href="#vocab-reference" class="tocxref"><span class="secno">12. </span>Vocabulary reference</a><ul class="toc"><li class="tocline"><a href="#reference-datasets" class="tocxref"><span class="secno">12.1 </span>DataSets</a></li><li class="tocline"><a href="#reference-observations" class="tocxref"><span class="secno">12.2 </span>Observations</a></li><li class="tocline"><a href="#reference-slices" class="tocxref"><span class="secno">12.3 </span>Slices</a></li><li class="tocline"><a href="#reference-components" class="tocxref"><span class="secno">12.4 </span>Dimensions, Attributes, Measures</a></li><li class="tocline"><a href="#reference-component-properties" class="tocxref"><span class="secno">12.5 </span>Reusable general purpose component properties</a></li><li class="tocline"><a href="#reference-dsd" class="tocxref"><span class="secno">12.6 </span>Data Structure Definitions</a></li><li class="tocline"><a href="#reference-compspec" class="tocxref"><span class="secno">12.7 </span>Component specifications - for qualifying component use in a DSD</a></li><li class="tocline"><a href="#reference-slice-definitions" class="tocxref"><span class="secno">12.8 </span>Slice definitions</a></li><li class="tocline"><a href="#reference-concepts" class="tocxref"><span class="secno">12.9 </span>Concepts</a></li><li class="tocline"><a href="#reference-nonskos-hierarchy" class="tocxref"><span class="secno">12.10 </span>Non-SKOS Hierarchies</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#change-history" class="tocxref"><span class="secno">B. </span>Change history </a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></section>
+
+
+
+
+<section id="outline">
+<!--OddPage--><h2><span class="secno">1. </span>Outline of the vocabulary</h2>
+
+<!-- <img src="images/qb-fig1.png" alt="UML-style block diagram of the terms in this vocabulary"/> -->
+
+<img src="images/qb-fig1-proposed.png" alt="UML-style block diagram of the terms in this vocabulary">
+
+<section id="index">
+<h3><span class="secno">1.1 </span>Vocabulary index</h3>
+
+ <p><b>Classes:</b>
+ <a href="#ref_qb_Attachable">qb:Attachable</a>
+ <a href="#ref_qb_AttributeProperty">qb:AttributeProperty</a>
+ <a href="#ref_qb_CodedProperty">qb:CodedProperty</a>
+ <a href="#ref_qb_ComponentProperty">qb:ComponentProperty</a>
+ <a href="#ref_qb_ComponentSet">qb:ComponentSet</a>
+ <a href="#ref_qb_ComponentSpecification">qb:ComponentSpecification</a>
+ <a href="#ref_qb_DataSet">qb:DataSet</a>
+ <a href="#ref_qb_DataStructureDefinition">qb:DataStructureDefinition</a>
+ <a href="#ref_qb_DimensionProperty">qb:DimensionProperty</a>
+ <a href="#ref_qb_MeasureProperty">qb:MeasureProperty</a>
+ <a href="#ref_qb_Observation">qb:Observation</a>
+ <a href="#ref_qb_Slice">qb:Slice</a>
+ <a href="#ref_qb_ObservationGroup">qb:ObservationGroup</a>
+ <a href="#ref_qb_SliceKey">qb:SliceKey</a>
+ <a href="#ref_qb_Hierarchy">qb:HierarchicalCodeList</a>
+ <a href="#ref_qb_AggregatableHierarchy">qb:AggregatableHierarchy</a>
+ </p>
+ <p><b>Properties:</b>
+ <a href="#ref_qb_attribute">qb:attribute</a>
+ <a href="#ref_qb_codeList">qb:codeList</a>
+ <a href="#ref_qb_component">qb:component</a>
+ <a href="#ref_qb_componentAttachment">qb:componentAttachment</a>
+ <a href="#ref_qb_componentProperty_LC">qb:componentProperty</a>
+ <a href="#ref_qb_componentRequired">qb:componentRequired</a>
+ <a href="#ref_qb_concept">qb:concept</a>
+ <a href="#ref_qb_dataSet_LC">qb:dataSet</a>
+ <a href="#ref_qb_dimension">qb:dimension</a>
+ <a href="#ref_qb_measure">qb:measure</a>
+ <a href="#ref_qb_measureDimension">qb:measureDimension</a>
+ <a href="#ref_qb_measureType">qb:measureType</a>
+ <a href="#ref_qb_observation_LC">qb:observation</a>
+ <a href="#ref_qb_order">qb:order</a>
+ <a href="#ref_qb_slice_LC">qb:slice</a>
+ <a href="#ref_qb_sliceKey_LC">qb:sliceKey</a>
+ <a href="#ref_qb_sliceStructure">qb:sliceStructure</a>
+ <a href="#ref_qb_structure">qb:structure</a>
+ <a href="#ref_qb_observationGroup">qb:observationGroup</a>
+ <a href="#ref_qb_hierarchyRoot">qb:hierarchyRoot</a>
+ <a href="#ref_qb_narrowingProperty">qb:parentChildProperty</a>
+ </p>
+</section>
+
+</section>
+
+<section id="introduction" class="informative">
+<!--OddPage--><h2><span class="secno">2. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
+
+<p>
+Statistical data is a foundation for policy
+prediction, planning and adjustments and
+underpins many of the mash-ups and visualisations
+we see on the web. There is strong interest
+in being able to publish statistical data in a web-friendly format
+to enable it to be linked and combined with related information.
+</p>
+
+<p>
+At the heart of a statistical dataset is a set of observed values
+organized along a group of dimensions, together with associated metadata.
+The Data Cube vocabulary enables such information to be represented
+using the <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/TR/REC-rdf-syntax/">RDF</a>
+(Resource Description Framework) standard and published following the
+principles of
+<a href="http://linkeddata.org/">linked data</a>.
+The vocabulary is based upon the approach used by the SDMX ISO standard
+for statistical data exchange. This <em>cube</em> model is very
+general and so the Data Cube vocabulary can be used for other data sets
+such as survey data, spreadsheets and OLAP data cubes [<cite><a class="bibref" href="#bib-OLAP">OLAP</a></cite>].
+</p>
+
+<p>
+The Data Cube vocabulary is focused purely on the
+publication of multi-dimensional data on the web. We envisage a series of modular
+vocabularies being developed which extend this core foundation. In
+particular, we see the need for an SDMX extension vocabulary to support the
+publication of additional context to statistical data (such as the encompassing Data
+Flows and associated Provision Agreements). Other extensions are possible to
+support metadata for surveys (so called "micro-data", as encompassed by <a href="http://www.ddialliance.org/">DDI</a>)
+or publication of statistical reference metadata.
+</p>
+
+<p>The Data Cube in turn builds upon the following existing RDF
+vocabularies:</p>
+<ul>
+ <li><a href="http://www.w3.org/2004/02/skos/">SKOS</a> for concept schemes</li>
+ <li><a href="http://sw.joanneum.at/scovo/schema.html">SCOVO</a> for
+core statistical structures</li>
+ <li><a href="http://purl.org/dc/terms/">Dublin Core Terms</a> for metadata</li>
+ <li><a href="http://rdfs.org/ns/void-guide">VoiD</a> for data access</li>
+ <li><a href="http://xmlns.com/foaf/0.1/">FOAF</a> for agents</li>
+ <li><a href="http://www.w3.org/ns/org#">ORG</a> for organizations</li>
+</ul>
+
+
+<section id="intro-rdf">
+<h3><span class="secno">2.1 </span>RDF and Linked Data</h3><p><em>This section is non-normative.</em></p>
+
+<p><em>Linked data</em> is an approach to publishing data on the web, enabling
+datasets to be linked together through references to common concepts.
+ The approach [<cite><a class="bibref" href="#bib-LOD">LOD</a></cite>]
+recommends use of HTTP URIs to name the entities and concepts so that consumers of
+the data can look-up those URIs to get more information, including links
+to other related URIs.
+RDF [<cite><a class="bibref" href="#bib-RDF-PRIMER">RDF-PRIMER</a></cite>]
+provides a standard for the representation of the
+information that describes those entities and concepts, and is returned
+by dereferencing the URIs. </p>
+
+<p>There are a number of benefits to being able to publish multi-dimensional data, such as statistics,
+using RDF and the linked data approach:</p>
+<ul>
+ <li>The individual observations, and groups of observations, become
+(web) addressable. This allows publishers and third parties to annotate
+and link to this data; for example a report can reference the specific
+figures it is based on allowing for fine grained provenance trace-back.</li>
+ <li>Data can be flexibly combined across datasets and between
+statistical and non-statistical sets (for example <em>find all
+Religious schools in census areas with high values for National
+Indicators pertaining to religious tolerance</em>). The statistical
+data becomes an integral part of the broader web of linked data.</li>
+ <li>For publishers who currently only offer static files then
+publishing as linked-data offers a flexible, non-proprietary, machine
+readable means of publication that supports an out-of-the-box web API
+for programmatic access.</li>
+ <li>It enables reuse of standardized tools and components.</li>
+</ul>
+</section>
+
+
+<section id="intro-sdmx">
+<h3><span class="secno">2.2 </span>SDMX and related standards</h3>
+
+<p>The Statistical Data and Metadata Exchange (SDMX) Initiative
+was organised in 2001 by seven international organisations (BIS,
+ECB, Eurostat, IMF, OECD, World Bank and the UN) to
+realise greater efficiencies in statistical practice. These
+organisations all
+collect significant amounts of data, mostly from the national level,
+to support policy. They also disseminate data at the supra-national
+and international levels.</p>
+
+<p>
+There have been a number of important results from this work: two
+versions of a set of technical specifications - ISO:TS 17369
+(SDMX) - and the release of several recommendations for
+structuring and harmonising cross-domain statistics, the SDMX
+Content-Oriented Guidelines. All of the products are available at
+<a href="http://www.sdmx.org">www.sdmx.org</a>. The standards are now
+being widely adopted
+around the world for the collection, exchange, processing, and
+dissemination of aggregate statistics by official statistical
+organisations. The UN Statistical Commission recommended
+SDMX as the preferred standard for statistics in 2007.
+</p>
+
+<p>The SDMX specification defines a core <em>information model</em>
+which is reflected in concrete form in two syntaxes - SDMX-ML (an XML
+syntax) and SDMX-EDI.
+</p>
+
+<p>The RDF Data Cube vocabulary builds upon the core of the
+ the SDMX 2.0 Information Model [<cite><a class="bibref" href="#bib-SDMX20">SDMX20</a></cite>].</p>
+
+<p>A key component of the SDMX standards package are
+the <strong>Content-Oriented Guidelines</strong> (COGs), a set of
+cross-domain concepts, code lists, and categories that support
+interoperability and comparability between datasets by providing a
+shared terminology between SDMX implementers [<cite><a class="bibref" href="#bib-COG">COG</a></cite>]. RDF versions of these
+terms are available separately for use along with the Data Cube
+vocabulary, see <a href="#dsd-cog">Content oriented guidelines</a>.
+</p>
+</section>
+
+
+<section id="intro-audience">
+<h3><span class="secno">2.3 </span>Audience and scope</h3>
+
+<p>This document describes the Data Cube vocabulary
+It is aimed at people wishing to publish
+statistical or other multi-dimension data in RDF.
+Mechanics of cross-format translation from other
+formats such as SDMX-ML are not covered here.</p>
+</section>
+
+</section>
+
+<section id="namespaces">
+<!--OddPage--><h2><span class="secno">3. </span>Namespaces and Document Conventions</h2>
+
+<p>
+The names of RDF entities -- classes, predicates, individuals -- are
+URIs. These are usually expressed using a compact notation where the
+name is written <code>prefix:localname</code>, and where the <code>prefix</code>
+identifies a <i>namespace URI</i>. The namespace identified by the prefix is
+ prepended to the <code>localname</code> to obtain the full URI.
+</p>
+
+<p>The following namespaces are used in this document:</p>
+
+<table>
+ <thead><tr><th>Prefix</th><th>Namespace</th><th>Reference</th></tr></thead>
+ <tbody>
+ <tr><td>qb</td><td><a href="http://purl.org/linked-data/cube#">http://purl.org/linked-data/cube#</a></td><td><em>This document</em></td></tr>
+ <tr><td>skos</td><td><a href="http://www.w3.org/2004/02/skos/core">http://www.w3.org/2004/02/skos/core#</a></td><td>[<cite><a class="bibref" href="#bib-SKOS-REFERENCE">SKOS-REFERENCE</a></cite>]</td></tr>
+ <tr><td>scovo</td><td><a href="http://purl.org/NET/scovo#">http://purl.org/NET/scovo#</a></td><td>[<cite><a class="bibref" href="#bib-SCOVO">SCOVO</a></cite>]</td></tr>
+ <tr><td>void</td><td><a href="http://rdfs.org/ns/void#">http://rdfs.org/ns/void#</a></td><td>[<cite><a class="bibref" href="#bib-VOID">VOID</a></cite>]</td></tr>
+ <tr><td>foaf</td><td><a href="http://xmlns.com/foaf/0.1/">http://xmlns.com/foaf/0.1/</a></td><td>[<cite><a class="bibref" href="#bib-FOAF">FOAF</a></cite>]</td></tr>
+ <tr><td>org</td><td><a href="http://www.w3.org/ns/org#">http://www.w3.org/ns/org#</a></td><td>[<cite><a class="bibref" href="#bib-ORG">ORG</a></cite>]</td></tr>
+ <tr><td>dct</td><td><a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></td><td>[<cite><a class="bibref" href="#bib-DC11">DC11</a></cite>]</td></tr>
+ <tr><td>owl</td><td><a href="http://www.w3.org/2002/07/owl">http://www.w3.org/2002/07/owl#</a></td><td>[<cite><a class="bibref" href="#bib-OWL2-PRIMER">OWL2-PRIMER</a></cite>]</td></tr>
+ <tr><td>rdf</td><td><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></td><td>[<cite><a class="bibref" href="#bib-RDF-CONCEPTS">RDF-CONCEPTS</a></cite>]</td></tr>
+ <tr><td>rdfs</td><td><a href="http://www.w3.org/2000/01/rdf-schema">http://www.w3.org/2000/01/rdf-schema#</a></td><td>[<cite><a class="bibref" href="#bib-RDF-SCHEMA">RDF-SCHEMA</a></cite>]</td></tr>
+ <tr><td>admingeo</td><td><a href="http://data.ordnancesurvey.co.uk/ontology/admingeo/">http://data.ordnancesurvey.co.uk/ontology/admingeo/</a></td><td><em>(Non-normative, used for examples only)</em></td></tr>
+ <tr><td>eg</td><td><a href="http://example.org/ns#">http://example.org/ns#</a></td><td><em>(Non-normative, used for examples only)</em></td></tr>
+ </tbody>
+</table>
+
+<p>All RDF examples are written in Turtle syntax [<cite><a class="bibref" href="#bib-TURTLE-TR">TURTLE-TR</a></cite>].</p>
+
+</section>
+
+
+<section id="conformance"><!--OddPage--><h2><span class="secno">4. </span>Conformance</h2>
+<p>
+ As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
+ and notes in this specification are non-normative. Everything else in this specification is
+ normative.
+</p>
+<p>
+ The key words <em class="rfc2119" title="must">must</em>, <em class="rfc2119" title="must not">must not</em>, <em class="rfc2119" title="required">required</em>, <em class="rfc2119" title="should">should</em>, <em class="rfc2119" title="should not">should not</em>, <em class="rfc2119" title="recommended">recommended</em>, <em class="rfc2119" title="may">may</em>,
+ and <em class="rfc2119" title="optional">optional</em> in this specification are to be interpreted as described in [<cite><a class="bibref" href="#bib-RFC2119">RFC2119</a></cite>].
+</p>
+
+
+<p>A data interchange, however that interchange occurs, is conformant
+ with Data Cube if:
+</p><ul>
+<li>it uses terms (classes and properties) from Data Cube in a way consistent with
+ their semantics as declared in this specification, in particular the exchanged RDF graphs constitute
+ either <em><a href="#dfn-well-formed" class="internalDFN">well-formed</a></em> or <em><a href="#dfn-well-formed-abbreviated" class="internalDFN">well-formed abbreviated</a></em> Data Cubes;</li>
+<li>it does <strong>not</strong> use terms from other vocabularies <strong>instead</strong> of ones defined
+ in this vocabulary that could reasonably be used (use of such
+ terms <strong>in addition</strong> to Data Cube terms is permissible).</li>
+</ul>
+<p></p>
+
+<p>A conforming data interchange:
+</p><ul>
+<li><em class="rfc2119" title="may">may</em> include terms from other vocabularies;</li>
+<li><em class="rfc2119" title="may">may</em> use only a subset of Data Cube terms.</li>
+</ul>
+<p></p>
+
+</section>
+
+<section id="data-cubes" class="informative">
+<!--OddPage--><h2><span class="secno">5. </span>Data cubes</h2><p><em>This section is non-normative.</em></p>
+
+
+<section id="cubes-model" class="informative">
+<h3><span class="secno">5.1 </span>The cube model - dimensions, attributes, measures</h3><p><em>This section is non-normative.</em></p>
+
+<p>A statistical data set comprises a collection of observations made
+at some points across some logical space. The collection can be characterized by
+a set of dimensions that define what the observation applies to (e.g. time,
+area, gender) along with metadata describing what has been
+measured (e.g. economic activity, population), how it was measured and how the
+observations are expressed (e.g. units, multipliers, status). We can
+think of the statistical data set as a multi-dimensional
+space, or hyper-cube, indexed by those dimensions. This space is
+commonly referred to
+as a <em>cube</em> for short; though the name shouldn't be taken
+literally, it is not meant to imply that
+there are exactly three dimensions (there can be more or fewer) nor
+that
+all the dimensions are somehow similar in size.</p>
+
+<p>A cube is organized according to a set of <em>dimensions</em>,
+<em>attributes</em> and <em>measures</em>. We collectively call these <em>components</em>.</p>
+
+<p>The <em>dimension</em> components serve to identify
+the observations. A set of values for all the dimension
+components
+is sufficient to identify a single observation. Examples of dimensions
+include the
+time to which the observation applies, or a geographic region which the observation covers.</p>
+
+<p>The <em>measure</em> components represent the phenomenon being
+observed.</p>
+
+<p>The <em>attribute</em> components allow us to qualify and
+interpret the observed value(s). They enable specification of the units of
+measure, any scaling factors and metadata such as the status
+of the observation (e.g. <em>estimated</em>, <em>provisional</em>).</p>
+</section>
+
+
+<section id="cubes-slices" class="informative">
+<h3><span class="secno">5.2 </span>Introducing Slices</h3><p><em>This section is non-normative.</em></p>
+
+<p>It is frequently useful to group subsets of observations within a
+dataset. In particular to fix all but one (or a small subset) of the
+dimensions and be able to refer to all observations with those
+dimension values as a single entity. We call such a selection a <em>slice</em>
+through the cube. For example, given a data set on regional performance
+indicators then we might group all the observations about a given indicator
+and a given region into a slice, each slice would then represent a time series of observed values.</p>
+
+<p>A data publisher may identify slices through the data for various
+purposes. They can be a useful grouping to which metadata might be attached, for example to note a
+change in measurement process which
+affects a particular time or region. Slices also enable the publisher to
+identify and label particular subsets of the data which should be presented to the
+user - they can enable the consuming application to more easily
+ construct the appropriate graph or chart for presentation.</p>
+
+<p>In statistical applications it is common to work with
+slices in which a single dimension is left unspecified.
+In particular,
+to refer to such slices in which the single free dimension is time as <em>Time
+Series</em> and to refer slices along non-time dimensions as <em>Sections</em>.
+Within the Data Cube vocabulary we allow arbitrary dimensionality
+slices and do not give different names to particular types of
+ slice. Such sub classes of slice could be added in extension vocabularies.</p>
+
+</section>
+
+<section id="example" class="informative">
+<h3><span class="secno">5.3 </span>An example</h3><p><em>This section is non-normative.</em></p>
+
+<p>In order to illustrate the use of the data cube vocabulary we will
+use a small demonstration
+data set extracted from
+<a href="http://statswales.wales.gov.uk/index.htm">StatsWales</a> report
+number 003311 which describes life expectancy broken down by region
+(unitary authority), age and time. The extract we will use is:<br>
+</p>
+
+<table id="example-data" style="text-align: left; width: 80%;">
+ <tbody>
+ <tr>
+ <td style="vertical-align: top;"><br>
+ </td>
+ <td colspan="2" rowspan="1" style="vertical-align: top; text-align: center; font-weight: bold;">2004-2006<br>
+ </td>
+ <td colspan="2" rowspan="1" style="vertical-align: top; text-align: center; font-weight: bold;">2005-2007<br>
+ </td>
+ <td colspan="2" rowspan="1" style="vertical-align: top; text-align: center; font-weight: bold;">2006-2008<br>
+ </td>
+ </tr>
+ <tr>
+ <td style="vertical-align: top;"><br>
+ </td>
+ <td style="vertical-align: top; text-align: center; font-weight: bold;">Male<br>
+ </td>
+ <td style="vertical-align: top; text-align: center; font-weight: bold;">Female<br>
+ </td>
+ <td style="vertical-align: top; text-align: center; font-weight: bold;">Male<br>
+ </td>
+ <td style="vertical-align: top; text-align: center; font-weight: bold;">Female<br>
+ </td>
+ <td style="vertical-align: top; text-align: center; font-weight: bold;">Male<br>
+ </td>
+ <td style="vertical-align: top; text-align: center; font-weight: bold;">Female<br>
+ </td>
+ </tr>
+ <tr>
+ <td style="vertical-align: top; text-align: right; font-weight: bold;">Newport<br>
+ </td>
+ <td style="vertical-align: top;">76.7<br>
+ </td>
+ <td style="vertical-align: top;">80.7<br>
+ </td>
+ <td style="vertical-align: top;">77.1<br>
+ </td>
+ <td style="vertical-align: top;">80.9<br>
+ </td>
+ <td style="vertical-align: top;">77.0<br>
+ </td>
+ <td style="vertical-align: top;">81.5<br>
+ </td>
+ </tr>
+ <tr>
+ <td style="vertical-align: top; text-align: right; font-weight: bold;">Cardiff<br>
+ </td>
+ <td style="vertical-align: top;">78.7<br>
+ </td>
+ <td style="vertical-align: top;">83.3<br>
+ </td>
+ <td style="vertical-align: top;">78.6<br>
+ </td>
+ <td style="vertical-align: top;">83.7<br>
+ </td>
+ <td style="vertical-align: top;">78.7<br>
+ </td>
+ <td style="vertical-align: top;">83.4<br>
+ </td>
+ </tr>
+ <tr>
+ <td style="vertical-align: top; text-align: right; font-weight: bold;">Monmouthshire<br>
+ </td>
+ <td style="vertical-align: top;">76.6<br>
+ </td>
+ <td style="vertical-align: top;">81.3<br>
+ </td>
+ <td style="vertical-align: top;">76.5<br>
+ </td>
+ <td style="vertical-align: top;">81.5<br>
+ </td>
+ <td style="vertical-align: top;">76.6<br>
+ </td>
+ <td style="vertical-align: top;">81.7<br>
+ </td>
+ </tr>
+ <tr>
+ <td style="vertical-align: top; text-align: right; font-weight: bold;">Merthyr
+Tydfil<br>
+ </td>
+ <td style="vertical-align: top;">75.5<br>
+ </td>
+ <td style="vertical-align: top;">79.1<br>
+ </td>
+ <td style="vertical-align: top;">75.5<br>
+ </td>
+ <td style="vertical-align: top;">79.4<br>
+ </td>
+ <td style="vertical-align: top;">74.9<br>
+ </td>
+ <td style="vertical-align: top;">79.6<br>
+ </td>
+ </tr>
+ </tbody>
+</table>
+
+<p>We can see that there are three dimensions - time period (rolling averages over three year timespans),
+ region and sex. Each observation represents the life expectancy for that population (the measure) and
+ we will need an attribute to define the units (years) of the measured values.</p>
+
+<p>An example of slicing the data would be to define slices in which the time and sex are
+fixed for each slice. Such slices then show the variation in life expectancy across the
+ different regions, i.e. corresponding to the columns in the above tabular layout.</p>
+
+</section>
+
+</section>
+
+
+<section id="dsd">
+<!--OddPage--><h2><span class="secno">6. </span>Creating data structure definitions</h2>
+
+<p>A <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> defines the structure of one or more
+datasets. In particular, it defines the dimensions, attributes and measures
+used in the dataset along with qualifying information such as ordering of
+ dimensions and whether attributes are required or optional. For well-formed
+ data sets much of this information is implicit within the RDF component properties
+ found on the observations. However, the explicit declaration of the structure has
+ several benefits:</p>
+
+<ul>
+ <li>it enables verification that the data set matches the expected structure,
+ in particular helps with detection of incoherent sets obtained by
+ combining differently structured source data;</li>
+ <li>it allows a consumer to easily determine what dimensions are available for query
+ and their presentational order, which in turn simplifies UI construction;</li>
+ <li>it supports transmission of the structure information in associated SDMX data flows.</li>
+</ul>
+
+<p>It is common, when publishing statistical data, to have a regular series of publications which
+all follow the same structure. The notion of a Data Structure Definition (DSD) allows us to define
+that structure once and then reuse it for each publication in the series. Consumers can then be
+ confident that the structure of the data has not changed.</p>
+
+<section id="dsd-dimensions">
+<h3><span class="secno">6.1 </span>Dimensions, attributes and measures</h3>
+
+<p>The Data Cube vocabulary represents the dimensions, attributes and measures
+ as RDF properties. Each is an instance of the abstract <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
+ class, which in turn has sub-classes <code><a href="#dfn-qb-dimensionproperty" class="internalDFN">qb:DimensionProperty</a></code>,
+ <code><a href="#dfn-qb-attributeproperty" class="internalDFN">qb:AttributeProperty</a></code> and <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code>.</p>
+
+<p>A component property encapsulates several pieces of information:</p>
+<ul>
+ <li>the concept being represented (e.g. time or geographic area),</li>
+ <li>the nature of the component (dimension, attribute or measure) as represented by the type of the component property,</li>
+ <li>the type or code list used to represent the value.</li>
+</ul>
+
+<p>The same <em>concept</em> can be manifested in different components. For example, the concept
+ of <em>currency</em> may be used as a dimension (in a data set dealing with exchange rates) or as
+ an attribute (when describing the currency in which an observed trade took place). The concept of time
+ is typically used only as a dimension but may be encoded as a data value (e.g. an <code>xsd:dateTime</code>)
+ or as a symbolic value (e.g. a URI drawn from the reference time URI set developed by data.gov.uk).
+ In statistical agencies it is common to have a standard thesaurus of statistical concepts which
+ underpin the components used in multiple different data sets.</p>
+
+<p>To support this reuse of general statistical concepts the data cube vocabulary provides the <code><a href="#dfn-qb-concept" class="internalDFN">qb:concept</a></code> property which
+ links a <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code> to the concept it represents. We use the SKOS
+ vocabulary [<cite><a class="bibref" href="#bib-SKOS-PRIMER">SKOS-PRIMER</a></cite>] to represent such concepts. This is very natural for those cases where the
+ concepts are already maintained as a controlled term list or thesaurus.
+ When developing a data structure definition for an informal data set there may not be an appropriate
+ concept already. In those cases, if the concept is likely to be reused in other guises it is recommended to
+ publish a <code>skos:Concept</code> along with the specific <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>. However, if
+ such reuse is not expected then it is not required to do so - the <code><a href="#dfn-qb-concept" class="internalDFN">qb:concept</a></code>
+ link is optional and a simple instance of the appropriate subclass of <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code> is
+ sufficient.</p>
+
+<p>The representation of the possible values of the component is described using the <code>rdfs:range</code>
+ property of the component in the usual RDF manner. Thus, for example, values of a time dimension might
+ be represented using literals of type <code>xsd:dateTime</code> or as URIs drawn from a time reference service.</p>
+
+<p>In statistical data sets it is common
+ for values to be encoded using some (possibly hierarchical) code list and it can be useful to be
+ able to easily identify the overall code list in some more structured form. To cater for this a
+ component can also be optionally annotated with a <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code> to indicate a set of
+ <code>skos:Concept</code>s which may be used as codes. The <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code> value may be a
+ <code>skos:ConceptScheme</code>, <code>skos:Collection</code> or <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>.
+ In such a case the <code>rdfs:range</code> of the component might be left as simply <code>skos:Concept</code> but
+ a useful design pattern is to also define an <code>rdfs:Class</code>
+ whose members are all the <code>skos:Concept</code>s within a particular scheme. In that way
+ the <code>rdfs:range</code> can be made more specific which enables generic RDF tools to perform
+ appropriate range checking.</p>
+
+<p>Note that in any SDMX extension vocabulary there would be one further item of information to encode
+ about components - the role that they play within the structure definition. In particular, it is sometimes
+ convenient for consumers to be able to easily identify which is the time dimension,
+ which component is the primary measure and so forth. It turns out that such roles are intrinsic to
+ the concepts and so this information can encoded by providing subclasses of <code>skos:Concept</code>
+ for each role. The particular choice of roles here is specific to the SDMX standard and so is not
+ included within the core Data Cube vocabulary.</p>
+
+<p>Before illustrating the components needed for our running example, there is one more piece
+ of machinery to introduce, a reusable set of concepts and components based on SDMX.
+</p>
+</section>
+
+<section id="dsd-cog" class="informative">
+<h3><span class="secno">6.2 </span>Content oriented guidelines</h3><p><em>This section is non-normative.</em></p>
+
+<p>The SDMX standard includes a set of <em>content oriented guidelines</em> (COG) [<cite><a class="bibref" href="#bib-COG">COG</a></cite>]
+ which define a set of common statistical concepts and associated code lists that are intended to be
+ reusable across data sets. A <a href="https://code.google.com/p/publishing-statistical-data/">community group</a>
+ has developed RDF encodings of these guidelines. These comprise:
+
+</p><table id="namespaces-table">
+ <thead><tr><th>Prefix</th><th>Namespace</th><th>Description</th></tr></thead>
+ <tbody>
+ <tr><td><code>sdmx-concept</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/concept#">http://purl.org/linked-data/sdmx/2009/concept#</a></td><td>SKOS Concepts for each COG defined concept</td>
+ </tr><tr><td><code>sdmx-code</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/code#">http://purl.org/linked-data/sdmx/2009/code#</a></td><td>SKOS Concepts and ConceptSchemes for each COG defined code list</td>
+ </tr><tr><td><code>sdmx-dimension</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/dimension#">http://purl.org/linked-data/sdmx/2009/dimension#</a></td><td>component properties corresponding to each COG concept that can be used as a dimension</td>
+ </tr><tr><td><code>sdmx-attribute</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/attribute#">http://purl.org/linked-data/sdmx/2009/attribute#</a></td><td>component properties corresponding to each COG concept that can be used as an attribute</td>
+ </tr><tr><td><code>sdmx-measure</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/measure#">http://purl.org/linked-data/sdmx/2009/measure#</a></td><td>component properties corresponding to each COG concept that can be used as a measure</td>
+
+ </tr></tbody>
+</table>
+
+<p>These resources are provided as a convenience and do not form part
+ of the Data Cube standard at this time. However, they are used
+ by a number of existing Data Cube publications and so we will
+ reference them within our worked examples.</p>
+
+</section>
+
+
+<section id="dsd-example" class="informative">
+<h3><span class="secno">6.3 </span>Example</h3><p><em>This section is non-normative.</em></p>
+
+<p>Turning to our example data set then we can see there are three dimensions to represent
+ - time period, region (unitary authority) and sex of the population. There is a single
+ (primary) measure which corresponds to the topic of the data set (life expectancy) and
+ encodes a value in years. Hence, we need the following components.</p>
+
+<p><b>Time.</b> There is a suitable predefined concept in the SMDX-COG for this, REF_PERIOD, so
+ we could reuse the corresponding component property <code>sdmx-dimension:refPeriod</code>. However,
+ to represent the time period itself it would be convenient to use the data.gov.uk reference
+ time service and to declare this within the data structure definition.</p>
+
+<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example">eg:refPeriod a rdf:Property, qb:DimensionProperty;
+ rdfs:label "reference period"@en;
+ rdfs:subPropertyOf sdmx-dimension:refPeriod;
+ rdfs:range interval:Interval;
+ qb:concept sdmx-concept:refPeriod . </pre></div>
+
+<p><b>Region.</b> Again there is a suitable COG concept and associated component that
+we can use for this, and again we can customize the range of the component. In this case
+ we can use the Ordnance Survey Administrative Geography Ontology [<cite><a class="bibref" href="#bib-OS-GEO">OS-GEO</a></cite>].</p>
+
+<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example">eg:refArea a rdf:Property, qb:DimensionProperty;
+ rdfs:label "reference area"@en;
+ rdfs:subPropertyOf sdmx-dimension:refArea;
+ rdfs:range admingeo:UnitaryAuthority;
+ qb:concept sdmx-concept:refArea . </pre></div>
+
+<p><b>Sex.</b> In this case we can use the corresponding COG component <code>sdmx-dimension:sex</code>
+ directly, since the default code list for it includes the terms we need.</p>
+
+<p><b>Measure.</b> This property will give the value of each observation.
+ We could use the default <code>smdx-measure:obsValue</code> for this (defining
+ the topic being observed using metadata). However, it can aid readability and processing
+ of the RDF data sets to use a specific measure corresponding to the phenomenon being observed.</p>
+
+<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example">eg:lifeExpectancy a rdf:Property, qb:MeasureProperty;
+ rdfs:label "life expectancy"@en;
+ rdfs:subPropertyOf sdmx-measure:obsValue;
+ rdfs:range xsd:decimal . </pre></div>
+
+<p><b>Unit measure attribute.</b> The primary measure on its own is a plain decimal value.
+ To correctly interpret this value we need to define what units it is measured in (years in this case).
+ This is defined using attributes which qualify the interpretation of the observed value.
+ Specifically in this example we can use the predefined <code>sdmx-attribute:unitMeasure</code>
+ which in turn corresponds to the COG concept of <code>UNIT_MEASURE</code>. To express
+ the value of this attribute we would typically us a common thesaurus of units of measure.
+ For the sake of this simple example we will use the DBpedia resource <code>http://dbpedia.org/resource/Year</code>
+ which corresponds to the topic of the Wikipedia page on "Years".</p>
+
+<p>This covers the minimal components needed to define the structure of this data set.</p>
+</section>
+
+
+<section id="dsd-dsd">
+<h3><span class="secno">6.4 </span>ComponentSpecifications and DataStructureDefinitions</h3>
+
+<p>To combine the components into a specification for the structure of this
+ dataset we need to declare a <code><a>qb:DataStuctureDefinition</a></code>
+ resource which in turn will reference a set of <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code> resources.
+ The <code><a>qb:DataStuctureDefinition</a></code> will be reusable across other data sets with the same structure.</p>
+
+<p>In the simplest case the <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code> simply references the
+ corresponding <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code> (usually using one of the sub properties
+ <code><a href="#dfn-qb-dimension" class="internalDFN">qb:dimension</a></code>, <code><a href="#dfn-qb-measure" class="internalDFN">qb:measure</a></code> or <code><a href="#dfn-qb-attribute" class="internalDFN">qb:attribute</a></code>).
+ However, it is also possible to qualify the
+ component specification in several ways.</p>
+
+<ul>
+ <li>Attributes may be declared as optional or required. If an
+ attribute is required to be present for every observation then the specification should set
+ <code><a>qb:componentRequired></a></code>. In the
+ absence of such a declaration an attribute is assumed to be
+ optional. The <code><a href="#dfn-qb-componentrequired" class="internalDFN">qb:componentRequired</a></code>
+ declaration may only be applied to component specifications of
+ attributes - measures and dimensions are always required.</li>
+ <li>The components may be ordered by giving an integer value for <code><a href="#dfn-qb-order" class="internalDFN">qb:order</a></code>.
+ This order carries no semantics but can be useful to aid consuming agents in generating
+ appropriate user interfaces. It can also be useful in the publication chain to enable
+ synthesis of appropriate URIs for observations.</li>
+ <li>By default the values of all of the components will be attached to each individual observation,
+ well call this the <em><a href="#dfn-normalized" class="internalDFN">normalized</a></em> representation.
+ This allows such observations to stand alone, so that a SPARQL query to retrieve the observation
+ can immediately locate the attributes which enable the observation to be interpreted. However,
+ it is also permissible to attach attributes to the
+ overall data set, to an intervening slice or to a specific Measure (in the case of multiple measures).
+ This reduces some of the redundancy in the encoding of the instance data. To declare such an
+ abbreviated structure, the <code><a href="#dfn-qb-componentattachment" class="internalDFN">qb:componentAttachment</a></code> property of the specification should
+ reference the class corresponding to the attachment level (e.g. <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> for attributes
+ that will be attached to the overall data set).</li>
+</ul>
+
+<p>In the case of our running example the dimensions can be usefully ordered. There is only one
+ attribute, the unit measure, and this is required. In the interest of illustrating the vocabulary
+ use we will declare that this attribute will be attached at the level of the data set, however
+ normalized representations are in general easier to query and combine.</p>
+
+<p>So the structure of our example data set (and other similar datasets) can be declared by:</p>
+
+<div class="example"><div class="example-title"><span>Example 4</span></div><pre id="attachment-example" class="example">eg:dsd-le a qb:DataStructureDefinition;
+ # The dimensions
+ qb:component [qb:dimension eg:refArea; qb:order 1];
+ qb:component [qb:dimension eg:refPeriod; qb:order 2];
+ qb:component [qb:dimension sdmx-dimension:sex; qb:order 3];
+ # The measure(s)
+ qb:component [qb:measure eg:lifeExpectancy];
+ # The attributes
+ qb:component [qb:attribute sdmx-attribute:unitMeasure;
+ qb:componentRequired "true"^^xsd:boolean;
+ qb:componentAttachment qb:DataSet;] .</pre></div>
+
+<p>Note that we have given the data structure definition (DSD) a URI since it will be
+ reused across different datasets with the same structure. Similarly the component properties
+ themselves can be reused across different DSDs. However, the component specifications
+ are only useful within the scope of a particular DSD and so we have chosen to represent
+ them using blank nodes.
+</p>
+</section>
+
+
+<section id="dsd-mm">
+<h3><span class="secno">6.5 </span>Handling multiple measures</h3>
+
+<p>Our example data set is relatively simple in having a single observable (in this case "life expectancy")
+ that is being measured. In other data sets there can be multiple measures. These measures
+ may be of similar nature (e.g. a data set on local government performance might provide
+ multiple different performance indicators for each region) or quite different (e.g. a data set
+ on trades might provide quantity, value, weight for each trade).</p>
+
+<p>There are two approaches to representing multiple measures. In the SDMX information model, each
+ observation can record a single observed value. In a data set with multiple observations then we
+ add an additional dimension whose value indicates the measure. This is appropriate for applications
+ where the measures are separate aggregate statistics. In other domains such as a clinical statistics
+ or sensor networks then the term <em>observation</em> usually denotes an observation event which can include multiple
+ observed values. Similarly in Business Intelligence applications and OLAP, a single "cell" in the data cube will
+ typically contain values for multiple measures.
+</p>
+
+<p>The data cube vocabulary permits either representation approach to be used though they cannot be mixed
+ within the same data set. </p>
+
+<p>Both representation approaches require
+ that, for every point in the space of dimensions for which there is
+ an observation, then a value must be given for every measure. In the
+ case of multi-measure observations then each measure must be
+ present on each observation. In cubes which use a measure dimension
+ then there are sets of observations for each populated point in the
+ cube and within each of those sets there must be an observation giving each measure.</p>
+
+
+<section id="dsd-mm-obs">
+<h4><span class="secno">6.5.1 </span>Multi-measure observations</h4>
+
+<p> This approach allows multiple observed values to be attached
+ to an individual observation. It is suited to representation of things like sensor data and OLAP cubes.
+ To use this representation you simply declare multiple <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code> components
+ in the data structure definition and attach an instance of each property to the observations within
+ the data set.</p>
+
+<p>For example, if we have a set of shipment data containing unit count and total weight for each
+ shipment then we might have a data structure definition such as:</p>
+<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example">eg:dsd1 a qb:DataStructureDefinition;
+ rdfs:comment "shipments by time (multiple measures approach)"@en;
+ qb:component
+ [ qb:dimension sdmx-dimension:refTime; ],
+ [ qb:measure eg-measure:quantity; ],
+ [ qb:measure eg-measure:weight; ] . </pre></div>
+
+<p>This would correspond to individual observations such as:</p>
+<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example">eg:dataset1 a qb:DataSet;
+ qb:structure eg:dsd1 .
+
+eg:obs1a a qb:Observation;
+ qb:dataSet eg:dataset1;
+ sdmx-dimension:refTime "30-07-2010"^^xsd:date;
+ eg-measure:weight 1.3 ;
+ eg-measure:quantity 42 ;
+ . </pre></div>
+
+<p>Note that one limitation of the multi-measure approach is that it is not possible to attach
+ an attribute to a single observed value. An attribute attached to the observation instance
+ will apply to the whole observation (e.g. to indicate who made the observation). Attributes
+ can also be attached directly to the <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code> itself (e.g. to indicate
+ the <em>unit of measure</em> for that measure) but that attachment applies to the whole data
+ set (indeed any data set using that measure property) and cannot vary for different observations.
+ For applications where this limitation is a problem then use the <em>measure dimension</em> approach.</p>
+</section>
+
+
+<section id="dsd-mm-dim">
+<h4><span class="secno">6.5.2 </span><dfn id="dfn-measure-dimension">Measure dimension</dfn></h4>
+
+<p>This approach restricts observations to having a single measured value but allows
+ a data set to carry multiple measures by adding an extra dimension, a <em>measure dimension</em>.
+ The value of the measure dimension denotes which particular measure is being conveyed by the
+ observation. This is the representation approach used within SDMX and the SMDX-in-RDF
+ extension vocabulary introduces a subclass of <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> which is restricted
+ to using the <em>measure dimension</em> representation.</p>
+
+<p>To use this representation you declare an additional dimension within the data structure
+ definition to play the role of the measure dimension. For use within the Data Cube vocabulary
+ we provide a single distinguished component for this purpose -- <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code>.
+ An extension vocabulary could generalize this through the provision of roles to
+ identify concepts which
+ act as measure types, enabling other measure dimensions to be declared.
+</p>
+
+ <p>
+ In the special case of using <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code> as the measure dimension, the set of allowed
+ measures is assumed to be those measures declared within the DSD. There is no need to
+ define a separate code list or enumerated class to duplicate this information.
+ Thus, <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code> is a “magic” dimension property with an implicit code list.</p>
+
+<p>The data structure definition for our above example, using this representation approach, would then be:</p>
+<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example">eg:dsd2 a qb:DataStructureDefinition;
+ rdfs:comment "shipments by time (measure dimension approach)"@en;
+ qb:component
+ [ qb:dimension sdmx-dimension:refTime; ],
+ [ qb:measure eg-measure:quantity; ],
+ [ qb:measure eg-measure:weight; ],
+ [ qb:dimension qb:measureType; ] . </pre></div>
+
+<p>This would correspond to individual observations such as:</p>
+<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example">eg:dataset2 a qb:DataSet;
+ qb:structure eg:dsd2 .
+
+eg:obs2a a qb:Observation;
+ qb:dataSet eg:dataset2;
+ sdmx-dimension:refTime "30-07-2010"^^xsd:date;
+ qb:measureType eg-measure:weight ;
+ eg-measure:weight 1.3 .
+
+eg:obs2b a qb:Observation;
+ qb:dataSet eg:dataset2;
+ sdmx-dimension:refTime "30-07-2010"^^xsd:date;
+ qb:measureType eg-measure:quantity ;
+ eg-measure:quantity 42 . </pre></div>
+
+
+<p>Note the duplication of having the measure property show up both as the property that
+ carries the measured value, and as the value of the measure dimension. We accept
+ this duplication as necessary to ensure the uniform cube/dimension mechanism and
+ a uniform way of declaring and using measure properties on all kinds of datasets.</p><p>
+
+</p><p>Those familiar with SDMX should also note that in the RDF representation there is
+ no need for a separate "primary measure" which subsumes each of the individual
+ measures, those individual measures are used directly. Extension vocabularies
+ could address the round-tripping of the SDMX primary measure by use of a
+ separate annotation on the data structure definition.
+</p></section>
+
+</section>
+
+</section>
+
+
+<section id="datasets">
+<!--OddPage--><h2><span class="secno">7. </span>Expressing data sets</h2>
+
+<p>A DataSet is a collection of statistical data that corresponds to a given data structure definition.
+The data in a data set can be roughly described as belonging to one of the following kinds:</p>
+
+<dl>
+ <dt>Observations</dt>
+ <dd>This is the actual data, the measured numbers. In a statistical table, the observations
+ would be the numbers in the table cells.</dd>
+
+ <dt>Organizational structure</dt>
+ <dd>To locate an observation within the hypercube, one has at least to know the value of each
+ dimension at which the observation is located, so these values must be specified for each observation.
+ Datasets can have additional organizational structure in the form of <em>slices</em>
+ as described earlier in <a href="#slices">section 7.2</a>.
+
+ </dd><dt>Internal metadata</dt>
+ <dd>Having located an observation, we need certain metadata in order to be able to interpret it.
+ What is the unit of measurement? Is it a normal value or a series break?
+ Is the value measured or estimated? These metadata are provided as <em>attributes</em> and can
+ be attached to individual observations, or to higher levels as defined by the ComponentSpecification
+ described earlier.</dd>
+
+ <dt>External metadata</dt>
+ <dd>This is metadata that describes the dataset as a whole, such as categorization of the
+ dataset, its publisher, and a SPARQL endpoint where it can be accessed.
+ External metadata is described in <a href="#metadata">section 9</a>.</dd>
+</dl>
+
+
+<section id="dataset-basic">
+<h3><span class="secno">7.1 </span>Data sets and observations</h3>
+
+<p>A resource representing the entire data set is created and typed as <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> and
+ linked to the corresponding data structure definition via the <code><a href="#dfn-qb-structure" class="internalDFN">qb:structure</a></code> property.</p>
+
+<p><strong>Pitfall</strong>: Note the capitalization of <code>qb:<strong>D</strong>ata<strong>S</strong>et</code>,
+which differs from the capitalization in other vocabularies, such as
+<a href="http://semanticweb.org/wiki/VoiD">void:Dataset</a> and <a href="http://www.w3.org/egov/wiki/Data_Catalog_Vocabulary">dcat:Dataset</a>. This unusual capitalization is chosen for compatibility
+with the SDMX standard. The same applies to the related property <code>qb:data<strong>S</strong>et</code>.</p>
+
+<p>Each observation is represented as an instance of type <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>.
+ In the basic case then values for each of the attributes, dimensions and measurements are attached directly to the observation (remember
+ that these components are all RDF properties). The observation is linked to the containing
+ data set using the <code><a href="#dfn-qb-dataset-1" class="internalDFN">qb:dataSet</a></code> property. </p>
+
+<p>Thus for our running example we might expect to have:</p>
+
+<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example">eg:dataset-le1 a qb:DataSet;
+ rdfs:label "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
+ qb:structure eg:dsd-le ;
+ .
+
+eg:o1 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea ex-geo:newport_00pr ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
+ eg:lifeExpectancy 76.7 ;
+ .
+
+eg:o2 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea ex-geo:cardiff_00pt ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
+ eg:lifeExpectancy 78.7 ;
+ .
+
+eg:o3 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea ex-geo:monmouthshire_00pp ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
+ eg:lifeExpectancy 76.6 ;
+ .
+
+...</pre></div>
+
+<p>This <a href="#dfn-normalized" class="internalDFN">normalized</a> structure makes it easy to query and combine data sets
+ but there is some redundancy here. For example, the unit of measure for the
+ life expectancy is uniform across the whole data set and does not change between
+ observations. To cater for situations like this the Data Cube vocabulary allows components
+ to be attached at a high level in the nested structure. Indeed if we re-examine our
+ original Data Structure Declaration we see that we declared the unit of measure to be
+ attached at the data set level. So an improved version of the example is:</p>
+
+<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example">eg:dataset-le1 a qb:DataSet;
+ rdfs:label "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
+ qb:structure eg:dsd-le ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
+ .
+
+eg:o1 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea ex-geo:newport_00pr ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 76.7 ;
+ .
+
+eg:o2 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea ex-geo:cardiff_00pt ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 78.7 ;
+ .
+
+eg:o3 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea ex-geo:monmouthshire_00pp ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 76.6 ;
+ .
+
+...</pre></div>
+
+<p>In a data set containing just observations with no intervening structure then each observation
+ must have a complete set of dimension values, along with all the measure values. If the
+ set is structured by using slices then further abbreviation is possible, as discussed
+ in the next section.</p>
+</section>
+
+
+<section id="slices">
+<h3><span class="secno">7.2 </span>Slices and groups of observations</h3>
+
+<p>Slices allow us to group subsets of observations together. This not intended
+ to represent arbitrary selections from the observations but uniform slices
+ through the cube in which one or more of the dimension values are fixed.</p>
+
+<p>Slices may be used for a number of reasons:</p>
+<ul>
+ <li>to guide consuming applications in how to present the data (e.g. to organize
+ data as a set of time series);</li>
+ <li>to provide an identity (URI) for the slice to enable it to be annotated or externally referenced;</li>
+ <li>to reduce the verbosity of the data set by only stating each fixed dimensional value once.</li>
+</ul>
+
+<p>To illustrate the use of slices let us group the sample data set into geographic series.
+ That will enable us to refer to e.g. "male life expectancy observations for 2004-2006"
+ and guide applications to present a comparative chart across regions. </p>
+
+<p>We first define the structure of the slices we want by associating a "slice key" which the
+ data structure definition. This is done by creating a <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code> which
+ lists the component properties (which must be dimensions) which will be fixed in the
+ slice. The key is attached to the DSD using <code><a href="#dfn-qb-slicekey-1" class="internalDFN">qb:sliceKey</a></code>. For example: </p>
+
+<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example">eg:sliceByRegion a qb:SliceKey;
+ rdfs:label "slice by region"@en;
+ rdfs:comment "Slice by grouping regions together, fixing sex and time values"@en;
+ qb:componentProperty eg:refPeriod, sdmx-dimension:sex .
+
+eg:dsd-le-slice1 a qb:DataStructureDefinition;
+ qb:component
+ [qb:dimension eg:refArea; qb:order 1];
+ [qb:dimension eg:refPeriod; qb:order 2];
+ [qb:dimension sdmx-dimension:sex; qb:order 3];
+ [qb:measure eg:lifeExpectancy];
+ [qb:attribute sdmx-attribute:unitMeasure; qb:componentAttachment qb:DataSet;] ;
+ qb:sliceKey eg:sliceByRegion .</pre></div>
+
+<p>In the instance data then slices are represented by instances of <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code> which
+ link to the observations in the slice via <code><a href="#dfn-qb-observation-1" class="internalDFN">qb:observation</a></code> and to the key by means
+ of <code><a href="#dfn-qb-slicestructure" class="internalDFN">qb:sliceStructure</a></code>. Data sets indicate
+ the slices they contain by means of <code><a href="#dfn-qb-slice-1" class="internalDFN">qb:slice</a></code>. Thus in our example we would have:</p>
+
+<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example">eg:dataset-le2 a qb:DataSet;
+ rdfs:label "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
+ qb:structure eg:dsd-le-slice2 ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
+ qb:slice eg:slice2;
+ .
+
+eg:slice2 a qb:Slice;
+ qb:sliceStructure eg:sliceByRegion ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ qb:observation eg:o1b, eg:o2b; eg:o3b, ... .
+
+eg:o1b a qb:Observation;
+ qb:dataSet eg:dataset-le2 ;
+ eg:refArea ex-geo:newport_00pr ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 76.7 ;
+ .
+
+eg:o2b a qb:Observation;
+ qb:dataSet eg:dataset-le2 ;
+ eg:refArea ex-geo:cardiff_00pt ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 78.7 ;
+ .
+
+eg:o3b a qb:Observation;
+ qb:dataSet eg:dataset-le2 ;
+ eg:refArea ex-geo:monmouthshire_00pp ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 76.6 ;
+ .
+
+...</pre></div>
+
+<p>Note that here we are still repeating the dimension values on the individual observations.
+This normalized representation means that a consuming application can still query
+for observed values uniformly without having to first parse the data structure
+definition and search for slice definitions. If it is desired, this redundancy can be reduced
+by declaring different attachment levels for the dimensions. For example:
+</p>
+<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example">eg:dsd-le-slice3 a qb:DataStructureDefinition;
+ qb:component
+ [qb:dimension eg:refArea; qb:order 1];
+ [qb:dimension eg:refPeriod; qb:order 2; qb:componentAttachment qb:Slice];
+ [qb:dimension sdmx-dimension:sex; qb:order 3; qb:componentAttachment qb:Slice];
+ [qb:measure eg:lifeExpectancy];
+ [qb:attribute sdmx-attribute:unitMeasure; qb:componentAttachment qb:DataSet;] ;
+ qb:sliceKey eg:sliceByRegion .
+
+eg:dataset-le3 a qb:DataSet;
+ rdfs:label "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
+ qb:structure eg:dsd-le-slice3 ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
+ qb:slice eg:slice3 ;
+ .
+
+eg:slice3 a qb:Slice;
+ qb:sliceStructure eg:sliceByRegion ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ qb:observation eg:o1c, eg:o2c; eg:o3c, ... .
+
+eg:o1c a qb:Observation;
+ qb:dataSet eg:dataset-le3 ;
+ eg:refArea ex-geo:newport_00pr ;
+ eg:lifeExpectancy 76.7 ;
+ .
+
+eg:o2c a qb:Observation;
+ qb:dataSet eg:dataset-le3 ;
+ eg:refArea ex-geo:cardiff_00pt ;
+ eg:lifeExpectancy 78.7 ;
+ .
+
+eg:o3c a qb:Observation;
+ qb:dataSet eg:dataset-le3 ;
+ eg:refArea ex-geo:monmouthshire_00pp ;
+ eg:lifeExpectancy 76.6 ;
+ .
+
+...</pre></div>
+
+<p>There are also situations in which a publisher wishes to group a set of observations
+together for ease of access or presentation purposes but where that set is not defined
+by simply fixing a set of dimension values. For example, in
+ representing weather observations it can be desirable to group
+ together the latest observation available from each station even though
+ each observation may have been taken at a different time.
+ For those situations the Data Cube vocabulary supports
+<code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code>. A <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code> can contain an arbitrary
+collection of observations. A <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code> is a special case of a <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code>.
+
+</p></section>
+
+</section>
+
+
+<section id="schemes">
+<!--OddPage--><h2><span class="secno">8. </span>Concept schemes and code lists</h2>
+
+<section id="schemes-intro">
+<h3><span class="secno">8.1 </span>Coded values for components properties</h3>
+
+<p>The values for dimensions within a data set must be unambiguously
+ defined. They may be typed values (e.g. <code>xsd:dateTime</code> for time instances)
+ or codes drawn from some code list. Similarly, many attributes
+ used in data sets represent coded values from some controlled term list rather
+ than free text descriptions. In the Data Cube vocabulary such codes are
+ represented by URI references in the usual RDF fashion.</p>
+
+<p>Sometimes
+ appropriate URI sets already exist for the relevant dimensions (e.g. the representations
+ of area and time periods in our running example). In other cases the data set being
+ converted may use controlled terms from some scheme which does not yet have
+ associated URIs. In those cases we recommend use of SKOS, representing
+ the individual code values using <code>skos:Concept</code> and the overall
+ set of admissible values using <code>skos:ConceptScheme</code> or <code>skos:Collection</code>.</p>
+
+<p>We illustrate this with an example drawn from the translation of the SDMX COG
+ code list for gender, as used already in our worked example. The relevant subset of this code list is:</p>
+
+<div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example">sdmx-code:sex a skos:ConceptScheme;
+ skos:prefLabel "Code list for Sex (SEX) - codelist scheme"@en;
+ rdfs:label "Code list for Sex (SEX) - codelist scheme"@en;
+ skos:notation "CL_SEX";
+ skos:note "This code list provides the gender."@en;
+ skos:definition <http://sdmx.org/wp-content/uploads/2009/01/02_sdmx_cog_annex_2_cl_2009.pdf> ;
+ rdfs:seeAlso sdmx-code:Sex ;
+ sdmx-code:sex skos:hasTopConcept sdmx-code:sex-F ;
+ sdmx-code:sex skos:hasTopConcept sdmx-code:sex-M .
+
+sdmx-code:Sex a rdfs:Class, owl:Class;
+ rdfs:subClassOf skos:Concept ;
+ rdfs:label "Code list for Sex (SEX) - codelist class"@en;
+ rdfs:comment "This code list provides the gender."@en;
+ rdfs:seeAlso sdmx-code:sex .
+
+sdmx-code:sex-F a skos:Concept, sdmx-code:Sex;
+ skos:topConceptOf sdmx-code:sex;
+ skos:prefLabel "Female"@en ;
+ skos:notation "F" ;
+ skos:inScheme sdmx-code:sex .
+
+sdmx-code:sex-M a skos:Concept, sdmx-code:Sex;
+ skos:topConceptOf sdmx-code:sex;
+ skos:prefLabel "Male"@en ;
+ skos:notation "M" ;
+ skos:inScheme sdmx-code:sex .</pre></div>
+
+<p><code>skos:prefLabel</code> is used to give a name to the code,
+<code>skos:note</code> gives a description and <code>skos:notation</code> can be used
+to record a short form code which might appear in other serializations.
+The SKOS specification [<cite><a class="bibref" href="#bib-SKOS-REFERENCE">SKOS-REFERENCE</a></cite>] recommends the generation of a custom datatype for
+each use of <code>skos:notation</code> but here the notation is not intended for use
+within RDF encodings, it merely documents the notation used in other representations
+(which do not use such a datatype).</p>
+
+<p>It is convenient and good practice when developing a code list to also
+create a Class to denote all the codes within the code
+list, irrespective of hierarchical structure. This allows the range of an
+<code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code> to be defined by using <code>rdfs:range</code>
+which then permits standard RDF closed-world checkers to validate use of the
+code list without requiring custom SDMX-RDF-aware tooling. We do that in the
+above example by using the common convention that the class name is the
+same as that of the concept scheme but with leading upper case.</p>
+
+<p>This code list can then be associated with a coded property, such as a dimension:</p>
+
+<div class="example"><div class="example-title"><span>Example 15</span></div><pre class="example">eg:sex a qb:DimensionProperty, qb:CodedProperty;
+ qb:codeList sdmx-code:sex ;
+ rdfs:range sdmx-code:Sex .</pre></div>
+
+<p>Explicitly declaring the code list using <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code>
+ is not mandatory but can be helpful in those cases where a concept scheme has been defined.</p>
+</section>
+
+<section id="schemes-hierarchy">
+<h3><span class="secno">8.2 </span>Hierarchical code lists</h3>
+
+<p>In some cases code lists have a hierarchical structure. In particular, this is
+used in SDMX when the data cube includes aggregations of data values
+(e.g. aggregating a measure across geographic regions).
+Hierarchical code lists <em class="rfc2119" title="should">should</em> be represented using the
+<code>skos:narrower</code> relationship to link from the <code>skos:hasTopConcept</code>
+codes down through the tree or lattice of child codes.
+In some publishing tool chains the corresponding transitive closure
+<code>skos:narrowerTransitive</code> will be automatically inferred.
+The use of <code>skos:narrower</code> makes it possible to declare new
+concept schemes which extend an existing scheme by adding additional aggregation layers on top.
+All items are linked to the scheme via <code>skos:inScheme</code>.</p>
+</section>
+
+<section id="schemes-hierarchy-nonskos">
+<h3><span class="secno">8.3 </span>Non-SKOS hierarchies</h3>
+
+<p>It is sometimes convenient to be able to specify a hierarchical arrangement of
+concepts other than through the use of the SKOS relation <code>skos:narrower</code>.
+There are several situations where this is useful:</p>
+
+<ul>
+<li>In some cases publishers wish to be able to reuse existing reference data as their
+code lists. This particularly occurs where a geographic or admin-geographic hierarchy
+is already maintained by a separate authority but which uses non-SKOS containment or part-of relationships.</li>
+<li>Where such maintained reference data is to be reused there can be multiple hierarchies which relate
+the same codes. In particular a set of geographic entities may participate in both a geographic-containment hierarchy
+and an administrative hierarchy which do not precisely align. </li>
+<li>The SKOS relations do not define when the child concepts are disjoint (mutually exclusive) or when they form
+a complete cover of the parent concept (exhaustive).</li>
+</ul>
+
+<p>The Data Cube vocabulary supports this situation through the <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> class.
+An instance of <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> defines a set of root concepts in the hierarchy
+(<code><a href="#dfn-qb-hierarchyroot" class="internalDFN">qb:hierarchyRoot</a></code>) and a parent-to-child relationship (<code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code>) which
+links a term in the hierarchy to its immediate sub-terms. </p>
+
+<p>Thus a <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>
+is similar to a <code>skos:ConceptScheme</code> in which <code><a href="#dfn-qb-hierarchyroot" class="internalDFN">qb:hierarchyRoot</a></code> plays the same
+role as <code>skos:hasTopConcept</code>, and the value of <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> plays
+the same role as <code>skos:narrower</code>. In the case where a code list is already available as a SKOS concept scheme or collection
+then those <em class="rfc2119" title="should">should</em> be used directly; <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> is provided for cases where the
+terms are not available as SKOS but are available in some other RDF representation suitable for reuse.
+</p>
+
+<p>For example, the Ordnance Survey of Great Britain publishes a geographic hierarchy which has
+eleven roots (European Regions such as Wales, Scotland, the South West) and uses a spatial relations
+ontology to define a containment hierarchy. This could be represented as a <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> using the following.</p>
+
+<div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example">PREFIX spatial: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
+
+eg:GBgeoHierarchy a qb:HierarchicalCodeList;
+ rdfs:label "Geographic Hierarchy for Great Britain"@en;
+ qb:hierarchyRoot
+ <http://data.ordnancesurvey.co.uk/id/7000000000041427>, # South West
+ <http://data.ordnancesurvey.co.uk/id/7000000000041426>, # West Midlands
+ <http://data.ordnancesurvey.co.uk/id/7000000000041421>, # South East
+ <http://data.ordnancesurvey.co.uk/id/7000000000041430>, # Yorkshire & the Humber
+ <http://data.ordnancesurvey.co.uk/id/7000000000041423>, # East Midlands
+ <http://data.ordnancesurvey.co.uk/id/7000000000041425>, # Eastern
+ <http://data.ordnancesurvey.co.uk/id/7000000000041428>, # London
+ <http://data.ordnancesurvey.co.uk/id/7000000000041431>, # North West
+ <http://data.ordnancesurvey.co.uk/id/7000000000041422>, # North East
+ <http://data.ordnancesurvey.co.uk/id/7000000000041424>, # Wales
+ <http://data.ordnancesurvey.co.uk/id/7000000000041429>; # Scotland
+ qb:parentChildProperty spatial:contains;
+ .
+
+eg:geoDimension a qb:DimensionProperty ;
+ qb:codeList eg:GBgeoHierarchy .</pre></div>
+
+<p>Note that in some cases the hierarchy to be reused may only have a
+ property relating child concepts to parent concepts. This situation
+ is handled by declaring
+ the <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> to be
+ the <code>owl:inverseOf</code> of the child-to-parent property. For
+ example:</p>
+
+<div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example">PREFIX spatial: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
+
+eg:GBgeoHierarchy a qb:HierarchicalCodeList;
+ qb:parentChildProperty [owl:inverseOf spatial:within] .</pre></div>
+
+<p>Future extensions of Data Cube may support additional sub classes
+ of <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>, for example to
+ declare hierarchies in which each parent is a disjoint union of its children.</p>
+
+<!--
+<p>A sub class of <code><a>qb:HierarchicalCodeList</a></code>, <code><a>qb:AggregatableHierarchy</a></code>, is provided to declare
+hierarchies where for each parent concept the set of child concepts form a disjoint cover (i.e. a
+mutually-exclusive and exhaustive decomposition) of the parent.</p>
+-->
+
+</section>
+
+<section id="schemes-aggregation">
+<h3><span class="secno">8.4 </span>Aggregation</h3>
+
+<p>The use of SKOS, or non-SKOS, hierarchies makes it possible to publish aggregated
+statistics for the non-leaf concepts in the hierarchy. The Data Cube vocabulary itself imposes
+no constraints on how such aggregation is done. Indeed in statistical applications the
+appropriate statistical corrections to make to aggregated values may be non-trivial and dependent on
+the data and precise analysis methodology. Even in simple, non-statistical, applications such
+as OLAP a number of different aggregation operators are commonly used.
+</p>
+
+<p>Vocabulary terms to represent the aggregation operations employed within a given dataset, and how one dataset
+might be derived from another, are not supported in this version of the Data Cube specification. This
+area may be addressed by future extensions to Data Cube.</p>
+</section>
+
+</section>
+
+
+<section id="metadata">
+<!--OddPage--><h2><span class="secno">9. </span>DataSet metadata</h2>
+
+<p>DataSets should be marked up with metadata to support discovery, presentation and
+ processing. Dublin Core Terms [<cite><a class="bibref" href="#bib-DC11">DC11</a></cite>] <em class="rfc2119" title="should">should</em> be used
+ for representing the key metadata annotations commonly needed for
+ DataSets. The RDFS terms for display label (<code>rdfs:label</code>)
+ descriptive comment (<code>rdfs:comment</code>) <em class="rfc2119" title="should">should</em> be given as
+ well for compatibility with earlier versions of Data Cube and common
+ RDF practice.
+</p>
+
+<p>The recommend core set of metadata terms is:</p>
+<ul>
+ <li><code>dct:title</code></li>
+ <li><code>rdfs:label</code> - may be same as <code>dct:title</code></li>
+ <li><code>dct:description</code></li>
+ <li><code>rdfs:comment</code> - may be same as <code>dct:description</code></li>
+ <li><code>dct:issued</code></li>
+ <li><code>dct:modified</code></li>
+ <li><code>dct:subject</code></li>
+ <li><code>dct:publisher</code></li>
+ <li><code>dct:license</code></li>
+</ul>
+
+<p>Other documents, notably [<cite><a class="bibref" href="#bib-DCAT">DCAT</a></cite>], provide additional
+ recommendations for metadata terms for data sets
+ which may be used for describing Data Cube DataSets.</p>
+
+<section id="metadata-categorization">
+<h3><span class="secno">9.1 </span>Categorizing a data set</h3>
+
+<p>Publishers of statistics often categorize their data sets into different statistical
+domains, such as <em>Education</em>, <em>Labour</em>, or <em>Transportation</em>.
+We encourage use of <code>dct:subject</code> to record such a classification of
+a whole data set.
+The classification terms can include coarse grained classifications, such
+as the List of Subject-matter Domains from the SDMX Content-oriented Guidelines,
+and fine grained classifications to support discovery of data sets.</p>
+
+<p>The classification schemes are typically represented using the SKOS vocabulary. For
+convenience the SMDX Subject-matter Domains have been encoded as a SKOS concept scheme
+at <a href="http://purl.org/linked-data/sdmx/2009/subject">http://purl.org/linked-data/sdmx/2009/subject#</a>.</p>
+
+<p>Thus our sample dataset might be marked up by:</p>
+
+<div class="example"><div class="example-title"><span>Example 18</span></div><pre class="example">eg:dataset1 a qb:DataSet;
+ rdfs:label "Life expectancy"@en;
+ dct:title "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
+ dct:description "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
+ dct:issued "2010-08-11"^^xsd:date;
+ dct:subject
+ sdmx-subject:3.2 , # regional and small area statistics
+ sdmx-subject:1.4 , # Health
+ ex:wales; # Wales
+ ...</pre></div>
+
+<p>where <code>eg:Wales</code> is a <code>skos:Concept</code> drawn from an appropriate controlled
+vocabulary for places.</p>
+</section>
+
+
+<section id="metadata-publishers">
+<h3><span class="secno">9.2 </span>Describing publishers</h3>
+
+<p>The organization that publishes a dataset should be recorded as part of the dataset metadata.
+Again we recommend use of the Dublin Core term <code>dct:publisher</code> for this.
+The organization should be represented as an instance of <code>foaf:Agent</code>, or
+some more specific subclass such as <code>org:Organization</code> [<cite><a class="bibref" href="#bib-ORG">ORG</a></cite>].</p>
+
+<div class="example"><div class="example-title"><span>Example 19</span></div><pre class="example">eg:dataset1 a qb:DataSet;
+ dct:publisher <http://example.com/meta#organization> .
+
+<http://example.com/meta#organization> a org:Organization, foaf:Agent;
+ rdfs:label "Example org" . </pre></div>
+
+<p>Extension vocabularies may provide additional metadata properties and may impose
+ constraints on what metadata must be provided.</p>
+</section>
+
+</section>
+
+<section id="normalize">
+<!--OddPage--><h2><span class="secno">10. </span>Abbreviated and normalized data cubes</h2>
+
+<p>In normal form then the <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>s which
+make up a Data Cube have property values for each of the required
+dimensions, attributes and measures as declared in the associated data
+structure definition. This form for a Data Cube is
+termed <em><dfn id="dfn-normalized">normalized</dfn></em>. It is a convenient format for
+querying data and makes it possible to write uniform queries which
+extract sets of observations, including from across multiple
+cubes. However, the verbosity of a fully normalized representation
+incurs overheads in transmission and storage of Data Cubes which may
+be problematic in some settings.
+</p>
+
+<p>To address this the Data Cube vocabulary supports a notion of
+an <em><dfn id="dfn-abbreviated">abbreviated</dfn></em> format in which component
+properties may be <em><dfn id="dfn-attached">attached</dfn></em> to other levels in the
+Data Cube. Specifically they may be attached to
+a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> or <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>.
+In those cases the attached property is taken to be applied to all
+the <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> instances associated with that
+attachment point. For illustration
+see <a href="#attachment-example">example 4</a> in which the unit of
+measure is declared as to be attached to the whole data set and need
+not be repeated for every observation.</p>
+
+<p>It is also possible to attach attributes to a <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code>
+ in which case the attribute is intended to apply only to that property and not
+ to the observations in which that property occurs.</p>
+
+<section id="normalize-algorithm">
+<h3><span class="secno">10.1 </span>Normalization algorithm</h3>
+
+<div class="note"><div class="note-title"><span>Note</span></div><div class="">
+This section is At Risk. The working group believes this formulation to
+be correct and compatible with earlier versions of the Data Cube vocabulary.
+However as a new addition it has not received as much
+scrutiny as other parts of the specification. If problems are uncovered
+during the Last Call process the working group may retract all or part of this section.
+</div></div>
+
+<p>We define these notions by means of a transformation algorithm
+ which can normalize an abbreviated Data Cube. We express this transformation using the SPARQL 1.1
+ Update language [<cite><a class="bibref" href="#bib-SPARQL-UPDATE-11">SPARQL-UPDATE-11</a></cite>]. Use of this notation does not imply that
+ the transformation must be implemented this way. Information
+ exchanges using Data Cube may retain data in abbreviated form and
+ use other techniques such as query rewriting to ease access, may
+ implement the normalization algorithm by other means or may handle
+ all data in normalized form or any mix of these.</p>
+
+
+<p>The normalization algorithm comprises two sets of SPARQL Update
+ operations which should be applied in turn to a SPARQL Dataset in which the
+ default graph contains the Data Cube RDF graph to be normalized.</p>
+
+<p>The first update operation performs selective type and property closure
+ operations. These serve two purposes. They ensure
+ that <code>rdf:type</code> assertions on instances
+ of <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> and <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>
+ may be omitted in an abbreviated Data Cube. They also simplify
+ the second set of update operations by expanding
+ the sub properties of <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
+ (specifically <code><a href="#dfn-qb-dimension" class="internalDFN">qb:dimension</a></code>, <code><a href="#dfn-qb-measure" class="internalDFN">qb:measure</a></code>
+ and <code><a href="#dfn-qb-attribute" class="internalDFN">qb:attribute</a></code>).</p>
+
+<table class="bordered-table">
+ <thead>
+ <tr><th>Phase 1: Type and property closure</th></tr>
+ </thead>
+ <tbody><tr><td>
+<pre>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
+PREFIX qb: <http://purl.org/linked-data/cube#>
+
+INSERT {
+ ?o rdf:type qb:Observation .
+} WHERE {
+ [] qb:observation ?o .
+};
+
+INSERT {
+ ?o rdf:type qb:Observation .
+} WHERE {
+ ?o qb:dataSet [] .
+};
+
+INSERT {
+ ?s rdf:type qb:Slice .
+} WHERE {
+ [] qb:slice ?s.
+};
+
+INSERT {
+ ?cs qb:componentProperty ?p .
+ ?p rdf:type qb:DimensionProperty .
+} WHERE {
+ ?cs qb:dimension ?p .
+};
+
+INSERT {
+ ?cs qb:componentProperty ?p .
+ ?p rdf:type qb:MeasureProperty .
+} WHERE {
+ ?cs qb:measure ?p .
+};
+
+INSERT {
+ ?cs qb:componentProperty ?p .
+ ?p rdf:type qb:AttributeProperty .
+} WHERE {
+ ?cs qb:attribute ?p .
+}
+</pre>
+ </td></tr></tbody>
+</table>
+
+
+<p>These closure operations are implied by the RDFS semantics of the
+ Data Cube vocabulary. Data Cube processors <em class="rfc2119" title="may">may</em> apply full RDFS
+ closure in place of the update operation defined here.</p>
+
+<p>The second update operation checks the components of the data
+ structure definition of the data set for declared attachment levels.
+ For each of the possible attachments levels it looks for occurrences
+ of that component to be pushed down to the corresponding
+ observations.
+</p>
+
+<table class="bordered-table">
+ <thead>
+ <tr><th>Phase 2: Push down attachment levels</th></tr>
+ </thead>
+ <tbody><tr><td>
+<pre>PREFIX qb: <http://purl.org/linked-data/cube#>
+
+# Dataset attachments
+INSERT {
+ ?obs ?comp ?value
+} WHERE {
+ ?spec qb:componentProperty ?comp ;
+ qb:componentAttachment qb:DataSet .
+ ?dataset qb:structure [qb:component ?spec];
+ ?comp ?value .
+ ?obs qb:dataSet ?dataset.
+};
+
+# Slice attachments
+INSERT {
+ ?obs ?comp ?value
+} WHERE {
+ ?spec qb:componentProperty ?comp;
+ qb:componentAttachment qb:Slice .
+ ?dataset qb:structure [qb:component ?spec];
+ qb:slice ?slice .
+ ?slice ?comp ?value;
+ qb:observation ?obs .
+};
+
+# Dimension values on slices
+INSERT {
+ ?obs ?comp ?value
+} WHERE {
+ ?spec qb:componentProperty ?comp .
+ ?comp a qb:DimensionProperty .
+ ?dataset qb:structure [qb:component ?spec];
+ qb:slice ?slice .
+ ?slice ?comp ?value;
+ qb:observation ?obs .
+}
+</pre>
+ </td></tr></tbody>
+</table>
+
+
+</section>
+
+</section>
+
+<section id="wf">
+<!--OddPage--><h2><span class="secno">11. </span>Well-formed cubes</h2>
+
+<div class="note"><div class="note-title"><span>Note</span></div><div class="">
+This section is At Risk. The working group believes these criteria to
+be correct and compatible with earlier versions of the Data Cube vocabulary.
+However as a new addition they have not received as much
+scrutiny as other parts of the specification. If problems are uncovered
+during the Last Call process the working group may retract all or part of this section.
+</div></div>
+
+<p>An instance of an RDF Data Cube should conform to a set of
+ integrity constraints which we define in this section.</p>
+
+<p>A <dfn id="dfn-well-formed">well-formed</dfn> RDF Data Cube is an a RDF graph describing
+ one or more instances of <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> for which
+ each of the integrity checks defined here passes.</p>
+
+<p>A <dfn id="dfn-well-formed-abbreviated">well-formed abbreviated</dfn> RDF Data Cube is an a RDF
+ graph which, when expanded using
+ the <a href="#normalize-algorithm">normalization algorithm</a>,
+ yields a <a>well-formed RDF Data Cube</a>.</p>
+
+<section id="wf-rules">
+<h3><span class="secno">11.1 </span>Integrity constraints</h3>
+
+<p>Each integrity constraint is expressed as narrative prose and, where possible, a SPARQL
+ [<cite><a class="bibref" href="#bib-SPARQL-QUERY-11">SPARQL-QUERY-11</a></cite>] ASK query or query template. If the ASK query is applied to an RDF graph then it
+ will return <em>true</em> if that graph contains one or more Data Cube instances which
+ violate the corresponding constraint.
+</p>
+<p>
+ Using SPARQL queries to
+ express the integrity constraints does not imply that integrity
+ checking must be performed this way. Implementations are free
+ to use alternative query formulations or alternative implementation
+ techniques to perform equivalent checks. </p>
+
+<p>Each integrity constraint query assumes the following set of prefix bindings:</p>
+<pre>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
+PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
+PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
+PREFIX qb: <http://purl.org/linked-data/cube#>
+PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
+PREFIX owl: <http://www.w3.org/2002/07/owl#>
+</pre>
+
+<p>The complete set of constraints is listed below.</p>
+
+<h3 id="ic-0">IC-0. Datatype consistency</h3>
+<p>
+The RDF graph must be consistent under RDF D-entailment [<cite><a class="bibref" href="#bib-RDF-MT">RDF-MT</a></cite>]
+using a datatype map containing all the datatypes used within the graph.
+</p>
+
+<h3 id="ic-1">IC-1. Unique DataSet</h3>
+<p>
+Every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> has exactly one associated <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ {
+ # Check observation has a data set
+ ?obs a qb:Observation .
+ FILTER NOT EXISTS { ?obs qb:dataSet ?dataset1 . }
+ } UNION {
+ # Check has just one data set
+ ?obs a qb:Observation ;
+ qb:dataSet ?dataset1, ?dataset2 .
+ FILTER (?dataset1 != ?dataset2)
+ }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-2">IC-2. Unique DSD</h3>
+<p>
+Every <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> has exactly one associated <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ {
+ # Check dataset has a dsd
+ ?dataset a qb:DataSet .
+ FILTER NOT EXISTS { ?dataset qb:structure ?dsd . }
+ } UNION {
+ # Check has just one dsd
+ ?dataset a qb:DataSet ;
+ qb:structure ?dsd1, ?dsd2 .
+ FILTER (?dsd1 != ?dsd2)
+ }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-3">IC-3. DSD includes measure</h3>
+<p>
+Every <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> must include at least one declared measure.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?dsd a qb:DataStructureDefinition .
+ FILTER NOT EXISTS { ?dsd qb:component [qb:componentProperty [a qb:MeasureProperty]] }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-4">IC-4. Dimensions have range</h3>
+<p>
+Every dimension declared in a <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> must have a declared <code><a>rdfs:range</a></code>.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?dim a qb:DimensionProperty .
+ FILTER NOT EXISTS { ?dim rdfs:range [] }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-5">IC-5. Concept dimensions have code lists</h3>
+<p>
+Every dimension with range <code><a>skos:Concept</a></code> must have a <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code>.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?dim a qb:DimensionProperty ;
+ rdfs:range skos:Concept .
+ FILTER NOT EXISTS { ?dim qb:codeList [] }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-6">IC-6. Only attributes may be optional</h3>
+<p>
+The only components of
+a <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> that may be marked as
+optional, using <code><a href="#dfn-qb-componentrequired" class="internalDFN">qb:componentRequired</a></code> are attributes.
+</p>
+
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?dsd qb:component ?componentSpec .
+ ?componentSpec qb:componentRequired "false"^^xsd:boolean ;
+ qb:componentProperty ?component .
+ FILTER NOT EXISTS { ?component a qb:AttributeProperty }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-7">IC-7. Slice Keys must be declared</h3>
+<p>
+Every <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code> must be associated with a <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>.
+</p>
+
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?sliceKey a qb:SliceKey .
+ FILTER NOT EXISTS { [a qb:DataStructureDefinition] qb:sliceKey ?sliceKey }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-8">IC-8. Slice Keys consistent with DSD</h3>
+<p>
+Every <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code> on a <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code> must also be declared as a <code><a href="#dfn-qb-component" class="internalDFN">qb:component</a></code> of the associated <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>.
+</p>
+
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?slicekey a qb:SliceKey;
+ qb:componentProperty ?prop .
+ ?dsd qb:sliceKey ?sliceKey .
+ FILTER NOT EXISTS { ?dsd qb:component [qb:componentProperty ?prop] }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-9">IC-9. Unique slice structure</h3>
+<p>
+Each <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code> must have exactly one associated <code><a href="#dfn-qb-slicestructure" class="internalDFN">qb:sliceStructure</a></code>.
+</p>
+
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ {
+ # Slice has a key
+ ?slice a qb:Slice .
+ FILTER NOT EXISTS { ?slice qb:sliceStructure ?key }
+ } UNION {
+ # Slice has just one key
+ ?slice a qb:Slice ;
+ qb:sliceStructure ?key1, ?key2;
+ FILTER (?key1 != ?key2)
+ }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+
+<h3 id="ic-10">IC-10. Slice dimensions complete</h3>
+<p>
+Every <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code> must have a value for every dimension declared in its <code><a href="#dfn-qb-slicestructure" class="internalDFN">qb:sliceStructure</a></code>.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?slice qb:sliceStructure [qb:componentProperty ?dim] .
+ FILTER NOT EXISTS { ?slice ?dim [] }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-11">IC-11. All dimensions required</h3>
+<p>
+Every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> has a value for each dimension declared in its associated <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>.
+</p>
+
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
+ ?dim a qb:DimensionProperty;
+ FILTER NOT EXISTS { ?obs ?dim [] }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-12">IC-12. No duplicate observations</h3>
+<p>
+No two <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>s in the same <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> may have the same value for all dimensions.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ FILTER( ?allEqual )
+ {
+ # For each pair of observations test if all the dimension values are the same
+ SELECT (MIN(?equal) AS ?allEqual) WHERE {
+ ?obs1 qb:dataSet ?dataset .
+ ?obs2 qb:dataSet ?dataset .
+ FILTER (?obs1 != ?obs2)
+ ?dataset qb:structure/qb:component/qb:componentProperty ?dim .
+ ?dim a qb:DimensionProperty .
+ ?obs1 ?dim ?value1 .
+ ?obs2 ?dim ?value2 .
+ BIND( ?value1 = ?value2 AS ?equal)
+ } GROUP BY ?obs1 ?obs2
+ }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-13">IC-13. Required attributes</h3>
+<p>
+Every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> has a value for each declared attribute that is marked as required.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?obs qb:dataSet/qb:structure/qb:component ?component .
+ ?component qb:componentRequired "true"^^xsd:boolean ;
+ qb:componentProperty ?attr .
+ FILTER NOT EXISTS { ?obs ?attr [] }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-14">IC-14. All measures present</h3>
+<p>
+In a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> which does not use a <a href="#dfn-measure-dimension" class="internalDFN">Measure dimension</a> then each individual <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> must have a value for every declared measure.
+</p>
+
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ # Observation in a non-measureType cube
+ ?obs qb:dataSet/qb:structure ?dsd .
+ FILTER NOT EXISTS { ?dsd qb:component/qb:componentProperty qb:measureType }
+
+ # verify every measure is present
+ ?dsd qb:component/qb:componentProperty ?measure .
+ ?measure a qb:MeasureProperty;
+ FILTER NOT EXISTS { ?obs ?measure [] }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-15">IC-15. Measure dimension consistent</h3>
+<p>
+In a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> which uses a <a href="#dfn-measure-dimension" class="internalDFN">Measure dimension</a> then each <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> must have a value for the measure corresponding to its given <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code>.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ # Observation in a measureType-cube
+ ?obs qb:dataSet/qb:structure ?dsd ;
+ qb:measureType ?measure .
+ ?dsd qb:component/qb:componentProperty qb:measureType .
+ # Must have value for its measureType
+ FILTER NOT EXISTS { ?obs ?measure [] }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-16">IC-16. Single measure on measure dimension observation</h3>
+<p>
+In a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> which uses a <a href="#dfn-measure-dimension" class="internalDFN">Measure dimension</a> then each <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> must only have a value for one measure (by IC-15 this will be the measure corresponding to its <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code>).
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ # Observation with measureType
+ ?obs qb:dataSet/qb:structure ?dsd ;
+ qb:measureType ?measure ;
+ ?omeasure [] .
+ # Any measure on the observation
+ ?dsd qb:component/qb:componentProperty qb:measureType ;
+ qb:component/qb:componentProperty ?omeasure .
+ ?omeasure a qb:MeasureProperty .
+ # Must be the same as the measureType
+ FILTER (?omeasure != ?measure)
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-17">IC-17. All measures present in measures dimension cube </h3>
+<p>
+In a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> which uses a <a href="#dfn-measure-dimension" class="internalDFN">Measure dimension</a> then if there is a Observation for some combination of non-measure dimensions then there must be other Observations with the same non-measure dimension values for each of the declared measures.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ {
+ # Count number of other measures found at each point
+ SELECT ?numMeasures (COUNT(?obs2) AS ?count) WHERE {
+ {
+ # Find the DSDs and check how many measures they have
+ SELECT ?dsd (COUNT(?m) AS ?numMeasures) WHERE {
+ ?dsd qb:component/qb:componentProperty ?m.
+ ?m a qb:MeasureProperty .
+ } GROUP BY ?dsd
+ }
+
+ # Observation in measureType cube
+ ?obs1 qb:dataSet/qb:structure ?dsd;
+ qb:dataSet ?dataset ;
+ qb:measureType ?m1 .
+
+ # Other observation at same dimension value
+ ?obs2 qb:dataSet ?dataset ;
+ qb:measureType ?m2 .
+ FILTER NOT EXISTS {
+ ?dsd qb:component/qb:componentProperty ?dim .
+ FILTER (?dim != qb:measureType)
+ ?dim a qb:DimensionProperty .
+ ?obs1 ?dim ?v1 .
+ ?obs2 ?dim ?v2.
+ FILTER (?v1 != ?v2)
+ }
+
+ } GROUP BY ?obs1 ?numMeasures
+ HAVING (?count != ?numMeasures)
+ }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-18">IC-18. Consistent data set links</h3>
+<p>
+If a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> D has a <code><a href="#dfn-qb-slice-1" class="internalDFN">qb:slice</a></code> S, and S has an <code><a href="#dfn-qb-observation-1" class="internalDFN">qb:observation</a></code> O, then the <code><a href="#dfn-qb-dataset-1" class="internalDFN">qb:dataSet</a></code> corresponding to O must be D.
+</p>
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?dataset qb:slice ?slice .
+ ?slice qb:observation ?obs .
+ FILTER NOT EXISTS { ?obs qb:dataSet ?dataset . }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-19">IC-19. Codes from code list</h3>
+<p>
+If a dimension property has a <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code>, then the value of the dimension property on every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> must be in the code list.
+</p>
+<p>The following integrity check queries must be applied to an RDF graph which contains the
+definition of the code list as well as the Data Cube to be checked. In the case
+of a <code>skos:ConceptScheme</code> then each concept must be linked to the scheme using
+<code>skos:inScheme</code>. In the case of a <code>skos:Collection</code> then the
+collection must link to each concept or nested collection using <code>skos:member</code> (i.e. if the
+collection uses <code>skos:memberList</code> then the entailment of <code>skos:member</code>
+values defined by <a href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/#S36">S36</a>
+in [<cite><a class="bibref" href="#bib-SKOS-REFERENCE">SKOS-REFERENCE</a></cite>] must be materialized). </p>
+
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
+ ?dim a qb:DimensionProperty ;
+ qb:codeList ?list .
+ ?list a skos:ConceptScheme .
+ ?obs ?dim ?v .
+ FILTER NOT EXISTS { ?v skos:inScheme ?list }
+}
+
+ASK {
+ ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
+ ?dim a qb:DimensionProperty ;
+ qb:codeList ?list .
+ ?list a skos:Collection .
+ ?obs ?dim ?v .
+ FILTER NOT EXISTS { ?list skos:member+ ?v }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-20">IC-20. Codes from hierarchy</h3>
+<p>
+If a dimension property has
+a <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> with a
+non-blank <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> then the value of
+that dimension property on every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>
+must be reachable from a root of the hierarchy using zero or more hops along the <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> links.
+</p>
+<p>
+This check cannot be made by a simple fixed SPARQL query. Instead a
+query template is supplied.
+An instance of the template should be generated
+for each <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> which has an IRI
+value for its <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code>.
+That is for each binding of <code>?p</code> in the following
+instantiation query:</p>
+<pre>SELECT ?p WHERE {
+ ?hierarchy a qb:HierarchicalCodeList ;
+ qb:parentChildProperty ?p .
+ FILTER ( isIRI(?p) )
+}
+</pre>
+
+<p>The template is then instantiated by replacing the
+ string <code>$p</code> by the IRI found by the
+ instantiation query. The template is:</p>
+
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
+ ?dim a qb:DimensionProperty ;
+ qb:codeList ?list .
+ ?list a qb:HierarchicalCodeList .
+ ?obs ?dim ?v .
+ FILTER NOT EXISTS { ?list qb:hierarchyRoot/<$p>* ?v }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+<h3 id="ic-21">IC-21. Codes from hierarchy (inverse)</h3>
+<p>
+If a dimension property has
+a <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> with an
+inverse <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> then the value of
+that dimension property on every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>
+must be reachable from a root of the hierarchy using zero or more hops along the inverse <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> links.
+</p>
+
+<p>
+This check cannot be made by a simple fixed SPARQL query. Instead a
+query template is supplied.
+An instance of the template should be generated
+for each <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> which has a blank-node
+value for its <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code>, with an
+associated inverse property.
+That is for each binding of <code>?p</code> in the following
+instantiation query:</p>
+<pre>SELECT ?p WHERE {
+ ?hierarchy a qb:HierarchicalCodeList;
+ qb:parentChildProperty ?pcp .
+ FILTER( isBlank(?pcp) )
+ ?pcp owl:inverseOf ?p .
+ FILTER( isIRI(?p) )
+}
+</pre>
+
+<p>The template is then instantiated by replacing the
+ string <code>$p</code> by the IRI found by the
+ instantiation query. The template is:</p>
+
+<table class="bordered-table">
+ <tbody>
+ <tr><td><pre>ASK {
+ ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
+ ?dim a qb:DimensionProperty ;
+ qb:codeList ?list .
+ ?list a qb:HierarchicalCodeList .
+ ?obs ?dim ?v .
+ FILTER NOT EXISTS { ?list qb:hierarchyRoot/(^<$p>)* ?v }
+}
+ </pre></td></tr>
+ </tbody>
+</table>
+
+</section>
+
+</section>
+
+<section id="vocab-reference">
+<!--OddPage--><h2><span class="secno">12. </span>Vocabulary reference</h2>
+
+
+<section id="reference-datasets">
+<h3><span class="secno">12.1 </span>DataSets</h3>
+
+<p><em>See Section <a href="#datasets">Expressing data sets</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_DataSet">
+ <em>Class:</em> <code><dfn id="dfn-qb-dataset">qb:DataSet</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-attachable" class="internalDFN">qb:Attachable</a></code>
+ <em>Equivalent to: </em>
+ <code>scovo:Dataset</code>
+ </dt>
+ <dd>Represents a collection of observations, possibly organized into various slices, conforming to some common dimensional structure.</dd>
+</dl>
+</section>
+
+
+<section id="reference-observations">
+<h3><span class="secno">12.2 </span>Observations</h3>
+<p><em>See Section <a href="#datasets">Expressing data sets</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_Observation">
+ <em>Class:</em> <code><dfn id="dfn-qb-observation">qb:Observation</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-attachable" class="internalDFN">qb:Attachable</a></code>
+ <em>Equivalent to: </em>
+ <code>scovo:Item</code>
+ </dt>
+ <dd>A single observation in the cube, may have one or more associated measured values.</dd>
+
+ <dt id="ref_qb_dataSet_LC">
+ <em>Property:</em> <code><dfn id="dfn-qb-dataset-1">qb:dataSet</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>
+ )
+ </dt>
+ <dd>Indicates the data set of which this observation is a part.</dd>
+
+ <dt id="ref_qb_observation_LC">
+ <em>Property:</em> <code><dfn id="dfn-qb-observation-1">qb:observation</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>
+ )
+ </dt>
+ <dd>Indicates a observation contained within this slice of the data set.</dd>
+</dl>
+</section>
+
+
+<section id="reference-slices">
+<h3><span class="secno">12.3 </span>Slices</h3>
+<p><em>See Section <a href="#slices">Slices</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_ObservationGroup">
+ <em>Class:</em> <code><dfn id="dfn-qb-observationgroup">qb:ObservationGroup</dfn></code>
+ </dt>
+ <dd>A, possibly arbitrary, group of observations.</dd>
+
+
+ <dt id="ref_qb_Slice">
+ <em>Class:</em> <code><dfn id="dfn-qb-slice">qb:Slice</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-attachable" class="internalDFN">qb:Attachable</a></code>,
+ <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code>
+ </dt>
+ <dd>Denotes a subset of a DataSet defined by fixing a subset of the dimensional values, component properties on the Slice.</dd>
+
+ <dt id="ref_qb_slice_LC">
+ <em>Property:</em> <code><dfn id="dfn-qb-slice-1">qb:slice</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>;
+ <em>sub property of:</em>
+ <code><a href="#dfn-qb-observationgroup-1" class="internalDFN">qb:observationGroup</a></code>
+ )
+ </dt>
+ <dd>Indicates a subset of a DataSet defined by fixing a subset of the dimensional values.</dd>
+
+ <dt id="ref_qb_observationGroup">
+ <em>Property:</em> <code><dfn id="dfn-qb-observationgroup-1">qb:observationGroup</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code>
+ )
+ </dt>
+ <dd>Indicates a group of observations. The domain of this property is left open so that a group may be attached to different resources and need not be restricted to a single DataSet.</dd>
+
+</dl>
+</section>
+
+
+<section id="reference-components">
+<h3><span class="secno">12.4 </span>Dimensions, Attributes, Measures</h3>
+<p><em>See Section <a href="#dsd-dimensions">Dimensions, attributes and measures</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_Attachable">
+ <em>Class:</em> <code><dfn id="dfn-qb-attachable">qb:Attachable</dfn></code>
+ </dt>
+ <dd>Abstract superclass for everything that can have attributes and dimensions.</dd>
+
+ <dt id="ref_qb_ComponentProperty">
+ <em>Class:</em> <code><dfn id="dfn-qb-componentproperty">qb:ComponentProperty</dfn></code>
+ <em>Sub class of: </em>
+ <code>rdf:Property</code>
+ </dt>
+ <dd>Abstract super-class of all properties representing dimensions, attributes or measures.</dd>
+
+ <dt id="ref_qb_DimensionProperty">
+ <em>Class:</em> <code><dfn id="dfn-qb-dimensionproperty">qb:DimensionProperty</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>,
+ <code><a href="#dfn-qb-codedproperty" class="internalDFN">qb:CodedProperty</a></code>
+ </dt>
+ <dd>The class of component properties which represent the dimensions of the cube.</dd>
+
+ <dt id="ref_qb_AttributeProperty">
+ <em>Class:</em> <code><dfn id="dfn-qb-attributeproperty">qb:AttributeProperty</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
+ </dt>
+ <dd>The class of component properties which represent attributes of observations in the cube, e.g. unit of measurement.</dd>
+
+ <dt id="ref_qb_MeasureProperty">
+ <em>Class:</em> <code><dfn id="dfn-qb-measureproperty">qb:MeasureProperty</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
+ </dt>
+ <dd>The class of component properties which represent the measured value of the phenomenon being observed.</dd>
+
+ <dt id="ref_qb_CodedProperty">
+ <em>Class:</em> <code><dfn id="dfn-qb-codedproperty">qb:CodedProperty</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
+ </dt>
+ <dd>Superclass of all coded component properties.</dd>
+</dl>
+</section>
+
+
+<section id="reference-component-properties">
+<h3><span class="secno">12.5 </span>Reusable general purpose component properties</h3>
+<p><em>See Section <a href="#dsd-mm-dim">Measure dimensions</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_measureType">
+ <em>Property:</em> <code><dfn id="dfn-qb-measuretype">qb:measureType</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code>
+ )
+ </dt>
+ <dd>Generic measure dimension, the value of this dimension indicates which measure (from the set of measures in the DSD) is being given by the observation.</dd>
+</dl>
+</section>
+
+
+<section id="reference-dsd">
+<h3><span class="secno">12.6 </span>Data Structure Definitions</h3>
+<p><em>See Section <a href="#dsd-dsd">ComponentSpecifications and DataStructureDefinitions</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_DataStructureDefinition">
+ <em>Class:</em> <code><dfn id="dfn-qb-datastructuredefinition">qb:DataStructureDefinition</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-componentset" class="internalDFN">qb:ComponentSet</a></code>
+ </dt>
+ <dd>Defines the structure of a DataSet or slice.</dd>
+
+ <dt id="ref_qb_structure">
+ <em>Property:</em> <code><dfn id="dfn-qb-structure">qb:structure</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>
+ )
+ </dt>
+ <dd>Indicates the structure to which this data set conforms</dd>
+
+ <dt id="ref_qb_component">
+ <em>Property:</em> <code><dfn id="dfn-qb-component">qb:component</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code>
+ )
+ </dt>
+ <dd>Indicates a component specification which is included in the structure of the dataset.</dd>
+</dl>
+</section>
+
+
+<section id="reference-compspec">
+<h3><span class="secno">12.7 </span>Component specifications - for qualifying component use in a DSD</h3>
+<p><em>See Section <a href="#dsd-dsd">ComponentSpecifications and DataStructureDefinitions</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_ComponentSpecification">
+ <em>Class:</em> <code><dfn id="dfn-qb-componentspecification">qb:ComponentSpecification</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-componentset" class="internalDFN">qb:ComponentSet</a></code>
+ </dt>
+ <dd>Used to define properties of a component (attribute, dimension etc) which are specific to its usage in a DSD.</dd>
+
+ <dt id="ref_qb_ComponentSet">
+ <em>Class:</em> <code><dfn id="dfn-qb-componentset">qb:ComponentSet</dfn></code>
+ </dt>
+ <dd>Abstract class of things which reference one or more ComponentProperties</dd>
+
+ <dt id="ref_qb_componentProperty_LC">
+ <em>Property:</em> <code><dfn id="dfn-qb-componentproperty-1">qb:componentProperty</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-componentset" class="internalDFN">qb:ComponentSet</a></code>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
+ )
+ </dt>
+ <dd>Indicates a ComponentProperty (i.e. attribute/dimension) expected on a DataSet, or a dimension fixed in a SliceKey.</dd>
+
+ <dt id="ref_qb_order">
+ <em>Property:</em> <code><dfn id="dfn-qb-order">qb:order</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code>
+ -> <em>Range:</em>
+ <code>xsd:int</code>
+ )
+ </dt>
+ <dd>Indicates a priority order for the components of sets with this structure, used to guide presentations - lower order numbers come before higher numbers, un-numbered components come last.</dd>
+
+ <dt id="ref_qb_componentRequired">
+ <em>Property:</em> <code><dfn id="dfn-qb-componentrequired">qb:componentRequired</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code>
+ -> <em>Range:</em>
+ <code>xsd:boolean</code>
+ )
+ </dt>
+ <dd>Indicates whether a component property is required (true) or optional (false) in the context of a DSD. Only applicable
+ to components corresponding to an attribute. Defaults to false (optional).</dd>
+
+ <dt id="ref_qb_componentAttachment">
+ <em>Property:</em> <code><dfn id="dfn-qb-componentattachment">qb:componentAttachment</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code>
+ -> <em>Range:</em>
+ <code>rdfs:Class</code>
+ )
+ </dt>
+ <dd>Indicates the level at which the component property should be attached, this might be an qb:DataSet, qb:Slice or qb:Observation, or a qb:MeasureProperty.</dd>
+
+ <dt id="ref_qb_dimension">
+ <em>Property:</em> <code><dfn id="dfn-qb-dimension">qb:dimension</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-dimensionproperty" class="internalDFN">qb:DimensionProperty</a></code>
+ ; <em>sub property of: </em>
+ <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
+ )
+ </dt>
+ <dd>An alternative to qb:componentProperty which makes explicit that the component is a dimension.</dd>
+
+ <dt id="ref_qb_measure">
+ <em>Property:</em> <code><dfn id="dfn-qb-measure">qb:measure</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code>
+ ; <em>sub property of: </em>
+ <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
+ )
+ </dt>
+ <dd>An alternative to qb:componentProperty which makes explicit that the component is a measure.</dd>
+
+ <dt id="ref_qb_attribute">
+ <em>Property:</em> <code><dfn id="dfn-qb-attribute">qb:attribute</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-attributeproperty" class="internalDFN">qb:AttributeProperty</a></code>
+ ; <em>sub property of: </em>
+ <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
+ )
+ </dt>
+ <dd>An alternative to qb:componentProperty which makes explicit that the component is a attribute.</dd>
+
+ <dt id="ref_qb_measureDimension">
+ <em>Property:</em> <code><dfn id="dfn-qb-measuredimension">qb:measureDimension</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-dimensionproperty" class="internalDFN">qb:DimensionProperty</a></code>
+ ; <em>sub property of: </em>
+ <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
+ )
+ </dt>
+ <dd>An alternative to qb:componentProperty which makes explicit that the component is a measure dimension.</dd>
+</dl>
+</section>
+
+
+<section id="reference-slice-definitions">
+<h3><span class="secno">12.8 </span>Slice definitions</h3>
+<p><em>See Section <a href="#slices">Slices</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_SliceKey">
+ <em>Class:</em> <code><dfn id="dfn-qb-slicekey">qb:SliceKey</dfn></code>
+ <em>Sub class of: </em>
+ <code><a href="#dfn-qb-componentset" class="internalDFN">qb:ComponentSet</a></code>
+ </dt>
+ <dd>Denotes a subset of the component properties of a DataSet which are fixed in the corresponding slices.</dd>
+
+ <dt id="ref_qb_sliceStructure">
+ <em>Property:</em> <code><dfn id="dfn-qb-slicestructure">qb:sliceStructure</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code>
+ )
+ </dt>
+ <dd>Indicates the slice key corresponding to this slice.</dd>
+
+ <dt id="ref_qb_sliceKey_LC">
+ <em>Property:</em> <code><dfn id="dfn-qb-slicekey-1">qb:sliceKey</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>
+ -> <em>Range:</em>
+ <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code>
+ )
+ </dt>
+ <dd>Indicates a slice key which is used for slices in this dataset.</dd>
+</dl>
+</section>
+
+
+<section id="reference-concepts">
+<h3><span class="secno">12.9 </span>Concepts</h3>
+<p><em>See Section <a href="#schemes">Concept schemes and code lists</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_concept">
+ <em>Property:</em> <code><dfn id="dfn-qb-concept">qb:concept</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
+ -> <em>Range:</em>
+ <code>skos:Concept</code>
+ )
+ </dt>
+ <dd>Gives the concept which is being measured or indicated by a ComponentProperty.</dd>
+
+ <dt id="ref_qb_codeList">
+ <em>Property:</em> <code><dfn id="dfn-qb-codelist">qb:codeList</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-codedproperty" class="internalDFN">qb:CodedProperty</a></code>
+ -> <em>Range:</em>
+ <code>owl:unionOf(skos:ConceptScheme skos:Collection qb:HierarchicalCodeList)</code>
+ )
+ </dt>
+ <dd>Gives the code list associated with a CodedProperty.</dd>
+</dl></section>
+
+<section id="reference-nonskos-hierarchy">
+<h3><span class="secno">12.10 </span>Non-SKOS Hierarchies</h3>
+<p><em>See Section <a href="#schemes-hierarchy-nonskos">Non-SKOS hierarchies</a>.</em></p>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_Hierarchy">
+ <em>Class:</em> <code><dfn id="dfn-qb-hierarchicalcodelist">qb:HierarchicalCodeList</dfn></code>
+ </dt>
+ <dd>Represents a generalized hierarchy of concepts which can be used for coding. The hierarchy is defined by one or more roots together with a property which relates concepts in the hierarchy to their child concept . The same concepts may be members of multiple hierarchies provided that different qb:parentChildProperty values are used for each hierarchy.</dd>
+ <dt id="ref_qb_hierarchyRoot">
+ <em>Property:</em> <code><dfn id="dfn-qb-hierarchyroot">qb:hierarchyRoot</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>
+ )
+ </dt>
+ <dd>Specifies a root of the hierarchy. A hierarchy may have multiple roots but must have at least one. </dd>
+
+ <dt id="ref_qb_parentChildProperty">
+ <em>Property:</em> <code><dfn id="dfn-qb-parentchildproperty">qb:parentChildProperty</dfn></code>
+ ( <em>Domain:</em>
+ <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>
+ -> <em>Range:</em>
+ <code>rdf:Property</code>
+ )
+ </dt>
+ <dd>Specifies a property which relates a parent concept in the hierarchy to a child concept. Note that a child may have more than one parent.</dd>
+
+<!--
+ <dt id="ref_qb_AggregatableHierarchy">
+ <em>Class:</em> <code><dfn>qb:AggregatableHierarchy</dfn></code>
+ </dt>
+ <dd>Indicates a hierarchy in which each parent concept is a disjoint union of its child concepts. So that measures such as simple counts may be aggregated up the hierarchy.</dd>
+-->
+
+</dl>
+</section>
+
+</section>
+
+
+<section id="acknowledgements" class="appendix">
+<!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2>
+
+<p>This work is based on a collaboration that was initiated in a
+workshop on Publishing statistical datasets in SDMX and the semantic
+web, hosted by ONS in Sunningdale, United Kingdom in February 2010 and
+continued at the ODaF 2010 workshop in Tilburg. The authors would like
+to thank all the participants at those workshops for their input into
+this work but especially Arofan Gregory for his patient
+explanations of SDMX and insight in the need and requirements
+for a core Data Cube representation.</p>
+
+<p>The editors would like to thank John Sheridan for his comments,
+suggestions and support for the original work.</p>
+
+<p>Many individuals provided valuable comments on this specification
+as it made its way through the <abbr title="World Wide Web Consortium">W3C</abbr> process. We would like to
+especially acknowledge the contributions of
+Benedikt Kaempgen, Sarven Capadisli and Curran Kelleher.</p>
+
+</section>
+
+<section id="change-history" class="appendix">
+<!--OddPage--><h2><span class="secno">B. </span>Change history </h2>
+
+Changes since <a href="http://www.w3.org/TR/2012/WD-vocab-data-cube-20120405/"><abbr title="World Wide Web Consortium">W3C</abbr> Working Draft 5 April 2012</a>:
+
+<ul>
+ <li>Added <a href="#wf">section</a> on criteria for well-formed cubes. <a href="http://www.w3.org/2011/gld/track/issues/29">ISSUE-29</a></li>
+ <li>Added <a href="#normalize">section</a> on normalization algorithm
+ for handling abbreviated cubes.</li>
+ <li>Added <a href="#conformance">conformance section</a>.
+ </li><li>Clarified that <code><a href="#dfn-qb-componentrequired" class="internalDFN">qb:componentRequired</a></code> is only applicable to
+ attributes and that it defaults to optional.</li>
+ <li>Moved vocabulary reference into the normative body of the specification, adding hyperlinks for all qb: terms.</li>
+ <li>Added <a href="#schemes-hierarchy-nonskos">section</a> on non-skos hierarchies. <a href="http://www.w3.org/2011/gld/track/issues/31">ISSUE-31</a>.</li>
+ <li>Added <a href="#schemes-aggregation">note</a> that aggregation operations and inter-cube relations are out of scope for this version. <a href="http://www.w3.org/2011/gld/track/issues/30">ISSUE-30</a>.</li>
+ <li>Added <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code> as a generalization of <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>. <a href="http://www.w3.org/2011/gld/track/issues/33">ISSUE-33</a>.</li>
+ <li>Removed <code><a>qb:subSlice</a></code> as being problematic in how
+ they interact with attachment levels. <a href="http://www.w3.org/2011/gld/track/issues/34">ISSUE-34</a>.</li>
+ <li>Generalized range of <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code> to allow <code>skos:Collection</code>. <a href="http://www.w3.org/2011/gld/track/issues/39">ISSUE-39</a>.</li>
+ <li>Moved namespace definitions to a normative <a href="#namespaces">section</a> within the body of the specification.</li>
+ <li>Moved Jeni Tennison from being listed as an author to being a
+ contributor. </li>
+</ul>
+
+
+</section>
+
+<section id="references_section" class="appendix">
+</section>
+
+
+
+<section id="references" class="appendix"><!--OddPage--><h2><span class="secno">C. </span>References</h2><section id="normative-references"><h3><span class="secno">C.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-DC11">[DC11]</dt><dd>Dublin Core metadata initiative. <a href="http://dublincore.org/documents/dcmi-terms/"><cite>Dublin Core metadata element set, version 1.1.</cite></a> July 1999. Dublin Core recommendation. URL: <a href="http://dublincore.org/documents/dcmi-terms/">http://dublincore.org/documents/dcmi-terms/</a>
+</dd><dt id="bib-OWL2-PRIMER">[OWL2-PRIMER]</dt><dd>Pascal Hitzler; Markus Krötzsch; Bijan Parsia; Peter F. Patel-Schneider; Sebastian Rudolph. <a href="http://www.w3.org/TR/2009/REC-owl2-primer-20091027/"><cite>OWL 2 Web Ontology Language:Primer.</cite></a> 27 October 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-owl2-primer-20091027/">http://www.w3.org/TR/2009/REC-owl2-primer-20091027/</a>
+</dd><dt id="bib-RDF-CONCEPTS">[RDF-CONCEPTS]</dt><dd>Graham Klyne; Jeremy J. Carroll. <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210"><cite>Resource Description Framework (RDF): Concepts and Abstract Syntax.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210">http://www.w3.org/TR/2004/REC-rdf-concepts-20040210</a>
+</dd><dt id="bib-RDF-MT">[RDF-MT]</dt><dd>Patrick Hayes. <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210"><cite>RDF Semantics.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210">http://www.w3.org/TR/2004/REC-rdf-mt-20040210</a>
+</dd><dt id="bib-RDF-PRIMER">[RDF-PRIMER]</dt><dd>Frank Manola; Eric Miller. <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/"><cite>RDF Primer.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">http://www.w3.org/TR/2004/REC-rdf-primer-20040210/</a>
+</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd>Dan Brickley; Ramanathan V. Guha. <a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210"><cite>RDF Vocabulary Description Language 1.0: RDF Schema.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210">http://www.w3.org/TR/2004/REC-rdf-schema-20040210</a>
+</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119. URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
+</dd><dt id="bib-SKOS-REFERENCE">[SKOS-REFERENCE]</dt><dd>Sean Bechhofer; Alistair Miles. <a href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/"><cite>SKOS Simple Knowledge Organization System Reference.</cite></a> 18 August 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/">http://www.w3.org/TR/2009/REC-skos-reference-20090818/</a>
+</dd><dt id="bib-SPARQL-QUERY-11">[SPARQL-QUERY-11]</dt><dd>Steve Harris; Andy Seaborne. <a href="http://www.w3.org/TR/2012/PR-sparql11-query-20121108/"><cite>SPARQL 1.1 Query Language</cite></a> 8 November 2012. W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/2012/PR-sparql11-query-20121108/">http://www.w3.org/TR/2012/PR-sparql11-query-20121108/</a>
+</dd><dt id="bib-SPARQL-UPDATE-11">[SPARQL-UPDATE-11]</dt><dd>Paul Gearon; Alexandre Passant; Axel Polleres. <a href="http://www.w3.org/TR/2012/PR-sparql11-update-20121108/"><cite>SPARQL 1.1 Update</cite></a> 8 November 2012. W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/2012/PR-sparql11-update-20121108/">http://www.w3.org/TR/2012/PR-sparql11-update-20121108/</a>
+</dd><dt id="bib-TURTLE-TR">[TURTLE-TR]</dt><dd>Eric Prud'hommeaux, Gavin Carothers. <a href="http://www.w3.org/TR/2013/CR-turtle-20130219/"><cite>Turtle: Terse RDF Triple Language.</cite></a> 19 February 2013. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/2013/CR-turtle-20130219/">http://www.w3.org/TR/2013/CR-turtle-20130219/</a>
+</dd></dl></section><section id="informative-references"><h3><span class="secno">C.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-COG">[COG]</dt><dd>SDMX Contnent Oriented Guidelines, <a href="http://sdmx.org/?page_id=11">http://sdmx.org/?page_id=11</a>
+</dd><dt id="bib-DCAT">[DCAT]</dt><dd>Fadi Maali; John Erickson; Phil Archer. <a href="http://www.w3.org/TR/vocab-dcat/"><cite>Data Catalog Vocabulary (DCAT)</cite></a> W3C Working Draft. 12 March 2013. URL: <a href="http://www.w3.org/TR/vocab-dcat/">http://www.w3.org/TR/vocab-dcat/</a>
+</dd><dt id="bib-FOAF">[FOAF]</dt><dd>Dan Brickley, Libby Miller. <a href="http://xmlns.com/foaf/spec/"><cite>FOAF Vocabulary Specification 0.98.</cite></a> 9 August 2010. URL: <a href="http://xmlns.com/foaf/spec/">http://xmlns.com/foaf/spec/</a>
+</dd><dt id="bib-LOD">[LOD]</dt><dd>Linked Data, <a href="http://linkeddata.org/">http://linkeddata.org/</a>
+</dd><dt id="bib-OLAP">[OLAP]</dt><dd>Online Analytical Processing Data Cubes, <a href="http://en.wikipedia.org/wiki/OLAP_cube">http://en.wikipedia.org/wiki/OLAP_cube</a>
+</dd><dt id="bib-ORG">[ORG]</dt><dd>An Organization Ontology, <a href="http://www.epimorphics.com/public/vocabulary/org.html">http://www.epimorphics.com/public/vocabulary/org.html</a>
+</dd><dt id="bib-OS-GEO">[OS-GEO]</dt><dd>Ordnance Survey Administrative Geography Ontology, <a href="http://data.ordnancesurvey.co.uk/ontology/admingeo/">http://data.ordnancesurvey.co.uk/ontology/admingeo/</a>
+</dd><dt id="bib-SCOVO">[SCOVO]</dt><dd>The Statistical Core Vocabulary, <a href="http://sw.joanneum.at/scovo/schema.html">http://sw.joanneum.at/scovo/schema.html</a><br>SCOVO: Using Statistics on the Web of data, <a href="http://sw-app.org/pub/eswc09-inuse-scovo.pdf">http://sw-app.org/pub/eswc09-inuse-scovo.pdf</a>
+</dd><dt id="bib-SDMX20">[SDMX20]</dt><dd>SDMX Information Model: UML Conceptual Design (Version 2.0), November 2005, Statistical Data and Metadata Exchange Initiative. URL: <a href="http://sdmx.org/docs/2_0/SDMX_2_0%20SECTION_02_InformationModel.pdf">http://sdmx.org/docs/2_0/SDMX_2_0%20SECTION_02_InformationModel.pdf</a>
+</dd><dt id="bib-SKOS-PRIMER">[SKOS-PRIMER]</dt><dd>Antoine Isaac; Ed Summers. <a href="http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/"><cite>SKOS Simple Knowledge Organization System Primer.</cite></a> 18 August 2009. W3C Note. URL: <a href="http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/">http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/</a>
+</dd><dt id="bib-VOID">[VOID]</dt><dd>Keith Alexander; Richard Cyganiak; Michael Hausenblas; Jun Zhao. <a href="http://www.w3.org/TR/void/"><cite>Describing Linked Datasets with the VoID Vocabulary</cite></a> 03 March 2011. Interest Group Note. URL: <a href="http://www.w3.org/TR/void/">http://www.w3.org/TR/void/</a>
+</dd></dl></section></section></body></html>
--- a/data-cube/static.html Sun Mar 10 19:58:22 2013 +0100
+++ /dev/null Thu Jan 01 00:00:00 1970 +0000
@@ -1,2938 +0,0 @@
-<!DOCTYPE html>
-<html lang="en">
-<head>
- <title>The RDF Data Cube Vocabulary</title>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
-
-<!-- <script type="text/javascript" src="respec-ref.js" class="remove"></script> -->
-
-
-<!-- <script type="text/javascript" src="../respec/gld-config.js" class="remove"></script> -->
-
-
- <style type="text/css">
-.todo { background-color: #fdd; border: 1px solid #800; margin: 1em 0em; padding: 1em; page-break-inside: avoid ; font-style: italic; }
-.todo:before { content: 'TODO: '; }
-.spare-table { border-collapse: collapse; margin-left: 5ex; }
-.spare-table thead { border-bottom: black 1px solid; }
-.spare-table td { padding-left: 1em; padding-right: 1em; }
-.spare-table td + td { border-left: black 1px solid; padding-left: 1em; padding-right: 1em; }
-.spare-table th + th { border-left: black 1px solid; }
-dl.vocab_reference dt { margin-top: 1em; }
-.bordered-table { border: black 1px solid;}
-.bordered-table th { border-bottom: black 1px solid;}
-.bordered-table td { padding-right: 1em; background: #fcfaee }
-table#example-data { border: black 1px solid; border-collapse:collapse; border-spacing: 0; }
-table#example-data td { border: black 1px solid; padding: 3px; text-align: right; }
- </style>
-<style>/*****************************************************************
- * ReSpec 3 CSS
- * Robin Berjon - http://berjon.com/
- *****************************************************************/
-
-/* --- INLINES --- */
-em.rfc2119 {
- text-transform: lowercase;
- font-variant: small-caps;
- font-style: normal;
- color: #900;
-}
-
-h1 acronym, h2 acronym, h3 acronym, h4 acronym, h5 acronym, h6 acronym, a acronym,
-h1 abbr, h2 abbr, h3 abbr, h4 abbr, h5 abbr, h6 abbr, a abbr {
- border: none;
-}
-
-dfn {
- font-weight: bold;
-}
-
-a.internalDFN {
- color: inherit;
- border-bottom: 1px solid #99c;
- text-decoration: none;
-}
-
-a.externalDFN {
- color: inherit;
- border-bottom: 1px dotted #ccc;
- text-decoration: none;
-}
-
-a.bibref {
- text-decoration: none;
-}
-
-cite .bibref {
- font-style: normal;
-}
-
-code {
- color: #ff4500;
-}
-
-
-/* --- --- */
-ol.algorithm { counter-reset:numsection; list-style-type: none; }
-ol.algorithm li { margin: 0.5em 0; }
-ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; }
-
-/* --- TOC --- */
-.toc a, .tof a {
- text-decoration: none;
-}
-
-a .secno, a .figno {
- color: #000;
-}
-
-ul.tof, ol.tof {
- list-style: none outside none;
-}
-
-.caption {
- margin-top: 0.5em;
- font-style: italic;
-}
-
-/* --- TABLE --- */
-table.simple {
- border-spacing: 0;
- border-collapse: collapse;
- border-bottom: 3px solid #005a9c;
-}
-
-.simple th {
- background: #005a9c;
- color: #fff;
- padding: 3px 5px;
- text-align: left;
-}
-
-.simple th[scope="row"] {
- background: inherit;
- color: inherit;
- border-top: 1px solid #ddd;
-}
-
-.simple td {
- padding: 3px 10px;
- border-top: 1px solid #ddd;
-}
-
-.simple tr:nth-child(even) {
- background: #f0f6ff;
-}
-
-/* --- DL --- */
-.section dd > p:first-child {
- margin-top: 0;
-}
-
-.section dd > p:last-child {
- margin-bottom: 0;
-}
-
-.section dd {
- margin-bottom: 1em;
-}
-
-.section dl.attrs dd, .section dl.eldef dd {
- margin-bottom: 0;
-}
-</style><style>/* --- EXAMPLES --- */
-div.example-title {
- min-width: 7.5em;
- color: #b9ab2d;
-}
-div.example-title span {
- text-transform: uppercase;
-}
-aside.example, div.example, div.illegal-example {
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
-}
-div.illegal-example { color: red }
-div.illegal-example p { color: black }
-aside.example, div.example {
- padding: .5em;
- border-left-width: .5em;
- border-left-style: solid;
- border-color: #e0cb52;
- background: #fcfaee;
-}
-
-aside.example div.example {
- border-left-width: .1em;
- border-color: #999;
- background: #fff;
-}
-aside.example div.example div.example-title {
- color: #999;
-}
-</style><style>/* --- ISSUES/NOTES --- */
-div.issue-title, div.note-title {
- padding-right: 1em;
- min-width: 7.5em;
- color: #b9ab2d;
-}
-div.issue-title { color: #e05252; }
-div.note-title { color: #52e052; }
-div.issue-title span, div.note-title span {
- text-transform: uppercase;
-}
-div.note, div.issue {
- margin-top: 1em;
- margin-bottom: 1em;
-}
-.note > p:first-child, .issue > p:first-child { margin-top: 0 }
-.issue, .note {
- padding: .5em;
- border-left-width: .5em;
- border-left-style: solid;
-}
-div.issue, div.note {
- padding: 0.5em;
- margin: 1em 0;
- position: relative;
- clear: both;
-}
-span.note, span.issue { padding: .1em .5em .15em; }
-
-.issue {
- border-color: #e05252;
- background: #fbe9e9;
-}
-.note {
- border-color: #52e052;
- background: #e9fbe9;
-}
-
-
-</style><link rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WD"><!--[if lt IE 9]><script src='http://www.w3.org/2008/site/js/html5shiv.js'></script><![endif]--></head>
-
-<body><div class="head">
- <p>
-
- <a href="http://www.w3.org/"><img width="72" height="48" src="http://www.w3.org/Icons/w3c_home" alt="W3C"></a>
-
- </p>
- <h1 class="title" id="title">The RDF Data Cube Vocabulary</h1>
-
- <h2 id="w3c-working-draft-12-march-2013"><abbr title="World Wide Web Consortium">W3C</abbr> Working Draft 12 March 2013</h2>
- <dl>
-
- <dt>This version:</dt>
- <dd><a href="http://www.w3.org/TR/2013/WD-vocab-data-cube-20130312/">http://www.w3.org/TR/2013/WD-vocab-data-cube-20130312/</a></dd>
- <dt>Latest published version:</dt>
- <dd><a href="http://www.w3.org/TR/vocab-data-cube/">http://www.w3.org/TR/vocab-data-cube/</a></dd>
-
-
- <dt>Latest editor's draft:</dt>
- <dd><a href="https://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html">https://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html</a></dd>
-
-
-
-
-
- <dt>Previous version:</dt>
- <dd><a href="http://www.w3.org/TR/2012/WD-vocab-data-cube-20120405/">http://www.w3.org/TR/2012/WD-vocab-data-cube-20120405/</a></dd>
-
-
- <dt>Editors:</dt>
- <dd><a href="http://richard.cyganiak.de/">Richard Cyganiak</a>, <a href="http://www.deri.ie/">DERI, NUI Galway</a></dd>
-<dd><span>Dave Reynolds</span>, <a href="http://www.epimorphics.com/">Epimorphics Ltd</a></dd>
-
-
- <dt>Contributor:</dt> <dd><a href="http://www.jenitennison.com/">Jeni Tennison</a></dd></dl>
-
-
-
- <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
-
-
- <hr>
-</div>
-
-<section id="abstract" class="introductory"><h2>Abstract</h2>
-<p>There are many situations where it would be useful to be able to
-publish
-multi-dimensional data, such as statistics, on the web in such a way
-that it can be linked to related data sets and concepts. The Data Cube
-vocabulary provides a means to do this using the <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/TR/REC-rdf-syntax/">RDF</a>
-(Resource Description Framework) standard. The model underpinning the
-Data Cube vocabulary is
-compatible with the cube model that underlies <a href="http://sdmx.org">SDMX</a> (Statistical Data
-and Metadata eXchange), an ISO standard for exchanging and sharing
-statistical data and metadata among organizations. The Data Cube
-vocabulary is a core foundation which supports extension
-vocabularies to enable publication of other aspects of
-statistical data flows or other multi-dimensional data sets.</p>
-</section><section id="sotd" class="introductory"><h2>Status of This Document</h2>
-
-
-
- <p>
- <em>This section describes the status of this document at the time of its publication. Other
- documents may supersede this document. A list of current <abbr title="World Wide Web Consortium">W3C</abbr> publications and the latest revision
- of this technical report can be found in the <a href="http://www.w3.org/TR/"><abbr title="World Wide Web Consortium">W3C</abbr> technical reports
- index</a> at http://www.w3.org/TR/.</em>
- </p>
-
- <p>This publication transitions <a href="http://publishing-statistical-data.googlecode.com/svn/trunk/specs/src/main/html/cube.html">previous work</a> on this subject onto the <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation Track.</p>
-
- <p>
- This document was published by the <a href="http://www.w3.org/2011/gld/">Government Linked Data Working Group</a> as a Last Call Working Draft.
-
- This document is intended to become a <abbr title="World Wide Web Consortium">W3C</abbr> Recommendation.
-
-
- If you wish to make comments regarding this document, please send them to
- <a href="mailto:public-gld-comments@w3.org">public-gld-comments@w3.org</a>
- (<a href="mailto:public-gld-comments-request@w3.org?subject=subscribe">subscribe</a>,
- <a href="http://lists.w3.org/Archives/Public/public-gld-comments/">archives</a>).
-
- The Last Call period ends 08 April 2013.
-
-
- All comments are welcome.
-
-
- </p><p>
- Publication as a Last Call Working Draft does not imply endorsement by the <abbr title="World Wide Web Consortium">W3C</abbr> Membership.
- This is a draft document and may be updated, replaced or obsoleted by other documents at
- any time. It is inappropriate to cite this document as other than work in progress.
- </p>
-
-
- <p>
- This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the
- relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.
- </p>
-
- <p>
-
- This document was produced by a group operating under the
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-
-
-
-
- <abbr title="World Wide Web Consortium">W3C</abbr> maintains a <a href="http://www.w3.org/2004/01/pp-impl/47663/status" rel="disclosure">public list of any patent disclosures</a>
-
- made in connection with the deliverables of the group; that page also includes instructions for
- disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains
- <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the
- information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
- 6 of the <abbr title="World Wide Web Consortium">W3C</abbr> Patent Policy</a>.
-
-
- </p>
-
-
-
-
-</section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#outline" class="tocxref"><span class="secno">1. </span>Outline of the vocabulary</a><ul class="toc"><li class="tocline"><a href="#index" class="tocxref"><span class="secno">1.1 </span>Vocabulary index</a></li></ul></li><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">2. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#intro-rdf" class="tocxref"><span class="secno">2.1 </span>RDF and Linked Data</a></li><li class="tocline"><a href="#intro-sdmx" class="tocxref"><span class="secno">2.2 </span>SDMX and related standards</a></li><li class="tocline"><a href="#intro-audience" class="tocxref"><span class="secno">2.3 </span>Audience and scope</a></li></ul></li><li class="tocline"><a href="#namespaces" class="tocxref"><span class="secno">3. </span>Namespaces and Document Conventions</a></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">4. </span>Conformance</a></li><li class="tocline"><a href="#data-cubes" class="tocxref"><span class="secno">5. </span>Data cubes</a><ul class="toc"><li class="tocline"><a href="#cubes-model" class="tocxref"><span class="secno">5.1 </span>The cube model - dimensions, attributes, measures</a></li><li class="tocline"><a href="#cubes-slices" class="tocxref"><span class="secno">5.2 </span>Introducing Slices</a></li><li class="tocline"><a href="#example" class="tocxref"><span class="secno">5.3 </span>An example</a></li></ul></li><li class="tocline"><a href="#dsd" class="tocxref"><span class="secno">6. </span>Creating data structure definitions</a><ul class="toc"><li class="tocline"><a href="#dsd-dimensions" class="tocxref"><span class="secno">6.1 </span>Dimensions, attributes and measures</a></li><li class="tocline"><a href="#dsd-cog" class="tocxref"><span class="secno">6.2 </span>Content oriented guidelines</a></li><li class="tocline"><a href="#dsd-example" class="tocxref"><span class="secno">6.3 </span>Example</a></li><li class="tocline"><a href="#dsd-dsd" class="tocxref"><span class="secno">6.4 </span>ComponentSpecifications and DataStructureDefinitions</a></li><li class="tocline"><a href="#dsd-mm" class="tocxref"><span class="secno">6.5 </span>Handling multiple measures</a><ul class="toc"><li class="tocline"><a href="#dsd-mm-obs" class="tocxref"><span class="secno">6.5.1 </span>Multi-measure observations</a></li><li class="tocline"><a href="#dsd-mm-dim" class="tocxref"><span class="secno">6.5.2 </span><span>Measure dimension</span></a></li></ul></li></ul></li><li class="tocline"><a href="#datasets" class="tocxref"><span class="secno">7. </span>Expressing data sets</a><ul class="toc"><li class="tocline"><a href="#dataset-basic" class="tocxref"><span class="secno">7.1 </span>Data sets and observations</a></li><li class="tocline"><a href="#slices" class="tocxref"><span class="secno">7.2 </span>Slices and groups of observations</a></li></ul></li><li class="tocline"><a href="#schemes" class="tocxref"><span class="secno">8. </span>Concept schemes and code lists</a><ul class="toc"><li class="tocline"><a href="#schemes-intro" class="tocxref"><span class="secno">8.1 </span>Coded values for components properties</a></li><li class="tocline"><a href="#schemes-hierarchy" class="tocxref"><span class="secno">8.2 </span>Hierarchical code lists</a></li><li class="tocline"><a href="#schemes-hierarchy-nonskos" class="tocxref"><span class="secno">8.3 </span>Non-SKOS hierarchies</a></li><li class="tocline"><a href="#schemes-aggregation" class="tocxref"><span class="secno">8.4 </span>Aggregation</a></li></ul></li><li class="tocline"><a href="#metadata" class="tocxref"><span class="secno">9. </span>DataSet metadata</a><ul class="toc"><li class="tocline"><a href="#metadata-categorization" class="tocxref"><span class="secno">9.1 </span>Categorizing a data set</a></li><li class="tocline"><a href="#metadata-publishers" class="tocxref"><span class="secno">9.2 </span>Describing publishers</a></li></ul></li><li class="tocline"><a href="#normalize" class="tocxref"><span class="secno">10. </span>Abbreviated and normalized data cubes</a><ul class="toc"><li class="tocline"><a href="#normalize-algorithm" class="tocxref"><span class="secno">10.1 </span>Normalization algorithm</a></li></ul></li><li class="tocline"><a href="#wf" class="tocxref"><span class="secno">11. </span>Well-formed cubes</a><ul class="toc"><li class="tocline"><a href="#wf-rules" class="tocxref"><span class="secno">11.1 </span>Integrity constraints</a></li></ul></li><li class="tocline"><a href="#vocab-reference" class="tocxref"><span class="secno">12. </span>Vocabulary reference</a><ul class="toc"><li class="tocline"><a href="#reference-datasets" class="tocxref"><span class="secno">12.1 </span>DataSets</a></li><li class="tocline"><a href="#reference-observations" class="tocxref"><span class="secno">12.2 </span>Observations</a></li><li class="tocline"><a href="#reference-slices" class="tocxref"><span class="secno">12.3 </span>Slices</a></li><li class="tocline"><a href="#reference-components" class="tocxref"><span class="secno">12.4 </span>Dimensions, Attributes, Measures</a></li><li class="tocline"><a href="#reference-component-properties" class="tocxref"><span class="secno">12.5 </span>Reusable general purpose component properties</a></li><li class="tocline"><a href="#reference-dsd" class="tocxref"><span class="secno">12.6 </span>Data Structure Definitions</a></li><li class="tocline"><a href="#reference-compspec" class="tocxref"><span class="secno">12.7 </span>Component specifications - for qualifying component use in a DSD</a></li><li class="tocline"><a href="#reference-slice-definitions" class="tocxref"><span class="secno">12.8 </span>Slice definitions</a></li><li class="tocline"><a href="#reference-concepts" class="tocxref"><span class="secno">12.9 </span>Concepts</a></li><li class="tocline"><a href="#reference-nonskos-hierarchy" class="tocxref"><span class="secno">12.10 </span>Non-SKOS Hierarchies</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#change-history" class="tocxref"><span class="secno">B. </span>Change history </a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></section>
-
-
-
-
-<section id="outline">
-<!--OddPage--><h2><span class="secno">1. </span>Outline of the vocabulary</h2>
-
-<!-- <img src="images/qb-fig1.png" alt="UML-style block diagram of the terms in this vocabulary"/> -->
-
-<img src="images/qb-fig1-proposed.png" alt="UML-style block diagram of the terms in this vocabulary">
-
-<section id="index">
-<h3><span class="secno">1.1 </span>Vocabulary index</h3>
-
- <p><b>Classes:</b>
- <a href="#ref_qb_Attachable">qb:Attachable</a>
- <a href="#ref_qb_AttributeProperty">qb:AttributeProperty</a>
- <a href="#ref_qb_CodedProperty">qb:CodedProperty</a>
- <a href="#ref_qb_ComponentProperty">qb:ComponentProperty</a>
- <a href="#ref_qb_ComponentSet">qb:ComponentSet</a>
- <a href="#ref_qb_ComponentSpecification">qb:ComponentSpecification</a>
- <a href="#ref_qb_DataSet">qb:DataSet</a>
- <a href="#ref_qb_DataStructureDefinition">qb:DataStructureDefinition</a>
- <a href="#ref_qb_DimensionProperty">qb:DimensionProperty</a>
- <a href="#ref_qb_MeasureProperty">qb:MeasureProperty</a>
- <a href="#ref_qb_Observation">qb:Observation</a>
- <a href="#ref_qb_Slice">qb:Slice</a>
- <a href="#ref_qb_ObservationGroup">qb:ObservationGroup</a>
- <a href="#ref_qb_SliceKey">qb:SliceKey</a>
- <a href="#ref_qb_Hierarchy">qb:HierarchicalCodeList</a>
- <a href="#ref_qb_AggregatableHierarchy">qb:AggregatableHierarchy</a>
- </p>
- <p><b>Properties:</b>
- <a href="#ref_qb_attribute">qb:attribute</a>
- <a href="#ref_qb_codeList">qb:codeList</a>
- <a href="#ref_qb_component">qb:component</a>
- <a href="#ref_qb_componentAttachment">qb:componentAttachment</a>
- <a href="#ref_qb_componentProperty_LC">qb:componentProperty</a>
- <a href="#ref_qb_componentRequired">qb:componentRequired</a>
- <a href="#ref_qb_concept">qb:concept</a>
- <a href="#ref_qb_dataSet_LC">qb:dataSet</a>
- <a href="#ref_qb_dimension">qb:dimension</a>
- <a href="#ref_qb_measure">qb:measure</a>
- <a href="#ref_qb_measureDimension">qb:measureDimension</a>
- <a href="#ref_qb_measureType">qb:measureType</a>
- <a href="#ref_qb_observation_LC">qb:observation</a>
- <a href="#ref_qb_order">qb:order</a>
- <a href="#ref_qb_slice_LC">qb:slice</a>
- <a href="#ref_qb_sliceKey_LC">qb:sliceKey</a>
- <a href="#ref_qb_sliceStructure">qb:sliceStructure</a>
- <a href="#ref_qb_structure">qb:structure</a>
- <a href="#ref_qb_observationGroup">qb:observationGroup</a>
- <a href="#ref_qb_hierarchyRoot">qb:hierarchyRoot</a>
- <a href="#ref_qb_narrowingProperty">qb:parentChildProperty</a>
- </p>
-</section>
-
-</section>
-
-<section id="introduction" class="informative">
-<!--OddPage--><h2><span class="secno">2. </span>Introduction</h2><p><em>This section is non-normative.</em></p>
-
-<p>
-Statistical data is a foundation for policy
-prediction, planning and adjustments and
-underpins many of the mash-ups and visualisations
-we see on the web. There is strong interest
-in being able to publish statistical data in a web-friendly format
-to enable it to be linked and combined with related information.
-</p>
-
-<p>
-At the heart of a statistical dataset is a set of observed values
-organized along a group of dimensions, together with associated metadata.
-The Data Cube vocabulary enables such information to be represented
-using the <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/TR/REC-rdf-syntax/">RDF</a>
-(Resource Description Framework) standard and published following the
-principles of
-<a href="http://linkeddata.org/">linked data</a>.
-The vocabulary is based upon the approach used by the SDMX ISO standard
-for statistical data exchange. This <em>cube</em> model is very
-general and so the Data Cube vocabulary can be used for other data sets
-such as survey data, spreadsheets and OLAP data cubes [<cite><a class="bibref" href="#bib-OLAP">OLAP</a></cite>].
-</p>
-
-<p>
-The Data Cube vocabulary is focused purely on the
-publication of multi-dimensional data on the web. We envisage a series of modular
-vocabularies being developed which extend this core foundation. In
-particular, we see the need for an SDMX extension vocabulary to support the
-publication of additional context to statistical data (such as the encompassing Data
-Flows and associated Provision Agreements). Other extensions are possible to
-support metadata for surveys (so called "micro-data", as encompassed by <a href="http://www.ddialliance.org/">DDI</a>)
-or publication of statistical reference metadata.
-</p>
-
-<p>The Data Cube in turn builds upon the following existing RDF
-vocabularies:</p>
-<ul>
- <li><a href="http://www.w3.org/2004/02/skos/">SKOS</a> for concept schemes</li>
- <li><a href="http://sw.joanneum.at/scovo/schema.html">SCOVO</a> for
-core statistical structures</li>
- <li><a href="http://purl.org/dc/terms/">Dublin Core Terms</a> for metadata</li>
- <li><a href="http://rdfs.org/ns/void-guide">VoiD</a> for data access</li>
- <li><a href="http://xmlns.com/foaf/0.1/">FOAF</a> for agents</li>
- <li><a href="http://www.w3.org/ns/org#">ORG</a> for organizations</li>
-</ul>
-
-
-<section id="intro-rdf">
-<h3><span class="secno">2.1 </span>RDF and Linked Data</h3><p><em>This section is non-normative.</em></p>
-
-<p><em>Linked data</em> is an approach to publishing data on the web, enabling
-datasets to be linked together through references to common concepts.
- The approach [<cite><a class="bibref" href="#bib-LOD">LOD</a></cite>]
-recommends use of HTTP URIs to name the entities and concepts so that consumers of
-the data can look-up those URIs to get more information, including links
-to other related URIs.
-RDF [<cite><a class="bibref" href="#bib-RDF-PRIMER">RDF-PRIMER</a></cite>]
-provides a standard for the representation of the
-information that describes those entities and concepts, and is returned
-by dereferencing the URIs. </p>
-
-<p>There are a number of benefits to being able to publish multi-dimensional data, such as statistics,
-using RDF and the linked data approach:</p>
-<ul>
- <li>The individual observations, and groups of observations, become
-(web) addressable. This allows publishers and third parties to annotate
-and link to this data; for example a report can reference the specific
-figures it is based on allowing for fine grained provenance trace-back.</li>
- <li>Data can be flexibly combined across datasets and between
-statistical and non-statistical sets (for example <em>find all
-Religious schools in census areas with high values for National
-Indicators pertaining to religious tolerance</em>). The statistical
-data becomes an integral part of the broader web of linked data.</li>
- <li>For publishers who currently only offer static files then
-publishing as linked-data offers a flexible, non-proprietary, machine
-readable means of publication that supports an out-of-the-box web API
-for programmatic access.</li>
- <li>It enables reuse of standardized tools and components.</li>
-</ul>
-</section>
-
-
-<section id="intro-sdmx">
-<h3><span class="secno">2.2 </span>SDMX and related standards</h3>
-
-<p>The Statistical Data and Metadata Exchange (SDMX) Initiative
-was organised in 2001 by seven international organisations (BIS,
-ECB, Eurostat, IMF, OECD, World Bank and the UN) to
-realise greater efficiencies in statistical practice. These
-organisations all
-collect significant amounts of data, mostly from the national level,
-to support policy. They also disseminate data at the supra-national
-and international levels.</p>
-
-<p>
-There have been a number of important results from this work: two
-versions of a set of technical specifications - ISO:TS 17369
-(SDMX) - and the release of several recommendations for
-structuring and harmonising cross-domain statistics, the SDMX
-Content-Oriented Guidelines. All of the products are available at
-<a href="http://www.sdmx.org">www.sdmx.org</a>. The standards are now
-being widely adopted
-around the world for the collection, exchange, processing, and
-dissemination of aggregate statistics by official statistical
-organisations. The UN Statistical Commission recommended
-SDMX as the preferred standard for statistics in 2007.
-</p>
-
-<p>The SDMX specification defines a core <em>information model</em>
-which is reflected in concrete form in two syntaxes - SDMX-ML (an XML
-syntax) and SDMX-EDI.
-</p>
-
-<p>The RDF Data Cube vocabulary builds upon the core of the
- the SDMX 2.0 Information Model [<cite><a class="bibref" href="#bib-SDMX20">SDMX20</a></cite>].</p>
-
-<p>A key component of the SDMX standards package are
-the <strong>Content-Oriented Guidelines</strong> (COGs), a set of
-cross-domain concepts, code lists, and categories that support
-interoperability and comparability between datasets by providing a
-shared terminology between SDMX implementers [<cite><a class="bibref" href="#bib-COG">COG</a></cite>]. RDF versions of these
-terms are available separately for use along with the Data Cube
-vocabulary, see <a href="#dsd-cog">Content oriented guidelines</a>.
-</p>
-</section>
-
-
-<section id="intro-audience">
-<h3><span class="secno">2.3 </span>Audience and scope</h3>
-
-<p>This document describes the Data Cube vocabulary
-It is aimed at people wishing to publish
-statistical or other multi-dimension data in RDF.
-Mechanics of cross-format translation from other
-formats such as SDMX-ML are not covered here.</p>
-</section>
-
-</section>
-
-<section id="namespaces">
-<!--OddPage--><h2><span class="secno">3. </span>Namespaces and Document Conventions</h2>
-
-<p>
-The names of RDF entities -- classes, predicates, individuals -- are
-URIs. These are usually expressed using a compact notation where the
-name is written <code>prefix:localname</code>, and where the <code>prefix</code>
-identifies a <i>namespace URI</i>. The namespace identified by the prefix is
- prepended to the <code>localname</code> to obtain the full URI.
-</p>
-
-<p>The following namespaces are used in this document:</p>
-
-<table>
- <thead><tr><th>Prefix</th><th>Namespace</th><th>Reference</th></tr></thead>
- <tbody>
- <tr><td>qb</td><td><a href="http://purl.org/linked-data/cube#">http://purl.org/linked-data/cube#</a></td><td><em>This document</em></td></tr>
- <tr><td>skos</td><td><a href="http://www.w3.org/2004/02/skos/core">http://www.w3.org/2004/02/skos/core#</a></td><td>[<cite><a class="bibref" href="#bib-SKOS-REFERENCE">SKOS-REFERENCE</a></cite>]</td></tr>
- <tr><td>scovo</td><td><a href="http://purl.org/NET/scovo#">http://purl.org/NET/scovo#</a></td><td>[<cite><a class="bibref" href="#bib-SCOVO">SCOVO</a></cite>]</td></tr>
- <tr><td>void</td><td><a href="http://rdfs.org/ns/void#">http://rdfs.org/ns/void#</a></td><td>[<cite><a class="bibref" href="#bib-VOID">VOID</a></cite>]</td></tr>
- <tr><td>foaf</td><td><a href="http://xmlns.com/foaf/0.1/">http://xmlns.com/foaf/0.1/</a></td><td>[<cite><a class="bibref" href="#bib-FOAF">FOAF</a></cite>]</td></tr>
- <tr><td>org</td><td><a href="http://www.w3.org/ns/org#">http://www.w3.org/ns/org#</a></td><td>[<cite><a class="bibref" href="#bib-ORG">ORG</a></cite>]</td></tr>
- <tr><td>dct</td><td><a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></td><td>[<cite><a class="bibref" href="#bib-DC11">DC11</a></cite>]</td></tr>
- <tr><td>owl</td><td><a href="http://www.w3.org/2002/07/owl">http://www.w3.org/2002/07/owl#</a></td><td>[<cite><a class="bibref" href="#bib-OWL2-PRIMER">OWL2-PRIMER</a></cite>]</td></tr>
- <tr><td>rdf</td><td><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></td><td>[<cite><a class="bibref" href="#bib-RDF-CONCEPTS">RDF-CONCEPTS</a></cite>]</td></tr>
- <tr><td>rdfs</td><td><a href="http://www.w3.org/2000/01/rdf-schema">http://www.w3.org/2000/01/rdf-schema#</a></td><td>[<cite><a class="bibref" href="#bib-RDF-SCHEMA">RDF-SCHEMA</a></cite>]</td></tr>
- <tr><td>admingeo</td><td><a href="http://data.ordnancesurvey.co.uk/ontology/admingeo/">http://data.ordnancesurvey.co.uk/ontology/admingeo/</a></td><td><em>(Non-normative, used for examples only)</em></td></tr>
- <tr><td>eg</td><td><a href="http://example.org/ns#">http://example.org/ns#</a></td><td><em>(Non-normative, used for examples only)</em></td></tr>
- </tbody>
-</table>
-
-<p>All RDF examples are written in Turtle syntax [<cite><a class="bibref" href="#bib-TURTLE-TR">TURTLE-TR</a></cite>].</p>
-
-</section>
-
-
-<section id="conformance"><!--OddPage--><h2><span class="secno">4. </span>Conformance</h2>
-<p>
- As well as sections marked as non-normative, all authoring guidelines, diagrams, examples,
- and notes in this specification are non-normative. Everything else in this specification is
- normative.
-</p>
-<p>
- The key words <em class="rfc2119" title="must">must</em>, <em class="rfc2119" title="must not">must not</em>, <em class="rfc2119" title="required">required</em>, <em class="rfc2119" title="should">should</em>, <em class="rfc2119" title="should not">should not</em>, <em class="rfc2119" title="recommended">recommended</em>, <em class="rfc2119" title="may">may</em>,
- and <em class="rfc2119" title="optional">optional</em> in this specification are to be interpreted as described in [<cite><a class="bibref" href="#bib-RFC2119">RFC2119</a></cite>].
-</p>
-
-
-<p>A data interchange, however that interchange occurs, is conformant
- with Data Cube if:
-</p><ul>
-<li>it uses terms (classes and properties) from Data Cube in a way consistent with
- their semantics as declared in this specification, in particular the exchanged RDF graphs constitute
- either <em><a href="#dfn-well-formed" class="internalDFN">well-formed</a></em> or <em><a href="#dfn-well-formed-abbreviated" class="internalDFN">well-formed abbreviated</a></em> Data Cubes;</li>
-<li>it does <strong>not</strong> use terms from other vocabularies <strong>instead</strong> of ones defined
- in this vocabulary that could reasonably be used (use of such
- terms <strong>in addition</strong> to Data Cube terms is permissible).</li>
-</ul>
-<p></p>
-
-<p>A conforming data interchange:
-</p><ul>
-<li><em class="rfc2119" title="may">may</em> include terms from other vocabularies;</li>
-<li><em class="rfc2119" title="may">may</em> use only a subset of Data Cube terms.</li>
-</ul>
-<p></p>
-
-</section>
-
-<section id="data-cubes" class="informative">
-<!--OddPage--><h2><span class="secno">5. </span>Data cubes</h2><p><em>This section is non-normative.</em></p>
-
-
-<section id="cubes-model" class="informative">
-<h3><span class="secno">5.1 </span>The cube model - dimensions, attributes, measures</h3><p><em>This section is non-normative.</em></p>
-
-<p>A statistical data set comprises a collection of observations made
-at some points across some logical space. The collection can be characterized by
-a set of dimensions that define what the observation applies to (e.g. time,
-area, gender) along with metadata describing what has been
-measured (e.g. economic activity, population), how it was measured and how the
-observations are expressed (e.g. units, multipliers, status). We can
-think of the statistical data set as a multi-dimensional
-space, or hyper-cube, indexed by those dimensions. This space is
-commonly referred to
-as a <em>cube</em> for short; though the name shouldn't be taken
-literally, it is not meant to imply that
-there are exactly three dimensions (there can be more or fewer) nor
-that
-all the dimensions are somehow similar in size.</p>
-
-<p>A cube is organized according to a set of <em>dimensions</em>,
-<em>attributes</em> and <em>measures</em>. We collectively call these <em>components</em>.</p>
-
-<p>The <em>dimension</em> components serve to identify
-the observations. A set of values for all the dimension
-components
-is sufficient to identify a single observation. Examples of dimensions
-include the
-time to which the observation applies, or a geographic region which the observation covers.</p>
-
-<p>The <em>measure</em> components represent the phenomenon being
-observed.</p>
-
-<p>The <em>attribute</em> components allow us to qualify and
-interpret the observed value(s). They enable specification of the units of
-measure, any scaling factors and metadata such as the status
-of the observation (e.g. <em>estimated</em>, <em>provisional</em>).</p>
-</section>
-
-
-<section id="cubes-slices" class="informative">
-<h3><span class="secno">5.2 </span>Introducing Slices</h3><p><em>This section is non-normative.</em></p>
-
-<p>It is frequently useful to group subsets of observations within a
-dataset. In particular to fix all but one (or a small subset) of the
-dimensions and be able to refer to all observations with those
-dimension values as a single entity. We call such a selection a <em>slice</em>
-through the cube. For example, given a data set on regional performance
-indicators then we might group all the observations about a given indicator
-and a given region into a slice, each slice would then represent a time series of observed values.</p>
-
-<p>A data publisher may identify slices through the data for various
-purposes. They can be a useful grouping to which metadata might be attached, for example to note a
-change in measurement process which
-affects a particular time or region. Slices also enable the publisher to
-identify and label particular subsets of the data which should be presented to the
-user - they can enable the consuming application to more easily
- construct the appropriate graph or chart for presentation.</p>
-
-<p>In statistical applications it is common to work with
-slices in which a single dimension is left unspecified.
-In particular,
-to refer to such slices in which the single free dimension is time as <em>Time
-Series</em> and to refer slices along non-time dimensions as <em>Sections</em>.
-Within the Data Cube vocabulary we allow arbitrary dimensionality
-slices and do not give different names to particular types of
- slice. Such sub classes of slice could be added in extension vocabularies.</p>
-
-</section>
-
-<section id="example" class="informative">
-<h3><span class="secno">5.3 </span>An example</h3><p><em>This section is non-normative.</em></p>
-
-<p>In order to illustrate the use of the data cube vocabulary we will
-use a small demonstration
-data set extracted from
-<a href="http://statswales.wales.gov.uk/index.htm">StatsWales</a> report
-number 003311 which describes life expectancy broken down by region
-(unitary authority), age and time. The extract we will use is:<br>
-</p>
-
-<table id="example-data" style="text-align: left; width: 80%;">
- <tbody>
- <tr>
- <td style="vertical-align: top;"><br>
- </td>
- <td colspan="2" rowspan="1" style="vertical-align: top; text-align: center; font-weight: bold;">2004-2006<br>
- </td>
- <td colspan="2" rowspan="1" style="vertical-align: top; text-align: center; font-weight: bold;">2005-2007<br>
- </td>
- <td colspan="2" rowspan="1" style="vertical-align: top; text-align: center; font-weight: bold;">2006-2008<br>
- </td>
- </tr>
- <tr>
- <td style="vertical-align: top;"><br>
- </td>
- <td style="vertical-align: top; text-align: center; font-weight: bold;">Male<br>
- </td>
- <td style="vertical-align: top; text-align: center; font-weight: bold;">Female<br>
- </td>
- <td style="vertical-align: top; text-align: center; font-weight: bold;">Male<br>
- </td>
- <td style="vertical-align: top; text-align: center; font-weight: bold;">Female<br>
- </td>
- <td style="vertical-align: top; text-align: center; font-weight: bold;">Male<br>
- </td>
- <td style="vertical-align: top; text-align: center; font-weight: bold;">Female<br>
- </td>
- </tr>
- <tr>
- <td style="vertical-align: top; text-align: right; font-weight: bold;">Newport<br>
- </td>
- <td style="vertical-align: top;">76.7<br>
- </td>
- <td style="vertical-align: top;">80.7<br>
- </td>
- <td style="vertical-align: top;">77.1<br>
- </td>
- <td style="vertical-align: top;">80.9<br>
- </td>
- <td style="vertical-align: top;">77.0<br>
- </td>
- <td style="vertical-align: top;">81.5<br>
- </td>
- </tr>
- <tr>
- <td style="vertical-align: top; text-align: right; font-weight: bold;">Cardiff<br>
- </td>
- <td style="vertical-align: top;">78.7<br>
- </td>
- <td style="vertical-align: top;">83.3<br>
- </td>
- <td style="vertical-align: top;">78.6<br>
- </td>
- <td style="vertical-align: top;">83.7<br>
- </td>
- <td style="vertical-align: top;">78.7<br>
- </td>
- <td style="vertical-align: top;">83.4<br>
- </td>
- </tr>
- <tr>
- <td style="vertical-align: top; text-align: right; font-weight: bold;">Monmouthshire<br>
- </td>
- <td style="vertical-align: top;">76.6<br>
- </td>
- <td style="vertical-align: top;">81.3<br>
- </td>
- <td style="vertical-align: top;">76.5<br>
- </td>
- <td style="vertical-align: top;">81.5<br>
- </td>
- <td style="vertical-align: top;">76.6<br>
- </td>
- <td style="vertical-align: top;">81.7<br>
- </td>
- </tr>
- <tr>
- <td style="vertical-align: top; text-align: right; font-weight: bold;">Merthyr
-Tydfil<br>
- </td>
- <td style="vertical-align: top;">75.5<br>
- </td>
- <td style="vertical-align: top;">79.1<br>
- </td>
- <td style="vertical-align: top;">75.5<br>
- </td>
- <td style="vertical-align: top;">79.4<br>
- </td>
- <td style="vertical-align: top;">74.9<br>
- </td>
- <td style="vertical-align: top;">79.6<br>
- </td>
- </tr>
- </tbody>
-</table>
-
-<p>We can see that there are three dimensions - time period (rolling averages over three year timespans),
- region and sex. Each observation represents the life expectancy for that population (the measure) and
- we will need an attribute to define the units (years) of the measured values.</p>
-
-<p>An example of slicing the data would be to define slices in which the time and sex are
-fixed for each slice. Such slices then show the variation in life expectancy across the
- different regions, i.e. corresponding to the columns in the above tabular layout.</p>
-
-</section>
-
-</section>
-
-
-<section id="dsd">
-<!--OddPage--><h2><span class="secno">6. </span>Creating data structure definitions</h2>
-
-<p>A <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> defines the structure of one or more
-datasets. In particular, it defines the dimensions, attributes and measures
-used in the dataset along with qualifying information such as ordering of
- dimensions and whether attributes are required or optional. For well-formed
- data sets much of this information is implicit within the RDF component properties
- found on the observations. However, the explicit declaration of the structure has
- several benefits:</p>
-
-<ul>
- <li>it enables verification that the data set matches the expected structure,
- in particular helps with detection of incoherent sets obtained by
- combining differently structured source data;</li>
- <li>it allows a consumer to easily determine what dimensions are available for query
- and their presentational order, which in turn simplifies UI construction;</li>
- <li>it supports transmission of the structure information in associated SDMX data flows.</li>
-</ul>
-
-<p>It is common, when publishing statistical data, to have a regular series of publications which
-all follow the same structure. The notion of a Data Structure Definition (DSD) allows us to define
-that structure once and then reuse it for each publication in the series. Consumers can then be
- confident that the structure of the data has not changed.</p>
-
-<section id="dsd-dimensions">
-<h3><span class="secno">6.1 </span>Dimensions, attributes and measures</h3>
-
-<p>The Data Cube vocabulary represents the dimensions, attributes and measures
- as RDF properties. Each is an instance of the abstract <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
- class, which in turn has sub-classes <code><a href="#dfn-qb-dimensionproperty" class="internalDFN">qb:DimensionProperty</a></code>,
- <code><a href="#dfn-qb-attributeproperty" class="internalDFN">qb:AttributeProperty</a></code> and <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code>.</p>
-
-<p>A component property encapsulates several pieces of information:</p>
-<ul>
- <li>the concept being represented (e.g. time or geographic area),</li>
- <li>the nature of the component (dimension, attribute or measure) as represented by the type of the component property,</li>
- <li>the type or code list used to represent the value.</li>
-</ul>
-
-<p>The same <em>concept</em> can be manifested in different components. For example, the concept
- of <em>currency</em> may be used as a dimension (in a data set dealing with exchange rates) or as
- an attribute (when describing the currency in which an observed trade took place). The concept of time
- is typically used only as a dimension but may be encoded as a data value (e.g. an <code>xsd:dateTime</code>)
- or as a symbolic value (e.g. a URI drawn from the reference time URI set developed by data.gov.uk).
- In statistical agencies it is common to have a standard thesaurus of statistical concepts which
- underpin the components used in multiple different data sets.</p>
-
-<p>To support this reuse of general statistical concepts the data cube vocabulary provides the <code><a href="#dfn-qb-concept" class="internalDFN">qb:concept</a></code> property which
- links a <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code> to the concept it represents. We use the SKOS
- vocabulary [<cite><a class="bibref" href="#bib-SKOS-PRIMER">SKOS-PRIMER</a></cite>] to represent such concepts. This is very natural for those cases where the
- concepts are already maintained as a controlled term list or thesaurus.
- When developing a data structure definition for an informal data set there may not be an appropriate
- concept already. In those cases, if the concept is likely to be reused in other guises it is recommended to
- publish a <code>skos:Concept</code> along with the specific <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>. However, if
- such reuse is not expected then it is not required to do so - the <code><a href="#dfn-qb-concept" class="internalDFN">qb:concept</a></code>
- link is optional and a simple instance of the appropriate subclass of <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code> is
- sufficient.</p>
-
-<p>The representation of the possible values of the component is described using the <code>rdfs:range</code>
- property of the component in the usual RDF manner. Thus, for example, values of a time dimension might
- be represented using literals of type <code>xsd:dateTime</code> or as URIs drawn from a time reference service.</p>
-
-<p>In statistical data sets it is common
- for values to be encoded using some (possibly hierarchical) code list and it can be useful to be
- able to easily identify the overall code list in some more structured form. To cater for this a
- component can also be optionally annotated with a <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code> to indicate a set of
- <code>skos:Concept</code>s which may be used as codes. The <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code> value may be a
- <code>skos:ConceptScheme</code>, <code>skos:Collection</code> or <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>.
- In such a case the <code>rdfs:range</code> of the component might be left as simply <code>skos:Concept</code> but
- a useful design pattern is to also define an <code>rdfs:Class</code>
- whose members are all the <code>skos:Concept</code>s within a particular scheme. In that way
- the <code>rdfs:range</code> can be made more specific which enables generic RDF tools to perform
- appropriate range checking.</p>
-
-<p>Note that in any SDMX extension vocabulary there would be one further item of information to encode
- about components - the role that they play within the structure definition. In particular, it is sometimes
- convenient for consumers to be able to easily identify which is the time dimension,
- which component is the primary measure and so forth. It turns out that such roles are intrinsic to
- the concepts and so this information can encoded by providing subclasses of <code>skos:Concept</code>
- for each role. The particular choice of roles here is specific to the SDMX standard and so is not
- included within the core Data Cube vocabulary.</p>
-
-<p>Before illustrating the components needed for our running example, there is one more piece
- of machinery to introduce, a reusable set of concepts and components based on SDMX.
-</p>
-</section>
-
-<section id="dsd-cog" class="informative">
-<h3><span class="secno">6.2 </span>Content oriented guidelines</h3><p><em>This section is non-normative.</em></p>
-
-<p>The SDMX standard includes a set of <em>content oriented guidelines</em> (COG) [<cite><a class="bibref" href="#bib-COG">COG</a></cite>]
- which define a set of common statistical concepts and associated code lists that are intended to be
- reusable across data sets. A <a href="https://code.google.com/p/publishing-statistical-data/">community group</a>
- has developed RDF encodings of these guidelines. These comprise:
-
-</p><table id="namespaces-table">
- <thead><tr><th>Prefix</th><th>Namespace</th><th>Description</th></tr></thead>
- <tbody>
- <tr><td><code>sdmx-concept</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/concept#">http://purl.org/linked-data/sdmx/2009/concept#</a></td><td>SKOS Concepts for each COG defined concept</td>
- </tr><tr><td><code>sdmx-code</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/code#">http://purl.org/linked-data/sdmx/2009/code#</a></td><td>SKOS Concepts and ConceptSchemes for each COG defined code list</td>
- </tr><tr><td><code>sdmx-dimension</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/dimension#">http://purl.org/linked-data/sdmx/2009/dimension#</a></td><td>component properties corresponding to each COG concept that can be used as a dimension</td>
- </tr><tr><td><code>sdmx-attribute</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/attribute#">http://purl.org/linked-data/sdmx/2009/attribute#</a></td><td>component properties corresponding to each COG concept that can be used as an attribute</td>
- </tr><tr><td><code>sdmx-measure</code></td><td><a href="http://purl.org/linked-data/sdmx/2009/measure#">http://purl.org/linked-data/sdmx/2009/measure#</a></td><td>component properties corresponding to each COG concept that can be used as a measure</td>
-
- </tr></tbody>
-</table>
-
-<p>These resources are provided as a convenience and do not form part
- of the Data Cube standard at this time. However, they are used
- by a number of existing Data Cube publications and so we will
- reference them within our worked examples.</p>
-
-</section>
-
-
-<section id="dsd-example" class="informative">
-<h3><span class="secno">6.3 </span>Example</h3><p><em>This section is non-normative.</em></p>
-
-<p>Turning to our example data set then we can see there are three dimensions to represent
- - time period, region (unitary authority) and sex of the population. There is a single
- (primary) measure which corresponds to the topic of the data set (life expectancy) and
- encodes a value in years. Hence, we need the following components.</p>
-
-<p><b>Time.</b> There is a suitable predefined concept in the SMDX-COG for this, REF_PERIOD, so
- we could reuse the corresponding component property <code>sdmx-dimension:refPeriod</code>. However,
- to represent the time period itself it would be convenient to use the data.gov.uk reference
- time service and to declare this within the data structure definition.</p>
-
-<div class="example"><div class="example-title"><span>Example 1</span></div><pre class="example">eg:refPeriod a rdf:Property, qb:DimensionProperty;
- rdfs:label "reference period"@en;
- rdfs:subPropertyOf sdmx-dimension:refPeriod;
- rdfs:range interval:Interval;
- qb:concept sdmx-concept:refPeriod . </pre></div>
-
-<p><b>Region.</b> Again there is a suitable COG concept and associated component that
-we can use for this, and again we can customize the range of the component. In this case
- we can use the Ordnance Survey Administrative Geography Ontology [<cite><a class="bibref" href="#bib-OS-GEO">OS-GEO</a></cite>].</p>
-
-<div class="example"><div class="example-title"><span>Example 2</span></div><pre class="example">eg:refArea a rdf:Property, qb:DimensionProperty;
- rdfs:label "reference area"@en;
- rdfs:subPropertyOf sdmx-dimension:refArea;
- rdfs:range admingeo:UnitaryAuthority;
- qb:concept sdmx-concept:refArea . </pre></div>
-
-<p><b>Sex.</b> In this case we can use the corresponding COG component <code>sdmx-dimension:sex</code>
- directly, since the default code list for it includes the terms we need.</p>
-
-<p><b>Measure.</b> This property will give the value of each observation.
- We could use the default <code>smdx-measure:obsValue</code> for this (defining
- the topic being observed using metadata). However, it can aid readability and processing
- of the RDF data sets to use a specific measure corresponding to the phenomenon being observed.</p>
-
-<div class="example"><div class="example-title"><span>Example 3</span></div><pre class="example">eg:lifeExpectancy a rdf:Property, qb:MeasureProperty;
- rdfs:label "life expectancy"@en;
- rdfs:subPropertyOf sdmx-measure:obsValue;
- rdfs:range xsd:decimal . </pre></div>
-
-<p><b>Unit measure attribute.</b> The primary measure on its own is a plain decimal value.
- To correctly interpret this value we need to define what units it is measured in (years in this case).
- This is defined using attributes which qualify the interpretation of the observed value.
- Specifically in this example we can use the predefined <code>sdmx-attribute:unitMeasure</code>
- which in turn corresponds to the COG concept of <code>UNIT_MEASURE</code>. To express
- the value of this attribute we would typically us a common thesaurus of units of measure.
- For the sake of this simple example we will use the DBpedia resource <code>http://dbpedia.org/resource/Year</code>
- which corresponds to the topic of the Wikipedia page on "Years".</p>
-
-<p>This covers the minimal components needed to define the structure of this data set.</p>
-</section>
-
-
-<section id="dsd-dsd">
-<h3><span class="secno">6.4 </span>ComponentSpecifications and DataStructureDefinitions</h3>
-
-<p>To combine the components into a specification for the structure of this
- dataset we need to declare a <code><a>qb:DataStuctureDefinition</a></code>
- resource which in turn will reference a set of <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code> resources.
- The <code><a>qb:DataStuctureDefinition</a></code> will be reusable across other data sets with the same structure.</p>
-
-<p>In the simplest case the <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code> simply references the
- corresponding <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code> (usually using one of the sub properties
- <code><a href="#dfn-qb-dimension" class="internalDFN">qb:dimension</a></code>, <code><a href="#dfn-qb-measure" class="internalDFN">qb:measure</a></code> or <code><a href="#dfn-qb-attribute" class="internalDFN">qb:attribute</a></code>).
- However, it is also possible to qualify the
- component specification in several ways.</p>
-
-<ul>
- <li>Attributes may be declared as optional or required. If an
- attribute is required to be present for every observation then the specification should set
- <code><a>qb:componentRequired></a></code>. In the
- absence of such a declaration an attribute is assumed to be
- optional. The <code><a href="#dfn-qb-componentrequired" class="internalDFN">qb:componentRequired</a></code>
- declaration may only be applied to component specifications of
- attributes - measures and dimensions are always required.</li>
- <li>The components may be ordered by giving an integer value for <code><a href="#dfn-qb-order" class="internalDFN">qb:order</a></code>.
- This order carries no semantics but can be useful to aid consuming agents in generating
- appropriate user interfaces. It can also be useful in the publication chain to enable
- synthesis of appropriate URIs for observations.</li>
- <li>By default the values of all of the components will be attached to each individual observation,
- well call this the <em><a href="#dfn-normalized" class="internalDFN">normalized</a></em> representation.
- This allows such observations to stand alone, so that a SPARQL query to retrieve the observation
- can immediately locate the attributes which enable the observation to be interpreted. However,
- it is also permissible to attach attributes to the
- overall data set, to an intervening slice or to a specific Measure (in the case of multiple measures).
- This reduces some of the redundancy in the encoding of the instance data. To declare such an
- abbreviated structure, the <code><a href="#dfn-qb-componentattachment" class="internalDFN">qb:componentAttachment</a></code> property of the specification should
- reference the class corresponding to the attachment level (e.g. <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> for attributes
- that will be attached to the overall data set).</li>
-</ul>
-
-<p>In the case of our running example the dimensions can be usefully ordered. There is only one
- attribute, the unit measure, and this is required. In the interest of illustrating the vocabulary
- use we will declare that this attribute will be attached at the level of the data set, however
- normalized representations are in general easier to query and combine.</p>
-
-<p>So the structure of our example data set (and other similar datasets) can be declared by:</p>
-
-<div class="example"><div class="example-title"><span>Example 4</span></div><pre id="attachment-example" class="example">eg:dsd-le a qb:DataStructureDefinition;
- # The dimensions
- qb:component [qb:dimension eg:refArea; qb:order 1];
- qb:component [qb:dimension eg:refPeriod; qb:order 2];
- qb:component [qb:dimension sdmx-dimension:sex; qb:order 3];
- # The measure(s)
- qb:component [qb:measure eg:lifeExpectancy];
- # The attributes
- qb:component [qb:attribute sdmx-attribute:unitMeasure;
- qb:componentRequired "true"^^xsd:boolean;
- qb:componentAttachment qb:DataSet;] .</pre></div>
-
-<p>Note that we have given the data structure definition (DSD) a URI since it will be
- reused across different datasets with the same structure. Similarly the component properties
- themselves can be reused across different DSDs. However, the component specifications
- are only useful within the scope of a particular DSD and so we have chosen to represent
- them using blank nodes.
-</p>
-</section>
-
-
-<section id="dsd-mm">
-<h3><span class="secno">6.5 </span>Handling multiple measures</h3>
-
-<p>Our example data set is relatively simple in having a single observable (in this case "life expectancy")
- that is being measured. In other data sets there can be multiple measures. These measures
- may be of similar nature (e.g. a data set on local government performance might provide
- multiple different performance indicators for each region) or quite different (e.g. a data set
- on trades might provide quantity, value, weight for each trade).</p>
-
-<p>There are two approaches to representing multiple measures. In the SDMX information model, each
- observation can record a single observed value. In a data set with multiple observations then we
- add an additional dimension whose value indicates the measure. This is appropriate for applications
- where the measures are separate aggregate statistics. In other domains such as a clinical statistics
- or sensor networks then the term <em>observation</em> usually denotes an observation event which can include multiple
- observed values. Similarly in Business Intelligence applications and OLAP, a single "cell" in the data cube will
- typically contain values for multiple measures.
-</p>
-
-<p>The data cube vocabulary permits either representation approach to be used though they cannot be mixed
- within the same data set. </p>
-
-<p>Both representation approaches require
- that, for every point in the space of dimensions for which there is
- an observation, then a value must be given for every measure. In the
- case of multi-measure observations then each measure must be
- present on each observation. In cubes which use a measure dimension
- then there are sets of observations for each populated point in the
- cube and within each of those sets there must be an observation giving each measure.</p>
-
-
-<section id="dsd-mm-obs">
-<h4><span class="secno">6.5.1 </span>Multi-measure observations</h4>
-
-<p> This approach allows multiple observed values to be attached
- to an individual observation. It is suited to representation of things like sensor data and OLAP cubes.
- To use this representation you simply declare multiple <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code> components
- in the data structure definition and attach an instance of each property to the observations within
- the data set.</p>
-
-<p>For example, if we have a set of shipment data containing unit count and total weight for each
- shipment then we might have a data structure definition such as:</p>
-<div class="example"><div class="example-title"><span>Example 5</span></div><pre class="example">eg:dsd1 a qb:DataStructureDefinition;
- rdfs:comment "shipments by time (multiple measures approach)"@en;
- qb:component
- [ qb:dimension sdmx-dimension:refTime; ],
- [ qb:measure eg-measure:quantity; ],
- [ qb:measure eg-measure:weight; ] . </pre></div>
-
-<p>This would correspond to individual observations such as:</p>
-<div class="example"><div class="example-title"><span>Example 6</span></div><pre class="example">eg:dataset1 a qb:DataSet;
- qb:structure eg:dsd1 .
-
-eg:obs1a a qb:Observation;
- qb:dataSet eg:dataset1;
- sdmx-dimension:refTime "30-07-2010"^^xsd:date;
- eg-measure:weight 1.3 ;
- eg-measure:quantity 42 ;
- . </pre></div>
-
-<p>Note that one limitation of the multi-measure approach is that it is not possible to attach
- an attribute to a single observed value. An attribute attached to the observation instance
- will apply to the whole observation (e.g. to indicate who made the observation). Attributes
- can also be attached directly to the <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code> itself (e.g. to indicate
- the <em>unit of measure</em> for that measure) but that attachment applies to the whole data
- set (indeed any data set using that measure property) and cannot vary for different observations.
- For applications where this limitation is a problem then use the <em>measure dimension</em> approach.</p>
-</section>
-
-
-<section id="dsd-mm-dim">
-<h4><span class="secno">6.5.2 </span><dfn id="dfn-measure-dimension">Measure dimension</dfn></h4>
-
-<p>This approach restricts observations to having a single measured value but allows
- a data set to carry multiple measures by adding an extra dimension, a <em>measure dimension</em>.
- The value of the measure dimension denotes which particular measure is being conveyed by the
- observation. This is the representation approach used within SDMX and the SMDX-in-RDF
- extension vocabulary introduces a subclass of <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> which is restricted
- to using the <em>measure dimension</em> representation.</p>
-
-<p>To use this representation you declare an additional dimension within the data structure
- definition to play the role of the measure dimension. For use within the Data Cube vocabulary
- we provide a single distinguished component for this purpose -- <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code>.
- An extension vocabulary could generalize this through the provision of roles to
- identify concepts which
- act as measure types, enabling other measure dimensions to be declared.
-</p>
-
- <p>
- In the special case of using <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code> as the measure dimension, the set of allowed
- measures is assumed to be those measures declared within the DSD. There is no need to
- define a separate code list or enumerated class to duplicate this information.
- Thus, <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code> is a “magic” dimension property with an implicit code list.</p>
-
-<p>The data structure definition for our above example, using this representation approach, would then be:</p>
-<div class="example"><div class="example-title"><span>Example 7</span></div><pre class="example">eg:dsd2 a qb:DataStructureDefinition;
- rdfs:comment "shipments by time (measure dimension approach)"@en;
- qb:component
- [ qb:dimension sdmx-dimension:refTime; ],
- [ qb:measure eg-measure:quantity; ],
- [ qb:measure eg-measure:weight; ],
- [ qb:dimension qb:measureType; ] . </pre></div>
-
-<p>This would correspond to individual observations such as:</p>
-<div class="example"><div class="example-title"><span>Example 8</span></div><pre class="example">eg:dataset2 a qb:DataSet;
- qb:structure eg:dsd2 .
-
-eg:obs2a a qb:Observation;
- qb:dataSet eg:dataset2;
- sdmx-dimension:refTime "30-07-2010"^^xsd:date;
- qb:measureType eg-measure:weight ;
- eg-measure:weight 1.3 .
-
-eg:obs2b a qb:Observation;
- qb:dataSet eg:dataset2;
- sdmx-dimension:refTime "30-07-2010"^^xsd:date;
- qb:measureType eg-measure:quantity ;
- eg-measure:quantity 42 . </pre></div>
-
-
-<p>Note the duplication of having the measure property show up both as the property that
- carries the measured value, and as the value of the measure dimension. We accept
- this duplication as necessary to ensure the uniform cube/dimension mechanism and
- a uniform way of declaring and using measure properties on all kinds of datasets.</p><p>
-
-</p><p>Those familiar with SDMX should also note that in the RDF representation there is
- no need for a separate "primary measure" which subsumes each of the individual
- measures, those individual measures are used directly. Extension vocabularies
- could address the round-tripping of the SDMX primary measure by use of a
- separate annotation on the data structure definition.
-</p></section>
-
-</section>
-
-</section>
-
-
-<section id="datasets">
-<!--OddPage--><h2><span class="secno">7. </span>Expressing data sets</h2>
-
-<p>A DataSet is a collection of statistical data that corresponds to a given data structure definition.
-The data in a data set can be roughly described as belonging to one of the following kinds:</p>
-
-<dl>
- <dt>Observations</dt>
- <dd>This is the actual data, the measured numbers. In a statistical table, the observations
- would be the numbers in the table cells.</dd>
-
- <dt>Organizational structure</dt>
- <dd>To locate an observation within the hypercube, one has at least to know the value of each
- dimension at which the observation is located, so these values must be specified for each observation.
- Datasets can have additional organizational structure in the form of <em>slices</em>
- as described earlier in <a href="#slices">section 7.2</a>.
-
- </dd><dt>Internal metadata</dt>
- <dd>Having located an observation, we need certain metadata in order to be able to interpret it.
- What is the unit of measurement? Is it a normal value or a series break?
- Is the value measured or estimated? These metadata are provided as <em>attributes</em> and can
- be attached to individual observations, or to higher levels as defined by the ComponentSpecification
- described earlier.</dd>
-
- <dt>External metadata</dt>
- <dd>This is metadata that describes the dataset as a whole, such as categorization of the
- dataset, its publisher, and a SPARQL endpoint where it can be accessed.
- External metadata is described in <a href="#metadata">section 9</a>.</dd>
-</dl>
-
-
-<section id="dataset-basic">
-<h3><span class="secno">7.1 </span>Data sets and observations</h3>
-
-<p>A resource representing the entire data set is created and typed as <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> and
- linked to the corresponding data structure definition via the <code><a href="#dfn-qb-structure" class="internalDFN">qb:structure</a></code> property.</p>
-
-<p><strong>Pitfall</strong>: Note the capitalization of <code>qb:<strong>D</strong>ata<strong>S</strong>et</code>,
-which differs from the capitalization in other vocabularies, such as
-<a href="http://semanticweb.org/wiki/VoiD">void:Dataset</a> and <a href="http://www.w3.org/egov/wiki/Data_Catalog_Vocabulary">dcat:Dataset</a>. This unusual capitalization is chosen for compatibility
-with the SDMX standard. The same applies to the related property <code>qb:data<strong>S</strong>et</code>.</p>
-
-<p>Each observation is represented as an instance of type <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>.
- In the basic case then values for each of the attributes, dimensions and measurements are attached directly to the observation (remember
- that these components are all RDF properties). The observation is linked to the containing
- data set using the <code><a href="#dfn-qb-dataset-1" class="internalDFN">qb:dataSet</a></code> property. </p>
-
-<p>Thus for our running example we might expect to have:</p>
-
-<div class="example"><div class="example-title"><span>Example 9</span></div><pre class="example">eg:dataset-le1 a qb:DataSet;
- rdfs:label "Life expectancy"@en;
- rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
- qb:structure eg:dsd-le ;
- .
-
-eg:o1 a qb:Observation;
- qb:dataSet eg:dataset-le1 ;
- eg:refArea ex-geo:newport_00pr ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
- eg:lifeExpectancy 76.7 ;
- .
-
-eg:o2 a qb:Observation;
- qb:dataSet eg:dataset-le1 ;
- eg:refArea ex-geo:cardiff_00pt ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
- eg:lifeExpectancy 78.7 ;
- .
-
-eg:o3 a qb:Observation;
- qb:dataSet eg:dataset-le1 ;
- eg:refArea ex-geo:monmouthshire_00pp ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
- eg:lifeExpectancy 76.6 ;
- .
-
-...</pre></div>
-
-<p>This <a href="#dfn-normalized" class="internalDFN">normalized</a> structure makes it easy to query and combine data sets
- but there is some redundancy here. For example, the unit of measure for the
- life expectancy is uniform across the whole data set and does not change between
- observations. To cater for situations like this the Data Cube vocabulary allows components
- to be attached at a high level in the nested structure. Indeed if we re-examine our
- original Data Structure Declaration we see that we declared the unit of measure to be
- attached at the data set level. So an improved version of the example is:</p>
-
-<div class="example"><div class="example-title"><span>Example 10</span></div><pre class="example">eg:dataset-le1 a qb:DataSet;
- rdfs:label "Life expectancy"@en;
- rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
- qb:structure eg:dsd-le ;
- sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
- .
-
-eg:o1 a qb:Observation;
- qb:dataSet eg:dataset-le1 ;
- eg:refArea ex-geo:newport_00pr ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- eg:lifeExpectancy 76.7 ;
- .
-
-eg:o2 a qb:Observation;
- qb:dataSet eg:dataset-le1 ;
- eg:refArea ex-geo:cardiff_00pt ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- eg:lifeExpectancy 78.7 ;
- .
-
-eg:o3 a qb:Observation;
- qb:dataSet eg:dataset-le1 ;
- eg:refArea ex-geo:monmouthshire_00pp ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- eg:lifeExpectancy 76.6 ;
- .
-
-...</pre></div>
-
-<p>In a data set containing just observations with no intervening structure then each observation
- must have a complete set of dimension values, along with all the measure values. If the
- set is structured by using slices then further abbreviation is possible, as discussed
- in the next section.</p>
-</section>
-
-
-<section id="slices">
-<h3><span class="secno">7.2 </span>Slices and groups of observations</h3>
-
-<p>Slices allow us to group subsets of observations together. This not intended
- to represent arbitrary selections from the observations but uniform slices
- through the cube in which one or more of the dimension values are fixed.</p>
-
-<p>Slices may be used for a number of reasons:</p>
-<ul>
- <li>to guide consuming applications in how to present the data (e.g. to organize
- data as a set of time series);</li>
- <li>to provide an identity (URI) for the slice to enable it to be annotated or externally referenced;</li>
- <li>to reduce the verbosity of the data set by only stating each fixed dimensional value once.</li>
-</ul>
-
-<p>To illustrate the use of slices let us group the sample data set into geographic series.
- That will enable us to refer to e.g. "male life expectancy observations for 2004-2006"
- and guide applications to present a comparative chart across regions. </p>
-
-<p>We first define the structure of the slices we want by associating a "slice key" which the
- data structure definition. This is done by creating a <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code> which
- lists the component properties (which must be dimensions) which will be fixed in the
- slice. The key is attached to the DSD using <code><a href="#dfn-qb-slicekey-1" class="internalDFN">qb:sliceKey</a></code>. For example: </p>
-
-<div class="example"><div class="example-title"><span>Example 11</span></div><pre class="example">eg:sliceByRegion a qb:SliceKey;
- rdfs:label "slice by region"@en;
- rdfs:comment "Slice by grouping regions together, fixing sex and time values"@en;
- qb:componentProperty eg:refPeriod, sdmx-dimension:sex .
-
-eg:dsd-le-slice1 a qb:DataStructureDefinition;
- qb:component
- [qb:dimension eg:refArea; qb:order 1];
- [qb:dimension eg:refPeriod; qb:order 2];
- [qb:dimension sdmx-dimension:sex; qb:order 3];
- [qb:measure eg:lifeExpectancy];
- [qb:attribute sdmx-attribute:unitMeasure; qb:componentAttachment qb:DataSet;] ;
- qb:sliceKey eg:sliceByRegion .</pre></div>
-
-<p>In the instance data then slices are represented by instances of <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code> which
- link to the observations in the slice via <code><a href="#dfn-qb-observation-1" class="internalDFN">qb:observation</a></code> and to the key by means
- of <code><a href="#dfn-qb-slicestructure" class="internalDFN">qb:sliceStructure</a></code>. Data sets indicate
- the slices they contain by means of <code><a href="#dfn-qb-slice-1" class="internalDFN">qb:slice</a></code>. Thus in our example we would have:</p>
-
-<div class="example"><div class="example-title"><span>Example 12</span></div><pre class="example">eg:dataset-le2 a qb:DataSet;
- rdfs:label "Life expectancy"@en;
- rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
- qb:structure eg:dsd-le-slice2 ;
- sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
- qb:slice eg:slice2;
- .
-
-eg:slice2 a qb:Slice;
- qb:sliceStructure eg:sliceByRegion ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- qb:observation eg:o1b, eg:o2b; eg:o3b, ... .
-
-eg:o1b a qb:Observation;
- qb:dataSet eg:dataset-le2 ;
- eg:refArea ex-geo:newport_00pr ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- eg:lifeExpectancy 76.7 ;
- .
-
-eg:o2b a qb:Observation;
- qb:dataSet eg:dataset-le2 ;
- eg:refArea ex-geo:cardiff_00pt ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- eg:lifeExpectancy 78.7 ;
- .
-
-eg:o3b a qb:Observation;
- qb:dataSet eg:dataset-le2 ;
- eg:refArea ex-geo:monmouthshire_00pp ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- eg:lifeExpectancy 76.6 ;
- .
-
-...</pre></div>
-
-<p>Note that here we are still repeating the dimension values on the individual observations.
-This normalized representation means that a consuming application can still query
-for observed values uniformly without having to first parse the data structure
-definition and search for slice definitions. If it is desired, this redundancy can be reduced
-by declaring different attachment levels for the dimensions. For example:
-</p>
-<div class="example"><div class="example-title"><span>Example 13</span></div><pre class="example">eg:dsd-le-slice3 a qb:DataStructureDefinition;
- qb:component
- [qb:dimension eg:refArea; qb:order 1];
- [qb:dimension eg:refPeriod; qb:order 2; qb:componentAttachment qb:Slice];
- [qb:dimension sdmx-dimension:sex; qb:order 3; qb:componentAttachment qb:Slice];
- [qb:measure eg:lifeExpectancy];
- [qb:attribute sdmx-attribute:unitMeasure; qb:componentAttachment qb:DataSet;] ;
- qb:sliceKey eg:sliceByRegion .
-
-eg:dataset-le3 a qb:DataSet;
- rdfs:label "Life expectancy"@en;
- rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
- qb:structure eg:dsd-le-slice3 ;
- sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
- qb:slice eg:slice3 ;
- .
-
-eg:slice3 a qb:Slice;
- qb:sliceStructure eg:sliceByRegion ;
- eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
- sdmx-dimension:sex sdmx-code:sex-M ;
- qb:observation eg:o1c, eg:o2c; eg:o3c, ... .
-
-eg:o1c a qb:Observation;
- qb:dataSet eg:dataset-le3 ;
- eg:refArea ex-geo:newport_00pr ;
- eg:lifeExpectancy 76.7 ;
- .
-
-eg:o2c a qb:Observation;
- qb:dataSet eg:dataset-le3 ;
- eg:refArea ex-geo:cardiff_00pt ;
- eg:lifeExpectancy 78.7 ;
- .
-
-eg:o3c a qb:Observation;
- qb:dataSet eg:dataset-le3 ;
- eg:refArea ex-geo:monmouthshire_00pp ;
- eg:lifeExpectancy 76.6 ;
- .
-
-...</pre></div>
-
-<p>There are also situations in which a publisher wishes to group a set of observations
-together for ease of access or presentation purposes but where that set is not defined
-by simply fixing a set of dimension values. For example, in
- representing weather observations it can be desirable to group
- together the latest observation available from each station even though
- each observation may have been taken at a different time.
- For those situations the Data Cube vocabulary supports
-<code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code>. A <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code> can contain an arbitrary
-collection of observations. A <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code> is a special case of a <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code>.
-
-</p></section>
-
-</section>
-
-
-<section id="schemes">
-<!--OddPage--><h2><span class="secno">8. </span>Concept schemes and code lists</h2>
-
-<section id="schemes-intro">
-<h3><span class="secno">8.1 </span>Coded values for components properties</h3>
-
-<p>The values for dimensions within a data set must be unambiguously
- defined. They may be typed values (e.g. <code>xsd:dateTime</code> for time instances)
- or codes drawn from some code list. Similarly, many attributes
- used in data sets represent coded values from some controlled term list rather
- than free text descriptions. In the Data Cube vocabulary such codes are
- represented by URI references in the usual RDF fashion.</p>
-
-<p>Sometimes
- appropriate URI sets already exist for the relevant dimensions (e.g. the representations
- of area and time periods in our running example). In other cases the data set being
- converted may use controlled terms from some scheme which does not yet have
- associated URIs. In those cases we recommend use of SKOS, representing
- the individual code values using <code>skos:Concept</code> and the overall
- set of admissible values using <code>skos:ConceptScheme</code> or <code>skos:Collection</code>.</p>
-
-<p>We illustrate this with an example drawn from the translation of the SDMX COG
- code list for gender, as used already in our worked example. The relevant subset of this code list is:</p>
-
-<div class="example"><div class="example-title"><span>Example 14</span></div><pre class="example">sdmx-code:sex a skos:ConceptScheme;
- skos:prefLabel "Code list for Sex (SEX) - codelist scheme"@en;
- rdfs:label "Code list for Sex (SEX) - codelist scheme"@en;
- skos:notation "CL_SEX";
- skos:note "This code list provides the gender."@en;
- skos:definition <http://sdmx.org/wp-content/uploads/2009/01/02_sdmx_cog_annex_2_cl_2009.pdf> ;
- rdfs:seeAlso sdmx-code:Sex ;
- sdmx-code:sex skos:hasTopConcept sdmx-code:sex-F ;
- sdmx-code:sex skos:hasTopConcept sdmx-code:sex-M .
-
-sdmx-code:Sex a rdfs:Class, owl:Class;
- rdfs:subClassOf skos:Concept ;
- rdfs:label "Code list for Sex (SEX) - codelist class"@en;
- rdfs:comment "This code list provides the gender."@en;
- rdfs:seeAlso sdmx-code:sex .
-
-sdmx-code:sex-F a skos:Concept, sdmx-code:Sex;
- skos:topConceptOf sdmx-code:sex;
- skos:prefLabel "Female"@en ;
- skos:notation "F" ;
- skos:inScheme sdmx-code:sex .
-
-sdmx-code:sex-M a skos:Concept, sdmx-code:Sex;
- skos:topConceptOf sdmx-code:sex;
- skos:prefLabel "Male"@en ;
- skos:notation "M" ;
- skos:inScheme sdmx-code:sex .</pre></div>
-
-<p><code>skos:prefLabel</code> is used to give a name to the code,
-<code>skos:note</code> gives a description and <code>skos:notation</code> can be used
-to record a short form code which might appear in other serializations.
-The SKOS specification [<cite><a class="bibref" href="#bib-SKOS-REFERENCE">SKOS-REFERENCE</a></cite>] recommends the generation of a custom datatype for
-each use of <code>skos:notation</code> but here the notation is not intended for use
-within RDF encodings, it merely documents the notation used in other representations
-(which do not use such a datatype).</p>
-
-<p>It is convenient and good practice when developing a code list to also
-create a Class to denote all the codes within the code
-list, irrespective of hierarchical structure. This allows the range of an
-<code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code> to be defined by using <code>rdfs:range</code>
-which then permits standard RDF closed-world checkers to validate use of the
-code list without requiring custom SDMX-RDF-aware tooling. We do that in the
-above example by using the common convention that the class name is the
-same as that of the concept scheme but with leading upper case.</p>
-
-<p>This code list can then be associated with a coded property, such as a dimension:</p>
-
-<div class="example"><div class="example-title"><span>Example 15</span></div><pre class="example">eg:sex a qb:DimensionProperty, qb:CodedProperty;
- qb:codeList sdmx-code:sex ;
- rdfs:range sdmx-code:Sex .</pre></div>
-
-<p>Explicitly declaring the code list using <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code>
- is not mandatory but can be helpful in those cases where a concept scheme has been defined.</p>
-</section>
-
-<section id="schemes-hierarchy">
-<h3><span class="secno">8.2 </span>Hierarchical code lists</h3>
-
-<p>In some cases code lists have a hierarchical structure. In particular, this is
-used in SDMX when the data cube includes aggregations of data values
-(e.g. aggregating a measure across geographic regions).
-Hierarchical code lists <em class="rfc2119" title="should">should</em> be represented using the
-<code>skos:narrower</code> relationship to link from the <code>skos:hasTopConcept</code>
-codes down through the tree or lattice of child codes.
-In some publishing tool chains the corresponding transitive closure
-<code>skos:narrowerTransitive</code> will be automatically inferred.
-The use of <code>skos:narrower</code> makes it possible to declare new
-concept schemes which extend an existing scheme by adding additional aggregation layers on top.
-All items are linked to the scheme via <code>skos:inScheme</code>.</p>
-</section>
-
-<section id="schemes-hierarchy-nonskos">
-<h3><span class="secno">8.3 </span>Non-SKOS hierarchies</h3>
-
-<p>It is sometimes convenient to be able to specify a hierarchical arrangement of
-concepts other than through the use of the SKOS relation <code>skos:narrower</code>.
-There are several situations where this is useful:</p>
-
-<ul>
-<li>In some cases publishers wish to be able to reuse existing reference data as their
-code lists. This particularly occurs where a geographic or admin-geographic hierarchy
-is already maintained by a separate authority but which uses non-SKOS containment or part-of relationships.</li>
-<li>Where such maintained reference data is to be reused there can be multiple hierarchies which relate
-the same codes. In particular a set of geographic entities may participate in both a geographic-containment hierarchy
-and an administrative hierarchy which do not precisely align. </li>
-<li>The SKOS relations do not define when the child concepts are disjoint (mutually exclusive) or when they form
-a complete cover of the parent concept (exhaustive).</li>
-</ul>
-
-<p>The Data Cube vocabulary supports this situation through the <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> class.
-An instance of <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> defines a set of root concepts in the hierarchy
-(<code><a href="#dfn-qb-hierarchyroot" class="internalDFN">qb:hierarchyRoot</a></code>) and a parent-to-child relationship (<code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code>) which
-links a term in the hierarchy to its immediate sub-terms. </p>
-
-<p>Thus a <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>
-is similar to a <code>skos:ConceptScheme</code> in which <code><a href="#dfn-qb-hierarchyroot" class="internalDFN">qb:hierarchyRoot</a></code> plays the same
-role as <code>skos:hasTopConcept</code>, and the value of <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> plays
-the same role as <code>skos:narrower</code>. In the case where a code list is already available as a SKOS concept scheme or collection
-then those <em class="rfc2119" title="should">should</em> be used directly; <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> is provided for cases where the
-terms are not available as SKOS but are available in some other RDF representation suitable for reuse.
-</p>
-
-<p>For example, the Ordnance Survey of Great Britain publishes a geographic hierarchy which has
-eleven roots (European Regions such as Wales, Scotland, the South West) and uses a spatial relations
-ontology to define a containment hierarchy. This could be represented as a <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> using the following.</p>
-
-<div class="example"><div class="example-title"><span>Example 16</span></div><pre class="example">PREFIX spatial: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
-
-eg:GBgeoHierarchy a qb:HierarchicalCodeList;
- rdfs:label "Geographic Hierarchy for Great Britain"@en;
- qb:hierarchyRoot
- <http://data.ordnancesurvey.co.uk/id/7000000000041427>, # South West
- <http://data.ordnancesurvey.co.uk/id/7000000000041426>, # West Midlands
- <http://data.ordnancesurvey.co.uk/id/7000000000041421>, # South East
- <http://data.ordnancesurvey.co.uk/id/7000000000041430>, # Yorkshire & the Humber
- <http://data.ordnancesurvey.co.uk/id/7000000000041423>, # East Midlands
- <http://data.ordnancesurvey.co.uk/id/7000000000041425>, # Eastern
- <http://data.ordnancesurvey.co.uk/id/7000000000041428>, # London
- <http://data.ordnancesurvey.co.uk/id/7000000000041431>, # North West
- <http://data.ordnancesurvey.co.uk/id/7000000000041422>, # North East
- <http://data.ordnancesurvey.co.uk/id/7000000000041424>, # Wales
- <http://data.ordnancesurvey.co.uk/id/7000000000041429>; # Scotland
- qb:parentChildProperty spatial:contains;
- .
-
-eg:geoDimension a qb:DimensionProperty ;
- qb:codeList eg:GBgeoHierarchy .</pre></div>
-
-<p>Note that in some cases the hierarchy to be reused may only have a
- property relating child concepts to parent concepts. This situation
- is handled by declaring
- the <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> to be
- the <code>owl:inverseOf</code> of the child-to-parent property. For
- example:</p>
-
-<div class="example"><div class="example-title"><span>Example 17</span></div><pre class="example">PREFIX spatial: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
-
-eg:GBgeoHierarchy a qb:HierarchicalCodeList;
- qb:parentChildProperty [owl:inverseOf spatial:within] .</pre></div>
-
-<p>Future extensions of Data Cube may support additional sub classes
- of <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>, for example to
- declare hierarchies in which each parent is a disjoint union of its children.</p>
-
-<!--
-<p>A sub class of <code><a>qb:HierarchicalCodeList</a></code>, <code><a>qb:AggregatableHierarchy</a></code>, is provided to declare
-hierarchies where for each parent concept the set of child concepts form a disjoint cover (i.e. a
-mutually-exclusive and exhaustive decomposition) of the parent.</p>
--->
-
-</section>
-
-<section id="schemes-aggregation">
-<h3><span class="secno">8.4 </span>Aggregation</h3>
-
-<p>The use of SKOS, or non-SKOS, hierarchies makes it possible to publish aggregated
-statistics for the non-leaf concepts in the hierarchy. The Data Cube vocabulary itself imposes
-no constraints on how such aggregation is done. Indeed in statistical applications the
-appropriate statistical corrections to make to aggregated values may be non-trivial and dependent on
-the data and precise analysis methodology. Even in simple, non-statistical, applications such
-as OLAP a number of different aggregation operators are commonly used.
-</p>
-
-<p>Vocabulary terms to represent the aggregation operations employed within a given dataset, and how one dataset
-might be derived from another, are not supported in this version of the Data Cube specification. This
-area may be addressed by future extensions to Data Cube.</p>
-</section>
-
-</section>
-
-
-<section id="metadata">
-<!--OddPage--><h2><span class="secno">9. </span>DataSet metadata</h2>
-
-<p>DataSets should be marked up with metadata to support discovery, presentation and
- processing. Dublin Core Terms [<cite><a class="bibref" href="#bib-DC11">DC11</a></cite>] <em class="rfc2119" title="should">should</em> be used
- for representing the key metadata annotations commonly needed for
- DataSets. The RDFS terms for display label (<code>rdfs:label</code>)
- descriptive comment (<code>rdfs:comment</code>) <em class="rfc2119" title="should">should</em> be given as
- well for compatibility with earlier versions of Data Cube and common
- RDF practice.
-</p>
-
-<p>The recommend core set of metadata terms is:</p>
-<ul>
- <li><code>dct:title</code></li>
- <li><code>rdfs:label</code> - may be same as <code>dct:title</code></li>
- <li><code>dct:description</code></li>
- <li><code>rdfs:comment</code> - may be same as <code>dct:description</code></li>
- <li><code>dct:issued</code></li>
- <li><code>dct:modified</code></li>
- <li><code>dct:subject</code></li>
- <li><code>dct:publisher</code></li>
- <li><code>dct:license</code></li>
-</ul>
-
-<p>Other documents, notably [<cite><a class="bibref" href="#bib-DCAT">DCAT</a></cite>], provide additional
- recommendations for metadata terms for data sets
- which may be used for describing Data Cube DataSets.</p>
-
-<section id="metadata-categorization">
-<h3><span class="secno">9.1 </span>Categorizing a data set</h3>
-
-<p>Publishers of statistics often categorize their data sets into different statistical
-domains, such as <em>Education</em>, <em>Labour</em>, or <em>Transportation</em>.
-We encourage use of <code>dct:subject</code> to record such a classification of
-a whole data set.
-The classification terms can include coarse grained classifications, such
-as the List of Subject-matter Domains from the SDMX Content-oriented Guidelines,
-and fine grained classifications to support discovery of data sets.</p>
-
-<p>The classification schemes are typically represented using the SKOS vocabulary. For
-convenience the SMDX Subject-matter Domains have been encoded as a SKOS concept scheme
-at <a href="http://purl.org/linked-data/sdmx/2009/subject">http://purl.org/linked-data/sdmx/2009/subject#</a>.</p>
-
-<p>Thus our sample dataset might be marked up by:</p>
-
-<div class="example"><div class="example-title"><span>Example 18</span></div><pre class="example">eg:dataset1 a qb:DataSet;
- rdfs:label "Life expectancy"@en;
- dct:title "Life expectancy"@en;
- rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
- dct:description "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
- dct:issued "2010-08-11"^^xsd:date;
- dct:subject
- sdmx-subject:3.2 , # regional and small area statistics
- sdmx-subject:1.4 , # Health
- ex:wales; # Wales
- ...</pre></div>
-
-<p>where <code>eg:Wales</code> is a <code>skos:Concept</code> drawn from an appropriate controlled
-vocabulary for places.</p>
-</section>
-
-
-<section id="metadata-publishers">
-<h3><span class="secno">9.2 </span>Describing publishers</h3>
-
-<p>The organization that publishes a dataset should be recorded as part of the dataset metadata.
-Again we recommend use of the Dublin Core term <code>dct:publisher</code> for this.
-The organization should be represented as an instance of <code>foaf:Agent</code>, or
-some more specific subclass such as <code>org:Organization</code> [<cite><a class="bibref" href="#bib-ORG">ORG</a></cite>].</p>
-
-<div class="example"><div class="example-title"><span>Example 19</span></div><pre class="example">eg:dataset1 a qb:DataSet;
- dct:publisher <http://example.com/meta#organization> .
-
-<http://example.com/meta#organization> a org:Organization, foaf:Agent;
- rdfs:label "Example org" . </pre></div>
-
-<p>Extension vocabularies may provide additional metadata properties and may impose
- constraints on what metadata must be provided.</p>
-</section>
-
-</section>
-
-<section id="normalize">
-<!--OddPage--><h2><span class="secno">10. </span>Abbreviated and normalized data cubes</h2>
-
-<p>In normal form then the <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>s which
-make up a Data Cube have property values for each of the required
-dimensions, attributes and measures as declared in the associated data
-structure definition. This form for a Data Cube is
-termed <em><dfn id="dfn-normalized">normalized</dfn></em>. It is a convenient format for
-querying data and makes it possible to write uniform queries which
-extract sets of observations, including from across multiple
-cubes. However, the verbosity of a fully normalized representation
-incurs overheads in transmission and storage of Data Cubes which may
-be problematic in some settings.
-</p>
-
-<p>To address this the Data Cube vocabulary supports a notion of
-an <em><dfn id="dfn-abbreviated">abbreviated</dfn></em> format in which component
-properties may be <em><dfn id="dfn-attached">attached</dfn></em> to other levels in the
-Data Cube. Specifically they may be attached to
-a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> or <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>.
-In those cases the attached property is taken to be applied to all
-the <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> instances associated with that
-attachment point. For illustration
-see <a href="#attachment-example">example 4</a> in which the unit of
-measure is declared as to be attached to the whole data set and need
-not be repeated for every observation.</p>
-
-<p>It is also possible to attach attributes to a <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code>
- in which case the attribute is intended to apply only to that property and not
- to the observations in which that property occurs.</p>
-
-<section id="normalize-algorithm">
-<h3><span class="secno">10.1 </span>Normalization algorithm</h3>
-
-<div class="note"><div class="note-title"><span>Note</span></div><div class="">
-This section is At Risk. The working group believes this formulation to
-be correct and compatible with earlier versions of the Data Cube vocabulary.
-However as a new addition it has not received as much
-scrutiny as other parts of the specification. If problems are uncovered
-during the Last Call process the working group may retract all or part of this section.
-</div></div>
-
-<p>We define these notions by means of a transformation algorithm
- which can normalize an abbreviated Data Cube. We express this transformation using the SPARQL 1.1
- Update language [<cite><a class="bibref" href="#bib-SPARQL-UPDATE-11">SPARQL-UPDATE-11</a></cite>]. Use of this notation does not imply that
- the transformation must be implemented this way. Information
- exchanges using Data Cube may retain data in abbreviated form and
- use other techniques such as query rewriting to ease access, may
- implement the normalization algorithm by other means or may handle
- all data in normalized form or any mix of these.</p>
-
-
-<p>The normalization algorithm comprises two sets of SPARQL Update
- operations which should be applied in turn to a SPARQL Dataset in which the
- default graph contains the Data Cube RDF graph to be normalized.</p>
-
-<p>The first update operation performs selective type and property closure
- operations. These serve two purposes. They ensure
- that <code>rdf:type</code> assertions on instances
- of <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> and <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>
- may be omitted in an abbreviated Data Cube. They also simplify
- the second set of update operations by expanding
- the sub properties of <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
- (specifically <code><a href="#dfn-qb-dimension" class="internalDFN">qb:dimension</a></code>, <code><a href="#dfn-qb-measure" class="internalDFN">qb:measure</a></code>
- and <code><a href="#dfn-qb-attribute" class="internalDFN">qb:attribute</a></code>).</p>
-
-<table class="bordered-table">
- <thead>
- <tr><th>Phase 1: Type and property closure</th></tr>
- </thead>
- <tbody><tr><td>
-<pre>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
-PREFIX qb: <http://purl.org/linked-data/cube#>
-
-INSERT {
- ?o rdf:type qb:Observation .
-} WHERE {
- [] qb:observation ?o .
-};
-
-INSERT {
- ?o rdf:type qb:Observation .
-} WHERE {
- ?o qb:dataSet [] .
-};
-
-INSERT {
- ?s rdf:type qb:Slice .
-} WHERE {
- [] qb:slice ?s.
-};
-
-INSERT {
- ?cs qb:componentProperty ?p .
- ?p rdf:type qb:DimensionProperty .
-} WHERE {
- ?cs qb:dimension ?p .
-};
-
-INSERT {
- ?cs qb:componentProperty ?p .
- ?p rdf:type qb:MeasureProperty .
-} WHERE {
- ?cs qb:measure ?p .
-};
-
-INSERT {
- ?cs qb:componentProperty ?p .
- ?p rdf:type qb:AttributeProperty .
-} WHERE {
- ?cs qb:attribute ?p .
-}
-</pre>
- </td></tr></tbody>
-</table>
-
-
-<p>These closure operations are implied by the RDFS semantics of the
- Data Cube vocabulary. Data Cube processors <em class="rfc2119" title="may">may</em> apply full RDFS
- closure in place of the update operation defined here.</p>
-
-<p>The second update operation checks the components of the data
- structure definition of the data set for declared attachment levels.
- For each of the possible attachments levels it looks for occurrences
- of that component to be pushed down to the corresponding
- observations.
-</p>
-
-<table class="bordered-table">
- <thead>
- <tr><th>Phase 2: Push down attachment levels</th></tr>
- </thead>
- <tbody><tr><td>
-<pre>PREFIX qb: <http://purl.org/linked-data/cube#>
-
-# Dataset attachments
-INSERT {
- ?obs ?comp ?value
-} WHERE {
- ?spec qb:componentProperty ?comp ;
- qb:componentAttachment qb:DataSet .
- ?dataset qb:structure [qb:component ?spec];
- ?comp ?value .
- ?obs qb:dataSet ?dataset.
-};
-
-# Slice attachments
-INSERT {
- ?obs ?comp ?value
-} WHERE {
- ?spec qb:componentProperty ?comp;
- qb:componentAttachment qb:Slice .
- ?dataset qb:structure [qb:component ?spec];
- qb:slice ?slice .
- ?slice ?comp ?value;
- qb:observation ?obs .
-};
-
-# Dimension values on slices
-INSERT {
- ?obs ?comp ?value
-} WHERE {
- ?spec qb:componentProperty ?comp .
- ?comp a qb:DimensionProperty .
- ?dataset qb:structure [qb:component ?spec];
- qb:slice ?slice .
- ?slice ?comp ?value;
- qb:observation ?obs .
-}
-</pre>
- </td></tr></tbody>
-</table>
-
-
-</section>
-
-</section>
-
-<section id="wf">
-<!--OddPage--><h2><span class="secno">11. </span>Well-formed cubes</h2>
-
-<div class="note"><div class="note-title"><span>Note</span></div><div class="">
-This section is At Risk. The working group believes these criteria to
-be correct and compatible with earlier versions of the Data Cube vocabulary.
-However as a new addition they have not received as much
-scrutiny as other parts of the specification. If problems are uncovered
-during the Last Call process the working group may retract all or part of this section.
-</div></div>
-
-<p>An instance of an RDF Data Cube should conform to a set of
- integrity constraints which we define in this section.</p>
-
-<p>A <dfn id="dfn-well-formed">well-formed</dfn> RDF Data Cube is an a RDF graph describing
- one or more instances of <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> for which
- each of the integrity checks defined here passes.</p>
-
-<p>A <dfn id="dfn-well-formed-abbreviated">well-formed abbreviated</dfn> RDF Data Cube is an a RDF
- graph which, when expanded using
- the <a href="#normalize-algorithm">normalization algorithm</a>,
- yields a <a>well-formed RDF Data Cube</a>.</p>
-
-<section id="wf-rules">
-<h3><span class="secno">11.1 </span>Integrity constraints</h3>
-
-<p>Each integrity constraint is expressed as narrative prose and, where possible, a SPARQL
- [<cite><a class="bibref" href="#bib-SPARQL-QUERY-11">SPARQL-QUERY-11</a></cite>] ASK query or query template. If the ASK query is applied to an RDF graph then it
- will return <em>true</em> if that graph contains one or more Data Cube instances which
- violate the corresponding constraint.
-</p>
-<p>
- Using SPARQL queries to
- express the integrity constraints does not imply that integrity
- checking must be performed this way. Implementations are free
- to use alternative query formulations or alternative implementation
- techniques to perform equivalent checks. </p>
-
-<p>Each integrity constraint query assumes the following set of prefix bindings:</p>
-<pre>PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
-PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
-PREFIX skos: <http://www.w3.org/2004/02/skos/core#>
-PREFIX qb: <http://purl.org/linked-data/cube#>
-PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
-PREFIX owl: <http://www.w3.org/2002/07/owl#>
-</pre>
-
-<p>The complete set of constraints is listed below.</p>
-
-<h3 id="ic-0">IC-0. Datatype consistency</h3>
-<p>
-The RDF graph must be consistent under RDF D-entailment [<cite><a class="bibref" href="#bib-RDF-MT">RDF-MT</a></cite>]
-using a datatype map containing all the datatypes used within the graph.
-</p>
-
-<h3 id="ic-1">IC-1. Unique DataSet</h3>
-<p>
-Every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> has exactly one associated <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- {
- # Check observation has a data set
- ?obs a qb:Observation .
- FILTER NOT EXISTS { ?obs qb:dataSet ?dataset1 . }
- } UNION {
- # Check has just one data set
- ?obs a qb:Observation ;
- qb:dataSet ?dataset1, ?dataset2 .
- FILTER (?dataset1 != ?dataset2)
- }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-2">IC-2. Unique DSD</h3>
-<p>
-Every <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> has exactly one associated <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- {
- # Check dataset has a dsd
- ?dataset a qb:DataSet .
- FILTER NOT EXISTS { ?dataset qb:structure ?dsd . }
- } UNION {
- # Check has just one dsd
- ?dataset a qb:DataSet ;
- qb:structure ?dsd1, ?dsd2 .
- FILTER (?dsd1 != ?dsd2)
- }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-3">IC-3. DSD includes measure</h3>
-<p>
-Every <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> must include at least one declared measure.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?dsd a qb:DataStructureDefinition .
- FILTER NOT EXISTS { ?dsd qb:component [qb:componentProperty [a qb:MeasureProperty]] }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-4">IC-4. Dimensions have range</h3>
-<p>
-Every dimension declared in a <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> must have a declared <code><a>rdfs:range</a></code>.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?dim a qb:DimensionProperty .
- FILTER NOT EXISTS { ?dim rdfs:range [] }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-5">IC-5. Concept dimensions have code lists</h3>
-<p>
-Every dimension with range <code><a>skos:Concept</a></code> must have a <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code>.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?dim a qb:DimensionProperty ;
- rdfs:range skos:Concept .
- FILTER NOT EXISTS { ?dim qb:codeList [] }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-6">IC-6. Only attributes may be optional</h3>
-<p>
-The only components of
-a <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code> that may be marked as
-optional, using <code><a href="#dfn-qb-componentrequired" class="internalDFN">qb:componentRequired</a></code> are attributes.
-</p>
-
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?dsd qb:component ?componentSpec .
- ?componentSpec qb:componentRequired "false"^^xsd:boolean ;
- qb:componentProperty ?component .
- FILTER NOT EXISTS { ?component a qb:AttributeProperty }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-7">IC-7. Slice Keys must be declared</h3>
-<p>
-Every <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code> must be associated with a <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>.
-</p>
-
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?sliceKey a qb:SliceKey .
- FILTER NOT EXISTS { [a qb:DataStructureDefinition] qb:sliceKey ?sliceKey }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-8">IC-8. Slice Keys consistent with DSD</h3>
-<p>
-Every <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code> on a <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code> must also be declared as a <code><a href="#dfn-qb-component" class="internalDFN">qb:component</a></code> of the associated <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>.
-</p>
-
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?slicekey a qb:SliceKey;
- qb:componentProperty ?prop .
- ?dsd qb:sliceKey ?sliceKey .
- FILTER NOT EXISTS { ?dsd qb:component [qb:componentProperty ?prop] }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-9">IC-9. Unique slice structure</h3>
-<p>
-Each <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code> must have exactly one associated <code><a href="#dfn-qb-slicestructure" class="internalDFN">qb:sliceStructure</a></code>.
-</p>
-
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- {
- # Slice has a key
- ?slice a qb:Slice .
- FILTER NOT EXISTS { ?slice qb:sliceStructure ?key }
- } UNION {
- # Slice has just one key
- ?slice a qb:Slice ;
- qb:sliceStructure ?key1, ?key2;
- FILTER (?key1 != ?key2)
- }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-
-<h3 id="ic-10">IC-10. Slice dimensions complete</h3>
-<p>
-Every <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code> must have a value for every dimension declared in its <code><a href="#dfn-qb-slicestructure" class="internalDFN">qb:sliceStructure</a></code>.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?slice qb:sliceStructure [qb:componentProperty ?dim] .
- FILTER NOT EXISTS { ?slice ?dim [] }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-11">IC-11. All dimensions required</h3>
-<p>
-Every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> has a value for each dimension declared in its associated <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>.
-</p>
-
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
- ?dim a qb:DimensionProperty;
- FILTER NOT EXISTS { ?obs ?dim [] }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-12">IC-12. No duplicate observations</h3>
-<p>
-No two <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>s in the same <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> may have the same value for all dimensions.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- FILTER( ?allEqual )
- {
- # For each pair of observations test if all the dimension values are the same
- SELECT (MIN(?equal) AS ?allEqual) WHERE {
- ?obs1 qb:dataSet ?dataset .
- ?obs2 qb:dataSet ?dataset .
- FILTER (?obs1 != ?obs2)
- ?dataset qb:structure/qb:component/qb:componentProperty ?dim .
- ?dim a qb:DimensionProperty .
- ?obs1 ?dim ?value1 .
- ?obs2 ?dim ?value2 .
- BIND( ?value1 = ?value2 AS ?equal)
- } GROUP BY ?obs1 ?obs2
- }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-13">IC-13. Required attributes</h3>
-<p>
-Every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> has a value for each declared attribute that is marked as required.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?obs qb:dataSet/qb:structure/qb:component ?component .
- ?component qb:componentRequired "true"^^xsd:boolean ;
- qb:componentProperty ?attr .
- FILTER NOT EXISTS { ?obs ?attr [] }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-14">IC-14. All measures present</h3>
-<p>
-In a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> which does not use a <a href="#dfn-measure-dimension" class="internalDFN">Measure dimension</a> then each individual <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> must have a value for every declared measure.
-</p>
-
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- # Observation in a non-measureType cube
- ?obs qb:dataSet/qb:structure ?dsd .
- FILTER NOT EXISTS { ?dsd qb:component/qb:componentProperty qb:measureType }
-
- # verify every measure is present
- ?dsd qb:component/qb:componentProperty ?measure .
- ?measure a qb:MeasureProperty;
- FILTER NOT EXISTS { ?obs ?measure [] }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-15">IC-15. Measure dimension consistent</h3>
-<p>
-In a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> which uses a <a href="#dfn-measure-dimension" class="internalDFN">Measure dimension</a> then each <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> must have a value for the measure corresponding to its given <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code>.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- # Observation in a measureType-cube
- ?obs qb:dataSet/qb:structure ?dsd ;
- qb:measureType ?measure .
- ?dsd qb:component/qb:componentProperty qb:measureType .
- # Must have value for its measureType
- FILTER NOT EXISTS { ?obs ?measure [] }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-16">IC-16. Single measure on measure dimension observation</h3>
-<p>
-In a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> which uses a <a href="#dfn-measure-dimension" class="internalDFN">Measure dimension</a> then each <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> must only have a value for one measure (by IC-15 this will be the measure corresponding to its <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code>).
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- # Observation with measureType
- ?obs qb:dataSet/qb:structure ?dsd ;
- qb:measureType ?measure ;
- ?omeasure [] .
- # Any measure on the observation
- ?dsd qb:component/qb:componentProperty qb:measureType ;
- qb:component/qb:componentProperty ?omeasure .
- ?omeasure a qb:MeasureProperty .
- # Must be the same as the measureType
- FILTER (?omeasure != ?measure)
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-17">IC-17. All measures present in measures dimension cube </h3>
-<p>
-In a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> which uses a <a href="#dfn-measure-dimension" class="internalDFN">Measure dimension</a> then if there is a Observation for some combination of non-measure dimensions then there must be other Observations with the same non-measure dimension values for each of the declared measures.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- {
- # Count number of other measures found at each point
- SELECT ?numMeasures (COUNT(?obs2) AS ?count) WHERE {
- {
- # Find the DSDs and check how many measures they have
- SELECT ?dsd (COUNT(?m) AS ?numMeasures) WHERE {
- ?dsd qb:component/qb:componentProperty ?m.
- ?m a qb:MeasureProperty .
- } GROUP BY ?dsd
- }
-
- # Observation in measureType cube
- ?obs1 qb:dataSet/qb:structure ?dsd;
- qb:dataSet ?dataset ;
- qb:measureType ?m1 .
-
- # Other observation at same dimension value
- ?obs2 qb:dataSet ?dataset ;
- qb:measureType ?m2 .
- FILTER NOT EXISTS {
- ?dsd qb:component/qb:componentProperty ?dim .
- FILTER (?dim != qb:measureType)
- ?dim a qb:DimensionProperty .
- ?obs1 ?dim ?v1 .
- ?obs2 ?dim ?v2.
- FILTER (?v1 != ?v2)
- }
-
- } GROUP BY ?obs1 ?numMeasures
- HAVING (?count != ?numMeasures)
- }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-18">IC-18. Consistent data set links</h3>
-<p>
-If a <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code> D has a <code><a href="#dfn-qb-slice-1" class="internalDFN">qb:slice</a></code> S, and S has an <code><a href="#dfn-qb-observation-1" class="internalDFN">qb:observation</a></code> O, then the <code><a href="#dfn-qb-dataset-1" class="internalDFN">qb:dataSet</a></code> corresponding to O must be D.
-</p>
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?dataset qb:slice ?slice .
- ?slice qb:observation ?obs .
- FILTER NOT EXISTS { ?obs qb:dataSet ?dataset . }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-19">IC-19. Codes from code list</h3>
-<p>
-If a dimension property has a <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code>, then the value of the dimension property on every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> must be in the code list.
-</p>
-<p>The following integrity check queries must be applied to an RDF graph which contains the
-definition of the code list as well as the Data Cube to be checked. In the case
-of a <code>skos:ConceptScheme</code> then each concept must be linked to the scheme using
-<code>skos:inScheme</code>. In the case of a <code>skos:Collection</code> then the
-collection must link to each concept or nested collection using <code>skos:member</code> (i.e. if the
-collection uses <code>skos:memberList</code> then the entailment of <code>skos:member</code>
-values defined by <a href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/#S36">S36</a>
-in [<cite><a class="bibref" href="#bib-SKOS-REFERENCE">SKOS-REFERENCE</a></cite>] must be materialized). </p>
-
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
- ?dim a qb:DimensionProperty ;
- qb:codeList ?list .
- ?list a skos:ConceptScheme .
- ?obs ?dim ?v .
- FILTER NOT EXISTS { ?v skos:inScheme ?list }
-}
-
-ASK {
- ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
- ?dim a qb:DimensionProperty ;
- qb:codeList ?list .
- ?list a skos:Collection .
- ?obs ?dim ?v .
- FILTER NOT EXISTS { ?list skos:member+ ?v }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-20">IC-20. Codes from hierarchy</h3>
-<p>
-If a dimension property has
-a <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> with a
-non-blank <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> then the value of
-that dimension property on every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>
-must be reachable from a root of the hierarchy using zero or more hops along the <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> links.
-</p>
-<p>
-This check cannot be made by a simple fixed SPARQL query. Instead a
-query template is supplied.
-An instance of the template should be generated
-for each <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> which has an IRI
-value for its <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code>.
-That is for each binding of <code>?p</code> in the following
-instantiation query:</p>
-<pre>SELECT ?p WHERE {
- ?hierarchy a qb:HierarchicalCodeList ;
- qb:parentChildProperty ?p .
- FILTER ( isIRI(?p) )
-}
-</pre>
-
-<p>The template is then instantiated by replacing the
- string <code>$p</code> by the IRI found by the
- instantiation query. The template is:</p>
-
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
- ?dim a qb:DimensionProperty ;
- qb:codeList ?list .
- ?list a qb:HierarchicalCodeList .
- ?obs ?dim ?v .
- FILTER NOT EXISTS { ?list qb:hierarchyRoot/<$p>* ?v }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-<h3 id="ic-21">IC-21. Codes from hierarchy (inverse)</h3>
-<p>
-If a dimension property has
-a <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> with an
-inverse <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> then the value of
-that dimension property on every <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>
-must be reachable from a root of the hierarchy using zero or more hops along the inverse <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> links.
-</p>
-
-<p>
-This check cannot be made by a simple fixed SPARQL query. Instead a
-query template is supplied.
-An instance of the template should be generated
-for each <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> which has a blank-node
-value for its <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code>, with an
-associated inverse property.
-That is for each binding of <code>?p</code> in the following
-instantiation query:</p>
-<pre>SELECT ?p WHERE {
- ?hierarchy a qb:HierarchicalCodeList;
- qb:parentChildProperty ?pcp .
- FILTER( isBlank(?pcp) )
- ?pcp owl:inverseOf ?p .
- FILTER( isIRI(?p) )
-}
-</pre>
-
-<p>The template is then instantiated by replacing the
- string <code>$p</code> by the IRI found by the
- instantiation query. The template is:</p>
-
-<table class="bordered-table">
- <tbody>
- <tr><td><pre>ASK {
- ?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
- ?dim a qb:DimensionProperty ;
- qb:codeList ?list .
- ?list a qb:HierarchicalCodeList .
- ?obs ?dim ?v .
- FILTER NOT EXISTS { ?list qb:hierarchyRoot/(^<$p>)* ?v }
-}
- </pre></td></tr>
- </tbody>
-</table>
-
-</section>
-
-</section>
-
-<section id="vocab-reference">
-<!--OddPage--><h2><span class="secno">12. </span>Vocabulary reference</h2>
-
-
-<section id="reference-datasets">
-<h3><span class="secno">12.1 </span>DataSets</h3>
-
-<p><em>See Section <a href="#datasets">Expressing data sets</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_DataSet">
- <em>Class:</em> <code><dfn id="dfn-qb-dataset">qb:DataSet</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-attachable" class="internalDFN">qb:Attachable</a></code>
- <em>Equivalent to: </em>
- <code>scovo:Dataset</code>
- </dt>
- <dd>Represents a collection of observations, possibly organized into various slices, conforming to some common dimensional structure.</dd>
-</dl>
-</section>
-
-
-<section id="reference-observations">
-<h3><span class="secno">12.2 </span>Observations</h3>
-<p><em>See Section <a href="#datasets">Expressing data sets</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_Observation">
- <em>Class:</em> <code><dfn id="dfn-qb-observation">qb:Observation</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-attachable" class="internalDFN">qb:Attachable</a></code>
- <em>Equivalent to: </em>
- <code>scovo:Item</code>
- </dt>
- <dd>A single observation in the cube, may have one or more associated measured values.</dd>
-
- <dt id="ref_qb_dataSet_LC">
- <em>Property:</em> <code><dfn id="dfn-qb-dataset-1">qb:dataSet</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>
- )
- </dt>
- <dd>Indicates the data set of which this observation is a part.</dd>
-
- <dt id="ref_qb_observation_LC">
- <em>Property:</em> <code><dfn id="dfn-qb-observation-1">qb:observation</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>
- )
- </dt>
- <dd>Indicates a observation contained within this slice of the data set.</dd>
-</dl>
-</section>
-
-
-<section id="reference-slices">
-<h3><span class="secno">12.3 </span>Slices</h3>
-<p><em>See Section <a href="#slices">Slices</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_ObservationGroup">
- <em>Class:</em> <code><dfn id="dfn-qb-observationgroup">qb:ObservationGroup</dfn></code>
- </dt>
- <dd>A, possibly arbitrary, group of observations.</dd>
-
-
- <dt id="ref_qb_Slice">
- <em>Class:</em> <code><dfn id="dfn-qb-slice">qb:Slice</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-attachable" class="internalDFN">qb:Attachable</a></code>,
- <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code>
- </dt>
- <dd>Denotes a subset of a DataSet defined by fixing a subset of the dimensional values, component properties on the Slice.</dd>
-
- <dt id="ref_qb_slice_LC">
- <em>Property:</em> <code><dfn id="dfn-qb-slice-1">qb:slice</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>;
- <em>sub property of:</em>
- <code><a href="#dfn-qb-observationgroup-1" class="internalDFN">qb:observationGroup</a></code>
- )
- </dt>
- <dd>Indicates a subset of a DataSet defined by fixing a subset of the dimensional values.</dd>
-
- <dt id="ref_qb_observationGroup">
- <em>Property:</em> <code><dfn id="dfn-qb-observationgroup-1">qb:observationGroup</dfn></code>
- ( <em>Domain:</em>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code>
- )
- </dt>
- <dd>Indicates a group of observations. The domain of this property is left open so that a group may be attached to different resources and need not be restricted to a single DataSet.</dd>
-
-</dl>
-</section>
-
-
-<section id="reference-components">
-<h3><span class="secno">12.4 </span>Dimensions, Attributes, Measures</h3>
-<p><em>See Section <a href="#dsd-dimensions">Dimensions, attributes and measures</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_Attachable">
- <em>Class:</em> <code><dfn id="dfn-qb-attachable">qb:Attachable</dfn></code>
- </dt>
- <dd>Abstract superclass for everything that can have attributes and dimensions.</dd>
-
- <dt id="ref_qb_ComponentProperty">
- <em>Class:</em> <code><dfn id="dfn-qb-componentproperty">qb:ComponentProperty</dfn></code>
- <em>Sub class of: </em>
- <code>rdf:Property</code>
- </dt>
- <dd>Abstract super-class of all properties representing dimensions, attributes or measures.</dd>
-
- <dt id="ref_qb_DimensionProperty">
- <em>Class:</em> <code><dfn id="dfn-qb-dimensionproperty">qb:DimensionProperty</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>,
- <code><a href="#dfn-qb-codedproperty" class="internalDFN">qb:CodedProperty</a></code>
- </dt>
- <dd>The class of component properties which represent the dimensions of the cube.</dd>
-
- <dt id="ref_qb_AttributeProperty">
- <em>Class:</em> <code><dfn id="dfn-qb-attributeproperty">qb:AttributeProperty</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
- </dt>
- <dd>The class of component properties which represent attributes of observations in the cube, e.g. unit of measurement.</dd>
-
- <dt id="ref_qb_MeasureProperty">
- <em>Class:</em> <code><dfn id="dfn-qb-measureproperty">qb:MeasureProperty</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
- </dt>
- <dd>The class of component properties which represent the measured value of the phenomenon being observed.</dd>
-
- <dt id="ref_qb_CodedProperty">
- <em>Class:</em> <code><dfn id="dfn-qb-codedproperty">qb:CodedProperty</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
- </dt>
- <dd>Superclass of all coded component properties.</dd>
-</dl>
-</section>
-
-
-<section id="reference-component-properties">
-<h3><span class="secno">12.5 </span>Reusable general purpose component properties</h3>
-<p><em>See Section <a href="#dsd-mm-dim">Measure dimensions</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_measureType">
- <em>Property:</em> <code><dfn id="dfn-qb-measuretype">qb:measureType</dfn></code>
- ( <em>Domain:</em>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code>
- )
- </dt>
- <dd>Generic measure dimension, the value of this dimension indicates which measure (from the set of measures in the DSD) is being given by the observation.</dd>
-</dl>
-</section>
-
-
-<section id="reference-dsd">
-<h3><span class="secno">12.6 </span>Data Structure Definitions</h3>
-<p><em>See Section <a href="#dsd-dsd">ComponentSpecifications and DataStructureDefinitions</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_DataStructureDefinition">
- <em>Class:</em> <code><dfn id="dfn-qb-datastructuredefinition">qb:DataStructureDefinition</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-componentset" class="internalDFN">qb:ComponentSet</a></code>
- </dt>
- <dd>Defines the structure of a DataSet or slice.</dd>
-
- <dt id="ref_qb_structure">
- <em>Property:</em> <code><dfn id="dfn-qb-structure">qb:structure</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>
- )
- </dt>
- <dd>Indicates the structure to which this data set conforms</dd>
-
- <dt id="ref_qb_component">
- <em>Property:</em> <code><dfn id="dfn-qb-component">qb:component</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code>
- )
- </dt>
- <dd>Indicates a component specification which is included in the structure of the dataset.</dd>
-</dl>
-</section>
-
-
-<section id="reference-compspec">
-<h3><span class="secno">12.7 </span>Component specifications - for qualifying component use in a DSD</h3>
-<p><em>See Section <a href="#dsd-dsd">ComponentSpecifications and DataStructureDefinitions</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_ComponentSpecification">
- <em>Class:</em> <code><dfn id="dfn-qb-componentspecification">qb:ComponentSpecification</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-componentset" class="internalDFN">qb:ComponentSet</a></code>
- </dt>
- <dd>Used to define properties of a component (attribute, dimension etc) which are specific to its usage in a DSD.</dd>
-
- <dt id="ref_qb_ComponentSet">
- <em>Class:</em> <code><dfn id="dfn-qb-componentset">qb:ComponentSet</dfn></code>
- </dt>
- <dd>Abstract class of things which reference one or more ComponentProperties</dd>
-
- <dt id="ref_qb_componentProperty_LC">
- <em>Property:</em> <code><dfn id="dfn-qb-componentproperty-1">qb:componentProperty</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-componentset" class="internalDFN">qb:ComponentSet</a></code>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
- )
- </dt>
- <dd>Indicates a ComponentProperty (i.e. attribute/dimension) expected on a DataSet, or a dimension fixed in a SliceKey.</dd>
-
- <dt id="ref_qb_order">
- <em>Property:</em> <code><dfn id="dfn-qb-order">qb:order</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code>
- -> <em>Range:</em>
- <code>xsd:int</code>
- )
- </dt>
- <dd>Indicates a priority order for the components of sets with this structure, used to guide presentations - lower order numbers come before higher numbers, un-numbered components come last.</dd>
-
- <dt id="ref_qb_componentRequired">
- <em>Property:</em> <code><dfn id="dfn-qb-componentrequired">qb:componentRequired</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code>
- -> <em>Range:</em>
- <code>xsd:boolean</code>
- )
- </dt>
- <dd>Indicates whether a component property is required (true) or optional (false) in the context of a DSD. Only applicable
- to components corresponding to an attribute. Defaults to false (optional).</dd>
-
- <dt id="ref_qb_componentAttachment">
- <em>Property:</em> <code><dfn id="dfn-qb-componentattachment">qb:componentAttachment</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code>
- -> <em>Range:</em>
- <code>rdfs:Class</code>
- )
- </dt>
- <dd>Indicates the level at which the component property should be attached, this might be an qb:DataSet, qb:Slice or qb:Observation, or a qb:MeasureProperty.</dd>
-
- <dt id="ref_qb_dimension">
- <em>Property:</em> <code><dfn id="dfn-qb-dimension">qb:dimension</dfn></code>
- ( <em>Domain:</em>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-dimensionproperty" class="internalDFN">qb:DimensionProperty</a></code>
- ; <em>sub property of: </em>
- <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
- )
- </dt>
- <dd>An alternative to qb:componentProperty which makes explicit that the component is a dimension.</dd>
-
- <dt id="ref_qb_measure">
- <em>Property:</em> <code><dfn id="dfn-qb-measure">qb:measure</dfn></code>
- ( <em>Domain:</em>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-measureproperty" class="internalDFN">qb:MeasureProperty</a></code>
- ; <em>sub property of: </em>
- <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
- )
- </dt>
- <dd>An alternative to qb:componentProperty which makes explicit that the component is a measure.</dd>
-
- <dt id="ref_qb_attribute">
- <em>Property:</em> <code><dfn id="dfn-qb-attribute">qb:attribute</dfn></code>
- ( <em>Domain:</em>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-attributeproperty" class="internalDFN">qb:AttributeProperty</a></code>
- ; <em>sub property of: </em>
- <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
- )
- </dt>
- <dd>An alternative to qb:componentProperty which makes explicit that the component is a attribute.</dd>
-
- <dt id="ref_qb_measureDimension">
- <em>Property:</em> <code><dfn id="dfn-qb-measuredimension">qb:measureDimension</dfn></code>
- ( <em>Domain:</em>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-dimensionproperty" class="internalDFN">qb:DimensionProperty</a></code>
- ; <em>sub property of: </em>
- <code><a href="#dfn-qb-componentproperty-1" class="internalDFN">qb:componentProperty</a></code>
- )
- </dt>
- <dd>An alternative to qb:componentProperty which makes explicit that the component is a measure dimension.</dd>
-</dl>
-</section>
-
-
-<section id="reference-slice-definitions">
-<h3><span class="secno">12.8 </span>Slice definitions</h3>
-<p><em>See Section <a href="#slices">Slices</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_SliceKey">
- <em>Class:</em> <code><dfn id="dfn-qb-slicekey">qb:SliceKey</dfn></code>
- <em>Sub class of: </em>
- <code><a href="#dfn-qb-componentset" class="internalDFN">qb:ComponentSet</a></code>
- </dt>
- <dd>Denotes a subset of the component properties of a DataSet which are fixed in the corresponding slices.</dd>
-
- <dt id="ref_qb_sliceStructure">
- <em>Property:</em> <code><dfn id="dfn-qb-slicestructure">qb:sliceStructure</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code>
- )
- </dt>
- <dd>Indicates the slice key corresponding to this slice.</dd>
-
- <dt id="ref_qb_sliceKey_LC">
- <em>Property:</em> <code><dfn id="dfn-qb-slicekey-1">qb:sliceKey</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-dataset" class="internalDFN">qb:DataSet</a></code>
- -> <em>Range:</em>
- <code><a href="#dfn-qb-slicekey" class="internalDFN">qb:SliceKey</a></code>
- )
- </dt>
- <dd>Indicates a slice key which is used for slices in this dataset.</dd>
-</dl>
-</section>
-
-
-<section id="reference-concepts">
-<h3><span class="secno">12.9 </span>Concepts</h3>
-<p><em>See Section <a href="#schemes">Concept schemes and code lists</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_concept">
- <em>Property:</em> <code><dfn id="dfn-qb-concept">qb:concept</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-componentproperty" class="internalDFN">qb:ComponentProperty</a></code>
- -> <em>Range:</em>
- <code>skos:Concept</code>
- )
- </dt>
- <dd>Gives the concept which is being measured or indicated by a ComponentProperty.</dd>
-
- <dt id="ref_qb_codeList">
- <em>Property:</em> <code><dfn id="dfn-qb-codelist">qb:codeList</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-codedproperty" class="internalDFN">qb:CodedProperty</a></code>
- -> <em>Range:</em>
- <code>owl:unionOf(skos:ConceptScheme skos:Collection qb:HierarchicalCodeList)</code>
- )
- </dt>
- <dd>Gives the code list associated with a CodedProperty.</dd>
-</dl></section>
-
-<section id="reference-nonskos-hierarchy">
-<h3><span class="secno">12.10 </span>Non-SKOS Hierarchies</h3>
-<p><em>See Section <a href="#schemes-hierarchy-nonskos">Non-SKOS hierarchies</a>.</em></p>
-
-<dl class="vocab_reference">
-
- <dt id="ref_qb_Hierarchy">
- <em>Class:</em> <code><dfn id="dfn-qb-hierarchicalcodelist">qb:HierarchicalCodeList</dfn></code>
- </dt>
- <dd>Represents a generalized hierarchy of concepts which can be used for coding. The hierarchy is defined by one or more roots together with a property which relates concepts in the hierarchy to their child concept . The same concepts may be members of multiple hierarchies provided that different qb:parentChildProperty values are used for each hierarchy.</dd>
- <dt id="ref_qb_hierarchyRoot">
- <em>Property:</em> <code><dfn id="dfn-qb-hierarchyroot">qb:hierarchyRoot</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>
- )
- </dt>
- <dd>Specifies a root of the hierarchy. A hierarchy may have multiple roots but must have at least one. </dd>
-
- <dt id="ref_qb_parentChildProperty">
- <em>Property:</em> <code><dfn id="dfn-qb-parentchildproperty">qb:parentChildProperty</dfn></code>
- ( <em>Domain:</em>
- <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>
- -> <em>Range:</em>
- <code>rdf:Property</code>
- )
- </dt>
- <dd>Specifies a property which relates a parent concept in the hierarchy to a child concept. Note that a child may have more than one parent.</dd>
-
-<!--
- <dt id="ref_qb_AggregatableHierarchy">
- <em>Class:</em> <code><dfn>qb:AggregatableHierarchy</dfn></code>
- </dt>
- <dd>Indicates a hierarchy in which each parent concept is a disjoint union of its child concepts. So that measures such as simple counts may be aggregated up the hierarchy.</dd>
--->
-
-</dl>
-</section>
-
-</section>
-
-
-<section id="acknowledgements" class="appendix">
-<!--OddPage--><h2><span class="secno">A. </span>Acknowledgements</h2>
-
-<p>This work is based on a collaboration that was initiated in a
-workshop on Publishing statistical datasets in SDMX and the semantic
-web, hosted by ONS in Sunningdale, United Kingdom in February 2010 and
-continued at the ODaF 2010 workshop in Tilburg. The authors would like
-to thank all the participants at those workshops for their input into
-this work but especially Arofan Gregory for his patient
-explanations of SDMX and insight in the need and requirements
-for a core Data Cube representation.</p>
-
-<p>The editors would like to thank John Sheridan for his comments,
-suggestions and support for the original work.</p>
-
-<p>Many individuals provided valuable comments on this specification
-as it made its way through the <abbr title="World Wide Web Consortium">W3C</abbr> process. We would like to
-especially acknowledge the contributions of
-Benedikt Kaempgen, Sarven Capadisli and Curran Kelleher.</p>
-
-</section>
-
-<section id="change-history" class="appendix">
-<!--OddPage--><h2><span class="secno">B. </span>Change history </h2>
-
-Changes since <a href="http://www.w3.org/TR/2012/WD-vocab-data-cube-20120405/"><abbr title="World Wide Web Consortium">W3C</abbr> Working Draft 5 April 2012</a>:
-
-<ul>
- <li>Added <a href="#wf">section</a> on criteria for well-formed cubes. <a href="http://www.w3.org/2011/gld/track/issues/29">ISSUE-29</a></li>
- <li>Added <a href="#normalize">section</a> on normalization algorithm
- for handling abbreviated cubes.</li>
- <li>Added <a href="#conformance">conformance section</a>.
- </li><li>Clarified that <code><a href="#dfn-qb-componentrequired" class="internalDFN">qb:componentRequired</a></code> is only applicable to
- attributes and that it defaults to optional.</li>
- <li>Moved vocabulary reference into the normative body of the specification, adding hyperlinks for all qb: terms.</li>
- <li>Added <a href="#schemes-hierarchy-nonskos">section</a> on non-skos hierarchies. <a href="http://www.w3.org/2011/gld/track/issues/31">ISSUE-31</a>.</li>
- <li>Added <a href="#schemes-aggregation">note</a> that aggregation operations and inter-cube relations are out of scope for this version. <a href="http://www.w3.org/2011/gld/track/issues/30">ISSUE-30</a>.</li>
- <li>Added <code><a href="#dfn-qb-observationgroup" class="internalDFN">qb:ObservationGroup</a></code> as a generalization of <code><a href="#dfn-qb-slice" class="internalDFN">qb:Slice</a></code>. <a href="http://www.w3.org/2011/gld/track/issues/33">ISSUE-33</a>.</li>
- <li>Removed <code><a>qb:subSlice</a></code> as being problematic in how
- they interact with attachment levels. <a href="http://www.w3.org/2011/gld/track/issues/34">ISSUE-34</a>.</li>
- <li>Generalized range of <code><a href="#dfn-qb-codelist" class="internalDFN">qb:codeList</a></code> to allow <code>skos:Collection</code>. <a href="http://www.w3.org/2011/gld/track/issues/39">ISSUE-39</a>.</li>
- <li>Moved namespace definitions to a normative <a href="#namespaces">section</a> within the body of the specification.</li>
- <li>Moved Jeni Tennison from being listed as an author to being a
- contributor. </li>
-</ul>
-
-
-</section>
-
-<section id="references_section" class="appendix">
-</section>
-
-
-
-<section id="references" class="appendix"><!--OddPage--><h2><span class="secno">C. </span>References</h2><section id="normative-references"><h3><span class="secno">C.1 </span>Normative references</h3><dl class="bibliography"><dt id="bib-DC11">[DC11]</dt><dd>Dublin Core metadata initiative. <a href="http://dublincore.org/documents/dcmi-terms/"><cite>Dublin Core metadata element set, version 1.1.</cite></a> July 1999. Dublin Core recommendation. URL: <a href="http://dublincore.org/documents/dcmi-terms/">http://dublincore.org/documents/dcmi-terms/</a>
-</dd><dt id="bib-OWL2-PRIMER">[OWL2-PRIMER]</dt><dd>Pascal Hitzler; Markus Krötzsch; Bijan Parsia; Peter F. Patel-Schneider; Sebastian Rudolph. <a href="http://www.w3.org/TR/2009/REC-owl2-primer-20091027/"><cite>OWL 2 Web Ontology Language:Primer.</cite></a> 27 October 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-owl2-primer-20091027/">http://www.w3.org/TR/2009/REC-owl2-primer-20091027/</a>
-</dd><dt id="bib-RDF-CONCEPTS">[RDF-CONCEPTS]</dt><dd>Graham Klyne; Jeremy J. Carroll. <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210"><cite>Resource Description Framework (RDF): Concepts and Abstract Syntax.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-concepts-20040210">http://www.w3.org/TR/2004/REC-rdf-concepts-20040210</a>
-</dd><dt id="bib-RDF-MT">[RDF-MT]</dt><dd>Patrick Hayes. <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210"><cite>RDF Semantics.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-mt-20040210">http://www.w3.org/TR/2004/REC-rdf-mt-20040210</a>
-</dd><dt id="bib-RDF-PRIMER">[RDF-PRIMER]</dt><dd>Frank Manola; Eric Miller. <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/"><cite>RDF Primer.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-primer-20040210/">http://www.w3.org/TR/2004/REC-rdf-primer-20040210/</a>
-</dd><dt id="bib-RDF-SCHEMA">[RDF-SCHEMA]</dt><dd>Dan Brickley; Ramanathan V. Guha. <a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210"><cite>RDF Vocabulary Description Language 1.0: RDF Schema.</cite></a> 10 February 2004. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2004/REC-rdf-schema-20040210">http://www.w3.org/TR/2004/REC-rdf-schema-20040210</a>
-</dd><dt id="bib-RFC2119">[RFC2119]</dt><dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for use in RFCs to Indicate Requirement Levels.</cite></a> March 1997. Internet RFC 2119. URL: <a href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>
-</dd><dt id="bib-SKOS-REFERENCE">[SKOS-REFERENCE]</dt><dd>Sean Bechhofer; Alistair Miles. <a href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/"><cite>SKOS Simple Knowledge Organization System Reference.</cite></a> 18 August 2009. W3C Recommendation. URL: <a href="http://www.w3.org/TR/2009/REC-skos-reference-20090818/">http://www.w3.org/TR/2009/REC-skos-reference-20090818/</a>
-</dd><dt id="bib-SPARQL-QUERY-11">[SPARQL-QUERY-11]</dt><dd>Steve Harris; Andy Seaborne. <a href="http://www.w3.org/TR/2012/PR-sparql11-query-20121108/"><cite>SPARQL 1.1 Query Language</cite></a> 8 November 2012. W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/2012/PR-sparql11-query-20121108/">http://www.w3.org/TR/2012/PR-sparql11-query-20121108/</a>
-</dd><dt id="bib-SPARQL-UPDATE-11">[SPARQL-UPDATE-11]</dt><dd>Paul Gearon; Alexandre Passant; Axel Polleres. <a href="http://www.w3.org/TR/2012/PR-sparql11-update-20121108/"><cite>SPARQL 1.1 Update</cite></a> 8 November 2012. W3C Proposed Recommendation. URL: <a href="http://www.w3.org/TR/2012/PR-sparql11-update-20121108/">http://www.w3.org/TR/2012/PR-sparql11-update-20121108/</a>
-</dd><dt id="bib-TURTLE-TR">[TURTLE-TR]</dt><dd>Eric Prud'hommeaux, Gavin Carothers. <a href="http://www.w3.org/TR/2013/CR-turtle-20130219/"><cite>Turtle: Terse RDF Triple Language.</cite></a> 19 February 2013. W3C Candidate Recommendation. URL: <a href="http://www.w3.org/TR/2013/CR-turtle-20130219/">http://www.w3.org/TR/2013/CR-turtle-20130219/</a>
-</dd></dl></section><section id="informative-references"><h3><span class="secno">C.2 </span>Informative references</h3><dl class="bibliography"><dt id="bib-COG">[COG]</dt><dd>SDMX Contnent Oriented Guidelines, <a href="http://sdmx.org/?page_id=11">http://sdmx.org/?page_id=11</a>
-</dd><dt id="bib-DCAT">[DCAT]</dt><dd>Fadi Maali; John Erickson; Phil Archer. <a href="http://www.w3.org/TR/vocab-dcat/"><cite>Data Catalog Vocabulary (DCAT)</cite></a> W3C Working Draft. 12 March 2013. URL: <a href="http://www.w3.org/TR/vocab-dcat/">http://www.w3.org/TR/vocab-dcat/</a>
-</dd><dt id="bib-FOAF">[FOAF]</dt><dd>Dan Brickley, Libby Miller. <a href="http://xmlns.com/foaf/spec/"><cite>FOAF Vocabulary Specification 0.98.</cite></a> 9 August 2010. URL: <a href="http://xmlns.com/foaf/spec/">http://xmlns.com/foaf/spec/</a>
-</dd><dt id="bib-LOD">[LOD]</dt><dd>Linked Data, <a href="http://linkeddata.org/">http://linkeddata.org/</a>
-</dd><dt id="bib-OLAP">[OLAP]</dt><dd>Online Analytical Processing Data Cubes, <a href="http://en.wikipedia.org/wiki/OLAP_cube">http://en.wikipedia.org/wiki/OLAP_cube</a>
-</dd><dt id="bib-ORG">[ORG]</dt><dd>An Organization Ontology, <a href="http://www.epimorphics.com/public/vocabulary/org.html">http://www.epimorphics.com/public/vocabulary/org.html</a>
-</dd><dt id="bib-OS-GEO">[OS-GEO]</dt><dd>Ordnance Survey Administrative Geography Ontology, <a href="http://data.ordnancesurvey.co.uk/ontology/admingeo/">http://data.ordnancesurvey.co.uk/ontology/admingeo/</a>
-</dd><dt id="bib-SCOVO">[SCOVO]</dt><dd>The Statistical Core Vocabulary, <a href="http://sw.joanneum.at/scovo/schema.html">http://sw.joanneum.at/scovo/schema.html</a><br>SCOVO: Using Statistics on the Web of data, <a href="http://sw-app.org/pub/eswc09-inuse-scovo.pdf">http://sw-app.org/pub/eswc09-inuse-scovo.pdf</a>
-</dd><dt id="bib-SDMX20">[SDMX20]</dt><dd>SDMX Information Model: UML Conceptual Design (Version 2.0), November 2005, Statistical Data and Metadata Exchange Initiative. URL: <a href="http://sdmx.org/docs/2_0/SDMX_2_0%20SECTION_02_InformationModel.pdf">http://sdmx.org/docs/2_0/SDMX_2_0%20SECTION_02_InformationModel.pdf</a>
-</dd><dt id="bib-SKOS-PRIMER">[SKOS-PRIMER]</dt><dd>Antoine Isaac; Ed Summers. <a href="http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/"><cite>SKOS Simple Knowledge Organization System Primer.</cite></a> 18 August 2009. W3C Note. URL: <a href="http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/">http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/</a>
-</dd><dt id="bib-VOID">[VOID]</dt><dd>Keith Alexander; Richard Cyganiak; Michael Hausenblas; Jun Zhao. <a href="http://www.w3.org/TR/void/"><cite>Describing Linked Datasets with the VoID Vocabulary</cite></a> 03 March 2011. Interest Group Note. URL: <a href="http://www.w3.org/TR/void/">http://www.w3.org/TR/void/</a>
-</dd></dl></section></section></body></html>