--- a/data-cube/index.html Sat Mar 02 22:53:35 2013 +0000
+++ b/data-cube/index.html Sun Mar 03 13:08:03 2013 +0000
@@ -17,6 +17,7 @@
.spare-table td { padding-left: 1em; padding-right: 1em; }
.spare-table td + td { border-left: black 1px solid; padding-left: 1em; padding-right: 1em; }
.spare-table th + th { border-left: black 1px solid; }
+dl.vocab_reference dt { margin-top: 1em; }
</style>
</head>
@@ -254,12 +255,12 @@
<tr><td>skos</td><td><a href="http://www.w3.org/2004/02/skos/core">http://www.w3.org/2004/02/skos/core#</a></td><td>[[!SKOS-REFERENCE]]</td></tr>
<tr><td>scovo</td><td><a href="http://purl.org/NET/scovo#">http://purl.org/NET/scovo#</a></td><td>[[SCOVO]]</td></tr>
<tr><td>void</td><td><a href="http://rdfs.org/ns/void#">http://rdfs.org/ns/void#</a></td><td>[[VOID]]</td></tr>
- <tr><td>foaf</td><td><a href="http://xmlns.com/foaf/0.1/">http://xmlns.com/foaf/0.1/</a></td><td>[[FOAF]]</td></tr>
+ <tr><td>foaf</td><td><a href="http://xmlns.com/foaf/0.1/">http://xmlns.com/foaf/0.1/</a></td><td>[[FOAF]] Non-normative, used for examples only.</td></tr>
<tr><td>dct</td><td><a href="http://purl.org/dc/terms/">http://purl.org/dc/terms/</a></td><td>[[DC11]]</td></tr>
<tr><td>owl</td><td><a href="http://www.w3.org/2002/07/owl">http://www.w3.org/2002/07/owl#</a></td><td>[[!OWL2-PRIMER]]</td></tr>
<tr><td>rdf</td><td><a href="http://www.w3.org/1999/02/22-rdf-syntax-ns">http://www.w3.org/1999/02/22-rdf-syntax-ns#</a></td><td>[[!RDF-CONCEPTS]]</td></tr>
<tr><td>rdfs</td><td><a href="http://www.w3.org/2000/01/rdf-schema">http://www.w3.org/2000/01/rdf-schema#</a></td><td>[[!RDF-SCHEMA]]</td></tr>
- <tr><td>admingeo</td><td><a href="http://data.ordnancesurvey.co.uk/ontology/admingeo/">http://data.ordnancesurvey.co.uk/ontology/admingeo/</a></td><td></td></tr>
+ <tr><td>admingeo</td><td><a href="http://data.ordnancesurvey.co.uk/ontology/admingeo/">http://data.ordnancesurvey.co.uk/ontology/admingeo/</a></td><td>Non-normative, used for examples only.</td></tr>
</tbody>
</table>
@@ -499,6 +500,8 @@
<a href='#ref_qb_Slice'>qb:Slice</a>
<a href='#ref_qb_ObservationGroup'>qb:ObservationGroup</a>
<a href='#ref_qb_SliceKey'>qb:SliceKey</a>
+ <a href='#ref_qb_Hierarchy'>qb:Hierarchy</a>
+ <a href='#ref_qb_AggregatableHierarchy'>qb:AggregatableHierarchy</a>
</p>
<p><b>Properties:</b>
<a href='#ref_qb_attribute'>qb:attribute</a>
@@ -520,6 +523,9 @@
<a href='#ref_qb_sliceStructure'>qb:sliceStructure</a>
<a href='#ref_qb_structure'>qb:structure</a>
<a href='#ref_qb_observationGroup'>qb:observationGroup</a>
+ <a href='#ref_qb_hierarchyRoot'>qb:hierarchyRoot</a>
+ <a href='#ref_qb_narrowingProperty'>qb:narrowingProperty</a>
+ <a href='#ref_qb_broadeningProperty'>qb:broadeningProperty</a>
</p>
</section>
@@ -1179,6 +1185,9 @@
<section id="schemes">
<h2>Concept schemes and code lists</h2>
+<section id="schemes-intro">
+<h3>Coded values for components properties</h3>
+
<p>The values for dimensions within a data set must be unambiguously
defined. They may be typed values (e.g. <code>xsd:dateTime</code> for time instances)
or codes drawn from some code list. Similarly, many attributes
@@ -1192,7 +1201,7 @@
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>
+ set of admissible values using <code>skos:ConceptScheme</code> or <code>skos:Collection</code>.</p>
<p>We illustrate this with an example drawn from the translation of the SDMX COG
code list for gender, as used already in our worked example. The relevant subset of this code list is:</p>
@@ -1254,7 +1263,11 @@
<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>
-
+</section>
+
+<section id="schemes-hierarchy">
+<h3>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).
@@ -1268,6 +1281,87 @@
All items are linked to the scheme via <code>skos:inScheme</code>.</p>
</section>
+<section id="schemes-hierarchy-nonskos">
+<h3>Non-skos hierarchies</h3>
+
+<div class="note">
+This section is At Risk. It is a new addition since the previous
+working draft and may be withdrawn in the light of further feedback.
+</div>
+
+<p>It is sometimes convenient to be able to specify a hierarchical arrangement of
+concepts other than through the use of the SKOS relation <code>skos:narrower</code>.
+There are several situations where this is useful:</p>
+
+<ul>
+<li>In some cases publishers wish to be able to reuse existing reference data as their
+code lists. This particularly occurs where a geographic or admin-geographic hierarchy
+is already maintained by a separate authority but which uses non-SKOS containment or part-of relationships.</li>
+<li>Where such maintained reference data is to be reused there can be multiple hierarchies which relate
+the same codes. In particular a set of geographic entities may participate in both a geographic-containment hierarchy
+and an administrative hierarchy which do not precisely align. </li>
+<li>The SKOS relations do not define when the child concepts are disjoint (mutually exclusive) or then they form
+a complete cover of the parent concept (exhaustive).</li>
+</ul>
+
+<p>The Data Cube vocabulary supports this situation through the <code>qb:Hierarchy</code> class.
+An instance of <code>qb:Hierarchy</code> defines a set of root concepts in the hierarchy
+(<code>qb:hierarchyRoot</code>) and either a parent-to-child relationship (<code>qb:narrowingProperty</code>)
+or a child-to-parent relationship (<code>qb:broadeningProperty</code>), or both.<p>
+
+<p>For example, the Ordnance Survey of Great Britain publishes a geographic hierarchy which has
+eleven roots (European Regions such as Wales, Scotland, the South West) and uses a spatial relations
+ontology to define a containment hierarchy. This could be represented as a <code>qb:Hierarchy</code> using the following.</p>
+
+<pre class="example">
+PREFIX spatial: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
+
+eg:GBgeoHierarchy a qb:Hierarchy;
+ rdfs:label "Geographic Hierarchy for Great Britain"@en;
+ qb:hierarchy Root
+ <http://data.ordnancesurvey.co.uk/id/7000000000041427>, # South West
+ <http://data.ordnancesurvey.co.uk/id/7000000000041426>, # West Midlands
+ <http://data.ordnancesurvey.co.uk/id/7000000000041421>, # South East
+ <http://data.ordnancesurvey.co.uk/id/7000000000041430>, # Yorkshire & the Humber
+ <http://data.ordnancesurvey.co.uk/id/7000000000041423>, # East Midlands
+ <http://data.ordnancesurvey.co.uk/id/7000000000041425>, # Eastern
+ <http://data.ordnancesurvey.co.uk/id/7000000000041428>, # London
+ <http://data.ordnancesurvey.co.uk/id/7000000000041431>, # North West
+ <http://data.ordnancesurvey.co.uk/id/7000000000041422>, # North East
+ <http://data.ordnancesurvey.co.uk/id/7000000000041424>, # Wales
+ <http://data.ordnancesurvey.co.uk/id/7000000000041429>; # Scotland
+ qb:narrowingProperty spatial:contains;
+ qb:broadeningProperty spatial:within;
+ .
+
+eg:geoDimension a qb:DimensionProperty ;
+ qb:codeList eg:GBgeoHierarchy .
+</pre>
+
+<p>A sub class of <code>qb:Hierarchy</code>, <code>qb:AggregatableHierarchy</code>, is provided to declare
+hierarchies where for each parent concept the set of child concepts form a disjoint cover (i.e. a
+mutually-exclusive and exhaustive decomposition) of the parent.</p>
+
+</section>
+
+<section id="schemes-aggregation">
+<h3>Aggregation</h3>
+
+<p>The use of SKOS, or non-SKOS, hierarchies makes it possible to publish aggregated
+statistics for the non-leaf concepts in the hierarchy. The Data Cube vocabulary itself imposes
+no constraints on how such aggregation is done. Indeed in statistical applications the
+appropriate statistical corrections to make to aggregated values may be non-trivial and dependent on
+the data and precise analysis methodology. Even in simple, non-statistical, applications such
+as OLAP a number of different aggregation operators are commonly used.
+</p>
+
+<p>Vocabulary terms to represent the aggregation operations employed within a given dataset, and how one dataset
+might be derived from another, are not supported in this version of the Data Cube specification. This
+area may be addressed by future extensions to Data Cube.</p>
+</section>
+
+</section>
+
<section id="metadata">
<h2>DataSet metadata</h2>
@@ -1682,7 +1776,7 @@
<code>skos:Concept</code>
)
</dt>
- <dd>gives the concept which is being measured or indicated by a ComponentProperty</dd>
+ <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>
@@ -1692,7 +1786,53 @@
<code>owl:unionOf(skos:ConceptScheme skos:Collection qb:Hierarchy)</code>
)
</dt>
- <dd>gives the code list associated with a CodedProperty</dd>
+ <dd>Gives the code list associated with a CodedProperty.</dd>
+</section>
+
+<section id="reference-nonskos-hierarchy">
+<h3>Non-SKOS Hierarchies</h3>
+<dl class='vocab_reference'>
+
+ <dt id="ref_qb_Hierarchy">
+ <em>Class:</em> <code>qb:Hierarchy</code>
+ </dt>
+ <dd>Represents a generalized hierarchy of concepts which can be used for coding. The hierarchy is defined by one or more roots together with a property which relates concepts in the hierarchy to either their parent or their child concept. At least one of <code>qb:narrowingProperty</code> or <code>qb:broadeningProperty</code> must be specified, it is permissible to provide both. The same concepts may be members of multiple hierarchies provided that different qb:[narrowing/broadening]Property values are using for each hierarchy.</dd>
+
+ <dt id="ref_qb_hierarchyRoot">
+ <em>Property:</em> <code>qb:hierarchyRoot</code>
+ (
+ <code>qb:Hierarchy</code>
+ ->
+ <code>skos:Concept</code>
+ )
+ </dt>
+ <dd>Specifies a root of the hierarchy. A hierarchy may have multiple roots but must have at least one.</dd>
+
+ <dt id="ref_qb_narrowingProperty">
+ <em>Property:</em> <code>qb:narrowingProperty</code>
+ (
+ <code>qb:Hierarchy</code>
+ ->
+ <code>rdf:Property</code>
+ )
+ </dt>
+ <dd>Specifies a property which relates a parent concept in the hierarchy to a child concept. One of <code>qb:narrowingProperty</code> or <code>qb:broadeningProperty</code> must be given but it is not necessary to have both. Note that a child may have more than one parent.</dd>
+
+ <dt id="ref_qb_broadeningProperty">
+ <em>Property:</em> <code>qb:broadeningProperty</code>
+ (
+ <code>qb:Hierarchy</code>
+ ->
+ <code>rdf:Property</code>
+ )
+ </dt>
+ <dd>Specifies a property which relates a child concept in the hierarchy to a parent concept. One of <code>qb:narrowingProperty</code> or <code>qb:broadeningProperty</code> must be given but it is not necessary to have both. Note that a child may have more than one parent.</dd>
+
+ <dt id="ref_qb_AggregatableHierarchy">
+ <em>Class:</em> <code>qb:AggregatableHierarchy</code>
+ </dt>
+ <dd>Indicates a hierarchy in which each parent concept is a disjoint union of its child concepts. So that measures such as simple counts may be aggregated up the hierarchy.</dd>
+
</dl>
</section>
@@ -1742,26 +1882,6 @@
cube-publishers should adhere to facilitate tool interoperability.</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>
-
- <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>
-
</section>
<section id="acknowledgements" class="appendix">
@@ -1770,9 +1890,12 @@
Changes since <a href="http://www.w3.org/TR/2012/WD-vocab-data-cube-20120405/">W3C Working Draft 5 April 2012</a>:
<ul>
- <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>Added <a href="#schemes-hierarchy-nonskos">section</a> on non-skos hierarchies. <a href="http://www.w3.org/2011/gld/track/issues/31">ISSUE-31</a>.</li>
+ <li>Added <a href="#schemes-aggregation">note</a> that aggregation operations and inter-cube relations are out of scope for this version. <a href="http://www.w3.org/2011/gld/track/issues/30">ISSUE-30</a>.</li>
+ <li>Added <code>qb:ObservationGroup</code> as a generalization of <code>qb:Slice</code>. <a href="http://www.w3.org/2011/gld/track/issues/33">ISSUE-33</a>.</li>
+ <li>Removed <code>qb:subSlice</code> as being problematic in how
+ they interact with attachment levels. <a href="http://www.w3.org/2011/gld/track/issues/34">ISSUE-34</a>.</li>
+ <li>Generalized range of <code>qb:codeList</code> to allow <code>skos:Collection</code>. <a href="http://www.w3.org/2011/gld/track/issues/39">ISSUE-39</a>.</li>
<li>Moved namespace definitions to a normative <a href="#namespaces">section</a> within the body of the specification.</li>
<li>Moved Jeni Tennison from being listed as an author to being a
contributor. Currently this has been done by listing her in the