Przewodnik dla programistów DSPL

DSPL to skrót od Dataset Publishing Language, Jest to format reprezentacji zarówno metadanych, czyli informacji o zbiorze danych, np. nazwę i dostawcę, a także zawarte w nim pojęcia i informacje) rzeczywiste dane zbiorów danych. Zbiory danych opisane w tym formacie można zaimportowane do publicznych danych Google Eksplorator, czyli narzędzie, które umożliwia rozbudowane, wizualne poznawanie i skalowalnych danych.

Uwaga: aby przesłać dane do Google Public Data za pomocą narzędzia do przesyłania danych publicznych musisz mieć konto Google.

Ten dokument jest przeznaczony dla właścicieli danych, którzy chcą, aby ich treści dostępne w narzędziu Public Data Explorer. To więcej niż tylko samouczek, bo zawiera szczegółowe informacje schemat DSPL i obsługiwane funkcje. Tylko podstawowa znajomość Przyjmuje się, że zazwyczaj znamy język XML, jednak znajomość relacyjnych baz danych przydatne.

Chociaż nie jest to wymagane, sugerujemy zapoznanie się z samouczkiem, który jest krótszy jest łatwiejszy do przeczytania, zanim zapozna się z tym dokumentem.

Omówienie

Zbiór danych DSPL to plik ZIP, który zawiera plik XML i zestaw plików CSV . Pliki CSV to proste tabele zawierające dane zbioru danych, a plik XML opisuje metadane zbioru danych. To ostatnie obejmuje m.in. metadane informacyjne, takie jak opisy wskaźników, a także metadane strukturalne, takie jak odwołania między tabelami. Te metadane pozwala użytkownikom, którzy nie są doświadczeni, przeglądać i wizualizować Twoje dane.

Przetwarzanie

Ogólnie proces tworzenia zbioru danych DSPL wygląda w ten sposób (niektóre czynności, które mogą mieć miejsce równolegle):

  1. Utwórz plik XML DSPL.
  2. Określ wszelkie zewnętrzne źródła danych, których chcesz użyć w zbiorze danych.
  3. Zdefiniuj swoje pojęcia, fragmenty i (opcjonalnie) tematy. Iteratywnie zaktualizować zawartość pliku DSPL.
  4. Wyeksportuj dane źródłowe do plików .csv.
  5. Utworzenie zbioru danych DSPL.
  6. Prześlij zbiór danych do Google.

Struktura XML

Omówienie

Plik XML DSPL definiuje metadane zbioru danych, w tym zależności strukturalne między koncepcjami, wycinkami, tematami i tabelami. Chociaż można utworzyć ten plik ręcznie, narzędzia do przetwarzania danych a skrypty mogą to znacznie usprawnić. Zobacz przykładowy plik DSPL w nowym formacie okno.

Plik zawiera pewną liczbę sekcji, które zostały podsumowane w tabeli. poniżej. W tabeli opisujemy każdą z nich w większym szczegóły.

Sekcja Podsumowanie Więcej informacji
Nagłówek i importy Element nadrzędny wszystkich pozostałych elementów zbioru danych. Obejmuje docelowej przestrzeni nazw (tzn. identyfikatora) zbioru danych wraz z przestrzeni nazw wszystkich zaimportowanych zbiorów danych. Dokumentacja
Informacje o zbiorze danych Nazwa, opis i adres URL zbioru danych. Dokumentacja
Informacje o dostawcy Nazwa, opis i adres URL dostawcy zbioru danych. Dokumentacja
Pojęcia

Definicje pojęć „rzeczy” widoczne w zbiorze danych (np. kraje, stopa bezrobocia, płeć itp.)

Każda koncepcja ma unikalny identyfikator, do którego może się odwoływać wycinki i tabele.

 Dokumentacja
Wycinki

Kombinacje pojęć, dla których dostępne są dane statystyczne w gromadzeniu danych. Każdy wycinek zawiera wymiary i danych.

Wycinki odwołują się do pojęć, a także do tabel, które zawierają rzeczywiste i skalowalnych danych. Każdy wycinek ma unikalny identyfikator, do którego może się odwoływać funkcja tabel zawierających rzeczywiste dane.

 Dokumentacja
Tabele Zdefiniuj dane pojęć i wycinków. Blokada tabel koncepcyjnych wyliczenia i tabele wycinków zawierają dane statystyczne. Zdefiniowano tabele w pliku XML i wskaż pliki .csv zawierające rzeczywiste dane. Dokumentacja
Tematy Kategorie do porządkowania koncepcji zbiorów danych. Nie są one wymagane, ale mogą być bardzo pomocne dla użytkowników korzystających z Twoich danych. Dokumentacja

Nagłówek i importowanie

Deklarowanie przestrzeni nazw Public Data

Zbiór danych DSPL zaczyna się od elementu <dspl> najwyższego poziomu. Służą do uwzględnienia wszystkich informacji ze zbioru danych i wskazywania przestrzeni nazw, które będą używane w całym pliku. Oto przykład:

<?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>

Przestrzeń nazw to unikalny identyfikator, który można powiązać z Schemat XML (zbiór elementów i atrybutów XML). targetNamespace udostępnia identyfikator URI, który identyfikuje zbiór danych. Ten identyfikator URI nie jest wymagany, aby wskazywać rzeczywisty zasób, ale jest to dobry Pomysł na udostępnienie identyfikatora URI dokumentu, który opisuje Twoją treść, w gromadzeniu danych.

Nie musisz podawać targetNamespace. Jeśli nie, zostanie on wygenerowany automatycznie podczas importu obecnie się znajdujesz.

Po atrybucie targetNamespace znajduje się seria Atrybuty xmlns określające inne schematy XML, które zostaną użyte w pliku. Każdy plik DSPL musi zawierać schemat Google Public Data, którego identyfikator URI to „http://schemas.google.com/dspl/2010” i wykorzystaj go jako domyślnej przestrzeni nazw. Powinien też zawierać standardowy schemat XML W3. zidentyfikowany przez „http://www.w3.org/2001/XMLSchema-instance”. Jako opisane w następnej sekcji, można dodać inne przestrzenie nazw, aby uwzględnić informacji z innych zbiorów danych.

Importowanie innych przestrzeni nazw zbiorów danych

Zbiory danych mogą wykorzystywać definicje i dane z innych zbiorów danych. Google dla zapewnia szereg podstawowych zbiorów danych, które definiują koncepcje często widoczne w danych użytkowników. Na przykład większość zbiorów danych wymaga pojęcia, aby reprezentują lata. Zamiast definiować nową koncepcję, możesz użyć atrybutu rok pojęcie z „http://www.google.com/publicdata/dataset/time” w gromadzeniu danych. Zapoznaj się z dokumentami kanonicznymi Pojęcia.

Aby użyć zewnętrznego zbioru danych, dodaj element <import> do pliku DSPL tuż po deklaracji przestrzeni nazw i wskaż importowaną przestrzeń danych, w następujący sposób:

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

Następnie dodaj zaimportowaną przestrzeń nazw (w tym przypadku time="http://www.google.com/publicdata/dataset/google/time"). do deklaracji przestrzeni nazw u góry pliku, na przykład:

<?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"/>

Twój plik DSPL może teraz odwoływać się do elementów z Google Public Data zbioru danych czasu. Powtórz dla każdego zbioru danych, do którego chcesz się odwołać.

Odwoływanie się do treści w zewnętrznych zbiorach danych

Po zaimportowaniu innego zbioru danych musisz mieć możliwość odwoływania się koncepcje, wycinki i dane z tego zbioru danych. Aby to zrobić, możesz użyć: odwołania w formacie prefix:other_id, gdzie prefix to prefiks używany dla przestrzeni nazw i do zewnętrznego zbioru danych.

Oto przykład odniesienia do pojęcia year z: zbiór danych time (opisany powyżej):

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

Informacje o zbiorze danych

Element <info> zawiera informacje opisowe na temat zbioru danych. Przykłady i szczegółowe informacje na temat odpowiednich elementów XML to wymienionych poniżej.

Przykład

<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>

Elementy

Element Wymagana? Opis
<info> Tak Obejmuje wszystkie opisowe informacje na temat zbioru danych. Zawiera elementy podrzędne <name>, <description> i <url>.
<name> Tak Dziecko konta <info>. Zawiera element podrzędny <value>, który określa nazwę w gromadzeniu danych.
<description> Opcjonalnie Dziecko konta <info>. Zawiera element podrzędny <value>, który zawiera opis tekstowy w gromadzeniu danych.
<url> Tak Dziecko konta <info>. link do adresu URL zawierający więcej elementów, informacje o zbiorze danych.

Informacje o dostawcy

Element <provider> zawiera informacje o dostawcy zbioru danych. Przykłady i szczegółowe informacje na temat odpowiednich elementów XML to wymienionych poniżej.

Przykład

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

Elementy

Element Wymagana? Opis
<provider> Tak Obejmuje wszystkie opisowe informacje o dostawcy zbioru danych. Zawiera elementy podrzędne <name> oraz <url>
<name> Opcjonalnie Dziecko konta <provider>. Zawiera element podrzędny <value>, która określa nazwę zbioru danych. dostawcy usług.
<url> Opcjonalnie Dziecko konta <info>. link do adresu URL zawierającego więcej informacji, informacje o dostawcy zbioru danych.

Pojęcia

Opis

Każdy zbiór danych zawiera co najmniej 1 koncepcję. Pojęcie to definicji typu danych występujących w zbiorze danych. Zbiór danych z dane demograficzne mogą obejmować na przykład koncepcje kraj, stan, ludność i rok. Wartości danych odpowiadające argumentowi danej koncepcji są nazywane wystąpieniami tej koncepcji. Pojęcia to zwykle opisane w zbiorze danych, ale niektóre koncepcje (takie jak czas lub rok) i można je opisać w zewnętrznych zbiorach danych.

Każdy element może mieć co najmniej 1 właściwość. Usługa jest dla instancji koncepcyjnej, która jest stabilna w czasie. Przykład: koncepcja kraju może mieć właściwości name, population i capital.

Pojęcia mogą mieć co najmniej 1 atrybut. Atrybuty dostarczają na poziomie koncepcji, a nie jej poszczególnych wystąpień. Dla: Na przykład, jeśli mamy zbiór danych z koncepcją stopy bezrobocia, moglibyśmy użyć atrybutu, by wskazać, że ta koncepcja ma wartość procentową. Innym przykładem częstego użycia atrybutów jest podawanie jednostki i informacjami o nich.

Przykład

Oto przykład koncepcji kraju z unikalnym identyfikatorem country i usługę name. Identyfikatorem pojęć może być używane do odwoływania się do koncepcji z wycinków i tabel.

<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>

Oto jak działa ten przykładowy kod.

  • Ten kod opisuje kraj koncepcji, który ma identyfikator. country i właściwości name, continent i capital.
  • Rozszerza koncepcję geo:location, kanoniczną koncepcję lokalizacji. Wydłużając termin: geo:location, country dziedziczy wszystkie właściwości i atrybuty zdefiniowane przez koncepcję rozszerzoną: właściwości, opis, url, szerokość i długość geograficzną. W porządku dla country, aby ponownie zdefiniować niektóre z tych atrybutów oraz o ile definicja jest zgodna z podaną ze względu na koncepcję rozszerzoną.
  • Element <info> opisuje klucz. informacji na temat koncepcji. Jest ona wyświetlana na stronie zbioru danych w narzędziu Public Data Explorer.
  • Koncepcja elementu <type> odnosi się do typu treści. W tym przypadku jest to ciąg znaków (ale to może być inne). Idea Typ populacji będzie miał typ integer; koncepcja Eurovision winner może mieć wartość logiczną.
  • Element <property> opisuje każdą właściwość w tym jego unikalny identyfikator (id), info oraz type Usługi mogą też odwoływać się do pojęć, aby wskazują, że ich wartości są prawidłowymi wystąpieniami tych koncepcji.

  • Koncepcja odwołuje się do tabeli danych, która wskazuje do pliku CSV z rzeczywistymi danymi. Odwołanie do tabeli danych w ten sposób: <table ref="countries_table"/>.

    Jeśli pojęcie odwołuje się do tabeli, powiązany plik danych musi zawierać listę wszystkich wystąpień tej koncepcji. Nie można na przykład utworzyć tabeli który zawiera tylko kilka krajów uwzględnionych w zbiorze danych. (Jeśli jest podzbiorem krajów, które Cię interesują, możesz utworzyć aby je opisać. np. mycountries.)

Elementy

Element Wymagana? Opis
<concepts> Tak Element najwyższego poziomu. Obejmuje wszystkie <concept> .
<concept> Tak Określa pojęcie. Wartość wymaganego atrybutu id musi być unikalna dla koncepcji w zbiorze danych. Jeśli koncepcja odwołuje się do tabeli danych koncepcji, wartość Wartość id musi być zgodna z nagłówkiem kolumny opisującym dany temat w tabeli danych. Można użyć atrybutu extends do oznaczenia że ta koncepcja jest rozwinięciem innej koncepcji. Wartość extends musi pasować do identyfikatora elementu zdefiniowanego w tym samym zbiór danych lub ma postać prefix:concept_id, gdzie concept_id to identyfikator koncepcji zdefiniowanej w importowanym pliku. i zewnętrzny zbiór danych powiązany z zasadą prefix.
<info> Opcjonalnie Zawiera opisowe informacje na temat pojęcia.
<name> Tak Dziecko konta <info>. Nazwa koncepcji. element podrzędny <value> zawiera tekst - dla na przykład Country.
<description> Opcjonalnie Dziecko konta <info>. Zawiera element podrzędny <value>, który zawiera opis tekstowy koncepcją działania.
<url> Opcjonalnie Dziecko konta <info>. Zawiera element podrzędny <value>, który zawiera adres URL koncepcją działania.
<pluralName> Opcjonalnie Dziecko konta <info>. Liczba mnoga dla koncepcją działania. Element podrzędny <value> zawiera tekst na przykład Countries.
<totalName> Opcjonalnie Dziecko konta <info>. Nazwa kombinacji wszystkich wystąpień tej koncepcji. Element podrzędny <value> zawiera tekst- w przypadku country koncepcja, na przykład World.
<type> Opcjonalnie Określa typ treści opisanym w koncepcji. Wymagane atrybut ref ma następujące dozwolone wartości:
  • ciąg znaków
  • liczba zmiennoprzecinkowa
  • liczba całkowita
  • data
  • wartość logiczna
Tę typ można pominąć, jeśli dane koncepcje rozszerzają inne koncepcje. W tym przypadku jest ona dziedziczona z pojęć rozszerzonej.
<property> Opcjonalnie

Właściwość koncepcji, na przykład capital. Wartość wymaganego atrybutu id musi być unikalny w koncepcją działania. Można użyć opcjonalnego atrybutu concept, aby: wskazują, że wartości tej właściwości są instancjami danej koncepcją działania. Jeśli określono concept, to id może zostać pominięty, jego wartość jest niejawnie zdefiniowana jako identyfikator funkcji przywołane pojęcie (np. <property concept="geo:country"/> jest odpowiednikiem funkcji <property id="country" concept="geo:country"/>).

Właściwość może zawierać atrybut isParent z wartością logiczną, wskazuje, że związek między przypadkiem i wystąpieniem koncepcji a jej wartość jest hierarchiczna.

Właściwość może zawierać atrybut isMapping z wartością logiczną, wskazuje, że istnieje mapowanie 1-1 między instancjami pojęcie i wartości właściwości.

Właściwość może określać zagnieżdżone info oraz type, które są zdefiniowane tak samo jak na potrzeby koncepcji. Element type jest wymagany, jeśli właściwość nie określa concept i musi być taki sam jak typ wymienionego pojęcia.
<attribute> Opcjonalnie

Atrybut koncepcji. Atrybuty reprezentują dodatkowe informacje o danym zagadnieniu (np. PKB to wartość procentowa). Wartość wymaganego atrybutu id musi być unikalny w koncepcją działania. Można użyć opcjonalnego atrybutu concept, aby: wskazują, że wartości tego atrybutu są wystąpieniami danego atrybutu koncepcją działania. Jeśli określono concept, to id może zostać pominięty. Jego wartość jest niejawnie zdefiniowana jako identyfikator wymienionego pojęcia. (np. <attribute concept="unit:unit"/> jest odpowiednikiem funkcji <attribute id="unit" concept="unit:unit"/>

Atrybut może określać zagnieżdżone atrybuty info i type, które są zdefiniowane tak samo jak koncepcja. type jest wymagany, jeśli atrybut nie określa concept i musi być taki sam jak typ wymienionego pojęcia.
<table> Opcjonalnie Identyfikuje tabelę danych zawierającą dane związane z zagadnieniem. wartość wymaganego atrybutu ref musi być zgodna z tabelą Identyfikator określony w powiązanym elemencie <table>.

Wycinki

Opis

Wycinek to kombinacja koncepcji, dla których istnieją dane. Wycinek zawiera 2 rodzaje odwołań do koncepcji: wymiary i danych. Wymiar to pojęcie używane do podziału na segmenty lub filtrowania danych. Dane opisują natomiast obserwowaną wartość lub powiązane z każdym punktem danych.

Ogólnie wymiary są kategoryczne, a dane – nie kategoryzujące, zmienności czasowe, wartości liczbowe. Oto kilka prototypowych przykładów każdego z nich: następujące:

  • Wymiary: kraj, stan, hrabstwo, region, rok miesiąc, płeć, kategoria wiekowa, segment branży
  • Dane: populacja, PKB, stopa bezrobocia, kompetencje, przychody, koszt, cena

Przykład

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

Oto jak działa ten przykładowy kod.

  • Ten wycinek reprezentuje populację według kraju.
  • Zawiera dane population, a wymiary country i year. Każdy wymiar jest koncepcją. już zdefiniowane w innym miejscu. Pojęcie country i wskaźnik population znajdują się w tym samym zbiorze danych co bieżący wycinek oraz są przywoływane w następujący sposób: concept="country"
  • Pojęcie year istnieje w czasie zaimportowanego zbioru danych, z prefiksem używanym przed nazwą koncepcji (year), : concept="time:year"
  • Wycinek odwołuje się do tabeli danych, która wskazuje plik CSV. zawierający rzeczywiste dane. Odwołanie do tabeli danych wygląda tak: <table ref="country_slice_table"/> (patrz wyżej do informacji o importowaniu i zbiory danych).

Uwaga: zwykle zbiór danych jeśli ograniczysz dane do minimum, a zamiast tego utworzysz istotne wymiarów. Na przykład zamiast tworzyć dane Female Unemployment i Male Unemployment, utwórz jeden rodzaj danych Unemployment i dodaj wymiar Gender, który zawiera instancje Female i Male.

Elementy

Element Wymagana? Opis
<slices> Tak Element najwyższego poziomu. Obejmuje wszystkie <slice> .
<slice> Opcjonalnie Identyfikuje wycinek. Wartość wymaganego atrybutu Wartość id musi być unikalna dla wycinka.
<dimension> Opcjonalnie Definiuje wymiar wycinka, odwołując się do koncepcji. wartość wymaganego atrybutu concept musi być dokładnie taka sama unikalny identyfikator koncepcji. Użyj prawidłowego prefiksu, jeśli dana koncepcja należy do zewnętrznego zaimportowanego zbioru danych.
<metric> Opcjonalnie Definiuje wskaźnik wycinka przez odniesienie do pojęcia. Wartość wymaganego atrybutu concept musi być dokładnie takie samo jak unikalny identyfikator koncepcji. Użyj też prawidłowego prefiksu, jeśli dana koncepcja jest odpowiednia, do zewnętrznego zaimportowanego zbioru danych.
<table> Tak Identyfikuje tabelę danych zawierającą dane dotyczące wycinka. Wartość z wymaganego atrybutu ref musi być zgodny z identyfikatorem tabeli określony w powiązanym elemencie <table>.
<mapDimension> Opcjonalnie Dziecko konta <table>. Zawiera atrybuty concept i toColumn; wartość pierwszego jest a wartością drugiej jest kolumna tabeli analogiczny do poprzedniego.
<mapMetric> Opcjonalnie Dziecko konta <table>. Zawiera atrybuty concept i toColumn; wartość pierwszej to dane w tym wycinku, a wartością drugiej jest kolumna tabeli analogiczny do poprzedniego.

Tabele

Opis

Sekcja tables pliku DSPL zawiera dane znajdujące się w zbiorze danych. Do tych tabel mogą odwoływać się pojęcia lub wycinkami. Każdy element <table> określa kolumny oraz ich typy i wskazuje plik CSV z tabelą. i skalowalnych danych.

Przykład

<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>

Oto jak działa ten przykładowy kod.

  • Ten przykład opisuje tabelę country_slice_table. tabela zawiera kolumny country, year i population
  • Każda kolumna w tabeli ma unikalny identyfikator zdefiniowany przez id. Ten identyfikator musi być identyczny z odpowiednim nagłówka kolumny w powiązanym pliku danych.
  • Wartość opcjonalnego atrybutu type określa dane dla każdej kolumny.
  • Element <data> opisuje rzeczywisty plik .csv (country_slice.csv) zawierający dane do tabeli. Format pliku to zawsze csv.

Elementy

Element Wymagana? Opis
<tables> Tak Element najwyższego poziomu. Obejmuje wszystkie <table> .
<table> Tak Identyfikuje tabelę. Wartość wymaganego atrybutu Wartość id musi być unikalna w tabeli.
<column> Opcjonalnie Dziecko konta <table>. Informacje o kolumnie podane w tabeli. Zawiera te atrybuty:
  • id (wymagany): identyfikator kolumny.
  • type (opcjonalny): typ danych informacji. we określonej kolumnie. Dozwolone wartości to: string, float, integer, date lub boolean.
<data> Opcjonalnie Dziecko konta <table>. Plik danych, do którego odwołuje się funkcja tabeli. Jeśli nazwa pliku ma postać adresu URL (np. http://...), plik zostanie pobrany przez odpowiedni protokół (HTTP, HTTPS lub FTP); w przeciwnym razie plik o tej nazwie musi być w pakiecie ze zbiorem danych. Wartość wymaganego atrybutu format to zawsze csv. Chociaż atrybut encoding jest opcjonalny, pliki .csv muszą mieć kodowanie UTF-8.

Tematy

Opis

Tematy hierarchicznie klasyfikują pojęcia, co pozwala użytkownikom poruszać się po nich i przetwarzanie danych w zbiorze danych.

Element <topics> powinien pojawić się tuż przed tagiem <concepts> w pliku DSPL. (Kolejność elementów są ważne i może nie być możliwe przesłanie zbioru danych, jeśli elementy wyświetlają się w złej kolejności). Aby używać tematów, odwołać się do nich z definicji koncepcji.

Przykład

Oto przykładowa definicja tematu:

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

...a oto przykładowe odniesienie do tego tematu:

<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>

Tematy mogą być zagnieżdżane, a koncepcja może odnosić się do więcej niż jednego tematu.

Definicja elementu

Element Wymagana? Opis
<topics> Tak Element najwyższego poziomu. Obejmuje wszystkie <topic> .
<topic> Tak Identyfikuje temat. Wartość wymaganego atrybutu Identyfikator id musi być unikalny w zbiorze danych.
<info> Opcjonalnie Dziecko konta <topic>. Zawiera informacje na temat temat.
<name> Opcjonalnie Dziecko konta <info>. Jego element podrzędny <value> określa nazwę tematu.

Pliki danych DSPL

Oprócz pliku metadanych XML zbiór danych DSPL może też dołączyć co najmniej jeden plik danych w formacie CSV. Każdy plik danych obsługuje tabelę w zbiorze danych i odwołuje się do niej w <data>...</data>. Zasadniczo te pliki i powiązane z nimi tabele są używane do przedstawiania pojęć definicje lub dane wycinków. Każdy z tych typów plików danych omówiono szczegółowo poniżej.

Pamiętaj, że niezależnie od celu wszystkie pliki danych muszą zostać rozdzielane przecinkami (CSV) pliki tekstowe UTF-8. Pliki muszą zawierać tylko zwykłe pliki tekst; bez kodu HTML. Możesz tworzyć pliki danych ręcznie, ale realnie będzie trzeba masować dane za pomocą narzędzia zawierającego oryginalne dane, źródła (np. w arkuszu kalkulacyjnym) lub w samym wyeksportowanym pliku.

Pliki można połączyć w pakiet ze zbiorem danych lub, jeśli nazwa ma postać Adres URL pobrany ze źródła zdalnego za pomocą protokołu HTTP, HTTPS lub FTP.

Pliki danych pojęć

Pliki danych pojęć zawierają odpowiednie informacje do każdego pojęcia. definicja koncepcji używa elementu <table>, aby się odwoływać ten plik.

Przykład

Oto przykład tabeli zawierającej pojęcie country zdefiniowane powyżej:

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

Oto jak to działa:

  • Jeśli nie określono mapowania, pierwszy wiersz pliku danych (kolumna) nagłówki) musi dokładnie odpowiadać identyfikatorowi elementu i odpowiedniej właściwości identyfikatory koncepcji, z którą są powiązane dane. Jednak orzeczenie kolumny nie muszą być takie same w pliku danych tabeli pojęć. W tym przypadku pierwsza kolumna jest powiązana z pojęcie country, a druga kolumna jest powiązana z usługa name.
  • Kolumny właściwości są opcjonalne. jeśli usługa nie ma kolumny w tabeli, przyjmuje się, że jego wartość jest niezdefiniowana w każdym wierszu. tabeli powyżej, na przykład pomija kolumny dla latitude i longitude, dlatego krajów nie będzie można mapować.
  • Każda wartość w polu identyfikatora elementu (w tym przypadku country) musi być niepowtarzalny i nie może być pusty (puste pole ma wartość 1) bez spacji lub tylko spacji).
  • Wartości właściwości, które odwołują się do innych pojęć, muszą być: puste lub być prawidłową wartością odniesienia.
  • Umieszczenie wartości w cudzysłowach podwójnych jest opcjonalne, chyba że zawierają przecinki, podwójne cudzysłowy lub znaki nowego wiersza.
  • Aby zmienić znaczenie dosłownego cudzysłowu podwójnych, który pojawia się w wartości, poprzedza ją kolejny podwójny cudzysłów.

Pliki z danymi do wycinka

Pliki danych o wycinkach zawierają odpowiednie dane dla każdego wycinka. Wycinek definicja używa elementu <table ref="..."> do odwołują się do definicji <table>, która z kolei określa ten plik.

Przykład

Oto przykładowy plik .csv zawierający dane witryny Wycinek population_by_country opisany powyżej:

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

Oto jak to działa:

  • Pole wskaźnika to population. Pola country i year to pola wymiarów.
  • Żadna z wartości w polu wymiaru nie może być pusta. Obejmuje to czas wymiarów. Wartości pól wskaźników mogą być puste. Pusta wartość to nie jest reprezentowana przez żaden znak.
  • Każdy nagłówek kolumny odwołujący się do danego zagadnienia (na przykład pierwszy powyższego przykładu odwołuje się do koncepcji country) musi dokładnie pasują do unikalnego identyfikatora elementu w definicji pojęć.
  • Unikalna kombinacja wartości wymiarów, np. AF, 2000, może wystąpić tylko raz.
  • Wiersze w tym samym ciągu czasowym (tzn. wiersze zawierające tę samą kombinację) wszystkich wartości wymiarów z wyjątkiem czasu) muszą być zgrupowane razem, ale są one nie są w inny sposób sortowane.

Funkcje zaawansowane

Wielojęzyczne zbiory danych

Przetłumaczone wartości XML

Możesz użyć atrybutu xml:lang z każdym <value> w pliku DSPL. Ten atrybut określa język zawartości elementu za pomocą standardowego algorytmu W3C, . Pamiętaj, że używanie tej funkcji jest opcjonalne. jeśli nie uwzględniono atrybut xml:lang, przyjmuje się, że treść znajduje się w Angielski.

Na poniższym przykładzie pokazano fragmenty zbioru danych w języku angielskim: bułgarski, kataloński i chiński uproszczony:

<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>

Przetłumaczone właściwości

Możesz potrzebować tłumaczeń, które wykraczają poza zakres metadanych na poziomie koncepcji, które mają zastosowanie dodatkowo (lub zamiast) do poszczególnych koncepcji. Jest to szczególnie przydatne, gdy wartości atrybutu właściwość (np. nazwa) różni się w zależności od języka.

Aby podać takie wartości w wielu językach, utwórz jedną kolumnę w odpowiednią tabelę definicji dla każdej kombinacji usługi i języka. Następnie połącz te kolumny z powiązanymi usługami i językami: dodanie do tabeli zestawu elementów <mapProperty xml:lang="..." ref="..." toColumn="..."> dla danej koncepcji.

Oto przykład, który określa pojęcie kraju z nazwami w języku angielskim: hiszpański i francuski:

<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>

Plik CSV z danymi countries_table będzie wtedy zawierał ten formularz:

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

Pojęcia możliwe do mapowania

wiele pojęć (np. „hrabstwo”, „stan” miasta) mają wystąpienia odpowiadające lokalizacji geograficznej. DSPL obsługuje geokodowanie tych instancji, dzięki czemu będzie można je zwizualizować Animowany wykres przedstawiający mapę Google Public Data.

Jeśli pojęcie jest równoważne z krajami świata, stanami USA lub USA możesz dodać link do odpowiedniej strony kanonicznej Google, koncepcja; nie jest wymagane żadne jawne geokodowanie. Więcej informacji znajdziesz w przewodniku po pojęciach kanonicznych. .

Jeśli nie, musisz dodać tę koncepcję do map. Najpierw ustaw rozszerzenie z geo:location:

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

Następnie musisz dodać szerokość i długość geograficzną jako właściwości:

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

Następnie określa się je jako kolumny w odpowiednich tabeli danych definicji pojęć.

Relacje między koncepcjami

Pojęcia często są powiązane z innymi pojęciami w uporządkowany sposób. Dla: np. wystąpienie kontynentu może zawierać wiele krajowych instancji, które z kolei mogą zawierać w poszczególnych stanach lub prowincjach. Kodowanie tych elementów relacje między metadanymi zbioru danych i umożliwiają bogatsze wizualizacje funkcji, niż byłoby to możliwe, np. wyświetlanie zwijanego drzewa z lokalizacji, które można wybrać.

W poniższych sekcjach opisaliśmy relacje powiązane między koncepcjami schemat DSPL.

Hierarchie

Hierarchie koncepcji są reprezentowane w DSPL za pomocą funkcji Atrybut isParent="true" w Tag <property> kategorii podrzędnej, który zawiera identyfikatory instancji z elementu nadrzędnego.

Na przykład koncepcja Google w USA dotyczy ten formularz:

<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>

Tabela danych pomocniczych ma kolumnę state z parametrem dwuliterowy kod stanu dla każdego hrabstwa. Ten typ metadanych pozwala Public Data Explorer wyświetlający stany i hrabstwa w postaci hierarchii, co znacznie ułatwia użytkownikom poznawanie ich możliwości.

Pamiętaj, że koncepcja może mieć wiele elementów potomnych, ale nie więcej niż jedno. Rodzic.

Odwzorowania

Mapowanie koncepcji (tzn. koncepcji, które zasadniczo reprezentują te same rzecz) są reprezentowane przez isMapping="true" w tagu property zmapowanego pojęcia.

Wskazanie, że jeden element jest mapowany na drugi, umożliwia dziedziczenie pierwszego elementu. właściwości i atrybuty obu tych obiektów. Poza innymi aplikacjami przydaje się do „łączenia” osobiste koncepcje geograficzne te zdefiniowane w kanonicznym zbiorze danych geograficznych:

<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>

Rozszerzenia

Rozszerzenia pojęć są określane za pomocą elementu extends w odpowiedniej definicji pojęć. Rozszerzenia są przydatne do wskazywania, że dana koncepcja jest podklasą innej, szerszej koncepcji. koncepcja rozszerzona dziedziczy wszystkie atrybuty i właściwości elementu nadrzędnego, ale możesz też dodać kolejne.

Na przykład koncepcja usługi currency Google rozszerza 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>

Zobacz dyskusję na temat koncepcji w samouczku.

Przesyłanie zbioru danych

Aby przesłać zbiór danych do Google Public Data Explorer, wykonaj te czynności: instrukcje:

  1. Utwórz katalog.
  2. Zapisz plik DSpl zbioru danych w utworzonym przez siebie katalogu. Upewnij się, że: użyj rozszerzenia .xml.
  3. Zapisz wszystkie lokalne pliki .csv w tym samym katalogu. Pliki danych, które są można pominąć.
  4. Skompresuj katalog.
  5. Prześlij zbiór danych do Google Public Data Eksplorator.

Gdy zbiór danych zostanie przesłany i zweryfikowany, możesz go przetestować po zalogowaniu na Twoje konto Google. Nie zostanie opublikowana, dopóki nie zaznaczysz tego pola i daj nam znać, że jest gotowa.