Changes for page Guidelines for SDMX Data Structure Definitions

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

From 1.8 to 1.7 From 1.11 to 1.10

From version 1.10

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

Change comment: There is no comment for this version

To version 1.8

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

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -262,10 +262,11 @@
  |(% style="width:360px" %)special values of code lists such as “not applicable”, “total” may be rather heavily used|(% style="width:1255px" %)less usage of these special values
  |(% style="width:360px" %)creates sparse data if many observations use “not applicable”|(% style="width:1255px" %)way to avoid sparseness
  |(% style="width:360px" %)many constraints may be necessary due to sparseness|(% style="width:1255px" %)typically fewer constraints required because data are less sparse
--|(% style="width:360px" %)many dimensions are tantamount to many attachment levels for attributes (i.e. DSD more flexible in terms of attribute attachment)|(% style="width:1255px" %)less dimensions = less possible attribute attachment levels
--|(% style="width:360px" %)more difficult to handle by an end user|(% style="width:1255px" %)presumably more easily comprehensible and manageable by an end user
--|(% style="width:360px" %)more flexible in terms of defining queries; can be mapped to any “mixed” representation|(% style="width:1255px" %)less flexible in terms of search and retrieval
++|(% style="width:360px" %) |(% style="width:1255px" %)
++|(% style="width:360px" %) |(% style="width:1255px" %)
++
++
  The latter two aspects mentioned in the table could be summarized as the “many pure dimensions” approach being more difficult to handle for a “basic” user, but providing fewer options for an “advanced” user. When it comes to dissemination to end users, a purer data structure is the appropriate format for consumption by applications and advanced users. For less advanced user groups it makes sense to hide the (for them: unnecessary) complexity by means of concatenating dimensions, for instance to create a time series view.
  Comparing single-purpose and single-domain exchange scenarios with multi-domain and/or multi-purpose scenarios, pure concepts are typically easier to achieve in the former, whereas composite concepts/dimensions may make life easier in the latter, especially because certain cross-classification concepts may only apply to some domains and/or purposes covered. “Purpose” mean“mixed” dimensions make data structure less
@@ -278,13 +278,18 @@
  |**Level of data exchange**|**Pure vs. composite concepts approach**
  |**within an organization**|(((
  Depends on diversity of systems involved in data exchange.
++
  The approach that requires the least mapping (and similar processing) steps between the two communicating data structures is preferable in terms of a “quick win” solution.
++
  In general, a more granular model is preferable due to its flexibility that helps support potential future needs (with respect to processing, analysis, exchange, dissemination, etc.).
++
  However, an internal exchange should not be made more complex than necessary. If the structures of the communicating systems are comparable, it may not make sense to create an artificial intermediary structure that is more pure, but also more complex than both underlying structures.
++
  Still, as a longer-term strategy it seems reasonable to define a set of internal “standard” code lists that all systems can map to. This allows bilateral communication via the shared concepts and code lists meaning that every data structure only has to be mapped once – to the internal standard – to be able to communicate with all other participating (i.e. mapped) systems.
  )))
  |**between organizations at national level**|(((
  The pros and cons at this level of exchange are comparable to those at the “within organization” level. If the data structures of the communicating systems are comparable, there is no need to introduce complexity by a conceptually optimal, pure data structure. However, if the data structures deviate to a greater extent (and they often do), they should both be decomposed to find a “common denominator”, a more granular “exchange vocabulary” which they can be mapped to.
++
  If related international or national standards exist, they should be used, even though national labels and/or additional levels of detail may be required in the code lists.
  )))
  |**between international organization and national organizations of member countries**|International organizations should collect data at a level of granularity and purity that is most suitable for the intended (and potential future) analyses. The tradeoff with the higher complexity of constraints required to check structural validity of collected data needs to be taken into account as well. Also it is recommended to consider the burden that a more complex data structure may put on national data providers. However, once a DSD is defined, its lifetime is expected to be a number of years. The main effort of the data provider is to specify the mapping from the production data structure to the DSD. Once this is done the data exchange can be automated and the complexity of the DSD does not matter that much.