Skip to Content
Last modified by Helena on 2025/09/10 11:19
From version 7.5
edited by Helena
on 2025/05/14 13:36
Change comment: There is no comment for this version
To version 10.2
edited by Helena
on 2025/05/14 14:41
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -1 Overview
1 +SDMX STANDARDS
Parent
... ... @@ -1,0 +1,1 @@
1 +Methodology.WebHome
Content
... ... @@ -88,8 +88,6 @@
88 88  
89 89  == //2.2 Transmission Formats// ==
90 90  
91 -:
92 -
93 93  (((
94 94  (% style="width:952.039px" %)
95 95  |(% style="width:130px" %)**SDMX-ML**|(% style="width:820px" %)(((
... ... @@ -117,20 +117,15 @@
117 117  The JSON structure message is not backwardly compatible primarily due to:
118 118  
119 119  * Changes to the information model
120 -* Changes to the way the structures are organised into
121 -
122 -‘collections’ within the message
123 -
118 +* Changes to the way the structures are organised into ‘collections’ within the message
124 124  * Deprecation of the Agency, ID, Version option for referencing of structures in messages
125 125  )))
126 126  |(% style="width:130px" %)**SDMX-EDI**|(% style="width:820px" %)The EDI format for both structures and data has been deprecated.
127 -|(% style="width:130px" %)**SDMX-CSV**|(% style="width:820px" %)The CSV data and reference metadata messages are not backwardly compatible with those under version 2.1 due to changes to the structure of the messages needed to support new features such as the improved REST API data queries.**     **
122 +|(% style="width:130px" %)**SDMX-CSV**|(% style="width:820px" %)The CSV data and reference metadata messages are not backwardly compatible with those under version 2.1 due to changes to the structure of the messages needed to support new features such as the improved REST API data queries.
128 128  )))
129 129  
130 130  == //2.3 Information Model// ==
131 131  
132 -:
133 -
134 134  (((
135 135  (% style="width:955.039px" %)
136 136  |(% style="width:132px" %)**Data Structure Definition**|(% style="width:819px" %)(((
... ... @@ -158,10 +158,7 @@
158 158  
159 159  //Conversion guidance for implementors//
160 160  
161 -A version 2.1 Metadata Structure Definition can be converted to the version 3.0 model under some circumstances, but target information is either lost or has to be translated into a metadataflow. Further, conversion of a Data Structure Definition for collecting reference metadata against a dataset would need to make changes to the dataset’s Data Structure Definition. As the Data Structure Definition may not actually be specified, judgement would need to be taken, perhaps determining the most likely candidate by examining which
162 -)))
163 -|(% style="width:132px" %) |(% style="width:819px" %)(((
164 -already have metadata reported against their datasets. A 2.1 metadata report could be converted to a version 3.0 Metadataset if it is attached to a structure, but requires a Metadata Provision Agreement which would need to be created if not already in existence.
154 +A version 2.1 Metadata Structure Definition can be converted to the version 3.0 model under some circumstances, but target information is either lost or has to be translated into a metadataflow. Further, conversion of a Data Structure Definition for collecting reference metadata against a dataset would need to make changes to the dataset’s Data Structure Definition. As the Data Structure Definition may not actually be specified, judgement would need to be taken, perhaps determining the most likely candidate by examining which already have metadata reported against their datasets. A 2.1 metadata report could be converted to a version 3.0 Metadataset if it is attached to a structure, but requires a Metadata Provision Agreement which would need to be created if not already in existence.
165 165  
166 166  Conversion from the version 3.0 model to version 2.1 cannot be performed reliably. The process would need target information to be derived from analysis of the Metadataflows and Metadata Provision Agreements. Depending on the complexity it may not be possible to express that information in a version 2.1 Data Structure Definition.
167 167  )))
... ... @@ -225,7 +225,8 @@
225 225  Removed Maintainable Artefacts
226 226  
227 227  * Structure Set – replaced by Structure Map and the four item scheme maps
228 -* Hierarchical Codelist – replaced by Hierarchy and Hierarchy Association • Constraint – replaced by Data Constraint and Metadata Constraint
218 +* Hierarchical Codelist – replaced by Hierarchy and Hierarchy Association
219 +* Constraint – replaced by Data Constraint and Metadata Constraint
229 229  
230 230  Changed Maintainable Artefacts
231 231  
... ... @@ -239,7 +239,7 @@
239 239  
240 240  * GeospatialInformation – a string type where the value is an expression defining a set of geographical features using a purpose-designed syntax
241 241  
242 -== //3.3 Areas Unchanged from Version 2.1// ==
233 +== 3.3 Areas Unchanged from Version 2.1 ==
243 243  
244 244  The following areas of the information model are unchanged from version 2.1:
245 245  
... ... @@ -252,7 +252,7 @@
252 252  * Reporting taxonomy
253 253  * Process
254 254  
255 -== //3.4 Reference Metadata// ==
246 +== 3.4 Reference Metadata ==
256 256  
257 257  Reference metadata has been substantially re-designed for version 3.0 to simplify the model and better support practical use cases.
258 258  
... ... @@ -281,83 +281,45 @@
281 281  * SOURCE_AGENCY – a multi-value data attribute
282 282  
283 283  <Obs xsi:type="dsd:ObsType" OBS_VALUE="112" OBS_STAUS=”A” TIME_PERIOD="2010-09">
284 -
285 285  <!—- complex multi-value and multi-lingual data attributes ~-~->
286 -
287 287  <Comp id="TITLE" xsi:type="ns1:TITLE_ATTRIBUTE">
288 -
289 289  <Value>
290 -
291 291  <common:Text xml:lang="en">Some English Text</common:Text>
292 -
293 293  <common:Text xml:lang="fr">Quelques textes en anglais</common:Text>
294 -
295 295  </Value>
296 -
297 297  </Comp>
298 298  
299 299  <Comp id="SOURCE_AGENCY" xsi:type="ns1:SOURCE_AGENCY_ATTRIBUTE">
300 -
301 301  <Value>4F0</Value>
302 -
303 303  <Value>4D0</Value>
304 -
305 305  <Value>CZ2</Value>
306 -
307 307  </Comp>
308 -
309 309  <!—- metadata attributes are reported like in metadata messages ~-~->
310 -
311 311  <Metadata>
312 -
313 313  <Attribute id="COLLECTION">
314 -
315 315  <Attribute id="METHOD">
316 -
317 317  <Text lang="en">AAA</Text>
318 -
319 319  </Attribute>
320 -
321 321  </Attribute>
322 -
323 323  <Attribute id="CONTACT">
324 -
325 325  <Value>CONTACT 1</Value>
326 -
327 327  <Attribute id="NAME">
328 -
329 329  <Value>Contact 1 Name 1</Value>
330 -
331 331  </Attribute>
332 -
333 333  <Attribute id="NAME">
334 -
335 335  <Value>Contact 1 Name 2</Value>
336 -
337 337  </Attribute>
338 -
339 339  </Attribute>
340 -
341 341  <Attribute id="CONTACT">
342 -
343 343  <Value>CONTACT 2</Value>
344 -
345 345  <Attribute id="NAME">
346 -
347 347  <Value>Contact 2 Name 1</Value>
348 -
349 349  </Attribute>
350 -
351 351  <Attribute id="NAME">
352 -
353 353  <Value>Contact 2 Name 2</Value>
354 -
355 355  </Attribute>
356 -
357 357  </Attribute>
358 -
359 359  </Metadata>
360 -
361 361  </Obs>
362 362  
363 363  === New - Metadata Provision Agreement ===
... ... @@ -372,7 +372,7 @@
372 372  
373 373  A Metadataset now has mandatory identification information, (owner id, id, version) enabling metadata providers to uniquely identify their reports for create, update or delete maintenance operations.
374 374  
375 -== //3.5 Microdata Exchange// ==
328 +== 3.5 Microdata Exchange ==
376 376  
377 377  Several changes have been made the Data Structure Definition to support microdata use cases in addition to aggregated time series.
378 378  
... ... @@ -430,7 +430,7 @@
430 430  
431 431  That allows ValueItems (the equivalent to Code) to contain symbols like ‘¥’ and ‘€’, but 208 also means they are not identifiable.
432 432  
433 -== //3.6 Geospatial Data Exchange// ==
386 +== 3.6 Geospatial Data Exchange ==
434 434  
435 435  The version 3.0 model has been extended to provide explicit support for geospatial data.
436 436  
... ... @@ -445,7 +445,7 @@
445 445  * GeographicCodelist – each item includes an element to represent a specific Geo Feature Set which is described using the same expression syntax as for GeospatialInformation type.
446 446  * GeoGridCodelist – A code list defining a geographical grid composed of cells representing regular squared portions of the Earth. Each item references a cell within the grid.
447 447  
448 -=== //3.7 Structure Mapping// ===
401 +=== 3.7 Structure Mapping ===
449 449  
450 450  The Structure Set in version 2.1 is a container for many mapping structures including Data Structure Map, Codelist Map and Concept Map. For version 3.0 the Structure Set artefact has been deprecated and replaced with a number of new maintainables giving better flexibility and reusability, specifically: Structure Map, Concept Scheme Map, Representation Map, Reporting Taxonomy Map, Category Scheme Map and Organisation Scheme Map.
451 451  
... ... @@ -477,7 +477,7 @@
477 477  
478 478  Item maps may further define the period for which the mapping is valid, meaning the mapping rule will only be applied if the row of information being mapped is within the period.
479 479  
480 -=== //3.8 Constraints// ===
433 +=== 3.8 Constraints ===
481 481  
482 482  Constraints in version 3.0 are modelled using two separate artefacts which replace the version 2.1 content constraint:
483 483  
... ... @@ -492,17 +492,17 @@
492 492  
493 493  Attachment constraints have been deprecated due to a lack of use cases.
494 494  
495 -=== //3.9 Code List Extension// ===
448 +=== 3.9 Code List Extension ===
496 496  
497 497  In addition to the two new specialised geospatial forms, the option has been added to define a code list as an extension of, or by inheriting codes from, other lists. An optional prefix can be added to inherited codes to disambiguate duplicates.
498 498  
499 499  This feature allows new code lists to be easily derived from existing lists without the need to make and manually maintain copies. When querying for extended code list structures using the REST API, the option has been added to retrieve either the definition or the materialised list. Traditional literal lists of codes continue to be supported.
500 500  
501 -=== //3.10 Discriminated Union of Code Lists// ===
454 +=== 3.10 Discriminated Union of Code Lists ===
502 502  
503 503  Combining code list extension with wildcarded constraints solves the discriminated union of code lists problem where a classification or breakdown has multiple “variants” which are all valid but mutually exclusive. A common example is economic activity where several alternative classification schemes are in use including ISIC revisions 1 to 4 and NACE as used in the European Community.
504 504  
505 -=== //3.11 Code Hierarchies// ===
458 +=== 3.11 Code Hierarchies ===
506 506  
507 507  Code hierarchies allow the definition of complex hierarchies of codes from potentially multiple lists for data discovery purposes. Hierarchical Codelist has been deprecated and replaced by two new artefacts: Hierarchy – the actual hierarchy of codes, and Hierarchy Association links hierarchies directly to any other identifiable object, a capability missing 312 from the version 2.1 model. Further, the linkage can be within a particular context, for instance linking a hierarchy to a dimension within the context of a specific Dataflow (dimension REF_AREA in the context of the ECB:EXR Dataflow).
508 508  
SUZ.Methodology.Code.MethodologyClass[0]