dovoľte mi otázku, či niekto má informácie k publikovanému registru adries. Dôvod je, že chceme tiež spracovať tento register ako Linked Data do projektu LOD Slovakia, čiže hlavne definovať URI (Jednotný referencovateľný identifikátor) pre jednotlivé entity, je viacej možných riešení, tak by sme radi získali nejakú vstupy aby sme sa vedeli rozhodnúť.
Použijem modelový príklad: Na data.gov.sk je napr. publikovaný nie celkom najkvalitnejší dataset Kraj - Konsolidované dáta.
Tu je nižšie obrázok, ktorý ukazuje predmetné CSV. A tu je možné vidieť, že sú tu natvrdo mergnuté dve distribúcie, jedna - už neplatná, kde BSK má kód 1 (čo je číselník CL0049) a druhá - platná, kde je kód SK010 (číselník CL0023). Tieto číselníky používajú dnes všetky (alebo aspoň drvivá väčšina) ISVS.
A teraz, Register adries, projekt ktorý nám má pomôcť vo všeobecnosti sa posunúť dalej, navrhuje pre BSK ID=2, ak správne tomu chápem.
Čiže otázka teraz znie, čo je vlastne identifikátor BSK? Ako bude vyzerať referencovanie nejakého ISVS, ktorý bude referevať, že daná entita je v kraji BSK?
a. použije sa 2 ? - teda navrhované nové ID? (a teda budú sa musieť prerábať všetky IS na tento export)
b. použije sa SK01? resp. pôvodná 1?
Ďakujeme za pomoc
Otázku som poslal na ministerstvo vnútra a rovnako i do nasesu.
Ak toto citam spravne ja, tak to je jasne. Oznacenie cislicou su neplatne, oznacenia SKXXX su platne.
PS. Preco a ako sa tam dostali tie presne timestampy netusim. Nechce sa mi verit, ze by sa ciselnik pre bratislavsky kraj menil presne 1.10.2015 o 10:11:53.
V tej tabuľke zrejme primárny kľúč je (objectId, versionId) - to reprezentuje stav objektu kraj v konkrétnom čase. Takže pre identifikáciu kraja v Registri adries “nadčasovo” je logicky identifikátorom atribút objectId.
Čiže pre objekt s aktuálnym menom “Bratislavský kraj” je identifikátor objectId=2.
Ale máš pravdu v tom, že je tu čudná duplicita - tie isté objekty “kraj” sú uvádzané aj v základnom číselníku CL000023, ktorého kódy sú v atribúte regionCode. A tam je ozaj nekonzistentná informácia. Ale podľa zmenových údajov atribút createdReason napovedá, že išlo o opravu chybných záznamov. Nakoľko však pôvodné - chybné - údaje neboli zatiaľ zmazané, sú v konsolidovanej verzii stále zobrazované. Ináč atribút createdReason neviem akú má presne definovanú sémantiku.
A aby to bolo zábavnejšie, zdá sa že platná vyhláška ŠÚ SR 597/2002 uvádza ako “číselný kód”, t.j. identifikátor pre Bratislavský kraj 2.
Unique pre externe pouzitie je zjavne viazany na cas, t.j. zlozeny z validFrom a regionCode. (Uvazujem, ze popis objektu sa moze zmenit, ale vyznam zostava, kym zostane rovnaky kod.)
T.j. pouzitie znacne zavisi od toho co chcete vyjadrit:
pre Bratislavsky kraj (bez udania vztazneho casu) mozete pouzit “1” alebo “SK010” - dovod: system musi akceptovat aj historicke zaznamy ak su este platne
pre Bratislavsky kraj pre zaznamy do 2015-10-01 treba pouzit kod “1”
pre Bratislavsky kraj pre zaznamy po 2015-10-01 treba pouzit kod “SK010”
Alebo?
Dalsia moznost by bola vzdy pouzivat dvojicku ObjectId a VersionId, ale toto vyzeraju byt interne kody…
Ale vyznam sa zjavne nemeni len pri ObjectId. Ma byt toto ten kod zmienovany vo vyhlaske vyssie?
Dobry hlavolam…
Zjavne by malo byt niekde zakotvene, ze identifikator polozky ciselnika (semanticky kod pre externe pouzitie) by mal mat vzdy rovnaky nazov (code / kod)…
B) A prečo vlastne je tam ten +1 posun tak či onak? Veď ten kód 1 pre BSK je platný od 2002 (správny je teda aj číselník CL0049, čo je nepresne v tom CSV), na čo sa to takto posunulo? (nie že by to bolo kritické, zo zájmu sa pýtam).
predsa ešte doplním otázku
C) Čo je to za mystériozný objekt _id=10 z roku 1875 reprezentujúci neznámy kraj, pričom aj _id=1 reprezentuje neznámy kraj (distribúcia 1996-07-24).
Interny register je podla mna objectId, pretoze tento isty nazov sa pouziva aj v ostanych ciselnikov z registra adries. Ako je ale mozne ze pri tomto ciselniku maju 2 prvky to iste ID v ich databaze, tak to uz nechapem pretoze nastava aj paradox ze to iste ID je a aj zaroven nie je platne. V inych ciselnikoch som si take nieco nevsimol.
Problem s registrom adries ale urcite nie je len v krajoch lebo cele je to akosi nestastne riesene a integracia urcite nie je jednoducha na dany register.
Zoberiem priklad z registra ulic. Tam su take ulice, ktore maju prislusnost k nejakemu mestu ze “neznama”. To akoze znamena ze nikto vlastne nevie kde ta ulica je ale uz ma IDcko? Aky to ma prinos resp. kto by referoval takuto neidentifikovanu ulicu?
Takisto je pri samotnych uliciach problem s velkym mnozstvom duplicit, kde ta ista ulica je v ramci mesta X krat zadana duplicitne ale raz je s malym pismenom, raz s velkym, raz s diakritikou a podobne. Co robit v takom pripade? Ktore ID z tych X rovnakych ulic pouzit ked chcem referovat danu ulicu?
Vitajte v svete open data! Zda sa, ze konecne vidite nazivo klucovy problem pre linked data. Mozete tomu vymysliet aj nakrajsiu schemu na svete a natlacit to do najlepsieho triple storu vo vesmire a bude to cele nanic. A z toho co som videl je register adries este ten slusny.
Centralny register zmluv napriklad celkom casto uvadza (ak uvadza) ICO, ktore je zle (proste neexistuje) alebo smeruje na uplne inu firmu (preklep, chyba atd). Jednotlive pravnicke osoby su tam zapisane na stovky roznych sposobov (nerobim si srandu).
V registri adries je pokial viem velmi vela (drviva vacsina) udajov neautorizovanych. @Lubor myslim vie aj cislo.
No co sa tohto ze linked data v nicom nepomozu tak tu s tebou musim trochu nesuhlasit. Problem s duplikovanim dat je prave v semantickych databazach mozne elegantne riesit cez predikat owl:sameAs co NIKTORA ina databaza o ktoru poznam nedokaze. Tj. vsetky duplikaty, ktore vznikaju sa proste len prepoja cez tento predikat. Nasledne databaza povazuje
A owl:sameAs B
za ten isty uzol (vytvori mu sice interne ID, ale neda sa k nemu ani dostat) tj. ked sa opytas na A, tak vidis aj okolie v grafe uzla B a naopak. Vysledok je ten ze i ked je spociatku bordel v datach, tak ich vies takto integrovat a neporusis tym vobec nic - prave naopak ziskas lepsiu a kvalitnejsiu bazu dat a ludia ktory pouzivali v minulosti neprehladne data nemusia preklapat vesmir, ale pouzivaju to tak aj nadalej a integracia medzi systemami je i tak zarucena.
V pripade, ze nechces v niektorych pripadoch vidiet naozaj tie mergnute data, ktore owl:sameAs vytvori, tak proste spravis query, kde vypnute odvodene udaje a je to vybavene.
Pokial ide o veci, ktore nikdy ani nemali vzniknut tj. nie su to duplicity ale proste chyby v datach, tak tam je problem odlisny. Tam proste treba dane itemy zatvarat, toto je neriesitelny problem pre akykolvek system a je nutna manualna kontrola. Ale take veci ze mame X krat “Neznamy” identifikator je krasne riesitelna zalezitost.
Pes je zakopany v spojeni “proste len prepoja”. Lebo to zahrna
musi to niekto najst a nahlasit
urcit duplicitu/chybu
v zdrojovom registri to treba opravit co je ovela vacsi problem ako sa zda.
Pokial viem tak ani MV nemoze len tak menit data v spominanom registri adries, kedze to tam zapisuju obce a mesta.
Vsetko ostatne su technicke ficury a detaily, ktore sa daju spravit viac ci menej sikovne v uplne lubovolnom ulozisku. Je fajn, ze triplestores maju tu funkcionalitu out-of-the-box, ale problemom su od zaciatku nekvalitne data.
To ze tie data su … mno povedzme ze su ake su tak na tom sa maximalne zhodneme a je to dost smutne nakolko to stalo urcite nemale peniaze.
Co sa tyka tvojho argumentu ohladom “proste sa len prepoja”, tak tuto som neni az taky pesimisticky lebo to nie je robota pre 10 clenny tym na 2 roky. Register ulic ma 37000 poloziek, po aplikovani mergu ze odstranis diakritiku+prevod na male pismena + osetris stavy ako M. R. Stefanika a Milana Rastislava Stefanika je ich uz len 30000 . Takze relativne rychlym sposobom je mozne docieli prve vyrazne zlepsenie, kde by sme duplicity na seba naparovali automatizovane s tym ze prave ta out-of-box featura nam zaruci ze kazdy kto uz v minulosti zacal pouzivat aj tie duplikovane IDcka sa nemusi bat o to ze by sa nedalo s nim integrovat. Vymyslat znova koleso a preimplementovavat naimplementovane mi pride zbytocne. Jedine ze by sme tu zasa chceli nejaky vladny projekt, za X penazi, ktory to dorobi a to si myslim ze asi nikto nechce. Chcem len poukazat na efektivne riesenie isteho typu problemov.
Prejst zoznam 30 tisic ulic rucne (na duplicity) s tym ze by boli nejako roztriedene podla mesta v ktorom sa nachadzaju a sortnute podla abecedy je uloha na jedneho cloveka na kolko? Nech 2 dni a to sa opravia IBA duplicity. Nic viac tj. netreba nikoho kontaktovat, staci porovnavat s Google, OpenStreetMaps, Bing Maps ze ci take nieco oni poznaju pri preklepoch alebo parovat na zaklade stringov. Vysledok by bol neporovnatelne kvalitnejsie data. Toto je podla mna jeden z par zakladnych registrov, ktore su nesmierne dolezite pre cely verejnu spravu.
Trochu ma ale prekvapila informacia ze MV aj ked vie ze data su zle tak ich nemoze opravit nakolko si predtym spominal ze velka vacsina dat je “neautorizovanych”. Tak ako to teda je? Odkial sa tam potom dostali? To znamena ze nikto ich pred vlozenim do systemu nekontroloval, len sa spoliehal ze su spravne aj ked to bolo od “neautorizovaneho zdroja”?
O danom projekte som nevedel a uvidime ako sa s tym popasuje. Ale to bude asi na dlhsie kym uvidime realne prinosy.
Urcite nenavrhujem to aby sa teraz vsetko zahodilo a preslo sa len na triplestores. Ved to by ani nemalo zmysel. Dolezite su tie data ktore by mali byt verejne a ktore by mali mat aj referencovatelny identifikator a tieto mozu byt urcite v jednej centralnej databaze pekne premapovane a nad ktorou sa vystava vrstva sluzieb( o tom je ten projekt? resp. to je jeho vystupom? ). Nieco ako nadstavba nad data.gov.sk ako centralny zdroj statnych udajov. Centralizovanejsi a spravovany register je proste pre jednoduchu integraciu ostatnych systemov nevyhnutny.
@Lubor , sorry a stále čakám na Tvoju odpoveď, zatiaľ nič. Rovnako by som chcel poprosiť aj niekoho, kto tento projekt vyvíjal, resp. sú tu nejaký zástupcovcia Nessu, ktorý by sa k projektu vyjadrili?
Úlohou registra adries malo byť zjednotenie a zefektívnenie procesu reprezentácie, či publikácie dát reprezentujúcich adresu. Bohužiaľ, podľa mňa reálny stav projektu, resp. jeho smerovanie je veľmi ťažko nazvať zásah do čierneho. Skôr by som si ho dovolil nazvať zbytočným projektom, ktorý súčasnému stavu moc nepomôže. Toto konštatovanie zatiaľ nemôžem zmeniť, a jeho dôvod nájdete snáď v otázkach, na ktoré som zatiaľ nedostal odpoveď.
Moje otázky sú nasledovné:
1) Prečo majú adresné entity zrazu úplne nové kódy? Napr. Register adries navrhuje pre BSK kód 2, kým od roku 2004 platí vyhľáška, kde je sa používa kód 1, čo je reprezentované používaným číselníkom CL0049?
A čo sa stane zo všetkými už publikovanými datasetmi ktorých je obrovské množstvo (či už na data.gov.sk alebo tie, ktoré sú publikované priamo niekde na ministerstve), ktoré používajú súčasne platné údaje? TREBA ICH DAŤ VŠETKY PREROBIŤ? (A k tomu ešte sa ani kvalita datasetu nezvýši, tj. stále to bude len 3★)
Tu na fóre sa často hovorí, že treba všetko správne pripomienkovať, otvorene, že niečo je zlý projekt a niečo dobrý. Podľa akého kľúča sa toto rozdeluje ?, keďže Register adries, ako sa zdá sa tu dosť obhajuje ? Navyše, nielen Register adries sám o sebe bohvieaký prínos nie je, skôr naopak, a navyše bude treba urobiť ďalší projekt za 13 088 096,80 EUR, ktorý bude - Informačný systém centrálnej správy referenčných údajov verejnej správy? - ktorý asi plánuje riešiť duplicity, resp. viacero možných kódovaní adresných entít strašne neefektíávnych spôsobom, (BSK má identifikátor 1, ale aj európsky SK010, čo je v základnom číselníku ISVS CL0023)
Čo s doteraz publikovanými údajmi? Pýtaj sa MF. Čítal si už metodické usmernenie pre riadenie kvality údajov? Že kvalita údajov / prechod na referenčné je veľká výzva a zatiaľ nie je jasné systematické riešenie si myslím aj ja, aj tu na platforme sme to vo viacerých diskusiách už načali.
Či má RA zmysel? Imho určite áno. Cena je samozrejme iná vec. Ináč CSRÚ už je prevádzkovaný.
Úprimne verím, že riešenie tohto problému treba preniesť do sémantiky, a tá bohužiaľ u nás nemá na ružiach ustlané . Pre snáď lepšie priblíženie, nech sa páči, tu je riešenie: - Linkovanie data.gov.sk datasetov s Registrom adries - . Riešenie je zadarmo (samozrejme treba ešte dorobiť XSLT transformátory na 8 datasetov z data.gov.sk (čo musí dať študent za víkend, publikovať API…). Výsledok je, že máme prepojené sémantické dáta (5★) a to je nutný predpoklad na reálne posunutie sa v informatizacii. Áno, aj procesy treba samozrejme zefektívniť (chaos v informatizácii je toho dôkazom), ale rovnako treba posunúť aj dáta, pretože inak premrháme úsilie na neefektívnu správu neefektívnych dát, čo nás jedného dňa môže odstaviť.
No. Register adries je krásny príklad toho, kedy už treba prejsť na linked data. (Možno že požiadavky na dátové prepojenia len v 3★ mali byť hooodne menej náročné ). Keby sme už ten problém riešili v sémantike, tj. linked data, nepotrebovali by sme zaviesť ďalšie IDčko aby sme zintegrovali iné dve. Stačilo by povedať že zdroje (jednotne referencovateľné) sú owl:sameAs. Sám triplestorový engin by mergoval identity a voči dotazom by sa to chovalo ako jedna entita (A taká profi tripletová DB (2CPU) stojí 3000E).
Nevadí ale. Tým, že je pridaný nový register adries a ten má svoje nové kódovanie, tak je pridaná nová entita i v sémantike. Tá sa samozrejme opäť prepája vzťahom owl:sameAs na existujúce, čiže v konečnom dôsledku aj nová entita predstavuje už existujúcu. A namiesto dvoch entít (referencovateľných zdrojov), máme ešte tretí, čo nie je treba. No, a v tom je tá zbytočnosť, že v sémantike to netreba riešiť týmto spôsobom (tj. na integráciu dvoch zdrojov pridajme tretí).
Ja ceny neriešim, snažím sa skôr hovoriť o úsilí. Ak sa bude stále sémantika odsúvať a odsúvať (pričom vo vyspelých egovernmentoch je to už základom), tak nám zbytočné úsilie na rozvoj a udržiavanie dát môže hodne prekrížiť plány.
Inak, mas aj nejake Tvoje odborne kratke slovne zhodnotenie tych otvorenych udajov z RA?
Lebo este nedavno sa nasadzovali nejake opravy na zverejnovaci proces, plus tusim data nie su kompletne (lebo ich do RA obce este asi stale priebezne nahadzuju), atd. Tak aby som si spravil obrazok, ze ci je to “dobre” alebo “zle” a co z pripadnych nedostatkov je problem samotneho RA a co prekladapania do Open Data.
p.s.: OpenAddress.io … sme v celku dobrom klube. Mam na mysli tych zelenych.
@hanecak ahoj, vedel by si nieco spravit s tym, ze zmenove davky sa publikuju ako Resources pod jednym datasetom vCKAN? Takto to autori ckanu nezamyslalu, resources maju byt rozne reprezentacie tych istych dat teda datasetu. Okrem toho sa to potom aj extremne dlho zobrazuje a podla mna je to dataset na odpisanie postgresql za tym…
?, keďže Register adries, ako sa zdá sa tu dosť obhajuje 
(A taká profi tripletová DB (2CPU) stojí 3000E).