Komisia pre štandardy ISVS - PS1

liska · October 11, 2017, 9:42am

Ak sa má štandardizovať Centrálny model, nie je možné oddeliť vlastnosti od tried, to potom nie je štandardizácia. Toto nebolo ambicíou ani v historickom KDP, veď predsa musia sa definovať požiadavky na názov spoločnosti, resp. alternatívny názov, resp. formátované meno spoločnosti. To sú tri rôzne vlastnosti a vyjadrujú rôzne veci. A to je kľúčové aj pri výmene údajov medzi ISVS a aj pri publikácií datasetov. My musíme spoločne vedieť, akú vlastnosť mám na mysli, a preto je globálny identifikátor nutný. Tj. raz je to lsub:name, raz lsub:alternativeName a raz lsub:formattedName.

Navyše, URI pre vlastnosti sú dôležité aj pre identifikovanie referečných údajov, čo je už podporované aj v MetaIS. Napr. referenčný register pre lsub:name je RPO, ale pre pper:givenName je to už RFO.

Centrálny model je ľahko možné vizualizovať aj prostredníctvom UML, pretože podobne ako UML aj OWL používa triedy, relácie (dedenie) a podobne. Keď študujeme rôzne iné zahraničné ontológie, veľmi často používame ich UML podobu. Aby informácie o centrálnom modeli neboli príliš roztrúsené vo viacerých vláknach, vytvoril som preň domovské samostatné vlákno, kde môžeš spomenutú vizualizáciu vidieť:

kyselat · October 11, 2017, 10:59am

Chápem. Iný pohľad je nasledovný - to meno z “physical-person” predsa používam len pri jednej entite (v ostatných len odkazujem identifikátorom na celú entitu (physical-person)). Keďže v tom jednom prípade bude jasne v dokumentácii typu povedané čo je to za atribút (či je tam meno alebo meno + priezvisko) - tak problém ktorý je tu uvedený vlastne nevzniká.

Iný pohľad je nasledovný - ak mám dobre zadefinované a zdokumentované typy v datasetoch, tak tento “strojovo spracovateľný meta-popis”, resp. napojenie na akúsi “globálnu” verziu - viem zostrojiť ako nadstavbovú vrstvu. Toto jasné členenie (základ a nadstavbová vrstva) mi umožní aplikovať “ontologický prístup” najprv len na vybranú podmnožinu údajov - následne vyhodnotiť prínosy voči prácnosti (či Google, Facebook, alebo EÚ sa pripojí a aké z toho budú efekty) a až potom rozširovať ďalej. Nazdávam sa, že toto je obojstranne výhodný princíp - najprv overiť a až postupne rozširovať - a pomôže k tvorbe širšieho konsenzu k tejto otázke.

Toto by som upresnil. V definíciach OpenAPI vieme presne povedať, ktorá služba má aké vstupy a aké výstupy (štruktúrovane). Adresácia celého API je pomocou URI, pričom je to už len o strojovom spracovaní formátu určeného na strojové spracovanie (= bez problémov). Takže tu nemusíme ísť do ontológie - stačí využiť štandard.

Otázka je ako to formálne dotiahneme v dokumente, ktorý je výstupom z PS. A o tom bude stretnutie - myslím si, že niektoré definície príliš striktne fixujú ontológiu a veci s ňou súvisiace (a náš názor zatiaľ je, že by nemuseli). Ale všetko je otvorené, závery budeme robiť až po stretnutí a diskusii.

msurek · October 11, 2017, 12:11pm

Ak sa bavime o dokumentacii, tak ta je vecinou slovna. Tu ide o strojovo citatelnu a jednoznacnu identifikaciu. A validacia centralna sa potom vlastne ako robi ked je to len v texte ze je to meno ale je to akekolvek meno? Ci bude sa to riesit ako doteraz ze validacia vlastne nie je?

Presli sme teda od API k datasetom? (je tu pomotany meta popis pre sluzby a jednoznacna schema tak neviem). Bavime sa o CSV? Kde sa tam definuje typ? Akoze textova dokumentacia? Ma CSV nieco take ako validaciu typov ako je XSD? Alebo predpiseme ze jediny mozny format je XML s XSD?

Ak sa bavime o API sluzbach, tym ze je to v MetaIS tak to moze byt chapane ako nadstavba a nie sucast.

EU to vyzaduje a viaze na to cerpanie eurofondov takze nie ze EU sa pripoji, ale my sa mame pripojit. Posielal som to sem uz viac krat, ale znova davam do pozornosti : https://www.europeandataportal.eu/sites/default/files/goldbook.pdf
Kde v kapitole 4.1.3 Preparing data: technical openness hovoria len o koncepte linkovanych datach a ako sa ma kazdy dataset donho transformovat a v kapitole 4.1.5 to popisuju ako potrebny check pred publikaciou. Nakolko Google a spol. to pouzivaju a my nie, tak znova si myslim ze to my sa pripajame na nich a nie oni na nas.

Zo dna na den to nebude mozne spravit takze rollout bude isto trvat a rozsirovanie bude postupne. Ked sa to tak vezme tak zatial len dva projekty sli na hearing a termin zaciatku je najskor koniec dalsieho roka. Myslim si ze rychly nastup nehrozi.

pokial viem tak viem definovat ze “meno” a viem povedat ze je to json. Ale to ze toto meno je to iste ako meno v inej sluzbe neviem kde sa prepaja v OpenAPI specifikacii. Ako teda viem povedat ze tato sluzba s meno je ta ista ako ina sluzba kde je taky atribut? a ze stat posiela v tu take data v tam zasa take a je to unifikovane?

Suhlasim, pobavme sa o tom.

kyselat · October 11, 2017, 1:02pm

Marek, uisťujem vás, že technologicky je možné všetko aj mimo ontológie. Validácie viete urobiť pomocou JSON schémy (napríklad). Nie som zatiaľ presvedčený, že nejaké validácie (publikované) potrebujeme (veď sa bavíme o exportoch kde sú tie dáta správne). V časti API predsa validuje služba (čo nezvaliduje z pohľadu formátu schéma) a pod. Ale možno mi len niečo v uvažovaní chýba.

“Strojovo čitateľná dokumentácia” je super, ale musíme vedieť kto ju na čo využije. Tu tvrdím, že je možné ju urobiť ako nadstavbu, overiť jej užitočnosť a v prípade osvedčenia postupne rozširovať.

V mojom rozmýšľaní (kde beriem RDF a ontológie ako jeden z možných nástrojov) sa svet API (vstupov alebo výstupov z metód) a svet datasetov celkom dobre prepája - ak budeme chcieť (to čo je definované v datasete je +/- súčasťou výstupu z nejakej služby a pod.). Neťahajme sem CSV - bavme sa o OpenAPI a bavme sa o JSON exportoch (datasetoch) - tam je aký problém s typmi?

V prvom rade sa bavme o tom, či je to užitočné, alebo nie. Využívať EÚ zdroje na niečo o čom nebudeme presvedčení že plní úžitok - nie je prístup, ktorý by sa od nás očakával (skôr by sme na to mali upozorniť, a keďže tá dohoda sa formovala už pred nejakým časom - možno dosiahnuť jej zmenu). Na druhej strane nikto netvrdí že to má zájsť sem, sústreďme sa na postupné zavedenie a skúsme nájsť mechanizmus, ktorý nám pomôže zaviesť novú myšlienku v miere, ktorá bude mať najlepší pomer prácnosť/úžitok. Ak sa ukáže téma ako užitočná - tak nikto nebude proti, aby sme ju zaviedli hoc aj v plnom rozsahu. Nazdávam sa, že oddelenie centrálneho dátového modelu od “ontologickej nadstavby” by mohol byť takýto mechanizmus.

Viac už v tejto chvíli nestíham, nechajme si niečo aj na stretnutie.

liska · October 24, 2017, 6:02pm

To je kto my?

Pretože na Slovensku existuje jediná pracovná skupina pre dátové štandardy a to je
PS1 - Pracovná skupina pre dátové štandardy a štandardy názvoslovia elektronických služieb

ktorá bola navyše pomerne nedávno aktualizovaná/renominovaná, takže jej stav je plne oficiálny, keď to mám tak povedať (A pracovnú skupinu NKIVS::K9.4 zatiaľ ešte dávam bokom). Na základe viacerých stretnutí, publikovaných informácií (a to aj tu na platforme) bol Centrálny model údajov verejnej správy schválený zástupcami rôznych inštitúcií, verejných a komerčných.

Kedže si nechodil na žiadnu pracovnú skupinu hoc mohol si vždy prísť, ja by som tomu bol rád, asi by sme veľa vecí mali vysvetlených lepšie (a keď privriem oči, tak si viem predstaviť že by sme aj spolupracovali) ; tak ti tú otázku musím položiť tu:

Čiže máme 1) oficiálne schválený Centrálny model, ktorý je otvorene komunikovaný a publikovaný postupne viac než rok, 2) umožňuje referencovateľnosť (URI), 3) vychádza z KDP (jeden po druhom dátovom prvku sú prenesené do Centrálneho modelu), 4) je namapovaný na vybrané ontológie EK, s ktorými pracujú už rôzne štáty, 5) a keďže RDF používa tiež triedy a relácie ako známe UML, ktoré je možné z neho generovať a zobrazovať ho v jednoduchej podobe, viď.

tak ty navrhuješ, že toto teraz zahoďme?
Resp. takto sa štandardy nerobia, otvorene, oficiálne, zohľadňujúc iné štandardy …

Alebo čo vlastne, lebo ja sa fakt ale strácam.

Netvrdím že je Centrálny model dokonalý, akiste je tam pár chýb, treba pridávať nové prvky, atď. Ale to už proste osud Centrálneho modelu v digitálnom svete, ktorý bude len rád že sa vieme spojiť pre lepší zajtrajšok.

Alebo inak sa spýtam: Čo navrhuješ? Máš spracovaný iný centrálny model v celej šírke bodov 1…5? Prosím, postni ho.

hanecak · October 25, 2017, 9:24am

Dňa 31.10.2017 v čase 09:00 až 11:00 sa uskutoční (na Úrade podpredsedu vlády SR pre investície a informatizáciu v zasadačke Bratislava 1. poschodie blok B) zasadnutie pracovnej skupiny PS1.

Program :

Prezentácia návrhu Open API (diskusia a pripomienkovanie)
Štandardizovaný spôsob a obsah zverejňovaných datasetov (diskusia a schválenie)

Podklady :

Pravidlá pre publikáciu katalógu, datasetu a distribúcie: https://wiki.finance.gov.sk/pages/viewpage.action?pageId=20022969
Open API štandardy (su este len tvorene)

liska · October 25, 2017, 11:10am

Pozri @kyselat, mrzí ma vypisovať také srdcervúce posty a najradšej by som tento čas strávil nejakou spoločnou produktívnou prácou. Ak som povedal že

nemyslel som v tom duchu, že sú to páni bohovia, ktorý sa musia počúvať a bodka, ale že je to príslušná pracovná skupina pre túto oblasť. A bol by som rád, keby sme sa tam stretli a veci si vysvetlili, aby potom tu to nemuselo takto vyzerať. Veď keď sa bavíme o otvorenosti a participatívnosti, načo je potom taká skupina. Tak ju treba otvorene navrhnúť na zrušenie (proti čomu samozrejme som), ale nech je všetko jasné.

A to isté platí pre SP Otvorené dáta. Súhlasíš s týmto dokumentom, alebo si podstatne proti niektorým častiam? OOK, príď na skupinu, vysvetli to všetkým členom, možno to prinesie opäť zlepšenie pre všetkých. Dnes je, 14:00, máš pozvánku. Podľa mňa si to za tú námahu členovia tejto skupiny zaslúžia počut názor priamo.

Občas naozaj snívam, ako aspoň na nejaké obdobie spolupracujeme a pozitívne míňame energiu. Že pracovné skupiny navzájom lepšie spolupracujú, aj samotný členovia, aj úrad aj firmy, aj slovensko digital, a vlastne všetci.

hanecak · October 25, 2017, 6:10pm

(miesto" “niekde v Bratislave”, operativne podla potvrdenych zucastnenych, idealne kde maju dobre pivo)

Tot hlasovanie, ze ci a kedy sa stretneme k teme Open API. Pointa je stretnut sa pred PS1 a vydebatit aj niektore vyssie uvedene veci, kedze spojenie “Open API” uz v SR aj world-wide nadobuda privela vyznamov a teda prudko stupa sanca na velke nedorozumenie (vid Janovu poznamku k openapis.org v napr. Open API štandardy - #6 by jsuchal).

hanecak · October 27, 2017, 10:18am

Stretnutie ohladom pripravy Open API (Open API štandardy) bude dnes (27.10.) o 17:30 v Drag, Stare Grunty 64, Bratislava (nedaleko MFUK).

liska · December 27, 2017, 10:17am

Odlišovanie triedy a relácie veľkosťou znakov v URI

Keďže sa už viac krát riešilo či je URI case (in)sensitive, najmä v spojitosti: či môže existovať URI s rovnakými znakmi iba s rozdielom malých/veľkých písmen, pokúsim sa k tomu pridať viac informácií a príkladov.

1) URI a case-sensitivita

6.2.2.1. Case Normalization
https://tools.ietf.org/html/rfc3986#section-6.2.2.1

tj. doména je case-insensitive, https://data.gov.sk je to isté ako HTTPS://DATA.GOV.SK, ale ostatok je case-sensitive, tj. nasledovné URI reprezentujú iné entity

lsub:LegalForm (https://data.gov.sk/def/ontology/legal-subject/LegalForm)
lsub:legalForm (https://data.gov.sk/def/ontology/legal-subject/legalForm)

Rozdiel uvedených URI je, že prvý reprezentuje triedu LegalForm a druhý reláciu (objektovu vlastnosť).

2) DCAT ako príklad

Príkladom keď sa používa len odlišná veľkosť písmena (tiež) na definíciu triedy a objektovej vlastnosti je základná ontológia pre publikáciu otvorených údajov DCAT. Medzi základné triedy patrí dcat:Catalog, dcat:Dataset, dcat:Distribution a iné. Existujú aj ďalšie definované entity (relácie) dcat:dataset, dcat:distribution ktoré sú použité na definíciu vzájomných vzťahov týchto tried.

Čiže napr. v oficiálnej špecifikácii DCATu

je vidno že dcat:dataset je relácia (owl:ObjectProperty) a dcat:Dataset je trieda (owl:Class). Detailne

:catalog
   a dcat:Catalog ;
   dcat:daset :dataset-001 .

kde dcat:dataset je relácia (objektová vlastnosť) katalógu na svoje datasety.

:dataset-001
   a dcat:Dataset .

kde dcat:Dataset je trieda pre konkrétny dataset-001:

3) Prípady odlišovania URI entít veľkosťou znakou

Uvedená konvencia je asi známa viac developerskému svetu, je to klasický CamelCase, kde je trieda veľkým, relácia malým. Nevidel som ešte štandardizovanú ontológiu, kde by sa toto nepoužívalo. Presne to je aj ten prípad z predchádzajúcich bodov. Je to vyjadrenie dvoch entít vo forme 1) URI relácie na 2) URI triedu. Príklady použitia sú pri referencovaní číselníkov alebo pri začlenení vzájomných vzťahov tried do hierarchií, pri vzniku tzv. top relácie.

4) Použitie v Centrálnom modeli údajov

URI pattern pre Triedu/objektovuVlastnost je použitý v prípade číselníkov, aj v prípade top relácií.

Ako číselník: Potrebujem riešiť situáciu priradenia číselníkovej hodnoty pre nejaký objekt (záznam, inštanciu, indivíduum). Stanovím možným hodnotám typy, tj. ich triedu. Následne urobim dve URI (vzor): ClassURI a objektovaVlastnostURI.

Napr. lsub:LegalForm je trieda inštancií (definícií) ako: akciová spoločnosť, spoločnosť s ručením obmedzeným a podobne. Súvisiaca objektová vlastnosť tj. lsub:legalForm spája konkrétny právny subjekt s týmto typom. Napr. Slovensko.Digital je združenie

<lsub:LegalSubject rdf:about="https://data.gov.sk/id/legal-subject/50158635">
   <lsub:legalForm rdf:resource="https://data.gov.sk/def/legal-form/701"/>
</lsub:LegalSubject>

pričom “združenie” je položka číselníka definovaná ako inštancia triedy

<lsub:LegalForm rdf:about="https://data.gov.sk/def/legal-form/701">
   <rdfs:label xml:lang="sk">Združenie (zväz, spolok, spoločnosť, klub ai.)</rdfs:label>
</lsub:LegalForm>

Tu je vidieť použitie dvoch samostatných entít - lsub:legalForm a lsub:LegalForm.

5) Registrácia v MetaIS

V Metais sú niektoré dátové prvky zaevidované týmto spôsobom a nie je to preklep
https://metais.finance.gov.sk/uri/list/accepted

Ked si zobrazíte detail jednotlivých URI, tak je to dobre vidieť že raz je to trieda
https://metais.finance.gov.sk/uri/detail/d43acd16-bb4f-41f3-9bb8-635ac18809f6?navBack=accepted

a v druhom prípade je to zas objektová vlastnosť.
https://metais.finance.gov.sk/uri/detail/bc2a695f-c780-40fd-9762-eab8e82bbc7e?navBack=accepted

hanecak · April 6, 2018, 9:11am

5.4.2018 sa konalo 7. stretnutie PS1, vid https://metais.finance.gov.sk/standardization/meetingdetail/32 .

Agenda:

Študenti FIIT (cca 30min)- prezentácia na tému: Nástroj pre zosúladenie zverejňovaných dát s centrálnym modelom
M. Liška/ M. Šurek- Slovenský rámec pre sémantickú interoperabilitu (cca 1 hod.)
Š. Szilva: (cca 1 hod)
- Opatrenie o jednotnom formáte elektronických správ
- Štandardizácia vytvárania dátovej štruktúry elektronických formulárov
- Návrhy MZ SR na doplnenie základného číselníka Identifikátor
- Metodika k § 51 až 53 Výnosu o štandardoch a metodika pre štandaradizovaný obsah a spôsob zverejňovania datasetov na základe úlohy B.1 z uznesenia vlády č. 346/2017
- Návrh štandardov pre analytickú vrstvu vo verejnej správe, internet vecí a Big Data (apríl 2018 - úloha z NKIVS)

Draft k metodike zverejnovaia datasetov je tu: https://docs.google.com/document/d/1pEsyWQwkhFsrtRaugxk0IbPEEzHnhMdyAFPFkADw4Xk/edit . Pripomienkovat je mozne do 9.4.2018.

@msurek, su niekde dostune slidy k nastroju prezentovanom studentami?

msurek · April 6, 2018, 12:34pm

Prezentacia by mala byt aj so zapisom na webe. Dovtedy teda aspon ta prezentacia :

Importer_pracovna_skupina_april.pdf (1.4 MB)

hanecak · April 25, 2018, 11:44am

Vraj sa dnes konalo 8. stretnutie PS1, vid https://wiki.finance.gov.sk/display/PS1/8.+zasadnutie+PS1 . Agenda:

Návrh MZ SR na doplnenie základného číselníka (“Identifikátor záznamu o povolení”, “Identifikátor záznamu o zdravotníckom zariadení” podľa zákona č. 578/2004 Z. z.)
Opatrenie o jednotnom formáte elektronických správ a Schémy správ Sk-Talk
Štandardizácia vytvárania dátovej štruktúry elektronických formulárov
Centrálny model údajov (Aktualizácia centrálneho modelu- verzia 1.1)
Štandardizovaná štruktúra údajov pre popis elektronických služieb - štandard CSPV-AP
Návrh štandardov pre analytickú vrstvu vo verejnej správe, internet vecí a Big Data

Zial, nestihol som tam ist, cak m teda na zapis.

Lubor · July 19, 2018, 4:02pm

V pripomienkovaní pracovných skupín PS1-4 je návrh novely výnosu o štd.: 03_navrh_standardy_pripomienkovanie PS.pdf (461.9 KB)

Oficiálne info:"
Vážení členovia pracovných skupín PS1, PS2, PS3 a PS4,
v prílohe tohto mailu si vám dovoľujem zaslať návrh novely výnosu č. 55/2014 Z. z. o štandardoch pre ISVS, v ktorom sú zmeny reflektujúce transpozíciu Smernice 2016/2102 o prístupnosti webových sídel a mobilných aplikácii verejného sektora. Ďalej sa upravujú bezpečnostné štandardy, technické štandardy a čiastočne dátové štandardy.

Prípadné pripomienky k návrhu nám prosím zasielajte prostredníctvom emailu najneskôr do 22.07.2018 podľa vášho členstva v jednotlivých skupinách k nasledovným bodom návrhu:

PS1: body č. 3, 4, 6, 14, 15
PS2: body č. 2, 9, 10, 11, 12, 13
PS3: body č. 1, 7, 8, 18, 19
PS4: body č. 2, 3, 4, 6, 17, 20, 21

Zároveň si vás dovoľujem upozorniť, že príloha č. 1 výnosu o štandardoch (navrhovaný bod 19) bude doplnená o znenie WCAG 2.1 v slovenskej verzii po oponentúre prekladu.

Niektoré návrhy zapracované do návrhu novely výnosu o štandardoch ešte neboli schválené samostatnými hlasovaniami pracovných skupín, avšak potreba ich úpravy vzišla zo Strategickej priority NKIVS Integrácia a orchestrácia a z pracovnej skupiny k NKIVS K 9.3 Architektúra.

Po skončení pripomienkovania budú príslušné body návrhu novely zaslané jednotlivým pracovným skupinám na ich schválenia prostredníctvo dištančného hlasovania v MetaIS."

msurek · May 23, 2019, 2:43pm

Nakolko bol schvaleny zákon č. 95/2019 Z. z. o informačných technológiách vo verejnej správe, ktory uklada povinnost vydat novy vykonavaci predpis o standardoch, aktualne prebieha zber nametov do 28.5.2019. Samotne namety budu nasledne prerokovane na zasadnuti PS1, ktore sa predpoklada na 11.6.2019.

Jednou z oblasti, ktore navrhnem je pomenovanie data.gov.sk, ako prevadzkovatela Centralneho repozitara zdrojovych kodov vsetkych ISVS ako aj prislusnej dokumentacie (vzhladom na studiu OpenData 2.0, kde tento repozitar vznikne ako aj zakon o ITVS kde je povinnost zdrojove kody publikovat).

robert.kuchar · May 25, 2019, 7:55am

Navrhujem vzniest tuto pripomieku @Lubor :

v § 57b Prijímanie a čítanie podpisových kontajnerov , písmeno C.

Vypustiť akékoľvek zmienky o formátoch ZEPf. Text je absolútne zmätočný a pri jeho výklade budú úradnici produkovať chybné úkony. Podľa expertízy NBU je formát XZEP nesúladný s eIDAS. Formát ZEP by za istých okolností mohol byť súladný ak by sa obsiahnutý XAdES podpis vybral a “prebalil” do ASiCS kontajnera a ten potom Overoval na platnosť. Aspoň tak si vysvetľujem vyjadrenie, že v tomto formáte je nsúladna iba vnútorná štruktúra kontajneru, ale podpis samotný by mohol byť súladný. Takúto činnosť ale žiaden Slovenský, ani Europsky vyrobca nemá vo svojich produktoch zahrnutú. Išlo by prakticky o Zaručenú konverziu E2E, ku ktorej za 6 rokov jej existencie v zákone o eGOV doteraz nebol vydaný elektronický formulár, ani vykonávací predpis, takže sa oficiálne a de facto nedá vykonávať, ani ju žiaden výrobca zaručenej konverzie nevykonáva. Dokonca ju dodnes nevykonal ani jeden OVM, ani jeden advokát… (podobne ako ten úlet s OCR, ktoré tiež nik nevykonáva). Preto akýkoľvek podpis obsiahnutý v ZEPf nie je overiteľný na prítomnosť KVALIFIKOVANEHO el. podpisu. Dá sa overiť iba algoritmom z roku 2002 na prítomnosť Zaručeného el. podpisu. Keďže však sa na Slovensku podľa zákona 305/2013, par. 23, odsek 1 elektronické úradné dokumenty musia autorizovať iba KEPom, toto nie je možné vo formáte ZEPf dosiahnúť. Rovnako to platí aj pre elektronické dokumenty autorizované notárom, alebo advokátom. Formulácia “…, ak takýto podpis strana spoliehajúca sa na podpis akceptuje.” totiž v prípadoch kedy sa má overovať Autorizácia dokumentu nijako to povinné overenie autorizácie nenahrádza. Takže situácia, že povolím prijať ZEPf, ale nebudem vedieť overiť autorizáciu podľa platného zákona (QES) - je presne ten moment, ktorý bude úradné osoby pliesť a vystavovať nebezpečiu pochybenia… Resp. takmer istote pochybenia. Asi sa fakt čaká na prvý súdny spor.

Prosím o tlmočenie návrhu, prípadne jeho adopciu pod krídla S.D
(eIDAS sa pripravoval od roku 2012 na pôde EU, vošiel v platnosť s dvojročným prechodným obdobím v roku 2014, prechodné obdobie skončilo v roku 2016, dnes máme 2019 … a stále operujeme s proprietárnym štandardom. Dokonca na seminári v NASES v októbri sa spomínalo, že aj kvôli tomuto paragrafu a písmenu sa pripravujú ďalšie CRs pre CEP ohľadne doplňovania funkcionality “ZEP” - A možno to je aj jediná príčina, prečo sa tam to písmeno začiatkom roku 2018 dostalo. Času na zmeny bolo dosť, zároveň všetky podpisovátka a všetky súčasné podateľne už dlho vedia podpisovať v zákonnom formáte, nevidím pret problém zmeniť pár volaní podateľni na ine parametre a z predpisov tie prepašované formulky nadobro vypustiť)

Ak by to nešlo, potom to treba asi nahlasiť ako incident na CSIRT.

hanecak · May 27, 2019, 8:35pm

organizacna: Poprosim @msurek to posunut na PS1, kedze je tam zastupcom. Aj ked zase Lubor to moze dat na PS2.

Lukas_Hlavicka · May 27, 2019, 9:28pm

Dobry den,
ako incident to mozeme riesit az ked sa neico stane … ale odporucam to otvorit na pracovnej skupine napriklad na pracovnej skupine PS2 v tento stvrtok.

msurek · May 28, 2019, 7:17am

To je na PS2, ktora je ako povedal @Lukas_Hlavicka teraz vo stvrtok. Ja tam nemam nominaciu. Takze snad tam pojde @Lubor .

hanecak · May 28, 2019, 9:28pm

Ano aj. Formalne vzate sa napr. v ZEPf spomina v § 57b co teda patri do PS4 (lebo § 57b, vid Komisia pre štandardy ISVS - #37 by hanecak ). Ale da sa argumenovat, ze ZEPf je aj vec spadajuca pod ‘§ 45 Výmena údajov medzi informačnými systémami verejnej správy’ a teda do PS1. Spomenut teda mozno dane veci aj na PS1 a potom uz ze do akej hlbky sa pojde, zavisi najma od ostanych v PS. Plus samozrejme pre PS1 je to “okrajove”, pre PS2 “klucove”, t.j. tak nejak, primerane.