Architektúra verejnej správy

Stretnutie

Architecture Review Board

Dátum stretnutia

10.01.2023

Miesto stretnutia

MS Teams

Vypracoval

Anton Svetlošák

Prítomní:

anton.svetlosak@mirri.gov.sk

vladimir.kovac@mirri.gov.sk

marian.nagy@mirri.gov.sk

Miroslav.liska@mirri.gov.sk

Daniel.mikulka@mirri.gov.sk

Viktoria.sunderlikova@mirri.gov.sk

peter.stavny@slovenskoit.sk

radovan.kulin@slovenskoit.sk

viliam.tokarcik@slovenskoit.sk

peter.zovak@nases.gov.sk

stefan.szilva@nases.gov.sk

lenka.mitakova@nases.gov.sk

1. Zápis zo stretnutia

I

Miroslav Líška, téma:

Na RV projektu OpenData sa schvaľujú výstupy projektu OpenData, prezentácia pre ARB.

1) DCAT-AP-SK2.0 (metadatovy standard pre opendata)

https://datova-kancelaria.github.io/dcat-ap-sk-2.0/

2) Spôsoby automatizovaného katalogizácie lokálnych katalógov (opendata portálov)

Poskytnutie LKODu pre harvestovanie – Metodika pre otvorené údaje (opendata.gov.sk) – Confluence

DCAT-AP-SK2.0 hovorí aké metadata majú mať Otvorené údaje (napr. Dataset, služby, atribúty)

Rovnaké riešenie a štandard sa používa aj v Nórsku – DCAT-AP-NO, Česku – DCAT-AP-CZ, Nemecku – DCAT-AP-DE, Taliansku – DCAT-AP-IT a podobne.

Tento štandard nie je určený len pre národný portál data.gov.sk (NKOD), ale aj pre ostatné portály (LKOD) – opendata.mzv.gov.sk, register priestorových informácií

Existujú metadáta katalógu, datasetu, distribúcie a dátovej služby.

Dôležité je aby všetky portály používali rovnaký štandard. Hlavne pre harvestovanie. Takto sa dostanú všetky datasety na 1 miesto.

Pre harvestovanie sú 2 možnosti:

1. Ukladať súbor s metadátami (katalogizačný súbor, musí to urobiť LKOD)
2. Transformácia všetkých metadát do 1 súboru, nahrám to do RDF databázy a sprístupním SPARQL endpoint

Slovenský štandard je upravený

ODK vypracoval aj metodiku pre sprístupnenie datasetov z LKOD

V starom systéme opendata sa nepracovalo dobre s distribúciou, nedodržiavala sa hlavná podmienka – distribúcie rovnakého datasetu by mali byť rovnaké.

Otázky a odpovede:

Čo sa upravilo na SVK štandarde

• Základ je rovnaký, na národnej úrovni je rozšírenie – preklad a atribúty naviac – atribút typ datasetu, pridanie podmienok použitia

Akú metodiku, štandardy oDK pripravila? Aká je jej vymožiteľnosť.

• Bolo to na PS1, bude sa hlasovať dištančne. Vo vyhláške 78 je DCAT-AP-SK 1.0 a teraz sa chce prejsť na DCAT-AP-SK 2.0
• Zatiaľ sa vydajú len návody pre OVM.

Budú existovať štandardné zoznamy atribútov, ktoré by mali datasety obsahovať?

• Štandard DCAT-AP je len pre metadata. Pre konkrétne datasety je to tzv. Publikačné minimum.

SPARQL endpoint – nie je jednoduché vedieť písať query, nebude dobré nad tým urobiť GUI?

• Je to v pláne do budúcna.

Praktická situácia, keď ide OVM publikovať datasety. OVM má svoju databázu katalóg, alebo ju nemá (posiela do NKOD). Ak má svoju databázu OVM si povie svoju štruktúru. Datasety – súbory (csv, xml) si OVM nechá uložené u seba, metadáta musí sprístupniť pre harvestor.

• LKOD musí exportovať z portálu z CSV a urobí transformáciu do metadát. MIRRI (oDK) s transformáciou pomôže.
• V portáli sa zaregistruje nový katalóg s cestou na SPARQL endpoint.

Na slovensku existujú 2 portály, ktoré chcú čítať dáta z UVO a zobrazovať ich.

• Takto by to mohli sťahovať cez SPARQL. Môžu robiť aj zložitejšie datasety.

Chystá sa aj funkcionalita pre konverziu dát?

• Chystá sa verejné obstarávanie, ktorého súčasťou bude systém pre transformáciu a validáciu datasetov. Hľadá sa spôsob ako to urobiť efektívne s čo najväčšou pridanou hodnotou. Neplánuje sa urobiť univerzálne riešenie.

I

Koexistencia eNotify a PACHO/Innocent

V rámci DNR pre OTS a PAP sa malo zakresliť a zapísať ako sa s tým chcú vysporiadať. Problém, že používateľ si vie nastaviť notifikácie cez eDesk ale aj cez iné kanály. Je potrebné zamedziť tomu aby notifikácie chodili duplicitne.

Pacho by mal byť súčasťou Innocent. Je ambícia kompletne prejsť na Innocent aj pre use case, kde OVM posiela notifikácie (obce), bude to spätne kompatibilné?

Vyhnúť sa aby nové moduly si vytvárali vlastné SKTALK pre účely notifikácií.

Innocent je samostatný produkt. To, že je možné nastavovať notifikácie aj v slovensko.sk neznamená, že ide o duplicitu – prevolá sa API Innocent. Innocent budú slúžiť aj na nastavovanie. Jednotlivé kanály sú push, email, sms. Staré eNotify sa môže zrušiť len ak budeme vedieť presmerovať staré moduly na Innocent. SKIT navrhne migračný plán. Bude vytvorené aj synchrónne aj asynchrónne API. eNotify sa môže vypnúť až keď ho nebudú používať moduly UPVS.

Konsolidácia do 1 správy nemusí dávať vždy zmysel, kvôli zložitosti pre univerzálne riešenie.

Otázky a odpovede:

Budú aj iné spôsoby notifikácií? napr. Na webe zvonček

• Nie, zvonček je len UI nad zoznamom prečítaných/neprečítaných notifikácií. Len preklik do zoznamu notifikácií.

Notifikácia, ktorá príde bude smerovať do správy eDesku?

• Ako prvé sa vytvorí kontextová správa a z nej sa smeruje ďalej (napr. Na portál). V rámci kontextovej správy sú definované akcie, ktoré je možné vykonať.
• Z push sa dostane do kontextovej správy a z kontextovej správy ďalej (napr. Do eDesk). Kontextová správa môže mať nastavené akcie – napr. rovno otvorí eDesk.

I

Bude potrebné, aby SKIT používal správnu konvenciu a názvoslovia. Je potrebné vychádzať z Centrálneho modelu údajov verejnej správy. Link

SKIT pripraví analýzu z ktorej vyplynie ako budú právnické osoby získavať údaje, ktoré im bude posielať OVM. Zároveň bude analyzované ako sa vyvarovať možnosti využívania kontextových sprav na účely, na ktoré nie sú určené.

       2.Otvorené otázky a riziká

2.1

O

V dlhodobom hľadisku chceme eNofify nahradiť s Innocent.

2.2

O

2.3

O

      3.Úlohy

Zodpovedný

Termín

Stav

3.1

U

3.2

U

3.3

U

      4. Závery

4.1

Z

Nenašli sme žiadne závažné nedostatky v návrhu používania DCAT-AP-SK2.0.

4.2

Z

SKIT pripraví HL návrh pre koexistenciu eNotify a Innocent. Návrh by mal obsahovať popis AS IS a TOBE stavu.

4.3

Z