--- a/data-cube/index.html Tue Mar 05 11:19:32 2013 +0000
+++ b/data-cube/index.html Tue Mar 05 14:05:38 2013 +0000
@@ -40,7 +40,7 @@
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>
+statistical data flows or other multi-dimensional data sets.</p>
</section>
<section id="sotd">
@@ -150,10 +150,10 @@
<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://purl.org/dc/terms/">Dublin Core Terms</a> for metadata</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>
+ <li><a href="http://xmlns.com/foaf/0.1/">FOAF</a> for agents</li>
+ <li><a href="http://www.w3.org/ns/org#">ORG</a> for organizations</li>
</ul>
</section>
@@ -225,9 +225,7 @@
syntax) and SDMX-EDI.
</p>
<div class="note">
- Richard - next para will need updating if we move to
- 2.1.
- Should the SDMX reference be categorized as normative?
+ Next para will need updating if we move to 2.1.
</div>
<p>The RDF Data Cube vocabulary builds upon the core of the
@@ -271,7 +269,7 @@
<p>
The design of the Data Cube vocabulary is informed by SCOVO,
-and every SCOVO dataset can be re-expressed within the vocabulary.
+and every SCOVO dataset can be re-expressed within the Data Cube vocabulary.
</p>
</section>
@@ -283,7 +281,7 @@
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>
+formats such as SDMX-ML are not covered here.</p>
</section>
@@ -315,7 +313,8 @@
<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]] <em>(Non-normative, used for examples only)</em></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>org</td><td><a href="http://www.w3.org/ns/org#">http://www.w3.org/ns/org#</a></td><td>[[ORG]]</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>
@@ -391,7 +390,7 @@
<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
+measure, any scaling factors and metadata such as the status
of the observation (e.g. <em>estimated</em>, <em>provisional</em>).</p>
</section>
@@ -668,14 +667,14 @@
</table>
<p>These resources are provided as a convenience and do not form part
- of the RDF Data Cube standard at this time. However, they are used
- by a number of existing RDF Data Cube publications and so we will
+ of the Data Cube standard at this time. However, they are used
+ by a number of existing Data Cube publications and so we will
reference them within our worked examples.</p>
</section>
-<section id="dsd-example">
+<section id="dsd-example" class="informative">
<h3>Example</h3>
<p>Turning to our example data set then we can see there are three dimensions to represent
@@ -750,11 +749,11 @@
<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>qb:componentRequired "true"^^xsd:boolean</code>. In the
+ <code></code>. In the
absence of such a declaration an attribute is assumed to be
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>
+ 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>.
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
@@ -787,12 +786,14 @@
# 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:componentRequired "true"^^xsd:boolean;
+ qb:componentAttachment qb:DataSet;] .</pre>
<p>Note that we have given the data structure definition (DSD) a URI since it will be
reused across different datasets with the same structure. Similarly the component properties
themselves can be reused across different DSDs. However, the component specifications
- are only useful within the scope of a particular DSD and so we have chosen the represent
+ are only useful within the scope of a particular DSD and so we have chosen to represent
them using blank nodes.
</p>
</section>
@@ -824,7 +825,7 @@
<h4>Multi-measure observations</h4>
<p> This approach allows multiple observed values to be attached
- to an individual observation. Is suited to representation of things like sensor data and OLAP cubes.
+ to an individual observation. It is suited to representation of things like sensor data and OLAP cubes.
To use this representation you simply declare multiple <code><a>qb:MeasureProperty</a></code> components
in the data structure definition and attach an instance of each property to the observations within
the data set.</p>
@@ -879,7 +880,7 @@
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.
- Thus, qb:measureType is a “magic” dimension property with an implicit code list.</p>
+ Thus, <code><a>qb:measureType</a></code> 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 class="example">
@@ -916,9 +917,9 @@
<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>
+ measures, those individual measures are used directly. Extension vocabularies
+ could address the round-tripping of the SDMX primary measure by use of a
+ separate annotation on the data structure definition.
</section>
</section>
@@ -941,7 +942,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 2.2</a>.
+ as described earlier in <a href="#cubes-slices">section 5.2</a>.
<dt>Internal metadata</dt>
<dd>Having located an observation, we need certain metadata in order to be able to interpret it.
@@ -953,7 +954,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 9</a>.</dd>
+ External metadata is described in <a href="#metadata">section 11</a>.</dd>
</dl>
@@ -971,7 +972,7 @@
<p>Each observation is represented as an instance of type <code><a>qb:Observation</a></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><a>qb:dataSet</a></code> property. For example:</p>
+ data set using the <code><a>qb:dataSet</a></code> property. </p>
<p>Thus for our running example we might expect to have:</p>
@@ -1012,13 +1013,13 @@
...
</pre>
-<p>This <em>flattened</em> structure makes it easy to query and combine data sets
+<p>This <a>flattened</a> 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 an improved version of the example is:</p>
<pre class="example">
eg:dataset-le1 a qb:DataSet;
@@ -1271,7 +1272,7 @@
<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
+The SKOS specification [[!SKOS-REFERENCE]] recommends the generation of a custom datatype for
each use of <code>skos:notation</code> but here the notation is not intended for use
within RDF encodings, it merely documents the notation used in other representations
(which do not use such a datatype).</p>
@@ -1303,7 +1304,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 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
@@ -1468,8 +1469,8 @@
rdfs:label "Example org" .
</pre>
-<p>Note that the SDMX extension vocabulary supports further description of
- publication pipelines (data flows, reporting taxonomies, maintainers, provision agreements).</p>
+<p>Extension vocabularies may provide additional metadata properties and may impose
+ constraints on what metadata must be provided.</p>
</section>
</section>
@@ -1493,15 +1494,18 @@
an <em><dfn>abbreviated</dfn></em> format in which component
properties may be <em><dfn>attached</dfn></em> to other levels in the
Data Cube. Specifically they may be attached to
-a <code><a>qb:DataSet</a></code>, <code><a>qb:Slice</a></code>
-or <code><a>qb:MeasureProperty</a></code>. In those cases the
-attached property is taken to be applied to all
+a <code><a>qb:DataSet</a></code> or <code><a>qb:Slice</a></code>.
+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
measure is declared as to be attached to the whole data set and need
not be repeated for every observation.</p>
+<p>It is also possible to attach attributes to a <code><a>qb:MeasureProperty</a></code>
+ in which case the attribute is intended to apply only to that property and not
+ to the observations in which that property occurs.</p>
+
<p>We define these notions by means of a transformation algorithm
which can normalize an abbreviated Data Cube to a flattened
representation. We express this transformation using the SPARQL 1.1
@@ -1516,8 +1520,8 @@
<h3>Normalization algorithm</h3>
<p>The normalization algorithm comprises two sets of SPARQL Update
- operations which should be applied in turn to a Dataset in which the
- default graph contains the Data Cube graph to be normalized.</p>
+ operations which should be applied in turn to a SPARQL Dataset in which the
+ default graph contains the Data Cube RDF graph to be normalized.</p>
<p>The first update operation performs selective type and property closure
operations. These serve two purposes. They ensure
@@ -1582,16 +1586,15 @@
<p>These closure operations are implied by the RDFS semantics of the
- Data Cube vocabulary. Data Cube processors may apply full RDFS
+ Data Cube vocabulary. Data Cube processors MAY apply full RDFS
closure in place of the update operation defined here.</p>
<p>The second update operation checks the components of the data
structure definition of the data set for declared attachment levels.
- For each of the possible attachments levels
- (<code><a>qb:DataSet</a></code>, <code><a>qb:Slice</a></code>
- and <code><a>qb:MeasureProperty</a></code>) it looks for occurrences
+ For each of the possible attachments levels it looks for occurrences
of that component to be flattened down to the corresponding
- observations. </p>
+ observations.
+</p>
<table class="bordered-table">
<thead>
@@ -1634,20 +1637,6 @@
qb:slice ?slice .
?slice ?comp ?value;
qb:observation ?obs .
-};
-
-# Measure property attachments
-INSERT {
- ?obs ?comp ?value
-} WHERE {
- ?spec qb:componentProperty ?comp ;
- qb:componentAttachment qb:MeasureProperty .
- ?dataset qb:structure [qb:component ?spec] .
- ?comp a qb:AttributeProperty .
- ?measure a qb:MeasureProperty;
- ?comp ?value .
- ?obs qb:dataSet ?dataset;
- ?measure [] .
}
</pre>
</td></tr></tbody>
@@ -1663,8 +1652,8 @@
<div class="note">
This section is At Risk. The working group believes these criteria to
-be correct and compatible with earlier versions of the RDF Data Cube vocabulary.
-However as a new addition they not received as much
+be correct and compatible with earlier versions of the Data Cube vocabulary.
+However as a new addition they have not received as much
scrutiny as other parts of the specification. If problems are uncovered
during the Last Call process the working group may retract all or part of this section.
</div>
@@ -1678,21 +1667,23 @@
<p>A <dfn>well-formed abbreviated</dfn> RDF Data Cube is an a RDF
graph which, when expanded using
- the <a href="#normalize-algorithm">normalization algorithm</a>
+ the <a href="#normalize-algorithm">normalization algorithm</a>,
yields a <a>well-formed RDF Data Cube</a>.</p>
<section id="wf-rules">
<h3>Integrity constraints</h3>
<p>Each integrity constraint is expressed as narrative prose and, where possible, a SPARQL
- [[!SPARQL-QUERY-11]]. If the ASK query is applied to an RDF graph then it
- will return <em>true</em> if that graph contains one or more RDF Data Cube instances which
+ [[!SPARQL-QUERY-11]] ASK query or query template. If the ASK query is applied to an RDF graph then it
+ will return <em>true</em> if that graph contains one or more Data Cube instances which
violate the corresponding constraint.
+</p>
+<p>
Using SPARQL queries to
express the integrity constraints does not imply that integrity
checking must be performed this way. Implementations are free
to use alternative query formulations or alternative implementation
- techniques to perform equivalent checks.</p>
+ techniques to perform equivalent checks. </p>
<p>Each integrity constraint query assumes the following set of prefix bindings:</p>
<pre>
@@ -1706,7 +1697,6 @@
<p>The complete set of constraints is listed below.</p>
-jobs
<h4 id="ic-0">IC-0. Datatype consistency</h4>
<p>
The RDF graph must be consistent under RDF D-entailment [[!RDF-MT]]
@@ -1746,7 +1736,7 @@
ASK {
{
# Check dataset has a dsd
- ?dataset a iqb:DataSet .
+ ?dataset a qb:DataSet .
FILTER NOT EXISTS { ?dataset qb:structure ?dsd . }
} UNION {
# Check has just one dsd
@@ -1783,7 +1773,7 @@
<tr><td><pre>
ASK {
?dim a qb:DimensionProperty .
- FILTER NOT EXISTS { ?dim rdfs:range ?range }
+ FILTER NOT EXISTS { ?dim rdfs:range [] }
}
</td></pre></tr>
</tbody>
@@ -1809,7 +1799,7 @@
<p>
The only components of
a <code><a>qb:DataStructureDefinition</a></code> that may be marked as
-optional, using <code><a>qb:componentRequired</a> false</code> are attributes.
+optional, using <code><a>qb:componentRequired</a></code> are attributes.
</p>
<table class="bordered-table">
@@ -1910,7 +1900,7 @@
ASK {
?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
?dim a qb:DimensionProperty;
- FILTER NOT EXISTS { ?obs ?.dim [] }
+ FILTER NOT EXISTS { ?obs ?dim [] }
}
</td></pre></tr>
</tbody>
@@ -1933,7 +1923,7 @@
FILTER (?obs1 != ?obs2)
?dataset qb:structure/qb:component/qb:componentProperty ?dim .
?dim a qb:DimensionProperty .
- ) ?obs1 ?dim ?value1 .
+ ?obs1 ?dim ?value1 .
?obs2 ?dim ?value2 .
BIND( ?value1 = ?value2 AS ?equal)
} GROUP BY ?obs1 ?obs2
@@ -1945,7 +1935,7 @@
<h3 id="ic-13">IC-13. Required attributes</h3>
<p>
-Every <code><a>qb:Observation</a></code> has a value for each declared attribute that is not explicitly marked as optional.
+Every <code><a>qb:Observation</a></code> has a value for each declared attribute that is marked as required.
</p>
<table class="bordered-table">
<tbody>
@@ -2003,7 +1993,7 @@
<h3 id="ic-16">IC-16. Single measure on measure dimension observation</h3>
<p>
-In a <code><a>qb:DataSet</a></code> which uses a <a>Measure dimension</a> then each <code><a>qb:Observation</a></code> must only have a measure value one measure (by IC-15 this will be the measure corresponding to its <code><a>qb:measureType</a></code>).
+In a <code><a>qb:DataSet</a></code> which uses a <a>Measure dimension</a> then each <code><a>qb:Observation</a></code> must only have a value for one measure (by IC-15 this will be the measure corresponding to its <code><a>qb:measureType</a></code>).
</p>
<table class="bordered-table">
<tbody>
@@ -2089,7 +2079,7 @@
If a dimension property has a <code><a>qb:codeList</a></code>, then the value of the dimension property on every <code><a>qb:Observation</a></code> must be in the code list.
</p>
<p>The following integrity check queries must be applied to an RDF graph which contains the
-definition of the code list as well as the RDF Data Cube to be checked. In the case
+definition of the code list as well as the Data Cube to be checked. In the case
of a <code>skos:ConceptScheme</code> then each concept must be linked to the scheme using
<code>skos:inScheme</code>. In the case of a <code>skos:Collection</code> then the
collection must link to each concept using <code>skos:member</code> (i.e. if the
@@ -2137,7 +2127,7 @@
<pre>
SELECT ?p WHERE {
?hierarchy a qb:HierarchicalCodeList ;
- qb:parentChildProperty ?p .
+ qb:parentChildProperty ?p .
FILTER ( isIRI(?p) )
}
</pre>
@@ -2170,8 +2160,7 @@
This check cannot be made by a simple fixed SPARQL query. Instead a
query template is supplied.
An instance of the template should be generated
-for each <code><a>qb:HierarchicalCodeList</a></code> which has an
-blank-node
+for each <code><a>qb:HierarchicalCodeList</a></code> which has a blank-node
value for its <code><a>qb:parentChildProperty</a></code>, with an
associated inverse property.
That is for each binding of <code>?p</code> in the following
@@ -2179,7 +2168,7 @@
<pre>
SELECT ?p WHERE {
?hierarchy a qb:HierarchicalCodeList;
- qb:parentChildProperty ?pcp .
+ qb:parentChildProperty ?pcp .
FILTER( isBlank(?pcp) )
?pcp owl:inverseOf ?p .
FILTER( isIRI(?p) )
@@ -2196,7 +2185,7 @@
ASK {
?obs qb:dataSet/qb:structure/qb:component/qb:componentProperty ?dim .
?dim a qb:DimensionProperty ;
- qb:codeList ?list .
+ qb:codeList ?list .
?list a qb:HierarchicalCodeList .
?obs ?dim ?v .
FILTER NOT EXISTS { ?list qb:hierarchyRoot/(^<$p>)* ?v }
@@ -2245,7 +2234,7 @@
<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>
+ <dd>A single observation in the cube, may have one or more associated measured values.</dd>
<dt id="ref_qb_dataSet_LC">
<em>Property:</em> <code><dfn>qb:dataSet</dfn></code>
@@ -2255,7 +2244,7 @@
<code><a>qb:DataSet</a></code>
)
</dt>
- <dd>indicates the data set of which this observation is a part</dd>
+ <dd>Indicates the data set of which this observation is a part.</dd>
<dt id="ref_qb_observation_LC">
<em>Property:</em> <code><dfn>qb:observation</dfn></code>
@@ -2265,7 +2254,7 @@
<code><a>qb:Observation</a></code>
)
</dt>
- <dd>indicates a observation contained within this slice of the data set</dd>
+ <dd>Indicates a observation contained within this slice of the data set.</dd>
</dl>
</section>
@@ -2288,7 +2277,7 @@
<code><a>qb:Attachable</a></code>,
<code><a>qb:ObservationGroup</a></code>
</dt>
- <dd>Denotes a subset of a DataSet defined by fixing a subset of the dimensional values, component properties on the Slice</dd>
+ <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_LC">
<em>Property:</em> <code><dfn>qb:slice</dfn></code>
@@ -2297,10 +2286,10 @@
-> <em>Range:</em>
<code><a>qb:Slice</a></code>;
<em>sub property of:</em>
- <code><a>qb:observationgroup</a></code>
+ <code><a>qb:observationGroup</a></code>
)
</dt>
- <dd>Indicates a subset of a DataSet defined by fixing a subset of the dimensional values</dd>
+ <dd>Indicates a subset of a DataSet defined by fixing a subset of the dimensional values.</dd>
<dt id="ref_qb_observationGroup">
<em>Property:</em> <code><dfn>qb:observationGroup</dfn></code>
@@ -2324,43 +2313,43 @@
<dt id="ref_qb_Attachable">
<em>Class:</em> <code><dfn>qb:Attachable</dfn></code>
</dt>
- <dd>Abstract superclass for everything that can have attributes and dimensions</dd>
+ <dd>Abstract superclass for everything that can have attributes and dimensions.</dd>
<dt id="ref_qb_ComponentProperty">
<em>Class:</em> <code><dfn>qb:ComponentProperty</dfn></code>
<em>Sub class of: </em>
<code>rdf:Property</code>
</dt>
- <dd>Abstract super-property of all properties representing dimensions, attributes or measures</dd>
+ <dd>Abstract super-class of all properties representing dimensions, attributes or measures.</dd>
<dt id="ref_qb_DimensionProperty">
<em>Class:</em> <code><dfn>qb:DimensionProperty</dfn></code>
<em>Sub class of: </em>
- <code><a>qb:ComponentProperty</a></code>
+ <code><a>qb:ComponentProperty</a></code>,
<code><a>qb:CodedProperty</a></code>
</dt>
- <dd>The class of components which represent the dimensions of the cube</dd>
+ <dd>The class of component properties which represent the dimensions of the cube.</dd>
<dt id="ref_qb_AttributeProperty">
<em>Class:</em> <code><dfn>qb:AttributeProperty</dfn></code>
<em>Sub class of: </em>
<code><a>qb:ComponentProperty</a></code>
</dt>
- <dd>The class of components which represent attributes of observations in the cube, e.g. unit of measurement</dd>
+ <dd>The class of component properties which represent attributes of observations in the cube, e.g. unit of measurement.</dd>
<dt id="ref_qb_MeasureProperty">
<em>Class:</em> <code><dfn>qb:MeasureProperty</dfn></code>
<em>Sub class of: </em>
<code><a>qb:ComponentProperty</a></code>
</dt>
- <dd>The class of components which represent the measured value of the phenomenon being observed</dd>
+ <dd>The class of component properties which represent the measured value of the phenomenon being observed.</dd>
<dt id="ref_qb_CodedProperty">
<em>Class:</em> <code><dfn>qb:CodedProperty</dfn></code>
<em>Sub class of: </em>
<code><a>qb:ComponentProperty</a></code>
</dt>
- <dd>Superclass of all coded ComponentProperties</dd>
+ <dd>Superclass of all coded component properties.</dd>
</dl>
</section>
@@ -2378,7 +2367,7 @@
<code><a>qb:MeasureProperty</a></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>
+ <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 observation.</dd>
</dl>
</section>
@@ -2394,7 +2383,7 @@
<em>Sub class of: </em>
<code><a>qb:ComponentSet</a></code>
</dt>
- <dd>Defines the structure of a DataSet or slice</dd>
+ <dd>Defines the structure of a DataSet or slice.</dd>
<dt id="ref_qb_structure">
<em>Property:</em> <code><dfn>qb:structure</dfn></code>
@@ -2414,7 +2403,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>
@@ -2445,7 +2434,7 @@
<code><a>qb:ComponentProperty</a></code>
)
</dt>
- <dd>indicates a ComponentProperty (i.e. attribute/dimension) expected on a DataSet, or a dimension fixed in a SliceKey</dd>
+ <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><dfn>qb:order</dfn></code>
@@ -2455,7 +2444,7 @@
<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>
+ <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><dfn>qb:componentRequired</dfn></code>
@@ -2466,7 +2455,7 @@
)
</dt>
<dd>Indicates whether a component property is required (true) or optional (false) in the context of a DSD. Only applicable
- to components correspond to an attribute. Defaults to false (optional).</dd>
+ to components corresponding to an attribute. Defaults to false (optional).</dd>
<dt id="ref_qb_componentAttachment">
<em>Property:</em> <code><dfn>qb:componentAttachment</dfn></code>
@@ -2487,7 +2476,7 @@
<code><a>qb:componentProperty</a></code>
)
</dt>
- <dd>An alternative to qb:componentProperty which makes explicit that the component is a dimension</dd>
+ <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><dfn>qb:measure</dfn></code>
@@ -2498,7 +2487,7 @@
<code><a>qb:componentProperty</a></code>
)
</dt>
- <dd>An alternative to qb:componentProperty which makes explicit that the component is a measure</dd>
+ <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><dfn>qb:attribute</dfn></code>
@@ -2509,7 +2498,7 @@
<code><a>qb:componentProperty</a></code>
)
</dt>
- <dd>An alternative to qb:componentProperty which makes explicit that the component is a attribute</dd>
+ <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><dfn>qb:measureDimension</dfn></code>
@@ -2520,7 +2509,7 @@
<code><a>qb:componentProperty</a></code>
)
</dt>
- <dd>An alternative to qb:componentProperty which makes explicit that the component is a measure dimension</dd>
+ <dd>An alternative to qb:componentProperty which makes explicit that the component is a measure dimension.</dd>
</dl>
</section>
@@ -2536,7 +2525,7 @@
<em>Sub class of: </em>
<code><a>qb:ComponentSet</a></code>
</dt>
- <dd>Denotes a subset of the component properties of a DataSet which are fixed in the corresponding slices</dd>
+ <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><dfn>qb:sliceStructure</dfn></code>
@@ -2546,7 +2535,7 @@
<code><a>qb:SliceKey</a></code>
)
</dt>
- <dd>indicates the sub-key corresponding to this slice</dd>
+ <dd>Indicates the slice key corresponding to this slice.</dd>
<dt id="ref_qb_sliceKey_LC">
<em>Property:</em> <code><dfn>qb:sliceKey</dfn></code>
@@ -2556,7 +2545,7 @@
<code><a>qb:SliceKey</a></code>
)
</dt>
- <dd>indicates a slice key which is used for slices in this dataset</dd>
+ <dd>Indicates a slice key which is used for slices in this dataset.</dd>
</dl>
</section>
@@ -2597,17 +2586,16 @@
<dt id="ref_qb_Hierarchy">
<em>Class:</em> <code><dfn>qb:HierarchicalCodeList</dfn></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><a>qb:parentChildProperty</a></code> or <code><a>qb:broadeningProperty</a></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>
-
+ <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 their child concept . The same concepts may be members of multiple hierarchies provided that different qb:parentChildProperty values are used for each hierarchy.</dd>
<dt id="ref_qb_hierarchyRoot">
<em>Property:</em> <code><dfn>qb:hierarchyRoot</dfn></code>
( <em>Domain:</em>
<code><a>qb:HierarchicalCodeList</a></code>
)
</dt>
- <dd>Specifies a root of the hierarchy. A hierarchy may have multiple roots but must have at least one.</dd>
+ <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">
+ <dt id="ref_qb_parentChildProperty">
<em>Property:</em> <code><dfn>qb:parentChildProperty</dfn></code>
( <em>Domain:</em>
<code><a>qb:HierarchicalCodeList</a></code>
@@ -2646,32 +2634,13 @@
explanations of SDMX and insight in the need and requirements
for a core Data Cube representation.</p>
-<p>The authors would also like to thank John Sheridan for his comments,
-suggestions and support for this work.</p>
+<p>The editors would like to thank John Sheridan for his comments,
+suggestions and support for the original work.</p>
<p>Many individuals provided valuable comments on this specification
-as it made its way through the W3C process, including Curran Kelleher, …</p>
-
-</section>
-
-
-<section id="issues">
-<h2>Open issues</h2>
-
-<p>
- Based on early use experiences with the vocabulary the working group is considering
- some clarifications and modifications to the specification. Each of
- the candidate areas under consideration are listed as issues
- below. Note that there is, as yet, no commitment that all (or indeed any) of these areas
- will be addressed by the working group.
-</p>
-
- <div class='issue'>
- <h3><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>
+as it made its way through the W3C process. We would like to
+especially acknowledge the contributions of
+Benedikt Kaempgen, Sarven Capadisli and Curran Kelleher.</p>
</section>
@@ -2681,12 +2650,13 @@
Changes since <a href="http://www.w3.org/TR/2012/WD-vocab-data-cube-20120405/">W3C Working Draft 5 April 2012</a>:
<ul>
- <li>Clarified that <code><a>qb:componentRequired</a></code> is only applicable to
- attributes and that it defaults to optional.</li>
+ <li>Added <a href="#wf">section</a> on criteria for well-formed cubes. <a href="http://www.w3.org/2011/gld/track/issues/29">ISSUE-29</a></li>
<li>Added <a href="#normalize">section</a> on flattening algorithm
for handling abbreviated cubes.</li>
<li>Added <a href="#conformance">conformance section</a>.
- <li>Moved vocabulary reference into the normative body of the specification, adding hyperlinks for all qb: terms</li>
+ <li>Clarified that <code><a>qb:componentRequired</a></code> is only applicable to
+ attributes and that it defaults to optional.</li>
+ <li>Moved vocabulary reference into the normative body of the specification, adding hyperlinks for all qb: terms.</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><a>qb:ObservationGroup</a></code> as a generalization of <code><a>qb:Slice</a></code>. <a href="http://www.w3.org/2011/gld/track/issues/33">ISSUE-33</a>.</li>