16 Annex 6: Worked Use Case
16.1 Scope
The scope of this Chapter is to show the SDMX-ML interactions with the Registry, database, and metadata repository for the use case scenario outlined in Chapter 3. The scenario is repeated below.
The SDMX-ML examples used are version 2.1.
16.2 Scenario
This scenario is the dissemination of data and related reference metadata using SDMX web services. It shows how the data, reference metadata, and structural metadata are used to build a web dissemination system.
Figure 47: Process flow of an SDMX Web Data Dissemination System
Process Description 1 Retrieve the DSD from a structural metadata source (e.g. an SDMX Registry), and create database tables. 2 Read an SDMX data set file and load the data into the database 3 Data discovery system continually synchronises its metadata with the structural metadata source. A user makes a data selection from choices built from the information held in an SDMX Registry (structural metadata such as category scheme, dataflow, DSD, data provider, provision agreements and data registration) 3 These choices are logical choices, built from the dimension selections. 5 The logical choice is formatted as an SDMX data query. This is passed to the Data Base which responds with an SDMX data set. 6 Reference metadata relevant to the data returned is retrieved from a metadata repository. 7 The data and metadata are passed to a visualization tool to display the data in tables, charts, graphs, maps etc. Often a download is offered in various formats. The download options often include also the DSD or MSD. 16.3 Structural Metadata
16.3.1 Schematic
The following structural metadata and provisioning metadata is used in the scenario.
Figure 48: Structural and Provisioning Metadata Used in the Scenario
16.3.2 Data Structure Definition
For the reasons of clarity a sub set of the contents of the Code Lists and Concept Schemes are used in this example, and only a few of the DSD Attributes are used.
Dimensions
Attributes
Group
Primary Measure
16.4 Scenario Steps
16.4.1 Create Data Base
Figure 49: User Case - Create Database Tables from DSD
The following SDMX-ML is extracted from the Registry using the REST query
http://[ ws-entry-point]/DataStructure_ECB/ECB_EXR1Dimensions
Note that for brevity only the XML of the FREQ and TIME_PERIOD are shown in full.
Notes
- A Dimension can state its position in the key, but the actual sequence is defined by the sequence in the i.e. the inferred sequence in the takes precedence over the value of the position attribute.
- This DSD is converted from version 2.0. The version 2.0 Concepts were standalone in the form <Concept agencyID=”ECB” version=”1.0”/>
- The standalone concept is not supported in 2.1 and any standalone concept is placed in a Concept Scheme with the Id “STANDALONE_CONCEPT_SCHEME” of the version corresponding to the version of the original standalone concept.
Group
Notes:
- A Group in version 2.1 plays the same role as it does in version 2.0 except that it does not group Series in the data set. The Group in version 2.1 is used solely as a mechanism to attach Attributes in the data set.
- The Group in version 2.1 is retained for compatibility with version 2.0 and for avoiding repetition in the new Attribute Relationship construct which is introduced in version 2.1.
Attributes
Note that for brevity only the XML of the DECIMALS (relationship to a group) COLLECTION (relationship to a set of Dimensions) and OBS_CONF (relationship to the Primary Measure) are shown in full.
Notes
- The Attribute has a relationship to either a data set of one or more Dimensions as described in Chapter 4.
- DECIMALS has a relationship to a Group with the Id of Group.
- COLLECTION has a relationship to a set of Dimensions – in this case this is, in reality, the series key as this has been converted from version 2.0. It is possible for an attribute to have a relationship with just one, a few, or all of the Dimensions.
- OBS_CONF has a relationship with the Primary Measure.
Measure
A typical database schema that can be set up using this DSD is shown below.
Series Key Table
Figure 50: Relational Table Structure created from a DSD Dimensions and Related Attributes
Group “Group” Table
Figure 51: Relational Table Structure created from a DSD Group and Related Attributes
Observation
Figure 52: Relational Table Structure created from a DSD Primary Measure and Related Attributes
16.4.2 Load Database
Figure 53: Loading an SDMX Dataset into a Database
The following is an extract from the SDMX dataset.
Note that this is a sub set of the actual data message.
Notes
- The reference to the DSD is given in the message header and given a local structureId
- The local structureId (DSD) is referenced from the DataSet
- A Group does not contain Series in version 2.1: it is used solely to declare attributes
- The first in the first has an OBS_VALUE of “NaN”. This is an XML expression that declared a value of “not a number”, thus allowing a “missing value” to be declared.
- A dataset can contain observations from different frequencies.
The diagrams below show the database content based on the schema created.
Series Key Table
Group Table
Observation Table
The database is now available for query.
16.4.3 Register Data Source
The following registration is submitted to the Registry.
The SDMX web service of the database can now be searched for in the Registry.
16.4.4 Retrieve and Visualise Category Scheme and Dataflows
Figure 54: Building a Search Screen from Structural Metadata
The following REST query will return the Category Scheme and Categorisations that reference any of the Categories in the scheme.
http:// [ws-entry-point]/categoryscheme/ECB/SDW_ECONOMIC_CONCEPTS/1.0?references=parents
The application will now retrieve the Dataflows in the list of Categorisations – in this case there is only one – effective exchange rates.
The following REST query will return the dataflow.
http:// [ws-entry-point]/dataflow/ECB/2034482/1.0
The actual choreography of the query application is dependent upon the implementation but the following is assumed for this example.
- Query application queries the Registry for the Provision Agreement.
- Query application queries the Registry for data Registrations.
- If there is a data source registered then the dataflow is displayed and can be selected.
The following REST query will return any provision agreements referenced from the dataflow
http://[ws-entry-point]/dataflow/ECB/2034482/1.0?references=provisionagreement
Notes
1. The contains the same identification information as the individual attributes in the tag in the context of the <Dataflow> and tags (the <Dataflow> identifies that the is a DataStructure).
The following REST query will return the Data Provider Scheme that contains the Data Provider connected to the Provision Agreement. Note that this is not necessary in order to query for the data unless the Data Provider contains information required by the query application (such as the name of the Data Provider).
http://[ws-entry-point]/dataprovider/ECB
Notes
1.
As an Agency can have only one Data Provider Scheme and this has a mandatory Id of DATA_PROVIDER_SCHEME and must be version 1.0 there is no need to specify any other parameters to the REST query.
This returns the following as part of the Data Provider Scheme.
The following Registry query will return the REST data source referenced in a Registration for the Provision Agreement
The response from this query is:
The query application now has the details of the web service to call when making a query, and it also knows that the query expected uses the REST interface.
http://[ws-entry-point] /[RESTParameters]]
Where [ws-entry-point] is the URL of the SDMX web service and [RESTParameters] are the query parameters.
The application can now visualize the information it has retrieved from the Registry in a way that is meaningful to the user. An example visualization is shown below.
Figure 55: Example Query Screen Built from SDMX Category Scheme and Dataflows
The user will select the Category and this then shows the Dataflows that are available and which have data available for query (i.e. there is a Registration). There can be many such Dataflows but in this example there is only one.
16.4.5 Build Dimension Selection and Logical Query
Clicking on the Dataflow will cause the query application to query the Registry for the DSD associated to the Dataflow. The Dimensions and the relevant codes associated with the Dimensions are then shown for detailed data selections.
Figure 56: Selection Screen build from SDMX DSD
The user can click on each of the Dimensions and the relevant code selections are displayed. Note that in the example above the application is assumed to have queries for all the keys so that it can process them in order to grey-out the Dimension selections for which there is no data. These are greyed-out based on the current selections in the other Dimensions. This shows the importance of content constraints in a web dissemination system, as they can be used to guide the user to make only the selections that will return data. The same result can be achieved if these constraints are available for query (e.g. in a Registry), but this is a less effective way of processing if the contenrts of the database are dynamic.
16.4.6 Query Database
The logical query of the user is converted to an SDMX query and sent to the Data Web Service of the data publisher. The Data Web Service may also query the Metadata Repository in order to return both data and related metadata to the user application. The Data Web Service may also require structural metadata (DSD and MSD and related Code Lists and Concepts) from the structural metadata repository, in this example this an SDMX Registry.
Data Query Logical Selections
Dimension Values FREQ M CURRENCY Z26,Z28 CURRENCY_DENOM EUR,CZK,DKK EXR-TYPE DFCO,EN00 EXR_SUFFIX A Time Jan 2008-Dec 2010 REST Query
16.4.7 Visualise the Resultant Data Set
The returned data and metadata can be presented to the user in many ways – tables, graphs, charts, maps etc. SDMX does not support visualization directly but it is possible to define roles for a Dimension and Attribute in the DSD. For instance, it is possible to assign a role of “Geography” or “Title” or “Measure Unit” etc. which will aid a data visualization service to present this information in a meaningful way to the user.
Figure 57: Example Graph Built from Data Returned from a Query