SDMX, un modèle pour l’échange de données statistiques

Description de l’information statistique territoriale

3.4 SDMX, un modèle pour l’échange de données statistiques

Les langages semi-structurés ont été avancés depuis quelques années comme une solution au pro-blème de non-interopérabilité entre Systèmes d’Information Statistiques (SIS), [Meyer 04]. La raison principale est que ces langages (basés sur XML et des schémas XSD) permettent d’embarquer une des-cription du format des données dans les données. Ainsi, la flexibilité et la souplesse d’utilisation des données s’en trouveraient accrues. C’est la raison pour laquelle le Statistical Data Model eXchange (SDMX)⁸est aujourd’hui promu par l’OCDE, mais également Eurostat, ou d’autres organismes de pro-duction de données statistiques à caractère commercial (et non plus forcément territorial) comme les banques et les organismes financiers. Ainsi, le Fond Monétaire International⁹ou la Banque Centrale

Eu-8. http://sdmx.org/

ropéenne¹⁰font partie des promoteurs de ce standard. Déjà standardisé en 2005 dans sa première version 1.0 avec la norme ISO TS 17369, [ISO 05], la seconde version de SDMX présentée ici est en cours de standardisation.

En tant que successeur de GESMES (pour Generic Statistical Messages) [Kent 97], SDMX est conçu pour faciliter l’échange de données, en précisant l’identité de l’émetteur des données, le format des données envoyées, ainsi que la nature des données employées. GESMES est un standard conçu par Euro-stat, dérivé de EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport)¹¹, qui vise à spécifier le format électronique dans lequel les données statistiques et leurs métadonnées devraient être transférées et qui s’est développé dans les systèmes d’information bancaires. GESMES comme SDMX contribuent à promouvoir le développement de systèmes d’information dits «actifs», où les métadonnées sont conçues pour traiter les données automatiquement, et non pas uniquement pour que les utilisateurs comprennent les données. Par exemple, il s’agit d’être en mesure de vérifier si des données sont conformes à leurs spécifications (puisque le type des valeurs, et la fourchette de valeurs autorisées sont incluses dans les métadonnées) ou de traduire automatiquement les unités de mesure des données. En effet, entre deux systèmes d’informationSI₁ etSI₂, siSI₁ envoie les données exprimées dans l’unité u₁ (l’euro par exemple), et SI₂ veut réutiliser ces données converties dans l’unitéu₂ (le dollar par exemple), il faut que :

– SI₂sache que l’unité postée parSI₁étaitu₁(donc sache dans quel champ de métadonnées trouver cette information) ;

– SI2 reconnaisse ce que veut direu1 (si u1 est une chaine de texte au format libre, ceci n’est pas assuré).

Ceci implique de s’entendre sur un certain nombre deconcepts(ou descripteurs) contenus dans les mé-tadonnées, mais également sur la façon de renseigner chaque concept (leur représentation). Ce second point n’est pas vraiment assuré dans la norme ISO 19115 pour l’instant car les champs descriptifs sont pour la plupart textuels, et ne font pas l’objet d’harmonisation. C’est un problème d’interopérabilité sémantique [Barde 05].

Cependant, contrairement à GESMES qui est un standard pour les métadonnées à caractère essen-tiellement « logistique », SDMX présente également un caractère « documentaire » comme la norme ISO 19115. En effet, les concepts et les codes utilisés par les parties s’échangeant l’information pour décrire l’information sont eux-même échangés avec les données ou mutualisés dans des registres accessibles par tous sur le Web, avec leur description textuelle en langue naturelle.

SDMX inclut un modèle de diffusion des données qui repose sur la technologie des services Web et propose aux producteurs de données de s’enregistrer comme « Fournisseur » auprès d’un registre public, et de publier les métadonnées (les fichiers de structure (Data Structure Definition, DSD), les concepts et les listes de codes qu’ils auront définis) sur ce registre. Les utilisateurs de données (ayant un rôle de « Demandeur ») consultent ces registres (l’équivalent d’annuaires) pour récupérer l’URL d’accès au service Web d’un producteur délivrant les données souhaitées, ainsi que les modalités de formulation de la requête sur le service, voir figure 3.4. Dans ce modèle, il n’est plus nécessaire que le Fournisseur ou le Demandeur se connaissent, et la donnée est accessible en permanence, tant que le service de délivraison électronique fonctionne.

10. http://www.ecb.int/home/html/index.en.html

Fournisseur Demandeur

S'enregistre

et publie ses métadonnées

Récupère les données au format SDMX-ML Recherche Metadonnées structurelles - Concepts - Codes - DSDs Informations d'approvisionnement - Dataflows - Provison agreements Registre SDMX WEB

FIGURE3.4 – Architecture pour l’échange d’information proposée par SDMX.

Les auteurs de SDMX se sont concertés pour définir une liste de concepts¹², termes¹³, et codes¹⁴ identifiés et partagés dans un registre, en vue de faciliter l’intégration statistique. Les concepts, référen-cés par un identifiant unique peuvent être valués, soit par des codes indépendants de la langue, soit par du texte. Par exemple, le statut (OBS_STATUS) d’une valeur statistique est décrit par une liste de codes (A, B, E, F, I, M, P, S) qui signale si la valeur est normale (A), manquante (B), estimée (E), etc., et le registre définit exactement la signification de ces codes. De même, la fréquence de publication des don-nées est définie par un code (CL_FREQ) : A (Annuel), S (Semestriel), Q (Trimestriel), M (Mensuel), W (Hebdomadaire), B (semaine travaillée), D (Journalier), N (Minutes). Concernant les devises d’échange (CL_CURRENCY), ou le format des dates (TIME_FORMAT), la norme se refére aux standards ISO en vigueur : la norme ISO 4217¹⁵et la norme ISO 8601.

La liste des concepts et des codes qui leur sont associés peut également être étendue dans le fichier DSD, et être utilisée comme une dimension descriptive de l’information. Par exemple, une catégorie

TRANCHE_AGEsera définie comme un concept, avec la liste des différentes tranches d’âge codifiées, décrites chacune par un champ texte. Une observation peut y faire référence. Le fichier de données fait référence à cette description au niveau, par exemple, de la valeur observée, lorsque sont présentées les données :

3.4.1 Utilisation de SDMX

L’échange de données statistiques nécessite la définition du format des données dans un fichier ex-terne, leData Structure Definition (DSD), qui structure l’information à l’aide de ces codes et ces concepts

12. http://sdmx.org/wp-content/uploads/2009/01/01_sdmx_cog_annex_1_cdc_2009.pdf

13. http://sdmx.org/wp-content/uploads/2009/01/04_sdmx_cog_annex_4_mcv_2009.pdf

14. http://sdmx.org/wp-content/uploads/2009/01/02_sdmx_cog_annex_2_cl_2009.pdf

harmonisés¹⁶. Ce fichier sert à produire une grammaire (le schéma XSD standard) des données que le fichier de données utilise et référence. Les étapes de production de données dans le standard SDMX sont résumées dans la figure 3.5.

.DSD .XSD .XML

Structure des données

Fichier d'échange contenant les données décrites par les métadonnées Schéma du fichier d'échange

FIGURE3.5 – Etapes de production des données dans le standard SDMX.

Le format prévu pour structurer les données correspond à la hiérarchisation des informations pré-sentes dans les formats tabulaires que s’échangent les acteurs. En effet, plusieurs niveaux de description sont prévus, et les informations rattachées à un niveau inférieur spécialisent les informations décrites au niveau supérieur, la racine de cette hiérarchie étant le jeu de données.

Voici une description de ces niveaux :

1. les observations (observation) qui concernent la mesure d’un indicateur sur une unité statistique. 2. les séries (series) qui sont définies comme la mesure d’un même phénomène dans le temps, et

regroupent les observations d’un même indicateur, mais à des dates différentes ;

3. les groupes (group) dont la définition est encore un peu vague mais pourrait s’appliquer par exemple à des séries publiées à des fréquences différentes : journalières, mensuelles et annuelles¹⁷; 4. le jeu de données (dataset) qui regroupe des séries d’observations d’indicateurs liés à une certaine

thématique ;

Le modèle utilisé pour décrire les valeurs statistiques s’inspire du vocabulaire du domaine des en-trepôts de données [Rafanelli 90], comme présenté dans la section A.3.2 page 17 du préambule. Ainsi, les valeurs des indicateurs statistiques associées à des unités spatiales sont du niveau observation (ou mesure), et se rattachent à desdimensions, dont la combinaison permet d’identifier de façon unique une valeur. Les dimensions correspondent aux catégories statistiques, comme le sexe, l’âge, la classe socio-professionnelle, mais aussi l’unité statistique. Les dimensions doivent toujours êtres renseignées par des codes, en vue d’assurer l’interopérabilité sémantique, et donc l’interprétation « active » des métadonnées. Le modèle SDMX n’est pas spécifiquement conçu pour l’information statistique territoriale. Ainsi l’unité statistique peut être une entreprise comme une unité géographique ; toutefois, lorsque les unités sont géo-graphiques, SDMX préconise l’usage de nomenclatures géographiques en vigueur, telles que la norme ISO 3166 ou la NUTS pour codifier les unités. À chaque observation est attachée unAttributdont le rôle est purement descriptif, mais qui doit être associé à son concept. Un attribut peut aussi être utilisé à des niveaux supérieurs de description (comme la série, le groupe ou le jeu de données), et la grammaire doit définir son caractère obligatoire ou facultatif. Par défaut, le niveauserieshérite des dimensions décrites au niveau dugroup.

16. Selon la documentation de SDMX, la grammaire .XSD n’est pas directement exigée car le fichier .DSD est l’expression d’une grammaire considérablement allégée qui facilite le travail de conception au Fournisseur.

17. Voici ce que dit la documentation : « group of series. A well-known example is the sibling group which contains a set of series which are identical except that they are measured with different frequencies ». On peut donc comprendre que les groupes sont une option permettant de regrouper entre elles des séries d’un même indicateur, mais mesurées avec des fréquences différentes. Dans la DSD, ce niveau est facultatif.

3.4.1.1 Exemple

Nous fournissons ici un exemple complet, qui montre à la fois la souplesse de ce format et la com-plexité de sa mise en œuvre. L’exemple est issu du domaine bancaire : il vise à décrire des données sur le taux de change entre deux devises, données publiées par la Banque Centrale Européenne (ECB en anglais).

Dans un premier temps, le Fournisseur doit décrire la structure de ses données dans un fichier conte-nant la «Data Structure Definition». De façon simplifiée, la structure d’un tel fichier est la suivante :

– une entête (Header) qui rapporte des informations équivalentes à l’élément MD_Metadata de la norme ISO 19115 ;

– les concepts (Concept) utilisés pour décrire ces données ;

– l’énumération des listes de codes (Codelist) employées pour valuer les dimensions ou les attri-buts ;

– la structure des informations (KeyFamily), précisant à quel niveau chaqueDimensionouAttribut se rattache.

Nous commentons ici en détail le contenu du fichier qui est en annexe, page 267.

L’entête (Header) (3.1) permet d’identifier cette structure de données, à laquelle on attache un identi-fiant unique (ID), un nom (Name) ainsi qu’une date (Prepared). Le créateur de cette structure de données (Sender) peut être référencé dans une liste de codes pré-établis dans un des registres SDMX : il est alors identifié par son id dans cette liste.

<ID>IREF000506</ID> <Test>false</Test>

<Name>ECB structural definitions</Name> <Prepared>2006-10-25T14:26:00</Prepared> <Sender id="4F0"/>

</Header>

Listing 3.1 – Entête d’un fichier DSD.

Chaque élément Concept (3.2) définit un des concepts utilisés pour identifier et décrire des données. <Concept agencyID="ECB" id="COLLECTION">

<Name xml:lang="fr">Collection d’indicateurs</Name> <Name xml:lang="en">Indicators collection</Name> </Concept>

Listing 3.2 – Définition d’un concept.

Chaque élément CodeList (3.3) définit une liste de codes (et leur signification) qui seront utilisés pour valuer un attribut. Chaque élément CodeList contient au moins 2 attributs :

– l’ID de l’organisme (agency) responsable de cette liste de code (dans l’exemple, "ECB"), – l’ID de cette liste de code (dans l’exemple, "CL_EXR_SUFFIX").

<Name xml:lang="fr">Liste des codes associés à la variation des taux de change</Name>

<Description xml:lang="fr">Moyenne (ou mesure standardisée) sur la période</Description>

</Code>

<Description xml:lang="fr">Valeur en fin de période</ Description>

</Code> </CodeList>

Listing 3.3 – Définition d’une liste de codes.

L’élément KeyFamily (3.4) définit ensuite la hiérarchie des informations. Ses attributs sont :

– l’ID de l’organisme (agency) responsable de cette structure est obligatoire (dans l’exemple, "ECB"), – l’ID de ce jeu de données (dans l’exemple, "ECB_EXR1"),

– l’URI de l’espace de nommage de ce jeu de données (dans l’exemple, "http://www.ecb. int/vocabulary-/stats/exr/1"),

– le nom du jeu de donnée dans une langue (dans l’exemple, "Taux de change"). <KeyFamily agencyID="ECB" id="ECB_EXR1"

uri="http://www.ecb.int/vocabulary/stats/exr/1"> <Name xml:lang="fr">Taux de change</Name>

<Components> ...

</Components> </KeyFamily>

Listing 3.4 – Hiérarchisation de l’information.

Dans la balise Components sont spécifiées les informations relevant des quatre différents niveaux d’information avec d’abord la listes des dimensions utilisées pour décrire les valeurs statistiques, puis déterminer quelles dimensions sont au niveau du groupe (Group). PrimaryMeasure identifie le concept qui porte la valeur mesurée pour chaque unité, et c’est par convention le concept OBS_VALUE. Ensuite sont précisés tous les attributs par leur niveau de rattachement, leur concept, liste de code et leur caractère obligatoire ou facultatif.

<Dimension conceptRef="EXR_SUFFIX" codelist="CL_EXR_SUFFIX"/> <TimeDimension conceptRef="TIME_PERIOD"/> <Group id="Group"> <DimensionRef>CURRENCY</DimensionRef> <DimensionRef>CURRENCY_DENOM</DimensionRef> <DimensionRef>EXR_TYPE</DimensionRef> <DimensionRef>EXR_SUFFIX</DimensionRef> </Group> <PrimaryMeasure conceptRef="OBS_VALUE"/> <Attributes>

<Attribute conceptRef="DECIMALS" attachmentLevel="Group" assignmentStatus="Mandatory" codelist="CL_DECIMALS"> <AttachmentGroup>Group</AttachmentGroup>

</Attribute> </Attributes>

Listing 3.5 – Spécification des dimensions - des groupes et des attributs.

Dans ce fichier de structure, seuls les concepts ou les codes qui n’ont pas déjà été définis dans la liste des concepts standardisés proposés par SDMX sont expliqués. Par exemple, les concepts EXPR_TYPE et EXR_SUFFIX sont des concepts particuliers à ces données, non standardisés dans des registres. Pour l’exemple proposé, le tableau 3.3 décrit la structure de l’information utilisée (les concepts retenus pour chaque niveau, et leur domaine de valeur).

TABLE3.3 – Structure de l’information pour l’exemple proposé.

Niveau Concept Représentation Statut

Group CURRENCY CL_CURRENCY Dimension

CURRENCY_DENOM CL_CURRENCY Dimension

EXR_TYPE CL_EXR_TYPE Dimension

EXR_SUFFIX CL_EXR_SUFFIX Dimension

DECIMALS CL_DECIMALS Attribute

UNIT CL_UNIT Attribute

UNIT_MULT CL_UNIT_MULT Attribute

Series FREQ CL_FREQ Dimension

CURRENCY CL_CURRENCY Dimension

CURRENCY_DENOM CL_CURRENCY Dimension

EXR_TYPE CL_EXR_TYPE Dimension

EXR_SUFFIX CL_EXR_SUFFIX Dimension

TIME_FORMAT un des formats ISO 8601 Attribute

COLLECTION CL_COLLECTION Attribute

Observation TIME_PERIOD chaîne de caractères conforme à TIME_FORMAT Dimension OBS_VALUE nombre (nombre de digits définis par DECIMALS) Dimension

OBS_STATUS CL_OBS_STATUS Attribute

3.4.1.2 Fichier d’échange SDMX-ML

Le fichier DSD est ensuite transformé en schéma XML standard (dans un fichier XSD¹⁸) qui est utilisé comme grammaire du fichier de données produit. En effet, les données sont dans un fichier XML (que la documentation de SDMX définit parfois comme fichier SDMX-ML). L’exemple complet est en ligne surhttp://www.ecb.europa.eu/stats/eurofxref/eurofxref-sdmx.xml, mais nous en commentons quelques extraits dans ce qui suit.

L’entête du fichier (3.6) identifie de façon unique le document (ID), lui donne un titre ("Euro foreign exchange reference rates"), une date de publication ("2006-11-23T08:26:29"), et fournit l’auteur de cette publication ("European Central Bank"). Cette section est très semblable à la rubrique MD_Metadata de la norme ISO 19115.

<ID>EXR-HIST_2006-11-29</ID> <Test>false</Test>

<Name xml:lang="en">Euro foreign exchange reference rates</Name> <Prepared>2006-11-23T08:26:29</Prepared>

<Name xml:lang="en">European Central Bank</Name> <Contact>

<Department xml:lang="en">DG Statistics</Department> <URI>mailto:statistics@ecb.int</URI>

</Contact> </Sender> </Header>

Listing 3.6 – Entête du fichier de données.

La suite du fichier (3.7) décrit chaque niveau :dataset(Dataset) -group(Group) -series(Series) -observation(Obs).

<DataSet xmlns="http://www.ecb.int/vocabulary/stats/exr/1" xsi:schemaLocation="http://www.ecb.int/vocabulary/stats/exr/1

ecb_exr1_compact.xsd" datasetID="ECB_EXR1">

<Group CURRENCY="AUD" CURRENCY_DENOM="EUR" EXR_TYPE="SP00" EXR_SUFFIX="A" DECIMALS="4" UNIT="AUD" UNIT_MULT="0"

TITLE_COMPL="ECB reference exchange rate, Australian dollar/Euro "/>

...

<Group CURRENCY="CZK" CURRENCY_DENOM="EUR" EXR_TYPE="SP00" EXR_SUFFIX="A" DECIMALS="3" UNIT="CZK"

18. En ligne sur : https://stats.ecb.europa.eu/stats/vocabulary/exr/1/2006-09-04/ sdmx-compact.xsd

UNIT_MULT="0" TITLE_COMPL="ECB reference exchange rate, Czech koruna/Euro, 2:15 pm (C.E.T.)"/>

... </Series> </DataSet>

Listing 3.7 – Corps du fichier de données.

Le jeu de données (DataSet) référence la grammaire qu’il utilise (xsi :schemaLocation="....xsd") décrivant tous les concepts et les valeurs de codes utilisés dans ce fichier. Le premier groupe d’obser-vations concerne le taux de change entre le dollar australien (CURRENCY="AUD") et l’euro (CUR-RENCY_DENOM="EUR"), en valeur comptante (EXR_TYPE="SP00") exprimé en valeur moyenne sur la période (EXR_SUFFIX="A"), avec une précision de 4 décimales (DECIMALS="4"), et un facteur multiplicateur de 1 (UNIT_MULT="0"). Le second groupe est identique sauf que ce sont les observations pour le taux de change entre la couronne Tchèque (CURRENCY="CZK") et l’euro, et que la précision est donnée avec 3 digits (DECIMALS="3").

Les mesures sont publiées tous les jours (FREQ="D"), et datées suivant le format de la norme ISO 8601 correspondant à P1D (TIME_FORMAT="P1D"). Chaque jour, le taux de change est donc précisé avec sa date (TIME_PERIOD="1999-01-04"), sa valeur (OBS_VALUE="1.9100"), le statut de la mesure (OBS_STATUS="A") - qui est normale ici - et les contraintes de confidentialité associées à la valeur (OBS_CONF="F") - F signifie libre.

3.4.2 Les limites de SDMX

La prise en charge dans ce standard de l’aspect multi-dimensionnel de l’information statistique est donc meilleure que dans le format ISO 19115. En ce qui concerne la définition des transformations, le conceptDOC_METHOD s’utilise pour décrire les méthodes de mesure, la définition et les transfor-mations opérées sur les données, et le conceptCOMPARABILITYpour fournir un commentaire sur l’équivalence de cette donnée avec une autre. Le focus de ce standard porte sur la publication de sé-ries statistiques temporelles. De ce fait, la gestion des révisions de publication et de leur fréquence est mieux assurée que dans la norme ISO 19115 avec un code prévu au niveau de la valeur décrivant le statut de chaque valeur, mais également la fréquence de publication des valeurs ainsi que leur niveau de confidentialité.

Néanmoins, ce format ne résout pas le problème d’hétérogénéité des catégories, comme le rapporte l’expérience à grande échelle menée par [Oakley 05], membres du Bureau Australien des Statistiques (ABS), producteur officiel en Australie, dans le cadre d’un projet visant à exporter au format SDMX les

Dans le document Modèles et méthodes pour l'information spatio-temporelle évolutive (Page 103-112)