--- a/data-cube/index.html Thu Mar 07 17:11:21 2013 +0000
+++ b/data-cube/index.html Thu Mar 07 18:45:44 2013 +0000
@@ -121,7 +121,7 @@
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 W3C <a href="http://www.w3.org/TR/REC-rdf-syntax/">RDF</a>
+using 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>.
@@ -350,7 +350,7 @@
<section id="cubes-slices" class="informative">
-<h3>Slices</h3>
+<h3>Introducing Slices</h3>
<p>It is frequently useful to group subsets of observations within a
dataset. In particular to fix all but one (or a small subset) of the
@@ -588,7 +588,7 @@
appropriate range checking.</p>
<p>Note that in any SDMX extension vocabulary there would be one further item of information to encode
- about components - the role that they play within the structure definition. In particular, is sometimes
+ about components - the role that they play within the structure definition. In particular, it is sometimes
convenient for consumers to be able to easily identify which is the time dimension,
which component is the primary measure and so forth. It turns out that such roles are intrinsic to
the concepts and so this information can encoded by providing subclasses of <code>skos:Concept</code>
@@ -605,8 +605,8 @@
<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. A <a href="https://code.google.com/p/publishing-statistical-data/">community group</a> has developed, and
- maintains, RDF encodings of these guidelines. These comprise:
+ reusable across data sets. A <a href="https://code.google.com/p/publishing-statistical-data/">community group</a>
+ has developed RDF encodings of these guidelines. These comprise:
<table id="namespaces-table">
<thead><tr><th>Prefix</th><th>Namespace</th><th>Description</th></tr></thead>
@@ -703,9 +703,9 @@
<ul>
<li>Attributes may be declared as optional or required. If an
attribute is required to be present for every observation then the specification should set
- <code></code>. In the
+ <code><a>qb:componentRequired></a></code>. In the
absence of such a declaration an attribute is assumed to be
- optional. The <code><a>qb:componentRequired></a></code>
+ optional. The <code><a>qb:componentRequired</a></code>
declaration may only be applied to component specifications of
attributes - measures and dimensions are always required.</li>
<li>The components may be ordered by giving an integer value for <code><a>qb:order</a></code>.
@@ -829,8 +829,12 @@
<p>To use this representation you declare an additional dimension within the data structure
definition to play the role of the measure dimension. For use within the Data Cube vocabulary
we provide a single distinguished component for this purpose -- <code><a>qb:measureType</a></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.
+ An extension vocabulary could generalize this through the provision of roles to
+ identify concepts which
+ act as measure types, enabling other measure dimensions to be declared.
+</p>
+
+ <p>
In the special case of using <code><a>qb:measureType</a></code> as the measure dimension, the set of allowed
measures is assumed to be those measures declared within the DSD. There is no need to
define a separate code list or enumerated class to duplicate this information.
@@ -896,7 +900,7 @@
<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 5.2</a>.
+ as described earlier in <a href="#slices">section 7.2</a>.
<dt>Internal metadata</dt>
<dd>Having located an observation, we need certain metadata in order to be able to interpret it.
@@ -908,7 +912,7 @@
<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 10</a>.</dd>
+ External metadata is described in <a href="#metadata">section 9</a>.</dd>
</dl>
@@ -1016,11 +1020,9 @@
in the next section.</p>
</section>
-</section>
-
<section id="slices">
-<h2>Slices</h2>
+<h2>Slices and groups of observations</h2>
<p>Slices allow us to group subsets of observations together. This not intended
to represent arbitrary selections from the observations but uniform slices
@@ -1168,6 +1170,8 @@
</section>
+</section>
+
<section id="schemes">
<h2>Concept schemes and code lists</h2>
@@ -1258,7 +1262,7 @@
<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
+Hierarchical code lists SHOULD be represented using the
<code>skos:narrower</code> relationship to link from the <code>skos:hasTopConcept</code>
codes down through the tree or lattice of child codes.
In some publishing tool chains the corresponding transitive closure
@@ -1282,13 +1286,22 @@
<li>Where such maintained reference data is to be reused there can be multiple hierarchies which relate
the same codes. In particular a set of geographic entities may participate in both a geographic-containment hierarchy
and an administrative hierarchy which do not precisely align. </li>
-<li>The SKOS relations do not define when the child concepts are disjoint (mutually exclusive) or then they form
+<li>The SKOS relations do not define when the child concepts are disjoint (mutually exclusive) or when they form
a complete cover of the parent concept (exhaustive).</li>
</ul>
<p>The Data Cube vocabulary supports this situation through the <code><a>qb:HierarchicalCodeList</a></code> class.
An instance of <code><a>qb:HierarchicalCodeList</a></code> defines a set of root concepts in the hierarchy
-(<code><a>qb:hierarchyRoot</a></code>) and a parent-to-child relationship (<code><a>qb:parentChildProperty</a></code>).</p>
+(<code><a>qb:hierarchyRoot</a></code>) and a parent-to-child relationship (<code><a>qb:parentChildProperty</a></code>) which
+links a term in the hierarchy to its immediate sub-terms. </p>
+
+<p>Thus a <code><a>qb:HierarchicalCodeList</a></code>
+is similar to a <code>skos:ConceptScheme</code> in which <code><a>qb:hierarchyRoot</a></code> plays the same
+role as <code>skos:hasTopConcept</code>, and the value of <code><a>qb:parentChildProperty</a></code> plays
+the same role as <code>skos:narrower</code>. In the case where a code list is already available as a SKOS concept scheme or collection
+then those SHOULD be used directly; <code><a>qb:HierarchicalCodeList</a></code> is provided for cases where the
+terms are not available as SKOS but are available in some other RDF representation suitable for reuse.
+</p>
<p>For example, the Ordnance Survey of Great Britain publishes a geographic hierarchy which has
eleven roots (European Regions such as Wales, Scotland, the South West) and uses a spatial relations
@@ -1299,7 +1312,7 @@
eg:GBgeoHierarchy a qb:HierarchicalCodeList;
rdfs:label "Geographic Hierarchy for Great Britain"@en;
- qb:hierarchy Root
+ qb:hierarchyRoot
<http://data.ordnancesurvey.co.uk/id/7000000000041427>, # South West
<http://data.ordnancesurvey.co.uk/id/7000000000041426>, # West Midlands
<http://data.ordnancesurvey.co.uk/id/7000000000041421>, # South East
@@ -1398,7 +1411,7 @@
dcterms:subject
sdmx-subject:3.2 , # regional and small area statistics
sdmx-subject:1.4 , # Health
- ex-geo:wales_gor_l ; # Wales
+ ex:wales; # Wales
...
</pre>
@@ -1452,7 +1465,7 @@
In those cases the attached property is taken to be applied to all
the <code><a>qb:Observation</a></code> instances associated with that
attachment point. For illustration
-see <a href="attachment-example">example 4</a> in which the unit of
+see <a href="#attachment-example">example 4</a> in which the unit of
measure is declared as to be attached to the whole data set and need
not be repeated for every observation.</p>
@@ -2362,7 +2375,7 @@
<code><a>qb:DataStructureDefinition</a></code>
)
</dt>
- <dd>indicates the structure to which this data set conforms</dd>
+ <dd>Indicates the structure to which this data set conforms</dd>
<dt id="ref_qb_component">
<em>Property:</em> <code><dfn>qb:component</dfn></code>
@@ -2372,7 +2385,7 @@
<code><a>qb:ComponentSpecification</a></code>
)
</dt>
- <dd>indicates a component specification which is included in the structure of the dataset.</dd>
+ <dd>Indicates a component specification which is included in the structure of the dataset.</dd>
</dl>
</section>
@@ -2434,7 +2447,7 @@
<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>
+ <dd>Indicates the level at which the component property should be attached, this might be an qb:DataSet, qb:Slice or qb:Observation, or a qb:MeasureProperty.</dd>
<dt id="ref_qb_dimension">
<em>Property:</em> <code><dfn>qb:dimension</dfn></code>
--- a/data-cube/static.html Thu Mar 07 17:11:21 2013 +0000
+++ b/data-cube/static.html Thu Mar 07 18:45:44 2013 +0000
@@ -249,7 +249,7 @@
<dt>Contributor:</dt> <dd><a href="http://www.jenitennison.com/">Jeni Tennison</a></dd></dl>
- <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
+ <p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2013 <a href="http://www.w3.org/"><abbr title="World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><abbr title="Massachusetts Institute of Technology">MIT</abbr></a>, <a href="http://www.ercim.eu/"><abbr title="European Research Consortium for Informatics and Mathematics">ERCIM</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>, <a href="http://ev.buaa.edu.cn/">Beihang</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p>
<hr>
</div>
@@ -332,7 +332,7 @@
-</section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#outline" class="tocxref"><span class="secno">1. </span>Outline of the vocabulary</a><ul class="toc"><li class="tocline"><a href="#index" class="tocxref"><span class="secno">1.1 </span>Vocabulary index</a></li></ul></li><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">2. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#intro-rdf" class="tocxref"><span class="secno">2.1 </span>RDF and Linked Data</a></li><li class="tocline"><a href="#intro-sdmx" class="tocxref"><span class="secno">2.2 </span>SDMX and related standards</a></li><li class="tocline"><a href="#intro-audience" class="tocxref"><span class="secno">2.3 </span>Audience and scope</a></li></ul></li><li class="tocline"><a href="#namespaces" class="tocxref"><span class="secno">3. </span>Namespaces and Document Conventions</a></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">4. </span>Conformance</a></li><li class="tocline"><a href="#data-cubes" class="tocxref"><span class="secno">5. </span>Data cubes</a><ul class="toc"><li class="tocline"><a href="#cubes-model" class="tocxref"><span class="secno">5.1 </span>The cube model - dimensions, attributes, measures</a></li><li class="tocline"><a href="#cubes-slices" class="tocxref"><span class="secno">5.2 </span>Slices</a></li><li class="tocline"><a href="#example" class="tocxref"><span class="secno">5.3 </span>An example</a></li></ul></li><li class="tocline"><a href="#dsd" class="tocxref"><span class="secno">6. </span>Creating data structure definitions</a><ul class="toc"><li class="tocline"><a href="#dsd-dimensions" class="tocxref"><span class="secno">6.1 </span>Dimensions, attributes and measures</a></li><li class="tocline"><a href="#dsd-cog" class="tocxref"><span class="secno">6.2 </span>Content oriented guidelines</a></li><li class="tocline"><a href="#dsd-example" class="tocxref"><span class="secno">6.3 </span>Example</a></li><li class="tocline"><a href="#dsd-dsd" class="tocxref"><span class="secno">6.4 </span>ComponentSpecifications and DataStructureDefinitions</a></li><li class="tocline"><a href="#dsd-mm" class="tocxref"><span class="secno">6.5 </span>Handling multiple measures</a><ul class="toc"><li class="tocline"><a href="#dsd-mm-obs" class="tocxref"><span class="secno">6.5.1 </span>Multi-measure observations</a></li><li class="tocline"><a href="#dsd-mm-dim" class="tocxref"><span class="secno">6.5.2 </span><span>Measure dimension</span></a></li></ul></li></ul></li><li class="tocline"><a href="#datasets" class="tocxref"><span class="secno">7. </span>Expressing data sets</a><ul class="toc"><li class="tocline"><a href="#dataset-basic" class="tocxref"><span class="secno">7.1 </span>Data sets and observations</a></li></ul></li><li class="tocline"><a href="#slices" class="tocxref"><span class="secno">8. </span>Slices</a></li><li class="tocline"><a href="#schemes" class="tocxref"><span class="secno">9. </span>Concept schemes and code lists</a><ul class="toc"><li class="tocline"><a href="#schemes-intro" class="tocxref"><span class="secno">9.1 </span>Coded values for components properties</a></li><li class="tocline"><a href="#schemes-hierarchy" class="tocxref"><span class="secno">9.2 </span>Hierarchical code lists</a></li><li class="tocline"><a href="#schemes-hierarchy-nonskos" class="tocxref"><span class="secno">9.3 </span>Non-SKOS hierarchies</a></li><li class="tocline"><a href="#schemes-aggregation" class="tocxref"><span class="secno">9.4 </span>Aggregation</a></li></ul></li><li class="tocline"><a href="#metadata" class="tocxref"><span class="secno">10. </span>DataSet metadata</a><ul class="toc"><li class="tocline"><a href="#metadata-categorization" class="tocxref"><span class="secno">10.1 </span>Categorizing a data set</a></li><li class="tocline"><a href="#metadata-publishers" class="tocxref"><span class="secno">10.2 </span>Describing publishers</a></li></ul></li><li class="tocline"><a href="#normalize" class="tocxref"><span class="secno">11. </span>Abbreviated and normalized data cubes</a><ul class="toc"><li class="tocline"><a href="#normalize-algorithm" class="tocxref"><span class="secno">11.1 </span>Normalization algorithm</a></li></ul></li><li class="tocline"><a href="#wf" class="tocxref"><span class="secno">12. </span>Well-formed cubes</a><ul class="toc"><li class="tocline"><a href="#wf-rules" class="tocxref"><span class="secno">12.1 </span>Integrity constraints</a></li></ul></li><li class="tocline"><a href="#vocab-reference" class="tocxref"><span class="secno">13. </span>Vocabulary reference</a><ul class="toc"><li class="tocline"><a href="#reference-datasets" class="tocxref"><span class="secno">13.1 </span>DataSets</a></li><li class="tocline"><a href="#reference-observations" class="tocxref"><span class="secno">13.2 </span>Observations</a></li><li class="tocline"><a href="#reference-slices" class="tocxref"><span class="secno">13.3 </span>Slices</a></li><li class="tocline"><a href="#reference-components" class="tocxref"><span class="secno">13.4 </span>Dimensions, Attributes, Measures</a></li><li class="tocline"><a href="#reference-component-properties" class="tocxref"><span class="secno">13.5 </span>Reusable general purpose component properties</a></li><li class="tocline"><a href="#reference-dsd" class="tocxref"><span class="secno">13.6 </span>Data Structure Definitions</a></li><li class="tocline"><a href="#reference-compspec" class="tocxref"><span class="secno">13.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">13.8 </span>Slice definitions</a></li><li class="tocline"><a href="#reference-concepts" class="tocxref"><span class="secno">13.9 </span>Concepts</a></li><li class="tocline"><a href="#reference-nonskos-hierarchy" class="tocxref"><span class="secno">13.10 </span>Non-SKOS Hierarchies</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#change-history" class="tocxref"><span class="secno">B. </span>Change history </a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></section>
+</section><section id="toc"><h2 class="introductory">Table of Contents</h2><ul class="toc"><li class="tocline"><a href="#outline" class="tocxref"><span class="secno">1. </span>Outline of the vocabulary</a><ul class="toc"><li class="tocline"><a href="#index" class="tocxref"><span class="secno">1.1 </span>Vocabulary index</a></li></ul></li><li class="tocline"><a href="#introduction" class="tocxref"><span class="secno">2. </span>Introduction</a><ul class="toc"><li class="tocline"><a href="#intro-rdf" class="tocxref"><span class="secno">2.1 </span>RDF and Linked Data</a></li><li class="tocline"><a href="#intro-sdmx" class="tocxref"><span class="secno">2.2 </span>SDMX and related standards</a></li><li class="tocline"><a href="#intro-audience" class="tocxref"><span class="secno">2.3 </span>Audience and scope</a></li></ul></li><li class="tocline"><a href="#namespaces" class="tocxref"><span class="secno">3. </span>Namespaces and Document Conventions</a></li><li class="tocline"><a href="#conformance" class="tocxref"><span class="secno">4. </span>Conformance</a></li><li class="tocline"><a href="#data-cubes" class="tocxref"><span class="secno">5. </span>Data cubes</a><ul class="toc"><li class="tocline"><a href="#cubes-model" class="tocxref"><span class="secno">5.1 </span>The cube model - dimensions, attributes, measures</a></li><li class="tocline"><a href="#cubes-slices" class="tocxref"><span class="secno">5.2 </span>Introducing Slices</a></li><li class="tocline"><a href="#example" class="tocxref"><span class="secno">5.3 </span>An example</a></li></ul></li><li class="tocline"><a href="#dsd" class="tocxref"><span class="secno">6. </span>Creating data structure definitions</a><ul class="toc"><li class="tocline"><a href="#dsd-dimensions" class="tocxref"><span class="secno">6.1 </span>Dimensions, attributes and measures</a></li><li class="tocline"><a href="#dsd-cog" class="tocxref"><span class="secno">6.2 </span>Content oriented guidelines</a></li><li class="tocline"><a href="#dsd-example" class="tocxref"><span class="secno">6.3 </span>Example</a></li><li class="tocline"><a href="#dsd-dsd" class="tocxref"><span class="secno">6.4 </span>ComponentSpecifications and DataStructureDefinitions</a></li><li class="tocline"><a href="#dsd-mm" class="tocxref"><span class="secno">6.5 </span>Handling multiple measures</a><ul class="toc"><li class="tocline"><a href="#dsd-mm-obs" class="tocxref"><span class="secno">6.5.1 </span>Multi-measure observations</a></li><li class="tocline"><a href="#dsd-mm-dim" class="tocxref"><span class="secno">6.5.2 </span><span>Measure dimension</span></a></li></ul></li></ul></li><li class="tocline"><a href="#datasets" class="tocxref"><span class="secno">7. </span>Expressing data sets</a><ul class="toc"><li class="tocline"><a href="#dataset-basic" class="tocxref"><span class="secno">7.1 </span>Data sets and observations</a></li><li class="tocline"><a href="#slices" class="tocxref"><span class="secno">7.2 </span>Slices and groups of observations</a></li></ul></li><li class="tocline"><a href="#schemes" class="tocxref"><span class="secno">8. </span>Concept schemes and code lists</a><ul class="toc"><li class="tocline"><a href="#schemes-intro" class="tocxref"><span class="secno">8.1 </span>Coded values for components properties</a></li><li class="tocline"><a href="#schemes-hierarchy" class="tocxref"><span class="secno">8.2 </span>Hierarchical code lists</a></li><li class="tocline"><a href="#schemes-hierarchy-nonskos" class="tocxref"><span class="secno">8.3 </span>Non-SKOS hierarchies</a></li><li class="tocline"><a href="#schemes-aggregation" class="tocxref"><span class="secno">8.4 </span>Aggregation</a></li></ul></li><li class="tocline"><a href="#metadata" class="tocxref"><span class="secno">9. </span>DataSet metadata</a><ul class="toc"><li class="tocline"><a href="#metadata-categorization" class="tocxref"><span class="secno">9.1 </span>Categorizing a data set</a></li><li class="tocline"><a href="#metadata-publishers" class="tocxref"><span class="secno">9.2 </span>Describing publishers</a></li></ul></li><li class="tocline"><a href="#normalize" class="tocxref"><span class="secno">10. </span>Abbreviated and normalized data cubes</a><ul class="toc"><li class="tocline"><a href="#normalize-algorithm" class="tocxref"><span class="secno">10.1 </span>Normalization algorithm</a></li></ul></li><li class="tocline"><a href="#wf" class="tocxref"><span class="secno">11. </span>Well-formed cubes</a><ul class="toc"><li class="tocline"><a href="#wf-rules" class="tocxref"><span class="secno">11.1 </span>Integrity constraints</a></li></ul></li><li class="tocline"><a href="#vocab-reference" class="tocxref"><span class="secno">12. </span>Vocabulary reference</a><ul class="toc"><li class="tocline"><a href="#reference-datasets" class="tocxref"><span class="secno">12.1 </span>DataSets</a></li><li class="tocline"><a href="#reference-observations" class="tocxref"><span class="secno">12.2 </span>Observations</a></li><li class="tocline"><a href="#reference-slices" class="tocxref"><span class="secno">12.3 </span>Slices</a></li><li class="tocline"><a href="#reference-components" class="tocxref"><span class="secno">12.4 </span>Dimensions, Attributes, Measures</a></li><li class="tocline"><a href="#reference-component-properties" class="tocxref"><span class="secno">12.5 </span>Reusable general purpose component properties</a></li><li class="tocline"><a href="#reference-dsd" class="tocxref"><span class="secno">12.6 </span>Data Structure Definitions</a></li><li class="tocline"><a href="#reference-compspec" class="tocxref"><span class="secno">12.7 </span>Component specifications - for qualifying component use in a DSD</a></li><li class="tocline"><a href="#reference-slice-definitions" class="tocxref"><span class="secno">12.8 </span>Slice definitions</a></li><li class="tocline"><a href="#reference-concepts" class="tocxref"><span class="secno">12.9 </span>Concepts</a></li><li class="tocline"><a href="#reference-nonskos-hierarchy" class="tocxref"><span class="secno">12.10 </span>Non-SKOS Hierarchies</a></li></ul></li><li class="tocline"><a href="#acknowledgements" class="tocxref"><span class="secno">A. </span>Acknowledgements</a></li><li class="tocline"><a href="#change-history" class="tocxref"><span class="secno">B. </span>Change history </a></li><li class="tocline"><a href="#references" class="tocxref"><span class="secno">C. </span>References</a><ul class="toc"><li class="tocline"><a href="#normative-references" class="tocxref"><span class="secno">C.1 </span>Normative references</a></li><li class="tocline"><a href="#informative-references" class="tocxref"><span class="secno">C.2 </span>Informative references</a></li></ul></li></ul></section>
@@ -408,7 +408,7 @@
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 <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/TR/REC-rdf-syntax/">RDF</a>
+using the <abbr title="World Wide Web Consortium">W3C</abbr> <a href="http://www.w3.org/TR/REC-rdf-syntax/">RDF</a>
(Resource Description Framework) standard and published following the
principles of
<a href="http://linkeddata.org/">linked data</a>.
@@ -646,7 +646,7 @@
<section id="cubes-slices" class="informative">
-<h3><span class="secno">5.2 </span>Slices</h3><p><em>This section is non-normative.</em></p>
+<h3><span class="secno">5.2 </span>Introducing Slices</h3><p><em>This section is non-normative.</em></p>
<p>It is frequently useful to group subsets of observations within a
dataset. In particular to fix all but one (or a small subset) of the
@@ -871,7 +871,7 @@
appropriate range checking.</p>
<p>Note that in any SDMX extension vocabulary there would be one further item of information to encode
- about components - the role that they play within the structure definition. In particular, is sometimes
+ about components - the role that they play within the structure definition. In particular, it is sometimes
convenient for consumers to be able to easily identify which is the time dimension,
which component is the primary measure and so forth. It turns out that such roles are intrinsic to
the concepts and so this information can encoded by providing subclasses of <code>skos:Concept</code>
@@ -888,8 +888,8 @@
<p>The SDMX standard includes a set of <em>content oriented guidelines</em> (COG) [<cite><a class="bibref" href="#bib-COG">COG</a></cite>]
which define a set of common statistical concepts and associated code lists that are intended to be
- reusable across data sets. A <a href="https://code.google.com/p/publishing-statistical-data/">community group</a> has developed, and
- maintains, RDF encodings of these guidelines. These comprise:
+ reusable across data sets. A <a href="https://code.google.com/p/publishing-statistical-data/">community group</a>
+ has developed RDF encodings of these guidelines. These comprise:
</p><table id="namespaces-table">
<thead><tr><th>Prefix</th><th>Namespace</th><th>Description</th></tr></thead>
@@ -983,9 +983,9 @@
<ul>
<li>Attributes may be declared as optional or required. If an
attribute is required to be present for every observation then the specification should set
- <code></code>. In the
+ <code><a>qb:componentRequired></a></code>. In the
absence of such a declaration an attribute is assumed to be
- optional. The <code><a>qb:componentRequired></a></code>
+ optional. The <code><a href="#dfn-qb-componentrequired" class="internalDFN">qb:componentRequired</a></code>
declaration may only be applied to component specifications of
attributes - measures and dimensions are always required.</li>
<li>The components may be ordered by giving an integer value for <code><a href="#dfn-qb-order" class="internalDFN">qb:order</a></code>.
@@ -1106,8 +1106,12 @@
<p>To use this representation you declare an additional dimension within the data structure
definition to play the role of the measure dimension. For use within the Data Cube vocabulary
we provide a single distinguished component for this purpose -- <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code>.
- 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.
+ An extension vocabulary could generalize this through the provision of roles to
+ identify concepts which
+ act as measure types, enabling other measure dimensions to be declared.
+</p>
+
+ <p>
In the special case of using <code><a href="#dfn-qb-measuretype" class="internalDFN">qb:measureType</a></code> as the measure dimension, the set of allowed
measures is assumed to be those measures declared within the DSD. There is no need to
define a separate code list or enumerated class to duplicate this information.
@@ -1171,7 +1175,7 @@
<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 5.2</a>.
+ as described earlier in <a href="#slices">section 7.2</a>.
</dd><dt>Internal metadata</dt>
<dd>Having located an observation, we need certain metadata in order to be able to interpret it.
@@ -1183,7 +1187,7 @@
<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 10</a>.</dd>
+ External metadata is described in <a href="#metadata">section 9</a>.</dd>
</dl>
@@ -1287,11 +1291,9 @@
in the next section.</p>
</section>
-</section>
-
<section id="slices">
-<!--OddPage--><h2><span class="secno">8. </span>Slices</h2>
+<h3><span class="secno">7.2 </span>Slices and groups of observations</h3>
<p>Slices allow us to group subsets of observations together. This not intended
to represent arbitrary selections from the observations but uniform slices
@@ -1433,12 +1435,14 @@
</p></section>
+</section>
+
<section id="schemes">
-<!--OddPage--><h2><span class="secno">9. </span>Concept schemes and code lists</h2>
+<!--OddPage--><h2><span class="secno">8. </span>Concept schemes and code lists</h2>
<section id="schemes-intro">
-<h3><span class="secno">9.1 </span>Coded values for components properties</h3>
+<h3><span class="secno">8.1 </span>Coded values for components properties</h3>
<p>The values for dimensions within a data set must be unambiguously
defined. They may be typed values (e.g. <code>xsd:dateTime</code> for time instances)
@@ -1514,12 +1518,12 @@
</section>
<section id="schemes-hierarchy">
-<h3><span class="secno">9.2 </span>Hierarchical code lists</h3>
+<h3><span class="secno">8.2 </span>Hierarchical code lists</h3>
<p>In some cases code lists have a hierarchical structure. In particular, this is
used in SDMX when the data cube includes aggregations of data values
(e.g. aggregating a measure across geographic regions).
-Hierarchical code lists lists <em class="rfc2119" title="should">should</em> be represented using the
+Hierarchical code lists <em class="rfc2119" title="should">should</em> be represented using the
<code>skos:narrower</code> relationship to link from the <code>skos:hasTopConcept</code>
codes down through the tree or lattice of child codes.
In some publishing tool chains the corresponding transitive closure
@@ -1530,7 +1534,7 @@
</section>
<section id="schemes-hierarchy-nonskos">
-<h3><span class="secno">9.3 </span>Non-SKOS hierarchies</h3>
+<h3><span class="secno">8.3 </span>Non-SKOS hierarchies</h3>
<p>It is sometimes convenient to be able to specify a hierarchical arrangement of
concepts other than through the use of the SKOS relation <code>skos:narrower</code>.
@@ -1543,13 +1547,22 @@
<li>Where such maintained reference data is to be reused there can be multiple hierarchies which relate
the same codes. In particular a set of geographic entities may participate in both a geographic-containment hierarchy
and an administrative hierarchy which do not precisely align. </li>
-<li>The SKOS relations do not define when the child concepts are disjoint (mutually exclusive) or then they form
+<li>The SKOS relations do not define when the child concepts are disjoint (mutually exclusive) or when they form
a complete cover of the parent concept (exhaustive).</li>
</ul>
<p>The Data Cube vocabulary supports this situation through the <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> class.
An instance of <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> defines a set of root concepts in the hierarchy
-(<code><a href="#dfn-qb-hierarchyroot" class="internalDFN">qb:hierarchyRoot</a></code>) and a parent-to-child relationship (<code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code>).</p>
+(<code><a href="#dfn-qb-hierarchyroot" class="internalDFN">qb:hierarchyRoot</a></code>) and a parent-to-child relationship (<code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code>) which
+links a term in the hierarchy to its immediate sub-terms. </p>
+
+<p>Thus a <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code>
+is similar to a <code>skos:ConceptScheme</code> in which <code><a href="#dfn-qb-hierarchyroot" class="internalDFN">qb:hierarchyRoot</a></code> plays the same
+role as <code>skos:hasTopConcept</code>, and the value of <code><a href="#dfn-qb-parentchildproperty" class="internalDFN">qb:parentChildProperty</a></code> plays
+the same role as <code>skos:narrower</code>. In the case where a code list is already available as a SKOS concept scheme or collection
+then those <em class="rfc2119" title="should">should</em> be used directly; <code><a href="#dfn-qb-hierarchicalcodelist" class="internalDFN">qb:HierarchicalCodeList</a></code> is provided for cases where the
+terms are not available as SKOS but are available in some other RDF representation suitable for reuse.
+</p>
<p>For example, the Ordnance Survey of Great Britain publishes a geographic hierarchy which has
eleven roots (European Regions such as Wales, Scotland, the South West) and uses a spatial relations
@@ -1559,7 +1572,7 @@
eg:GBgeoHierarchy a qb:HierarchicalCodeList;
rdfs:label "Geographic Hierarchy for Great Britain"@en;
- qb:hierarchy Root
+ qb:hierarchyRoot
<http://data.ordnancesurvey.co.uk/id/7000000000041427>, # South West
<http://data.ordnancesurvey.co.uk/id/7000000000041426>, # West Midlands
<http://data.ordnancesurvey.co.uk/id/7000000000041421>, # South East
@@ -1602,7 +1615,7 @@
</section>
<section id="schemes-aggregation">
-<h3><span class="secno">9.4 </span>Aggregation</h3>
+<h3><span class="secno">8.4 </span>Aggregation</h3>
<p>The use of SKOS, or non-SKOS, hierarchies makes it possible to publish aggregated
statistics for the non-leaf concepts in the hierarchy. The Data Cube vocabulary itself imposes
@@ -1621,7 +1634,7 @@
<section id="metadata">
-<!--OddPage--><h2><span class="secno">10. </span>DataSet metadata</h2>
+<!--OddPage--><h2><span class="secno">9. </span>DataSet metadata</h2>
<p>DataSets should be marked up with metadata to support discovery, presentation and
processing. Metadata such as a display label (<code>rdfs:label</code>),
@@ -1631,7 +1644,7 @@
<section id="metadata-categorization">
-<h3><span class="secno">10.1 </span>Categorizing a data set</h3>
+<h3><span class="secno">9.1 </span>Categorizing a data set</h3>
<p>Publishers of statistics often categorize their data sets into different statistical
domains, such as <em>Education</em>, <em>Labour</em>, or <em>Transportation</em>.
@@ -1654,7 +1667,7 @@
dcterms:subject
sdmx-subject:3.2 , # regional and small area statistics
sdmx-subject:1.4 , # Health
- ex-geo:wales_gor_l ; # Wales
+ ex:wales; # Wales
...</pre></div>
<p>where <code>eg:Wales</code> is a <code>skos:Concept</code> drawn from an appropriate controlled
@@ -1663,7 +1676,7 @@
<section id="metadata-publishers">
-<h3><span class="secno">10.2 </span>Describing publishers</h3>
+<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.
@@ -1683,7 +1696,7 @@
</section>
<section id="normalize">
-<!--OddPage--><h2><span class="secno">11. </span>Abbreviated and normalized data cubes</h2>
+<!--OddPage--><h2><span class="secno">10. </span>Abbreviated and normalized data cubes</h2>
<p>In normal form then the <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code>s which
make up a Data Cube have property values for each of the required
@@ -1705,7 +1718,7 @@
In those cases the attached property is taken to be applied to all
the <code><a href="#dfn-qb-observation" class="internalDFN">qb:Observation</a></code> instances associated with that
attachment point. For illustration
-see <a href="attachment-example">example 4</a> in which the unit of
+see <a href="#attachment-example">example 4</a> in which the unit of
measure is declared as to be attached to the whole data set and need
not be repeated for every observation.</p>
@@ -1714,7 +1727,7 @@
to the observations in which that property occurs.</p>
<section id="normalize-algorithm">
-<h3><span class="secno">11.1 </span>Normalization algorithm</h3>
+<h3><span class="secno">10.1 </span>Normalization algorithm</h3>
<div class="note"><div class="note-title"><span>Note</span></div><div class="">
This section is At Risk. The working group believes this formulation to
@@ -1861,7 +1874,7 @@
</section>
<section id="wf">
-<!--OddPage--><h2><span class="secno">12. </span>Well-formed cubes</h2>
+<!--OddPage--><h2><span class="secno">11. </span>Well-formed cubes</h2>
<div class="note"><div class="note-title"><span>Note</span></div><div class="">
This section is At Risk. The working group believes these criteria to
@@ -1884,7 +1897,7 @@
yields a <a>well-formed RDF Data Cube</a>.</p>
<section id="wf-rules">
-<h3><span class="secno">12.1 </span>Integrity constraints</h3>
+<h3><span class="secno">11.1 </span>Integrity constraints</h3>
<p>Each integrity constraint is expressed as narrative prose and, where possible, a SPARQL
[<cite><a class="bibref" href="#bib-SPARQL-QUERY-11">SPARQL-QUERY-11</a></cite>] ASK query or query template. If the ASK query is applied to an RDF graph then it
@@ -2395,11 +2408,11 @@
</section>
<section id="vocab-reference">
-<!--OddPage--><h2><span class="secno">13. </span>Vocabulary reference</h2>
+<!--OddPage--><h2><span class="secno">12. </span>Vocabulary reference</h2>
<section id="reference-datasets">
-<h3><span class="secno">13.1 </span>DataSets</h3>
+<h3><span class="secno">12.1 </span>DataSets</h3>
<p><em>See Section <a href="#datasets">Expressing data sets</a>.</em></p>
@@ -2418,7 +2431,7 @@
<section id="reference-observations">
-<h3><span class="secno">13.2 </span>Observations</h3>
+<h3><span class="secno">12.2 </span>Observations</h3>
<p><em>See Section <a href="#datasets">Expressing data sets</a>.</em></p>
<dl class="vocab_reference">
@@ -2456,7 +2469,7 @@
<section id="reference-slices">
-<h3><span class="secno">13.3 </span>Slices</h3>
+<h3><span class="secno">12.3 </span>Slices</h3>
<p><em>See Section <a href="#slices">Slices</a>.</em></p>
<dl class="vocab_reference">
@@ -2501,7 +2514,7 @@
<section id="reference-components">
-<h3><span class="secno">13.4 </span>Dimensions, Attributes, Measures</h3>
+<h3><span class="secno">12.4 </span>Dimensions, Attributes, Measures</h3>
<p><em>See Section <a href="#dsd-dimensions">Dimensions, attributes and measures</a>.</em></p>
<dl class="vocab_reference">
@@ -2551,7 +2564,7 @@
<section id="reference-component-properties">
-<h3><span class="secno">13.5 </span>Reusable general purpose component properties</h3>
+<h3><span class="secno">12.5 </span>Reusable general purpose component properties</h3>
<p><em>See Section <a href="#dsd-mm-dim">Measure dimensions</a>.</em></p>
<dl class="vocab_reference">
@@ -2569,7 +2582,7 @@
<section id="reference-dsd">
-<h3><span class="secno">13.6 </span>Data Structure Definitions</h3>
+<h3><span class="secno">12.6 </span>Data Structure Definitions</h3>
<p><em>See Section <a href="#dsd-dsd">ComponentSpecifications and DataStructureDefinitions</a>.</em></p>
<dl class="vocab_reference">
@@ -2589,7 +2602,7 @@
<code><a href="#dfn-qb-datastructuredefinition" class="internalDFN">qb:DataStructureDefinition</a></code>
)
</dt>
- <dd>indicates the structure to which this data set conforms</dd>
+ <dd>Indicates the structure to which this data set conforms</dd>
<dt id="ref_qb_component">
<em>Property:</em> <code><dfn id="dfn-qb-component">qb:component</dfn></code>
@@ -2599,13 +2612,13 @@
<code><a href="#dfn-qb-componentspecification" class="internalDFN">qb:ComponentSpecification</a></code>
)
</dt>
- <dd>indicates a component specification which is included in the structure of the dataset.</dd>
+ <dd>Indicates a component specification which is included in the structure of the dataset.</dd>
</dl>
</section>
<section id="reference-compspec">
-<h3><span class="secno">13.7 </span>Component specifications - for qualifying component use in a DSD</h3>
+<h3><span class="secno">12.7 </span>Component specifications - for qualifying component use in a DSD</h3>
<p><em>See Section <a href="#dsd-dsd">ComponentSpecifications and DataStructureDefinitions</a>.</em></p>
<dl class="vocab_reference">
@@ -2661,7 +2674,7 @@
<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>
+ <dd>Indicates the level at which the component property should be attached, this might be an qb:DataSet, qb:Slice or qb:Observation, or a qb:MeasureProperty.</dd>
<dt id="ref_qb_dimension">
<em>Property:</em> <code><dfn id="dfn-qb-dimension">qb:dimension</dfn></code>
@@ -2711,7 +2724,7 @@
<section id="reference-slice-definitions">
-<h3><span class="secno">13.8 </span>Slice definitions</h3>
+<h3><span class="secno">12.8 </span>Slice definitions</h3>
<p><em>See Section <a href="#slices">Slices</a>.</em></p>
<dl class="vocab_reference">
@@ -2747,7 +2760,7 @@
<section id="reference-concepts">
-<h3><span class="secno">13.9 </span>Concepts</h3>
+<h3><span class="secno">12.9 </span>Concepts</h3>
<p><em>See Section <a href="#schemes">Concept schemes and code lists</a>.</em></p>
<dl class="vocab_reference">
@@ -2774,7 +2787,7 @@
</dl></section>
<section id="reference-nonskos-hierarchy">
-<h3><span class="secno">13.10 </span>Non-SKOS Hierarchies</h3>
+<h3><span class="secno">12.10 </span>Non-SKOS Hierarchies</h3>
<p><em>See Section <a href="#schemes-hierarchy-nonskos">Non-SKOS hierarchies</a>.</em></p>
<dl class="vocab_reference">
@@ -2890,4 +2903,3 @@
</dd><dt id="bib-SKOS-PRIMER">[SKOS-PRIMER]</dt><dd>Antoine Isaac; Ed Summers. <a href="http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/"><cite>SKOS Simple Knowledge Organization System Primer.</cite></a> 18 August 2009. W3C Note. URL: <a href="http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/">http://www.w3.org/TR/2009/NOTE-skos-primer-20090818/</a>
</dd><dt id="bib-VOID">[VOID]</dt><dd>Keith Alexander; Richard Cyganiak; Michael Hausenblas; Jun Zhao. <a href="http://www.w3.org/TR/void/"><cite>Describing Linked Datasets with the VoID Vocabulary</cite></a> 03 March 2011. Interest Group Note. URL: <a href="http://www.w3.org/TR/void/">http://www.w3.org/TR/void/</a>
</dd></dl></section></section></body></html>
-