This document describes an extension to the existing RDF Data Cube ontology to support specification of key metadata required to interpret spatio-temporal data. The RDF Data Cube defines CodedProperties, which relate to a reference system based on a list of terms, QB4ST provides generalized support for numeric and other ordered references systems, particularly Spatial Reference Systems and Temporal Reference Systems. Although RDF Data Cube supports AttributeProperties for metadata of individual observations, the requirement is to specify such metadata per property, rather than for each observation, and thus allow different properties to use different spatial or temporal reference systems. QB4ST also provides for such properties to be defined for a ComponentProperty, or defined at the time of referencing that ComponentProperty in a ComponentSpecification. QB4ST is thus aimed at improving the scope and consistency of dataset metadata, and hence discovery and interpretation of spatio-temporal data through its spatio-temporal reference system and bounding values.
This is expected to be the final release of this document by the Spatial Data on the Web Working Group.
For OGC This is a Public Draft of a document prepared by the Spatial Data on the Web Working Group (SDWWG) — a joint W3C-OGC project (see charter). The document is prepared following W3C conventions. The document is released at this time to solicit public comment.
This document represents early thinking about how best to bridge the gap between available standards and identified Use Cases and Requirements for "Spatial Data on the Web" [[SDW-UCR]]. It does not represent or replace any known implementation practice.
QB4ST is an extension to the RDF Data Cube [[VOCAB-DATA-CUBE]] to provide mechanisms for defining spatio-temporal aspects of dimension and measure descriptions.
QB4ST is intended to enable the development of semantic descriptions of specific spatio-temporal data elements by appropriate communities of interest, rather than to enumerate a static list of such definitions. It provides a minimal ontology of spatio-temporal properties and defines abstract classes for data cube components (i.e. dimensions and measures) that use these, to allow classification and discovery of specialized component definitions using general terms.
QB4ST is designed to support the publication of consistently described re-usable and comparable definitions of spatial and temporal data elements by appropriate communities of practice. One obvious such case is the use of GPS coordinates described as decimal latitude and longitude measures. Another example is the intended publication of a register of Discrete Global Grid Systems (DGGS) by the OGC DGGS Working Group. QB4ST is intended to support publication of descriptions of such data using a common set of attributes that can be attached to a property description (extending the available RDF Data Cube mechanisms for attributes of observations)
This document will refer to a set of instances of RDF Data Cube components defined using the QB4ST extensions. These examples are informative, although publication of a separate specification for common spatial and temporal dimensions and measures is an expected outcome.
The motivation for QB4ST arises from identification of Use Case Requirements [[SDW-UCR]] and Best Practices [[SDW-BP]] by the Spatial Data on the Web Working Group. The Data on the Web Best Practices [[DWBP]] indicate re-use of common vocabularies: BP15: Reuse vocabularies, preferably standardized ones. As far as could be ascertained no such vocabularies existed to support key UCRs identified that require explicit metadata about spatio-temporal aspects of data: CRS Definition, Determinable CRS, Quality Per Sample, Spatial Metadata, GeoReferenced Data and Machine To Machine. Two sets of vocabularies are required for each case - one to describe the aspect of the data being expressed, and another for the relationships (predicates) by which such descriptions may be attached to data objects. QB4ST is primarily aimed at providing canonical predicates to include metadata about data elements with spatial and/or temporal characteristics.
The names of RDF entities — classes, predicates, individuals — are URIs. These are usually expressed using a compact notation where the name is written prefix:localname, and where the prefix identifies a namespace URI. The namespace identified by the prefix is prepended to the localname to obtain the full URI.
The following namespaces are used in this document:
| Prefix | Namespace | Reference |
|---|---|---|
| qb4st | http://www.w3.org/ns/qb4st/ | This document |
| qb | http://purl.org/linked-data/cube# | [[VOCAB-DATA-CUBE]] |
| skos | http://www.w3.org/2004/02/skos/core# | [[SKOS-REFERENCE]] |
| scovo | http://purl.org/NET/scovo# | [[SCOVO]] [[HAUS09]] |
| void | http://rdfs.org/ns/void# | [[VOiD]] |
| foaf | http://xmlns.com/foaf/0.1/ | [[FOAF]] |
| org | http://www.w3.org/ns/org# | [[Vocab-ORG]] |
| dct | http://purl.org/dc/terms/ | [[DCTerms]] |
| owl | http://www.w3.org/2002/07/owl# | [[OWL2-PRIMER]] |
| rdf | http://www.w3.org/1999/02/22-rdf-syntax-ns# | [[RDF-CONCEPTS]] |
| rdfs | http://www.w3.org/2000/01/rdf-schema# | [[RDF-SCHEMA]] |
| geo | http://www.w3.org/2003/01/geo/wgs84_pos# | [[W3C-BASIC-GEO]] |
| eg | http://example.org/ns# |
All RDF examples are written in Turtle syntax [[Turtle]].
A data interchange, however that interchange occurs, is conformant with QB4ST if:
A conforming data interchange:
The RDF Data Cube [[VOCAB-DATA-CUBE]] is an existing standard for representing data as RDF.
It is derived from the traditions of Statistical Data Metadata Exchange [[SDMX]], and is typically used for data that is associated with statistical regions (e.g. government jurisdictions). It provides a canonical mechanism for metadata binding the components of a datacube to a range defined by a set of coded values, using the SKOS vocabulary. It also provides for a generalized "AttributeProperty" that can contain additional information about an "Attachable" - i.e. a Dataset, a subset (slice) or an observation. Individual components (such as measures and dimensions) are not included in this notion, so it is not directly possible to define the reference system for each component individually, and there is no canonical representation of reference systems other than "codelists."
Some spatio-temporal concepts have been defined as extensions to RDF Data Cube for use in SDMX applications. These simply refer to named concepts in a SDMX specific vocabulary, as seen in the example. These are not general enough definitions for use outside the SDMX context, nor do they provide for metadata to allow these dimensions to be fully specified. They do, however, highlight the need for such specialisations in practice, and that [[VOCAB-DATA-CUBE]] does not directly support these concerns.
# REF_AREA sdmx-dimension:refArea a qb:DimensionProperty, rdf:Property ; rdfs:range rdfs:Resource ; qb:concept sdmx-concept:refArea ; rdfs:label "Reference Area"@en ; rdfs:comment """The country or geographic area to which the measured statistical phenomenon relates."""@en ; rdfs:isDefinedBy <https://sdmx.org/wp-content/uploads/01_sdmx_cog_annex_1_cdc_2009.pdf> . # REF_PERIOD sdmx-dimension:refPeriod a qb:DimensionProperty, rdf:Property ; rdfs:range rdfs:Resource ; qb:concept sdmx-concept:refPeriod ; rdfs:label "Reference Period"@en ; rdfs:comment """The period of time or point in time to which the measured observation is intended to refer."""@en ; rdfs:isDefinedBy <https://sdmx.org/wp-content/uploads/01_sdmx_cog_annex_1_cdc_2009.pdf> .
OWL-Time [[OWL-Time]] provides basic concepts for Time as well as canonical terms for commonly used specializations. QB4ST extends RDF Data Cube by specifying use of OWL-Time as the appropriate ontology for temporal reference systems.
There is currently no foundation ontology equivalent to OWL-Time for spatial concepts. Although the GeoSPARQL [[GeoSPARQL]] specification includes some concepts within the larger scope of defining functions to extend the SPARQL language. QB4ST will thus provide placeholders for necessary concepts that can be declared equivalent to the spatial concepts in use within an implementation.
Online Analytical Processing (OLAP) provides the underlying meta-model for dimensional data, and a richer set of concepts including how dimensions are "rolled-up" with functions that aggregate data. At least two attempts have been made recently to characterise these general concepts using an ontology, [[QB4OLAP]] and [[XKOS]]. These do not currently have a formal status, and so its not appropriate to directly reuse these vocabularies within QB4ST, however it is also noted that this is a more general set of issues, and is thus out of scope for QB4ST. Application may choose the model and vocabulary for these aspects and combine with QB4ST elements as required. What has been provided is a simple model based on the SKOS semantics already adopted by [[VOCAB-DATA-CUBE]] that will allow at least declaration of structural hierarchies to be provide, whilst leaving the semantics of the relationships in that structure to more specialised models.
The scope of the Spatial Data on the Web Working Group does not include updating [[VOCAB-DATA-CUBE]]. Thus a requirement is that QB4ST re-uses and respects the declared semantics of RDF Data Cube, OWL-Time and other relevant W3C standards, such as RDFS, OWL, SKOS.
The RDF Data Cube specification provides an ontology in the form of a RDFS class model for describing the elements of a dataset by classifying a "record" (an instance of a resource with a set of properties) as a qb:Observation and then allowing the properties of that Observation to be classified as Dimensions, Measures or Attributes. This classification must be undertaken in a separate ontology that must be defined by the domain of use. Where possible, arbitrary extensions to the data model should be avoided. There are however a number of limitations of the RDF Data Cube model when it comes to the case of data organized using typical spatial and temporal reference systems.
The main limitation of RDF Data Cube is that Attribute properties, intended to convey such things as the unit of measure of an observation, can be attached to a complete Observation, or a higher level aggregation (DataSet or Slice), but not unambiguously to a specific component. Spatio-temporal data will have often have multiple values recorded, such as latitude, longitude, elevation and observation time. Often spatial measurements are either recorded in, or need to be delivered in, a domain-specific reference system — for example a national grid system, local building coordinates, pixel location in a satellite image — and converted to a more generally understood reference system — such as WGS84 coordinates for latitude and longitude. Such conversions have implications for the interpretation of such data, and require attributes to be attached to individual property definitions. Likewise, a mechanism to specify precision and data quality of each component is required. RDF Data Cube does not provide this finer-grained assignment of attributes to specific components.
The choice here is either to update [[VOCAB-DATA-CUBE]] or provide an extended model. The latter approach allows us to provide a set of canonical property names for such attributes, and to allow them to be attached either to a qb:Component (to apply to all Observations using a specific dimension), or a qb:ComponentSpecification (allowing attachment to components within a specific dataset). Note that if defined by extending qb:Attribute such attributes are already attachable to Observation, DataSet and Slice.
Many applications of qb:CodedProperty may require very large, and potentially dynamic codelists. Spatial feature references are such a case, where we may, for example, have a national scope database of land parcels, but also a subset for a given local administration. It is theoretically possible for each reference used to be interrogated to see if is a member of the national codelist, but where such codelists are spatial data sets this is not feasible due to both the potentially large number of features and the amount of data that may be included describing feature geometry. Furthermore, although feature identifies may be stable, new ones may be added regularly. The same issues apply to non-spatial codelists, for example, the list of biota taxon keys managed by the Global Biodiversity Information Facility, a very large and dynamic set of codes. A database of invasive species may use these codes, but be restricted to using those codes that appear in a a locally managed list of invasive species. qb:codeList has a declared rdfs:domain of a qb:CodedProperty. If dimension D1 defines the use of GBIF taxon keys, there is currently no obvious mechanism to define D2 to be equivalent to D1, but using a refined range such as a UK list of declared weeds.
One option would be to relax the rdfs domain of qb:codeList - however this changes the [[VOCAB-DATA-CUBE]] model. Another option is to allow for instances of qb:ComponentProperty to have an inheritance hierarchy, with the semantics that the property qb:codeList of a child refers to a valid subset of the codelist its parent.
As seen from the issues regarding refinement of codelists there is a need to be able to define restricted versions of ComponentProperty, and to be able to traverse this hierarchy in order of refinement. This is the same requirement met by SKOS using "narrower", "broader", "narrowerTransitive", "broaderTransitive". Reusing these terms from SKOS, for which the rdfs:domain is specified to be a skos:Concept, implies that qb:ComponentProperty instances are also skos:Concepts, which is not unreasonable, and provides for using SKOS semantics to offer alternative labels, multiple identifying notation codes, equivalence statements, etc.
A common requirement when describing a spatial or temporal aspect of a dataset is to define the range of its spatial and temporal properties. This is usually a dataset specific qualification, and thus is typically required to be an attribute of a ComponentSpecification. Canonical means to specify the start and end values of [numeric, time etc] or ordered lists are required. Also required is the ability to specify range using nominal values within a notional hierachy of features, such as administrative units within a specific country.
In much the same way as skos:Concepts may have defined narrower terms, spatial references may be nested, for example a country may be divided into a series of administrative units, or a grid may be broken into a finer grid. Determining the nature of such relationships may be possible by analysing the declared types designated by the rdfs:range of qb:ComponentProperty elements - however this requires both dereferencing these and the ability to interpret how such nesting relationships are described, if in fact such information is available. There is thus a requirement to provide a simple declaration of sub-division relationships between the ranges of related spatial components.
The normative definition of the QB4ST ontology is available at https://www.w3.org/ns/qb4st/. This section highlights and explains the most important aspects of the ontology but is not intended to be a complete specification.
QB4ST defines a number of basic concepts that could be defined by standard vocabularies with broader scope, but which are not currently available. These can be expected to be aligned (e.g. using owl:equivalentClass) with future standards.
qb4st:SpatialThing a rdfs:Class, owl:Class ;
rdfs:label "Spatial Thing"@en ;
rdfs:comment "This is defined here pending availability of a canonical definition of spatial concepts - at which point an equivalence will be declared"@en .
qb4st:Point a rdfs:Class, owl:Class ;
rdfs:label "Geometric Point"@en ;
rdfs:comment "This is defined here pending availability of a canonical definition of spatial concepts - at which point an equivalence will be declared"@en .
qb4st:CRS a rdfs:Class, owl:Class ;
rdfs:label "Coordinate Reference System"@en ;
rdfs:comment "This is defined here pending availability of a canonical definition of spatial concepts - at which point an equivalence will be declared"@en .
qb4st:AnyNumber a rdfs:Class, owl:Class ;
rdfs:label "Any number"@en ;
rdfs:comment "A datatype that is the union of numeric xsd data types. equivalent to the xsd specification that uses an xsd:union of memberTypes='xsd:decimal xsd:double xsd:float xsd:integer'."@en ;
owl:equivalentClass [
rdf:type rdfs:Datatype ;
owl:unionOf (xsd:float xsd:decimal xsd:integer xsd:double)
] .
When a property of an object is defined, this can be either as an rdf:Property, defining a predicate that can be used to link a value to the object - but it can also be a more abstract reference to a named element in an arbitrary data structure. (I.e. we can use QB4ST to describe data structures that are not necessarily encoded in RDF, although it does define an RDF encoding should this be required.
The most common case is for spatial or temporal properties to be measures associated with another property measured at this time and location. In some cases however, a single observation is taken at a predetermined location or time, in which case these properties are "dimensions". In either case, common properties relating to their spatio-temporal nature are needed, and defined by QB4ST:
qb4st:srs a rdfs:Property, owl:ObjectProperty ; # meta:rangeIncludes qb4st:SpatialProperty, qb4st:SpatialComponentSpecification ; rdfs:label "Spatial Reference System"@en ; rdfs:comment "Generalised Spatial Reference System - specific types may be coordinate, grid or feature based "@en . qb4st:crs a rdfs:Property, owl:ObjectProperty ; # meta:rangeIncludes qb4st:SpatialProperty, qb4st:SpatialComponentSpecification ; rdfs:subPropertyOf qb4st:srs ; rdfs:label "CRS binding for a component specification or a property"@en ; rdfs:comment "Allows declaration of a CRS for any spatial propert -- do we want to leave domain open? Leaves it to a general spatial ontology to handle if CRS is a canonical URI set , or dereferences to anything specific)"@en . qb4st:crsaxis a rdfs:Property ; # meta:rangeIncludes qb4st:SpatialProperty, qb4st:SpatialComponentSpecification ; rdfs:label "CRS axis element name"@en ; rdfs:comment "Names a specific axis of the CRS"@en . qb4st:coordGranularity a rdfs:Property ; # meta:domainIncludes qb4st:CoordDimension , qb4st:SpatialComponentSpecification ; rdfs:range qb4st:AnyNumber ; rdfs:label "Resolution (Granularity)" ; rdfs:comment "Dimensions are indexes, a coordDimension specifies the granular partitioning of the coordinate space represented."@en . qb4st:subdivides a rdfs:Property ; rdfs:label "Subdivides reference unit"@en ; rdfs:comment "Identifies that the range of the subject is a smaller division of the range of the identified object - either a qb:ComponentProperty or indirectly via a qb:ComponentSpecification"@en ; # meta:domainIncludes qb4st:CoordDimension, qb4st:SpatialComponentSpecification ; # meta:rangeIncludes qb4st:CoordDimension, qb4st:SpatialComponentSpecification .
Let us look at a well known example of a geo-spatial location recorded as part of an observation. The Basic Geo (WGS84 lat/long) Vocabulary [[W3C-BASIC-GEO]] allows either individual values for latitude and longitude, or a complex point object to be used (note that only a single latitude and longitude value may be present, but possibly multiple Point objects may be recorded).
@prefix crs-ogc: <http://www.opengis.net/def/crs/OGC/1.3/> . @prefix crs-epsg: <http://www.opengis.net/def/crs/EPSG/0/> . geo:lat a qb4st:CoordMeasure ; qb4st:crs crs-ogc:CRS84, crs-epsg:4326 ; qb4st:crsaxis "latitude" ; qb4st:crslabel "WGS84" . geo:long a qb4st:CoordMeasure ; qb4st:crs crs-ogc:CRS84, crs-epsg:4326 ; qb4st:crsaxis "longitude" ; qb4st:crslabel "WGS84" . geo:Point a qb4st:PositionMeasure ; qb4st:crslabel "WGS84" ; qb4st:crs crs-ogc:CRS84, crs-epsg:4326 . eg:exampleDSD a qb:DataStructureDefinition ; qb:component eg:exampleSpatialMeasure . eg:exampleSpatialMeasure a qb4st:SpatialComponentSpecification, qb:ComponentSpecification ; qb:measure geo:Point .
In this case we have made assertions about externally defined rdfs:Property (geo:lat, geo:Point) as spatial components within the QB4ST RDFS class hierarchy. This makes it possible for an application to readily determine which properties of an object described using QB4ST are spatial, and hence what types of actions make sense with this data.
In a future revision of this document it is intended to add an example of using QB4ST to describe in detail the axes of a gridded coverage.
QB4ST defines a "reference Area" in a more generalized way than and SDMX dimension, simply requiring that referenced areas a identifiable as spatial Features (qb4st:Feature) which implies stable URI identification.
The additional predicate qb4st:subdivides provides a declarative means to express the relationship between two different feature sets representing nested topology (for example countries containing administrative units). This means that applications do not need to inspect data sets bound to each dimension, or be able to identify this relationship from other forms of metadata or information model, and hence publishers do not need to provide standardized formalisms of information models for each data set (notwithstanding the desirability of such models).
qb4st:RefArea a rdfs:Class, owl:Class ;
rdfs:subClassOf qb:SpatialDimension, qb:CodedProperty ;
rdfs:label "Location by spatial Feature"@en ;
rdfs:comment "Spatial context identified by a Spatial Feature. As a dimension, it is used as an index, and may not be missing or multi-valued. Such a property is both a spatial property and a CodedProperty. Note this must also have a codelist defined, and thus each Feature is regarded as a skos:Concept"@en ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty rdfs:range ;
owl:someValuesFrom qb4st:Feature
] .
qb4st:subdivides a rdfs:Property ;
rdfs:range qb4st:SpatialDimension ;
rdfs:domain qb4st:SpatialDimension ;
rdfs:label "Sub-divides Spatial Reference Area" ;
rdfs:comment "Indicates that the subject dimension property is bound to feature identifiers that are sub-divisions of the features used by the object dimension property. This means applications do not need to download either information models or feature sets to determine this critical relationship, nor rely on complex spatial operations."@en .
eg:country a qb4st:RefArea ; qb:codeList eg:Countries . eg:admin1 a qb4st:RefArea ; qb:dimension qb4st:refArea ; qb:codeList eg:Admin1 ; qb4st:subdivides eg:country .
qb4st:SpatialProperty a rdfs:Class, owl:Class ;
rdfs:subClassOf rdfs:Property, qb:ComponentProperty ;
rdfs:label "Abstract Spatial Property"@en ;
rdfs:comment "A generalised spatial property - defines how properties like CRS, accuracy and precision can be applied to any spatial value in a dimension of measure"@en ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty qb:concept ;
owl:someValuesFrom qb4st:SpatialThing
] .
qb4st:SpatialMeasure a rdfs:Class, owl:Class ;
rdfs:subClassOf qb:MeasureProperty, qb4st:SpatialProperty ;
rdfs:label "abstract measure of spatial location"@en .
qb4st:PositionMeasure a rdfs:Class, owl:Class ;
rdfs:subClassOf qb4st:SpatialMeasure ;
rdfs:label "Location by Point Coordinates"@en ;
rdfs:comment "a measure of location as a Point (i.e. a complex spatial data type)"@en ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty rdfs:range ;
owl:someValuesFrom qb4st:Point
] .
qb4st:CoordMeasure a rdfs:Class, owl:Class ;
rdfs:subClassOf qb4st:SpatialMeasure ;
rdfs:label "Location partially recorded by a single Coordinate"@en ;
rdfs:comment "Abstract class for partial measure of location as a single Coordinate - such as latitude"@en;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty rdfs:range ;
owl:someValuesFrom qb4st:AnyNumber ;
] .
By using the QB4ST specializations of qb:ComponentProperty, a qb:DataStructureDefinition can use instances of these classes to define their spatio-temporal charactieristics (e.g. CRS), and dataset containing such components can be understood to be a "spatial dataset" by testing for such elements. QB4ST also defines classes for spatial, temporal and spatio-temporal data structures to allow these to be declared as such, and avoid placing the burden on the client or server to perform RDFS reasoning to establish these classifications.
qb4st:SpatialDSD a rdfs:Class, owl:Class ;
rdfs:subClassOf qb:DataStructureDefinition ;
rdfs:label "Spatial Data Structure Definition"@en ;
rdfs:comment "Specifies a data set includes one or more spatial properties, either in its organising dimension or its observed values"@en ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty qb:component ;
owl:someValuesFrom qb4st:SpatialComponentSpecification
] .
qb4st:SpatialComponentSpecification a rdfs:Class, owl:Class ;
rdfs:subClassOf qb:ComponentSpecification ;
rdfs:label "Spatial Component"@en ;
rdfs:comment "A generalised spatial property - allows properties like CRS, bounds, accuracy and precision to be define for a spatial dimension or measure"@en ;
rdfs:subClassOf [
a owl:Restriction ;
owl:onProperty qb:componentProperty ;
owl:someValuesFrom qb4st:SpatialProperty
] .
Equivalent classes are defined for TemporalDSD and SpatioTemporalDSD, along with further specializations such as qb4st:SpatialDimensionComponentSpecification.
Datasets may be partially described using qb:DataStructureDefinition, which have qb:componentSpecification properties which bind qb:ComponentProperties using qb:measure, qb:dimension and qb:attribute. QB4ST extends this by allowing relevant properties of the dataset related to specific spatio-temporal dimensions and measures to be specified as additional properties of qb:ComponentSpecification elements (the rdfs:range of qb:componentSpecification).
eg:ds1_latMeasure a qb:ComponentSpecification, qb4st:SpatialComponentSpecification ; qb:measure geo:lat ; rdfs:comment "Units of measure should be implicit in the definition of qeo:lat, via dereferencing the resource related by qb4st:crs, however it may be useful to allow it to be specified here and checked or inferred"@en ; qb4st:resolution 0.001 ; qb4st:envelopeStart -31.5 ; qb4st:envelopeEnd -17.2 .
eg:ds1_latMeasure a qb:ComponentSpecification, qb4st:SpatialComponentSpecification ; qb:measure geo:Point ; rdfs:comment "Units of measure should be implicit in the definition of measure, via dereferencing the resource related by qb4st:crs, however it may be useful to allow it to be specified here and checked or inferred"@en ; qb4st:resolution 0.001 ; qb4st:envelope "POLYGON((90 41.87, 93.33 41.87, 93.33 38.18, 90 38.18, 90 41.87))"^^ogc:wktLiteral .
A significant challenge in using RDF Data Cube is that many related dimensions and measures may be defined, but there is no obvious way of determing the relationships without potentially dereferencing and reasoning over very large, possibly dynamic, code lists. This is problematic for many reasons, including that spatial features may be regarded as skos:Concept to be consistent with the semantics of RDF Data Cube, but not actually dereferenceable in this form.
The approach chosen is to use SKOS semantics to allow such declarations of hierarchy for convenience, leaving the details of the relationship between hierarchy levels to additional vocabularies, such as [[QB4OLAP]] or [[XKOS]], or to the underlying model of the Classes referenced by the rdfs:range.
Note that the use of skos:broader relationship preserves the immediate parent-child relationship, whereas A rdfs:subClassOf B . B rdfs:subClassOf C . also entails A rdfs:subClassOf A . A rdfs:subClassOf C . , thus potentially losing information about which subject (A, B or C) is the immediate parent of A.
geo:Point a qb4st:PositionMeasure ; qb4st:crs <http://www.opengis.net/def/crs/OGC/1.3/CRS84> . eg:propertyCentroid a qb4st:PositionMeasure ; rdfs:label "The centroid of a land parcel determined by an observed address, and recorded as a nominal location"@en ; skos:broader geo:Point .
This mechanism may be applied to non-spatial components.
eg:GBIF a qb:CodedProperty ; qb:codelist <uri of GBIF taxon keys> ; rdfs:range eg:AnyTaxon . eg:GBIFspecies a qb:CodedProperty ; skos:broader eg:GBIF ; qb:codelist <uri of GBIF taxon keys> ; # inferrable from skos:broader relationship using specific entailment rules rdfs:range eg:SpeciesTaxon . # must be subtype of GBIFSpecies eg:InvasiveSpecies a qb:CodedProperty ; skos:broader eg:GBIFspecies ; qb:codelist <uri of InvasiveSpecies list> ; # all members must also be members of the GBIF concept scheme rdfs:range eg:SpeciesTaxon . # must be subtype of GBIFSpecies eg:AnyTaxon a rdfs:Class ; rdfs:comment "RDF type of a taxon key at any level of the tree of life (kingdom, familiy, genus, species etc)"@en . eg:SpeciesTaxon a rdfs:Class ; rdfs:subClassOf eg:AnyTaxon ; rdfs:comment "RDF type of a taxon key of a specific Species"@en .
# REF_AREA sdmx-dimension:refArea a qb:DimensionProperty, rdf:Property ; rdfs:range rdfs:Resource ; qb:concept sdmx-concept:refArea ; rdfs:label "Reference Area"@en ; rdfs:comment """The country or geographic area to which the measured statistical phenomenon relates."""@en ; rdfs:isDefinedBy <https://sdmx.org/wp-content/uploads/01_sdmx_cog_annex_1_cdc_2009.pdf> . # REF_PERIOD sdmx-dimension:refPeriod a qb:DimensionProperty, rdf:Property ; rdfs:range rdfs:Resource ; qb:concept sdmx-concept:refPeriod ; rdfs:label "Reference Period"@en ; rdfs:comment """The period of time or point in time to which the measured observation is intended to refer."""@en ; rdfs:isDefinedBy <https://sdmx.org/wp-content/uploads/01_sdmx_cog_annex_1_cdc_2009.pdf> . # SEX sdmx-dimension:sex a qb:DimensionProperty, rdf:Property ; rdfs:range rdfs:Resource ; qb:concept sdmx-concept:sex ; rdfs:label "Sex"@en ; rdfs:comment """The state of being male or female."""@en ; rdfs:isDefinedBy <https://sdmx.org/wp-content/uploads/01_sdmx_cog_annex_1_cdc_2009.pdf> . # TIME_PERIOD sdmx-dimension:timePeriod a qb:DimensionProperty, rdf:Property ; rdfs:range rdfs:Resource ; qb:concept sdmx-concept:timePeriod ; rdfs:label "Time Period"@en ; rdfs:comment """The period of time or point in time to which the measured observation refers."""@en ; rdfs:isDefinedBy <https://sdmx.org/wp-content/uploads/01_sdmx_cog_annex_1_cdc_2009.pdf> .