ÚPVII Pracovná skupina K9.4 Lepšie dáta


#110

V tom zmysle, ze sa nakoniec tomu venovalo vcelku vela castu, o.i.:


#111

Štefan začal aj diskusiu k tomu či/ako podpisovať datasety KEPom:


#112

Milí priatelia/kolegovia,

práve finišuje dokument Strategická priorita Otvorené údaje, prebiehajú posledné hlasovania o témach ktoré treba doriešiť, a práve dva hlasovania súvisiace s LinkedData-mi sa budú riešiť na budúci týždeň. Som ich absolútny zástanca, avšak momentálny setup v dokumente je viac než nešťastný. Dovoľte aby som Vám predstavil tento problém a poprosil Vás o podporu môjho názoru.

1. Cieľový stav kvality údajov vs. Pravidlá pre interoperabilitu otvorených údajov

Dôvodom sporu je nejasnosť medzi a) cieľovým stavom kvality otvorených údajov a pravidlami pre interoperabilitu otvorených údajov verejnej správy. U niektorých členov pracovnej skupiny sa to zamieňa/nerozlišuje.

PS dopredu: Nechceme totálne, hlava-nehlava tlačiť na linkované údaje, nechceme zvyšovať stanovený podieľ linkovaných datasetov na celkovom počte, ale presne naopak, chceme to znížiť.

Cielový stav kvality údajov v roku 2020:
Súčasné cieľe pre otvorené údaje sú stanovéné tak, že 70% údajov má byť na úrovni 5★, tj. musia byť popísané centrálnym modelom údajov verejnej správy a používať URI identifkátory.

Keď to prepočítam trochu presnejšie: V súčasnosti data.gov.sk obsahuje 1235 datasetov. Tj. pre ilustráciu, ak by mali byť splnené vyššie uvedené ciele už dnes (tj. 70% je 5★), bolo by nutné, aby z nich 864 bolo linked data, tj. aby boli popísané Centrálnym modelom verejnej správy s použitím URI identifikátorov na entity. Čiže, akoby sa to dalo splniť?
Aby boli uvedené splnené platí, že k existujúcim 1235 datasetom by muselo pribudnúť 2880 linkeddata datasetov, tj. celkový počet datasetov bude 4415 (70% je 2880). A toto je podľa nesplniteľná úloha, a to som zástanca LinkedData na maximum.

Pravidlá pre interoperabilitu otvorených údajov verejnej správy:
My, bojovníci za linkované verejné dáta :wink: sme navrhli tzv. Pravidlá pre interoperabilitu otvorených údajov - je publikovaná o pár príspevkov vyššie, tj. všetky nové datasety za verejné zdroje z centrálnou povahou 5★ inak 4★, pričom tie systémy ktoré sa nebudú inovované (mať zdroje) budeme radi keď sa dosiahne aspoň 3★. Toto bol výsledok dohody na pracovnom stretnutí K9.4. Zavedenie takéhoto prístupu by zaviedlo konečne systematický rozvoj ISVS, tj. dodávatelia by museli byť koordinovaný dátovou kanceláriou, resp. pracovnou skupinou pre dátové štandardy, čo by nesmierne zefektívnilo milión aspektov pri práci z verejnými dátami (jednotný model, jednotné identifikátory … proste tak ako to má byť).

Tak či onak, ani tieto skvelé pravidlá nedokážu zabezpečiť dosiahnutie horeuvedených cieľov, tj. 5★. Navyše, tesne pred dokončením dokumentu boli tieto pravidlá pre interoperabilitu zmenené tak, že boli prebraté cieľové hodnoty pre kvalitu údajov, tj. nie všetky nové publikované údaje za verejné zdroje musia byť 5★, ale len 70%, a podobne. Čiže jednak ešte viac sa týmto vzdialio plnenie cieľov, ale hlavne, ponechala sa možnosť, že dodávatelia štátnych zákazok nebudú musieť všetky robiť kvalitné dáta, ale urobia si veci po svojom. A neexistuje pravidlo, kto si to môže urobiť po svojom, a kto musí dodržať LinkedData. Takže v tomto sa nikde neposunieme, a keďže platí, že kvalita dát je pre celú informatizáciu kľúčová, opäť si môže robiť dodávateľ svoje projekty ako sa mu zachce. Sú to otvorené dvierka, ak máš problém, nech sa páči, takto sa to dá obísť.

Návrh riešenia:
Z tohto pohľadu je teda kriticky dôležité ponechať len Pravidlá interoperability pre otvorené údaje verejnej správy tak ako sú (všetko nové 5* za verejné peniaze…), a samotné ciele aj kľudne znížiť!, neviem odhadnúť na koľko presne, na 50%. 40%? Neviem, tak či onak by to bolo varenie z vody (nevieme koľko datasetov pribudne, nevieme koľko sa prerobí …).

2. Zverejnenie datasetov vs. ich skrytie za API

Ďalšie hlasovanie bude o tom, či majú byť dostupné datasety tak ako je to všade vo svete, tj. v otvorených formátoch, súboroch priamo na stiahnutie, alebo to majú riešiť API. Toto je podľa mňa mimo scenáru, pretože niečo iné je dataset a niečo iné je API, a to sa v prípade otvorených údajov nemá zamieňať. Otvorené údaje majú mať formu datasetu, ktorá má jednotný popis (v našom prípade je to použitie odporúčania Európskej komisie jazykom DCAT, atd. …). Skrátka, nie som proti otvorenému API, toto ale nemá nahradzovať klasické publikované datasety vo forme súborov, tak ako je to na ostatných svetových portáloch.

Na záver: minulý týždeň som sa stretol so zástupcami Európskej komisie (na konferencii Semantics v Amsterdame) kde som prezentoval náš prístup, a musím povedať že sa im to veľmi páčilo (v dohľadom čase majú o tom publikovať informáciu), pretože to absolútne napĺňa ich stratégiu, Lenže to by nebolo naše milované Slovensko, aby sa to niekde nezačalo škrípať. No hlasovanie je o týždeň, tak mi držte palce.


#113

Práve som dorobil konkrétne príklady úrovní interoperability pre ich predloženie na PS1, a keď sa na to tak pozerám, pravda je, že spôsob ako boli tie jednoduché pravidlá napísané, nebol celkom prehľadný, tj.

obrázok

Pretože

  1. ten druhý riadok, ktorý iba odporúča prerobenie údajov z 3★ vyššie, nie je pravidlo, ale iba odporúčanie a môže to odtiaľ vyhodiť a môže to byť len doplňujúca poznámka
  2. tie percentá (100%) tu potom nemá význam písať
  3. nielen z diskusíí na K9.4, či PS1 vyplynulo, že URI fyzickej osoby nemôže byť povinne referenčné (nutnosť ho používať) ale má byť sektorové, resp. odporúča to aj Európska komisia pri realizácii princípu 1xdosť v dokumente Access to Base Registers (No. 14), takže výsledné pravidlá pre interoperabilitu, ktoré budú predložené na K9.4 (a podrobnejšie aj na PS1) vyzerajú takto:

Keď sa tieto pravidlá schvália na SP Otvorené údaje, pričom už o tom bola na stretnutí dohoda, tak tieto pravidlá patria do zlatých základných pravidiel, ktoré posunú slovenskú informatizáciu. Akiste je ešte takých pár, a bolo by skvelé ich povedať (ak má niekto na to svoj názor), aby vzniklo napr. 5i (interoperabilita, informovanosť … )


#114

ahojte,

dovoľte mi ešte pred zajtrajším dôležitým hlasovaním vyjadriť sa k nemu (ku konkrétne dvom bodom spojených s cieľmi a princípmi LinkedData). Tie body nie sú o tom, či Centrálny model údajov a URI je správny prístup, alebo nesprávny. Hlasuje je sa o tom, ako silno/systémovo má byť linkeddata prístup zavedený. Či má existovať povinný centrálny dátový koordinačný orgán pre ISVS, ktorý bude koordinovať a vynucovať dodržiavanie dátových štandardov, alebo bude na svojvôly dodávateľa štátnej zákazky, aké dáta si vytvorí. Samozrejme také dáta budú len veľmi ťažko dbat na interoperabilitu s inými datasetmi od iného dodávateľa, čiže vždy treba všetko opakovane integrovať nanovo. Súčasný nevyhovujúci stav.

O čom sa teda hlasuje?

Možno sa teda strácate, že @Lubor toto podporuje, veď od slovenska.digital by sa toto očakávalo, tento prístup. Ja som teda už tiež stratený. :wink: lebo opak je pravdou. Tesne pred ukončením dokumentu

1)

Lubor navrhuje aby skrátka nemuseli byť otvorené dáta publikované ako datasety, ale postačia len API. A to teda najmä pre úroveň 4* a 5* (hoc takmer na každom gov portále je ZVÝRAZNENÁ podpora linkedata) .

Všiimnite si plís SPARQL Search priamo na uvode Europskeho data portalu

Teda nebude sa dať stiahnuť súbor, čo je základná požiadavka na open data, ale bude musieť postačiť API. Pritom takmer na každom gov open data portály sú formáty RDF, OWL publikované.

a dokonca už aj na našom data.gov.sk sú publikované prvé LinkedData

Takže v tomto prípade dúfam, že API nemôže nahradiť otvorený dataset. Ten je základnou formou reprezentácie open data. Ale určite je dobré mať aj API, ale nenahrádza ho.

2)

Hlasovanie o pravidlách interoperability otvorených dát pre nové datasety za verejné peniaze

  • Toto už bolo na dvoch stretnutiach dohodnuté, tj.
    Nové dáta 4*, Nové centrálne dáta 5*, Publikačné minimum 3*

Avšak chybou sa to stotožnilo s percentami pre Cieľový pomer počtu datasetov (70% zo všetkých má byť 5*).

Tu má platit vyššie uvedená definícia (bez percent). Je to ale veľmi kľúčové, je to učite zatial najdôležiteľší pilier dátovej interoperability na Slovensku, tj. systémové zavedenie linkedata. Tak nech sa prosím čo najviac schváli nahlas.

Ide o to, aby nemohli niektorý dodávatelia ignorovať štátne dátové štandardy - na identifikáciu (URI) a popis údajov (Centrálny model údajov verejnej správy). Nielen že dátová interoperabilita je prínosná pre tvorbu aplikácií, tvorbu dátových analýz, prehliadanie a objavovanie všetkých vzťahov entít so súvisiacimi entitami, ale dátová interoperabilita je kľúčová aj na efektívnu integráciu rôznych dodávateľov, ciže tu vyhráme všetci. A dôležité je, aby sa toto nedalo obchádzať, aby to malo systém, dalo sa to kontrolovať, rozvíjať, a podobne.

@lubor často argumentuje - “som proti novym projektom ktore potrebuju financie a technológie, ktoré nemám rád” :wink: “Čo keď všetko bude tunel, vy si chcete iba postaviť dom pri mori”, “najlepšie bude počkať až kým to bude niekde inde opensource (historický okamih)”. tu ale nejde o to, pretekať sa s rakúskom, anglickom, holandskom a tak ďalej, kto vie utratiť peniaze. napísal si, že “koľko bude sranda ako dereferenciácia stáť”. A marek Ti odpísal, že nie veľa, že ide o nastavenie presmerovania + univerzálnu stránku nad ľuvovoľnou entitou. Celý centrálny model údajov sme urobili zadarmo za 3 roky, a bol od začiatku publikovaný tu, a bol aj schválený na PS1. Predstav si. Takže to máme náklady ďalšie dolu. Už je v metais subsystém na registráciu URI a všetky entity v ňom majú URI. Ďalšie náklady preč. LOD Slovakia predstavuje zadarmo príklady prepojenia kľúčových referenčných registrov. Ďalšie náklady dole.

Veď podme to vyskúšať, o čom snívame. Centrálne spravovať dátové štandardy, aby boli dáta ISVS interoperabilné, a s takými dátami sa dá robiť všetko oveľa efektívnejšie. Otázka nákladov je samozrejme na mieste. Čo nám môžu také dáta priniesť? pre človeka, novinára, vývojové firmy, štát, eú, výskum, iot … ako toto vyčísliť? Neviem. Ale stanoviť si hru v informatike, a dávať pozor ako sa hrá, to podľa mňa vieme dať.

Prosím preto otvorene o podporu @hanecak , @mtuchyna, @msurek, ale aj @jsuchal @Lubor :wink: resp. všetkým ostatným samozrejme, ktorí si myslia že toto je cesta.

Čiže v tomto prípade pre nové open dáta VS za verejné zdroje platí: Nové dáta - aspoň 4★, Nové centrálne dáta - 5★, Publikačné minimum 3★

ktoré prispôsobujú postupné zavedenie linked data o ohľadom na zdroje. Ak sa robí veľký projekt dodávateľom a robí open data, tak jednoznačne musí dodržať URI + centrálny model. Ak ale nie sú dukáty, tak umožniť hociku vôbec publikovať aspoň niečo.

Ešte mi toto dovoľte zakončiť screenshotom s dokumentu

European Data Portal
Open Data Goldbook for Data Managers and Data Holders
Practical guidebook for organisations wanting to publish Open Data
4. Putting in place an Open Data lifecycle
4.1. Collecting data.
4.1.5. The Final Check::Check if metadata is described as LinkedData :blush:
POST5

ďakujem všetkým za podporu


#115

Tiez som sa pri hlasovani na ostanej K9.4 uz zacinal stracat, ale teda v dokumente v0 5_SP_Otvorene_udaje.docx je teraz (26.9.2017, 23:19) v kapitole “2.1.2 Zlepšiť dostupnosť údajov verejnej správy vo forme otvorených údajov” toto:

Zvýšiť kvalitu publikovaných údajov štátnej správy

  • Podiel datasetov publikovaných minimálne v úrovni kvality 3★ (http://3stardata.info/ ) : 100%
  • Podiel datasetov publikovaných minimálne v úrovni kvality 4★ (http://4stardata.info/) s vysokým potenciálom na znovupoužitie : 90%
  • Podiel datasetov publikovaných minimálne v úrovni kvality 5★ (http://5stardata.info/ ) s vysokým potenciálom na znovupoužitie: 70%
  • Podiel datasetov publikovaných prostredníctvom aplikačného rozhrania (API): 70%

S takymito cielmi suhlasim.

Upresnenie pojmov:

  • tyka sa len/primarne “novych datasetov”, t.j. tych ktore vzniknu pocas implementacie novych alebo upgradu existujucich ISVS vramci OPVII (2018-2020)
  • 4* a 5* sa tyka len casti “novych datasetov” (to je to spojenie “s vysokým potenciálom na znovupoužitie”) ktore v kontexte SP Menezment udajov (cast “2.1.5 Prepojené dáta (Linked Data)”) znamena primarne “v rozsahu katalógu dátových prvkov, referenčných registrov, základných číselníkov a entít MetaIS s registráciou daných URI v MetaIS” a mozno niektore dalsie dolezite datasety (zalezitost posudi UPVII resp. centralny datovy kurator … dufajme ze aj nadalej v spolupraci s odbornikmi a verejnostou :slight_smile:)

S tym suhlasim (vid https://utopia.sk/wiki/display/opendata/Design+Open+Data+API ). Ale opat este ujasnenie pojmov:

Cize na PS bol IMHO chaos o.i. aj kvoli terminologii, kedy sa (asi) pozabudlo na to, ze pod 3*, 4* a 5* sa primarne myslia suborove dumpy. Kedze v dnesnej dobe bezne robime “multimodalne” (t.j. ta ista vec je dostupna vo viacerych “serializaciach”, typicky HTML, XML a/alebo JSON, zvykne byt pouzity aj HTTP autonegotiation), tak pridanie nejakeho 4* RDF je vcelku trivialne (a 5* je v SP “trochu orezane” na “dolezite veci”, cize nebudu a s nim trapit vsetci a ti co budu, budu to robit v spolupraci s centalnym datovym kuratorom/kancelariou).

Povedane inak, “dumpty su zvycajne lahke” (a ked nie, robi sa Open Data API) a teda vysoke ciele pre nove datasety na urovni 4* by nemali byt rizikom. A vysoke ciele pre 5* su IMHO tiez OK, kedze sa tykaju “uzsieho vyberu dolezitych datasetov”. A vcelku vysoke ciele pre Open Data API su … opat … IMHO OK.

A navzajom sa (zvycajne) nevylucuju. Samozrejme musime uznat, ze ak sa bude robit aj dump aj API (Open Data), tak to bude stat o trochu (ale nie 2x) viac nez keby bolo robene len jedno. Ale kedze balik OPII na Open Data sa rata na urovni 30-60 prip. viac milionov € a ze napr. vcelku komplikovane Open Data API RegisterUZ stalo cca 20 MD, tak by tym rozpocet na Open Data nemal vyrazne trpiet (“trpim” skor pri pohlade na niektore ine polozky v sekciach “projekty” :slight_smile: ).


Komisia pre štandardy ISVS - PS1
#116

Priatelia, kolegovia,

dovoľte aby som poďakoval všetkým, ktorý pomohli s presadzovaním LinkedData do verejných údajov SR. Jedným zo schválených bodov dnešného hlasovania sa dosiahlo že:

Všetky nové a inovované ISVS publikujúce otvorené údaje s centrálnou povahou (referenčné údaje, centrálne registre, údaje v rozsahu metais, resp. prioritné datasety, publikačné minimum samosprávy, publikované údaje a poskytované elektronické služby miest a obcí - DCOM …(to sa presne ešte dopresní)) musia byť publikované na úrovni kvality 5★, tj. musia používať URI (Jednotný referencovateľný identifikátoro /jednotný identifkátor zdroja/) na identifikáciu údajov ISVS a Centrálny model údajov verejnej správy na ich popis.

Dôležité je, že kľúčová rola na centrálnej úrovni, tj. Centrálna dátová kancelária, ktorá je v súčasnosti reprezentovaná K9.4 a PS1, začne koordinovať vývoj ISVS a aktivity dodávateľov s ohľadom na ich celkovú interoperabilitu v prostredí ISVS verejnej správy. Skrátka, aby sa eliminovali zblúdené ISVS aj technologicky, aj poslaním. :innocent:

Ešte raz vďaka všetkým, ktorí prispeli. Nebolo ich málo. :slight_smile:


#117

Len jedna poznámka špeciálne k tomu API.
Ak mám porovnať súborové dumpy a prístup cez API, tak:

  • API je online, súborové dumpy už z povahy veci sú iba obraz histórie
  • API umožňuje jemnejšiu granularitu požiadaviek (napr. vypýtam si jeden konkrétny objekt)

Tým pádom niektoré situácie sú extrémne nevhodné na riešenie cez súborové dumpy, napr. datasety ktoré sa rýchlo menia, alebo sú veľké. Povedzme v katastri nehnuteľností (klasický to príklad asi na všetko) nastáva zmena v priemere každé cca.2-3 sekundy, je v ňom 15,6 milióna parciel (C+E), 28 miliónov subjektov, ak si správne pamätám viac ako 100 miliónov vzťahov. Ako budeš toto prakticky a efektívne modelovať súborovými dumpmi? Lebo teda API je k tomu jednoduché a priamočiare.

…čiže 1) API je plnohodnotný, štandardný, flexibilný a využívaný prístup k údajom, aj otvoreným údajom, nie žiadne “skrytie” 2) pri dôležitých dátach, alebo nových IS za prioritu považujem prístup k údajom cez API a “klasické publikované datasety vo forme súborov” za podružné, v niektorých prípadoch až nevhodné

A druhá poznámka k identifikátoru fyzickej osoby: Pokiaľ ide o interoperabilitu (nie interné uloženie v IS), je určenie jedného, konkrétneho, univerzálneho identifikátora nevyhnutnosť. Toto sa týka najmä komunikácie G2G. Ochrana súkromia sa vykonáva skúmaním oprávnenosti sprístupniť údaje. Rovnako pri zverejňovaní identity fyzickej osoby (tam kde je to dovolené, alebo prikázané) je nevyhnutné, aby bol použitý jej univerzálny identifikátor - práve preto, že ináč by som vlastne nevedel kto tá osoba je, čím by nebol naplnený účel zverejnenia.


#118

Suhlasim s tym, ze na niektore veci je lepsie API a na niektore zasa datasety a vsetko ma svoje specificke usecases takisto ako svoje naroky. Musis ale uznat ze forma publikacie by nemala byt v kolonke kvalita udajov a ani sa s nou spajat, pretoze jedna hovori o ich reprezentacii a druha zasa ze ci to bude subor alebo API.

Kazdopadne vidim, ze viac asi v tomto pripade hovorime o OpenAPI co sa riesilo v Lepsie sluzby a ta skupina to podrobne rozoberala a tym padom prave ona je podla mna relevantna aby pomenovala tento ciel lebo najlepsie pozna ake dopady to ma aj na ostatne veci. Kazdopadne sa to na skupine rozdelilo do dvoch separatnych cielov(jedna je publikacia a druhy je kvalita), kde sa stanovilo ze
70% dat publikovanych cez API
90% dat publikovanych ako dataset
co je podla mna dobry ciel.

Osobne som tej skupine bol len par krat, takze sa to mohlo vyvinut, ale pamatam si ze sa tam hovorilo aj o nejakej API Gateway, o moznom pouziti API kluca a mozno az spoplatneny pri nadmernom zatazovani. Treba si uvedomit, ze ak si 500 systemov komercneho sektoru zacne robit API tisice requestov na kataster(zadarmo) tak ten spadne ako nic a preto treba mat aj tento pristup riadeny. Suborovy dump je z tohto pohladu menej aktualny ale menej zatazujuci koncovy system. Mozno na ucely odhalovania podvodov na katastry nepotrebujes mat realtime API, ale staci ti zbehavat aj dlhotrvajuce joby. Vsetko je to case od case. Mozno ze by bolo fajn ak by si mal o tom prezentaciu na skupine ak vies viac ze ako je to navrhovane. Minimalne z informacneho charakteru by to bolo podla mna super.


#119

Pointa OpenAPI je trosku inde. OpenAPI je hlavne o pristupe k datam a sluzbam, ktore zo svojej povahy nie su verejne. Napriklad vsetky data o mne (auta, rodinny prislusnici, etc) a potom sluzby (napriklad pristup do schranky, moznost prevziat spravu do vl. ruk).

To co lubor riesi je API na verejne data (open data). Ono vo vynose to uz davno je, nevymyslajme koleso https://www.slov-lex.sk/pravne-predpisy/SK/ZZ/2014/55/#paragraf-53 (odstavec e)


#120

Sluzby katastra su preto vnimane ako co? Open Data API alebo Open API? Jediny rozdiel ktory vnimam je jedno je read only, ale z pohladu pristupov, ktore popisujem sa to nema riesit rovnako? Tj. scenar ktory som popisal s katastrom, zostane nemanazovany takze ked oni vypublikuju to API tak tam im mozu chodit tisice requestov, ktore oni budu musiet obhospodarovat zadarmo a mat k tomu aj SLA? Daju sa povedat jasne pravidla, ze kedy povazujem read sluzbu za OpenData API a kedy za Open API?


#121

Ja to chapem takto: OpenAPI je nadmnozina. Zahrna aj API na otvorene data aj API na sukromne data, aj pripadne aj write operacie.


#122

A v lepsich sluzbach sa vymysleli mechanizmy ako riesit pristupy? Myslim z pohladu najekeho manazmentu kolko pristupov ma kto povolene resp. predplatene tj. nieco co mozno mal aj tento dokument referovat v zmysle “Data budu zverejnovane prostrednictvom nasledovneho procesu a komponentov”? Inak fakt by mozno nebolo naskodu si spravit nejake obojstranne prezentacie aby boli tie veci synchronizovane.


#123

Ahoj,

pozri multichannel 4.2.3 Open API ako spúšťač prístupu k službám VS z tretích strán (partnerstvo), tam je to HL vysvetlene.

Projekt Open API (nie Open Data API) by to mal dotiahnut do detailu…


#124

Ahoj,
pozeram je to tam dost highlevel s referenciou ze maju vzniknut nejake metodiky a standardy v tejto oblasti ako sa to bude realizovat. Ked hovoris ze projekt Open API… to je nieco existujuce alebo planovane v nejako dohladnom case? Ide mi hlavne o to ze ci sa da niekde referovat ze Open API bude implementovane v zmysle dokumentu/standardu/metodiky ako povinnost pre dalsie projekty.

Ten dokument sa publikoval pred pol rokom ale skupina co viem stale prebieha tak ci sa tam taka vec nerozvijala popripade ci je uz priradena nejaka zodpovednost nejakej standardizacnej PS aby take nieco vzniklo.


#125

Draft dokumentu Strategickej priority pre Open Data:

verzia do ktorej môžete písať komentáre

verzia na stiahnutie:v0 92_SP_Otvorene_udaje.docx (471.1 KB)

Teraz je záverečné pripomienkovanie, 18.10. pripomienky prerokuje pracovná skupina.

Pozornosť čitateľa by možno zaujalo zopár špecialitiek, napr:

  • nové služby typu “archív otvorených údajov” (napr. str. 48), “nástroje umelej inteligencie”, “štátny github”, “blockchain”, “úložisko pre otvorené dokumenty” (všetko str. 42) - po ktorých túžia určite davy používateľov, len sa zatiaľ dobre ukrývajú
  • explicitne uvedené projekty pre “otvorené údaje v školstve” a zdravotníctve (str. 51), pričom kvalita tých projektov je zatiaľ asi takáto (mizerná)

Komentáre sú vítané, najmä teda do 17.10.


Komisia pre štandardy ISVS - PS1
#126

preco tolko ironie? ved tam Urad pise o proof of concept, nie o plosnom nasadeni blockchainu. Doteraz sa tu kritizovalo ako je Slovensko malo inovativne a ked ide UPPVI s dobou tak je to zle? Napr. ja som za, aby sa ten proof of concept vyuzitia blockchainu zrealizoval a nielen ja https://www.europeandataportal.eu/en/news/open-data-blockchains-missing-link-opening-governments


#127

Je to nanestastie tak. Nehovorim ze blockchain je najdolezitejsia vec na svete, alebo aj ine z menovanych, skor ide o to ze ked sa ani napady, ktore maju hlavu a patu budu automaticky radit do kategorie ulet tak potom sa na konci obdobia budu robit take projekty, ze skonci to mozno aj horsie ako obdobie predtym (lebo nebudu vlastne existovat dobre napady, ktorymi sa bude dat naplnit scope ). Len pre porovnanie Estonsko ma uz N sluzieb na blockchaine : https://e-estonia.com/solutions/security-and-safety/e-law a funguje to. Ale niekedy je vyhodne sa porovnavat s Estonskom a brat si ich za vzor a niekedy zasa nie. Podobne plati aj o zvysnych temach.
Elementarny problem totiz podla mna nie je ani tak v temach, ale v ich vyslednej realizacii. Popisanych a akceptovanych veci, ktore boli “odovzdane” v minulom obdobi bolo tolko ze viac menej si zijeme v nadigitalizovanejsej krajine na svete. Ved aj sluzba na ktoru sa integruje GovBox funguje (to ze za normalnych okolnosti banalna integracia stala @jsuchal pol roka zivota a 3 roky popritom zostarol je druha veec). Na dopracovanie peniaze nie su a ani nie je mozne povedat EU ze tie akceptaky boli odrb a ze potrebujeme peniaze na to iste, lebo vlastne hento bol odpad. Deadlock. Podla mna je preto dolezite nastavit mantinely kvality a priebeznych kontrol pri projektoch, priebezne zverejnovanie zdrojakov, … a nie potapat napady, ktore maju aspon hlavu a patu.


#128

tiež sa divím, ak sa spraví POC, riadny tender - kludne mikroobstaravanie, zdrojaky budu na githube, tak kde je problem?
naopak vitam ze @juraj.bardy to tam dal, kludne aj viac takychto tem, aspon sa to preveri, prediskutuje a uvidi sa


#129

I talk about how RDF and linked open data are a waste of their time—that there’s no meaningful ecosystem around them

Keby ste niekto nevedeli tak. https://waldo.jaquith.org/about/

I used to be the Director of U.S. Open Data and a Shuttleworth Foundation fellow. Now I work for 18F.