Register partnerov VS - OpenData


#1

Od 1.2.2017 fungujúci Register partnerov verejnej správy bude poskytovať od začiatku zrejme aj OpenData. Podľa popisu to bude REST API a dokumentácia cez swagger. :+1:
https://www.justice.gov.sk/Stranky/Registre/Dalsie-uzitocne-zoznamy-a-registre/RPVS/Opendata.aspx

Len im to ešte nefunguje…


#2

Uz funguje.


#3

V nasledujucich dnoch sa to este cele vyladi. Berte to ako betu :slight_smile:


#4

pekne…kto dal navrh na API? zakaznik, ci ty?


#5

my sme dali, na zaklade inspiracie itms :wink:


#6

cize ste navrhli zakaznikovi a on sa k tomu komitol


#7

no komitol… dajme tomu ze komitol


#8

Ja mam rovnake pripomienky ako som mal tu Informácie o úpadcoch z Registra úpadcov :slight_smile:


#9

thx, pozrieme to, performance problemy nepredpokladam, cca 10 000 partnerov a 20000 kuv, nejako to sice porastie kvoli historii, ale stale sme 10tis.


#10

Pôvodná predstava ministerstva bola klasické “dumpy”. Bolo k tomu aj stretnutie s mimovládkami, kde som vysvetľoval API.
Požiadavka bola aj na synchronizačnú funkčnosť, t.j. jednoduché zistenie zmien od nejakého bodu (napr. timestamp). To tam zatiaľ nevidím (viď. aj §53.g.2 výnosu 55/2014).


#11

zatial nie je, viem o tom,
povodne sme vobec chceli open data spustit neskor, kvoli casu, ale podarilo sa aspon nieco. myslim ze lahsie pripomienkuje nieco co existuje, ako ked nie je nic, takze teraz je vhodny cas zozbierat poaziadavky verejnosti a zapracovat to


#12

10k nebude nijaka zloba, ale aj tam uz sa to moze ukazat. http://use-the-index-luke.com/blog/2013-07/pagination-done-the-postgresql-way

Inak myslite na to, ze ked sa nieco zmaze, updatne tak by sa to mal konzument dozvediet. => Treba to riesit trosku inak, zmeni sa ti trosku workflow entit. Lebo ich vlastne nemozes uplne zmazat.


#13

Zopár otázok:

  • chýbajú oznámenia, pokuty
  • chýbajú dokumenty, tam samozrejme pokiaľ ide o obsah stačí URL, zhodná ako v GUI
  • nie celkom sedí Model a Model schema vo swaggeri…

Zasa chápem že kvôli OpenData fanatikom nebudú robiť zásadné zmeny. Pre update funkciu postačí napr. samostatná tabuľka histórie s id obj, timestamp a typ zmeny (insert / update / delete).
Vzhľadom na jednoduchú doménu - v podstate ide o strom objektov - v minimalistickom prípade stačí log pre 1 tabuľku s vrcholovým objektom, čiže Partner, že nastala zmena niekde v ňom alebo nižšie - dáta si dotiahneš. Ale samozrejme dá sa aj inak.


#14

Ano, takto som to myslel. Pomocov triggerov je toto asi najminimalistickejsie riesenie. EDIT: Uplbne minimalisticke je si len drzat posledny update (timestamp) a priznak ci to bolo zmazane. Netreba ani historiu.


#15

@anton-somora kukol som teraz chvilu na to: mam par navrhov na zlepsenie

  • ked zavolam toto https://rpvs.gov.sk/OpenData/Partneri?%24expand=Vymaz%2CKonecniUzivateliaVyhod%2CPartneriVerejnehoSektora%2COpravneneOsoby
    tak to hodi error - asi by nemalo
  • ako api na “zmeny” by sa hodilo povolit nieco ako $filter=Id gt 10 a k tomu $orderby=Id Asc. Kedze Id je predpokladam autoincrement + vyriesilo by to problem s kritickym subehom ked sa updatne databaza a ja volam medzicasom nejaky $skip=123220
  • vyzera, ze sa tam nerobi vobec ziadna normalizacia entit - osob - su tam duplicity etc. chapem to spravne?
  • bolo by fajn dat niekde na uvod dokumentacie datovy model. logicky je v odata metadata, ale fyzicky, aby sa to dalo zreplikovat chyba. Ja si ho predstavujem nejako takto:

#16

pozrieme to,

  • normalizacia entit osob, no popravde, zatial nie je rfo, rpo (iba predvyplnovanie), ra, ale nieco navrhujeme, uvidime ako sa k tomu postavi MS
  • minimalne PVS a OO by mali byt bez duplicit, ale ano nerobime tam ziadnu velku vedu, co je na vstupe to zapiseme
  • datovy model mas celkom blizko, v ramci nejakeho change requestu mozeme upravit tie rozhranie a doplnime model
  • pravda s rozvojom rpvs neviem presne ako to bude… ono je to take cele zle podla mna v egov… ze urobilo sa a koniec…

#17

Pokiaľ si pamätám rokovanie s MS a zákon o RPVS, normalizácia FO bude problém, lebo register úmyselne neobsahuje rodné čísla. Celkom by ma zaujímalo, ako sa tu vyrieši povinnosť stotožňovať FO.

Podľa toho čo sme (S.D) navrhovali v PS Lepšie dáta, by “normalizácia” mala vyzerať tak, že pre ref údaje (FO, PO, adresa) existuje štandardizovaný minimalistický dátový objekt, v prvom kroku si RPVS k nemu vytvorí identický vlastný (pointre do neho sú vlastné URI) a ako postupne prebieha stotožňovanie, sú URI iba prevesné do ref. reg. V ideálnom prípade nakoniec všetky URI smerujú do ref. reg., a teda vlastné objekty nie sú ďalej potrebné. Toto je samozrejme pohľad z von viditeľného rozhrania, interná reprezentácia podľa chuti.


#18

Preto je tam datum narodenia… to by malo stacit - meno, priezvisko, datum narodenia


#19

uplne hrube cislo, len 10% zaznamov tam ma uvedeny datum narodenia…zvysok je mozne “unikatne” identifikovat len kombinaciou tituly, meno, adresa a dufat ze dvaja rozlicni ludia s rovnakymi menami a titulmi nebyvaju na rovnakej adrese

Mal by som jednu mozno primitivnu otazku, ako sa cez to API dostat ku Statu v adrese? Tato URL mi zavola konecneho uzivatela vyhod s partner ID s cim to viem prelinkovat dalej, co je super, adresu mi tak isto zobrazi ale ako pozeram adresa by mala mat vnoreny este stat, ale netusim ako sa k nemu dostat…diky
https://rpvs.gov.sk/OpenData/KonecniUzivateliaVyhod(234)?%24expand=Adresa,Partner


#20

Datum narodenia - este sa vsetci nepreregistrovali, cas maju tusim do 31.07.2017, udaje su import z povodneho registra KUV, kde datum narodenia nie je, takze sa to doplni vsetko k 31.07.2017 (tie PO, ktore k tomuto datumu sa nezaregistruju, budu vymazane)

  • stat v adrese doplnime, thx