Changes for page Guidelines for SDMX Data Structure Definitions
Last modified by Artur K. on 2026/05/29 14:28
Summary
-
Page properties (1 modified, 0 added, 0 removed)
Details
- Page properties
-
- Content
-
... ... @@ -266,8 +266,6 @@ 266 266 |(% style="width:360px" %)more difficult to handle by an end user|(% style="width:1255px" %)presumably more easily comprehensible and manageable by an end user 267 267 |(% 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 268 268 269 - 270 - 271 271 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. 272 272 273 273 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 ... ... @@ -280,18 +280,13 @@ 280 280 |**Level of data exchange**|**Pure vs. composite concepts approach** 281 281 |**within an organization**|((( 282 282 Depends on diversity of systems involved in data exchange. 283 - 284 284 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. 285 - 286 286 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.). 287 - 288 288 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. 289 - 290 290 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. 291 291 ))) 292 292 |**between organizations at national level**|((( 293 293 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. 294 - 295 295 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. 296 296 ))) 297 297 |**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.