obraciam sa na vas s moznostou spoluprace pri vydefinovani datasetu v strojovo spracovatelnej podobe pre oblast implementacie eurofondov v SR v programovom obdobi 2014 - 2020, ktore su/budu spracuvane v ramci ITMS2014+.
Dataset bude publikovany prostrednictvom API a sluzieb v ramci projektu eDemokracia, ale zaroven predmetne API bude aj verejne dostupne.
Cielom je poskytnutie verejnosti takych dat o eurofondoch, ktore verejnost zaujimaju a ta ich vie dalej pouzit a vytvarat dalsie aplikacie. Nie je efektivne a ani fyzicky mozne, aby sa v ramci verejnej casti ITMS2014+ vytvarali vsetky funkcionality a sluzby, po ktorych je spolocenska objednavka, alebo mensia skupina ludi ich povazuje za dolezite a ina skupina zasa nie, lebo povazuje nieco ine za dolezite a pod.
Strategia tvorby datasetu je iterativnym, lean sposobom…proste rozsirovat dataset o take data, o ktore je zaujem a ktore prinesu pridanu hodnotu a komunita ich vie spracovat. Plus sa pocita s tym, ze na prvykrat sa netrafi cela struktura a bude sa dopracovavat
Bolo by som rad za konstruktivny feedback, resp. konkretne priklady zatial k tymto bodom:
1. vydefinovanie konkretnych dat, informacii a struktur, ktore komunitu zaujimaju z oblasti eurofondov - pripravujem zakladny nastrel struktury (bude tu publikovane),
2. definovanie formatov a standardov, ktore sa odporucaju na na publikovanie,
3. hinty, odporucania a ake su standardy pre vytvorenie dokumentacie popisujucej API, datovu strukturu datasetu, a pod.
Skvely priklad moderneho, ale stale praktickeho API je https://developer.github.com/v3/ co sa tyka dokumentacie, ja osobne mam rad veci ako https://apiary.io/ alebo https://getsandbox.com/ alebo http://readme.io/ - specialne apiary je vyborny na rychle prototypovanie API, bez nejakej zbytocnej zataze programatorov. Nasledne to vie sluzit aj ako “vykonatelna specifikacia” pre API.
V domene eurofondov sa velmi nevyznam, ale zasadou je publikovat data v co mozno najnizsej granularite, takmer az tupe raw data. Akekolvek filtrovacky, analytiky nad tym su nice-to-have a zalezi od konzumentov ci take nieco ma zmysel robit na strane u vas alebo u nich. Mate identifikovanych nejakych realnych konzumentov tychto dat? Tam by bolo dobre zacat.
este by bolo vhodne pouvazovat aj nad tym, ze by tam mala byt aj informacia o prepojeni na ine projekty,a by sa dala sledovat opodstatnenost projektu aj casovy sulad s vystupmi.
Okrem toho aj informacia ako projekt prispieva k naplneniu cielov programu.
Uplne na zaciatok jedno zakladne voditko: Nesnazit sa robit veci na dva krat: raz “normalne” (na internu potrebu) a raz “Open Data”.
Stava sa, ze niektore interne tabulky mozu obsahovat nieco “citlive” (a teda SELECT * ... by pre Open Data nebol dobry), ale zvycajne sa nad tou internou tabulkou da spravit aj iny - verejny - pohlad (SELECT verejna_vec_1, ...).
Tiez je mozne, ze Open Data budu robit na system vacsi load. Vtedy sa da spravit druha read-only replika (pripadne s mensim objemom dat - vid vyssie).
Dalej, par konkretnosti (o.i. doplnim, co nacal @jsuchal).
Ako naznacil Jano, prioritou maju byt “raw data”. Dovody:
Ak to v nejakej strukture potrebuje (resp. mu staci) niekto na urade, malo by to stacit aj 3rd party developerom. (ak by ta struktura nevyhovovala ani samotnemu uradnikovy, nuz to by bol dovod na prerobenie IS ) A teda aby sa veci nerobili dvojmo, zvrejni sa to co je tak ako je.
Sumare a priemery limituju re-use, lebo sa napr. na agregatoch uz nedaju urobit niektore druhy analayz a pod.
Zverejnenie “raw dat” sa zvycajne robi najlahsie zverejnenim dumpov. Najma ak na zaciatok nie je jasne, komu by to na co bolo.
Potom, ked sa na tie dumpy uz niekto pozrie a bude mat otazky, da sa s nim viest zmysluplny dialog na temu ci aj API a ak ano, ake.
Ak je aj tak chcene robit API hned na zaciatku, tak dobry pristup je “API first”, t.j. vyuzit to, ze sa robi uceleny IS ktory bude poskytovat niekomu nejake (zmysluplne) funkcie. Zjednodusene: IS ma zvycajne back-end a front-end. Nuz a “API first” znamena, ze sa spravi back-end, nad nim sa spravi API a front-end vyuziva (len) toto API. A to API sa potom (mozno po drobnych upravach) reusne aj pre Open Data (idealne pamatat na to uz pri designovani API).
Ako uz tiez pisal @jsuchal a ini, netreba sa snazit mat to “100% super” hned na prvy krat. Treba spravit beta verzie, treba to nechat ludom pripomienkovat, netreba sa bat veci redesignovat ak testy ukazu ze nieco nie je uplne OK.
subory (a.k.a. dumpy): CSV alebo XML (idealne taky, co sa da otvorit v tabulkovych procesoroch)
Co najviac veci ma byt jasnych uz z pozretia sa na URL a z obsahu toho, co z daneho URL dostanem. Dokumentacia ma byt co najstrucnejsia (ak strucna dokumentacia nestaci, zrejme je nieco zle v API alebo je nejako “vadny” uz cely IS ).
A ako spomenul @Neco, je dolezite nejako “linkovat” jednotlive datove zaznamy na dalsie “dokumenty”. K tomu doplnim, ze ak referencujeme “mimo vlastny dataset” (t.j. na data niekoho dalsieho), je idealne pouzit URL (referencovatelny identifikator, ktory ked zadam do browsera, ziskam informacie tykajuce sa daneho “ID”). Ak sa neda, tak ine jednoznacne ID (a v dokumentacii napisat, ze kde a ako si info k danemu ID potom inde viem dohladat). Priklad: Zaznam o prideleni penazi by mal obsahovat zrejme ICO (toho, kto nieco z fondov dostal a … uz kvazi vsetci vedia, kde si maju ist hladat podrobnosti o organizacii na zaklade ICO), mala by tam byt linka na suvisiace dokumenty (ziadost, jej prilohy, dekret o schvaleni, …), atd.
V prvom rade dik za reakcie, nazory, postrehy a rady…dufam, ze tato debata bude pokracovat dalej a spolocne vydefinujeme pouzitelne API, ktore bude moct verejnost, komunita bezproblemov pouzivat…napada ma vela moznych aplikacii a pouziti spristupnenych dat, ktore vedia byt zaujimave pre odbornu a aj laicku verejnost.
@otopse realna schema implementacie fondov je zlozitejsia…v scheme v tvojom prispevku chybaju este dalsie dolezite entity, ktore verejnost a dokonca ani prijimatelia nevnimaju alebo ani nepoznaju. Dokonca pre programove obdobie 2014 - 2020 budu uplne nove entity a to dost dolezite pre implementaciu fondov. Toto nie je ziadna chyba tvojej schemy…postupne vydefinujeme vsetky potrebne entity/struktury.
Ako pisal @hanecak tak na prvykrat sa nepodari trafit vsetko na 100% a preto som premyslal nad strategiou, ze zverejnovanie by kopirovalo realny stav procesov implementacie fondov v SR a v ITMS2014+, t.j. v prvej iteracii by sme sa pozreli na data o Operacnom programe, Vyzvach na predkladanie ziadosti o NFP, konkretnych schvalenych/neschvalenych ziadostiach o NFP, o realizacii projektov (podpisanej zmluve o prideleni NFP), ziadostiach o platbu v ramci projektov. Nasledne, neskor sa moze ist na dalsie entity ako je napr. verejne obstaravanie a ich vazby na jednotlive projekty, identifikovane porusenia a nezrovnalosti v ramci implementacie fondov a pod.
@jsuchal aktualne by som konzumentov rozdelelil nasledovne:
konzumenti s konkretnymi poziadavkami a poziadavkami na API - napr. IS SOFIA pre uctovnictvo vysokych skol, IS UPSVR SR - ale tu od konzumentov chyba take strategickejsie a komplexnejsie zamyslenie sa nad strukturou, ktoru potrebuju
konzumenti (IS), s ktorymi este len zaciname dialog o ich potrebach, ale tiez sa to crta hlavne na API
verejnost, komunita - ich poziadavky nepozname, iba vieme odhadnut, co by ich asi mohlo zaujimat a preto otvaram tento dialog
@jsuchal@hanecak celkom nemam jasno v tej “raw” podobe. Sumaciam a priemerom som pochopil, ze nie su ziadane. Cize “raw” podobu mozem chapat takto…napriklad ked uz sa vydefinuju publikovatelne udaje, cize potom teda nejdem za niekoho robit sumaciu, priemery a pod., ale poskytnem tie definovane data v najsurovejsej podobe aku mam?
Ano, v principe vypublikujes domenovy model a k nemu data - vsetko co moze byt verejne. Ako prve priblizenie ja vzdy rozmyslam normalne copy-paste db schemy a nad tym spravis nejake zakladne sluzby ako findByPK a synchronizacne API. Pridas tam odkazy na cudzie kluce/entity. Vsetko ostatne si konzument vie vyskladat, ak nevie, tak sa ozve.
Tou schémou som chcel len podčiarknuť, že kým nepoznáme proces a dátové entity, dovtedy nemá veľký zmysel baviť sa o ich štruktúrach a API. Ak sa proces od r. 2014 mení a ak ho dokonca nepoznajú žiadatelia ktorí sú jeho účastníkmi, potom je o to dôležitejšie začať priamo ním.
Mám tiež obavy, či táto debata nie je čisto hypotetická - ak tomu dobre rozumiem, eDov aktuálne nemá v sebe žiadne dáta o eurofondoch a potenciálny záujemca môže pre ne klopať priamo na dvere jedn. RO/SORO a nečakať, kým na tie isté dvere raz zaklope eDOV.
Kde je vlastne GUI k eDOV? Toto je ono? https://data.gov.sk/
Aha, rozumiem. Ale to je potom celkom jednoduché, publikujte ten istý excel ako doteraz, len tam doplňte neschválené žiadosti, neorezávajte názov projektu, a doplňte chýbajúce polia: číslo výzvy, prioritnú os, č. opatrenia, stručný popis projektu a jeho hl. parametre (v rozsahu ako napr. Česi), prijímateľa včítane IČO a adresy, počet získaných bodov hodnotenia, dátum podpísania zmluvy alebo dôvod odmietnutia žiadosti, č. zmluvy a link na uverejnenú zmluvu, trvanie projektu, link na VO, zoznam realizačných zmlúv medzi prijímateľom a dodávateľmi - meno dodávateľa včítane IČO a adresy, cenu, č. zmluvy a link na uverejnené zmluvy.
Rovnaký excel by bolo potrebné publikovať aj o výzvach a ďaľší o auditoch…
A publikujte ich nie 1xmesačne, ale nechajte ich vygenerovať každú noc…
A ideálne by bolo samozrejme zahrnúť do ITMS aj vśetky ostatné dotačné schémy EÚ alebo súvisiace s EÚ včítane cezhraničných, INTERREG, švajčiarskych a nórskych fondov, poľnodotácií oboch typov, atď.
Ad OpenData: ako už viacerí spomínali, treba to spraviť čo najviac priamočiaro. Čiže sprístupniť údaje v takej štruktúre, aký je interný doménový model. Predpokladám že je to relačný model. V takom prípade skrátka vytvoriť z každej tabuľky dataset, ponechať v nich aj interné identifikátory potrebné na zaistenie ref. integrity. Pridať do tabuliek (kde to má význam - napr. v číselníkoch nie) informáciu umožňujúcu zistiť zmenené údaje - najjednoduchšie je pridať atribút s časom poslednej zmeny riadka.
Môj názor je, že nerobiť ani žiadne špecifické API (aj to že o tom v diskusii špekulujeme dáva tušiť že to nie je optimálna cesta). Údaje sprístupniť cez SQL endpoint. Vytvoriť k tomu jednoduchú dokumentáciu s príkladmi query. Používateľ si vytvorí vlastné ako potrebuje.
Ak model nie je relačný, ale objektový - gratulujem. Vtedy produkovať priamo LOD do triplestore.
Ak model je ad-hoc, čiže primárna reprezentácia údajov nie je v DB, ale povedzme v excel súboroch, tak skrátka sprístupniť tie súbory + dump do csv.
Ad eDOV: pokiaľ viem, tento projekt obsahuje samostatný modul “ITMS OpenData”. Čo/ako v ňom je neviem, ja som tento modul neriešil.
Pokiaľ ide o MOD (modul OpenData), jeho frontend je naozaj data.gov.sk. Ak je záujem, v rámci MOD sa dajú vytvoriť vyššie spomínané datasety so SQL endpointom (t.j. nahrávať dáta do rel.DB), alebo SPARQL endpointom (triplestore), či nahrávať súbory. V katalógu následne vytvoriť k nim metadáta.
dik za reakciu…nastrelime strukturu a dame pripomienkovat
Ad audity: v ITMS II a ani ITMS2014+ nie su a nebudu v nejakej vacsej podobe…MF SR ako organ auditu pre eurofondy v SR ma vlastny IS tzv, CEDIS…pokusame sa o integraciu s tymto IS, aby sme aspon zakladne info o auditoch dostali na podporene projekty v ITMS2014+
Ad ostatne dotacne schemy: v ITMS II a aj ITMS2014+ su len vybrate operacne programy…projekt eDemokracie ma taku ambiciu zhromazdit na jednom mieste datasety z roznych IS, ktore sa tykaju dotacnych schem…cize napr. ITMS2014+, ako jeden z IS spravujuci urcitu oblast dotacii, sem ma poskytovat dataset v strukture a sposobom, o ktorych sa bavime v ramci tohto fora
no vtip je v tom, co ja mam info, ze tento modul projektu eDOV ma riesit datasety aj inych dotacnych schem ako napr Program rozvoja vidieka, rozne dotacie v ramci vyskumu mimo eurofondov a pod…aspon tak bola pisana “DFS”…vzhladom na tieto fakty je nazov modulu dost zavadzajuci…ale to je uz ina tema ako ta, ktoru sa snazim v tomto fore riesit…
S touto požiadavkou (resp. požiadavkami) sa viem dosťstotožniť.
Vypichol by som hlavne to, aby fakt bol niekde pokope zoznam realizačných zmlúv s jasnou identifikáciou dodávateľov.
K tomu celému by som pridal ešte údaje o osobách, ktoré sa podieľali na
rozhodovacom/hodnotiacom procesue.
Chapem Peta, problematika cerpania Fondov (konkretne Kohezneho a Strukturalnych) je tak (umelo?) zamotana a zlozita, ze podla mna sa Petrovi zda nie celkom koser publikovat surove data na urovni domenoveho modelu … Tie data chcel zjavne predpripravit (zjednodusit, okliestit, skumulovat) tak aby boli zrozumitelnejsie. Ale to sme zasa podla mna vkrocili do domeny Data Science a napriklad jazyka R. Podla mna je treba vytipovat a vytviorit ZROZUMITELNE objekty (vychadzajuce z objektov a vztahov domenoveho modelu, ale enkapsulovane do samostatnych objektov na prezeranie) v JSON strukture, ktore mozu byt publikovane na zdokumentovanom API (samozrejme po prideleni nejakeho API KEY, a s daslimi ochranami proti utokom). Ale s ich vytipovanim myslim ze najviac skusenosti bude mat prave CKO. Inac vzniknu nezmysly a dezinterpretacie.
Ja by som sa riadil sedliackym rozumom. Pojmy, na ktore sa pytaju novinari, ktore sa davaju na stol do vlady, pojmy(miery) , ktore sa nachadzaju v BI a ich filtrovanie (cez dimenzie). A to mi evokuje, ze ak je dobre navrhnute BI, tak tym API by mohli byt prave requesty do multidimenzionalnych kociek, kedze tam su uz miery a dimenzie definovane pomerne zrozumitelne aj pre laikov.
v zmysle zakona o eurofondoch pre programove obdobie 2014 - 2020, t.j. zakon c. 292/2014 Z.z. su RO/SO okrem inych udajov povinne zverejnit aj mena hodnotitelov ziadosti o NFP
Ak je to neverejný údaj, tak to je celkom na hlavu a bolo by fajn to zmeniť.
Zloženie výberovej komisie pri verejnom obstarávaní sa zverejňuje už pár rokov a pri zverejnení členov týchto komisií nevidím principiálny rozdiel. Bezpečnosť hodnotiteľov je pseudoargument.
) A teda aby sa veci nerobili dvojmo, zvrejni sa to co je tak ako je.