C3V8.pdf

1

C3V8 - Návrh zajištění podpory dokumentace datových sad generované z ontologických konceptuálních datových modelů agend v NKOD

Vytvořeno v rámci projektu

Rozvoj datových politik v oblasti zlepšování kvality a interoperability dat veřejné správy CZ.03.4.74/0.0/0.0/15_025/0013983

Klíčová aktivita: 04: Návrhy a realizace opatření pro zvyšování povědomí o otevřených datech

Indikátor: 8 05 00 Počet napsaných a zveřejněných analytických a strategických dokumentů (vč. evaluačních)

Verze výstupu: 01

2 Návrh zajištění podpory dokumentace datových sad generované z ontologických konceptuálních datových modelů agend v NKOD V tomto dokumentu popisujeme návrh zajištění podpory dokumentace datových sad v NKOD generované z ontologických konce ptuálních datových modelů agend, kterému zde říkáme sémantický slovník pojmů. Návrh úprav NKOD Z Portálu otevřených dat data.gov.cz ze sekce pro poskytovatele dat může vést odkaz na instanci vyvinutého prototypu, která poběží nezávisle na NKOD na serverech MV. Uživatelské rozhraní prototypu V této sekci představujeme uživatelské rozhraní navrženého a implementovaného prototypu. Má tři hlavní část - manažer specifikací, detailní pohled na specifikaci a editor schématu. Manažer specifikací První částí je manažer specifikací. Každá datová sada nebo přepoužitelná část datové sady se zde nazývá specifikace, a může být samostatně editovatelná. Manažer specifikací tedy umožňuje pracovat na více datových sadách (jejich specifikacích) naráz. Níže vidíme screenshot seznamu specifikací dostupných v dané instanci prototypu.

Konkrétní specifikace Pro konkrétní specifikaci prototyp nabízí detailní přehled. Ten obsahuje seznam datových struktur, které budou dokumentovány, a seznam specifikací, které jsou aktuální specifik ací přepoužívané (reused). Pokud specifikace bude obsahovat více datových struktur, budou zde vypsány. Tato obrazovka také obsahuje tlačítko “Generate .zip file”, pomocí kterého se generují veškeré artefakty (dokumentace, schémata).

3

Editor datové struktury Největším detailem je pak editor konkrétní datové struktury. Zde má uživatel možnost vybrat podmnožinu entit sémantického slovníku pojmů a uspořádat ji do hierarchie, ze které bude generována lidsky čitelná dokumentace a JSON schéma. V prázdné specifikaci uživatel nejprve vybere kořen - entitu ze sémantického slovníku pojmů. Následně přidává atributy a ostatní entity za asistence p rototypu dle jejich propojení v sémantickém slovníku pojmů, specifikuje datové typy, technické názvy a kardinality.

4

Výsledkem může být například struktura pro popis Informačního systému veřejné správy, jako na obrázku níže.

5 Výsledná generovaná dokumentace datové sady V této části prezentujeme ukázku výstupních artefaktů generovaných prototypem. Lidsky čitelná dokumentace Dokumentace pro čtení uživateli dat, vývojáři aplikací a dodavateli poskytovatele dat. V úvodu obsahuje grafický přehled dokumentované datové sady generovaný pomocí nástroje PlantUML.

Pro každou položku datové sady pak obsahuje detailní specifikaci - jméno, popis, povinnost, kardinalitu, význam a odkaz do sémantického slovníku pojmů.

6

JSON Schema V této sekci uvádíme úryvek generovaného schématu v jazyce JSON Schema odpovídajícímu části dokumentované datové sady. Toto schéma je možné použít pro validaci dat jak uživateli, tak poskytovateli, například v nástroji JSON Schema Validator , Jim Blackler's JSON tools
nebo Altova XMLSpy.

{ "$schema": "https://json-schema.org/draft/2020-12/schema", "title": "Informační systém veřejné správy", "description": "Informačním systémem veřejné správy funkční celek nebo jeho část zabezpečující cílevědomou a systematickou informační činnost pro účely výkonu veřejné správ y nebo plnění jiných funkcí státu anebo dalších veřejnoprávních korporací. Každý informační systém veřejné správy zahrnuje data, která jsou uspořádána tak, aby bylo možné jejich zpracování a zpřístupnění, provozní údaje a dále technické a programové prostř edky, případně jiné nástroje umožňující výkon informačních činností", "type": "object", "required": [ "identifikátor", "název" ], "properties": { "identifikátor": { "title": "Má identifikátor ISVS", "type": "string" }, "název": { "title": "název ISVS",

7 "description": "Název ISVS, který používá správce ISVS.", "type": "object", "required": [], "properties": { "cs": { "title": "Hodnota v českém jazyce", "type": "string" }, "en": { "title": "Hodnota v anglickém jazyce", "type": "string" } } }, "vytvoření": { "title": "datum vytvoření ISVS", "description": "Datum způsobilosti ISVS poskytovat služby uživateli ISVS v produkčním provozu.", "type": "string", "format": "date" }, "likvidace": { "title": "datum likvidace ISVS", "description": "Datum trvalého ukončení poskytování služeb ISVS.", "type": "string", "format": "date" }, "poslední-změna": { "title": "má datum poslední změny ISVS", "description": "Datum poslední změny ISVS.", "type": "string", "format": "date" },

Testování použitelnosti V této sekci se věnujeme testování použitelnosti prototypu pomocí standardní metodiky System Usability Scale (SUS). Testovací uživatelé nejprve prototyp vyzkoušeli na základě

8 scénáře, a pak vyplnili dotazník založený na SUS. Pro plné využití potenciálu generování dokumentace je třeba se orientovat v datových formátech a datovém modelování. Scénář V tomto scénáři vytvoříme dokumentaci a související artefakty (schémata) pro jednoduchou datovou sadu Sportoviště. Toto téma již je namodelováno v Sémantickém slovníku pojmů, tedy máme vše, co pro specifikaci datové sady a generování její dokumentace budeme potřebovat.

V naší datové sadě bude mít Sportoviště následující atributy:

• Podmínky užívání
• Provozní řád
• Adresu (text)
• Provozovatele - právnickou osobu

Provozovatel má identifikační číslo osoby.

Testovací scénář

1. Pracovat budeme s nástrojem na adrese https://demo.d ataspecer.com/, který si teď otevřete v novém okně.
2. V seznamu existujících specifikací pravděpodobně již naleznete nějakou specifikaci pro Sportoviště, my si ale vytvoříme novou pomocí tlačítka "Create new". V dialogu si specifikaci pojmenujeme. Po vytvoření se specifikace ukáže v seznamu. Klikneme u ní na "Detail".
3. V detailu specifikace vidíme její název, datové struktury, které specifikuje, specifikace, které přepoužívá a tlačítko "Generate .ZIP file", které na základě specifikace vygeneruje výstupní artefakty, tedy dokumentaci, schémata, atd.
4. Vytvoříme novou datovou strukturu tlačítkem "Create new". Uvidíme prázdnou specifikaci datové struktury. Tu je teď třeba naplnit tím, co chceme, aby v datové struktuře bylo, viz seznam atributů výše.
5. Nejprve je třeba zvolit kořen tlačítkem "Zvolit kořen". Tvoříme strukturu pro Sportoviště, tedy jako kořenem bude Sportoviště z datového slovníku.
6. Pod kořen chceme přidat potřebné atributy. Můžeme tak udělat tlačítkem "+".
7. Podmínky užívání a provozní řád v idíme přímo jako atributy Sportoviště, tedy je zvolíme.
8. Co se týče Adresy, v levé části dialogu vidíme rodičovské třídy Sportoviště, konrkétně Místo. Klikneme na něj. Vidíme, že místo může mít Adresu. Díky tomu, že Sportoviště od Místa dědí, Adresu může mít i Sportoviště. Vybereme jí.
9. Sportoviště také dědí od Veřejného místa, které má Provozovatele. Vybereme ho.
10. U tlačítka vpravo dole vidíme "Přidat (4)" - máme vybrány 4 položky, které kliknutím přidáme pod kořen.

9 11. Nyní musíme specifikovat, že u Adresy chceme v datové sadě mít pouze text. Tedy u vazby "má adresu: adresa" opět klikneme na "+" a přidáme "text adresy". 12. U Provozovatele chceme říct, že to má být právnická osoba. Když klikneme na "+", žádný obsah k použití nevidíme. Je to proto, že sám provozovatel žádné atributy nemá. Má ale řadu specializací (v dědičnostní hierarchii), a jednou z nich je Provozovatel jako právnická osoba. Pro nahrazení třídy její specializací slouží tlačítko tří teček a volba "Replace along inheritance". Tam vybereme "Provozovatel jako právnická osoba". 13. Nyní již víme, že je náš provozovatel sportoviště je právnickou osobou. A tedy má identifikační číslo osoby (IČO), které přidáme pomocí "+". IČO však není definováno pouze pro provozovatele, ale pro Osobu dle zákona 111/2009 Sb. Tedy klikneme na tu, a přidáme identifikační číslo osoby. 14. Tím je naše specifikace hotová. Přejdeme zpět do manažeru specifikací a vygenerujeme výstupní artefakty pomocí "Generate .ZIP file". 15. Výsledný soubor artifact.zip pak obsahuje vygenerovanou HTML dokumentaci a XML, JSON a CSV schémata. Výsledky dle metodiky SUS Počet testovacích uživatelů: 3 Výsledné skóre a jeho interpretace: 65 - lehce podprůměrné skóre, jednomu z uživatelů prototyp evidentně nesedl. Jednotlivé výsledky

Už./O. O1 O2 O3 O4 O5 O6 O7 O8 O9 O10 Skóre 1 4 3 4 3 4 3 3 3 3 3 82.5 2 4 3 3 4 3 2 4 3 3 4 82.5 3 1 1 1 1 4 1 1 1 1 0 30

Přílohy Zdrojové kódy prototypu z GitHubu jsou v příloze model-driven-data-main.zip.