Skip to Content

7 Concept Roles

Last modified by Artur on 2025/07/14 10:19

Contents

7.1 Overview

The DSD Components of Dimension and Attribute can play a specific role in the DSD and it is important to some applications that this role is specified. For instance, the following roles are some examples:

Frequency – in a data set the content of this Component contains information on the frequency of the observation values
Geography - in a data set the content of this Component contains information on the geographic location of the observation values
Unit of Measure - in a data set the content of this Component contains information on the unit of measure of the observation values

In order for these roles to be extensible and also to enable user communities to maintain community-specific roles, the roles are maintained in a controlled vocabulary which is implemented in SDMX as Concepts in a Concept Scheme. The Component optionally references this Concept if it is required to declare the role explicitly. Note that a Component can play more than one role and therefore multiple “role” concepts can be referenced.

7.2 Information Model

The Information Model for this is shown below:

1748248853846-124.png

Figure 8: Information Model Extract for Concept Role

It is possible to specify zero or more concept roles for a Dimension, Measure Dimension and Data Attribute (but not the ReportingYearStartDay). The Time Dimension, Primary Measure, and the Attribute ReportingYearStartDay have explicitly defined roles and cannot be further specified with additional concept roles.

7.3 Technical Mechanism

The mechanism for maintain and using concept roles is as follows:

  1. Any recognized Agency can have a concept scheme that contains concepts that identify concept roles. Indeed, from a technical perspective any agency can have more than one of these schemes, though this is not recommended.
  2. The concept scheme that contains the “role” concepts can contain concepts that do not play a role. 
  3. There is no explicit indication on the Concept whether it is a ‘role” concept. 
  4. Therefore, any concept in any concept scheme is capable of being a “role” concept.
  5. It is the responsibility of Agencies to ensure their community knows which concepts in which concept schemes play a “role” and the significance and interpretation of this role. In other words, such concepts must be known by applications, there is no technical mechanism that can inform an application on how to process such a “role”.
  6. If the concept referenced in the Concept Identity in a DSD component (Dimension, Measure Dimension, Attribute) is contained in the concept scheme containing concept roles then the DSD component could play the role implied by the concept, if this is understood by the processing application. 
  7. If the concept referenced in the Concept Identity in a DSD component (Dimension, Measure Dimension, Attribute) is not contained in the concept scheme containing concept roles, and the DSD component is playing a role, then the concept role is identified by the Concept Role in the schema. 

7.4 SDMX-ML Examples in a DSD

The Cross-Domain Concept Scheme maintained by SDMX contains concept role concepts (FREQ chosen as an example). 

1748248881670-659.png

Whether this is a role or not depends upon the application understanding that FREQ in the Cross-Domain Concept Scheme is a role of Frequency.

Using a Concept Scheme that is not the Cross-Domain Concept Scheme where it is required to assign a role using the Cross-Domain Concept Scheme. Again FREQ is chosen as the example. 

1748248908247-956.png

T

his explicitly states that this Dimension is playing a role identified by the FREQ concept in the Cross-Domain Concept Scheme. Again the application needs to understand what FREQ in the Cross-Domain Concept Scheme implies in terms of a role. 

This is all that is required for interoperability within a community. The important point is that a community must recognise a specific Agency as having the authority to define concept roles and to maintain these “role” concepts in a concept scheme together with documentation on the meaning of the role and any relevant processing implications. This will then ensure there is interoperability between systems that understand the use of these concepts.

Note that each of the Components (Data Attribute, Primary Measure, Dimension, Measure Dimension, Time Dimension) has a mandatory identity association (Concept Identity) and if this Concept also identifies the role then it is possible to state this by

7.5 SDMX Cross Domain Concept Scheme

All concepts in the SDMX Cross Domain Concept Scheme are capable of playing a role and this scheme will contain all of the roles that were allowed at version 2.0 and will be maintained with new roles that are agreed at the level of the community using the Cross Domain Concept Scheme.

The table below lists the Concepts that need to be in this scheme either for compatibility with version 2.0 or because of requests for additional roles at version 2.1 which have been accepted.

Note that each of the Components (Data Attribute, Primary Measure, Dimension, Measure Dimension, Time Dimension) has a mandatory identity association (Concept Identity) and if this Concept also identifies the role then it is possible to state this by means of the isRole attribute (isRole=true) Additional roles can still be specified by means of the +role association to additional Concepts that identify the role.