Changes for page Guidelines for SDMX Data Structure Definitions

Last modified by Artur K. on 2026/05/29 14:28

From 1.1 to 1.2 From 1.3 to 1.4

From version 1.2

edited by Helena K.
on 2026/01/15 12:12

Change comment: There is no comment for this version

To version 1.3

edited by Helena K.
on 2026/01/15 12:15

Change comment: There is no comment for this version

Raw
Rendered

Summary

Page properties (1 modified, 0 added, 0 removed)

Details

Page properties

Content

@@ -73,7 +73,7 @@
 . If a concept is obsolete because only total values aggregated over the corresponding dimension are relevant, the dimension (or code list) should be restricted to a “total” item. For instance, an existing DSD on bilateral trade contains “Partner Country” as dimension, since data are collected with a breakdown by country of trade counterpart. The new data exchange disseminates similar data, but only the trade totals “vis-à-vis all countries”.
 . If a concept is not needed because it cannot even be relevant for the data at all or because an additional breakdown is just not available, the concept should be restricted to “not applicable” or “unknown” via constraints. For example, a financial instrument breakdown was not collected and it is unclear whether data for all or only for some financial instruments were included, that is whether the “total” value can be used. In this case, the dimension would be restricted to “unknown”. Consider another simple example of a DSD that contains, amongst others, the two dimensions “Unit of Measure” and “Base Period”. The code list for “Unit of Measure” consists of percent per annum, percentage, and index with base year=100. “Base Period” can contain dates, years, months, etc. If the new data exchange restricts “Unit of Measure” to percent per annum, “Base Period” becomes obsolete and should be constrained to “not applicable”.
--**2.1.3.2 Missing concepts**
++==== 2.1.3.2 Missing concepts ====
  In this case additional concepts (and possibly code lists) are required, for example to accommodate an additional cross-classification. One option is to adapt the existing DSD to satisfy the new needs, i.e., create a new version of the DSD by adding the concepts, dimensions/attributes, and code lists. The feasibility of this solution depends on the relation between the organization requiring the new data structure and the organization maintaining the existing DSD, and the relation between the two usage contexts. The original, restricted model needed for the existing data flows can be specified by means of constraints, as described above for irrelevant concepts, or by referring to the original version of the DSD.
@@ -93,17 +93,17 @@
 . No appropriate code lists are available. New code lists have to be defined based on the guidelines for the development of code lists. This may often be the case for domain-specific code lists, especially in new areas of investigation.
--**2.1.3.3 Concepts in different roles**
++==== 2.1.3.3 Concepts in different roles ====
  In this case concepts are available in other roles than required, for example what needs to be a dimension is merely an attribute or vice versa. This case is already briefly discussed above as part of the first case (“irrelevant concepts”). Basically, a new DSD has to be defined. It can reuse the concept scheme and code lists, but specifies the concepts in the new DSD as dimensions or attributes as required. In case an attribute needs to become a dimension, it may be necessary to define a new code list for that dimension in case it did not exist previously.
  An example for an attribute having to be redefined as a dimension may be the “Unit of measure” that is frequently just specified as an attribute. If certain indicators are presented in different units in the same data flow, the corresponding DSD must contain “Unit of measure” as dimension, though.
--**2.1.3.4 Different code lists**
++==== 2.1.3.4 Different code lists ====
  In this case the new requirements differ from the existing DSD with respect to some of the code lists, either by only a subset of codes being relevant, by a deviating hierarchical structure, or by necessitating additional codes. These three scenarios are discussed above as special cases of the “missing concepts” case. In theory, just defining a new code list whenever an existing one is not completely appropriate is also possible (but not desirable). However, this means that the overlapping items have to be managed in multiple code lists unless they are included by reference. Also, different DSDs have to be maintained. If the constraints are neither imposed at the code list nor at the DSD level, but at the data flow level, the DSD is simply reused. This is highly recommended. The cost of maintaining multiple DSDs or multiple, largely overlapping code lists can be high. The lack of harmonization has one advantage, though: the increased maintenance and versioning flexibility. For global data exchange, this is not regarded as a reasonable solution.
--**2.1.3.5 Pure vs. mixed dimensions**
++==== 2.1.3.5 Pure vs. mixed dimensions ====
  The design principle of pure dimensions is explained in more detail in subsections 3.3 and section 4 on data structuring approaches. If an existing DSD does not have the desired degree of dimension purity, it is necessary to further decompose and/or combine dimensions of that DSD. This will lead to a new derived DSD and also requires the definition of new (combined or split) code lists, unless they are available from elsewhere.
@@ -200,13 +200,13 @@
  |(% rowspan="2" %)**Concept**|(% colspan="2" %)**ECB**|(% colspan="2" %)**Eurostat**|**OECD**|(% colspan="2" %)**IMF**
  |**IRT**|**BOP**|**IIP**|**TS**|**BOP**|**CPIS**|**CDIS**
--|**Reporting country or area**|X|X|X|X|X|X|X
--|**Unit of measure**|X|X|X|X|X|X|X
--|**Flows and stocks indicator**|X|O|O|O|O|O|O
--|**Reporting sector**|X|X|X|O|X|X|X
--|**Financial instrument**|X|X|X|O|X|X|X
--|**Maturity**|X|X|X|O|X|X|O
--|**Valuation**|X|O|X|O|O|O|O
++|Reporting country or area|X|X|X|X|X|X|X
++|Unit of measure|X|X|X|X|X|X|X
++|Flows and stocks indicator|X|O|O|O|O|O|O
++|Reporting sector|X|X|X|O|X|X|X
++|Financial instrument|X|X|X|O|X|X|X
++|Maturity|X|X|X|O|X|X|O
++|Valuation|X|O|X|O|O|O|O
  == 3.4 Type of data exchange and recipient ==
@@ -559,18 +559,22 @@
  The second step in the process of defining a new DSD is the specification of code lists for all coded concepts. All dimensions must be coded (with time being an exception to this rule); attributes may be coded. For uncoded concepts, a data format has to be specified. Existing formats may be reused or new ones defined. An example is the time format that is specified in the SDMX COG. Figure 13 illustrates the code list specification process. If no relevant and suitable code list exists, a new one will be defined or a partially suitable one will be adapted (see Figure 16). Suitable code lists can simply be reused via reference.
--==== Figure 13. Code list specification process ====
++(% class="wikigeneratedid" id="HFigure13.Codelistspecificationprocess" %)
++Figure 13. Code list specification process
  Figure 14 recaps the priorities given to different types of existing code lists when searching for candidates for reuse (step 4.3.2.1.). Code lists recommended by the SDMX COG (and maintained by the SDMX consortium) are ranked the highest.
--==== Figure 14. Priority ranking of existing code lists for reuse ====
++(% class="wikigeneratedid" id="HFigure14.Priorityrankingofexistingcodelistsforreuse" %)
++Figure 14. Priority ranking of existing code lists for reuse
  Figure 15 summarizes the aspects to be considered in the evaluation of the suitability of existing code lists (step 4.3.2.2.). Figure 16 summarizes the scenarios of adapting existing code lists that do not fully meet the specified needs (step 4.3.2.3.2). For a detailed description of the cases of partial unsuitability see section 2.1. above.
--==== Figure 15. Aspects of code list suitability ====
++(% class="wikigeneratedid" id="HFigure15.Aspectsofcodelistsuitability" %)
++Figure 15. Aspects of code list suitability
--==== Figure 16. Code list modification scenarios ====
++(% class="wikigeneratedid" id="HFigure16.Codelistmodificationscenarios" %)
++Figure 16. Code list modification scenarios
  If new code lists need to be defined, please refer to the SDMX Guidelines for the creation of code lists. Basically, code, name, and definition need to be provided for each item in the code list. In addition, hierarchical code lists may be defined.
@@ -580,10 +580,10 @@
  Figure 17 provides an overview of all steps in the DSD design process as described in the previous subsections 1. to 3. Figure 18 compiles those steps into a checklist for DSD designers to help them make sure all aspects are considered.
--**Figure 17. DSD design process**
++Figure 17. DSD design process
--**Figure 18. Checklist for DSD design process**
++Figure 18. Checklist for DSD design process
  = 7 ANNEX 1. GLOSSARY OF TERMS =