Sdmx-EDI and Sdmx-ML

Editor's Notes

• #27: <pagebreak> This diagram depicts one of the most important SDMX Artefacts, the Data Structure Definition (aka Key Family). NOTE: The three classes (DataSet, DataflowDefintion, Category) above the DSD class are not part of the Data Structure Definition, but are included in this diagram in order to show how the DSD is used by Dataflows that define DataSets and are linked to Categories within a Category Scheme. Three conceptual levels can be identified within the DSD diagram. The first level is the Structure level where the DSD is identified (id, version and other attributes not shown in this diagram). The second level comprises ComponentLists. These are conceptual groupings of components (i.e. Key, Groups). The third level includes the Components used by the DSD in order to define the structure of DataSet(s). Moreover, Components reference Concepts residing in ConceptSchemes and may have specific Roles within the DSD. Finally, a Dimension may be a MeasureType dimension, thus defining a Cross-Sectional Measure (XSMeasure class) for every Code included in the Codelist related to this Dimension.
• #40: <pagebreak> The SDMX standard specifies a single Information Model in order to describe what and how data and metadata can be exchanged in the context of SDMX. Based on this Information Model, SDMX defines two ways of representing its messages. Two different formats are available for expressing SDMX messages. The first format is SDMX-EDI and is equivalent to GESMES/TS. This format is based on an EDIFACT syntax and is Time-Series oriented. This means that only one type of observation throughout time can be carried in a single DataSet. Moreover, the DataSet messages have only one format. This format covers a subset of the SDMX-IM. For example, non time-series messages or reference metadata messages are not supported. The second format is SDMX-ML. It is an XML format that covers the whole SDMX-IM. The SDMX-ML format supports four different (although equivalent) formats, for data messages, in order to serve different purposes. It also supports reference metadata messages as well as messages for querying SDMX Web Services and Registry Interface messages. Two simple “rules” in order to go from the SDMX-IM to the SDMX-ML implementation are that: (concrete) classes become XML elements and their attributes become XML attributes. Of course, there are exceptions in these “rules”. In the SDMX-ML implementation there are XML elements that do not correspond directly to classes from the SDMX-IM and vice versa.
• #48: <pagebreak> The Cross-Sectional format is the only one capable of expressing non-time series DSDs. In case a TimeDimension is defined in the DSD, the Cross-Sectional measure is equivalent to the rest of the formats. In the namespace declarations of this message, a DSD specific XSD should be included in order to enable syntactical validation of the message. This XSD file can be downloaded from Eurostat’s SDMX Registry (https://webgate.ec.europa.eu/sdmxregistry). The layout of the Cross-Sectional type adopts the nesting used in the Generic format but expressing SDMX Artefacts like the Compact format. A major difference in this format is that the elements have different semantic than the previous formats. Although four levels are also defined in this format, only the <DataSet> element is used in the same way. The <Group> element is independent of the Groups included in the DSD. The <Section> element is different from the <Series> element in the sense that it does not include a time-series but a vertical slice across a time-series. Finally, the observation values are now included in DSD specific elements that correspond to the CrossSectionalMeasures defined in the DSD. The SDMX Dimensions and Attributes can be attached at any of the four aforementioned levels as defined in the DSD. Moreover, in the DSD more than one possible levels can be defined per SDMX Component. Of course, only one instance of each SDMX Component should exist in each combination of the four “level” elements. Apart from the capability of reporting data without Time, the Cross-Sectional format is also a useful message for reporting more than one measures at a single DataSet. Thus, in some cases the produced file is even smaller in size than the equivalent Compact message.
• #51: <pagebreak> The SDMX standard, in its 5 th document of specifications (http://www.sdmx.org/docs/2_0/SDMX_2_0%20SECTION_05_RegistrySpecification.pdf), gives details on the interfaces that an SDMX compliant Registry should implement. Based on these specifications, Eurostat’s SDMX Registry has been developed and is now deployed in the European Commission’s production environment ( https://webgate.ec.europa.eu/sdmxregistry/ ). Eurostat’s SDMX Registry has been developed in order to be used a central repository for: Structural metadata: Code Lists, Concept Schemes, Data Structure Definitions, Metadata Structure Definitions, Category Schemes, Organisation Schemes, Hierarchical Code Lists Provisioning metadata: Data flows, Metadata flows, Provision Agreements The major interface of Eurostat’s SDMX Registry is a Web Service implementing the SDMX Registry Interface messages. These are SDMX-ML messages and are specified within the standard and by the following XSD: http://www.sdmx.org/docs/2_0/SDMXRegistry.xsd A Graphical User Interface (GUI) has been also implemented in order to enable human interaction of the World Wide Web. The user-authentication is realized using CIRCA accounts. A standalone tool implementing almost all functionality of the SDMX registry is the DSW (already presented).