--- a/data-cube/static.html Thu Mar 29 15:38:30 2012 +0100
+++ b/data-cube/static.html Thu Mar 29 15:49:08 2012 +0100
@@ -1,14 +1,14 @@
-<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">
+<?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">
+<head>
+ <title>The RDF Data Cube Vocabulary</title>
+ <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
+ <script type="text/javascript" src="../respec/ReSpec.js/js/respec.js" class="remove"></script>
+ <script src="../respec/gld-bib.js" class="remove"></script>
+ <script src="respec-config.js" class="remove"></script>
+ <style type="text/css">
.todo { background-color: #fdd; border: 1px solid #800; margin: 1em 0em; padding: 1em; page-break-inside: avoid ; font-style: italic; }
.todo:before { content: 'TODO: '; }
.spare-table { border-collapse: collapse; margin-left: 5ex; }
@@ -16,714 +16,243 @@
.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;
-}
+ </style>
+</head>
-.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;
-}
+<body>
-.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
+<section id="abstract">
+<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>
+vocabulary provides a means to do this using the W3C <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
+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">
+statistical data flows.</p>
+</section>
-<!-- OddPage -->
-<h2><span class="secno">1. </span>Introduction</h2>
+<section id="introduction">
+<h2>Introduction</h2>
-<div id="intro-cube" class="section">
-<h3><span class="secno">1.1 </span>A Data Cube vocabulary</h3>
+<section id="intro-cube">
+<h3>A Data Cube vocabulary</h3>
-<p>
+<p>
Statistical data is a foundation for policy
prediction, planning and adjustments and
underpins many of the mash-ups and visualisations
we see on the web. There is strong interest
in being able to publish statistical data in a web-friendly format
to enable it to be linked and combined with related information.
-</p>
+</p>
-<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>
+using the the W3C <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>.
+<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
+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>
+such as survey data, spreadsheets and OLAP data cubes [[OLAP]].
+</p>
-<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>)
+support metadata for surveys (so called "micro-data", as encompassed by <a
+ href="http://www.ddialliance.org/">DDI</a>)
or publication of statistical reference metadata.
-</p>
+</p>
-<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>
+<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>
+</section>
-<div id="intro-rdf" class="section">
-<h3><span class="secno">1.2 </span>RDF and Linked Data</h3>
+<section id="intro-rdf">
+<h3>RDF and Linked Data</h3>
-<p><em>Linked data</em> is an approach to publishing data on the web, enabling
+<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>]
+ The approach [[LOD]]
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>]
+RDF [[RDF-PRIMER]]
provides a standard for the representation of the
information that describes those entities and concepts, and is returned
-by dereferencing the URIs. </p>
+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
+<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
+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
+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>
+for programmatic access.</li>
+ <li>It enables reuse of standardized tools and components.</li>
+</ul>
+</section>
-<div id="intro-sdmx" class="section">
-<h3><span class="secno">1.3 </span>SDMX and related standards</h3>
+<section id="intro-sdmx">
+<h3>SDMX and related standards</h3>
-<p>The Statistical Data and Metadata Exchange (SDMX) Initiative
+<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>
+and international levels.</p>
-<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
+<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>
-<p>The SDMX specification defines a core <em>information model</em>
+<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>
-<p>A key component of the SDMX standards package are
-the <strong>Content-Oriented Guidelines</strong> (COGs), a set of
+<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>
+</p>
+</section>
-<div id="intro-scovo" class="section">
-<h3><span class="secno">1.4 </span>Relationship to SCOVO</h3>
+<section id="intro-scovo">
+<h3>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
+<p>The Statistical Core Vocabulary (SCOVO) [[SCOVO]] 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
+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>
+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>
+<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 "slices" 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>
+<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>
+</p>
+</section>
-<div id="intro-audience" class="section">
-<h3><span class="secno">1.5 </span>Audience and scope</h3>
+<section id="intro-audience">
+<h3>Audience and scope</h3>
-<p>This document describes the Data Cube vocabulary
+<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>
+formats such as SDMX-ML will be covered elsewhere.</p>
+</section>
-<div id="intro-conventions" class="section">
-<h3><span class="secno">1.6 </span>Document conventions</h3>
+<section id="intro-conventions">
+<h3>Document conventions</h3>
-<p>
+<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>
+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>
+<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>
+<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>
+<p>All RDF examples are written in Turtle syntax [[TURTLE-TR]].</p>
+</section>
-</div>
+</section>
-<div id="data-cubes" class="section">
-
-<!-- OddPage -->
-<h2><span class="secno">2. </span>Data cubes</h2>
+<section id="data-cubes">
+<h2>Data cubes</h2>
-<div id="cubes-model" class="section">
-<h3><span class="secno">2.1 </span>The cube model - dimensions, attributes, measures</h3>
+<section id="cubes-model">
+<h3>The cube model - dimensions, attributes, measures</h3>
-<p>A statistical data set comprises a collection of observations made
+<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
@@ -732,444 +261,456 @@
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
+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>
+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>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
+<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>
+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>measure</em> components represent the phenomenon being
+observed.</p>
-<p>The <em>attribute</em> components allow us to qualify and
+<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>
+of the observation (e.g. <em>estimated</em>, <em>provisional</em>).</p>
+</section>
-<div id="cubes-slices" class="section">
-<h3><span class="secno">2.2 </span>Slices</h3>
+<section id="cubes-slices">
+<h3>Slices</h3>
-<p>It is frequently useful to group subsets of observations within a
+<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>
+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>
+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
+<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>
+ construct the appropriate graph or chart for presentation.</p>
-<p>In statistical applications it is common to work with
+<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>.
+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>
+concept labels.</p>
+</section>
-<div id="example" class="section">
+</section>
-<!-- OddPage -->
-<h2><span class="secno">3. </span>An example</h2>
+<section id="example">
+<h2>An example</h2>
-<p>In order to illustrate the use of the data cube vocabulary we will
+<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
+<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>
+(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>
+<table style="text-align: left; width: 80%;" border="1" cellpadding="2"
+ cellspacing="0">
+ <tbody>
+ <tr>
+ <td style="vertical-align: top;"><br>
+ </td>
+ <td colspan="2" rowspan="1"
+ style="vertical-align: top; text-align: center; font-weight: bold;">2004-2006<br>
+ </td>
+ <td colspan="2" rowspan="1"
+ style="vertical-align: top; text-align: center; font-weight: bold;">2005-2007<br>
+ </td>
+ <td colspan="2" rowspan="1"
+ style="vertical-align: top; text-align: center; font-weight: bold;">2006-2008<br>
+ </td>
+ </tr>
+ <tr>
+ <td style="vertical-align: top;"><br>
+ </td>
+ <td
+ style="vertical-align: top; text-align: center; font-weight: bold;">Male<br>
+ </td>
+ <td
+ style="vertical-align: top; text-align: center; font-weight: bold;">Female<br>
+ </td>
+ <td
+ style="vertical-align: top; text-align: center; font-weight: bold;">Male<br>
+ </td>
+ <td
+ style="vertical-align: top; text-align: center; font-weight: bold;">Female<br>
+ </td>
+ <td
+ style="vertical-align: top; text-align: center; font-weight: bold;">Male<br>
+ </td>
+ <td
+ style="vertical-align: top; text-align: center; font-weight: bold;">Female<br>
+ </td>
+ </tr>
+ <tr>
+ <td
+ style="vertical-align: top; text-align: right; font-weight: bold;">Newport<br>
+ </td>
+ <td style="vertical-align: top;">76.7<br>
+ </td>
+ <td style="vertical-align: top;">80.7<br>
+ </td>
+ <td style="vertical-align: top;">77.1<br>
+ </td>
+ <td style="vertical-align: top;">80.9<br>
+ </td>
+ <td style="vertical-align: top;">77.0<br>
+ </td>
+ <td style="vertical-align: top;">81.5<br>
+ </td>
+ </tr>
+ <tr>
+ <td
+ style="vertical-align: top; text-align: right; font-weight: bold;">Cardiff<br>
+ </td>
+ <td style="vertical-align: top;">78.7<br>
+ </td>
+ <td style="vertical-align: top;">83.3<br>
+ </td>
+ <td style="vertical-align: top;">78.6<br>
+ </td>
+ <td style="vertical-align: top;">83.7<br>
+ </td>
+ <td style="vertical-align: top;">78.7<br>
+ </td>
+ <td style="vertical-align: top;">83.4<br>
+ </td>
+ </tr>
+ <tr>
+ <td
+ style="vertical-align: top; text-align: right; font-weight: bold;">Monmouthshire<br>
+ </td>
+ <td style="vertical-align: top;">76.6<br>
+ </td>
+ <td style="vertical-align: top;">81.3<br>
+ </td>
+ <td style="vertical-align: top;">76.5<br>
+ </td>
+ <td style="vertical-align: top;">81.5<br>
+ </td>
+ <td style="vertical-align: top;">76.6<br>
+ </td>
+ <td style="vertical-align: top;">81.7<br>
+ </td>
+ </tr>
+ <tr>
+ <td
+ style="vertical-align: top; text-align: right; font-weight: bold;">Merthyr
+Tydfil<br>
+ </td>
+ <td style="vertical-align: top;">75.5<br>
+ </td>
+ <td style="vertical-align: top;">79.1<br>
+ </td>
+ <td style="vertical-align: top;">75.5<br>
+ </td>
+ <td style="vertical-align: top;">79.4<br>
+ </td>
+ <td style="vertical-align: top;">74.9<br>
+ </td>
+ <td style="vertical-align: top;">79.6<br>
+ </td>
+ </tr>
+ </tbody>
+</table>
-<p>We can see that there are three dimensions - time period (rolling averages over three year timespans),
+<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>
+ 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
+<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>
+ different regions, i.e. corresponding to the columns in the above tabular layout.</p>
-</div>
+</section>
-<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>
+<section id="outline">
+<h2>Outline of the vocabulary</h2>
- <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>
+<img src="images/qb-fig1.png" />
-</div>
+<section id="index">
+<h3>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>
+</section>
+
+</section>
-<div id="dsd" class="section">
+<section id="dsd">
+<h2>Creating data structure definitions</h2>
-<!-- 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
+<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>
+ several benefits:</p>
-<ul>
- <li>it enables verification that the data set matches the expected structure,
+<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>
+ 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
+<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>
+ confident that the structure of the data has not changed.</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>
+<section id="dsd-dimensions">
+<h3>Dimensions, attributes and measures</h3>
-<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
+<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>)
+ 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>
+ 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
+<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 [[SKOS-PRIMER]] 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>
+ 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>
+<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>
+ 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
+<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>
+ 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
+<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>
+ 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>
+ information.</p>
-<p>Before illustrating the components needed for our running example, there is one more piece
+<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>
+</p>
+</section>
-<div id="dsd-cog" class="section">
-<h3><span class="secno">5.2 </span>Content oriented guidelines</h3>
+<section id="dsd-cog">
+<h3>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>]
+<p>The SDMX standard includes a set of <em>content oriented guidelines</em> (COG) [[COG]]
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>
+ 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
+<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>
+ across data sets. Given this background we will reuse the relevant COG components in our worked example.</p>
+</section>
-<div id="dsd-example" class="section">
-<h3><span class="secno">5.3 </span>Example</h3>
+<section id="dsd-example">
+<h3>Example</h3>
-<p>Turning to our example data set then we can see there are three dimensions to represent
+<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>
+ 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,
+<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>
+ 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;
+<pre>
+ eg:refPeriod a rdf:Property, qb:DimensionProperty;
+ rdfs:label "reference period"@en;
rdfs:subPropertyOf sdmx-dimension:refPeriod;
rdfs:range interval:Interval;
- qb:concept sdmx-concept:refPeriod . </pre>
+ qb:concept sdmx-concept:refPeriod . </pre>
-<p><b>Region.</b> Again there is a suitable COG concept and associated component that
+<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>
+ we can use the Ordanance Survey administrative geography ontology [[OS-GEO]].</p>
-<pre> eg:refArea a rdf:Property, qb:DimensionProperty;
- rdfs:label &quot;reference area&quot;@en;
+<pre>
+ eg:refArea a rdf:Property, qb:DimensionProperty;
+ rdfs:label "reference area"@en;
rdfs:subPropertyOf sdmx-dimension:refArea;
rdfs:range admingeo:UnitaryAuthority;
- qb:concept sdmx-concept:refArea . </pre>
+ 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>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
+<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>
+ 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;
+<pre>
+ eg:lifeExpectancy a rdf:Property, qb:MeasureProperty;
+ rdfs:label "life expectancy"@en;
rdfs:subPropertyOf sdmx-measure:obsValue;
- rdfs:range xsd:decimal . </pre>
+ rdfs:range xsd:decimal . </pre>
-<p><b>Unit measure attribute.</b> The primary measure on its own is a plain decimal value.
+<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
+ 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>
+ For the sake of this simple example we will use the DBpedia resource <code>http://dbpedia.org/resource/Year</code>
+ which corresponds to the topic of the Wikipedia page on "Years".</p>
-<p>This covers the minimal components needed to define the structure of this data set.</p>
-</div>
+<p>This covers the minimal components needed to define the structure of this data set.</p>
+</section>
-<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>
+<section id="dsd-dsd">
+<h3>ComponentSpecifications and DataStructureDefinitions</h3>
-<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>).
+<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>
+ 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>.
+<ul>
+ <li>An Attribute may be optional in which case the specification should set
+ <code>qb:componentRequired "false"^^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.
+ 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>
+ 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
+<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>
+ 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>
+<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;
+<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];
@@ -1177,247 +718,251 @@
# The measure(s)
qb:component [qb:measure eg:lifeExpectancy];
# The attributes
- qb:component [qb:attribute sdmx-attribute:unitMeasure; qb:componentAttachment qb:DataSet;] .</pre>
+ 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
+<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>
+</p>
+</section>
-<div id="dsd-mm" class="section">
-<h3><span class="secno">5.5 </span>Handling multiple measures</h3>
+<section id="dsd-mm">
+<h3>Handling multiple measures</h3>
-<p>Our example data set is relatively simple in having a single observable (in this case &quot;life expectancy&quot;)
+<p>Our example data set is relatively simple in having a single observable (in this case "life expectancy")
that is being measured. In other data sets there can be multiple measures. These measures
may be of similar nature (e.g. a data set on local government performance might provide
multiple different performance indicators for each region) or quite different (e.g. a data set
- on trades might provide quantity, value, weight for each trade).</p>
+ 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
+<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
+ or sensor networks then the term <em>observation</em> usually denotes an observation event which can include multiple
+ observed values. Similarly in Business Intelligence applications and OLAP, a single "cell" in the data cube will
typically contain values for multiple measures.
-</p>
+</p>
-<p>The data cube vocabulary permits either representation approach to be used though they cannot be mixed
- within the same data set.</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>
+<section id="dsd-mm-obs">
+<h4>Multi-measure observations</h4>
-<p> This approach allows multiple observed values to be attached
+<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
+ 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>
+ 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;
+<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 "shipments by time (multiple measures approach)"@en;
qb:component
[ qb:dimension sdmx-dimension:refTime; ],
[ qb:measure eg-measure:quantity; ],
- [ qb:measure eg-measure:weight; ] . </pre>
+ [ qb:measure eg-measure:weight; ] . </pre>
-<p>This would correspond to individual observations such as:</p>
-<pre>eg:dataset1 a qb:DataSet;
+<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;
+ sdmx-dimension:refTime "30-07-2010"^^xsd:date;
eg-measure:weight 1.3 ;
eg-measure:quantity 42 ;
- . </pre>
+ . </pre>
-<p>Note that one limitation of the multi-measure approach is that it is not possible to attach
+<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
+ 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>
+ For applications where this limitation is a problem then use the <em>measure dimension</em> approach.</p>
+</section>
-<div id="dsd-mm-dim" class="section">
-<h4><span class="secno">5.5.2 </span>Measure dimension</h4>
+<section id="dsd-mm-dim">
+<h4>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>.
+<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>
+ 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
+<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>.
+ 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
+ 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>
+ 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;
+<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 "shipments by time (measure dimension approach)"@en;
qb:component
[ qb:dimension sdmx-dimension:refTime; ],
[ qb:measure eg-measure:quantity; ],
[ qb:measure eg-measure:weight; ],
- [ qb:dimension qb:measureType; ] . </pre>
+ [ qb:dimension qb:measureType; ] . </pre>
-<p>This would correspond to individual observations such as:</p>
-<pre>eg:dataset2 a qb:DataSet;
+<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;
+ sdmx-dimension:refTime "30-07-2010"^^xsd:date;
qb:measureType eg-measure:weight ;
eg-measure:weight 1.3 .
eg:obs2b a qb:Observation;
qb:dataSet eg:dataset2;
- sdmx-dimension:refTime &quot;30-07-2010&quot;^^xsd:date;
+ sdmx-dimension:refTime "30-07-2010"^^xsd:date;
qb:measureType eg-measure:quantity ;
- eg-measure:quantity 42 . </pre>
+ eg-measure:quantity 42 . </pre>
-<p>Note the duplication of having the measure property show up both as the property that
+<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>
+ a uniform way of declaring and using measure properties on all kinds of datasets.<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
+<p>Those familiar with SDMX should also note that in the RDF representation there is
+ no need for a separate "primary measure" which subsumes each of the individual
measures, those individual measures are used directly. 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>
+ separate annotation on <code>sdmx:DataStructureDefinition</code>.</p>
+</section>
-</div>
+</section>
-</div>
+</section>
-<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>
+<section id="datasets">
+<h2>Expressing data sets</h2>
- <dt>Organizational structure</dt>
- <dd>To locate an observation within the hypercube, one has at least to know the value of each
+<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>.
+ 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.
+ <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
+ 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>
+ described earlier.</dd>
- <dt>External metadata</dt>
- <dd>This is metadata that describes the dataset as a whole, such as categorization of the
+ <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>
+ 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>
+<section id="dataset-basic">
+<h3>Data sets and observations</h3>
-<p><strong>Pitfall</strong>: Note the capitalization of <tt>qb:<strong>D</strong>ata<strong>S</strong>et</tt>,
+<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>
+<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>.
+<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>
+ data set using the <code>qb:dataSet</code> property. For example:</p>
-<p>Thus for our running example we might expect to have:</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;
+<pre>
+ eg:dataset-le1 a qb:DataSet;
+ rdfs:label "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
qb:structure eg:dsd-le ;
.
eg:o1 a qb:Observation;
qb:dataSet eg:dataset-le1 ;
eg:refArea admingeo:newport_00pr ;
- eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
- sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
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; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
- sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
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; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
- sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
eg:lifeExpectancy 76.6 ;
.
...
-</pre>
+</pre>
-<p>This <em>flattened</em> structure makes it easy to query and combine data sets
+<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>
+ 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;
+<pre>
+ eg:dataset-le1 a qb:DataSet;
+ rdfs:label "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
qb:structure eg:dsd-le ;
- sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
.
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; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
eg:lifeExpectancy 76.7 ;
.
@@ -1425,7 +970,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; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
eg:lifeExpectancy 78.7 ;
.
@@ -1433,52 +978,51 @@
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; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
eg:lifeExpectancy 76.6 ;
.
...
-</pre>
+</pre>
-<p>In a data set containing just observations with no intervening structure then each observation
+<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>
+ in the next section.</p>
+</section>
-</div>
+</section>
-<div id="slices" class="section">
+<section id="slices">
+<h2>Slices</h2>
-<!-- OddPage -->
-<h2><span class="secno">7. </span>Slices</h2>
-
-<p>Slices allow us to group subsets of observations together. This not intended
+<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>
+ 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>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>To illustrate the use of slices let us group the sample data set into geographic series.
+ That will enable us to refer to e.g. "male life expectancy observations for 2004-6"
+ 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
+<p>We first define the structure of the slices we want by associating a "slice key" which the
+ data structure definition. This is done by creating a <code>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>
+ 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;
+<pre>
+ eg:sliceByRegion a qb:SliceKey;
+ rdfs:label "slice by region"@en;
+ rdfs:comment "Slice by grouping regions together, fixing sex and time values"@en;
qb:componentProperty eg:refPeriod, sdmx-dimension:sex .
eg:dsd-le-slice1 a qb:DataStructureDefinition;
@@ -1489,31 +1033,32 @@
[qb:measure eg:lifeExpectancy];
[qb:attribute sdmx-attribute:unitMeasure; qb:componentAttachment qb:DataSet;] ;
qb:sliceKey eg:sliceByRegion .
-</pre>
+</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>
+<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;
+<pre>
+ eg:dataset-le2 a qb:DataSet;
+ rdfs:label "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
qb:structure eg:dsd-le-slice2 ;
- sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
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; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
qb:observation eg:o1b, eg:o2b; eg:o3b, ... .
eg:o1b a qb:Observation;
qb:dataSet eg:dataset-le2 ;
eg:refArea admingeo:newport_00pr ;
- eg:refPeriod &lt;http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y&gt; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
eg:lifeExpectancy 76.7 ;
.
@@ -1521,7 +1066,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; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
eg:lifeExpectancy 78.7 ;
.
@@ -1529,21 +1074,22 @@
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; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
eg:lifeExpectancy 76.6 ;
.
...
-</pre>
+</pre>
-<p>Note that here we are still repeating the dimension values on the individual observations.
+<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;
+</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];
@@ -1553,16 +1099,16 @@
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;
+ rdfs:label "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
qb:structure eg:dsd-le-slice3 ;
- sdmx-attribute:unitMeasure &lt;http://dbpedia.org/resource/Year&gt; ;
+ sdmx-attribute:unitMeasure <http://dbpedia.org/resource/Year> ;
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; ;
+ eg:refPeriod <http://reference.data.gov.uk/id/gregorian-interval/2004-01-01T00:00:00/P3Y> ;
sdmx-dimension:sex sdmx-code:sex-M ;
qb:observation eg:o1c, eg:o2c; eg:o3c, ... .
@@ -1585,704 +1131,684 @@
.
...
-</pre>
+</pre>
-<p>The Data Cube vocabulary allows slices to be nested. We can declare
+<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
+ 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
+ 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>
+ abbreviated data sets.</p>
+</section>
-<div id="schemes" class="section">
+<section id="schemes">
+<h2>Concept schemes and code lists</h2>
-<!-- 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)
+<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>
+ represented by URI references in the usual RDF fashion.</p>
-<p>Sometimes
+<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>
+ 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>
+<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; ;
+<pre>
+sdmx-code:sex a skos:ConceptScheme;
+ skos:prefLabel "Code list for Sex (SEX) - codelist scheme"@en;
+ rdfs:label "Code list for Sex (SEX) - codelist scheme"@en;
+ skos:notation "CL_SEX";
+ skos:note "This code list provides the gender."@en;
+ skos:definition <http://sdmx.org/wp-content/uploads/2009/01/02_sdmx_cog_annex_2_cl_2009.pdf> ;
rdfs:seeAlso sdmx-code:Sex ;
sdmx-code:sex skos:hasTopConcept sdmx-code:sex-F ;
sdmx-code:sex skos:hasTopConcept sdmx-code:sex-M .
sdmx-code:Sex a rdfs:Class, owl:Class;
rdfs:subClassOf skos:Concept ;
- rdfs:label &quot;Code list for Sex (SEX) - codelist class&quot;@en;
- rdfs:comment &quot;This code list provides the gender.&quot;@en;
+ rdfs:label "Code list for Sex (SEX) - codelist class"@en;
+ rdfs:comment "This code list provides the gender."@en;
rdfs:seeAlso sdmx-code:sex .
sdmx-code:sex-F a skos:Concept, sdmx-code:Sex;
skos:topConceptOf sdmx-code:sex;
- skos:prefLabel &quot;Female&quot;@en ;
- skos:notation &quot;F&quot; ;
+ skos:prefLabel "Female"@en ;
+ skos:notation "F" ;
skos:inScheme sdmx-code:sex .
sdmx-code:sex-M a skos:Concept, sdmx-code:Sex;
skos:topConceptOf sdmx-code:sex;
- skos:prefLabel &quot;Male&quot;@en ;
- skos:notation &quot;M&quot; ;
+ skos:prefLabel "Male"@en ;
+ skos:notation "M" ;
skos:inScheme sdmx-code:sex .
-</pre>
+</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
+<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
+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>
+(which do not use such a datatype).</p>
-<p>It is convenient and good practice when developing a code list to also
+<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>
+<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>
+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>
+<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;
+<pre>
+ eg:sex a sdmx:DimensionProperty, sdmx:CodedProperty;
qb:codeList sdmx-code:sex ;
rdfs:range sdmx-code:Sex .
-</pre>
+</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>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
+<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>
+<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
+<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>
+All items are linked to the scheme via <code>skos:inScheme</code>.</p>
+</section>
-<div id="metadata" class="section">
-
-<!-- OddPage -->
-<h2><span class="secno">9. </span>DataSet metadata</h2>
+<section id="metadata">
+<h2>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>)
+<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>
+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>
+<section id="metadata-categorization">
+<h3>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
+<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>
+and fine grained classifications to support discovery of data sets.</p>
-<p>Thus our sample dataset might be marked up by:</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>
-<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;
+<p>Thus our sample dataset might be marked up by:</p>
+
+<pre>
+ eg:dataset1 a qb:DataSet;
+ rdfs:label "Life expectancy"@en;
+ rdfs:comment "Life expectancy within Welsh Unitary authorities - extracted from Stats Wales"@en;
+ dcterms:date "2010-08-11"^^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">
+</pre>
-<!-- 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>
+<p>where <code>eg:Wales</code> is a <code>skos:Concept</code> drawn from an appropriate controlled
+vocabulary for places.</p>
+</section>
-<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>
-
+<section id="metadata-publishers">
+<h3>Describing publishers</h3>
-<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">
+<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> [[ORG]].</p>
- <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>
+<pre>
+eg:dataset1 a qb:DataSet;
+ dc:publisher <http://example.com/meta#organization> .
+
+<http://example.com/meta#organization> a org:Organization, foaf:Agent;
+ rdfs:label "Example org" .
+</pre>
- <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>
+<p>Note that the SDMX extension vocabulary supports further description of
+ publication pipelines (data flows, reporting taxonomies, maintainers, provision agreements).</p>
+</section>
- <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>
+</section>
+
+<section id="namespaces-used-appendix" class="appendix">
+<h2>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>
+</section>
-<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>
+<section id="vocab-reference" class="appendix">
+<h2>Vocabulary reference</h2>
-<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>
+<section id="reference-datasets">
+<h3>DataSets</h3>
- <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>
+<dl class='vocab_reference'>
- <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>
+ <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>
+</section>
-<div id="reference-concepts" class="section">
-<h3><span class="secno">B.9 </span>Concepts</h3>
-<dl class="vocab_reference">
+<section id="reference-observations">
+<h3>Observations</h3>
- <dt id="ref_qb_concept">
- <em>Property:</em> <code>qb:concept</code>
+<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:ComponentProperty</code>
- -&gt;
- <code>skos:Concept</code>
+ <code>qb:Observation</code>
+ ->
+ <code>qb:DataSet</code>
)
- </dt>
- <dd>gives the concept which is being measured or indicated by a ComponentProperty</dd>
+ </dt>
+ <dd>indicates the data set of which this observation is a part</dd>
- <dt id="ref_qb_codeList">
- <em>Property:</em> <code>qb:codeList</code>
+ <dt id="ref_qb_observation">
+ <em>Property:</em> <code>qb:observation</code>
(
- <code>qb:CodedProperty</code>
- -&gt;
- <code>skos:ConceptScheme</code>
+ <code>qb:Slice</code>
+ ->
+ <code>qb:Observation</code>
)
- </dt>
- <dd>gives the code list associated with a CodedProperty</dd>
-</dl>
-</div>
-
-</div>
+ </dt>
+ <dd>indicates a observation contained within this slice of the data set</dd>
+</dl>
+</section>
-<div class="appendix section" id="acknowledgements">
+<section id="reference-slices">
+<h3>Slices</h3>
-<!-- OddPage -->
-<h2><span class="secno">C. </span>Acknowledgements</h2>
+<dl class='vocab_reference'>
-<p>This work is based on a collaboration that was initiated in a
+ <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>
+ ->
+ <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>
+ ->
+ <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>
+</section>
+
+
+<section id="reference-components">
+<h3>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>
+</section>
+
+
+<section id="reference-component-properties">
+<h3>Reusable general purpose component properties</h3>
+<dl class='vocab_reference'>
+
+ <dt id="ref_qb_measureType">
+ <em>Property:</em> <code>qb:measureType</code>
+ (
+ ->
+ <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>
+</section>
+
+
+<section id="reference-dsd">
+<h3>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>
+ ->
+ <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>
+ ->
+ <code>qb:ComponentSpecification</code>
+ )
+ </dt>
+ <dd>indicates a component specification which is included in the structure of the dataset</dd>
+</dl>
+</section>
+
+
+<section id="reference-compspec">
+<h3>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>
+ ->
+ <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>
+ ->
+ <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>
+ ->
+ <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>
+ ->
+ <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>
+ (
+ ->
+ <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>
+ (
+ ->
+ <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>
+ (
+ ->
+ <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>
+ (
+ ->
+ <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>
+</section>
+
+
+<section id="reference-slice-definitions">
+<h3>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>
+ ->
+ <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>
+ ->
+ <code>qb:SliceKey</code>
+ )
+ </dt>
+ <dd>indicates a slice key which is used for slices in this dataset</dd>
+</dl>
+</section>
+
+
+<section id="reference-concepts">
+<h3>Concepts</h3>
+<dl class='vocab_reference'>
+
+ <dt id="ref_qb_concept">
+ <em>Property:</em> <code>qb:concept</code>
+ (
+ <code>qb:ComponentProperty</code>
+ ->
+ <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>
+ ->
+ <code>skos:ConceptScheme</code>
+ )
+ </dt>
+ <dd>gives the code list associated with a CodedProperty</dd>
+</dl>
+</section>
+
+</section>
+
+
+<section id="acknowledgements" class="appendix">
+<h2>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>
+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>
+<p>The authors would also like to thank John Sheridan for his comments,
+suggestions and support for this work.</p>
+</section>
-<div id="issues" class="section">
+<section id="issues">
+<h2>Open issues</h2>
-<!-- OddPage -->
-<h2><span class="secno">D. </span>Open issues</h2>
-
-<p>
+<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>
+</p>
- <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><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-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
+ <div class='issue'>
+ <h3><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><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>
+ (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>
+ <div class='issue'>
+ <h3><a href="http://www.w3.org/2011/gld/track/issues/32">Issue-32</a>:
+ Relationship to ISO 19156 - Observations & 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.
+ Observations & Measurements (ISO 19156). There are multiple ways
+ that Data Cube can be mapped to the logical model of O&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>
+ Cube can be related to O&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>
+ <div class='issue'>
+ <h3><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>
+ 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
+ <div class='issue'>
+ <h3><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>
-
+ clarifying or deprecating <code>qb:subslice</code>.</p>
+ </div>
-
+</section>
-<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
+<section id="references" class="appendix">
+<p class="todo">Bring all references into W3C style</p>
+</section>
+
+</body>
+</html>