StatDCAT-AP respects the conformance requirements defined for DCAT-AP version 1.1 (https://joinup.ec.europa.eu/release/dcat-ap-v11), which means that it will have, at least, the same mandatory classes and mandatory properties as DCAT-AP 1.1. StatDCAT-AP may extend DCAT-AP by specifying additional properties, as long as they are reused from existing RDF vocabularies.
During discussion with stakeholders, the following additional property was proposed:
‘Dimensions’ as a property for Dataset.
This property is intended to provide insight on the level of the dataset description of the kinds of observations that are contained in the data, e.g. whether the data contains observations related to time periods, regions, sex etc. The expected value for this property is a URI of a SKOS concept scheme or code list (see https://www.w3.org/TR/vocab-data-cube/#schemes).
Participants in this activity are asked to respond to the following questions:
- Is the information for this property available in existing statistical systems and applications?
- How will exposing this information to general data portals enhance the discoverability of statistical datasets?
- Do you know of any property in existing RDF vocabularies that could hold this information?
Please note that there is also a proposal (https://joinup.ec.europa.eu/discussion/dimensions-keywords) to expose these dimensions as strings in the property keyword for Dataset.
Comments
An option could be to use the property qb:dimension from the Data Cube vocabulary. That property is a subproperty of the property qb:componentProperty that has a domain of qb:ComponentSet, defined as "Abstract class of things which reference one or more ComponentProperties".
Given that fairly broad definition, would it be legal to use the property on dcat:Dataset?
The WG decided in the meeting of 13 May 2016 to discuss this issue further. One suggestion that was made at the meeting was to also include measures and attributes, either by
or
We are inviting opinions on these proposal from the community.
I think we should keep in mind that:
qb:MeasureProperty owl:disjointWith qb:AttributeProperty, qb:DimensionProperty;I find this constraint too strict, as we are very likely to encounter a concept, such as time, represented as a measure in one dataset, yet as a dimension in another. This is actually a Data Cube issue (not mentioned in the spec, but in the actual ontology; the reason behind the modeling choice is not entirely clear).
Please note that the requirement to express 'measures' was not brought up in the Working Group. The initial issue was about 'dimensions' and later 'attributes' were added. Therefore, I propose that further discussion will not consider measures.
Proposed resolution: Extension of DCAT-AP with Data Cube properties qb:dimension and qb:attribute
The requirement has been brought forward to expose on the level of the Dataset the dimensions, i.e. the kinds of observations that are contained in the data, e.g. whether the data contains observations related to time periods, regions, sex etc.
In further discussions, it was recognised that also information about the attributes of the observations in the dataset, e.g. what their status is (e.g. estimated, provisional), would be useful information for users.
The Data Cube vocabulary (W3C Recommendation) contains properties that are candidates for these two elements, qb:dimension and qb:attribute. The values for those properties are be references to controlled vocabularies. An example for dimensions would be a SKOS concept scheme for sexes (sdmx-code:sex); for attributes a common thesaurus of units of measure.
In discussions in the WG, it was mentioned that the properties qb:dimension and qb:attribute are used in the Data Cube vocabulary in a very specific way within the Data Cube model and that using the properties in a description of a dcat:Dataset is incompatible with the intended use. On the other hand, it could be argued that dcat:Dataset is not necessarily disjoint with the “Abstract class of things which reference one or more ComponentProperties” which is the definition of the domain of both properties.
If, however, the opinion in the group is that this kind of use should not be permitted, the alternative is that two new properties are created in the StatDCAT-AP namespace, e.g. stat:dimension and stat:attribute. Values of both properties would still be references to controlled vocabularies (e.g. SKOS concept schemes).
Two new properties, stat:dimension and stat:attribute, are included in Draft 4, section 6.2.1.
See also issue https://joinup.ec.europa.eu/node/156469/.