Changes for page SDMX 3.0 Standards. Section 1. Framework for SDMX technical standards

Last modified by Helena on 2025/09/10 11:19

From 4.5 to 4.4 From 4.10 to 4.9

From version 4.9

edited by Helena
on 2025/05/14 15:27

Change comment: There is no comment for this version

To version 4.5

edited by Helena
on 2025/05/14 15:25

Change comment: There is no comment for this version

Raw
Rendered

Summary

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

Details

Page properties

Content

@@ -64,9 +64,10 @@
  == 2.1 Major Changes from 1.0 to 2.0 ==
  * **Reference Metadata**: In addition to describing and specifying data structures and formats (along with related structural metadata), the version 2.0 specification also provides for the exchange of metadata which is distinct from the structural metadata in the 1.0 version. This category includes “reference” metadata (regarding data quality, methodology, and similar types – it can be configured by the user to include whatever concepts require reporting); metadata related to data provisioning (release calendar information, description of the data and metadata provided, etc.); and metadata relevant to the exchange of categorization schemes.
--* **SDMX Registry**: Provision is made in the 2.0 standard for standard communication with registry services, to support a data-sharing model of statistical exchange. These services include registration of data and metadata, querying of registered data and metadata, and subscription.
--* **Structural Metadata**: The support for exchange of statistical data and related structural metadata has been expanded. Some support is provided for qualitative data; data cube structures are described; hierarchical code lists are supported; relationships between data structures can be expressed, providing support for extensibility of data structures; 101 and the description of functional dependencies within cubes are supported.
++* **SDMX Registry**: Provision is made in the 2.0 standard for standard communication with registry services, to support a data-sharing model of statistical exchange. These services include registration of data and metadata, querying of registered data and metadata, and subscription/notification.
++• **Structural Metadata**: The support for exchange of statistical data and related structural metadata has been expanded. Some support is provided for qualitative data; data cube structures are described; hierarchical code lists are supported; relationships between data structures can be expressed, providing support for extensibility of data structures; 101 and the description of functional dependencies within cubes are supported.
++
  == 2.2 Major Changes from 2.0 to 2.1 ==
  * **Simplification of the data structure definition - specific message types:** Both time series (version 2.0 Compact) and non-time series data sets (version 2.0 Cross Sectional) use the same underlying structure for a structure-specific formatted message, which is specific to the Data Structure Definition of the data set.
@@ -97,7 +97,7 @@
  ===== Versioning of Structural Metadata Artefacts =====
--* Adoption of the three-number semantic versioning standard for structural metadata artefacts (__[[https:~~/~~/semver.org>>url:https://semver.org/]])__
++• Adoption of the three-number semantic versioning standard for structural metadata artefacts [[(>>url:https://semver.org/]] __[[https:~~/~~/semver.org>>url:https://semver.org/]] __[[)>>url:https://semver.org/]]
  ===== REST Web Services Application Programming Interface (API) =====
@@ -108,7 +108,7 @@
  ===== SOAP Web Services API =====
--* The SOAP web services API has been deprecated with version 3.0 standardising on REST
++• The SOAP web services API has been deprecated with version 3.0 standardising on REST**&nbsp;**
  ===== XML, JSON, CSV and EDI Transmission formats =====
@@ -132,9 +132,9 @@
  The SDMX 3.0 Major Changes document provides more information including an analysis of the breaking changes.
--= 3 Processes and Business Scope =
++= {{id name="_Toc56231"/}}3 Processes and Business Scope =
--== 3.1 Process Patterns ==
++== {{id name="_Toc56232"/}}3.1 Process Patterns ==
  SDMX identifies three basic process patterns regarding the exchange of statistical data and metadata. These can be described as follows:
@@ -154,7 +154,7 @@
  It is important to note that SDMX is primarily focused on the //exchange// and //dissemination// of statistical data and metadata. There may also be many uses for the standard model and formats specified here in the context of internal processing of data that are not concerned with the exchange between organizations and users, however. It is felt that a clear, standard formatting of data and metadata for the purposes of exchange and dissemination can also facilitate internal processing by organizations and users, but this is not the focus of the specification.
--== 3.2 SDMX and Process Automation ==
++== {{id name="_Toc56233"/}}3.2 SDMX and Process Automation ==
  Statistical data and metadata exchanges employ many different automated processes, but some are of more general interest than others. There are some common information technologies that are nearly ubiquitous within information systems today. SDMX aims to provide standards that are most useful for these automated processes and technologies.
@@ -170,7 +170,7 @@
  The SDMX standards specified here are designed to support the requirements of all of these automation processes and technologies.
--== 3.3 Statistical Data and Metadata ==
++== {{id name="_Toc56234"/}}3.3 Statistical Data and Metadata ==
  To avoid confusion about which "data" and "metadata" are the intended content of the SDMX formats specified here, a statement of scope is offered. Statistical "data" are sets of often numeric observations which typically have time associated with them. They are associated with a set of metadata values, representing specific concepts, which act as identifiers and descriptors of the data. These metadata values and concepts can be understood as the named dimensions of a multi-dimensional co-ordinate system, describing what is often called a "cube" of data.
@@ -190,9 +190,9 @@
  [[image:SDMX 3-0-0 SECTION 1 FINAL-1.0_en_a3e7967f.png||height="921" width="629"]]
--Figure 1: High Level Schematic of Major Artefacts in the SDMX 3.0 Information Model
++**Figure 1: High Level Schematic of Major Artefacts in the SDMX 3.0 Information Model**
--== 3.4 The SDMX View of Statistical Exchange ==
++== {{id name="_Toc56235"/}}3.4 The SDMX View of Statistical Exchange ==
  Version 1.0 of ISO/TS 17369 SDMX covered statistical data sets and the metadata related to the structure of these data sets. This scope was useful in supporting the different models of statistical exchange (bilateral exchange, gateway exchange, and data-sharing) but was not by itself sufficient to support them completely. Versions 2.0 and 2.1 provide a much more complete view of statistical exchange, so that an open data-sharing model can be fully supported, and other models of exchange can be more completely automated. In order to produce technical standards that will support this increased scope, the SDMX Information Model provides a broader set of formal objects which describe the actors, processes, and resources within statistical exchanges.
@@ -226,16 +226,23 @@
  * //**Provision Agreement (Metadata Provision Agreement):**// The set of information which describes the way in which data sets and metadata sets are provided by a data/metadata provider. A provision agreement can be constrained in much the same way as a data or metadata flow definition. Thus, a data provider can express the fact that it provides a particular data flow covering a specific set of countries and topics, Importantly, the actual source of registered data or metadata is attached to the provision agreement (in terms of a URL). The term “agreement” is used because this information can be understood as the basis of a “service-level agreement”. In SDMX, however, this is informational metadata to support the technical systems, as opposed to any sort of contractual information (which is outside the scope of a technical specification). In version 3.0, metadata provision agreement and data provision agreement are two separate artefacts.
  * //**Constraint:**// Data and Metadata Constraints describe a subset of a data source or metadata source, and may also provide information about scheduled releases of data. They are associated with data / metadata providers, provision agreements, data flows, metadataflows, data structure definitions and metadata structure definitions.
  * //**Structure Map: **//Structure maps describes a mapping between data structure definitions or dataflows for the purpose of transforming a data set into a different structure. The mapping rules are defined using one or more component maps which each map in turn describes how one or more components from the source data 534 structure definition map to one or more components in that of the target. Represent maps act as lookup tables and specific provision is made for mapping dates and times.
--* //**Representation Map:**// Representation maps describe mappings between source value(s) and target value(s) where the values are restricted to those in a code list, value list or be of a certain type such as integer or string.
--* //**Item Scheme Map:**// An item scheme map describes mapping rules between any item scheme with the exception of code lists and value lists which use representation maps. The version 3.0 information model provides four item scheme maps: organisation scheme map, concept scheme map, category scheme map and reporting taxonomy map. Organisation scheme map and reporting scheme map have been omitted from the information model schematic in Figure 1.
--* //**Reporting Taxonomy: **//A reporting taxonomy allows an organisation to link (possibly in a hierarchical way) a number of cube or data flow definitions which together form a complete “report” of data or metadata. This supports primary reporting which often comprises multiple cubes of heterogeneous data, but may also support other collection and reporting functions. It also supports the specification of publications such as a yearbook, in terms of the data or metadata contained in the publication.
--* //**Process:**// The process class provides a way to model statistical processes as a set of interconnected //process steps.// Although not central to the exchange and dissemination of statistical data and metadata, having a shared description of processing allows for the interoperable exchange and dissemination of reference 556 metadata sets which describe processes-related concepts.
--* //**Hierarchy**//: Describes complex code hierarchies principally for data discovery purposes. The codes themselves are referenced from the code lists in which they are maintained.
--* //**Hierarchy Association**//: A hierarchy association links a hierarchy to something that needs it like a dimension. Furthermore, the linking can be specified in the context of another object such as a dimension in the context of a dataflow. Thus, a dimension in a data structure definition could have different hierarchies depending on the dataflow.
--* //**Transformation Scheme:**// A transformation scheme is a set of Validation and Transformation Language (VTL) transformations aimed at obtaining some meaningful results for the user (e.g., the validation of one or more data sets). The set of transformations is meant to be executed together (in the same run) and may contain any number of transformations in order to produce any number of results. Thus, a transformation scheme can be considered as a VTL ‘program’.
--== 3.5 SDMX Registry Services ==
++• //**Representation Map:**// Representation maps describe mappings between source value(s) and target value(s) where the values are restricted to those in a code list, value list or be of a certain type such as integer or string.
++• //**Item Scheme Map:**// An item scheme map describes mapping rules between any item scheme with the exception of code lists and value lists which use representation maps. The version 3.0 information model provides four item scheme maps: organisation scheme map, concept scheme map, category scheme map and reporting taxonomy map. Organisation scheme map and reporting scheme map have been omitted from the information model schematic in Figure 1.
++
++• //**Reporting Taxonomy: **//A reporting taxonomy allows an organisation to link (possibly in a hierarchical way) a number of cube or data flow definitions which together form a complete “report” of data or metadata. This supports primary reporting which often comprises multiple cubes of heterogeneous data, but may also support other collection and reporting functions. It also supports the specification of publications such as a yearbook, in terms of the data or metadata contained in the publication.
++
++• //**Process:**// The process class provides a way to model statistical processes as a set of interconnected //process steps.// Although not central to the exchange and dissemination of statistical data and metadata, having a shared description of processing allows for the interoperable exchange and dissemination of reference 556 metadata sets which describe processes-related concepts.
++
++• //**Hierarchy**//: Describes complex code hierarchies principally for data discovery purposes. The codes themselves are referenced from the code lists in which they are maintained.
++
++• //**Hierarchy Association**//: A hierarchy association links a hierarchy to something that needs it like a dimension. Furthermore, the linking can be specified in the context of another object such as a dimension in the context of a dataflow. Thus, a dimension in a data structure definition could have different hierarchies depending on the dataflow.
++
++• //**Transformation Scheme:**// A transformation scheme is a set of Validation and Transformation Language (VTL) transformations aimed at obtaining some meaningful results for the user (e.g., the validation of one or more data sets). The set of transformations is meant to be executed together (in the same run) and may contain any number of transformations in order to produce any number of results. Thus, a transformation scheme can be considered as a VTL ‘program’.
++
++== {{id name="_Toc56236"/}}3.5 SDMX Registry Services ==
++
  In order to provide visibility into the large amount of data and metadata which exists within the SDMX model of statistical exchange, it is felt that an architecture based on a set of registry services is potentially useful. A “registry” – as understood in webservices terminology – is an application which maintains and stores metadata for querying, and which can be used by any other application in the network with sufficient access privileges (though note that the mechanism of access control is outside of the scope of the SDMX standard). It can be understood as the index of a distributed database or metadata repository which is made up of all the data provider’s data sets and reference metadata sets within a statistical community, located across the Internet or similar network.
  Note that the SDMX registry services are not concerned with the storage of data or reference metadata. The assumption is that data and reference metadata lives on the sites of its data and metadata providers. The SDMX registry services concern themselves with providing visibility of the data and reference metadata, and information needed to access the data and reference metadata. Thus, a registered data set will have its URL available in the registry, but not the data itself. An application which wishes to access that data would query the registry, perhaps by drilling down via a Category Scheme and Dataflow, for the URL of a registered data source, and then retrieve the data directly from the data provider (using an SDMX REST API query message or other mechanism).
@@ -249,7 +249,7 @@
  * //**Querying: **//The registry services have interfaces for querying the metadata contained in a registry, so that applications and users can discover the existence of data sets and reference metadata sets, structural metadata, the providers/agencies associated with those objects, and the provider agreements which describe how the data and metadata are made available, and how they are categorized.
  * //**Subscription/Notification:**// It is possible to “subscribe” to specific objects in a registry, so that a notification will be sent to all subscribers whenever the registry objects are updated.
--== 3.6 RESTful Web services ==
++== {{id name="_Toc56237"/}}3.6 RESTful Web services ==
  Web services allow computer applications to exchange data directly over the Internet, essentially allowing modular or distributed computing in a more flexible fashion than ever before. In order to allow web services to function, however, many standards are required: for requesting and supplying data; for expressing the enveloping data which is used to package exchanged data; for describing web services to one another, to allow for easy integration into applications that use other web services as data resources.
@@ -263,7 +263,7 @@
  The following conceptual example uses the ‘data’ resource to query a data repository for a series identified by the key ‘M.USD.EUR.SP00.A’ in the EXR (ECB exchange rates) Dataflow: https:~/~/ws-entry-point/data/dataflow/ECB/EXR/1.0.0/M.USD.EUR.SP00.A
--= 4 The SDMX Information Model =
++= {{id name="_Toc56238"/}}4 The SDMX Information Model =
  SDMX provides a way of modelling statistical data, and defines the set of metadata constructs used for this purpose. Because SDMX specifies a number of transmission formats for expressing data and structural metadata, the model is used as a mechanism for guaranteeing that transformation between the different formats is lossless. In this sense, all of the formats are syntax-bound expressions of the common information model.
@@ -281,9 +281,9 @@
  A full UML conceptual design of the information model is set out in Section 2 of the Technical Specifications.
--= 5 The SDMX Transmission Formats =
++= {{id name="_Toc56239"/}}5 The SDMX Transmission Formats =
--== 5.1 SDMX-ML ==
++== {{id name="_Toc56240"/}}5.1 SDMX-ML ==
  SDMX-ML is the XML transmission format specification for exchanging structural metadata, data and reference metadata, and interacting with SDMX registry services. It is designed as a general-purpose format for all automation and data / metadata exchange tasks, and provides the most complete coverage.