Addressing issues 33, 34 and 39
authorDave Reynolds <>
Sat, 02 Mar 2013 22:53:35 +0000
changeset 327 1c3a135ec7bb
parent 326 cee7ea45c0f4
child 328 4d4f6803ed4a
Addressing issues 33, 34 and 39
--- a/data-cube/index.html	Sat Mar 02 16:35:16 2013 +0000
+++ b/data-cube/index.html	Sat Mar 02 22:53:35 2013 +0000
@@ -42,10 +42,10 @@
   <p>This publication transitions <a href="">previous work</a> on this subject onto the W3C Recommendation Track.</p>
-<section id="introduction">
+<section id="introduction" class="informative">
-<section id="intro-cube">
+<section id="intro-cube" class="informative">
 <h3>A Data Cube vocabulary</h3>
@@ -98,7 +98,7 @@
-<section id="intro-rdf">
+<section id="intro-rdf" class="informative">
 <h3>RDF and Linked Data</h3>
 <p><em>Linked data</em> is an approach to publishing data on the web, enabling
@@ -133,7 +133,7 @@
-<section id="intro-sdmx">
+<section id="intro-sdmx" class="informative">
 <h3>SDMX and related standards</h3>
 <p>The Statistical Data and Metadata Exchange (SDMX) Initiative
@@ -184,7 +184,7 @@
-<section id="intro-scovo">
+<section id="intro-scovo" class="informative">
 <h3>Relationship to SCOVO</h3>
 <p>The Statistical Core Vocabulary (SCOVO) [[SCOVO]] is a lightweight
@@ -215,7 +215,7 @@
-<section id="intro-audience">
+<section id="intro-audience" class="informative">
 <h3>Audience and scope</h3>
 <p>This document describes the Data Cube vocabulary
@@ -233,14 +233,21 @@
 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 
+identifies a <i>namespace URI</i>. The namespace identified by the prefix is 
  prepended to the <code>localname</code> to obtain the full URI.
-In this document we shall use the conventional prefix names for the
-<a href="#namespaces-used-appendix">well-known namespaces</a>:
+<p>All RDF examples are written in Turtle syntax [[!TURTLE-TR]].</p>
+<section id="namespaces">
+<p>The following namespaces are used in this document:</p>
 <table id="namespaces">
@@ -252,23 +259,20 @@
     <tr><td>owl</td><td><a href=""></a></td><td>[[!OWL2-PRIMER]]</td></tr>
     <tr><td>rdf</td><td><a href=""></a></td><td>[[!RDF-CONCEPTS]]</td></tr>
     <tr><td>rdfs</td><td><a href=""></a></td><td>[[!RDF-SCHEMA]]</td></tr>
+    <tr><td>admingeo</td><td><a href=""></a></td><td></td></tr>
 <p>We also introduce the prefix <code>qb</code> for the Data Cube
   namespace <a href=""></a>.</p>
-<p>All RDF examples are written in Turtle syntax [[!TURTLE-TR]].</p>
-<section id="data-cubes">
+<section id="data-cubes" class="informative">
 <h2>Data cubes</h2>
-<section id="cubes-model">
+<section id="cubes-model" class="informative">
 <h3>The cube model - dimensions, attributes, measures</h3>
 <p>A statistical data set comprises a collection of observations made
@@ -306,7 +310,7 @@
-<section id="cubes-slices">
+<section id="cubes-slices" class="informative">
 <p>It is frequently useful to group subsets of observations within a
@@ -338,7 +342,7 @@
-<section id="example">
+<section id="example" class="informative">
 <h2>An example</h2>
 <p>In order to illustrate the use of the data cube vocabulary we will
@@ -473,7 +477,9 @@
 <section id="outline">
 <h2>Outline of the vocabulary</h2>
-<img src="images/qb-fig1.png" alt="UML-style block diagram of the terms in this vocabulary"/>
+<!-- <img src="images/qb-fig1.png" alt="UML-style block diagram of the terms in this vocabulary"/> -->
+<img src="images/qb-fig1-proposed.png" alt="UML-style block diagram of the terms in this vocabulary"/>
 <section id="index">
 <h3>Vocabulary index</h3>
@@ -491,6 +497,7 @@
     <a href='#ref_qb_MeasureProperty'>qb:MeasureProperty</a>
     <a href='#ref_qb_Observation'>qb:Observation</a>
     <a href='#ref_qb_Slice'>qb:Slice</a>
+    <a href='#ref_qb_ObservationGroup'>qb:ObservationGroup</a>
     <a href='#ref_qb_SliceKey'>qb:SliceKey</a>
@@ -512,7 +519,7 @@
     <a href='#ref_qb_sliceKey_LC'>qb:sliceKey</a>
     <a href='#ref_qb_sliceStructure'>qb:sliceStructure</a>
     <a href='#ref_qb_structure'>qb:structure</a>
-    <a href='#ref_qb_subSlice'>qb:subSlice</a>
+    <a href='#ref_qb_observationGroup'>qb:observationGroup</a>
@@ -585,22 +592,22 @@
 <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>.
+  component can also be optionally annotated with  a <code>qb:codeList</code> to indicate a set of 
+  <code>skos:Concept</code>s which may be used as codes. The  <code>qb:codeList</code> value may be a
+  <code>skos:ConceptScheme</code>,  <code>skos:Collection</code> or <code>qb:Hierarchy</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 any SDMX extension vocabulary there would be one further item of information to encode
   about components - the role that they play within the structure definition. In particular, 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 can encoded by providing subclasses of <code>skos:Concept</code>
   for each role. The particular choice of roles here is specific to the SDMX standard and so is not 
-  included within the core data cube vocabulary. 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>
+  included within the core Data Cube vocabulary.</p>
 <p>Before illustrating the components needed for our running example, there is one more piece
   of machinery to introduce, a reusable set of concepts and components based on SDMX. 
@@ -1022,7 +1029,9 @@
 <section id="slices">
-<p>Slices allow us to group subsets of observations together.</p>
+<p>Slices allow us to group subsets of observations together. This not intended
+  to represent arbitrary selections from the observations but uniform slices
+  through the cube in which one or more of the dimension values are fixed.</p>
 <p>Slices may be used for a number of reasons:</p>
@@ -1032,23 +1041,6 @@
   <li>to reduce the verbosity of the data set by only stating each fixed dimensional value once.</li>
-<div class="note"> This section has been modified to
-  address <a href="">ISSUE-33</a></div>
-<p>Commonly in statistical publishing then slices are created by
-  fixing one or more dimension values. 
-  In particular, a common practice is for each slice to fix all dimensions
-  except time so that a slice represents a time series of
-  observations. However, the Data Cube vocabulary does not impose a
-  restriction that slices be only used in this manner. It is
-  permissible for a slice to be used to group observations together
-  for other reasons and for such slices to thus not have an associated
-  <em>slice key</em> (see below). For example, slices might be used to group
-  all of the latest available observations together for ease of
-  access. Extension vocabularies may introduce specialist sub classes of
-  slice for particular purposes, including ones which require presence
-  of a slice key.</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-2006" 
  and guide applications to present a comparative chart across regions. </p>
@@ -1172,15 +1164,15 @@
-<p>The Data Cube vocabulary allows slices to be nested. We can declare
-  multiple slice keys in a DSD and it is possible for one slice key to
-  be a narrower version of another, represented using <code>qb:subSlice</code>. In that case, when providing non-flattened
-  data with dimensions attached to the slice level, then
-  it is permissible to nest the <code>qb:Slice</code> instances and so 
-  further reduce the duplication stating of dimension values. However, 
-  in general flat representations are recommended to simplify data consumption. 
-  Some tool chains may support (dynamic or static) generation flattened representations from 
-  abbreviated data sets.</p>
+<p>There are also situations in which a publisher wishes to group a set of observations
+together for ease of access or presentation purposes but where that set is not defined
+by simply fixing a set of dimension values. For example, in representing results from a collection
+of asynchronous monitoring processes it can be desirable to group together the set of most recent
+observations available from each process.
+For those situations the Data Cube vocabulary supports
+<code>qb:ObservationGroup</code>. A <code>qb:ObservationGroup</code> can contain an arbitrary
+collection of observations.  A <code>qb:Slice</code> is a special case of a  <code>qb:ObservationGroup</code>.
@@ -1343,70 +1335,6 @@
-<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></td>
-      <td>RDF core</td>
-    </tr>
-    <tr>
-      <td>rdfs</td>
-      <td></td>
-      <td>RDF Schema</td>
-    </tr>
-    <tr>
-      <td>skos</td>
-      <td></td>
-      <td>Simple Knowledge Organization System</td>
-    </tr>
-    <tr>
-      <td>foaf</td>
-      <td></td>
-      <td>Friend Of A Friend</td>
-    </tr>
-    <tr>
-      <td>void</td>
-      <td></td>
-      <td>Vocabulary of Interlinked Datasets</td>
-    </tr>
-    <tr>
-      <td>scovo</td>
-      <td></td>
-      <td>Statistical Core Vocabulary</td>
-    </tr>
-    <tr>
-      <td>dc</td>
-      <td></td>
-      <td>Dublin Core</td>
-    </tr>
-    <tr>
-    <tr>
-      <td>admingeo</td>
-      <td></td>
-      <td>OS administrative geography ontology</td>
-    <tr>
-      <td>qb</td>
-      <td></td>
-      <td>The Data Cube vocabulary</td>
-    </tr>
-  </tbody>
-<p>The <code>eg</code> prefix, and all prefixes starting <code>eg-</code>, are fictional examples only.</p>
 <section id="vocab-reference" class="appendix">
 <h2>Vocabulary reference</h2>
@@ -1470,10 +1398,17 @@
 <dl class='vocab_reference'>
+  <dt id="ref_qb_ObservationGroup">
+    <em>Class:</em> <code>qb:ObservationGroup</code>
+  </dt>
+ <dd>A, possibly arbitrary, group of observations.</dd>
   <dt id="ref_qb_Slice">
     <em>Class:</em> <code>qb:Slice</code>
     <em>Sub class of: </em>
-      <code>qb:Attachable</code>
+      <code>qb:Attachable</code>,
+      <code>qb:ObservationGroup</code>
  <dd>Denotes a subset of a DataSet defined by fixing a subset of the dimensional values, component properties on the Slice</dd>
@@ -1487,15 +1422,15 @@
   <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>
+  <dt id="ref_qb_observationGroup">
+    <em>Property:</em> <code>qb:observationGroup</code>
-    <code>qb:Slice</code>
-    <code>qb:Slice</code>
+    <code>qb:ObservationGroup</code>
-  <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>
+  <dd>Indicates a group of observations. The domain of this property is left open so that a group may be attached to different resources and need not be restricted to a single DataSet.</dd>
@@ -1754,7 +1689,7 @@
-    <code>skos:ConceptScheme</code>
+    <code>owl:unionOf(skos:ConceptScheme skos:Collection qb:Hierarchy)</code>
   <dd>gives the code list associated with a CodedProperty</dd>
@@ -1835,6 +1770,10 @@
 Changes since <a href="">W3C Working Draft 5 April 2012</a>:
+  <li>Added <code>qb:ObservationGroup</code> as a generalization of <code>qb:Slice</code>.
+  <li>Removed <code>qb:subSlice</code> as being problematic in how they interact with attachment levels.</li>
+  <li>Generalized range of <code>qb:codeList</code> to allow <code>skos:Collection</code>.</li>
+  <li>Moved namespace definitions to a normative <a href="#namespaces">section</a> within the body of the specification.</li>
   <li>Moved Jeni Tennison from being listed as an author to being a
   contributor. Currently this has been done by listing her in the
   Acknowledgements section until tooling problems can be resolved.</li>