--- a/data-cube/index.html Sun Mar 03 13:09:08 2013 +0000
+++ b/data-cube/index.html Sun Mar 03 15:19:49 2013 +0000
@@ -535,7 +535,7 @@
<section id="dsd">
<h2>Creating data structure definitions</h2>
-<p>A <code>qb:DataStructureDefinition</code> defines the structure of one or more
+<p>A <code><a>qb:DataStructureDefinition</a></code> defines the structure of one or more
datasets. In particular, it defines the dimensions, attributes and measures
used in the dataset along with qualifying information such as ordering of
dimensions and whether attributes are required or optional. For well-formed
@@ -561,9 +561,9 @@
<h3>Dimensions, attributes and measures</h3>
<p>The Data Cube vocabulary represents the dimensions, attributes and measures
- as RDF properties. Each is an instance of the abstract <code>qb:ComponentProperty</code>
- class, which in turn has sub-classes <code>qb:DimensionProperty</code>,
- <code>qb:AttributeProperty</code> and <code>qb:MeasureProperty</code>.</p>
+ as RDF properties. Each is an instance of the abstract <code><a>qb:ComponentProperty</a></code>
+ class, which in turn has sub-classes <code><a>qb:DimensionProperty</a></code>,
+ <code><a>qb:AttributeProperty</a></code> and <code><a>qb:MeasureProperty</a></code>.</p>
<p>A component property encapsulates several pieces of information:</p>
<ul>
@@ -580,15 +580,15 @@
In statistical agencies it is common to have a standard thesaurus of statistical concepts which
underpin the components used in multiple different data sets.</p>
-<p>To support this reuse of general statistical concepts the data cube vocabulary provides the <code>qb:concept</code> property which
- links a <code>qb:ComponentProperty</code> to the concept it represents. We use the SKOS
+<p>To support this reuse of general statistical concepts the data cube vocabulary provides the <code><a>qb:concept</a></code> property which
+ links a <code><a>qb:ComponentProperty</a></code> to the concept it represents. We use the SKOS
vocabulary [[SKOS-PRIMER]] to represent such concepts. This is very natural for those cases where the
concepts are already maintained as a controlled term list or thesaurus.
When developing a data structure definition for an informal data set there may not be an appropriate
concept already. In those cases, if the concept is likely to be reused in other guises it is recommended to
- publish a <code>skos:Concept</code> along with the specific <code>qb:ComponentProperty</code>. However, if
- such reuse is not expected then it is not required to do so - the <code>qb:concept</code>
- link is optional and a simple instance of the appropriate subclass of <code>qb:ComponentProperty</code> is
+ publish a <code>skos:Concept</code> along with the specific <code><a>qb:ComponentProperty</a></code>. However, if
+ such reuse is not expected then it is not required to do so - the <code><a>qb:concept</a></code>
+ link is optional and a simple instance of the appropriate subclass of <code><a>qb:ComponentProperty</a></code> is
sufficient.</p>
<p>The representation of the possible values of the component is described using the <code>rdfs:range</code>
@@ -598,9 +598,9 @@
<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> 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>.
+ component can also be optionally annotated with a <code><a>qb:codeList</a></code> to indicate a set of
+ <code>skos:Concept</code>s which may be used as codes. The <code><a>qb:codeList</a></code> value may be a
+ <code>skos:ConceptScheme</code>, <code>skos:Collection</code> or <code><a>qb:Hierarchy</a></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
@@ -710,20 +710,20 @@
<h3>ComponentSpecifications and DataStructureDefinitions</h3>
<p>To combine the components into a specification for the structure of this
- dataset we need to declare a <code>qb:DataStuctureDefinition</code>
- resource which in turn will reference a set of <code>qb:ComponentSpecification</code> resources.
- The <code>qb:DataStuctureDefinition</code> will be reusable across other data sets with the same structure.</p>
+ dataset we need to declare a <code><a>qb:DataStuctureDefinition</a></code>
+ resource which in turn will reference a set of <code><a>qb:ComponentSpecification</a></code> resources.
+ The <code><a>qb:DataStuctureDefinition</a></code> will be reusable across other data sets with the same structure.</p>
-<p>In the simplest case the <code>qb:ComponentSpecification</code> simply references the
- corresponding <code>qb:ComponentProperty</code> (usually using one of the sub properties
- <code>qb:dimension</code>, <code>qb:measure</code> or <code>qb:attribute</code>).
+<p>In the simplest case the <code><a>qb:ComponentSpecification</a></code> simply references the
+ corresponding <code><a>qb:ComponentProperty</a></code> (usually using one of the sub properties
+ <code><a>qb:dimension</a></code>, <code><a>qb:measure</a></code> or <code><a>qb:attribute</a></code>).
However, it is also possible to qualify the
component specification in several ways.</p>
<ul>
<li>An Attribute may be optional in which case the specification should set
<code>qb:componentRequired "false"^^xsd:boolean.</code></li>
- <li>The components may be ordered by giving an integer value for <code>qb:order</code>.
+ <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
synthesis of appropriate URIs for observations.</li>
@@ -734,8 +734,8 @@
it is also permissible to attach attributes to the
overall data set, to an intervening slice or to a specific Measure (in the case of multiple measures).
This reduces some of the redundancy in the encoding of the instance data. To declare such a
- non-flat structure, the <code>qb:componentAttachment</code> property of the specification should
- reference the class corresponding to the attachment level (e.g. <code>qb:DataSet</code> for attributes
+ non-flat structure, the <code><a>qb:componentAttachment</a></code> property of the specification should
+ reference the class corresponding to the attachment level (e.g. <code><a>qb:DataSet</a></code> for attributes
that will be attached to the overall data set).</li>
</ul>
@@ -793,7 +793,7 @@
<p> This approach allows multiple observed values to be attached
to an individual observation. Is suited to representation of things like sensor data and OLAP cubes.
- To use this representation you simply declare multiple <code>qb:MeasureProperty</code> components
+ To use this representation you simply declare multiple <code><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>
@@ -822,7 +822,7 @@
<p>Note that one limitation of the multi-measure approach is that it is not possible to attach
an attribute to a single observed value. An attribute attached to the observation instance
will apply to the whole observation (e.g. to indicate who made the observation). Attributes
- can also be attached directly to the <code>qb:MeasureProperty</code> itself (e.g. to indicate
+ can also be attached directly to the <code><a>qb:MeasureProperty</a></code> itself (e.g. to indicate
the <em>unit of measure</em> for that measure) but that attachment applies to the whole data
set (indeed any data set using that measure property) and cannot vary for different observations.
For applications where this limitation is a problem then use the <em>measure dimension</em> approach.</p>
@@ -836,15 +836,15 @@
a data set to carry multiple measures by adding an extra dimension, a <em>measure dimension</em>.
The value of the measure dimension denotes which particular measure is being conveyed by the
observation. This is the representation approach used within SDMX and the SMDX-in-RDF
- extension vocabulary introduces a subclass of <code>qb:DataStructureDefinition</code> which is restricted
+ extension vocabulary introduces a subclass of <code><a>qb:DataStructureDefinition</a></code> which is restricted
to using the <em>measure dimension</em> representation.</p>
<p>To use this representation you declare an additional dimension within the data structure
definition to play the role of the measure dimension. For use within the Data Cube vocabulary
- we provide a single distinguished component for this purpose -- <code>qb:measureType</code>.
+ we provide a single distinguished component for this purpose -- <code><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.
- In the special case of using <code>qb:measureType</code> as the measure dimension, the set of allowed
+ In the special case of using <code><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>
@@ -928,18 +928,18 @@
<section id="dataset-basic">
<h3>Data sets and observations</h3>
-<p>A resource representing the entire data set is created and typed as <code>qb:DataSet</code> and
- linked to the corresponding data structure definition via the <tt>qb:structure</tt> property.</p>
+<p>A resource representing the entire data set is created and typed as <code><a>qb:DataSet</a></code> and
+ linked to the corresponding data structure definition via the <code><a>qb:structure</a></code> property.</p>
<p><strong>Pitfall</strong>: Note the capitalization of <tt>qb:<strong>D</strong>ata<strong>S</strong>et</tt>,
which differs from the capitalization in other vocabularies, such as
<a href="http://semanticweb.org/wiki/VoiD">void:Dataset</a> and <a href="http://www.w3.org/egov/wiki/Data_Catalog_Vocabulary">dcat:Dataset</a>. This unusual capitalization is chosen for compatibility
-with the SDMX standard. The same applies to the related property <tt>qb:data<strong>S</strong>et</tt>.</p>
+with the SDMX standard. The same applies to the related property <code>qb:data<strong>S</strong>et</code>.</p>
-<p>Each observation is represented as an instance of type <code>qb:Observation</code>.
+<p>Each observation is represented as an instance of type <code><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>qb:dataSet</code> property. For example:</p>
+ data set using the <code><a>qb:dataSet</a></code> property. For example:</p>
<p>Thus for our running example we might expect to have:</p>
@@ -1052,9 +1052,9 @@
and guide applications to present a comparative chart across regions. </p>
<p>We first define the structure of the slices we want by associating a "slice key" which the
- data structure definition. This is done by creating a <code>qb:SliceKey</code> which
+ data structure definition. This is done by creating a <code><a>qb:SliceKey</a></code> which
lists the component properties (which must be dimensions) which will be fixed in the
- slice. The key is attached to the DSD using <code>qb:sliceKey</code>. For example: </p>
+ slice. The key is attached to the DSD using <code><a>qb:sliceKey</a></code>. For example: </p>
<pre class="example">
eg:sliceByRegion a qb:SliceKey;
@@ -1072,10 +1072,10 @@
qb:sliceKey eg:sliceByRegion .
</pre>
-<p>In the instance data then slices are represented by instances of <code>qb:Slice</code> which
- link to the observations in the slice via <code>qb:observation</code> and to the key by means
- of <code>qb:sliceStructure</code>. Data sets indicate
- the slices they contain by means of <code>qb:slice</code>. Thus in our example we would have:</p>
+<p>In the instance data then slices are represented by instances of <code><a>qb:Slice</a></code> which
+ link to the observations in the slice via <code><a>qb:observation</a></code> and to the key by means
+ of <code><a>qb:sliceStructure</a></code>. Data sets indicate
+ the slices they contain by means of <code><a>qb:slice</a></code>. Thus in our example we would have:</p>
<pre class="example">
eg:dataset-le2 a qb:DataSet;
@@ -1176,8 +1176,8 @@
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>.
+<code><a>qb:ObservationGroup</a></code>. A <code><a>qb:ObservationGroup</a></code> can contain an arbitrary
+collection of observations. A <code><a>qb:Slice</a></code> is a special case of a <code><a>qb:ObservationGroup</a></code>.
</section>
@@ -1247,7 +1247,7 @@
<p>It is convenient and good practice when developing a code list to also
create a Class to denote all the codes within the code
list, irrespective of hierarchical structure. This allows the range of an
-<code>qb:ComponentProperty</code> to be defined by using <code>rdfs:range</code>
+<code><a>qb:ComponentProperty</a></code> to be defined by using <code>rdfs:range</code>
which then permits standard RDF closed-world checkers to validate use of the
code list without requiring custom SDMX-RDF-aware tooling. We do that in the
above example by using the common convention that the class name is the
@@ -1261,7 +1261,7 @@
rdfs:range sdmx-code:Sex .
</pre>
-<p>Explicitly declaring the code list using <code>qb:codeList</code>
+<p>Explicitly declaring the code list using <code><a>qb:codeList</a></code>
is not mandatory but can be helpful in those cases where a concept scheme has been defined.</p>
</section>
@@ -1304,14 +1304,14 @@
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>The Data Cube vocabulary supports this situation through the <code><a>qb:Hierarchy</a></code> class.
+An instance of <code><a>qb:Hierarchy</a></code> defines a set of root concepts in the hierarchy
+(<code><a>qb:hierarchyRoot</a></code>) and either a parent-to-child relationship (<code><a>qb:narrowingProperty</a></code>)
+or a child-to-parent relationship (<code><a>qb:broadeningProperty</a></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>
+ontology to define a containment hierarchy. This could be represented as a <code><a>qb:Hierarchy</a></code> using the following.</p>
<pre class="example">
PREFIX spatial: <http://data.ordnancesurvey.co.uk/ontology/spatialrelations/> .
@@ -1338,7 +1338,7 @@
qb:codeList eg:GBgeoHierarchy .
</pre>
-<p>A sub class of <code>qb:Hierarchy</code>, <code>qb:AggregatableHierarchy</code>, is provided to declare
+<p>A sub class of <code><a>qb:Hierarchy</a></code>, <code><a>qb:AggregatableHierarchy</a></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>
@@ -1429,19 +1429,21 @@
</section>
-<section id="vocab-reference" class="appendix">
+<section id="vocab-reference">
<h2>Vocabulary reference</h2>
<section id="reference-datasets">
<h3>DataSets</h3>
+<p>See Section <a href="#datasets">Expressing data sets</a></p>
+
<dl class='vocab_reference'>
<dt id="ref_qb_DataSet">
- <em>Class:</em> <code>qb:DataSet</code>
+ <em>Class:</em> <code><dfn>qb:DataSet</dfn></code>
<em>Sub class of: </em>
- <code>qb:Attachable</code>
+ <code><a>qb:Attachable</a></code>
<em>Equivalent to: </em>
<code>scovo:Dataset</code>
</dt>
@@ -1452,34 +1454,35 @@
<section id="reference-observations">
<h3>Observations</h3>
+<p><em>See Section <a href="#datasets">Expressing data sets</a>.</em></p>
<dl class='vocab_reference'>
<dt id="ref_qb_Observation">
- <em>Class:</em> <code>qb:Observation</code>
+ <em>Class:</em> <code><dfn>qb:Observation</dfn></code>
<em>Sub class of: </em>
- <code>qb:Attachable</code>
+ <code><a>qb:Attachable</a></code>
<em>Equivalent to: </em>
<code>scovo:Item</code>
</dt>
<dd>A single observation in the cube, may have one or more associated measured values</dd>
<dt id="ref_qb_dataSet_LC">
- <em>Property:</em> <code>qb:dataSet</code>
- (
- <code>qb:Observation</code>
- ->
- <code>qb:DataSet</code>
+ <em>Property:</em> <code><dfn>qb:dataSet</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:Observation</a></code>
+ -> <em>Range:</em>
+ <code><a>qb:DataSet</a></code>
)
</dt>
<dd>indicates the data set of which this observation is a part</dd>
<dt id="ref_qb_observation_LC">
- <em>Property:</em> <code>qb:observation</code>
- (
- <code>qb:Slice</code>
- ->
- <code>qb:Observation</code>
+ <em>Property:</em> <code><dfn>qb:observation</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:Slice</a></code>
+ -> <em>Range:</em>
+ <code><a>qb:Observation</a></code>
)
</dt>
<dd>indicates a observation contained within this slice of the data set</dd>
@@ -1489,38 +1492,39 @@
<section id="reference-slices">
<h3>Slices</h3>
+<p><em>See Section <a href="#slices">Slices</a>.</em></p>
<dl class='vocab_reference'>
<dt id="ref_qb_ObservationGroup">
- <em>Class:</em> <code>qb:ObservationGroup</code>
+ <em>Class:</em> <code><dfn>qb:ObservationGroup</dfn></code>
</dt>
<dd>A, possibly arbitrary, group of observations.</dd>
<dt id="ref_qb_Slice">
- <em>Class:</em> <code>qb:Slice</code>
+ <em>Class:</em> <code><dfn>qb:Slice</dfn></code>
<em>Sub class of: </em>
- <code>qb:Attachable</code>,
- <code>qb:ObservationGroup</code>
+ <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>
<dt id="ref_qb_slice_LC">
- <em>Property:</em> <code>qb:slice</code>
- (
- <code>qb:DataSet</code>
- ->
- <code>qb:Slice</code>
+ <em>Property:</em> <code><dfn>qb:slice</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:DataSet</a></code>
+ -> <em>Range:</em>
+ <code><a>qb:Slice</a></code>
)
</dt>
<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>qb:observationGroup</code>
- (
- ->
- <code>qb:ObservationGroup</code>
+ <em>Property:</em> <code><dfn>qb:observationGroup</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a>qb:ObservationGroup</a></code>
)
</dt>
<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>
@@ -1531,46 +1535,48 @@
<section id="reference-components">
<h3>Dimensions, Attributes, Measures</h3>
+<p><em>See Section <a href="#dsd-dimensions">Dimensions, attributes and measures</a>.</em></p>
+
<dl class='vocab_reference'>
<dt id="ref_qb_Attachable">
- <em>Class:</em> <code>qb:Attachable</code>
+ <em>Class:</em> <code><dfn>qb:Attachable</dfn></code>
</dt>
<dd>Abstract superclass for everything that can have attributes and dimensions</dd>
<dt id="ref_qb_ComponentProperty">
- <em>Class:</em> <code>qb:ComponentProperty</code>
+ <em>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>
<dt id="ref_qb_DimensionProperty">
- <em>Class:</em> <code>qb:DimensionProperty</code>
+ <em>Class:</em> <code><dfn>qb:DimensionProperty</dfn></code>
<em>Sub class of: </em>
- <code>qb:ComponentProperty</code>
- <code>qb:CodedProperty</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>
<dt id="ref_qb_AttributeProperty">
- <em>Class:</em> <code>qb:AttributeProperty</code>
+ <em>Class:</em> <code><dfn>qb:AttributeProperty</dfn></code>
<em>Sub class of: </em>
- <code>qb:ComponentProperty</code>
+ <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>
<dt id="ref_qb_MeasureProperty">
- <em>Class:</em> <code>qb:MeasureProperty</code>
+ <em>Class:</em> <code><dfn>qb:MeasureProperty</dfn></code>
<em>Sub class of: </em>
- <code>qb:ComponentProperty</code>
+ <code><a>qb:ComponentProperty</a></code>
</dt>
<dd>The class of components which represent the measured value of the phenomenon being observed</dd>
<dt id="ref_qb_CodedProperty">
- <em>Class:</em> <code>qb:CodedProperty</code>
+ <em>Class:</em> <code><dfn>qb:CodedProperty</dfn></code>
<em>Sub class of: </em>
- <code>qb:ComponentProperty</code>
+ <code><a>qb:ComponentProperty</a></code>
</dt>
<dd>Superclass of all coded ComponentProperties</dd>
</dl>
@@ -1579,13 +1585,15 @@
<section id="reference-component-properties">
<h3>Reusable general purpose component properties</h3>
+<p><em>See Section <a href="#dsd-mm-dim">Measure dimensions</a>.</em></p>
+
<dl class='vocab_reference'>
<dt id="ref_qb_measureType">
- <em>Property:</em> <code>qb:measureType</code>
- (
- ->
- <code>qb:MeasureProperty</code>
+ <em>Property:</em> <code><dfn>qb:measureType</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <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>
@@ -1595,31 +1603,33 @@
<section id="reference-dsd">
<h3>Data Structure Definitions</h3>
+<p><em>See Section <a href="#dsd-dsd">ComponentSpecifications and DataStructureDefinitions</a>.</em></p>
+
<dl class='vocab_reference'>
<dt id="ref_qb_DataStructureDefinition">
- <em>Class:</em> <code>qb:DataStructureDefinition</code>
+ <em>Class:</em> <code><dfn>qb:DataStructureDefinition</dfn></code>
<em>Sub class of: </em>
- <code>qb:ComponentSet</code>
+ <code><a>qb:ComponentSet</a></code>
</dt>
<dd>Defines the structure of a DataSet or slice</dd>
<dt id="ref_qb_structure">
- <em>Property:</em> <code>qb:structure</code>
- (
- <code>qb:DataSet</code>
- ->
- <code>qb:DataStructureDefinition</code>
+ <em>Property:</em> <code><dfn>qb:structure</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:DataSet</a></code>
+ -> <em>Range:</em>
+ <code><a>qb:DataStructureDefinition</a></code>
)
</dt>
<dd>indicates the structure to which this data set conforms</dd>
<dt id="ref_qb_component">
- <em>Property:</em> <code>qb:component</code>
- (
- <code>qb:DataStructureDefinition</code>
- ->
- <code>qb:ComponentSpecification</code>
+ <em>Property:</em> <code><dfn>qb:component</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:DataStructureDefinition</a></code>
+ -> <em>Range:</em>
+ <code><a>qb:ComponentSpecification</a></code>
)
</dt>
<dd>indicates a component specification which is included in the structure of the dataset</dd>
@@ -1629,100 +1639,102 @@
<section id="reference-compspec">
<h3>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'>
<dt id="ref_qb_ComponentSpecification">
- <em>Class:</em> <code>qb:ComponentSpecification</code>
+ <em>Class:</em> <code><dfn>qb:ComponentSpecification</dfn></code>
<em>Sub class of: </em>
- <code>qb:ComponentSet</code>
+ <code><a>qb:ComponentSet</a></code>
</dt>
<dd>Used to define properties of a component (attribute, dimension etc) which are specific to its usage in a DSD.</dd>
<dt id="ref_qb_ComponentSet">
- <em>Class:</em> <code>qb:ComponentSet</code>
+ <em>Class:</em> <code><dfn>qb:ComponentSet</dfn></code>
</dt>
<dd>Abstract class of things which reference one or more ComponentProperties</dd>
<dt id="ref_qb_componentProperty_LC">
- <em>Property:</em> <code>qb:componentProperty</code>
- (
- <code>qb:ComponentSet</code>
- ->
- <code>qb:ComponentProperty</code>
+ <em>Property:</em> <code><dfn>qb:componentProperty</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:ComponentSet</a></code>
+ -> <em>Range:</em>
+ <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>
<dt id="ref_qb_order">
- <em>Property:</em> <code>qb:order</code>
- (
- <code>qb:ComponentSpecification</code>
- ->
+ <em>Property:</em> <code><dfn>qb:order</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:ComponentSpecification</a></code>
+ -> <em>Range:</em>
<code>xsd:int</code>
)
</dt>
<dd>indicates a priority order for the components of sets with this structure, used to guide presentations - lower order numbers come before higher numbers, un-numbered components come last</dd>
<dt id="ref_qb_componentRequired">
- <em>Property:</em> <code>qb:componentRequired</code>
- (
- <code>qb:ComponentSpecification</code>
- ->
+ <em>Property:</em> <code><dfn>qb:componentRequired</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:ComponentSpecification</a></code>
+ -> <em>Range:</em>
<code>xsd:boolean</code>
)
</dt>
<dd>Indicates whether a component property is required (true) or optional (false) in the context of a DSD or MSD</dd>
<dt id="ref_qb_componentAttachment">
- <em>Property:</em> <code>qb:componentAttachment</code>
- (
- <code>qb:ComponentSpecification</code>
- ->
+ <em>Property:</em> <code><dfn>qb:componentAttachment</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:ComponentSpecification</a></code>
+ -> <em>Range:</em>
<code>rdfs:Class</code>
)
</dt>
<dd>Indicates the level at which the component property should be attached, this might an qb:DataSet, qb:Slice or qb:Observation, or a qb:MeasureProperty.</dd>
<dt id="ref_qb_dimension">
- <em>Property:</em> <code>qb:dimension</code>
- (
- ->
- <code>qb:DimensionProperty</code>
+ <em>Property:</em> <code><dfn>qb:dimension</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a>qb:DimensionProperty</a></code>
; <em>sub property of: </em>
- <code>qb:componentProperty</code>
+ <code><a>qb:componentProperty</a></code>
)
</dt>
<dd>An alternative to qb:componentProperty which makes explicit that the component is a dimension</dd>
<dt id="ref_qb_measure">
- <em>Property:</em> <code>qb:measure</code>
- (
- ->
- <code>qb:MeasureProperty</code>
+ <em>Property:</em> <code><dfn>qb:measure</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a>qb:MeasureProperty</a></code>
; <em>sub property of: </em>
- <code>qb:componentProperty</code>
+ <code><a>qb:componentProperty</a></code>
)
</dt>
<dd>An alternative to qb:componentProperty which makes explicit that the component is a measure</dd>
<dt id="ref_qb_attribute">
- <em>Property:</em> <code>qb:attribute</code>
- (
- ->
- <code>qb:AttributeProperty</code>
+ <em>Property:</em> <code><dfn>qb:attribute</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a>qb:AttributeProperty</a></code>
; <em>sub property of: </em>
- <code>qb:componentProperty</code>
+ <code><a>qb:componentProperty</a></code>
)
</dt>
<dd>An alternative to qb:componentProperty which makes explicit that the component is a attribute</dd>
<dt id="ref_qb_measureDimension">
- <em>Property:</em> <code>qb:measureDimension</code>
- (
- ->
- <code>qb:DimensionProperty</code>
+ <em>Property:</em> <code><dfn>qb:measureDimension</dfn></code>
+ ( <em>Domain:</em>
+ -> <em>Range:</em>
+ <code><a>qb:DimensionProperty</a></code>
; <em>sub property of: </em>
- <code>qb:componentProperty</code>
+ <code><a>qb:componentProperty</a></code>
)
</dt>
<dd>An alternative to qb:componentProperty which makes explicit that the component is a measure dimension</dd>
@@ -1732,31 +1744,33 @@
<section id="reference-slice-definitions">
<h3>Slice definitions</h3>
+<p><em>See Section <a href="#slices">Slices</a>.</em></p>
+
<dl class='vocab_reference'>
<dt id="ref_qb_SliceKey">
- <em>Class:</em> <code>qb:SliceKey</code>
+ <em>Class:</em> <code><dfn>qb:SliceKey</dfn></code>
<em>Sub class of: </em>
- <code>qb:ComponentSet</code>
+ <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>
<dt id="ref_qb_sliceStructure">
- <em>Property:</em> <code>qb:sliceStructure</code>
- (
- <code>qb:Slice</code>
- ->
- <code>qb:SliceKey</code>
+ <em>Property:</em> <code><dfn>qb:sliceStructure</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:Slice</a></code>
+ -> <em>Range:</em>
+ <code><a>qb:SliceKey</a></code>
)
</dt>
<dd>indicates the sub-key corresponding to this slice</dd>
<dt id="ref_qb_sliceKey_LC">
- <em>Property:</em> <code>qb:sliceKey</code>
- (
- <code>qb:DataSet</code>
- ->
- <code>qb:SliceKey</code>
+ <em>Property:</em> <code><dfn>qb:sliceKey</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:DataSet</a></code>
+ -> <em>Range:</em>
+ <code><a>qb:SliceKey</a></code>
)
</dt>
<dd>indicates a slice key which is used for slices in this dataset</dd>
@@ -1766,23 +1780,25 @@
<section id="reference-concepts">
<h3>Concepts</h3>
+<p><em>See Section <a href="#schemes">Concept schemes and code lists</a>.</em></p>
+
<dl class='vocab_reference'>
<dt id="ref_qb_concept">
- <em>Property:</em> <code>qb:concept</code>
- (
- <code>qb:ComponentProperty</code>
- ->
+ <em>Property:</em> <code><dfn>qb:concept</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:ComponentProperty</a></code>
+ -> <em>Range:</em>
<code>skos:Concept</code>
)
</dt>
<dd>Gives the concept which is being measured or indicated by a ComponentProperty.</dd>
<dt id="ref_qb_codeList">
- <em>Property:</em> <code>qb:codeList</code>
- (
- <code>qb:CodedProperty</code>
- ->
+ <em>Property:</em> <code><dfn>qb:codeList</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:CodedProperty</a></code>
+ -> <em>Range:</em>
<code>owl:unionOf(skos:ConceptScheme skos:Collection qb:Hierarchy)</code>
)
</dt>
@@ -1791,45 +1807,47 @@
<section id="reference-nonskos-hierarchy">
<h3>Non-SKOS Hierarchies</h3>
+<p><em>See Section <a href="#schemes-hierarchy-nonskos">Non-skos hierarchies</a>.</em></p>
+
<dl class='vocab_reference'>
<dt id="ref_qb_Hierarchy">
- <em>Class:</em> <code>qb:Hierarchy</code>
+ <em>Class:</em> <code><dfn>qb:Hierarchy</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>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>
+ <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:narrowingProperty</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>
<dt id="ref_qb_hierarchyRoot">
- <em>Property:</em> <code>qb:hierarchyRoot</code>
- (
- <code>qb:Hierarchy</code>
- ->
+ <em>Property:</em> <code><dfn>qb:hierarchyRoot</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:Hierarchy</a></code>
+ -> <em>Range:</em>
<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>
- ->
+ <em>Property:</em> <code><dfn>qb:narrowingProperty</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:Hierarchy</a></code>
+ -> <em>Range:</em>
<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>
+ <dd>Specifies a property which relates a parent concept in the hierarchy to a child concept. One of <code><a>qb:narrowingProperty</a></code> or <code><a>qb:broadeningProperty</a></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>
- ->
+ <em>Property:</em> <code><dfn>qb:broadeningProperty</dfn></code>
+ ( <em>Domain:</em>
+ <code><a>qb:Hierarchy</a></code>
+ -> <em>Range:</em>
<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>
+ <dd>Specifies a property which relates a child concept in the hierarchy to a parent concept. One of <code><a>qb:narrowingProperty</a></code> or <code><a>qb:broadeningProperty</a></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>
+ <em>Class:</em> <code><dfn>qb:AggregatableHierarchy</dfn></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>
@@ -1890,12 +1908,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>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>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
+ <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>
+ <li>Removed <code><a>qb:subSlice</a></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>Generalized range of <code><a>qb:codeList</a></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