Guide du développeur DSPL

DSPL signifie Dataset Publishing Language. C'est un format de représentation pour les métadonnées (des informations sur l'ensemble de données, telles que nom et fournisseur, ainsi que les concepts qu'ils contiennent et affiche) et les données réelles des ensembles de données. Les ensembles de données décrits dans ce format peuvent être importées dans le dossier Google Public Data Explorer, un outil qui permet une exploration visuelle enrichie données.

Remarque:Pour importer des données dans Google Public Data à l'aide de l'outil d'importation de données publiques, vous devez disposer d'un compte Google.

Ce document s'adresse aux propriétaires de données qui souhaitent que leur contenu disponible dans Public Data Explorer. Il va au-delà du tutoriel en explorant plus en détail détails du schéma DSPL et des fonctionnalités prises en charge. Des connaissances de base de XML, bien que la connaissance des bases de données relationnelles soit également utiles.

Bien que cela ne soit pas obligatoire, nous vous suggérons de consulter le tutoriel, qui est plus court et plus facile à assimiler, avant de regarder ce document.

Présentation

Un ensemble de données DSPL est un fichier .zip qui contient un fichier XML et un ensemble de fichiers CSV . Les fichiers CSV sont de simples tables contenant les données du jeu de données, tandis que le fichier XML décrit les métadonnées du jeu de données. Cette dernière inclut métadonnées informatives telles que des descriptions de mesures, ainsi que métadonnées structurelles telles que des références entre des tables. Ces métadonnées permet aux utilisateurs non experts d'explorer et de visualiser vos données.

Processus

Le processus de création d'un ensemble de données DSPL est généralement peuvent avoir lieu en parallèle):

  1. Créez votre fichier XML DSPL.
  2. Identifiez toutes les sources de données externes à utiliser dans votre ensemble de données.
  3. Définissez vos concepts, vos segments et (éventuellement) les sujets. De manière itérative mettre à jour le contenu de votre fichier DSPL.
  4. Exportez vos données sources dans des fichiers .csv.
  5. Créez un ensemble de données DSPL.
  6. Envoyez l'ensemble de données à Google.

Structure XML

Présentation

Le fichier XML DSPL définit les métadonnées de l'ensemble de données, y compris les relations structurelles entre les concepts, les secteurs, les sujets et les tableaux. Bien qu'il soit possible de créer ce fichier à la main, les outils de traitement des données et scripts peuvent considérablement rationaliser le processus. Voir un exemple de fichier DSPL dans une nouvelle fenêtre.

Le fichier comprend un certain nombre de sections, qui sont résumées dans le tableau. ci-dessous. À la suite du tableau, nous décrivons chacun de ces principes plus en détail dans les moindres détails.

Section Résumé Plus d'infos
En-tête et importations Parent de tous les autres éléments de l'ensemble de données. Inclut les l'espace de noms cible (identifiant) de l'ensemble de données, ainsi que des ensembles de données importés. Documentation
Informations sur l'ensemble de données Nom, description et URL de l'ensemble de données. Documentation
Informations sur le fournisseur Nom, description et URL du fournisseur de l'ensemble de données. Documentation
Concepts

Définitions de "choses" qui apparaissent dans l'ensemble de données (par exemple, pays, taux de chômage, genre, etc.)

Chaque concept est associé à un identifiant unique, qui peut être référencé les segments et les tableaux.

 Documentation
Tranches

Combinaisons de concepts pour lesquelles il existe des données statistiques dans le ensemble de données. Chaque secteur contient des dimensions et métriques.

Les segments font référence à des concepts, mais aussi à des tables, qui contiennent données. Chaque tranche a un identifiant unique qui peut être référencé par le tables contenant les données réelles.

 Documentation
Tables Définissez les données pour les concepts et les secteurs. Les tableaux de concepts contiennent les énumérations et les tables de tranches contiennent des données statistiques. Les tables sont définies dans le fichier XML, et pointer vers les fichiers .csv contenant les données réelles. Documentation
Thèmes Catégories pour organiser les concepts des ensembles de données. Bien que cela ne soit pas obligatoire, ces peut être très utile pour les utilisateurs qui naviguent dans vos données. Documentation

En-tête et importations

Déclarer l'espace de noms Public Data

Un ensemble de données DSPL commence par un élément <dspl> de niveau supérieur. Il permet de délimiter toutes les informations de l'ensemble de données et d'indiquer qui seront utilisés dans le fichier. Exemple:

<?xml version="1.0" encoding="UTF-8"?>
<dspl targetNamespace="http://www.example.com/mystats"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://schemas.google.com/dspl/2010" >
    ...
</dspl>

Un espace de noms est un identifiant unique qui peut être associé à un Schéma XML (ensemble d'éléments et d'attributs XML). La targetNamespace fournit un URI qui identifie votre ensemble de données. Cet URI n'est pas obligatoire pour pointer vers une ressource réelle, mais c'est un bon que l'URI pointe vers un document décrivant votre contenu ensemble de données.

Vous n'êtes pas obligé de fournir un targetNamespace. Si vous ne le faites pas, un fichier sera généré automatiquement lors de l'importation en temps réel.

L'attribut targetNamespace est suivi d'une série Attributs xmlns spécifiant d'autres schémas XML qui seront utilisés dans le fichier. Chaque fichier DSPL doit inclure le schéma Google Public Data, dont l'URI est "http://schemas.google.com/dspl/2010" et l'utiliser comme l'espace de noms par défaut. Il doit également inclure le schéma XML W3 standard. identifié par l'URL "http://www.w3.org/2001/XMLSchema-instance". En tant que décrit dans la section suivante, vous pouvez ajouter d'autres espaces de noms pour inclure des informations provenant d'autres jeux de données.

Importer d'autres espaces de noms d'ensembles de données

Les ensembles de données peuvent réutiliser les définitions et les données d'autres ensembles de données. Google, pour fournit un certain nombre d'ensembles de données de base qui définissent des concepts communément apparaissent dans les données utilisateur. Par exemple, la plupart des jeux de données ont besoin d’un concept pour représentent des années. Au lieu de définir un nouveau concept, vous pouvez utiliser l'année concept de "http://www.google.com/publicdata/dataset/time" ensemble de données. Reportez-vous à la version Concepts.

Pour utiliser un ensemble de données externe, ajoutez l'élément <import> à le fichier DSPL juste après la déclaration de l'espace de noms, et indiquez l'espace de données que vous importez, comme ceci:

<import namespace="http://www.google.com/publicdata/dataset/google/time"/>

Ajoutez ensuite l'espace de noms importé (dans ce cas, time="http://www.google.com/publicdata/dataset/google/time"). à la déclaration d'espace de noms en haut de votre fichier, comme ceci:

<?xml version="1.0" encoding="UTF-8"?>
<dspl targetNamespace="http://www.stats-bureau.com/mystats"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://schemas.google.com/dspl/2010"
    xmlns:time="http://www.google.com/publicdata/dataset/google/time" >
<import namespace="http://www.google.com/publicdata/dataset/google/time"/>

Votre fichier DSPL peut désormais faire référence à des éléments de Google Public Data ensemble de données temporelles. Répétition ce processus pour chaque jeu de données que vous souhaitez référencer.

Référencer du contenu dans des ensembles de données externes

Après avoir importé un autre ensemble de données, vous devez pouvoir vous référer des concepts, des tranches et des données de cet ensemble de données. Pour ce faire, vous pouvez utiliser les références au format prefix:other_id, où prefix est le préfixe utilisé pour l'espace de noms du un ensemble de données externe.

Voici un exemple de référence au concept year dans l'ensemble de données time (décrit ci-dessus):

<slices>
  <slice id="country_slice">
    <dimension concept="country"/>
    <dimension concept="time:year"/>
    <metric concept="population"/>
    <table ref="country_slice_table"/>
  </slice>
  ...
</slices>

Informations sur l'ensemble de données

L'élément <info> inclut des informations descriptives sur le jeu de données. Vous trouverez un exemple et des informations détaillées sur les éléments XML pertinents : comme indiqué ci-dessous.

Exemple

<info>
  <name>
    <value>Unemployment Rates</value>
  </name>
  <description>
    <value>Worldwide unemployment rates by region</value>
  </description>
  <url>
    <value>http://www.example.com/mystats/info.html</value>
  </url>
</info>

Éléments

Élément Obligatoire ? Description
<info> Oui Contient toutes les informations descriptives sur l'ensemble de données. Inclut les éléments enfants <name>, <description> et <url>.
<name> Oui Enfant de <info>. Inclut l'élément enfant <value>, qui identifie le nom ensemble de données.
<description> Facultatif Enfant de <info>. Inclut l'élément enfant <value>, qui inclut une description textuelle du ensemble de données.
<url> Oui Enfant de <info>. Un lien vers une URL avec plus des informations sur le jeu de données.

Informations sur le fournisseur

L'élément <provider> répertorie les informations concernant d'un fournisseur d'ensembles de données. Vous trouverez un exemple et des informations détaillées sur les éléments XML pertinents : comme indiqué ci-dessous.

Exemple

<provider>
  <name>
    <value>Bureau of Statistics</value>
  </name>
  <url>
    <value>http://www.example.com</value>
  </url>
</provider>

Éléments

Élément Obligatoire ? Description
<provider> Oui Contient toutes les informations descriptives sur le fournisseur de l'ensemble de données. Inclut les éléments enfants <name> et <url>
<name> Facultatif Enfant de <provider>. Inclut l'élément enfant <value>, qui identifie le nom de l'ensemble de données. un fournisseur de services agréé.
<url> Facultatif Enfant de <info>. Un lien vers une URL avec plus sur le fournisseur de l'ensemble de données.

Concepts

Description

Chaque ensemble de données contient un ou plusieurs concepts. Un concept est une définition d'un type de données qui apparaît dans un jeu de données. Un ensemble de données avec les données démographiques sur la population, par exemple, pourraient comporter les concepts le pays, l’état, la population et l’année. Les valeurs de données correspondant à un concept donné sont appelées instances de ce concept. Les concepts sont généralement décrits dans l'ensemble de données, mais certains concepts (tels que la période ou l'année) peuvent être décrits dans des ensembles de données externes.

Chaque concept peut avoir une ou plusieurs propriétés. Une propriété est un caractéristique d'une instance conceptuelle qui est stable dans le temps. Par exemple : le concept de pays peut avoir les propriétés name, population et capital.

Les concepts peuvent également avoir un ou plusieurs attributs. Les attributs permettent des informations au niveau du concept, et non de ses instances individuelles. Pour Par exemple, si nous avions un jeu de données avec un concept de taux de chômage, nous pourrions utiliser un attribut pour indiquer que ce concept est un pourcentage. Autre exemple d'utilisation courante des attributs : indiquer les attributs des informations.

Exemple

Voici un exemple de concept de pays avec l'identifiant unique country et la propriété name. L'identifiant du concept peut être utilisé pour référencer le concept à partir de tranches et de tables.

<concept id="country" extends="geo:location">
  <info>
    <name><value>Country</value></name>
    <description>
      <value>My list of countries.</value>
    </description>
  </info>
  <type ref="string"/>
  <property id="name">
    <info>
      <name><value>Name</value></name>
      <description>
        <value>The official name of the country</value>
      </description>
    </info>
    <type ref="string" />
  </property>
  <property concept="geo:continent" isParent="true"/>
  <property id="capital" concept="geo:city" />
  <table ref="countries_table" />
</concept>

Description de l'exemple

  • Ce code décrit le pays du concept, qui a l'identifiant country et les propriétés name, continent et capital.
  • Ce concept étend geo:location, le concept canonique pour emplacements. En prolongeant geo:location, country hérite de toutes les propriétés et de tous les attributs définis par le concept étendu: le nom, la description, l'URL, la latitude et la longitude de la propriété. C'était correct pour country afin de redéfinir certains de ces attributs et Propriétés, tant que la définition est cohérente avec celle fournie par le concept étendu.
  • L'élément conceptuel <info> décrit la clé des informations sur le concept. Il s'affiche sur le tableau de bord dans Public Data Explorer.
  • L'élément concept <type> fait référence au type contenus. Dans ce cas, il s'agit d'une chaîne, mais cela peut varier. Le concept La population doit être de type integer. le concept Eurovision winner pourrait avoir le type booléen.
  • Un élément <property> décrit chaque propriété de la y compris son identifiant unique (id), info et type Les propriétés peuvent également faire référence à des concepts, indiquent que leurs valeurs sont des instances valides de ces concepts.

  • Le concept fait référence à une table de données qui pointe au fichier CSV contenant les données réelles. Le tableau de données est référencé comme ceci: <table ref="countries_table"/>.

    Si votre concept fait référence à une table, le fichier de données associé doit répertorier toutes les instances du concept. Par exemple, vous ne pouvez pas créer de table qui ne répertorie que quelques-uns des pays inclus dans le jeu de données. (Si le est un sous-ensemble de pays qui vous intéresse, vous pouvez créer un concept pour les décrire. Exemple : mycountries.)

Éléments

Élément Obligatoire ? Description
<concepts> Oui Élément de premier niveau. Contient l'ensemble des <concept> éléments.
<concept> Oui Identifie le concept. La valeur de l'attribut obligatoire id doit être propre au concept dans l'ensemble de données. Si le concept fait référence à une table de données conceptuelle, la valeur id doit correspondre à l'en-tête de colonne décrivant le concept dans le tableau de données. Un attribut extends peut être utilisé pour indiquer que ce concept étend un autre concept. La valeur extends doit correspondre à l'identifiant d'un concept défini dans le même ou au format prefix:concept_id, où concept_id est l'identifiant d'un concept défini dans le fichier ensemble de données externe associé à prefix.
<info> Facultatif Contient des informations descriptives sur le concept.
<name> Oui Enfant de <info>. Nom du concept. La l'élément enfant <value> contient le texte - pour Exemple : Country.
<description> Facultatif Enfant de <info>. Inclut l'élément enfant <value>, qui inclut une description textuelle du concept.
<url> Facultatif Enfant de <info>. Inclut l'élément enfant <value>, qui inclut une URL pour concept.
<pluralName> Facultatif Enfant de <info>. Le nom au pluriel concept. L'élément enfant <value> contient le texte - Exemple : Countries.
<totalName> Facultatif Enfant de <info>. Le nom de la combinaison toutes les instances du concept. L'élément enfant <value> contient le texte (dans le cas d'une country). ce concept. Par exemple, il peut s'agir de World.
<type> Facultatif Identifie le type de contenu décrit par le concept. Le champ obligatoire L'attribut ref peut avoir les valeurs autorisées suivantes: <ph type="x-smartling-placeholder">
    </ph>
  • chaîne
  • float
  • entier
  • date
  • booléen
Le type peut être omis si le concept étend un autre concept, auquel cas il est hérité du concept étendu.
<property> Facultatif

Une propriété du concept, telle que capital. La valeur de l'attribut obligatoire id doit être unique concept. Un attribut concept facultatif peut être utilisé pour indiquent que les valeurs de cette propriété sont des instances d'une propriété concept. Si concept est spécifié, id. peut être omis ; sa valeur est implicitement définie comme l'identifiant concept référencé (par exemple, <property concept="geo:country"/> équivaut à <property id="country" concept="geo:country"/>).

Une propriété peut contenir un attribut booléen isParent, pour indiquer que la relation entre une instance du concept et la valeur de cette propriété est hiérarchique.

Une propriété peut contenir un attribut booléen isMapping, pour indiquer qu'il existe un mappage "1:1" entre les instances du et les valeurs de la propriété.

Une propriété peut spécifier un élément info imbriqué et type, qui sont définis exactement comme pour un concept. type est obligatoire si la propriété ne spécifie pas de concept et doit correspondre au type de l'attribut un concept référencé, le cas échéant.
<attribute> Facultatif

Un attribut du concept. Les attributs représentent des des informations sur le concept (par exemple, le PIB est un pourcentage). La valeur de l'attribut obligatoire id doit être unique concept. Un attribut concept facultatif peut être utilisé pour indiquent que les valeurs de cet attribut sont des instances d'un concept. Si concept est spécifié, id. peut être omise. Sa valeur est implicitement définie comme étant l'identifiant de référence. (par exemple, <attribute concept="unit:unit"/> équivaut à <attribute id="unit" concept="unit:unit"/>

Un attribut peut spécifier un élément info imbriqué et type, qui sont définis de la même manière que pour un concept. type est obligatoire si l'attribut ne spécifie pas de concept et doit correspondre au type de l'attribut un concept référencé, le cas échéant.
<table> Facultatif Identifie le tableau de données contenant des données pour le concept. La la valeur de l'attribut ref obligatoire doit correspondre à celle indiquée dans le tableau. ID spécifié dans l'élément <table> associé.

Tranches

Description

Une tranche est une combinaison de concepts pour lesquels des données existent. Une tranche qui contient deux types de références conceptuelles: les dimensions et métriques. Une dimension est un concept utilisé pour segmenter ou filtrer vos données. En revanche, une métrique décrit la valeur observée associées à chaque point de données.

En général, les dimensions sont catégorielles, tandis que les métriques ne le sont pas. des valeurs numériques variées dans le temps. Voici quelques exemples prototypiques pour chaque ce qui suit:

  • Dimensions: pays, État, comté, région, année mois, sexe, catégorie d'âge, segment du secteur
  • Métriques: Population, PIB, taux de chômage, alphabétisation revenus, coût, prix

Exemple

<slices>
  <slice id="country_slice">
    <dimension concept="country"/>
    <dimension concept="time:year"/>
    <metric concept="population"/>
    <table ref="country_slice_table"/>
  </slice>
  ...
</slices>

Description de l'exemple

  • Ce secteur représente la population par pays.
  • Il comporte la métrique population et les dimensions country et year. Chaque dimension est un concept déjà défini ailleurs. Le concept country et la métrique population se trouvent dans le même ensemble de données que la tranche actuelle ; et sont référencées comme suit: concept="country"
  • Le concept year existe dans l'heure de l'ensemble de données importé, identifié par le préfixe utilisé avant le nom du concept (year), comme ceci: concept="time:year"
  • La tranche fait référence à une table de données qui pointe vers le fichier CSV. contenant les données réelles. Le tableau de données est référencé comme suit: <table ref="country_slice_table"/> (voir ci-dessus) pour obtenir des informations sur l'importation ensembles de données.)

Remarque:En général, les volumes de données est flexible si vous limitez les métriques au minimum et que vous créez plutôt . Par exemple, au lieu de créer les métriques Female Unemployment et Male Unemployment, créez l'unique métrique Unemployment, puis ajoutez la dimension Gender, qui contient les instances Female et Male

Éléments

Élément Obligatoire ? Description
<slices> Oui Élément de premier niveau. Contient l'ensemble des <slice> éléments.
<slice> Facultatif Identifie la tranche. La valeur de l'attribut obligatoire id doit être unique au segment.
<dimension> Facultatif Définit une dimension du secteur, en référençant un concept. La la valeur de l'attribut obligatoire concept doit correspondre exactement l'identifiant unique du concept et utilisez un préfixe valide si celui-ci appartient à un ensemble de données importé externe.
<metric> Facultatif Définit une métrique du segment, en référençant un concept. La valeur de l'attribut obligatoire concept doit correspondre exactement à identifiant unique du concept et utilisez un préfixe valide si le concept appartient à un ensemble de données importé externe.
<table> Oui Identifie la table de données contenant les données pour la tranche. La valeur de l'attribut ref requis doit correspondre à l'ID de table spécifié dans l'élément <table> associé.
<mapDimension> Facultatif Enfant de <table>. Contient les attributs concept et toColumn. la valeur du premier est du segment, la valeur de la seconde étant la colonne du tableau correspondant au premier.
<mapMetric> Facultatif Enfant de <table>. Contient les attributs concept et toColumn. la valeur du premier est une métrique de la tranche, et la valeur de la seconde est la colonne du tableau correspondant au premier.

Tables

Description

La section tables du fichier DSPL identifie les données tables incluses dans l'ensemble de données. Ces tableaux peuvent être référencés par des concepts ou par tranches. Chaque élément <table> spécifie les colonnes de les tableaux et leurs types, et pointe vers un fichier CSV contenant le tableau données.

Exemple

<tables>
  <table id="country_slice_table">
    <column id="country" type="string"/>
    <column id="year" type="date" format="yyyy"/>
    <column id="population" type="integer"/>
    <data>
      <file format="csv" encoding="utf-8">country_slice.csv</file>
    </data>
  </table>
  ...
</tables>

Description de l'exemple

  • Cet exemple décrit la table country_slice_table. La contient les colonnes country, year et population
  • Chaque colonne de la table possède un identifiant unique, défini par le paramètre id. Cet identifiant doit correspondre exactement à l'ID l'en-tête de colonne du fichier de données associé.
  • La valeur de l'attribut facultatif type définit les données pour chaque colonne.
  • L'élément <data> décrit le fichier .csv réel. (country_slice.csv) contenant les données de la table. Le format de fichier est toujours csv.

Éléments

Élément Obligatoire ? Description
<tables> Oui Élément de premier niveau. Contient l'ensemble des <table> éléments.
<table> Oui Identifie la table. La valeur de l'attribut obligatoire id doit être unique à la table.
<column> Facultatif Enfant de <table>. Informations sur une colonne incluses dans le tableau. Inclut les attributs suivants: <ph type="x-smartling-placeholder">
    </ph>
  • id (obligatoire): ID de la colonne.
  • type (facultatif): type de données des informations dans la colonne spécifiée. Valeurs autorisées: string, float, integer, date ou boolean
<data> Facultatif Enfant de <table>. Le fichier de données référencé par le tableau. Si le nom du fichier se présente sous la forme d'une URL (par exemple, http://...), le fichier sera récupéré via la le protocole approprié (HTTP, HTTPS ou FTP) ; Sinon, un fichier doit être associé à l'ensemble de données. La valeur de l'attribut obligatoire format est toujours csv. Bien que l'attribut encoding est facultatif, vos fichiers .csv doivent être encodés en UTF-8.

Thèmes

Description

Les sujets classent les concepts de manière hiérarchique, ce qui permet aux utilisateurs de naviguer dans votre jeu de données plus facilement.

L'élément <topics> doit apparaître juste avant la balise <concepts> dans votre fichier DSPL. (L'ordre de est important, et vous ne pourrez peut-être pas télécharger votre jeu de données si votre éléments n'apparaissent pas dans le bon ordre.) Pour utiliser des thèmes, faites-les référence dans le la définition d'un concept.

Exemple

Voici un exemple de définition de sujet:

<topics>
  <topic id="population_indicators">
    <info>
      <name>
        <value>Population indicators</value>
      </name>
    </info>
  </topic>
  ...
</topics>

Voici un exemple de référence à ce sujet à partir d'un concept:

<concept id="population">
  <info>
    <name>
      <value>Population</value>
    </name>
    <description>
      <value>Size of the resident population.</value>
    </description>
  <topic ref="population_indicators"/>
  <type ref="integer"/>
</concept>

Les thèmes peuvent être imbriqués et un concept peut faire référence à plusieurs sujets.

Définition de l'élément

Élément Obligatoire ? Description
<topics> Oui Élément de premier niveau. Contient l'ensemble des <topic> éléments.
<topic> Oui Identifie le sujet. La valeur de l'attribut obligatoire id doit être unique à l'ensemble de données.
<info> Facultatif Enfant de <topic>. Contient des informations sur une sur ce sujet.
<name> Facultatif Enfant de <info>. Son élément enfant <value> spécifie le nom du sujet.

Fichiers de données DSPL

Outre le fichier de métadonnées XML, un ensemble de données DSPL peut également Incluez un ou plusieurs fichiers de données au format CSV. Chaque fichier de données prend en charge une table dans l'ensemble de données, et est référencée à partir de la première dans sa Section <data>...</data>. Conceptuellement, ces fichiers et les tableaux associés sont utilisés pour représenter les concepts des définitions ou des segments de données. Chacun de ces types de fichiers de données est décrits plus en détail ci-dessous.

Notez que, quelle que soit leur finalité, tous les fichiers de données doivent être fichiers texte CSV UTF-8 délimités par des virgules. Les fichiers ne doivent contenir que des Texte ; pas de code HTML. Vous pouvez créer les fichiers de données manuellement, devront masser les données soit dans l'outil contenant les données d'origine, source (une feuille de calcul, par exemple) ou directement dans le fichier exporté.

Les fichiers peuvent être regroupés avec le jeu de données ou, si le nom se présente sous la forme d'un URL, récupérée via HTTP, HTTPS ou FTP à partir d'une source distante.

Fichiers de données de concept

Les fichiers de données de concept contiennent des informations pertinentes pour chaque concept. La la définition de concept utilise l'élément <table> pour faire référence ce fichier.

Exemple

Voici un exemple de table pour le concept country définis ci-dessus:

country, name
AD, Andorra
AF, Afghanistan
AI, Anguilla
AL, Albania
AO, Angola
AQ, Antarctica
AS, American Samoa

Voici comment fonctionne cet exemple:

  • À moins que des mappages ne soient spécifiés, la première ligne du fichier de données (colonne en-têtes) doit correspondre exactement à l'identifiant de concept et à la propriété appropriée du concept auquel les données sont associées. Cependant, l'ordre des colonnes ne doivent pas nécessairement être identiques dans le fichier de données. tableau des concepts. Dans ce cas, la première colonne est associée au le concept country, et la deuxième colonne est associée au la propriété name.
  • Les colonnes de propriétés sont facultatives. Si une propriété n'a pas de colonne du tableau, sa valeur est considérée par défaut comme non définie pour chaque ligne. La ci-dessus, par exemple, omet les colonnes pour latitude et longitude : il ne sera pas possible de mapper les pays.
  • Chaque valeur du champ d'identifiant du concept (dans ce cas, country) doit être unique et non vide (un champ vide correspond à zéro ou uniquement des espaces blancs).
  • Les valeurs des propriétés qui font référence à d'autres concepts doivent être vide ou être une valeur valide du concept référencé.
  • Les valeurs entre guillemets doubles sont facultatives, sauf si contenir des virgules, des guillemets doubles ou des sauts de ligne.
  • Échappez un guillemet double littéral qui apparaît dans une valeur en le faisant précéder avec une autre guillemet double.

Fichiers de données de segment d'application

Les fichiers de données de segment contiennent des données pertinentes pour chaque segment. La tranche utilise l'élément <table ref="..."> pour se référer à la définition <table>, qui à son tour identifie ce fichier.

Exemple

Voici un exemple de fichier .csv contenant les données pour Tranche population_by_country décrite ci-dessus:

country, year, population
AF, 1960, 9616353
AF, 1961, 9799379
AF, 1962, 9989846
AF, 1963, 10188299

Voici comment fonctionne cet exemple:

  • Le champ de la métrique est population. Champs country et year sont des champs de dimension.
  • Chaque valeur d'un champ de dimension ne doit pas être vide. Cela inclut le temps . Les valeurs des champs de métriques peuvent être vides. Une valeur vide est représenté par aucun caractère.
  • Chaque en-tête de colonne qui fait référence à un concept (par exemple, le premier de l'exemple ci-dessus fait référence au concept country) doit correspondent exactement à l'identifiant unique du concept dans la définition du concept.
  • Une combinaison unique de valeurs de dimension (ex. : AF, 2000, ne peuvent survenir qu'une seule fois.
  • Lignes d'une même série temporelle (c'est-à-dire les lignes possédant la même combinaison de toutes les valeurs de dimension, à l'exception de l'heure) doivent être regroupées. n'ont pas besoin d'être triées.

Fonctionnalités avancées

Ensembles de données multilingues

Valeurs XML traduites

Vous pouvez utiliser l'attribut xml:lang avec toutes les <value> dans votre fichier DSPL. Cet attribut spécifie la langue du contenu de l'élément en utilisant la norme W3C, tags de langue. Notez que l'utilisation de cette fonctionnalité est facultative. si non L'attribut xml:lang est inclus, le contenu est censé se trouver au format anglais.

L'exemple suivant montre des extraits d'un jeu de données en anglais, Bulgare, catalan et chinois simplifié:

<dspl ...>
  <info>
    <name>
      <value xml:lang="en">World Bank, World Development Indicators</value>
      <value xml:lang="bg">Световна банка, Индикатори за световно развитие</value>
      <value xml:lang="ca">Banc Mundial, Indicadors del desenvolupament mundial</value>
      <value xml:lang="zh-CN">国家/地区</value>
    </name>
    ...
  </info>

  <concepts>
    <concept id="country">
      <info>
        <name>
          <value xml:lang="en">Country</value>
          <value xml:lang="bg">Страна</value>
          <value xml:lang="ca">País</value>
          <value xml:lang="zh-CN">国家/地区</value>
        </name>
        ...
      </info>
      ...
    </concept>
    ...
  </concepts>

  ...
</dspl>

Propriétés traduites

Dans certains cas, vous souhaiterez peut-être fournir des traductions qui vont au-delà métadonnées au niveau du concept, en s'ajoutant (ou à la place) à chaque Compute Engine. C'est particulièrement utile lorsque les valeurs d'un concept (le nom, par exemple) varient en fonction de la langue.

Pour fournir de telles valeurs dans plusieurs langues, créez une colonne dans la table de définition correspondante pour chaque combinaison propriété/langue. Ensuite, associez ces colonnes à leurs propriétés et langues associées en en ajoutant un ensemble d'éléments <mapProperty xml:lang="..." ref="..." toColumn="..."> au tableau de référence du concept.

Voici un exemple qui définit un concept de pays avec des noms en anglais, espagnol et français:

<concepts>
  ...
  <concept id="country" extends="geo:location">
    ...
    <property id="name">
      <info>
        <name>
          <value>Name</value>
        </name>
        <description>
          <value>The official name of the country</value>
        </description>
      </info>
      <type ref="string" />
    </property>
    ...
    <table ref="countries_table">
      <mapProperty xml:lang="en" ref="name" toColumn="name_en"/>
      <mapProperty xml:lang="es" ref="name" toColumn="name_es"/>
      <mapProperty xml:lang="fr" ref="name" toColumn="name_fr"/>
    </table>
  </concept>
  ...
</concepts>

...

<tables>
  ...
  <table id="countries_table">
    <column id="country" type="string"/>
    <column id="name_en" type="string"/>
    <column id="name_es" type="string"/>
    <column id="name_fr" type="string"/>
    ...
  </table>
</tables>

Le fichier CSV de countries_table contiendrait alors ce formulaire:

country,name_en,name_es,name_fr,...
...
US,United States of America,Estados Unidos de América,États-Unis d'Amérique,...
...

Concepts mappables

De nombreux concepts (par exemple, le comté, l'État et ville) ont des instances correspondant à des emplacements géographiques. DSPL prend en charge le geocoding de ces instances pour qu'elles puissent être visualisées dans la Graphique de carte animé Google Public Data.

Si votre concept correspond aux pays du monde, aux États américains ou aux États-Unis il vous suffit de créer un lien vers la page canonique Google correspondante conceptuel ; aucun geocoding explicite n'est requis. Pour en savoir plus, consultez le Guide des concepts canoniques. plus de détails.

Si ce n'est pas le cas, vous devez rendre votre concept cartographique. La première étape consiste à Faites-le s'étendre à partir de geo:location:

<concept id="..." extends="geo:location">
  ...
</concept>

Vous devez ensuite ajouter explicitement la latitude et la longitude en tant que propriétés:

<concept id="..." extends="geo:location">
  ...
  <property id="latitude"/>
  <property id="longitude"/>
</concept>

Les valeurs de ces attributs sont ensuite spécifiées sous forme de colonnes dans la table de données de définition de concept.

Relations entre les concepts

Les concepts sont souvent liés à d'autres concepts de manière structurée. Pour une instance "Continent" peut inclure plusieurs de pays qui, à leur tour, peuvent contenir plusieurs instances d'un État ou d'une province. Encoder ces relations dans les métadonnées de l'ensemble de données permet une visualisation enrichie que ce qui serait autrement possible, par exemple l'affichage d'une arborescence réductible de lieux parmi lesquels choisir.

Dans les sections ci-dessous, nous décrivons les relations de concept prises en charge dans le schéma DSPL.

Hiérarchies

Les hiérarchies de concepts sont représentées dans DSPL à l'aide d'un L'attribut isParent="true" dans une Le tag <property> du concept enfant, qui contient les identifiants d'instances du concept parent.

Par exemple, le concept de "comté aux États-Unis" de Google ce formulaire:

<concept id="us_county" extends="geo:location">
  <info>
    <name>
      <value xml:lang="en">County</value>
    </name>
    ...
  </info>
  ...
  <property id="state" concept="us_state" isParent="true"/>
  ...
  <data>
    <table ref="reference_us_counties"/>
  </data>
</concept>

Le tableau de données secondaire contient une colonne state avec le code d’État à deux lettres pour chaque comté. Ce type de métadonnées permet au Public Data Explorer pour afficher les états et les comtés sous forme de hiérarchie, une fonctionnalité qui facilite grandement l'exploration pour les utilisateurs.

Notez qu'un concept peut avoir de nombreux enfants, mais pas plus d'un parent.

Mappages

Mappages de concepts (c'est-à-dire des concepts qui représentent, fondamentalement, le même objet) sont représentés par un isMapping="true" dans une balise property du concept mappé.

Spécifier qu'un concept est mappé à un autre permet au premier d'hériter toutes les propriétés et tous les attributs de ce dernier. Entre autres applications, cela est utile pour « associer » concepts géographiques personnels avec celles définies dans l'ensemble de données géographiques canoniques de Google :

<concept id="my_country" extends="geo:location">
  <info>
    <name>
      <value xml:lang="en">Country</value>
    </name>
    ...
  </info>
  ...
  <property id="google_country_code" concept="geo:country" isMapping="true"/>
  <data>
    <table ref="countries_concept"/>
  </data>
</concept>

Extensions

Les extensions de concept sont désignées via un élément extends. dans la définition de concept correspondante. Les extensions permettent d'indiquer qu'un concept particulier est une sous-classe d'un autre concept plus large. La hérite de tous les attributs et propriétés de son parent, et vous pouvez en ajouter d'autres.

Par exemple, le concept currency de Google étend unit:

<concept id="unit">
  ...
</concept>

<concept id="currency" extends="unit">
  <info>
    <name>
      <value xml:lang="en">Currency unit</value>
    </name>
    ...
  </info>
  ...
  <table ref="currency_table"/>
</concept>

Voir la discussion sur le concept du tutoriel pour obtenir plus d'explications et d'exemples.

Envoyer votre ensemble de données

Pour envoyer votre jeu de données à Google Public Data Explorer, suivez ces instructions:

  1. Créez un répertoire.
  2. Enregistrez le fichier dspl de l'ensemble de données dans le répertoire que vous avez créé. Veillez à utilisez l'extension .xml.
  3. Enregistrez tous les fichiers .csv locaux dans le même répertoire. Les fichiers de données qui sont référencées via des URL peuvent être omises.
  4. Compressez le répertoire.
  5. Importez votre ensemble de données dans Google Public Data. l'explorateur de données.

Une fois votre ensemble de données importé et validé, vous pouvez le tester une fois signé à votre compte Google. Il ne sera pas publié tant que vous n'aurez pas coché et nous dire qu'il est prêt.