SDMX Users Forum

Please login or register.

Login with username, password and session length
Advanced search  


Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Xavier Sosnovsky - ECB

Pages: [1]
Updated (draft) versions of the SDMX user guide and of the SDMX web service guidelines have been released on the SDMX web site.

Comments are welcome and can be sent to the SDMX Secretariat. The final version – edited and approved by SDMX – will also be posted on the website.

Apologies for my late reply.

In summary:
  • All the dimensions have the same importance when fulfilling their purpose of identifying a piece of statistical data. It does not matter in your case, but I think it's nevertheless worth mentioning  :)
  • If, for whatever reason, you need to identify the role played by a particular dimension, you could have a look at concept roles. Again, it does not really apply in your case, but it's good to mention for the sake of completeness.
  • There is also the way mentioned by Stratos in his previous post.
  • There are additional means of expressing this semantic, such as using the description or annotation fields of the artefacts you maintain, or use attributes, metadata reports, etc. As you see, you have many options to choose from  :)

Let's take an example, just to make sure I understood what you mean. Let's assume the following fictional DSD about inflation:
- Dimension 1 = FREQUENCY
- Dimension 2 = REF_AREA
- Dimension 3 = ICP_ITEM (the inflation component, eg: food, transport, etc)
- Dimension 4 = ICP_SUFFIX (the series variation, e.g.: annual rate of change, index, etc).
- Dimension 5 = TIME_PERIOD

Let's assume the following values: M (monthy), DE (Germany), 010000 (Food and non-alcoholic beverages), INX (index), 2011-01

The (fictional) value 1.6 in this case would represent the measure of the phenomenon identified by the combination of the 5 dimension values mentioned previousely (i.e.: M.DE.010000.INX.2011-01 = 1.6).

Did I understand correctly that, what you want is to indicate that one of these dimensions (e.g. ICP_ITEM) tells what OBS_VALUE represents? Or is it something else?

Will you opt for a time series-oriented representation of the dataset or for a cross-sectional one?

Dear John,

The ECB has developed an SDMX-based visualisation framework. The framework is used to power the visualisation tools published on the ECB website, such as the ECB inflation dashoard (

In 2008, the framework has been released as an open source project (, to which various institutions have contributed so far. Two of them, the Federal Reserve Bank of New York and Bank of Canada have now released visualisation tools on their website, that are also powered by this framework (see and

In case this is useful, please let me know whether you would need additional information.

Kind regards,

Technical Specifications / Re: SDMX codes do not allow spaces and dots
« on: January 13, 2010, 07:11:27 AM »
Ken, Pascal: Thanks for the input and clarification :).

Actually, the problem we reported a while ago was not with the id of identifiable artefacts (the ids we use for our structural metadata are compliant with the IDType syntax) but with the ID element of the message Header (comment 2 in my inital post). Is there any reason why the message ID needs to comply with the URN syntax? We find it to be too restrictive, specially in a RESTful web service scenario, where it would make a lot of sense to use the query URL as message ID...


Technical Specifications / Re: SDMX codes do not allow spaces and dots
« on: January 05, 2010, 06:42:56 AM »
The restriction on the IDType allows for the value to comply with the URN specification

Hi J,

I have two comments regarding this approach:
- Identifiable artefacts have (among others) a urn attribute. Would that not be the appropriate place for storing the URN (rather than the id attribute)? Of course, nothing should prevent someone from using a URN as the id for an artefact, but why limiting the set of valid characters for the id attribute to those allowed by the URN syntax, when there is already a urn attribute that can (should?) be used for that purpose [Edited: clarified by Ken & Pascal posts below]?
- The IDType is also used for the ID element in the message header. In a RESTful scenario, where all the parameters for a query are stored in the URL, it might be seen as a good option to use the URL for the query as the ID for the returned message (for example, if users have questions about the data they downloaded, it's very easy to see the query they performed to get the data, as this would be displayed as the message ID. This information could be very helpful for debugging purposes). However, this is not possible, as characters allowed in the URL are not allowed in the IDType. Is there any reason why the id in the message header needs to be restricted to the characters allowed in the URN syntax?

Many thanks,


Pages: [1]