--- /dev/null Thu Jan 01 00:00:00 1970 +0000
+++ b/data-cube/static.html Thu Mar 29 15:38:30 2012 +0100
@@ -0,0 +1,2288 @@
+<html><head>
+<meta http-equiv="content-type" content="text/html; charset=UTF-8"></head><body><pre><?xml version='1.0' encoding='UTF-8'?>
+<!DOCTYPE html PUBLIC '-//W3C//DTD XHTML+RDFa 1.1//EN' 'http://www.w3.org/MarkUp/DTD/xhtml-rdfa-2.dtd'>
+<html xmlns="http://www.w3.org/1999/xhtml" dir="ltr">
+<head>
+ <title>The RDF Data Cube Vocabulary</title>
+ <meta content="text/html; charset=utf-8" http-equiv="Content-Type" />
+
+
+
+ <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; }
+ </style>
+<style type="text/css">
+/*****************************************************************
+ * ReSpec CSS
+ * Robin Berjon (robin at berjon dot com)
+ * v0.05 - 2009-07-31
+ *****************************************************************/
+
+
+/* --- 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;
+}
+
+code {
+ color: #ff4500;
+}
+
+
+/* --- WEB IDL --- */
+pre.idl {
+ border-top: 1px solid #90b8de;
+ border-bottom: 1px solid #90b8de;
+ padding: 1em;
+ line-height: 120%;
+}
+
+pre.idl::before {
+ content: "WebIDL";
+ display: block;
+ width: 150px;
+ background: #90b8de;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+.idlType {
+ color: #ff4500;
+ font-weight: bold;
+ text-decoration: none;
+}
+
+/*.idlModule*/
+/*.idlModuleID*/
+/*.idlInterface*/
+.idlInterfaceID, .idlDictionaryID {
+ font-weight: bold;
+ color: #005a9c;
+}
+
+.idlSuperclass {
+ font-style: italic;
+ color: #005a9c;
+}
+
+/*.idlAttribute*/
+.idlAttrType, .idlFieldType, .idlMemberType {
+ color: #005a9c;
+}
+.idlAttrName, .idlFieldName, .idlMemberName {
+ color: #ff4500;
+}
+.idlAttrName a, .idlFieldName a, .idlMemberName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlMethod*/
+.idlMethType {
+ color: #005a9c;
+}
+.idlMethName {
+ color: #ff4500;
+}
+.idlMethName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlParam*/
+.idlParamType {
+ color: #005a9c;
+}
+.idlParamName {
+ font-style: italic;
+}
+
+.extAttr {
+ color: #666;
+}
+
+/*.idlConst*/
+.idlConstType {
+ color: #005a9c;
+}
+.idlConstName {
+ color: #ff4500;
+}
+.idlConstName a {
+ color: #ff4500;
+ border-bottom: 1px dotted #ff4500;
+ text-decoration: none;
+}
+
+/*.idlException*/
+.idlExceptionID {
+ font-weight: bold;
+ color: #c00;
+}
+
+.idlTypedefID, .idlTypedefType {
+ color: #005a9c;
+}
+
+.idlRaises, .idlRaises a.idlType, .idlRaises a.idlType code, .excName a, .excName a code {
+ color: #c00;
+ font-weight: normal;
+}
+
+.excName a {
+ font-family: monospace;
+}
+
+.idlRaises a.idlType, .excName a.idlType {
+ border-bottom: 1px dotted #c00;
+}
+
+.excGetSetTrue, .excGetSetFalse, .prmNullTrue, .prmNullFalse, .prmOptTrue, .prmOptFalse {
+ width: 45px;
+ text-align: center;
+}
+.excGetSetTrue, .prmNullTrue, .prmOptTrue { color: #0c0; }
+.excGetSetFalse, .prmNullFalse, .prmOptFalse { color: #c00; }
+
+.idlImplements a {
+ font-weight: bold;
+}
+
+dl.attributes, dl.methods, dl.constants, dl.fields, dl.dictionary-members {
+ margin-left: 2em;
+}
+
+.attributes dt, .methods dt, .constants dt, .fields dt, .dictionary-members dt {
+ font-weight: normal;
+}
+
+.attributes dt code, .methods dt code, .constants dt code, .fields dt code, .dictionary-members dt code {
+ font-weight: bold;
+ color: #000;
+ font-family: monospace;
+}
+
+.attributes dt code, .fields dt code, .dictionary-members dt code {
+ background: #ffffd2;
+}
+
+.attributes dt .idlAttrType code, .fields dt .idlFieldType code, .dictionary-members dt .idlMemberType code {
+ color: #005a9c;
+ background: transparent;
+ font-family: inherit;
+ font-weight: normal;
+ font-style: italic;
+}
+
+.methods dt code {
+ background: #d9e6f8;
+}
+
+.constants dt code {
+ background: #ddffd2;
+}
+
+.attributes dd, .methods dd, .constants dd, .fields dd, .dictionary-members dd {
+ margin-bottom: 1em;
+}
+
+table.parameters, table.exceptions {
+ border-spacing: 0;
+ border-collapse: collapse;
+ margin: 0.5em 0;
+ width: 100%;
+}
+table.parameters { border-bottom: 1px solid #90b8de; }
+table.exceptions { border-bottom: 1px solid #deb890; }
+
+.parameters th, .exceptions th {
+ color: #fff;
+ padding: 3px 5px;
+ text-align: left;
+ font-family: initial;
+ font-weight: normal;
+ text-shadow: #666 1px 1px 0;
+}
+.parameters th { background: #90b8de; }
+.exceptions th { background: #deb890; }
+
+.parameters td, .exceptions td {
+ padding: 3px 10px;
+ border-top: 1px solid #ddd;
+ vertical-align: top;
+}
+
+.parameters tr:first-child td, .exceptions tr:first-child td {
+ border-top: none;
+}
+
+.parameters td.prmName, .exceptions td.excName, .exceptions td.excCodeName {
+ width: 100px;
+}
+
+.parameters td.prmType {
+ width: 120px;
+}
+
+table.exceptions table {
+ border-spacing: 0;
+ border-collapse: collapse;
+ width: 100%;
+}
+
+/* --- TOC --- */
+.toc a {
+ text-decoration: none;
+}
+
+a .secno {
+ color: #000;
+}
+
+/* --- 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;
+}
+
+/* --- EXAMPLES --- */
+pre.example {
+ border-top: 1px solid #ff4500;
+ border-bottom: 1px solid #ff4500;
+ padding: 1em;
+ margin-top: 1em;
+}
+
+pre.example::before {
+ content: "Example";
+ display: block;
+ width: 150px;
+ background: #ff4500;
+ color: #fff;
+ font-family: initial;
+ padding: 3px;
+ font-weight: bold;
+ margin: -1em 0 1em -1em;
+}
+
+/* --- EDITORIAL NOTES --- */
+.issue {
+ padding: 1em;
+ margin: 1em 0em 0em;
+ border: 1px solid #f00;
+ background: #ffc;
+}
+
+.issue::before {
+ content: "Issue";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #f00;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+.note {
+ margin: 1em 0em 0em;
+ padding: 1em;
+ border: 2px solid #cff6d9;
+ background: #e2fff0;
+}
+
+.note::before {
+ content: "Note";
+ display: block;
+ width: 150px;
+ margin: -1.5em 0 0.5em 0;
+ font-weight: bold;
+ border: 1px solid #cff6d9;
+ background: #fff;
+ padding: 3px 1em;
+}
+
+/* --- Best Practices --- */
+div.practice {
+ border: solid #bebebe 1px;
+ margin: 2em 1em 1em 2em;
+}
+
+span.practicelab {
+ margin: 1.5em 0.5em 1em 1em;
+ font-weight: bold;
+ font-style: italic;
+}
+
+span.practicelab { background: #dfffff; }
+
+span.practicelab {
+ position: relative;
+ padding: 0 0.5em;
+ top: -1.5em;
+}
+
+p.practicedesc {
+ margin: 1.5em 0.5em 1em 1em;
+}
+
+@media screen {
+ p.practicedesc {
+ position: relative;
+ top: -2em;
+ padding: 0;
+ margin: 1.5em 0.5em -1em 1em;
+ }
+}
+
+/* --- SYNTAX HIGHLIGHTING --- */
+pre.sh_sourceCode {
+ background-color: white;
+ color: black;
+ font-style: normal;
+ font-weight: normal;
+}
+
+pre.sh_sourceCode .sh_keyword { color: #005a9c; font-weight: bold; } /* language keywords */
+pre.sh_sourceCode .sh_type { color: #666; } /* basic types */
+pre.sh_sourceCode .sh_usertype { color: teal; } /* user defined types */
+pre.sh_sourceCode .sh_string { color: red; font-family: monospace; } /* strings and chars */
+pre.sh_sourceCode .sh_regexp { color: orange; font-family: monospace; } /* regular expressions */
+pre.sh_sourceCode .sh_specialchar { color: #ffc0cb; font-family: monospace; } /* e.g., \n, \t, \\ */
+pre.sh_sourceCode .sh_comment { color: #A52A2A; font-style: italic; } /* comments */
+pre.sh_sourceCode .sh_number { color: purple; } /* literal numbers */
+pre.sh_sourceCode .sh_preproc { color: #00008B; font-weight: bold; } /* e.g., #include, import */
+pre.sh_sourceCode .sh_symbol { color: blue; } /* e.g., *, + */
+pre.sh_sourceCode .sh_function { color: black; font-weight: bold; } /* function calls and declarations */
+pre.sh_sourceCode .sh_cbracket { color: red; } /* block brackets (e.g., {, }) */
+pre.sh_sourceCode .sh_todo { font-weight: bold; background-color: #00FFFF; } /* TODO and FIXME */
+
+/* Predefined variables and functions (for instance glsl) */
+pre.sh_sourceCode .sh_predef_var { color: #00008B; }
+pre.sh_sourceCode .sh_predef_func { color: #00008B; font-weight: bold; }
+
+/* for OOP */
+pre.sh_sourceCode .sh_classname { color: teal; }
+
+/* line numbers (not yet implemented) */
+pre.sh_sourceCode .sh_linenum { display: none; }
+
+/* Internet related */
+pre.sh_sourceCode .sh_url { color: blue; text-decoration: underline; font-family: monospace; }
+
+/* for ChangeLog and Log files */
+pre.sh_sourceCode .sh_date { color: blue; font-weight: bold; }
+pre.sh_sourceCode .sh_time, pre.sh_sourceCode .sh_file { color: #00008B; font-weight: bold; }
+pre.sh_sourceCode .sh_ip, pre.sh_sourceCode .sh_name { color: #006400; }
+
+/* for Prolog, Perl... */
+pre.sh_sourceCode .sh_variable { color: #006400; }
+
+/* for LaTeX */
+pre.sh_sourceCode .sh_italics { color: #006400; font-style: italic; }
+pre.sh_sourceCode .sh_bold { color: #006400; font-weight: bold; }
+pre.sh_sourceCode .sh_underline { color: #006400; text-decoration: underline; }
+pre.sh_sourceCode .sh_fixed { color: green; font-family: monospace; }
+pre.sh_sourceCode .sh_argument { color: #006400; }
+pre.sh_sourceCode .sh_optionalargument { color: purple; }
+pre.sh_sourceCode .sh_math { color: orange; }
+pre.sh_sourceCode .sh_bibtex { color: blue; }
+
+/* for diffs */
+pre.sh_sourceCode .sh_oldfile { color: orange; }
+pre.sh_sourceCode .sh_newfile { color: #006400; }
+pre.sh_sourceCode .sh_difflines { color: blue; }
+
+/* for css */
+pre.sh_sourceCode .sh_selector { color: purple; }
+pre.sh_sourceCode .sh_property { color: blue; }
+pre.sh_sourceCode .sh_value { color: #006400; font-style: italic; }
+
+/* other */
+pre.sh_sourceCode .sh_section { color: black; font-weight: bold; }
+pre.sh_sourceCode .sh_paren { color: red; }
+pre.sh_sourceCode .sh_attribute { color: #006400; }
+
+</style><link href="http://www.w3.org/StyleSheets/TR/W3C-WD" rel="stylesheet" type="text/css" charset="utf-8" /></head>
+
+<body style="display: inherit;"><div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home" /></a></p><h1 id="title" class="title">The RDF Data Cube Vocabulary</h1><h2 id="w3c-working-draft-03-april-2012"><acronym title="World Wide Web Consortium">W3C</acronym> Working Draft 03 April 2012</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2012/WD-data-cube-20120403/">http://www.w3.org/TR/2012/WD-data-cube-20120403/</a></dd><dt>Latest published version:</dt><dd><a href="http://www.w3.org/TR/data-cube/">http://www.w3.org/TR/data-cube/</a></dd><dt>Latest editor's draft:</dt><dd><a href="http://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html">http://dvcs.w3.org/hg/gld/raw-file/default/data-cube/index.html</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>Author:</dt><dd><a href="http://www.jenitennison.com/blog/">Jeni Tennison</a>, <a href="http://www.tso.co.uk/">TSO</a></dd>
+</dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2012 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.eu/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. <acronym title="World Wide Web Consortium">W3C</acronym> <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>
+
+<div id="abstract" class="introductory section"><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 <acronym title="World Wide Web Consortium">W3C</acronym> <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.</p>
+</div><div class="introductory section" id="sotd"><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 <acronym title="World Wide Web Consortium">W3C</acronym> publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/"><acronym title="World Wide Web Consortium">W3C</acronym> technical reports index</a> at http://www.w3.org/TR/.</em></p><p>This document was published by the <a href="http://www.w3.org/2011/gld/">Government Linked Data Working Group</a> as a First Public Working Draft. This document is intended to become a <acronym title="World Wide Web Consortium">W3C</acronym> 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>). All feedback is welcome.</p><p>Publication as a Working Draft does not imply endorsement by the <acronym title="World Wide Web Consortium">W3C</acronym> 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 document was produced by a group operating under the <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>. <acronym title="World Wide Web Consortium">W3C</acronym> maintains a <a rel="disclosure" href="">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 <acronym title="World Wide Web Consortium">W3C</acronym> Patent Policy</a>.</p></div><div id="toc" class="section"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">1. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#intro-cube" class="tocxref"><span class="secno">1.1 </span>A Data Cube vocabulary</a></li><li class="tocline"><a href="#intro-rdf" class="tocxref"><span class="secno">1.2 </span>RDF and Linked Data</a></li><li class="tocline"><a href="#intro-sdmx" class="tocxref"><span class="secno">1.3 </span>SDMX and related standards</a></li><li class="tocline"><a href="#intro-scovo" class="tocxref"><span class="secno">1.4 </span>Relationship to SCOVO</a></li><li class="tocline"><a href="#intro-audience" class="tocxref"><span class="secno">1.5 </span>Audience and scope</a></li><li class="tocline"><a href="#intro-conventions" class="tocxref"><span class="secno">1.6 </span>Document conventions</a></li></ul></li><li class="tocline"><a href="#data-cubes" class="tocxref"><span class="secno">2. </span>Data cubes</a><ul class="toc"><li class="tocline"><a href="#cubes-model" class="tocxref"><span class="secno">2.1 </span>The cube model - dimensions, attributes, measures</a></li><li class="tocline"><a href="#cubes-slices" class="tocxref"><span class="secno">2.2 </span>Slices</a></li></ul></li><li class="tocline"><a href="#example" class="tocxref"><span class="secno">3. </span>An example</a></li><li class="tocline"><a href="#outline" class="tocxref"><span class="secno">4. </span>Outline of the vocabulary</a><ul class="toc"><li class="tocline"><a href="#index" class="tocxref"><span class="secno">4.1 </span>Vocabulary index</a></li></ul></li><li class="tocline"><a href="#dsd" class="tocxref"><span class="secno">5. </span>Creating data structure definitions</a><ul class="toc"><li class="tocline"><a href="#dsd-dimensions" class="tocxref"><span class="secno">5.1 </span>Dimensions, attributes and measures</a></li><li class="tocline"><a href="#dsd-cog" class="tocxref"><span class="secno">5.2 </span>Content oriented guidelines</a></li><li class="tocline"><a href="#dsd-example" class="tocxref"><span class="secno">5.3 </span>Example</a></li><li class="tocline"><a href="#dsd-dsd" class="tocxref"><span class="secno">5.4 </span>ComponentSpecifications and DataStructureDefinitions</a></li><li class="tocline"><a href="#dsd-mm" class="tocxref"><span class="secno">5.5 </span>Handling multiple measures</a><ul class="toc"><li class="tocline"><a href="#dsd-mm-obs" class="tocxref"><span class="secno">5.5.1 </span>Multi-measure observations</a></li><li class="tocline"><a href="#dsd-mm-dim" class="tocxref"><span class="secno">5.5.2 </span>Measure dimension</a></li></ul></li></ul></li><li class="tocline"><a href="#datasets" class="tocxref"><span class="secno">6. </span>Expressing data sets</a><ul class="toc"><li class="tocline"><a href="#dataset-basic" class="tocxref"><span class="secno">6.1 </span>Data sets and observations</a></li></ul></li><li class="tocline"><a href="#slices" class="tocxref"><span class="secno">7. </span>Slices</a></li><li class="tocline"><a href="#schemes" class="tocxref"><span class="secno">8. </span>Concept schemes and code lists</a></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="#namespaces-used-appendix" class="tocxref"><span class="secno">A. </span>Namespaces used in this document</a></li><li class="tocline"><a href="#vocab-reference" class="tocxref"><span class="secno">B. </span>Vocabulary reference</a><ul class="toc"><li class="tocline"><a href="#reference-datasets" class="tocxref"><span class="secno">B.1 </span>DataSets</a></li><li class="tocline"><a href="#reference-observations" class="tocxref"><span class="secno">B.2 </span>Observations</a></li><li class="tocline"><a href="#reference-slices" class="tocxref"><span class="secno">B.3 </span>Slices</a></li><li class="tocline"><a href="#reference-components" class="tocxref"><span class="secno">B.4 </span>Dimensions, Attributes, Measures</a></li><li class="tocline"><a href="#reference-component-properties" class="tocxref"><span class="secno">B.5 </span>Reusable general purpose component properties</a></li><li class="tocline"><a href="#reference-dsd" class="tocxref"><span class="secno">B.6 </span>Data Structure Definitions</a></li><li class="tocline"><a href="#reference-compspec" class="tocxref"><span class="secno">B.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">B.8 </span>Slice definitions</a></li><li class="tocline"><a href="#reference-concepts" class="tocxref"><span class="secno">B.9 </span>Concepts</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">C. </span>Acknowledgements</a></li><li class="tocline"><a href="#issues" class="tocxref"><span class="secno">D. </span>Open issues</a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">E. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">E.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">E.2 </span>Informative references</a></li></ul></li></ul></div>
+
+<div id="introduction" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">1. </span>Introduction</h2>
+
+<div id="intro-cube" class="section">
+<h3><span class="secno">1.1 </span>A Data Cube vocabulary</h3>
+
+<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 the <acronym title="World Wide Web Consortium">W3C</acronym> <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" rel="biblioentry" 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 &quot;micro-data&quot;, 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://rdfs.org/ns/void-guide">VoiD</a> for data access</li>
+ <li><a href="http://xmlns.com/foaf/0.1/">FOAF</a> for organisations</li>
+ <li><a href="http://purl.org/dc/terms/">Dublin Core Terms</a> for
+metadata</li>
+</ul>
+</div>
+
+
+<div id="intro-rdf" class="section">
+<h3><span class="secno">1.2 </span>RDF and Linked Data</h3>
+
+<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" rel="biblioentry" 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" rel="biblioentry" 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>
+</div>
+
+
+<div id="intro-sdmx" class="section">
+<h3><span class="secno">1.3 </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.
+The Data Cube vocabulary builds upon the core of the SDMX information
+model.
+</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. RDF versions of these
+terms are available separately for use along with the Data Cube
+vocabulary.
+</p>
+</div>
+
+
+<div id="intro-scovo" class="section">
+<h3><span class="secno">1.4 </span>Relationship to SCOVO</h3>
+
+<p>The Statistical Core Vocabulary (SCOVO) [<cite><a class="bibref" rel="biblioentry" href="#bib-SCOVO">SCOVO</a></cite>] is a lightweight
+RDF vocabulary for expressing statistical data. Its relative
+simplicity allows easy adoption by data producers and consumers, and
+it can be combined with other RDF vocabularies for greater effect. The
+model is extensible both on the schema and the instance level for more
+specialized use cases.</p>
+<p>While SCOVO addresses the basic use case of expressing statistical
+data in RDF, its minimalist design is limiting, and it does not
+support important scenarios that occur in statistical publishing, such
+as:</p>
+
+<ul>
+ <li>definition and publication of the structure of a dataset
+independent from concrete data,</li>
+ <li>data flows which group together datasets that share the same
+structure, for example from different national data providers,</li>
+ <li>definition of &quot;slices&quot; through a dataset, such as an individual
+time series or cross-section, for individual annotation,</li>
+ <li>distinctions between dimensions, attributes and measures.</li>
+</ul>
+
+<p>
+The design of the Data Cube vocabulary is informed by SCOVO,
+and every SCOVO dataset can be re-expressed within the vocabulary.
+</p>
+</div>
+
+
+<div id="intro-audience" class="section">
+<h3><span class="secno">1.5 </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 will be covered elsewhere.</p>
+</div>
+
+
+<div id="intro-conventions" class="section">
+<h3><span class="secno">1.6 </span>Document conventions</h3>
+
+<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 namesapce identified by the prefix is
+ prepended to the <code>localname</code> to obtain the full URI.
+</p>
+
+<p>
+In this document we shall use the conventional prefix names for the
+<a href="#namespaces-used-appendix">well-known namespaces</a>:
+</p>
+<ul>
+ <li><code>rdf, rdfs</code> -- the core RDF namespaces</li>
+ <li><code>dc</code> -- Dublin Core</li>
+ <li><code>skos</code> -- Simple Knowledge Organization System</li>
+ <li><code>foaf</code> -- Friend Of A Friend</li>
+ <li><code>void</code> -- Vocabulary of Interlinked Datasets</li>
+ <li><code>scovo</code> -- Statistical Core Vocabulary</li>
+</ul>
+<p>We also introduce the prefix <code>qb</code> for the Data Cube
+ namespace <a href="http://purl.org/linked-data/cube#">http://purl.org/linked-data/cube#</a>.</p>
+
+<p>All RDF examples are written in Turtle syntax [<cite><a class="bibref" rel="biblioentry" href="#bib-TURTLE-TR">TURTLE-TR</a></cite>].</p>
+</div>
+
+</div>
+
+
+<div id="data-cubes" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">2. </span>Data cubes</h2>
+
+
+<div id="cubes-model" class="section">
+<h3><span class="secno">2.1 </span>The cube model - dimensions, attributes, measures</h3>
+
+<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
+measures, any scaling factors and metadata such as the status
+of the observation (e.g. <em>estimated</em>, <em>provisional</em>).</p>
+</div>
+
+
+<div id="cubes-slices" class="section">
+<h3><span class="secno">2.2 </span>Slices</h3>
+
+<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 but
+extension vocabularies, such as SDMX-RDF, can easily add such
+concept labels.</p>
+</div>
+
+</div>
+
+<div id="example" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">3. </span>An example</h2>
+
+<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 cellspacing="0" cellpadding="2" border="1" style="text-align: left; width: 80%;">
+ <tbody>
+ <tr>
+ <td style="vertical-align: top;"><br />
+ </td>
+ <td style="vertical-align: top; text-align: center; font-weight: bold;" rowspan="1" colspan="2">2004-2006<br />
+ </td>
+ <td style="vertical-align: top; text-align: center; font-weight: bold;" rowspan="1" colspan="2">2005-2007<br />
+ </td>
+ <td style="vertical-align: top; text-align: center; font-weight: bold;" rowspan="1" colspan="2">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>
+
+</div>
+
+
+<div id="outline" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">4. </span>Outline of the vocabulary</h2>
+
+<img src="images/qb-fig1.png" />
+
+<div id="index" class="section">
+<h3><span class="secno">4.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_SliceKey">qb:SliceKey</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">qb:componentProperty</a>
+ <a href="#ref_qb_componentRequired">qb:componentRequired</a>
+ <a href="#ref_qb_concept">qb:concept</a>
+ <a href="#ref_qb_dataSet">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">qb:observation</a>
+ <a href="#ref_qb_order">qb:order</a>
+ <a href="#ref_qb_slice">qb:slice</a>
+ <a href="#ref_qb_sliceKey">qb:sliceKey</a>
+ <a href="#ref_qb_sliceStructure">qb:sliceStructure</a>
+ <a href="#ref_qb_structure">qb:structure</a>
+ <a href="#ref_qb_subSlice">qb:subSlice</a>
+ </p>
+</div>
+
+</div>
+
+
+<div id="dsd" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">5. </span>Creating data structure definitions</h2>
+
+<p>A <code>qb:DataStructureDefinition</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>
+
+<div id="dsd-dimensions" class="section">
+<h3><span class="secno">5.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>qb:ComponentProperty</code>
+ class, which in turn has sub-classes <code>qb:DimensionProperty</code>,
+ <code>qb:AttributeProperty</code> and <code>qb:MeasureProperty</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>qb:concept</code> property which
+ links a <code>qb:ComponentProperty</code> to the concept it represents. We use the SKOS
+ vocabulary [<cite><a class="bibref" rel="biblioentry" 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>qb:ComponentProperty</code>. However, if
+ such reuse is not expected then it is not required to do so - the <code>qb:concept</code>
+ link is optional and a simple instance of the appropriate subclass of <code>qb:ComponentProperty</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>qb:codeList</code> denoting a <code>skos:ConceptScheme</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 the SDMX extension vocabulary there is one further item of information to encode
+ about components - the role that they play within the structure definition. In particular, 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 is 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. In cases where such roles are appropriate then we
+ encourage applications of the data cube vocabulary to also supply the relevant SDMX-derived role
+ information.</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>
+</div>
+
+<div id="dsd-cog" class="section">
+<h3><span class="secno">5.2 </span>Content oriented guidelines</h3>
+
+<p>The SDMX standard includes a set of <em>content oriented guidelines</em> (COG) [<cite><a class="bibref" rel="biblioentry" 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. As part of the data cube work we have created RDF analogues
+ to the COG. These include:</p>
+ <ul>
+ <li><code>sdmx-concept</code>: SKOS Concepts for each COG defined concept;</li>
+ <li><code>sdmx-code</code>: SKOS Concepts and ConceptSchemes for each COG defined code list;</li>
+ <li><code>sdmx-dimension</code>: component properties corresponding to each COG concept that can be used as a dimension;</li>
+ <li><code>sdmx-attribute</code>: component properties corresponding to each COG concept that can be used as a attribute;</li>
+ <li><code>sdmx-measure</code>: component properties corresponding to each COG concept that can be used as a measure.</li>
+ </ul>
+
+<p>The data cube vocabulary is standalone and it is not mandatory to use the SDMX COG-derived
+ terms. However, when the concepts being expressed do match a COG concept it is recommended
+ that publishers should reuse the corresponding components and/or concept URIs to simplify comparisons
+ across data sets. Given this background we will reuse the relevant COG components in our worked example.</p>
+</div>
+
+
+<div id="dsd-example" class="section">
+<h3><span class="secno">5.3 </span>Example</h3>
+
+<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>
+
+<pre> eg:refPeriod a rdf:Property, qb:DimensionProperty;
+ rdfs:label &quot;reference period&quot;@en;
+ rdfs:subPropertyOf sdmx-dimension:refPeriod;
+ rdfs:range interval:Interval;
+ qb:concept sdmx-concept:refPeriod . </pre>
+
+<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 Ordanance Survey administrative geography ontology [<cite><a class="bibref" rel="biblioentry" href="#bib-OS-GEO">OS-GEO</a></cite>].</p>
+
+<pre> eg:refArea a rdf:Property, qb:DimensionProperty;
+ rdfs:label &quot;reference area&quot;@en;
+ rdfs:subPropertyOf sdmx-dimension:refArea;
+ rdfs:range admingeo:UnitaryAuthority;
+ qb:concept sdmx-concept:refArea . </pre>
+
+<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>
+
+<pre> eg:lifeExpectancy a rdf:Property, qb:MeasureProperty;
+ rdfs:label &quot;life expectancy&quot;@en;
+ rdfs:subPropertyOf sdmx-measure:obsValue;
+ rdfs:range xsd:decimal . </pre>
+
+<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 &quot;Years&quot;.</p>
+
+<p>This covers the minimal components needed to define the structure of this data set.</p>
+</div>
+
+
+<div id="dsd-dsd" class="section">
+<h3><span class="secno">5.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>qb:DataStuctureDefinition</code>
+ resource which in turn will reference a set of <code>qb:ComponentSpecification</code> resources.
+ The <code>qb:DataStuctureDefinition</code> will be reusable across other data sets with the same structure.</p>
+
+<p>In the simplest case the <code>qb:ComponentSpecification</code> simply references the
+ corresponding <code>qb:ComponentProperty</code> (ususally using one of the sub properties
+ <code>qb:dimension</code>, <code>qb:measure</code> or <code>qb:attribute</code>).
+ However, it is also possible to qualify the
+ component specification in several ways.</p>
+
+<ul>
+ <li>An Attribute may be optional in which case the specification should set
+ <code>qb:componentRequired &quot;false&quot;^^xsd:boolean.</code></li>
+ <li>The components may be ordered by giving an integer value for <code>qb:order</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,
+ a so called <em>flattened</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 a
+ non-flat structure, the <code>qb:componentAttachment</code> property of the specification should
+ reference the class corresponding to the attachment level (e.g. <code>qb:DataSet</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 interests of illustrating the vocabulary
+ use we will declare that this attribute will be attached at the level of the data set, however
+ flattened 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>
+
+<pre> 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:componentAttachment qb:DataSet;] .</pre>
+
+<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 the represent
+ them using blank nodes.
+</p>
+</div>
+
+
+<div id="dsd-mm" class="section">
+<h3><span class="secno">5.5 </span>Handling multiple measures</h3>
+
+<p>Our example data set is relatively simple in having a single observable (in this case &quot;life expectancy&quot;)
+ 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 &quot;cell&quot; 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>
+
+
+<div id="dsd-mm-obs" class="section">
+<h4><span class="secno">5.5.1 </span>Multi-measure observations</h4>
+
+<p> This approach allows multiple observed values to be attached
+ to an individual observation. Is suited to representation of things like sensor data and OLAP cubes.
+ To use this representation you simply declare multiple <code>qb:MeasureProperty</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>
+<pre>eg:dsd1 a qb:DataStructureDefinition;
+ rdfs:comment &quot;shipments by time (multiple measures approach)&quot;@en;
+ qb:component
+ [ qb:dimension sdmx-dimension:refTime; ],
+ [ qb:measure eg-measure:quantity; ],
+ [ qb:measure eg-measure:weight; ] . </pre>
+
+<p>This would correspond to individual observations such as:</p>
+<pre>eg:dataset1 a qb:DataSet;
+ qb:structure eg:dsd1 .
+
+eg:obs1a a qb:Observation;
+ qb:dataSet eg:dataset1;
+ sdmx-dimension:refTime &quot;30-07-2010&quot;^^xsd:date;
+ eg-measure:weight 1.3 ;
+ eg-measure:quantity 42 ;
+ . </pre>
+
+<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>qb:MeasureProperty</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>
+</div>
+
+
+<div id="dsd-mm-dim" class="section">
+<h4><span class="secno">5.5.2 </span>Measure dimension</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>qb:DataStructureDefinition</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>qb:measureType</code>.
+ Within the SDMX-in-RDF extension then there is a role used to identify concepts which
+ act as measure types, enabling other measure dimensions to be declared.
+ In the special case of using <code>qb:measureType</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, qb:measureType 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>
+<pre>eg:dsd2 a qb:DataStructureDefinition;
+ rdfs:comment &quot;shipments by time (measure dimension approach)&quot;@en;
+ qb:component
+ [ qb:dimension sdmx-dimension:refTime; ],
+ [ qb:measure eg-measure:quantity; ],
+ [ qb:measure eg-measure:weight; ],
+ [ qb:dimension qb:measureType; ] . </pre>
+
+<p>This would correspond to individual observations such as:</p>
+<pre>eg:dataset2 a qb:DataSet;
+ qb:structure eg:dsd2 .
+
+eg:obs2a a qb:Observation;
+ qb:dataSet eg:dataset2;
+ sdmx-dimension:refTime &quot;30-07-2010&quot;^^xsd:date;
+ qb:measureType eg-measure:weight ;
+ eg-measure:weight 1.3 .
+
+eg:obs2b a qb:Observation;
+ qb:dataSet eg:dataset2;
+ sdmx-dimension:refTime &quot;30-07-2010&quot;^^xsd:date;
+ qb:measureType eg-measure:quantity ;
+ eg-measure:quantity 42 . </pre>
+
+
+<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 &quot;primary measure&quot; which subsumes each of the individual
+ measures, those individual measures are used directly. The SDMX-in-RDF extension
+ vocabulary addresses the round-tripping of the SDMX primary measure by use of a
+ separate annotation on <code>sdmx:DataStructureDefinition</code>.</p>
+</div>
+
+</div>
+
+</div>
+
+
+<div id="datasets" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">6. </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="#cubes-slices">section 2.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>
+
+
+<div id="dataset-basic" class="section">
+<h3><span class="secno">6.1 </span>Data sets and observations</h3>
+
+<p>A resource representing the entire data set is created and typed as <code>qb:DataSet</code> and
+ linked to the corresponding data structure definition via the <tt>qb:structure</tt> property.</p>
+
+<p><strong>Pitfall</strong>: Note the capitalization of <tt>qb:<strong>D</strong>ata<strong>S</strong>et</tt>,
+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 <tt>qb:data<strong>S</strong>et</tt>.</p>
+
+<p>Each observation is represented as an instance of type <code>qb:Observation</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>qb:dataSet</code> property. For example:</p>
+
+<p>Thus for our running example we might expect to have:</p>
+
+<pre> eg:dataset-le1 a qb:DataSet;
+ rdfs:label &quot;Life expectancy&quot;@en;
+ rdfs:comment &quot;Life expectancy within Welsh Unitary authorities - extracted from Stats Wales&quot;@en;
+ qb:structure eg:dsd-le ;
+ .
+
+ eg:o1 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea admingeo:newport_00pr ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ eg:lifeExpectancy 76.7 ;
+ .
+
+ eg:o2 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea admingeo:cardiff_00pt ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ eg:lifeExpectancy 78.7 ;
+ .
+
+ eg:o3 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea admingeo:monmouthshire_00pp ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ eg:lifeExpectancy 76.6 ;
+ .
+
+ ...
+</pre>
+
+<p>This <em>flattened</em> 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 the corrected example is:</p>
+
+<pre> eg:dataset-le1 a qb:DataSet;
+ rdfs:label &quot;Life expectancy&quot;@en;
+ rdfs:comment &quot;Life expectancy within Welsh Unitary authorities - extracted from Stats Wales&quot;@en;
+ qb:structure eg:dsd-le ;
+ sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ .
+
+ eg:o1 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea admingeo:newport_00pr ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 76.7 ;
+ .
+
+ eg:o2 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea admingeo:cardiff_00pt ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 78.7 ;
+ .
+
+ eg:o3 a qb:Observation;
+ qb:dataSet eg:dataset-le1 ;
+ eg:refArea admingeo:monmouthshire_00pp ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 76.6 ;
+ .
+
+ ...
+</pre>
+
+<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>
+</div>
+
+</div>
+
+
+<div id="slices" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">7. </span>Slices</h2>
+
+<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 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. &quot;male life expectancy observations for 2004-6&quot;
+ 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 &quot;slice key&quot; which the
+ data structure definition. This is done by creating a <code>qb:SliceKey</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>qb:sliceKey</code>. For example: </p>
+
+<pre> eg:sliceByRegion a qb:SliceKey;
+ rdfs:label &quot;slice by region&quot;@en;
+ rdfs:comment &quot;Slice by grouping regions together, fixing sex and time values&quot;@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>
+
+<p>In the instance data then slices are represented by instances of <code>qb:Slice</code> which
+ link to the observations in the slice via <code>qb:observation</code> and to the key by means
+ of <code>qb:sliceStructure</code>. Data sets indicate
+ the slices they contain by means of <code>qb:slice</code>. Thus in our example we would have:</p>
+
+<pre> eg:dataset-le2 a qb:DataSet;
+ rdfs:label &quot;Life expectancy&quot;@en;
+ rdfs:comment &quot;Life expectancy within Welsh Unitary authorities - extracted from Stats Wales&quot;@en;
+ qb:structure eg:dsd-le-slice2 ;
+ sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ qb:slice eg:slice2;
+ .
+
+ eg:slice2 a qb:Slice;
+ qb:sliceStructure eg:sliceByRegion ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ 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 admingeo:newport_00pr ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 76.7 ;
+ .
+
+ eg:o2b a qb:Observation;
+ qb:dataSet eg:dataset-le2 ;
+ eg:refArea admingeo:cardiff_00pt ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 78.7 ;
+ .
+
+ eg:o3b a qb:Observation;
+ qb:dataSet eg:dataset-le2 ;
+ eg:refArea admingeo:monmouthshire_00pp ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ sdmx-dimension:sex sdmx-code:sex-M ;
+ eg:lifeExpectancy 76.6 ;
+ .
+
+ ...
+</pre>
+
+<p>Note that here we are still repeating the dimension values on the individual observations.
+This flattened 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>
+<pre> 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 &quot;Life expectancy&quot;@en;
+ rdfs:comment &quot;Life expectancy within Welsh Unitary authorities - extracted from Stats Wales&quot;@en;
+ qb:structure eg:dsd-le-slice3 ;
+ sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ qb:slice eg:slice3 ;
+ .
+
+ eg:slice3 a qb:Slice;
+ qb:sliceStructure eg:sliceByRegion ;
+ eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ 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 admingeo:newport_00pr ;
+ eg:lifeExpectancy 76.7 ;
+ .
+
+ eg:o2c a qb:Observation;
+ qb:dataSet eg:dataset-le3 ;
+ eg:refArea admingeo:cardiff_00pt ;
+ eg:lifeExpectancy 78.7 ;
+ .
+
+ eg:o3c a qb:Observation;
+ qb:dataSet eg:dataset-le3 ;
+ eg:refArea admingeo:monmouthshire_00pp ;
+ eg:lifeExpectancy 76.6 ;
+ .
+
+ ...
+</pre>
+
+<p>The Data Cube vocabulary allows slices to be nested. We can declare
+ multiple slice keys in a DSD and it is possible for one slice key to
+ be a narrower version of another, represented using <code>qb:subSlice</code>. In that case, when providing non-flattened
+ data with dimensions attached to the slice level, then
+ it is permissible to nest the <code>qb:Slice</code> instances and so
+ further reduce the duplication stating of dimension values. However,
+ in general flat representations are recommended to simplify data consumption.
+ Some tool chains may support (dynamic or static) generation flattened representations from
+ abbreviated data sets.</p>
+</div>
+
+
+<div id="schemes" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">8. </span>Concept schemes and code lists</h2>
+
+<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>.</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>
+
+<pre>sdmx-code:sex a skos:ConceptScheme;
+ skos:prefLabel &quot;Code list for Sex (SEX) - codelist scheme&quot;@en;
+ rdfs:label &quot;Code list for Sex (SEX) - codelist scheme&quot;@en;
+ skos:notation &quot;CL_SEX&quot;;
+ skos:note &quot;This code list provides the gender.&quot;@en;
+ skos:definition &lt;http://sdmx.org/wp-content/uploads/2009/01/02_sdmx_cog_annex_2_cl_2009.pdf&gt; ;
+ 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 &quot;Code list for Sex (SEX) - codelist class&quot;@en;
+ rdfs:comment &quot;This code list provides the gender.&quot;@en;
+ rdfs:seeAlso sdmx-code:sex .
+
+sdmx-code:sex-F a skos:Concept, sdmx-code:Sex;
+ skos:topConceptOf sdmx-code:sex;
+ skos:prefLabel &quot;Female&quot;@en ;
+ skos:notation &quot;F&quot; ;
+ skos:inScheme sdmx-code:sex .
+
+sdmx-code:sex-M a skos:Concept, sdmx-code:Sex;
+ skos:topConceptOf sdmx-code:sex;
+ skos:prefLabel &quot;Male&quot;@en ;
+ skos:notation &quot;M&quot; ;
+ skos:inScheme sdmx-code:sex .
+</pre>
+
+<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 [SKOS] 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 an Class to denote all the codes within the code
+list, irrespective of hierarchical structure. This allows the range of an
+<code>qb:ComponentProperty</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>
+
+<pre> eg:sex a sdmx:DimensionProperty, sdmx:CodedProperty;
+ qb:codeList sdmx-code:sex ;
+ rdfs:range sdmx-code:Sex .
+</pre>
+
+<p>Explicitly declaring the code list using <code>qb:codeList</code>
+ is not mandatory but can be helpful in those cases where a concept scheme has been defined.</p>
+
+<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 lists should 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>
+</div>
+
+
+<div id="metadata" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">9. </span>DataSet metadata</h2>
+
+<p>DataSets should be marked up with metadata to support discovery, presentation and
+processing. Metadata such as a display label (<code>rdfs:label</code>),
+descriptive comment (<code>rdfs:comment</code>) and creation date (<code>dcterms:date</code>)
+are common to most resources. We recommend use of Dublin Core Terms
+for representing the key metadata annotations commonly needed for DataSets.</p>
+
+
+<div id="metadata-categorization" class="section">
+<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>dcterms: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>
+
+<pre> eg:dataset1 a qb:DataSet;
+ rdfs:label &quot;Life expectancy&quot;@en;
+ rdfs:comment &quot;Life expectancy within Welsh Unitary authorities - extracted from Stats Wales&quot;@en;
+ dcterms:date &quot;2010-08-11&quot;^^xsd:date;
+ dcterms:subject
+ sdmx-subject:3.2 , # regional and small area statistics
+ sdmx-subject:1.4 , # Health
+ admingeo:wales_gor_l ; # Wales
+ ...
+</pre>
+
+<p>where <code>eg:Wales</code> is a <code>skos:Concept</code> drawn from an appropriate controlled
+vocabulary for places.</p>
+</div>
+
+
+<div id="metadata-publishers" class="section">
+<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>dcterms: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" rel="biblioentry" href="#bib-ORG">ORG</a></cite>].</p>
+
+<pre>eg:dataset1 a qb:DataSet;
+ dc:publisher &lt;http://example.com/meta#organization&gt; .
+
+&lt;http://example.com/meta#organization&gt; a org:Organization, foaf:Agent;
+ rdfs:label &quot;Example org&quot; .
+</pre>
+
+<p>Note that the SDMX extension vocabulary supports further description of
+ publication pipelines (data flows, reporting taxonomies, maintainers, provision agreements).</p>
+</div>
+
+</div>
+
+<div class="appendix section" id="namespaces-used-appendix">
+
+<!-- OddPage -->
+<h2><span class="secno">A. </span>Namespaces used in this document</h2>
+
+<table class="spare-table">
+ <thead> <tr>
+ <th>prefix</th>
+ <th>namespace URI</th>
+ <th>vocabulary</th>
+ </tr>
+ </thead>
+ <tbody>
+ <tr>
+ <td>rdf</td>
+ <td>http://www.w3.org/1999/02/22-rdf-syntax-ns#</td>
+ <td>RDF core</td>
+ </tr>
+ <tr>
+ <td>rdfs</td>
+ <td>http://www.w3.org/2000/01/rdf-schema#</td>
+ <td>RDF Schema</td>
+ </tr>
+ <tr>
+ <td>skos</td>
+ <td>http://www.w3.org/2004/02/skos/core#</td>
+ <td>Simple Knowledge Organization System</td>
+ </tr>
+ <tr>
+ <td>foaf</td>
+ <td>http://xmlns.com/foaf/0.1/</td>
+ <td>Friend Of A Friend</td>
+ </tr>
+ <tr>
+ <td>void</td>
+ <td>http://rdfs.org/ns/void#</td>
+ <td>Vocabulary of Interlinked Datasets</td>
+ </tr>
+ <tr>
+ <td>scovo</td>
+ <td>http://purl.org/NET/scovo#</td>
+ <td>Statistical Core Vocabulary</td>
+ </tr>
+ <tr>
+ <td>dc</td>
+ <td>http://purl.org/dc/elements/1.1/</td>
+ <td>Dublin Core</td>
+ </tr>
+ <tr>
+ <td>qb</td>
+ <td>http://purl.org/linked-data/cube#</td>
+ <td>The Data Cube vocabulary</td>
+ </tr>
+ </tbody>
+</table>
+</div>
+
+
+<div class="appendix section" id="vocab-reference">
+
+<!-- OddPage -->
+<h2><span class="secno">B. </span>Vocabulary reference</h2>
+
+
+<div id="reference-datasets" class="section">
+<h3><span class="secno">B.1 </span>DataSets</h3>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_DataSet">
+ <em>Class:</em> <code>qb:DataSet</code>
+ <em>Sub class of: </em>
+ <code>qb:Attachable</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>
+</div>
+
+
+<div id="reference-observations" class="section">
+<h3><span class="secno">B.2 </span>Observations</h3>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_Observation">
+ <em>Class:</em> <code>qb:Observation</code>
+ <em>Sub class of: </em>
+ <code>qb:Attachable</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">
+ <em>Property:</em> <code>qb:dataSet</code>
+ (
+ <code>qb:Observation</code>
+ -&gt;
+ <code>qb:DataSet</code>
+ )
+ </dt>
+ <dd>indicates the data set of which this observation is a part</dd>
+
+ <dt id="ref_qb_observation">
+ <em>Property:</em> <code>qb:observation</code>
+ (
+ <code>qb:Slice</code>
+ -&gt;
+ <code>qb:Observation</code>
+ )
+ </dt>
+ <dd>indicates a observation contained within this slice of the data set</dd>
+</dl>
+</div>
+
+
+<div id="reference-slices" class="section">
+<h3><span class="secno">B.3 </span>Slices</h3>
+
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_Slice">
+ <em>Class:</em> <code>qb:Slice</code>
+ <em>Sub class of: </em>
+ <code>qb:Attachable</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">
+ <em>Property:</em> <code>qb:slice</code>
+ (
+ <code>qb:DataSet</code>
+ -&gt;
+ <code>qb:Slice</code>
+ )
+ </dt>
+ <dd>Indicates a subset of a DataSet defined by fixing a subset of the dimensional values</dd>
+
+ <dt id="ref_qb_subSlice">
+ <em>Property:</em> <code>qb:subSlice</code>
+ (
+ <code>qb:Slice</code>
+ -&gt;
+ <code>qb:Slice</code>
+ )
+ </dt>
+ <dd>Indicates a narrower slice which has additional fixed dimensional values, for example a time-series slice might a subSlice of a slice which spans both time and geographic area</dd>
+</dl>
+</div>
+
+
+<div id="reference-components" class="section">
+<h3><span class="secno">B.4 </span>Dimensions, Attributes, Measures</h3>
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_Attachable">
+ <em>Class:</em> <code>qb:Attachable</code>
+ </dt>
+ <dd>Abstract superclass for everything that can have attributes and dimensions</dd>
+
+ <dt id="ref_qb_ComponentProperty">
+ <em>Class:</em> <code>qb:ComponentProperty</code>
+ <em>Sub class of: </em>
+ <code>rdf:Property</code>
+ </dt>
+ <dd>Abstract super-property of all properties representing dimensions, attributes or measures</dd>
+
+ <dt id="ref_qb_DimensionProperty">
+ <em>Class:</em> <code>qb:DimensionProperty</code>
+ <em>Sub class of: </em>
+ <code>qb:ComponentProperty</code>
+ <code>qb:CodedProperty</code>
+ </dt>
+ <dd>The class of components which represent the dimensions of the cube</dd>
+
+ <dt id="ref_qb_AttributeProperty">
+ <em>Class:</em> <code>qb:AttributeProperty</code>
+ <em>Sub class of: </em>
+ <code>qb:ComponentProperty</code>
+ </dt>
+ <dd>The class of components which represent attributes of observations in the cube, e.g. unit of measurement</dd>
+
+ <dt id="ref_qb_MeasureProperty">
+ <em>Class:</em> <code>qb:MeasureProperty</code>
+ <em>Sub class of: </em>
+ <code>qb:ComponentProperty</code>
+ </dt>
+ <dd>The class of components which represent the measured value of the phenomenon being observed</dd>
+
+ <dt id="ref_qb_CodedProperty">
+ <em>Class:</em> <code>qb:CodedProperty</code>
+ <em>Sub class of: </em>
+ <code>qb:ComponentProperty</code>
+ </dt>
+ <dd>Superclass of all coded ComponentProperties</dd>
+</dl>
+</div>
+
+
+<div id="reference-component-properties" class="section">
+<h3><span class="secno">B.5 </span>Reusable general purpose component properties</h3>
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_measureType">
+ <em>Property:</em> <code>qb:measureType</code>
+ (
+ -&gt;
+ <code>qb:MeasureProperty</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 obsValue (or other primary measure)</dd>
+</dl>
+</div>
+
+
+<div id="reference-dsd" class="section">
+<h3><span class="secno">B.6 </span>Data Structure Definitions</h3>
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_DataStructureDefinition">
+ <em>Class:</em> <code>qb:DataStructureDefinition</code>
+ <em>Sub class of: </em>
+ <code>qb:ComponentSet</code>
+ </dt>
+ <dd>Defines the structure of a DataSet or slice</dd>
+
+ <dt id="ref_qb_structure">
+ <em>Property:</em> <code>qb:structure</code>
+ (
+ <code>qb:DataSet</code>
+ -&gt;
+ <code>qb:DataStructureDefinition</code>
+ )
+ </dt>
+ <dd>indicates the structure to which this data set conforms</dd>
+
+ <dt id="ref_qb_component">
+ <em>Property:</em> <code>qb:component</code>
+ (
+ <code>qb:DataStructureDefinition</code>
+ -&gt;
+ <code>qb:ComponentSpecification</code>
+ )
+ </dt>
+ <dd>indicates a component specification which is included in the structure of the dataset</dd>
+</dl>
+</div>
+
+
+<div id="reference-compspec" class="section">
+<h3><span class="secno">B.7 </span>Component specifications - for qualifying component use in a DSD</h3>
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_ComponentSpecification">
+ <em>Class:</em> <code>qb:ComponentSpecification</code>
+ <em>Sub class of: </em>
+ <code>qb:ComponentSet</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>qb:ComponentSet</code>
+ </dt>
+ <dd>Abstract class of things which reference one or more ComponentProperties</dd>
+
+ <dt id="ref_qb_componentProperty">
+ <em>Property:</em> <code>qb:componentProperty</code>
+ (
+ <code>qb:ComponentSet</code>
+ -&gt;
+ <code>qb:ComponentProperty</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>qb:order</code>
+ (
+ <code>qb:ComponentSpecification</code>
+ -&gt;
+ <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>qb:componentRequired</code>
+ (
+ <code>qb:ComponentSpecification</code>
+ -&gt;
+ <code>xsd:boolean</code>
+ )
+ </dt>
+ <dd>Indicates whether a component property is required (true) or optional (false) in the context of a DSD or MSD</dd>
+
+ <dt id="ref_qb_componentAttachment">
+ <em>Property:</em> <code>qb:componentAttachment</code>
+ (
+ <code>qb:ComponentSpecification</code>
+ -&gt;
+ <code>rdfs:Class</code>
+ )
+ </dt>
+ <dd>Indicates the level at which the component property should be attached, this might an qb:DataSet, qb:Slice or qb:Observation, or a qb:MeasureProperty.</dd>
+
+ <dt id="ref_qb_dimension">
+ <em>Property:</em> <code>qb:dimension</code>
+ (
+ -&gt;
+ <code>qb:DimensionProperty</code>
+ ; <em>sub property of: </em>
+ <code>qb:componentProperty</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>qb:measure</code>
+ (
+ -&gt;
+ <code>qb:MeasureProperty</code>
+ ; <em>sub property of: </em>
+ <code>qb:componentProperty</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>qb:attribute</code>
+ (
+ -&gt;
+ <code>qb:AttributeProperty</code>
+ ; <em>sub property of: </em>
+ <code>qb:componentProperty</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>qb:measureDimension</code>
+ (
+ -&gt;
+ <code>qb:DimensionProperty</code>
+ ; <em>sub property of: </em>
+ <code>qb:componentProperty</code>
+ )
+ </dt>
+ <dd>An alternative to qb:componentProperty which makes explicit that the component is a measure dimension</dd>
+</dl>
+</div>
+
+
+<div id="reference-slice-definitions" class="section">
+<h3><span class="secno">B.8 </span>Slice definitions</h3>
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_SliceKey">
+ <em>Class:</em> <code>qb:SliceKey</code>
+ <em>Sub class of: </em>
+ <code>qb:ComponentSet</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>qb:sliceStructure</code>
+ (
+ <code>qb:Slice</code>
+ -&gt;
+ <code>qb:SliceKey</code>
+ )
+ </dt>
+ <dd>indicates the sub-key corresponding to this slice</dd>
+
+ <dt id="ref_qb_sliceKey">
+ <em>Property:</em> <code>qb:sliceKey</code>
+ (
+ <code>qb:DataSet</code>
+ -&gt;
+ <code>qb:SliceKey</code>
+ )
+ </dt>
+ <dd>indicates a slice key which is used for slices in this dataset</dd>
+</dl>
+</div>
+
+
+<div id="reference-concepts" class="section">
+<h3><span class="secno">B.9 </span>Concepts</h3>
+<dl class="vocab_reference">
+
+ <dt id="ref_qb_concept">
+ <em>Property:</em> <code>qb:concept</code>
+ (
+ <code>qb:ComponentProperty</code>
+ -&gt;
+ <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>qb:codeList</code>
+ (
+ <code>qb:CodedProperty</code>
+ -&gt;
+ <code>skos:ConceptScheme</code>
+ )
+ </dt>
+ <dd>gives the code list associated with a CodedProperty</dd>
+</dl>
+</div>
+
+</div>
+
+
+<div class="appendix section" id="acknowledgements">
+
+<!-- OddPage -->
+<h2><span class="secno">C. </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 authors would also like to thank John Sheridan for his comments,
+suggestions and support for this work.</p>
+</div>
+
+
+<div id="issues" class="section">
+
+<!-- OddPage -->
+<h2><span class="secno">D. </span>Open issues</h2>
+
+<p>
+ Based on early use experiences with the vocabulary the working group is considering
+ some clarifications and modifications to the specification. Each of
+ the candidate areas under consideration are listed as issues
+ below. Note that there is, as yet, no commitment that all (or indeed any) of these areas
+ will be addressed by the working group.
+</p>
+
+ <div class="issue">
+ <h3 id="issue-29------criteria-for-well-formedness"><a href="http://www.w3.org/2011/gld/track/issues/29">Issue-29</a>:
+ Criteria for well-formedness</h3>
+ <p>Specify additional <em>well-formedness</em> criteria to which
+ cube-publishers should adhere to facilitate tool interoperability.</p>
+ </div>
+
+ <div class="issue">
+ <h3 id="issue-30--------declaring-relations-between-cubes"><a href="http://www.w3.org/2011/gld/track/issues/30">Issue-30</a>:
+ Declaring relations between cubes</h3>
+ <p>Consider extending the vocabulary to support declaring
+ relations between data cubes (or between measures within a cube).</p>
+ </div>
+
+ <div class="issue">
+ <h3 id="issue-31--------supporting-aggregation-for-other-than-skos-hierarchies"><a href="http://www.w3.org/2011/gld/track/issues/31">Issue-31</a>:
+ Supporting aggregation for other than SKOS hierarchies</h3>
+ <p>The Data Cube vocabulary allows hierarchical code lists to be
+ used as dimensions values by means of SKOS. Consider whether to
+ extend this to support use of other hierarchical relations
+ (e.g. geo-spatial containment) without requiring mapping to SKOS.</p>
+ </div>
+
+ <div class="issue">
+ <h3 id="issue-32--------relationship-to-iso-19156---observations---measurements"><a href="http://www.w3.org/2011/gld/track/issues/32">Issue-32</a>:
+ Relationship to ISO 19156 - Observations &amp; Measurements</h3>
+ <p>
+ One use case for the Data Cube vocabulary is for the publication
+ of observational, sensor network and forecast data
+ sets. Existing standards for such publication include OGC
+ Observations &amp; Measurements (ISO 19156). There are multiple ways
+ that Data Cube can be mapped to the logical model of O&amp;M.
+ Consider making an explicit statement of the ways in which Data
+ Cube can be related to O&amp;M as guidance for users seeking to
+ work with both specifications.</p>
+ </div>
+
+ <div class="issue">
+ <h3 id="issue-33--------collections-of-observations-and-well-formedness-of-slices"><a href="http://www.w3.org/2011/gld/track/issues/33">Issue-33</a>:
+ Collections of observations and well-formedness of slices</h3>
+ <p>
+ Experience with Data Cube has shown that publishers often wish
+ to publish slices comprising arbitrary collections of
+ observations.
+ Consider supporting this usage, either through a clarification
+ of <code>qb:Slice</code> or through an additional collection mechanism.</p>
+ </div>
+
+ <div class="issue">
+ <h3 id="issue-34--------clarify-or-drop-qb-subslice"><a href="http://www.w3.org/2011/gld/track/issues/34">Issue-34</a>:
+ Clarify or drop qb:subslice</h3>
+ <p>
+ Use of <code>qb:subslice</code> in abbreviated datasets can result
+ in ambiguity. Consider
+ clarifying or deprecating <code>qb:subslice</code>.</p>
+ </div>
+
+
+</div>
+
+
+
+
+
+
+<div id="references" class="appendix section">
+<!-- OddPage -->
+<h2><span class="secno">E. </span>References</h2>
+<p class="todo">Bring all references into <acronym title="World Wide Web Consortium">W3C</acronym> style</p>
+<div id="normative-references" class="section"><h3><span class="secno">E.1 </span>Normative references</h3><p>No normative references.</p></div><div id="informative-references" class="section"><h3><span class="secno">E.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-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 v1, <a href="http://www.ordnancesurvey.co.uk/ontology/v1/AdministrativeGeography.rdf">http://www.ordnancesurvey.co.uk/ontology/v1/AdministrativeGeography.rdf</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-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-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-TURTLE-TR">[TURTLE-TR]</dt><dd>Eric Prud'hommeaux, Gavin Carothers. <a href="http://www.w3.org/TR/2011/WD-turtle-20110809/"><cite>Turtle: Terse RDF Triple Language.</cite></a> 09 August 2011. W3C Working Draft. URL: <a href="http://www.w3.org/TR/2011/WD-turtle-20110809/">http://www.w3.org/TR/2011/WD-turtle-20110809/</a>
+</dd></dl></div></div></body></html></pre></body></html>
\ No newline at end of file