16.10.2012 SDMX

Meeting Notes: call on SDMX - Registry (Skype) Date: 16-Oct-2012 15:30 Topics: Statistical Cluster SDMX organization Participants • FAO: A. Ellenbroek , E.Van Ingen • CNR: P.Pagano, L.Fortunati Notes

• Overview:
  • SDMX specification covers registry message formats and data model. It also partially covers registry web service interfaces (SOAP and REST Structural metadata and reference data and metadata Query interface only)
  • CNR is working on the implementation of a SDMX registry with features regarding Querying and Structural Metadata Submission (Codelist) even if the specification regarding SDMX service interfaces are incomplete.
  • We'll ask M.Nelson (MetadataTechnology) to have access to version 0.9.1 (Erik) of SDMXSource in order to understand the capabilities of the registry.
  • We need to distinguish between long term goals and short term objectives. As actual SDMX specification does not describe SOAP or REST interface operations regarding registry capabilities (apart from querying) we can't be bound by specs. Therefore we'll proceed with our own custom interface for publication of SDMX data and metadata.
  • EI Now only 25% on iMarine, but wants to continue with the collaboration.
  • Adaptors (OpenSDMX) and SDMX writers (SDMXSource) are similar components, the exact implementations will be done on JAVA api’s, so there is flexibility.
• Publishing Structural Metadata and Data to a registry
  • While SDMX specification covers description of the message structures (XSDs) and sdmx data model there is no document regarding web service interface (SOAP or REST service) for Registry operations different than Querying.
  • FAO works more on dissemination, rather than ingestion, not sure of status.
  • CNR is interested on Registry Structural Metadata and Data registration, therefore has started developing a Registry which has these capabilities.
  • CNR is creating a gCube based backbone mantaining structural metadata in its registry implementation.
  • Structural Metadata and Data submission capabilities of the SDMXSource registry must be verified.
  • Once ready, provisioning agreements can be tackled.
• Development issues
  • SDMX misses a complete set of well-described web service operations in its specifications.
  • Specs have a focus on HTTP GET. Written by BoI, can be contacted.
  • CNR cannot rely on specs, since one of the main focuses it's on data registration.
  • OpenSDMX was started as a OS project. Now a new project has emerged (SDMXSource).
  • This will support version agnostic services.
• On OpenSDMX.
  • OpenSDMX low level components will likely be replaced by SDMXSource components
  • OpenSDMX will become a container of adapters
  • A migration to SDMXSource is foreseen (not yet planned)
• Next call
  • TBD

Follow-up actions

• Erik to ask for access to SDMXSource
• Erik to contact Xosnovsky(?) at the ECB
• Luigi to visit FAO on the 31th of October
• Luigi to start reading documentation and source code (if available) about SDMXSource