Структурні запити
Огляд
Структурні запити дозволяють отримувати структурні метадані.
Нижче наведено список популярних типів структурних метаданих, які ви зазвичай можете знайти в веб-службах SDMX.
Схеми концептів
: Щоб зрозуміти деякі статистичні дані, нам потрібно знати концепти, пов'язані з ними. Наприклад, саме по собі число 1.2953 є досить беззмістовним, але якщо ми знаємо, що це курс обміну долара США проти євро станом на 23 листопада 2006 року, то це число набуває більше сенсу. Різні концепти зазвичай групуються у збірники, відомі як схеми концептів.Довідники
: Деякі з понять можуть бути довільним текстом (наприклад, коментар до певного значення спостереження), але інші набувають значення з контрольованого словникового списку (наприклад, список країн). Ці списки в SDMX відомі як довідники.Визначення структури даних
: Усі поняття, які описують певну галузь (наприклад, курси обміну або інфляцію), групуються у визначення структури даних (DSD). У DSD поняття поділяються на виміри й атрибути. Поєднані між собою виміри дозволяють унікальним чином ідентифікувати статистичні дані. Водночас атрибути не допомагають ідентифікувати статистичні дані, але додають корисну інформацію (наприклад, одиницю виміру чи кількість десяткових знаків). Для проведення детальних запитів даних потрібно знати поняття, які використовуються як виміри, а також їх дозволені значення (як визначено в довідниках).Бази даних
: Бази даних представляють дані, що охоплюють певну галузь (наприклад, платіжний баланс). База даних надає посилання на визначення структури даних, що застосовується для певної галузі, тим самим вказуючи, як будуть виглядати дані для цієї галузі.
Запити структури в SDMX дозволяють вам отримувати структурні метадані на різних рівнях деталізації, від усіх структурних метаданих, доступних у джерелі, до окремого коду з певної версії певного довідника, який підтримується певною агенцією.
Синтаксис
https://stat.gov.ua/sdmx/workspaces/default:integration/registry/sdmx/3.0/structure/{artefactType}/{agencyID}/{resourceID}/{version}?{detail}&{references}
Для схем елементів допускається використання додаткового параметра шляху (itemID).
https://stat.gov.ua/sdmx/workspaces/default:integration/registry/sdmx/3.0/structure/{artefactType}/{agencyID}/{resourceID}/{version}/{itemID}?{detail}&{references}
Параметр | Тип | Опис | Базове значення | Множинні значення |
---|---|---|---|---|
artefactType | Один із наступних типів: datastructure, metadatastructure, categoryscheme, conceptscheme, codelist, hierarchy, hierarchyassociation, dataflow, metadataflow, structuremap, representationmap, categorisation | Тип структурних метаданих, які мають бути отримані назад. | * | Ні |
agencyID | Рядок, сумісний із SDMX common:NCNameIDType. |
Агенція, що обслуговує повернення артефакта. Можливо встановити більше ніж одну агенцію, використовуючи знак |
* | Так |
resourceID | Рядок, сумісний із SDMX common:IDType | Ідентифікатор артефакта, який має бути повернутий. Можливо встановити більше ніж один ідентифікатор, використовуючи знак , як роздільник (наприклад, CL_FREQ,CL_CONF_STATUS). |
* | Так |
version | Рядок, сумісний із правилами SDMX semantic versioning | Версія артефакта, який має бути повернуто. Можливо встановити більше ніж одну версію, використовуючи знак , як роздільник (наприклад, 1.0.0,2.1.7). |
~ | Так |
іtemID | Рядок, сумісний з SDMX common:NestedNCNameIDType для схеми концептів (conceptscheme) і схеми агенцій (agencyscheme), будь-яким типом переліку значень (valuelist), або з SDMX common:NestedIDType у всіх інших випадках | Ідентифікатор елемента, який має бути повернутий. Можливо встановити більше ніж один ідентифікатор, використовуючи знак , як роздільник (наприклад, A,Q,M). Цей параметр дійсний тільки для схем елементів. |
* | Так |
detail | Рядок | Цей атрибут вказує бажаний обсяг інформації, що має бути повернута. Наприклад, можна надіслати інструкцію веб-службі повернути лише основну інформацію про підтримуваний артефакт (тобто: id, id агенції, версію та назву). На відміну від інших, елементи схем елементів (item schemes) не будуть повернуті (наприклад, вони не повернуть коди у запиті довідника). Можливі значення: (1) full : мають бути повернуті всі доступні дані для всіх повернених артефактів. Повернуті розширені довідники повинні бути розв'язаними, тобто включати всі успадковані коди, і не повинні включати властивість CodelistExtension. Оскільки успадковані довідники мають бути розв'язані, вони не повинні повертатися вдруге як окремі довідники. (2) allstubs : усі повернуті артефакти повинні повертатися як публікації (stubs), тобто містити лише інформацію про ідентифікацію та ім'я артефактів. (3) referencestubs : так само, як і повні (full), за винятком того, що артефакти, на які посилаються, повинні повертатися лише у вигляді публікацій (stubs), тобто містити лише інформацію про ідентифікацію та ім'я артефактів. (4) allcompletestubs : усі повернуті артефакти повинні повертатися як повні короткі публікації (stubs), тобто містити лише інформацію про ідентифікацію, ім'я артефактів, опис та анотацію. (5) referencecompletestubs : так само, як і повні (full), за винятком того, що артефакти, на які покликаються, повинні повертатися як повні короткі публікації (stubs), тобто містити тільки інформацію про ідентифікацію, ім'я артефактів, опис та анотацію. (6) referencepartial : так само, як і повні (full), зі винятком того, що схеми елементів, на які покликаються, повинні включати лише елементи, використані артефактом для повернення. Наприклад, схема понять міститиме лише поняття, використані в DSD, і його прапорець isPartial буде встановлено в положення "істина (true)". Так само, якщо базу даних було обмежено, то довідники, на які посилається DSD, на яке посилається база даних, повинні містити лише коди, на які посилається зміст обмеження (content constraint). (7) raw : так само, як і повні (full), за винятком того, що повернуті розширені довідники - не розв'язані та повинні включати властивість CodelistExtension, і якщо довідники або їх залежності, на які здійснюється посилання, мають бути повернуті, то вони також мають включати всі успадковані довідники. |
full | Ні |
references | Рядок | Цей атрибут наказує веб-службі повертати (або не повертати) артефакти, на які посилається артефакт, що має бути повернутий (наприклад, довідники та концепти, що використовуються визначенням структури даних, що відповідає запиту), а також артефакти, що використовують відповідний артефакт (наприклад, бази даних, що використовують визначення структури даних, яке відповідає запиту). Можливі значення: none (посилання не будуть повернуті), parents (артефакти, які використовують артефакт, що відповідає запиту), parentsandsiblings (артефакти, які використовують артефакт, що відповідає запиту, а також артефакти, на які посилаються ці артефакти), ancestors (артефакти, на які посилається артефакт, що має бути повернений), children ((артефакти, на які посилається артефакт, що має бути повернений), descendants (посилання на посилання, до будь-якого рівня, також будуть повернуті), all (комбінація parentsandsiblings та descendants). Крім того, може бути використаний a concrete type of resource (наприклад, references=codelist). |
none | Так |
Особливості використання itemID
Як вже згадувалося, itemID може бути використаний тільки для запитів схем елементів!
Це такі запити:
- categoryscheme
- conceptscheme
- codelist
Хоча він не відповідає шаблонові схеми елементів, перелік значень також є збірником, а саме - збірником значень.
Якщо встановлено itemID і це ідентифікатор верхнього рівня (наприклад: Code A (Annual) в переліку частот), і такий елемент існує в відповідній схемі елементів, повернута схема елементів повинна містити тільки відповідний елемент, а його параметр isPartial повинен бути встановлений в true.
Якщо встановлено itemID і це вкладений ідентифікатор (наприклад: Category A.1.1, що належить Категорії A.1, яка належить Категорії A в схемі категорій), і такий елемент існує в відповідній схемі елементів, повернута схема елементів повинна містити відповідний елемент та його прецеденти, а його параметр isPartial повинен бути встановлений в true.
Параметр detail дозволяє вказати обсяг деталей, які слід отримати. При використанні itemID повні деталі запрошених елементів є наступними:
- Ідентифікація
- Імена
- Описи
- Анотації
- Інші деталі, крім елементів
Оскільки деталі не зовсім однакові для всіх схем елементів, наступна таблиця надає ці деталі за типом артефакта (@ використовується для атрибутів XML і / для елементів XML).
Елемент (Item) | flat/nested | Деталі запиту елемента (Item Query) |
---|---|---|
Code | flat | @id, @urn, @uri, /Annotations, /Name, /Description, /Parent |
Concept | flat | @id, @urn, @uri, /Annotations, /Name, /Description, /Parent, /CoreRepresentation, /ISOConceptReference |
Agency | flat | @id, @urn, @uri, /Annotations, /Name, /Description, /Contact |
DataProvider | flat | @id, @urn, @uri, /Annotations, /Name, /Description, /Contact |
DataConsumer | flat | @id, @urn, @uri, /Annotations, /Name, /Description, /Contact |
OrganisationUnit | flat | @id, @urn, @uri, /Annotations, /Name, /Description, /Parent, /Contact |
Category | nested | @id, @urn, @uri, /Annotations, /Name, /Description |
ReportingCategory | nested | @id, @urn, @uri, /Annotations, /Name, /Description, /StructuralMetadata, /ProvisioningMetadata |
Хоча більшість схем елементів є пласкими (flat), тому вищенаведену таблицю легко інтерпретувати, для схем категорій та звітних таксономій (які мають вкладену структуру) вищенаведена таблиця вказує, що жоден дочірній елемент(и) запитаного елемента(ів) не повинен бути включений в запит елемента.
Крім того, механізм розв'язування посилань буде застосований до всіх повернутих елементів. Наприклад, запитання категорії, яка має двох прецедентів у ієрархії схеми категорій, призведе до повернення трьох категорій (запитаної та її прецедентів), а також усіх посилань на ці три категорії.
Застосування і значення посилань (включно з referencepartial)
Таблиця нижче перераховує артефакти 1-го рівня (один рівень вгору, один рівень вниз), які будуть повернуті, якщо параметр посилань встановлено на all. Артефакти, на які посилається відповідний артефакт, відображаються звичайним стилем, артефакти, що посилаються на відповідний артефакт, відображаються курсивом, а артефакти, які можуть посилатися самі та на які може посилатися відповідний артефакт, відображаються жирним курсивом.
Підтримуваний артефакт | Повернені артефакти |
---|---|
Categorisation | Усі, HierarchyAssociation, Metadataflow, MetadataProvisionAgreement, Process |
CategoryScheme | AgencyScheme, Categorisation, CategorySchemeMap, Metadataflow, MetadataProvisionAgreement, Process |
Codelist | AgencyScheme, Categorisation, Codelist, ConceptScheme, DataStructureDefinition, Hierarchy, HierarchyAssociation, Metadataflow, MetadataProvisionAgreement, MetadataStructureDefinition, Process, RepresentationMap, VtlMappingScheme |
ConceptScheme | AgencyScheme, Categorisation, Codelist, ConceptSchemeMap, DataStructureDefinition, HierarchyAssociation, Metadataflow, MetadataProvisionAgreement, MetadataStructureDefinition, Process, VtlMappingScheme |
Dataflow | AgencyScheme, Categorisation, DataConstraint, DataStructureDefinition, HierarchyAssociation, Metadataflow, MetadataProvisionAgreement, Process, ProvisionAgreement, ReportingTaxonomy, StructureMap, VtlMappingScheme |
DataStructureDefinition | AgencyScheme, Categorisation, Codelist, ConceptScheme, DataConstraint, Dataflow, HierarchyAssociation, Metadataflow, MetadataProvisionAgreement, MetadataStructureDefinition, Process, StructureMap, ValueList |
Hierarchy | AgencyScheme, Categorisation, Codelist, HierarchyAssociation, Metadataflow, MetadataProvisionAgreement, Process |
HierarchyAssociation | Усі, Categorisation, Metadataflow, MetadataProvisionAgreement, Process |
Metadataflow | Усі, Categorisation, HierarchyAssociation, MetadataConstraint, Metadataflow, MetadataProvisionAgreement, Process, ReportingTaxonomy |
MetadataStructureDefinition | AgencyScheme, Categorisation, Codelist, ConceptScheme, DataStructureDefinition, HierarchyAssociation, MetadataConstraint, Metadataflow, MetadataProvisionAgreement, Process, ValueList |
RepresentationMap | AgencyScheme, Categorisation, Codelist, HierarchyAssociation, Metadataflow, MetadataProvisionAgreement, Process, ValueList |
StructureMap | AgencyScheme, Categorisation, Dataflow, DataStructureDefinition, HierarchyAssociation, Metadataflow, MetadataProvisionAgreement, Process |
Також, при поверненні тільки часткових посилань (за допомогою referencepartial), фільтрування застосовується до будь-якої залежності, незалежно від її рівня.
Таблиця нижче описує вплив використання referencepartial на посилання на схеми елементів.
Підтримуваний артефакт | Значення detail=referencepartial |
---|---|
CategoryScheme | Тільки категорії, на які посилаються повернуті категоризації або набори структур (structure sets), повинні бути включені в повернуті схеми категорій. |
Codelist | Тільки коди, на які посилаються повернені категоризації, обмеження даних/метаданих, ієрархії або набори структур (structure sets), повинні бути включені в повернені довідники. |
ConceptScheme | Тільки концепти, на які посилаються повернуті категоризації, визначення структури даних, визначення структури метаданих або набори структур (structure sets), повинні бути включені в повернуті схеми концептів. |
Наприклад, база даних посилається лише на визначення структури даних, і, крім того, на нього можуть посилатися одне або кілька обмежень даних. У випадку, якщо для параметра references встановлено значення all, а для параметра detail - значення referencepartial, до повернутих схем елементів слід застосовувати наступне:
- Схема(и) понять повинні включати тільки поняття, на які посилається структура даних, на яку посилається цільовий потік даних;
- Перелік(и) кодів повинен включати тільки коди, на які посилаються обмеження даних, що посилаються на цільовий потік даних;
Типи відповідей
Наступні типи медіа можуть бути використані зі структурними запитами :
- application/vnd.sdmx.structure+json;version=2.0.0
- application/vnd.sdmx.structure+json;version=1.0.0
- application/vnd.sdmx.structure+xml;version=3.0.0
- application/vnd.sdmx.structure+xml;version=2.1
Базовий (default) формат виділений жирним.
Приклади запитів
-
Щоб отримати версію 1.0.0 з DSD з id DSD_SCIENTIFIC_RESEARCH_DEVELOPMENT, що підтримується за допомогою агенції SSSU (Держстат), а також довідники і концепти, що використовуються в DSD:
-
Щоб отримати останню стабільну версію DSD з id DSD_SCIENTIFIC_RESEARCH_DEVELOPMENT, що підтримується за допомогою SSSU, а також довідники і концепти, що використовуються в DSD:
-
Щоб отримати останню версію всіх DSD, що підтримується за допомогою SSSU, а також бази даних, які використовують ці DSDs:
-
Щоб отримати останню версію всіх переліків кодів, що підтримуються всіма агентствами, але без кодів:
-
Щоб отримати в якості фрагментів останню версію всіх підтримуваних артефактів, що підтримуються SSSU:
-
Щоб отримати категорію AGRICULTURE_FORESTRY_AND_FISHERIES схеми категорій PORTAL_DEFAULT_HIERARCHY що підтримується за допомогою SSSU, а також категоризації, що посилаються на цю категорію:
-
Щоб отримати останню версію довідників CL_FREQ підтримуваних за допомогою SSSU або SDMX:
Запити на доступність даних
Огляд
Запити на доступність дозволяють бачити, які дані доступні для структури (структури даних, бази даних або угоди про надання), на основі запиту даних. Він повертає DataConstraint, тобто структурні метадані, а тому він подібний до інших запитів структурних метаданих, але сам по собі цей запит більш подібний до запиту даних.
Синтаксис
https://stat.gov.ua/sdmx/workspaces/default:integration/registry/sdmx/3.0/availability/{context}/{agencyID}/{resourceID}/{version}/{key}/{componentId}?{c}&{updatedAfter}&{references}&{mode}
Параметр | Tип | Опис |
Базове значення
|
Множинність значень?
|
---|---|---|---|---|
context | Одне з: datastructure , dataflow , provisionagreement |
Дані можуть надаватися за структурою даних, базою даних або угодою про надання. Цей параметр дозволяє вибрати бажаний контекст для отримання даних. | * | Ні |
agencyID | Рядок, сумісний із SDMX common:NCNameIDType | Агенція, що підтримує артефакт, для якого були надані дані. | * | Так |
resourceID | Рядок, сумісний із SDMX common:IDType | Ідентифікатор артефакту, для якого були надані дані. | * | Так |
version | Рядок, сумісний із VersionType визначеним у специфікації SDMX Open API | Версія артефакту, для якого були надані дані. | * | Так |
key | Рядок, сумісний із KeyType визначеним у специфікації SDMX Open API specification. | Комбінація значень вимірів, які ідентифікують зріз куба, для якого повинні бути повернуті дані. Підтримується за допомогою оператора * . Наприклад, якщо ключ D.USD.EUR.SP00.A ідентифікує двосторонній обмінний курс для щоденного обмінного курсу долара США проти євро, тоді для отримання даних для всіх валют проти євро може бути використаний ключ: D.*.EUR.SP00.A |
* | Так |
componentId | Рядок, сумісний із SDMX common: IDType | Ідентифікатор виміру, для якого потрібно отримати інформацію про доступність. У разі, якщо така інформація не надається, інформація про доступність даних буде надана для всіх вимірів. | * | Так |
c | Мапа (Map) | Фільтруйте дані за значенням компонента. Наприклад, якщо структура визначає вимір частоти (FREQ)у, і код A (Annual) є допустимим значенням для цього виміру, для отримання річних даних можна використовувати: c[FREQ]=A . Те ж саме стосується атрибутів (наприклад, c[CONF_STATUS]=F ) та мір. Кілька значень підтримуються при використанні коми (,) як роздільника: c[FREQ]=A,M . У випадку використання атрибутів, які підтримують кілька значень, можна використовувати плюс (+) для переліку всіх значень, які повинен мати атрибут. Наприклад, щоб вказати, що ATTR1 повинен бути або A, або (B AND M), використовуйте наступне:c[ATTR1]=A,B+M . Також можна використовувати оператори (див. таблицю з операторами нижче). Цей параметр можна використовувати додатково, або замість, параметра шляху key . Цей параметр можна використовувати кілька разів (наприклад, c[FREQ]=A,M&c[CONF_STATUS]=F ) |
Так | |
updatedAfter | xs:dateTime | Останній час виконання запиту клієнтом. Якщо використовується цей атрибут, повернене повідомлення повинно включати значення вимірів для даних, які змінилися з того часу (оновлення та ревізії). Це повинно включати значення вимірів для даних, які були додані з моменту останнього виконання запиту (INSERT), даних, що були змінені з моменту останнього виконання запиту (UPDATE) та даних, що були видалені з моменту останнього виконання запиту (DELETE). Якщо зміщення не вказано, за замовчуванням встановлюється місцевий час веб-сервісу. | Ні | |
references | Рядок | Цей атрибут наказує веб-сервісу повертати (або не повертати) артефакти, на які посилається DataConstraint, який повертається. Можливі значення: "codelist", "datastructure", "conceptscheme", "dataflow", "dataproviderscheme", "none", "all". Ключове слово "all" використовується, щоб вказати на включення dataflow, datastructure, conceptschemes, dataproviderschemes та codelists. Зауважте, що у разі, якщо повертаються ItemSchemes (тобто Codelists, ConceptSchemes та DataProviderSchemes), будуть включені лише елементи, що використовуються DataConstraint (тобто концепти, що використовуються обмеженими вимірами; коди, для яких доступні дані; провайдери даних, які надали доступні дані відповідно до CubeRegion). Додатково для довідників батьківські коди будуть включені в відповідь, якщо дочірні коди перебувають у повернутому довіднику, незалежно від того, чи вони посилаються на DataConstraint. Якщо це призводить до часткового списку, атрибут isPartial буде встановлено в true. | none | Так |
mode | Рядок | Цей атрибут наказує веб-сервісу повертати DataConstraint, який визначає Cube Region, що містить значення, які будуть повернуті виконанням запиту (mode="exact") проти Cube Region, який показує, які значення залишаються дійсними виборами, які можна було б додати до запиту даних (mode="available"). Дійсним вибором є той, який призводить до наявності одного або більше рядів серій (series) для обраного значення, на основі поточного стану вибору запиту даних, визначеного поточними параметрами шляху. | exact | Ні |
Примітка
- Передвстановлені значення (Default values) не потрібно надавати, якщо вони є останнім елементом шляху.
- Оператори можна використовувати для уточнення застосовності параметра запиту
c
.
Oператор | Значення | Примітка |
---|---|---|
eq | Дорівнює | За замовчуванням, якщо оператор не вказаний і є тільки одне значення (наприклад, c[FREQ]=M дорівнює c[FREQ]=eq:M ) |
ne | Не дорівнює | |
lt | Менше ніж | |
le | Менше або дорівнює | |
gt | Більше ніж | |
ge | Більше або дорівнює | |
co | Включає | |
nc | Не включає | |
sw | Починається з | |
ew | Закінчується на |
Оператори з'являються у вигляді префіксу до значень компонентів і відділяються від них двокрапкою :
(наприклад, c[TIME_PERIOD]=ge:2020-01+le:2020-12
).
Як уже згадувалось, відповідь від API доступності даних - це обмеження даних SDMX, яке містить CubeRegion, який визначає різні значення для кожного виміру даних. Ці різні значення, що містяться в CubeRegion, визначаються сервером на основі запиту даних, представленого цьому API. Значення різних значень залежить від режиму відповіді.
Режим відповіді
Відповідь API на запит даних залежить від режиму, з яким викликається API. Режим mode
є параметром запиту до API, і якщо його не надано, за замовчуванням встановлюється точний exact
. Залежно від режиму, повернуті значення представляють або:
- Різні значення, які будуть міститися в результуючому наборі даних, якщо запит даних буде виконаний на запит API даних (mode=exact);
- Дійсні майбутні вибори, які можна було б передати до API даних на основі поточних виборів запиту даних (mode=available).
Щоб підкреслити різницю між режимом відповіді, розгляньте наступний набір даних.
Reference Area
|
Employment Status
|
Sex
|
---|---|---|
UK | EMP | M |
FR | EMP | M |
FR | UEMP | F |
Клієнт викликає API доступності з запитом Reference Area=FR і Sex=F.
У режимі mode=exact
, відповідь буде:
Вимір
|
Значення
|
---|---|
Reference Area | FR |
Employment Status | UEMP |
SEX | F |
У режимі exact знайдено лише одну серію, яка відповідає цьому запиту, і клієнту повернені різні значення за виміром. У цьому випадку є лише одне відмінне значення за виміром.
У режимі mode=available
відповідь буде:
Вимір
|
Значення
|
---|---|
Reference Area | FR |
Employment Status | UEMP |
SEX | M, F |
Режим available визначив, що Великобританія вже не є дійсним вибором. Якщо було обрано Великобританію, дані для цієї області Reference Area не будуть повернені. Якщо користувач додатково включить Employment Status=EMP, це призведе до того, що дані взагалі не будуть повернені. Різниця в цьому режимі полягає в тому, що сервіс визначив, що SEX=M є дійсним вибором, якщо це буде додано до запиту на дані, це призведе до повернення більшої кількості серій.
Якщо користувач додав до свого запиту Sex=M, запит стане Reference Area=FR і Sex=M + F і відповідь зміниться наступним чином.
У режимі mode=exact:
Вимір
|
Значення
|
---|---|
Reference Area | FR |
Employment Status | EMP, UEMP |
SEX | M, F |
Сервіс визначив дві серії, які відповідають критеріям запиту, і відповів різними кодовими значеннями для кожного виміру для цих відповідностей.
У режимі mode=available
:
Вимір
|
Значення
|
---|---|
Reference Area | UK, FR |
Employment Status | EMP, UEMP |
SEX | M, F |
Reference Area UK (Великобританія) тепер стала доступною, тому, якщо користувач зараз вибере Область довідки=UK, то він додасть додаткові серії до відповіді на запит. Крім того, доступні обидва значення Employment Status. Вимір Employment Status у даний час не має виборів запитів, це означає, що на вимір не накладено жодних фільтрів. Сервіс визначив, що користувач може накласти фільтр для EMP або UEMP, і додавання цих фільтрів не призведе до повернення пустого набору даних.
Часове покриття
Для DSD, які мають часовий вимір, тимчасове покриття може бути включено в елемент ReferencePeriod
обмеження даних (DataConstraint). ReferencePeriod
використовується для вказівки найбільш ранніх та найпізніших доступних дат спостереження для підкуба даних на основі поточного запиту даних.
Ця інформація може бути не включена в відповідь, якщо сервіс не має доступу до цієї інформації.
Метрики
DataConstraint
може визначати до двох додаткових анотацій, що використовуються для захоплення метрик кількості серій та кількості спостережень, які будуть повернуті, якщо запит даних, направлений до цього API, було б виконано в окремому запиті до API даних.
Анотації Metrics
прикріплені до DataConstraint
і мають AnnotationType
типу sdmx_metrics
та Id типу series_count
або obs_count
залежно від звітної метрики, і назву анотації використовують для повідомлення кількості, яка є додатним цілим числом.
Метрики включаються лише у випадку, якщо у сервісу є доступна інформація щодо кількості. Запит на метрики може включати лише лічильник серій або жодних метрик взагалі, залежно від сервісу.
Доступність для одиничного виміру
Якщо клієнтська програма цікавиться лише даними, доступними для одного виміру набору даних, наприклад, якщо клієнт створює форму вибору коду лише для виміру "Країна звітування", то клієнт зможе вказати це, використовуючи параметр шляху componentId.
Якщо це так, CubeRegion буде включати лише інформацію про різні значення для вказаного виміру.
Посилання на структури
Клієнт може включити посилання на структури, задіяні обмеженням, використовуючи параметр references
, наприклад, якщо вимір закодовано, а посилання повертаються, список кодів виміру буде включено у відповідь. Важливо, що при цьомй довідник буде включати лише ті коди, які є частиною обмеження.
Включені посилання:
- Dataflow - безпосередньо посилається на обмеження
- Data Structure Definition - посилається на потік даних
- Codelist - які містять лише коди, вказані в обмеженні, з усіма батьківськими кодами, які також включені, навіть якщо вони не включені в обмеження
- Concept Scheme - які містять лише концепції, використовувані обмеженням Data Provider Scheme - які містять виключно провайдерів даних, які надавали дані для потоку даних
Типи відповідей
Наступні типи медіа можуть бути використані з запитами на доступність:
- application/vnd.sdmx.structure+json;version=2.0.0
- application/vnd.sdmx.structure+xml;version=3.0.0
- application/vnd.sdmx.structure+xml;version=2.1
- application/vnd.sdmx.structure+json;version=1.0.0
Базовий формат (default format) за замовчуванням виділено жирним шрифтом.
Приклади
-
Щоб отримати різні значення для кожного виміру для всього потоку даних DF_SCIENTIFIC_RESEARCH_DEVELOPMENT. Також запитується метадані, що використовуються для декодування ідентифікаторів коду та ідентифікаторів концепту у людські читабельні мітки.
-
Для запиту даних RD_EXPEND.UA00000000000000000.*.*._T.BUSIN_SECTOR._T.A, що надається для потоку даних DF_SCIENTIFIC_RESEARCH_DEVELOPMENT, клієнт запитує інформацію про те, які значення виміру залишаються дійсними для включення в запит:
-
Для запиту даних RD_EXPEND.UA00000000000000000.*.*._T.BUSIN_SECTOR._T.A, що надається для потоку даних DF_SCIENTIFIC_RESEARCH_DEVELOPMENT, клієнт запитує інформацію про те, які значення виміру будуть повернуті в результаті виконання запиту:
-
Оскільки exact є значенням за замовчуванням для mode, запит вище можна також записати так:
Типовий випадок використання: виконання запитів через форми запиту даних
Крок 1: Створення форми запиту даних
Форма запиту даних дозволяє користувачам інтерфейсу створювати запити даних до потоку даних, вибираючи виміри та встановлюючи фільтри для виміру. Наприклад, користувач може натиснути 'Країна звітування' і потім вибрати коди 'Великобританія', 'Франція', 'Німеччина'. Мітки кодів представлені на обраній користувачем мові, коли це можливо.
Приклад використання можна підтримати наступним чином:
-
Виконати запит API доступності даних за допомогою запиту на всі дані для бази даних і включити всі посилання:
- Відповідь включає DataConstraint та визначення структури даних. Ми можемо ітерувати виміри, щоб побудувати вибирач вимірів. Для кожного виміру ми можемо отримати концепт, оскільки це надає читабельну для людини мітку (ідеально - на обраній мові, якщо доступно). Обмеження Cube Region надає доступні значення для виміру. Якщо вимір кодується, то довідник можна використати для отримання мітки, читабельної для людини, на обраній мові. Код також надає будь-яку інформацію про ієрархію. Для кожного доступного значення виміру створюється HTML-прапорець.
Крок 2: Оновлення форми запиту даних на основі стану вибору коду
Цей приклад використання, коли деякі значення для вимірів можуть бути відключені або увімкнені для вибору на основі поточного стану запиту. Вибір відключити значення від вибору чи ні ґрунтується на відповіді на питання: Якщо вибрати це значення, чи воно: а) не поверне даних: б) не додасть більше даних?
Розглянемо для прикладу такий набір даних:
Reference Area
|
Employment Status
|
Sex
|
---|---|---|
UK | EMP | M |
FR | EMP | M |
FR | UEMP | F |
- Користувач вибирає
Reference Area=UK
.Employment Status=UEMP
таSex=F
вже не є дійсними виборами. Вибір будь-якого з цих двох кодів, а потім виконання запиту даних не дозволить повернути будь-які дані. - Однак користувач може додати до свого запиту Reference Area=FR. Повторне виконання запиту на доступність призводить до того, що
Employment Status=UEMP
таSex=F
знову стають дійсними виборами, оскільки включення будь-якого з цих значень призведе до повернення даних. - Якщо користувач тепер додає вибір
Sex=F
, тодіReference Area=UK
вже не є дійсним вибором.
Цей користувацький сценарій можна підтримати наступним чином:
-
Коли користувач додає або видаляє фільтр запиту даних, встановлюючи або знімаючи прапорець, викличте Data Availability API з поточним станом запиту даних і
mode=available
. - Відповідь буде включати лише ті значення, які залишаються дійсними виборами. Використовуйте цю інформацію, щоб увімкнути або вимкнути значення виміру.
Бонус: Запобігаємо клієнту виконання запиту даних, який перевищує ліміт сервера
Уявімо ситуацію, коли сервіс встановив ліміт на 2000 серій за запит. Якщо сервіс отримує запит даних, який призводить до повернення більшої кількості серій, то клієнт отримає відповідь про помилку. Ідея полягає в тому, щоб запобігти випадковому запуску запиту від веб-інтерфейсу користувача, який перевищує ліміт, встановлений цією службою.
Цей користувацький сценарій можна підтримати наступним чином:
- Коли користувач додає або видаляє фільтр запиту даних, встановлюючи або знімаючи прапорець, викличте Data Availability API з поточним станом запиту даних. Відповідь буде включати обмеження Cube Region.
- Якщо в обмеження Cube Region є анотація з типом
sdmx_metrics
таId series_count
, отримайте рахунок за допомогою назви анотації. Використовуйте цей рахунок для активування або відключення кнопки "Run Query".
Запити даних
Огляд
Запити даних дозволяють отримувати статистичні дані. Весь набір даних, окремі спостереження, або будь-що проміжне можна отримати, використовуючи фільтри за вимірами (включаючи час), атрибутами та/або мірою. Можна отримати всі дані, які відповідають запиту, або тільки дані, які змінилися з моменту останнього виконання такого самого запиту. Використовуючи параметр includeHistory, також можливо отримати попередні версії даних. Наприкінці, отримані дані можна упакувати різними способами (як часові ряди, перехресні розділи або як таблицю) в різноманітних форматах (JSON, XML, CSV тощо).
Синтаксис
https://stat.gov.ua/sdmx/workspaces/default:integration/registry/sdmx/3.0/data/{context}/{agencyID}/{resourceID}/{version}/{key}?
{c}&{updatedAfter}&{firstNObservations}&{lastNObservations}&{dimensionAtObservation}&{attributes}&{measures}&{includeHistory}
Параметр | Tип | Опис | Базове значення | Множинні значення? |
---|---|---|---|---|
context | Одне з: datastructure , dataflow , provisionagreement |
Дані можуть бути надані відносно структури даних, бази даних або угоди про надання. Цей параметр дозволяє вибрати бажаний контекст для отримання даних. | * | Так |
agencyID | Рядок, сумісний із SDMX common:NCNameIDType | Агенція, що підтримує артефакт, для якого були надані дані. | * | Так |
resourceID | Рядок, сумісний із SDMX common:IDType | Ідентифікатор артефакта, для якого були надані дані. | * | Так |
version | Рядок, дозволеним схемам версіонування SDMX | Версія артефакта, для якого були надані дані. | * | Так |
key | Рядок, сумісний із KeyType визначеним у специфікації SDMX Open API specification. | Комбінація значень вимірів, які ідентифікують зріз куба, для якого повинні бути повернуті дані. Підтримується за допомогою оператора * . Наприклад, якщо ключ D.USD.EUR.SP00.A ідентифікує двосторонній обмінний курс для щоденного обмінного курсу долара США відносно євро, тоді для отримання даних для всіх валют проти євро може бути використаний ключ: D.*.EUR.SP00.A Будь-яке значення виміру, яке пропущено в кінці ключа, вважається еквівалентом символу-замінника, наприклад, D.USD еквівалентно D.USD.* .* .* |
* | Так |
c | Мапа | Фільтрація даних за значенням компонента. Наприклад, якщо структура визначає розмірність частоти (FREQ) та код A (щорічно) є допустимим значенням для цього виміру, для отримання щорічних даних можна використати наступне: c[FREQ]=A. Те ж саме стосується атрибутів (наприклад, c[CONF_STATUS]=F) та мір. Підтримуються кілька значень, використовуючи кому (,) як роздільник: c[FREQ]=A,M . Кома фактично виступає як оператор OR (тобто FREQ є A АБО FREQ є M). Плюс (+) можна використовувати там, де потрібен оператор AND , наприклад, для атрибутів із кількома значеннями або для часових діапазонів. Наприклад, щоб вказати, що ATTR1 повинен бути A або (B AND M), використовуйте: c[ATTR1]=A,B+M . Можна використовувати й оператори (див. таблицю з операторами нижче). Цей параметр можна використовувати додатково або замість параметру шляху key . Цей параметр можна використовувати кілька разів (наприклад, c[FREQ]=A,M&c[CONF_STATUS]=F ), але тільки один раз на компонент. |
Так | |
updatedAfter | xs:dateTime | Це останній час виконання запиту клієнтом у базі даних. Якщо використовується цей параметр, повідомлення, яке повертається, повинно включати тільки останню версію того, що змінилося в базі даних від цього моменту часу (оновлення та ревізії). Вони повинні включати спостереження, які були додані з моменту останнього виконання запиту (INSERT), спостереження, які були переглянуті з моменту останнього виконання запиту (UPDATE) та спостереження, які були видалені з моменту останнього виконання запиту (DELETE). Якщо зміщення не вказано, використовується місцевий час веб-служби. Якщо інформація про те, коли дані було оновлено, недоступна на рівні спостереження, веб-служба повинна повернути або серії, які змінилися (якщо інформація прикріплена на рівні серій), або бази даних, які змінилися (якщо інформація прикріплена на рівні бази даних). | Ні | |
firstNObservations | Додатне ціле число | Це максимальна кількість спостережень, які мають бути повернуті для кожної відповідної серії, починаючи від першого спостереження. | Ні | |
lastNObservations | Додатне ціле число | Це максимальна кількість спостережень, які мають бути повернуті для кожної відповідної серії, рахуючи у зворотному порядку від найновішого спостереження. | Ні | |
dimensionAtObservation | Рядок, сумісний із SDMX common:NCNameIDType | Це ID виміру, який має бути прикріплений на рівні спостереження. Цей параметр дозволяє клієнту вказати, як саме служба має упакувати дані. Опції включають TIME_PERIOD (перегляд даних у вигляді часових рядів timeseries), ID of any other dimension (ID будь-якого іншого виміру), що використовується в цьому потоці даних (перегляд даних у вигляді перехресних розділів cross-sectional) або ключове слово AllDimensions (перегляд даних у вигляді списку/таблиці flat / table, де спостереження не групуються, ані в часових рядах, ані в розділах). У разі, якщо цей параметр не встановлено, від служби очікують за замовчуванням TimeDimension, якщо він є в описі структури даних, або в іншому випадку за замовчуванням AllDimensions. |
Залежно від DSD | Ні |
attributes | Рядок | Цей параметр вказує атрибути, які потрібно повернути. Можливі варіанти: dsd (всі атрибути, визначені в описі структури даних), msd (всі атрибути метаданих посилання), dataset (всі атрибути, прикріплені до рівня набору даних), series (всі атрибути, прикріплені до рівня серії), obs (всі атрибути, прикріплені до рівня спостереження), all (всі атрибути), none (без атрибутів), {attribute_id} : ID одного або декількох атрибутів, якими зацікавлений викликач. |
dsd |
Так |
measures | Рядок | Цей параметр вказує міри, які повинні бути повернуті. Можливі варіанти: all (всі міри), none (немає міри), {measure_id} : ID однієї або декількох мір, якими зацікавлений викликач. |
all |
Так |
includeHistory | Булевий | Цей параметр дозволяє отримувати попередні версії даних, так як вони були поширені в минулому (функціонал історії history або часової шкали timeline). Коли значення встановлено як true, повідомлення про повернені дані повинно містити один або два набори даних для кожного розповсюдження даних, залежно від того, чи були видалені спостереження з джерела даних під час розповсюдження. Атрибути validFromDate та/або validToDate набору даних слід використовувати для вказівки періодів дії даних, що містяться в наборі даних. Див. нижче приклад використання параметра includeHistory. |
false |
Ні |
Застосовуються наступні правила:
- Декілька значень для параметра мають бути розділені комою (,).
- Для параметра версії підтримуються два додаткові оператори:
+
, що вказує на останню стабільну версію артефакту, та~
, що вказує на останню версію артефакту, незалежно від його статусу (чернетка чи стабільна версія). - Значення за замовчуванням не потрібно надавати, якщо вони є останнім елементом шляху.
- Оператори можна використовувати для уточнення застосування параметра запиту
c:
Оператор
|
Значення
|
Примітка
|
---|---|---|
eq | Дорівнює | Якщо оператор не вказано та вказане тільки одне значення, за замовчуванням використовується оператор рівності (eq). Наприклад, c[FREQ]=M еквівалентно c[FREQ]=eq:M. |
ne | Не дорівнює | |
lt | Менше ніж | |
le | Менше або дорівнює | |
Більше ніж | ||
ge | Більше або дорівнює | |
co | Містить | |
nc | Не містить | |
sw | Починається з | |
ew | Закінчується на |
Оператори виступають у якості префікса до значень компонентів і від них відокремлюються двокрапкою (:). Наприклад, c[TIME_PERIOD] = ge: 2020-01 + le: 2020-12.
Типи відповідей
Наступні типи медіа можуть бути використані зі запитами даних:
- application/vnd.sdmx.data+json;version=2.0.0
- application/vnd.sdmx.data+xml;version=3.0.0
- application/vnd.sdmx.data+csv;version=2.0.0;labels=[id|name|both];timeFormat=[original|normalized];keys=[none|obs|series|both]
- application/vnd.sdmx.genericdata+xml;version=2.1
- application/vnd.sdmx.structurespecificdata+xml;version=2.1
- application/vnd.sdmx.generictimeseriesdata+xml;version=2.1
- application/vnd.sdmx.structurespecifictimeseriesdata+xml;version=2.1
- application/vnd.sdmx.data+json;version=1.0.0
- application/vnd.sdmx.data+csv;version=1.0.0;labels=[id|both];timeFormat=[original|normalized]
Базовий (default) формат виділений жирним.
SDMX-CSV пропонує можливість встановити значення для двох параметрів через медіа-тип. Ці параметри - label
і timeFormat
; обидва є необов'язковими. Значення за замовчуванням для цих параметрів позначені * в указаному вище медіа-типі (тобто id
та original
відповідно). Для додаткової інформації про ці параметри, будь ласка, зверніться до специфікації SDMX-CSV specification.
Приклади запитів
-
Отримати дані, що відповідають наданим параметрам шляху:
-
Отримати дані, що відповідають наданим параметрам шляху, і, для атрибутів, отримувати тільки SCALE та UNIT_OF_MEASURE:
-
Отримати дані, що відповідають наданим шаблонам шляху, включаючи кілька версій та символ-замінник для другого виміру:
-
Отримати дані, що відповідають наданим шаблонам шляху (включаючи кілька ключів та останню стабільну версію):
-
Отримати публічні дані, що відповідають наданим шаблонам шляху (всі дані, звітовані за останню версію потоку даних SSSU DF_SCIENTIFIC_RESEARCH_DEVELOPMENT), і що попадають між наданими початковим та кінцевим періодами:
-
Отримати список індикаторів по Україні (UA00000000000000000), доступних у джерелі:
-
Отримати перелік спостережень, що відповідають наданим шаблонам шляху, і що перебувають вище певного порогу:
-
Отримати список індикаторів, що містять слово Number в їхньому заголовку:
-
Отримати диференціювання (дельту) за допомогою параметра
updatedAfter
:Надавши відсоткове кодування часу до параметра
updatedAfter
, можливо отримати тільки останню версію змінених значень у базі даних із певного моменту часу (так звані оновлення та ревізії або дельти).
Розробники, які оновлюють свої локальні бази даних, повинні використовувати параметр updatedAfter
, оскільки це, ймовірно, значно покращить продуктивність. Замість систематичного завантаження даних, які можуть не змінюватися, ви отримаєте лише сконсолідовані зміни, які слід зробити у вашій базі даних із моменту останнього виконання того самого запиту вашим клієнтом.
Альтернативою, менш ефективною, ніж описане вище рішення, але ефективнішою, ніж постійне завантаження всього, може бути використання HTTP Conditional GET запитів (тобто заголовків HTTP Request If-Modified-Since
або If-None-Match
). Використовуючи цей механізм, все буде повернуто, але лише за умови, що щось змінилося відносно попереднього запиту.
Зразок повідомлення відповіді наведено нижче. У відповіді важливим є атрибут action
елемента Dataset
, тоді як validFromDate
є просто інформаційною складовою.
<?xml version="1.0" encoding="UTF-8"?> <message:GenericData xmlns:message="http://www.sdmx.org/resources/sdmxml/schemas/v2_1/message" xmlns:common="http://www.sdmx.org/resources/sdmxml/schemas/v2_1/common" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:generic="http://www.sdmx.org/resources/sdmxml/schemas/v2_1/data/generic" xsi:schemaLocation="http://www.sdmx.org/resources/sdmxml/schemas/v2_1/message http://sdw-wsrest.ecb.europa.eu:80/vocabulary/sdmx/2_1/SDMXMessage.xsd http://www.sdmx.org/resources/sdmxml/schemas/v2_1/common http://sdw-wsrest.ecb.europa.eu:80/vocabulary/sdmx/2_1/SDMXCommon.xsd http://www.sdmx.org/resources/sdmxml/schemas/v2_1/data/generic http://sdw-wsrest.ecb.europa.eu:80/vocabulary/sdmx/2_1/SDMXDataGeneric.xsd"> <message:Header> <message:ID>388d1c9a-d187-4f6a-8792-e117cf34047f</message:ID> <message:Test>false</message:Test> <message:Prepared>2016-12-20T16:19:56.398+01:00</message:Prepared> <message:Sender id="ECB"/> <message:Structure structureID="ECB_RTD1" dimensionAtObservation="TIME_PERIOD"> <common:Structure> <URN>urn:sdmx:org.sdmx.infomodel.datastructure.DataStructure=ECB:ECB_RTD1(1.0)</URN> </common:Structure> </message:Structure> </message:Header> <message:DataSet action="Replace" validFromDate="2016-12-20T16:19:56.398+01:00" structureRef="ECB_RTD1">[...]</message:DataSet> <message:DataSet action="Delete" validToDate="2016-12-20T16:19:56.440+01:00" structureRef="ECB_RTD1">[...]</message:DataSet> </message:GenericData>
-
Отримання обмеженої кількості спостережень за допомогою параметрів
firstNObservations
таlastNObservations:
Використовуючи параметри firstNObservations
та/або lastNObservations
, можна вказати максимальну кількість спостережень, які повинні бути повернуті для кожної з відповідних серій, починаючи від першого спостереження (firstNObservations
) або відлік від найновішого спостереження (lastNObservations
). Це може бути корисним для створення сторінки-огляду, де, наприклад, для кожного індикатора ви відображаєте лише 2 значення (поточне та попереднє).
-
Перегляд розвитку часового ряду за часом за допомогою параметра
includeHistory:
Використовуючи параметр includeHistory
, ви можете вказати веб-службі повернути попередні версії співставних даних. Це корисно для перегляду розвитку даних протягом часу, тобто коли були випущені нові дані або коли дані були відкориговані або видалені. Можливі варіанти:
false:
Буде повернуто тільки версію, яка зараз введена в роботу. Це є значенням за замовчуванням.true:
Буде повернуто версію, яка зараз введена в роботу, а також всі попередні версії. Такий запит дасть вам історію між цією точкою в часі та сьогоднішнім днем.
Нижче надано зразок повідомлення-відповіді. У відповіді важливі як атрибут action
, так і атрибут validFromDate
елемента Dataset
. У той час як атрибут action
вказує, що потрібно зробити, атрибут validFromDate
дозволяє визначити періоди дії звітованих даних.
<?xml version="1.0" encoding="UTF-8"?> <message:GenericData xmlns:message="http://www.sdmx.org/resources/sdmxml/schemas/v2_1/message" xmlns:common="http://www.sdmx.org/resources/sdmxml/schemas/v2_1/common" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:generic="http://www.sdmx.org/resources/sdmxml/schemas/v2_1/data/generic" xsi:schemaLocation="http://www.sdmx.org/resources/sdmxml/schemas/v2_1/message http://sdw-wsrest.ecb.europa.eu:80/vocabulary/sdmx/2_1/SDMXMessage.xsd http://www.sdmx.org/resources/sdmxml/schemas/v2_1/common http://sdw-wsrest.ecb.europa.eu:80/vocabulary/sdmx/2_1/SDMXCommon.xsd http://www.sdmx.org/resources/sdmxml/schemas/v2_1/data/generic http://sdw-wsrest.ecb.europa.eu:80/vocabulary/sdmx/2_1/SDMXDataGeneric.xsd"> <message:Header> <message:ID>a2c99026-00c8-4f9a-a3d4-1891f89bd2b0</message:ID> <message:Test>false</message:Test> <message:Prepared>2016-12-20T17:16:51.578+01:00</message:Prepared> <message:Sender id="ECB"/> <message:Structure structureID="ECB_RTD1" dimensionAtObservation="TIME_PERIOD"> <common:Structure> <URN>urn:sdmx:org.sdmx.infomodel.datastructure.DataStructure=ECB:ECB_RTD1(1.0)</URN> </common:Structure> </message:Structure> </message:Header> <message:DataSet action="Replace" validFromDate="2014-12-03T15:30:00.000+01:00" structureRef="ECB_RTD1">[...]</message:DataSet> <message:DataSet action="Replace" validFromDate="2015-06-02T15:30:00.000+02:00" structureRef="ECB_RTD1">[...]</message:DataSet> <message:DataSet action="Replace" validFromDate="2015-10-21T15:30:00.000+02:00" structureRef="ECB_RTD1">[...]</message:DataSet> <message:DataSet action="Replace" validFromDate="2016-06-01T15:30:00.000+02:00" structureRef="ECB_RTD1">[...]</message:DataSet> <message:DataSet action="Delete" validToDate="2014-11-05T15:30:00.000+01:00" structureRef="ECB_RTD1">[...]</message:DataSet> </message:GenericData>
Запити метаданих
За набором метаданих
Огляд
Ці запити дозволяють клієнтам знаходити бази метаданих за ідентифікацією бази метаданих, дозволяючи клієнтам отримувати конкретні звіти.
Синтаксис
https://stat.gov.ua/sdmx/workspaces/default:integration/registry/sdmx/3.0/metadata/metadataset/{providerID}/{metadatasetID}/{version}?{detail}
Параметр | Tип | Опис | Базове значення | Множинні значення? |
---|---|---|---|---|
providerID | Рядок, сумісний з SDMX common:NestedNCNameIDType для MetadataProvider | Id постачальника даних, який підтримує набір метаданих. Можна встановити більше ніж один id, використовуючи , як роздільник (наприклад, UK1,UK2) | * | Так |
metadatasetID | Рядок, сумісний з SDMX common:NestedNCNameIDType для MetadataSet | Id набору метаданих, що повертається. Можна встановити більше ніж один id, використовуючи , як роздільник (наприклад, MS1,MS2) | * | Так |
version | Рядок, сумісний з SDMX semantic versioning rules | Версія артефакту, що повертається. Можна встановити більше ніж одну версію, використовуючи , як роздільник (наприклад, 1.0.0,2.1.7). |
* | Так |
detail | Рядок | Цей атрибут визначає бажану кількість інформації, яка повинна бути повернута. Наприклад, можна доручити веб-службі повертати лише основну інформацію про набір метаданих (тобто: id, id постачальника даних, версію та ім'я). На відміну від іншого, атрибути метаданих набору метаданих не будуть повертатися. Можливі значення: (1) full: повна доступна інформація для всіх повернених наборів метаданих повинна бути повернута. (2) allstubs : всі повернуті набори метаданих повинні бути повернуті як описи, тобто містити тільки інформацію про ідентифікацію та ім'я набору метаданих. |
full | Ні |
Примітка:
- Якщо встановлені за замовчуванням значення є останнім елементом шляху, вказувати їх не потрібно.
Приклади
Щоб отримати версію 1.0.0 метаданих з id QUALITY_REPORT, що підтримується SSSU:
Щоб отримати всі метадані, які підтримує ЄЦБ, без атрибутів повідомлених метаданих:
За базою метаданих
Огляд
Ці запити дозволяють клієнтам знаходити набори метаданих за допомогою збірки (бази метаданих), які постачальник метаданих, за бажанням, може відфільтрувати.
Синтаксис
https://stat.gov.ua/sdmx/workspaces/default:integration/registry/sdmx/3.0/metadata/metadataflow/{flowAgencyID}/{flowID}/{flowVersion}/{providerRef}?{detail}
Параметр | Tип | Опис | Базове значення | Множинні значення? |
---|---|---|---|---|
flowAgencyID | Рядок, сумісний з SDMX common:NCNameIDType | Агенція, що підтримує базу метаданих, для якої були повідомлені метадані. | * | Так |
flowID | Рядок, сумісний з SDMX common:IDType | ID бази метаданих, для якої були повідомлені метадані. | * | Так |
flowVersion | Рядок, сумісний з VersionType визначеним у специфікації SDMX Open API | Версія бази метаданих, для якої були повідомлені метадані. | * | Так |
providerRef | Рядок, що ідентифікує постачальника метаданих. Синтаксис включає id агентства, id постачальника, розділені через "," . Наприклад: AGENCY_ID,PROVIDER_ID. У випадку, якщо рядок містить лише один із цих 2 елементів, вважається, що це id постачальника, тобто all,PROVIDER_ID. |
Постачальник даних (або метаданих), які потрібно отримати. Якщо не вказано, повернене повідомлення буде містити дані (або метадані), надані будь-яким постачальником. Загальним випадком використання у веб-службах, що базуються на SDMX, є те, що ідентифікатор постачальника - достатній для унікальної ідентифікації постачальника даних. Якщо це не так, можна використовувати агенцію разом із ідентифікатором постачальника, щоб унікально ідентифікувати постачальника даних. Підтримується оператор OR за допомогою символа +. Наприклад, таке значення можна використовувати, щоб вказати, що метанабір даних повинен надати Швейцарський національний банк (CH2) або Центральний банк Норвегії (NO2): CH2+NO2 . | * | Так |
detail | Рядок | Цей атрибут визначає бажану кількість інформації, яка повинна бути повернута. Наприклад, можливо доручити веб-службі повертати лише основну інформацію про набір метаданих (тобто: id, id постачальника даних, версію та ім'я). Найбільш помітно, атрибути метаданих набору метаданих не будуть повернуті. Можливі значення: (1) full : повна доступна інформація для всіх повернених наборів метаданих повинна бути повернута. (2) всі описи: всі повернуті набори метаданих повинні бути повернуті як описи, тобто містити тільки інформацію про ідентифікацію та ім'я набору метаданих. |
full | Ні |
Примітка:
- Якщо встановлені за замовчуванням значення є останнім елементом шляху, вказувати їх не потрібно.
Приклади
Щоб отримати всі метадатасети, повідомлені центральним банком Франції (FR2), щодо потоку метаданих SSSU METHODOLOGY (будь-якої версії)
Щоб отримати метадатасети від всіх постачальників метаданих, для останньої стабільної версії потоку метаданих METHODOLOGY, без повідомлених атрибутів метаданих
За структурою
Огляд
Ці запити дозволяють клієнтам запитувати всі набори метаданих, які повідомляються для однієї чи кількох структур, отже, синтаксис для визначення, для яких структур знайти метадані, відповідає синтаксису ресурсу структури.
Синтаксис
https://stat.gov.ua/sdmx/workspaces/default:integration/registry/sdmx/3.0/metadata/structure/{artefactType}/{agencyID}/{resourceID}/{version}?{detail}
Параметр | Tип | Опис | Базове значення | Множинні значення? |
---|---|---|---|---|
Параметр | Tип | Опис | Базове значення | Множинні значення? |
Type | Один із: datastructure, metadatastructure, categoryscheme, conceptscheme, codelist, hierarchy, hierarchyassociation, valuelist, organisationscheme, agencyscheme, dataproviderscheme, dataconsumerscheme, organisationunitscheme, dataflow, metadataflow, reportingtaxonomy, provisionagreement, structuremap, representationmap, conceptschememap,categoryschememap, organisationschememap, process, categorisation, dataconstraint, metadataconstraint, transformationscheme, rulesetscheme, userdefinedoperatorscheme, customtypescheme, namepersonalisationscheme, vtlmappingscheme | Тип структурних метаданих, які мають бути отримані назад. | * | Ні |
agencyID | Рядок, сумісний із SDMX common:NCNameIDType | Агенція, що обслуговує повернення артефакта. Можливо встановити більше ніж одну агенцію, використовуючи знак , як роздільник (наприклад, BIS,ECB). |
* | Так |
resourceID | Рядок, сумісний із SDMX common:IDType | Ідентифікатор артефакта, який має бути повернутий. Можливо встановити більше ніж один ідентифікатор, використовуючи знак , як роздільник (наприклад, CL_FREQ,CL_CONF_STATUS). |
* | Так |
version | Рядок, сумісний із SDMX semantic versioning rules | Версія артефакта, який має бути повернуто. Можливо встановити більше ніж одну версію, використовуючи знак , як роздільник (наприклад, 1.0.0,2.1.7). |
~ | Так |
detail | Рядок | Цей атрибут вказує бажану кількість інформації, яка має бути повернута. Наприклад, можна дати вказівку веб-сервісу повертати лише основну інформацію про набір метаданих (тобто: ідентифікатор, ідентифікатор провайдера даних, версію та назву). Найважливіше, що атрибути метаданих набору метаданих не будуть повернуті. Можливі значення: (1) full : уся доступна інформація для всіх повернутих наборів метаданих має бути повернута. (2) allstubs всі повернуті набори метаданих мають бути повернуті як описи, тобто містити лише інформацію для ідентифікації та назву набору метаданих. |
full | Ні |
Приклади
-
Щоб отримати набори метаданих для версії DSD 1.0.0 з id
METADATA
, що підтримується SSSU, а також довідники і концепти, що використовуються в DSD: -
Щоб отримати набори метаданих для останньої версії DSD з id
METADATA
, що підтримується SSSU, без довідників і концептів, що використовуються в DSD: -
Щоб отримати набори метаданих для будь-якої DSD , що підтримується SSSU (останньої версії), так само, як бази даних, що використовують ці DSDs:
-
Щоб отримати набори метаданих (як описи) для будь-якої баз даних Dataflow:
Типи відповідей
Наступні типи медіа можуть бути використані з запитами на отримання відправних метаданих:
- application/vnd.sdmx.metadata+json;version=2.0.0
- application/vnd.sdmx.metadata+xml;version=3.0.0
- application/vnd.sdmx.metadata+csv;version=1.0.0
- application/vnd.sdmx.genericmetadata+xml;version=2.1
- application/vnd.sdmx.structurespecificmetadata+xml;version=2.1
Базовий (default) формат виділений жирним.