Denník NP OpenData 2.0

Keď sme sa dotkli týchto analýz, najmä

tak mi dovoľte jednu vec ale opraviť, je veľmi dôležitá, a týka sa toho SPARQL Enpointu, ktorý neúnavne presadzujeme. :innocent:

Portálov s otvorenými údajmi a so SPARQL Endpointom nájdeme množstvo:

česko: https://data.gov.cz/sparql
španielsko: Punto SPARQL | datos.gob.es
eu: OpenLink Virtuoso SPARQL Query Editor
uk: ONS Geography Linked Data | SPARQL, api.parliament.uk/sparql
nemecko: SPARQL-Assistent - GovData

V analýze je malý odstavec k SPARQL Endpointu: “Vzhľadom na veľmi malý počet datasetov s formátom RDF, je tento nástroj nevyužitý.”.
Tu by som rád povedal, že SPARQL Endpoint nie je na prístup k RDFkovým distribúciam datasetov. V podstate nemá nič s nimi spoločné. Do vnútornej databázy portálu sa nenahrávajú žiadne dáta, len sa skatalogizujú ich metadáta. A nové portály na to používajú už RDF databázy (triplestores), tj. metadáta o katalógoch, datasetoch a ich distribúciách sú prepojené otvorené dáta. V oblasti popisu metadát otvorených údajov sa používa štandard DCAT.

Toto mi vysvetlí model dát.

Načo mi to vlastne je?

Aby som môhol cely katalóg (Národný Katalóg Otvorených Dát)NKOD dotazovať ľubovoľne v rozsahu jazyka SPARQL (čo niečo ako SQL len na triplestore). Čiže napr.

  • vráť mi zoznam všetkých datasetov
  • spočítaj počet všetkých CSV distribúcií
  • spočítaj len datasety Statistickeho uradu vytvorených v marci 2019
  • zobraz datasety z augusta 2020, ktoré majú kľúčové slovo COVID

V súčasnosti sa robí štantistika portálu veľmi komplikovane, teda aspoň čo som mal možnosť vidieť. Zo systému sa generujú EXCELY, a tie sa potom spracovávajú. Namiesto toho je úplne ideálne mať predpripravené dotazy, a tie len spustiť voči databáze. Samozrejme toto má skončiť peknými štatistikami na klientovi, aby si aj netechnický človek vedel napr. štatistiky pozrieť.

Ďaľšia vec je, že SPARQL Endpoint sa používa aj ako API do systému. Nemusím mať na tvrdo nakódené služby ktoré vracajú nejaké datasety (hoc samozrejme to niekedy je lepšie) ale sám si skoštruujem dotaz podľa toho čo potrebujem aj si vypýtam formát ktorý mi vyhovuje.

Takže náš plán rozbehnúť SPARL Endpoint data.gov.sk čím skôr, resp. možno si ho ešte predprojektom rozbehneme samy, na inom serveri. A plánujeme takto zostaviť jednak štatistiky a jednak začať merať dátovú kvalitu.

Koho by táto téma zaujímala, môžete si pozrieť prvé dokumentačné veci na opendata.gov.sk - Ako si rozbehať vlastný triplestore, naloadovať NKOD a dotazovať ho:

Bohužiaľ, zistili sme že služba súčasného portálu https://data.gov.sk/catalog.rdf vracia len prvých 100 záznamov, čiže čaká nás ešte zápas o celý dump súčasných metadát. :face_with_head_bandage:

edit: Ešte posledná info. V projekte OD2.0 rátame s databázou Virtuoso (podobne ako v ČR). Licencia je 1000 USD/Rok, hoc dá sa prevádzkovať aj bez podpory. Ako v ČR. My ale s tými zatiaľ na pár rokov rátame, mimálne počas trvania projektu.

https://virtuoso.openlinksw.com/pricing/

1 Like

V prvom rade vdaka za priebezne informacie. Nizsie budem pripadne asi viac kritizovat nez chvalit, ale aby sa teda nezabudlo, ze samotnu existenciu priebezneho otvoreneho informovania vnimam velmi pozitivne.

Open Source beriem ako samozrejmost, najma ked si spomenul “tisicky MD”, lebo:

  1. ako Open Source bol/je robeny aj OD1.0, vid napr. GitHub - nases-sk/eDemokracia-MOD a microcomp · GitHub

  2. zdrojový kód vytvorený počas projektu bude otvorený v súlade s licenčnými podmienkami verejnej softvérovej licencie Európskej únie podľa osobitného predpisu,18) a to v rozsahu, v akom zverejnenie tohto kódu nemôže byť zneužité na činnosť smerujúcu k narušeniu alebo k zničeniu informačného systému verejnej správy,”, vid https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2019/95/#paragraf-15.odsek-2.pismeno-d.bod-1

plus:

Zaratali ste aj migraciu obsahu? Tot data.gov.sk obsahuje aktualne 2554 datasetov, neviem kolko “resources”, zaregistrovanych je 92 organizacii a Y uzivatelov. A aj nejake data, napr. Register Adries.

Tu ozrejmim skor pre ostanych (=ini nez MIRRI a NASES) ze teda centralne ulozisko uz v OD1.0 bolo myslene ako “vec na ulahcenie, nie povinnost”, t.j. bolo a nadalej je chcene, aby sa publikovalo primarne priamo zo zdroja, ked sa da (vid napr. RegisterUZ ako optimalny priklad). Centralne ulozisko je pre pripady, ked “sa neda” resp. je centralne ulozisko efektivnejsou alternativou (prikladom nech je napr. uz spomenuty Register Adries, pri ktorom MV SR vyhodnotilo moznost “vypublikujeme sami” ako “neda sa” a tak to robi pre nich NASES cez ulozisko na data.gov.sk).

Scenar “interne kapacity MIRRI/NASES vezmu Open Source zdrojaky z CR a nasadia, pripadne si z CR (MFF UK) zaplatia drobny support a development” resp. nieco podobne, to by sme urcite chceli viaceri. Potom ale samozrejme bude namietat nejaky slovensky dodavatel, ze jeho riesenie nebolo ani len zvazovane … Cim sa dostavame k problemu “verejne obstaravanie” a na to su mnohe ine vlakna tu na platforme. Nazor mam, ale dalsej debaty k obstaravaniu sa zdrzim. :slight_smile:

Len teda vidiac vymenu, tak napisem, ako to vnimam ja, ze co asi MIRRI ide sutazit: “Tuna mame nejake zdrojaky a k nim dokumentaciu, ponuknite nam, za kolko to rozbehate.” Dufam, ze sa nebude obstaravat stylom “Kukneme, co je v CZ zrojakoch, vypiseme vlastnosti a funkcie a to dame do VO”, lebo tu by bolo riziko, ze niekto ponuknte re-implementaciu CZ riesenia, co bude drahsie ale z titulu roznych cudnych zakuti vo VO by aj mohlo vyhrat, ergo namiesto uspory mrhanie.

Uz od cias OD1.0 je navrhom ze (zjednodusene) “az tak velmi netreba, ale ked uz, tak skratka podpisat cez eID”. Ak by niekoho napadol block-chain, tak vid GitHub - milankowww/ckan2blockchain: Push dataset hashes to public blockchain for increased transparency. . Typicky scenar “paranoikov” (resp. tych, co by potrebovbali byt pravne kryty) by bol “periodicky stahovat dataset aj s podpisom prip. aj casovou peciatkou a tlacit napr. na verejny git” a ked pride na lamanie chleba, tak sa da demonstrovat, ze “toto sme stiahli vtedy a vtedy a podpisal to tento a tento subjekt VS”.

Priklad, realne z Viedne: Apka na parkovanie je 3rd party, zoznam platenych miest su Open Data mesta. A nastal zadrhel: apka povedala cloveku “tu je to zadarmo”, prisiel ale policajt, realne zadarmo nebolo, clovek dostal pokutu. Kedze sa bavime o trosku civilizovanejsej Viedni, nie SR, tak vec po internom presetreni uzavreli tak, ze identifikovali chybu v toku dat “mesto->3rd party apky” a danemu cloveku pokutu mesto odpustilo. V SR by sme zrejme museli ist sli cestou konfrontacie (lebo VS zvycajne na pokus c. 1 zodpovednost odmietne) a teda autor apky potrebuje dokazat, ze v danom case jeho apka vydala stanovisko na zaklade takych a takych dat od mesta.

Takuto garanciu v CR nemaju, ale budu mat, v systeme “verejny datovy fond” co je zjednodusene obdoba naseho CSRU. Pointa ale je, ze to je ciastocne separatny datovy tok: data by mali byt tie iste, ale tecu “zabezpecenymi kanalmi” vramci G2G. Ref.:

https://twitter.com/otevrenadata/status/1456552272209526787

Tu sa stotoznim, ze teda (odhliadnuc od sposobu obstarania) je technicka implementacia skor trivialna, lebo …

… problem s Open Data v SR je najma tu: metodicka a dalsia podpora, kedze povinnosti zverejnovat su definovane vcelku rozsiahlo, aj potrebne a dlhe roky. Ale typicky samosprava ani dnes netusi, co to vlastne je a ako sa to robi. A ked sa aj obratia na “gestorov” (typicky MV SR ci MIRRI), tak sa im pomoci nedostane.

+1, to potvrdili aj ludia zo samospravy.

Co ludia casto pytaju a nie je, to je dolezita metrika. Len sa tazko realizuje,

Naopak pocet downloadov sa implementuje lahko, ale je to skor “na nic”. Vezmime si povedzme Ekosystem.Slovensko.Digital a hypoteticku situaciu, ze by SU ratal downloady. Nuz, naratal by ich malo, lebo realne “pouzitie” je az za Ekosystemom, a teda ratali by len “par hitov mesacne” od servera Slovenko.Digital napriek tomu, ze Ekosystem by mal tisice ci miliony pouzivatelov.


Na zaver este vsuvka k debate “data vs. metadata”, lebo teda za ostanych 5-10 rokov to nie je prvy krat, ze sa v tom zamotava diskusia. Jeden, moj pohlad (a slovickarenie si dufam odpustime, podchytenie ma byt najma v Metodikach MIRRI, nie tu v diskusiach):

Dump ci API na data je samozrejme to hlavne o co ide. Ale ked uz mame stovky a viac datasetov v data.gov.sk, tak ma zmysel cielene pracovat aj s metadatami a mat povedzme aj API na metadata. (Moze ale nemusi to byt RDF/SPARQL.) Len teda nezamienat data a metadata.

(A aby som to zamiesal: vramci SPARQL endpointu by sa kludne dalo spravit, ze sa zmiesaju RDF data popisujuce datasety s RDF datami samotnych 4* ci 5* datasetov. T.j. jedno API pre data aj metadata. Cool, ale zaroven mozno matuce. :slight_smile: Miro uz vysvetlil, ze pod SPARLQ v tejto diskusii mysli najma to API na metadata.)

Tie zdrojáky z microcompu vidím prvý krát, díkes za linku. Otázka znie, či oba zdroje sú už komplet a stačilo by to na rozbehanie novej inštancie data.gov.sk, ktorú by sme mohli použiť ak by zlyhal plán s data.gov.cz. Zatiaľ len veľmi elaborujem. Napr. teraz neviem stiahnúť celý dump metadát (s ktorého viem stiahnuť aj samotné dáta), pretože táto služba

https://data.gov.sk/catalog.rdf, mi vracia len prvých 100 záznamov. Keby som dokázal stiahnúť všetky, tak máme migráciu dát a transformáciu metadát veľmi zjednodušenú.
V tým microcomp zdrojákoch sa presne píše o tejto službe:
GitHub - microcomp/ckanext-dcat: CKAN ♥ DCAT

Len zatiaľ neviem ako ju zavolať. Každopádne super, že sa nám rozšíril priestor na štúdium.

Neviem či som to dobre rozpísal, ale portál má dve časti. Jadro z data.gov.cz 70K (správa metadát, harvestovanie, dcat-ap-sk, meranie kvality, …) a druhá, ktorú bude robiť asi SKIT 400K (autentifikácia egov + pre komunitu, migrácia dát, poskytovanie služieb ná zápis súborov, grafický design), čiže migráciu dát plánujeme urobiť v tomto bode.

Avšak metadáta už budú premigrované do nového jadra, čím hneď ožívíme aj SPARQL Endpoint) a kým sa dokončí tá druhá fáza, bude sa dát robiť analýza datasetov (a vyhodnocovať správnosť metadát) cez český portál.

Kľudne sa nezdrž a svoj názor plís zdieľaj. Pre mňa je téma VO veľký hlavybôľ, jednak že chcem riešiť skôr technickú stránku, nie projektovú, ale aj že mi príde divné, že chceme spolupracovať z MFFUK, MinVČR, avšak vyzerá že nemáme inú možnosť len pozvať ich do VO. Priznám sa, že chápem načo je VO, ale toto mi príde divné.

Podobne je pre mňa divná a neurčitá situácia okolo SKITu. Vnímam veľkú debatu okolo tejto témy, priznám sa, že z mojej pozície nemám ambíciu byť atrbitrom, prial by som si, aby sa to na vyšších poschodiach vyriešilo. To že v tomto projekte došlo k zmene z pôvodného zámeru vyvinúť portál k nasadeniu opensource, nebolo motivované proti SKITu, ale za opensource. Mali sme viac kráť stretnutie, keď sa pripravovala ponuka a podľa mňa, normálnu situáciu by si priali aj SKITaci.

Díkes za linky, aspoň som prvýkrát niečo v tejto zachytil, a nevylučujem že elektronické podpisovanie datasetov niekde v EÚ funguje. Nerobili sme úplne detailnú analýzu portál za portálom. Ja sa osobne staviam k tomuto zatiaľ skepticky, aby sme si nezaviedli byrokraciu, ktorú nepotrebujeme.

Tak toto ma zaujíma mimoriadne, pretože sa snažim nájsť pridanú hodnotu CSRÚ pre opendata. Kedže projekt avizuje, že nemôžu napr. zvyšovať kvalitu, napr. robiť transformácie do vyššej kvality, alebo stotožňovať napr. adresy z registra adries a tak vylepšiť opendata dataset RPO (že už budú poskytovať adresu cez identifikátor adresy), tak stále musím prínos pre opendata hľadať. Či je Verejný dátový fond podobný ako CSRÚ, to by som potreboval vedieť.

Každopádne plánujeme hlbšiu diskusiu s kolegami z ČR na túto tému, teda ako zabezpečiť dôverihodnoť opendata, skúsim ju otočiť čím skôr. Tak či inak, PoCčka v projekte zatiaľ ponecháme, len diskusia o ich význame zatiaľ len začína.

1 Like

Čiže keď zhrniem aktuálny pohľad na projekt, tak to vyzerá takto:

1. Portál

2. Rozvoj

Tu by som sa chcel ešte zastaviť pri publikačnom minime. Kedže OD2.0 rieši centrálne komponenty, a už sme také jedno publikačné minimum robili, z prvej vlny publikačného minima
https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=67152325

bolo z pohľadu spracovania dát naťažie spracovať dotácie. Existoval na to excel ako to nahadzovať, no to bola jedna obrovská tabuľka s ktotou sa nedalo moc dobre robiť. Tak sme navrhli nový excel, ktorý rozdeľuje dáta na 4 samostatné datasety (schémy podpory, výzvy, obmedzenia výziev, žiadosti), a myslím že riešenie je urobiť obdobne ako Centrálny register zmlúv, tak aj Centrálny register dotácií.

My sme už vlastne spravili podstatnú časť dátovej analýzy
https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=77332958

a vedeli by sme urobiť ešte aj Špecifiáciu softvérových požiadaviek, a otázka znie, či by sa dala taká evidenčná aplikácia urobiť za 400K (VO), pričom my MIRRI tiež rátame podporu. Bojím sa že moje odhady sú skôr také čisto programátorské, a toto by radšej mal byť samostatný projekt. Každopádne, spravil som to zatiaľ tak, že som presne neuviedol, že publikačné minimum sú dotácie, ale čoskoro budeme musieť, keďže sa budú pripravovať podklady do VO.

3. PoC

4. Zhrnutie

Kedže nám tlačí maximálne čas, projekt už mal dávno začať, prosím o spätnú väzbu čím skôr ak sa dá. Potrebujeme riešiť zmenu NFP a to už v najbližších dňoch. Zatiaľ je kľúčový celkový rozpočet. Tieto tabuľky sú základným vstupom pre jeho vytvorenie.

(edit: do interného stuffu som pridal jedného vývojára, ktorý bude robiť podporu vývoja pre portál, publikačné minimum a komponent pre komunitu). Ak budú softvérové aktivity na projekte viaznúť, napr. kvoli VO, tak toto je naša cesta ako sa s tým vysporiadať.

Ja som tiež nahadzoval nejaké datasety a paradoxne autentifikácia mi nerobila problém, ale scenár: naša organizácia má 25 datasetov, ktoré sú nahrané na data.gov.sk a potrebujem ich aktualizovať. Keby som to vyklikával tak by som sa asi zbláznil (presne čo hovoríš že reakcia portálu nie je práve rýchla), čiže mal som na mysli urobiť nejaký batch proces, kde aktualizuješ na jeden klik ľubovoľný počet datasetov vrátane metadát (tie môžeš mať napríklad v csv súbore).

Účel je vedieť o aké dáta je reálne záujem, tieto môžu potom v portáli vyskočiť vyššie aby nezanikli v tom množstve iných. Problém totiž môže byť pre používateľa na začiatok identifikovať zaujímavé dáta (na toto sa používa v novinách políčko najčítanejšie články :)) A takisto je to zaujímavé aj ako akési vyhodnotenie, čo ak nejaká organizácia má veľa datasetov, ale nie sú zaujímavé, nie sú kvalitné, atď. A ide aj o transparentnosť celého portálu.

Myslel som najmä pridávanie nových aplikácií (preto ich máme tak málo) a hviezdičkovanie datasetov. Ak tieto funkcie majú byť v novom portáli (čo nehovorím že musia, napr. ČR to tam tuším nemá), tak to urobme tak aby sa to dalo ľahko použiť alebo to nerobme vôbec. Potenciálne sa dá urobiť aj komentovanie datasetov, označenie ako obľúbený, veľa vecí sa dá vymyslieť (ak na to je čas a priestor).

1 Like

Moja predstava vztahu Open Data a CSRU, ignorujuc to, ze obcas v CSRU mozu tiect aj tzv. “citlive data” (osobne a pod.), tot kedze by malo platit zakladne “co nie je tajne, je zverejnene”. Predpokladam, ze efektivna implemntacia CSRU a Open Data na strane zdrojovych systemov obnasa jedno API, nadizajnovane a naimplementovane raz s tym, ze jeden deployment/konfiguracia bude poskytovat Open Data rezim, druhy deployment/konfiguracia G2G rezim pricom v mnohych pripadoch nebude medzi Open Data a G2G ziaden alebo len maly obsahovy rozdiel.

Pointov idealneho scenaru je co najviac vytazit vsetky investicie, t.j.:

  • ak ma CSRU fungovat, musi pren niekto v agendovych systemoch urobit API na pristup k datam
    • a ak uz sa robi API pre CSRU, tak za drobnu prirazku sa jednym vrzom da urobit API tak, aby osetrilo aj Open Data use-case (tot co som pisal uz vyssie)
  • ak je (okrem integracii) hlavnou pridanou hodnotou este aj “integracia” a “jednotny pristup” (ze uz nemusim liezt do X dalsich IS/API), tak preco by z toho nemohol benefitovat aj obcan?
    • o.i. je tu “synergia”, ze ked uz data analyzoval ktosi na CSRU napr. z pohladu ochany osobnych udajov, tak uz vie vcelku lahko aj oznacit “nezavadne polozky”
    • a ked uz niekto na CSRU nadizajnoval ETL ci “pipe line” na stotoznovanie ci prevazovanie a pod., tak uz tam vie vcelku efektivne pridat nejaku tu sipecku a skatulku navyse, ktora vygeneruje aj Open Data
  • s tym, ze obcan ma na vyber, ci chce “lepsie data” od CSRU (aj ked mozno s mierne vyssim rizikom vypadku ci chyb) alebo “radsej na istotu” (a mat “raw” data priamo od zdroja)
    • t.j. o.i. motivacia pre CSRU naozaj dodat pridanu hodnotu resp. pre zdrojove systemy neposkytovat v porovnani s CSRU “totalny bordel”
    • alebo inak: ak bude tlak na kvalitu dat v G2G, pricom (s ohladom na cenu CSRU projektov) sa da poredpokladat nejaka citelna pridana hodnota aj zo systemu CSRU, tak treba zabezpecit, aby z nej benefitovala aj Open Data vetva

Podla toho co nakreslili v CR, tak sa blizia k takemuto scenaru, t.j. ze rozdiel medzi “verejny datovy fond” a “Open Data” je minimalny a spociva najma v:

  • dostupna sirsia mnozina dat (t.j. aj osobne ci inak citlive)
  • omnoho lepsie zabezpeceny pristup
    • ale teda neuvazuje sa s podpisovanim, lebo vsak cely system bude cisto statny a G2G a teda naco

A teraz (moje, mozno zle) vnimanie aktualnej nasej situacie:

CSRU podla doterajsich informacii ma zaujem najma:

  1. riesit integracie s kazdym zdrojom dat
  2. nasledne vsetkych pouzivatelov dat smerovat uz len na seba, pricom
    • vnimam snahu v kontexte G2G nepustit nikoho “naokolo”
      • naberie az absurdny rozmer v kontexte samospravy, kde je predstava DCOM asi takato: zdrojovy IS → CSRU → DCOM → konzument v samosprave (aj ten, co uz ma iny ako DCOM agendovy system)
        • a ze co teda v pripade vypadku CSRU alebo DCOM bude robit uradnik v samosprave, to si vie predstavi napr. obcan v Bratislave, kde si ho kvoli komplikovanejsej delbe zodpovednosti mozu kvoili chodniku, parkovisku ci ceste pohadzovat mestska cast, Magistrat a NDS pekne dokolecka
    • vnimam snahu v kontexte G2C ci G2B “hodit” Open Data na niekoho ineho, napr NASES
      • co by bolo neefektivne, lebo teda bude sa duplikovat analyza a integracia dat, navyse ludmi mimo prevadzkovatela a dodavatelov CSRU, t.j. da sa ocakavat “horsie” zdielanie know-how
      • zaroven sa vyrazne znizi re-use investicii do datovych API robenych pre CSRU, lebo sa teda zrejme malokedy prepouziju na Open Data

Toto by som sledoval, lebo v SU CSRU (a teraz ze ktorej? vid nizsie) to vyzeralo na ruzovu zahradu (zrejdnodusene integracie na zdrojove IS, ujednotene/integrovane data, atd.) a cenovky tych projektov su fakt velke. Pricom neskorsia komunikacia tohto typu akoby nas pripravovala na vyrazne menej ruzove vysledky. Ten system stal a este bude stat desiatky mega. Ak len vezme zlava nejake XML a vpravo zabali do JSON (alebo naopak), tak cela zxdovodnenie sa zuzi na “naintegrovali sme vam X zdrojovych systemov na jedno miesto”, ale budeme sa chytat za hlavu, ze aky bordel je v obsahu/datach.

A referencia: To, comu tu ja hovorim CSRU je o.i. toto:

(O.i., lebo si naisto uz nepamatam, ci tie dva su naozaj jedine “follow-up” pre CSRU v OPII.)

2 Likes

Ahojte, predtým ešte než odpoviem na vyššie posty, pridávam tu linku na google drive projektu OD2.0
https://drive.google.com/drive/u/1/folders/1xPuYehcSLop7M_xu2-9Bqt9OYzr2d5Bu

Môžete tam nájsť vznikajúcu dokumentáciu, model, či celkový pohľad na VO a participáciu MIRRI na jednotlivých komponentoch OD2.0:

1)

Pre nás najdôležitejšie je spustenie 1. projektu (VO) Portál pre správu Národného katalógu otvorených dát NKOD.
Prvé dokumenty ako Opis predmetu zákazky, alebo Katalóg požiadaviek pre NKOD , ktoré sú vstupom pre vytvorenie (aktualizáciu) rozpočtu projektu môžete nájsť tu:
https://drive.google.com/drive/u/1/folders/1_95MWwPeoQ52PmsXzeRcJ1LsX1xPmxtx
Momentálne sa pripravuje zmluva o dielo a kritéria vyhodnocovania ponuky. Keď to pripravíme, tak to zverejníme.

2)

Pôvodný katalóg požiadaviek som rozdelil na viac a pridelil do jednotlivých projektov. Dokončenie portálu (autentifikácia, storage, sk-id, služby)
https://drive.google.com/drive/u/1/folders/1-qchuM70QmpiwLJYqHpzaqDlV3piFpu8

sa ešte navrhuje, ktoré čoskoro zverejníme na pripomienkovanie. Rovnako je možné si pozrieť ako sa rysuje projekt, resp. požiadavky OpenData Komunity
https://drive.google.com/drive/u/1/folders/1WaYUc7h9X4Luqh2M8aD8fvV4Ch6JR9gx

Mimo prvého riešenia, sú ostatné v podstate ešte otvorené, a nexistuje ich presná špecifikácia. Pripomienky sa dajú ale dať ku všetkému.

Ak by niekto chcel vidieť ako postupne vzniká UML model pre projekt, môže si pozrieť dané EAPčko.

hmmm … myslím ale že Vás finančné správa dosť previezla … za pár šupov slušný portál s použiteľnými dátami. A bez dlhých rečí …
Aspoň takto to uvidí verejnosť.
(ja keď kuknem teraz na data.gov.sk tak polovica datasetov tam je nepoužiteľná, alebo stará - čo je väčší problém nejž nejaká konformnosť s nejakou normou)

1 Like

Vedelo o tom MIRRI, alebo bolo rovnako prekvapene ako zvysok verejnosti ?
lebo mi nejde do hlavy, ze akeklvek ine investicie do IT sa musia vzdy na MIRRI schvalovat … ale FS zjavne zije svojim zivotom

Ja si to teda nemyslím. V prvom rade poviem, že sme radi každému novému opendatovému portálu a bolo by super keby sme ich vedeli podporovať a usmerňovať. Navyše, toto je jedna z našich preferovaných foriem, tj. aby boli opendata decentralizované, a napr. sprístupnené cez OpenAPI u OVM, a na centrálnom portáli len skatalogizované. Takže za mňa super opendata. :ok_hand:

Avšak, vôbec si nemyslím, že nás previezli. Centrálny portál (NKOD), je niečo iné ako portál samotného OVM (LKOD).

Centrálny portál je predsa miesto, ktoré má obsahovať, resp. zhrávať všetky metadáta otvorených údajov všetkých OVMiek (aby sa dali otvorené údaje objaviť, pretože nie je možné aby používateľ vždy vedel kde má dané opendata hľadať). Centrálny portál je tiež miesto, ktoré poskytuje OVM autentifikáciu a API služby na zápis dát (hoc autentifikácia sa musí vylepšiť). A samozrejme, aby bolo možné efektívne s metadátami otvorených údajov pracovať, tj. aby som ich mal v nejakej strojovej forme, na to je ideálne poskytovať všetky metadáta cez nejaký endpoint, aby si každý našiel čo hľada a naimplementoval si systém ako mu to vyhovuje. V EÚ je štandardom SPARQL Endpoint, a verím že sa nám podarí poskytovať aj GraphQL Endpoint. Ten SPARQL Endpoint bohužiaľ doteraz nefungoval, aj možno preto sa presne nevedelo, na čo to slúži. :innocent: Už som to vyššie vysvetľovať, že to s RDF distribúciami nemá nič spoločné.

Portál finančnej správy nič také neposkytuje, hoc niektoré riešenia lokálnych portálov v EÚ sú také, že aj LKOD má vlastný SPARQL Enpoint, alebo DCAT-AP službu, ktorá sa NKODom harvestuje úplne najideálnejšie.

Určite je čo zlepšovať, napr. už len kvalitu metaúdajov, aby boli distribúcie skutočne dostupné (alebo služby). Centrálny portál toto bude mať, viď napr. Datová kvalita (nejen) v oblasti otevřených dat - Portál otevřených dat České republiky . Toto tiež neposkytuje a ani nerieši portál finančnej správy. :point_left:

Kým som aktívne nepracoval s data.gov.sk, mal som asi podobný názor. Teraz mám k nemu super vzťah a teším sa keď ho updatneme. Aj cez meranie kvality. Kým sa dokončí celý nový portál, tak plánujeme novým založeným na data.gov.cz harvestovať starý, a opravovať v ňom chyby, najmä dostupnosť a existenciu niektorých údajov. Plánujeme posilniť interné kapacity a rozdeliť si rezorty.

Čo sa týka financií. Na projekte ideme poriadne ušetriť oproti pôvodným plánom. Vybrali sme sa cestou opensource, a vôbec to nie je také ľahké ako som si myslel.

Vytváram požiadavku:
Dávkový upload súborov na data.gov.sk (na rozpracovanie)
Lokáciu pre požiadavku by som videl v časti Rozvoj - Komunita, podpora (3.fáza portálu OD2.0). Základný portál by sme chceli urobiť čo najednoduchší ale zároveň obdobný ako v EÚ.

Tak či onak. Musíme túto požiadavku čo najlepšie vyriešiť. Pretože, so samotnou distribúciou (súborom) sa nesie množstvo metadát, a udržiavanie tohto všetkého alebo len minima, je celkom komplexné. Otázka je vytvorenie nejakého klienta. Hoc by to bol len súbor, muselo by byť serializované URI distribúcie, popis zmeny, resp. ďalšie parametre. :neutral_face:

Možno ale, že keby sa len zrýchlil uload dát, pretože teraz to vyzerá tak, že sa každý súbor testuje všetkými antivirákmi sveta, tak by si stým možno ani taký problém nemal. 25 datasetov navyše je podla mna lahsie udrziavat rovno na serveri, ak to samozrejme beží rýchlo. Dávkovo by som riešil vačšie desiatky súborov. Čo tiez asi nie je cesta. Loadovať súbory niekam na digitálnu hromadu. Skôr byt miestom k prístupu dostupných živých opendát. Byť zaregistrovaný a harvestovateľný, čo máte nové.

Tak toto sa podľa mňa ešte musí došpecifikovať.

Ďaľšia požiadavka:
Účel je vedieť o aké dáta je reálne záujem, tieto môžu potom v portáli vyskočiť vyššie aby nezanikli v tom množstve iných.

Ak správne chápem, tu ide o určenie metódy a metriky, ako odmerať datasety od najzaujímavejších po najmenej zaujímavé. Či to už súvisí s počtom klikov na dataset, alebo počtom vyhľadávaní, stiahnutí. Dôležité je vedieť toto meranie zobrazovať, zohľadňovať. Toto by bolo dobré pozrieť ako je to v iných portáloch realizované a ako.

Ďaľšia požiadavka:
Zjednodušenie spôsobu pridávania novej aplikácie, ktorá využíva otvorené údaje.

Čo myslíš tým hviezdičkovaním? Myslíš tým kvalitu opendata, tj. 3★ CSV, XML, resp. 4★(RDF), 5★(LinkedData) ? Hoc preferujeme RDF (aj naše publikačné minimum mirri je príklad ), to je ešte hudba budúcnosti. Navyše pekné RDFfko nemusí byť v konečnom dôsledku už dostupné (nefunkčný odkaz), ale CSV áno. Či že ak by som zobrazoval nejaký príznak, tak skôr celkovú kvalitu datasetu, funkciu viacerých atribútov.

K označovaniu datasetov ako obľúbených sa staviam tiež trochu konzervatívne, pretože podľa správnosti - nový dataset nemá premazať starý dataset, ale má sa vytvoriť nový dataset, starý zachovať (ideálne ešte spojiť reláciou nahradzuje). Nesprávne je tiež zoskupovanie rôznych časových distribúcií pod jeden dataset. Čiže, to by som potom musel každú novú verziu lajkovať, resp. musel by sa prenášať like (čo by sa dalo ale neviem či by sa úsilie oplatilo). Podobne to platí pre komentovanie datasetov. Tiež keď nový dataset nahradí starý, strácam diskusiu k pôvodnému.

Avšak diskusia ani like sa nemusia prenášať, môže to byť okamžité. Prípadne nejaký iný návrh. Všetko je tu ešte otvorené.

1 Like

K Dávkový upload súborov na data.gov.sk (na rozpracovanie):
25 bol samozrejme len príklad kedy už začína dávať zmysel uľahčiť si prácu :slight_smile: Ale pokiaľ bude stačiť povedať portálu otvorených dát, že tu na svojom serveri mam zložku s otvorenými dátami a kontroluj si pravidelne aktualizáciu a aktualizuj si metadáta tak je to tiež OK. Neviem presne ako to technicky funguje, podstatné je aby to vedel podľa návodu nastaviť aj bežný úradník (neITčkár)

Páči sa mi ako je to napríklad urobené v Írsku: Datasets - data.gov.ie

Myslel som skôr používateľské hodnotenie (ak sa ti dataset páči, dáš mu 5 hviezdičiek, ak nie napríklad 2). No hej tu je na diskusiu ako to realizovať a či to vôbec robiť.

Ale ani hviezdičky podľa otvorenosti nie sú zlý nápad. (videl som to na viacerých portáloch).

Každopádne to pridávanie aplikácií je minimum, tie by sa mali dať pridať bez potreby autorizovať sa cez občiansky a slovensko.sk - buď klasický login - meno, heslo, e-mail alebo ak je to reálne bez registrácie (ak predpokladám že sa budú aplikácie kontrolovať pred zverejnením).

1 Like

Bavíme sa o https://opendata.financnasprava.sk/ ? lebo tam tých dát teda nie je … skôr tak grafy max

BTW chybu v kontrakte, kde má byť v headeri page miesto id som už nahlasoval.

Krátne poznámky k aktuálnemu stavu.

1)

Aktualizácie dokumentov

2)

Dobrá správa je, že sa nám podaril stiahnúť kompletný katalóg metadát (všetky datasety, distribúcie), takže môžeme data.gov.sk dotazovať (kvoli štatistikám napr. alebo migrácii) cez SPARQL Endpoint (zatiaľ len lokálne). Na tejto adrese si ho môžete stiahnuť a robiť s ním prvé pokusy.
https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=77334664

Pekne sedí aj celkový počet datasetov.

3)

Bohužiaľ, s prihlasovaním na data.gov.sk máme momentálne teraz problémy. Vypršala nam support zmluva s GlobalTelom, teraz to prevadzkuje NASESa a bohuzial práve v tej deň prestala ísť autentifikácia pre OVM. Podarilo sa to opraviť, ale už je to opäť zhodené. To len podčiarkuje dôvod nového projektu. Na druhej strane chceme ale povedať, že potrebujeme súčasný data.gov.sk funkčný tak dlho ako sa len dá.

Kvoli tomu som nemohol dump data.gov.sk publishnúť priamo na data.gov.sk, resp. potrebujeme správne nahodiť OpenDataAPI IMTS 2014+, aby sme dorobiť štandardy katalogizácie OpenDataAPI na centrálnom portály.
https://wiki.vicepremier.gov.sk/pages/viewpage.action?pageId=77333258

a mohli ísť príkladom, napr. aj pre finančnú správu.

4)

Už máme hotové aj kritériá pre prvé VO (Portál na správu Národného katalógu otvorených dát), čoskoro ho zverejníme. Určite ešte pred vyhlásením VO.

5)

2021-12-09T12:00:00Z bude ďaľšia pracovná skupina OpenData, kde OD2.0 bude jednou z hlavných tém. Budeme radi keď sa pripojíte a pomôžete nám urobiť projekt tak dobre ako sa len dá.

Ahojte,

pár infošiek k aktuálnemu vývoju (okrem toho že sme viacerí covid pozitívni).
Týka sa to hlavne portálu.

Ako sme uviedli, portál chceme nasadiť v dvoch fázach. Prvá bude o znovapoužití opensource a zameranie sa na podstatu diela (metadáta, meranie kvality, harvestovanie, dotazovanie), a druhá fáza bude o jeho umiestnení do prostredia slovenského egovu (autentifikácia, id-sk design, úložisko a zachovanie služby na ukladanie súboru).

Aby sme čo najefektívnejšie spojili tieto dve veci a ušetrili úsilie, z predmetu prvého diela vypadne požiadavka na GUI a zameriame sa viac na samotné dáta. Teda konkrétne na jadro dátového procesingu a publikácie do novej databázy metadát. Používateľ to uvidí v oživení prístupového bodu
https://data.gov.sk/sparql

Aktualizoval som OPZtko a katalóg požiadaviek
https://drive.google.com/drive/u/1/folders/1_95MWwPeoQ52PmsXzeRcJ1LsX1xPmxtx

Následne, po nasadení dátovej časti opensource, sa zameriame na dokončenie portálu. Najskôr v základnej výbave (2. fáza portálu).
Keďže sme viazaný SK-ID grafickým designom, tak je viac menej jasné, ako bude vyzerať, podobne ako data.gov.uk:
PS: Data.gov.uk podobne ako data.gov.cz neumožňuje ukladanie súborov do centrálneho úložiska. A to len podporuje našu snahu v budúcnosti sa k tomu tiež prepracovať. Čiže nový portál data.gov.sk v základnej výbave bude jednoduchý, strohý, konzervatívny rýchly portál. To je náš najväčší cieľ.

Toto musíme ešte rozpracovať, ako v najjednoduchšej verzii vypublikovať niekde na webe OVM súbory spolu so špeciálnym súborom popisujúcich ostatné súbory, ktoré by si harvester sám stiahol. Tu neviem či skončíme pri nejakom používateľsky príjemnom riešení. Jednoduchý používateľ by mal skôr používať taký soft, čo poskytuje harvestačné API, zaregistrované v centrálnom portály (NKODe).

Ja si skôr zatiaľ viem predstaviť, že takýto popisný súbor urobí technicky zručnejší človek. Nemusí to byť RDFko, ale len metadáta v rozsahu DCAT-AP-SK.

V čechách napr. si OVMko môže najjednoduchšie rozbehnúť lokálny katalṕg priamo na githube, a zedituje si súbor, ktorý s potom načíta, transformuje a naloaduje do centrálneho katalógu. Je to tak zvaný minimalistický variant LKODU:

Poviem aj to, že momentálne práce sú pre mňa na portály mimoradne obtiažne. Ani nie čo sa týka samotnej vecnosti projektu, ako skôr pripraviť Zmenu NFP, rozpočet, verejné obstarávania. Sme dosť v kritickom čase a je tu isté riziko že nám zastavia projekt, kvoli pokročilému času. Chcem len povedať že robíme čo môžeme a je v našich silách.

1 Like

Super, som rád že projekt napreduje. Za mňa je jednoduchý a rýchly portál OK, pokiaľ ho budete vedieť v budúcnosti jednoducho rozširovať. Btw. britský portál nevychádza z Open Data Maturity práve dobre, tak dúfam že náš bude lepší :smiley:

Všetci asi nebudú chcieť používať GitHub, takže je fajn ak bude nejaká iná možnosť. A ak sa to nedá urobiť pre bežného usera tak OK, potom je dobré urobiť nejaký prehľadný návod. Len neviem či ak na to bude potrebné inštalovať nejakú špeciálnu aplikáciu, či to nebude prekážka.

1 Like

čo s projektami, ktoré sú aktuálne v implementácii a majú publikovať otvorené dáta ?
Vlastne ani nevieme ako ich majú publikovať, ale projekty majú deadlines …

To je dobrá otázka. Máme štandardy, ktoré sa vždy nedarí dodržiavať, ak to mám tak povedať. A samozrejme veľké množstvo štandardov pre otvorené údaje nám chýba. Teda začali sme na nich pracovať (opendata.gov.sk), avšak zatiaľ sa to týkalo buď metadát otvorených údajov všeobecne, alebo dátových modelov niektorých datasetov.

Chýbajú nám technické štandardy, a pravidlá, kedy aký model sprístupnenia treba použiť:

ako napr. štandardy použitia OpenAPI pre OpenData (jazyk, kedy token áno kedy nie, výstupný formát …).

Čo sa týka rozbehnutých projektov. Viec vieme ovplyvniť podľa fázy kde je projekt. Napr. mali sme možnosť pripomienkovať pár datasetov RegistraOVM (ŠÚ), čo bol rozbehnutý projekt, a keďže sa jedná o zdrojový register pre RPO, tak sme hneď určili json-ld, kde sa už používajú na identifikáciu vecí URIčka

O ostatných sme sa jednoducho nedozvedeli, čo je škoda. Pretože určite opendata musia byť zastrešené centrálnym bodom, aby sa všetky dali nájsť, a čo najefektívnejšie vzájomne použiť. Podľa mňa keď sa dorobia spomenuté štandardy publikácie, tak sa dá veľmi pokročiť.

Ešte dodám, že máme napr. požiadavku na urobenie štandardu OpenDataReady, ktorý bol plánovaný v nejakom projekte EVS, ktorý sa nakoniec nerobil. Mali to byť pravidlá pre dodávateľov, ako majú dané opendata vlastne urobiť (pre štátnu správu a samosprávu). Mám pocit že také niečo majú v ČR, čiže toto musíme tiež pozrieť.

Aktuálne dávame dokopy zoznam dopytových projektov (Manažment údajov inštitúcii verejnej správy - 30 živých projektov) a vyťahujeme z nich, aké Open data nám nasľubovali pri schvaľovaní projektov (robíme to aj kvôli nášmu druhému projektu DI, aby sme vedeli, koľko dopytových projektov nás bude žiadať o integráciu na CSRÚ). V aktuálnom 5.kole dopytovej výzvy máme 5 projektov (Štatistický úrad + URSO, Trnava, Topoľčany… Zvolen ma pripravený projekt, ale podľa všetkého ho asi nestihli podať a pôjdu v ďalšej vlne) - všetci taktiež nasľubovali veľa Open data. Pri konzultáciách im hovoríme, nech sa zatiaľ napoja na staré data.gov.sk (v projektoch preferujeme automatizované publikovanie) s tým, že po spustení nového portálu premigrujeme datasety aj integrácie.

Pár aktuálnych infos:

Na nasledovnom obrázku môžete vidieť aktualizovaný stav komponentov OD2.0

VO1:

Toto prvé obstarávanie pôjde vonku v nabližších dňoch.
Ešte sa formálne finalizujú súvisiace dokumenty, OPZ, požiadavky, kritériá
https://drive.google.com/drive/u/1/folders/1_95MWwPeoQ52PmsXzeRcJ1LsX1xPmxtx

Keby som to mal veľmi zjednodušiť, prvým produktom je nová databáza metadát podľa DCAT-AP-SK, prístupná cez SPARQL Endpoint, tj. dotazovacie rozhranie.

Rozhranie bude vlastne oknom do nového systému, do novej databázy a nového dataprocesingu (harvestovanie, meranie kvality, počítanie štatistiky). Pomoc neho bude možné zadávať ľubovoľné dopyty na metadáta a žiadať aj formát odpovede. Súčasťou predpripravených dotazov bude množina systémových dotazov - tj. celkové štatistiky a merania kvality

Začali sme robiť aj návrh GUI, čiže po prvom VO to bude vyzerať nejako takto:

Rámcová zmluva so SKIT:

Dorobenie autentifikácie, úložiska, služby pre ukladanie súboru a vytvorenie webových stránok pre portál v súlade s ID-SK plánujeme robiť s SKITom.
Samozrejme snažíme sa minimalizovať riziko ich nedostupnosti, takže čo vieme spraviť, spravíme v dátovke. Na druhej strane, s chalanmi so SKITu čo som ja mal možnosť robiť na príprave OD2.0, by som rád robil opäť. Mrzí ma celá tá debata o regulérnosti, resp. neregulérnosti SKIT, my to nemáme ambíciu v rámci OD2.0 rozhodnúť.

Tak či onak, portál podľa SK-ID bude vyzerať nejako takto. Ešte musíme overiť či je toto posledná verzia, alebo nie. Prekreslíme.

VO2:

Súčasný plán je, že ostatné veci pôjdu do druhého veľkého obstarávania, pričom na jednotlivé komponenty sa budú môcť prihlásiť samostní uchádzači.
Za najdôležitejšie súčasti tejto fázy považujeme V2.3 Komunita otvorené údaje, a V2.2 Publikačné minimum. A bohužiaľ tu sme veľmi na začiatku. A potrebujeme tu veľkú pomoc.
Musíme sa prioritne dohodnúť na Katalógu požiadaviek.

https://drive.google.com/drive/u/1/folders/1WaYUc7h9X4Luqh2M8aD8fvV4Ch6JR9gx
https://drive.google.com/drive/u/1/folders/1NhUdqZKfK3LIH0II3nBWIkDapW8gU-m2

Náš dátovkový cieľ s portálom je jasný. Priorita je základný portál ako je to v iných krajinách. Komunitnú nádstavbu, resp. centrálne komponenty pre publikačné minimum potrebujeme rozhodne viac rozbehnúť.

VO3:

Neviem či sme toto vôbec ešte komunikovali, ale náš projekt OpenData bol vybratý ako vhodný prvý projekt pre tzv. Komerčnú časť vládneho cloudu, čo by mal byť nejaký poskytovaný cloud v spolupráci s komerčným subjetom. Na toto sa bude robiť tiež obstarávanie. Podklady sa pripravujú, posnažíme sa ich zverejniť čím skôr.

VO4:

Jediná komernčná licencia softvéru, ak vôbec, bude databáza pre Národný katalóg otvorených dát, čo je RDFDatabáza. Česi používajú Virtuoso, čo bolo plánované aj pre slovenský OD1.0. Cena je 1000USD/ROK, pre prvotný výkon. Česi stále fungujú na opendata verzii.

My plánujeme používať GraphDB. Tiež na opendata verzii. Samozrejme plánujeme dokumentovať porovnanie GraphDB, Virtuoso a RDF4J-DB.
GraphDB je špička v obore.

VO5:

Toto je základná publicita. Plagát, prezentácia …