[Rejestr] Fwd: formaty danych
Paweł Krawczyk
pawel.krawczyk w hush.com
Pon, 30 Maj 2011, 23:03:10 CEST
Panie Igorze,
Ponieważ spora część z tych uwag pochodzi ze zgłoszenia jakie w lutym
przesłałem do MSWiA więc odsyłam do tego dokumentu, który w całości jest
opublikowany tutaj:
http://echelon.pl/sites/echelon.pl/files/uwagi_do_kri.pdf
“Załącznika nr 6” czyli dawnego rozporządzenia o minimalnych wymaganiach
dotyczy przede wszystkim “Uwaga nr 6” na stronach 3-4. Na początku opisałem
jaki moim zdaniem powinien być charakter tego rozporządzenia - tzn. trzy
listy formatów, z czego tylko jedna prawdopodobnie powinna być
obligatoryjna.
Część uwag ma charakter czysto redakcyjny – np. poprawne opisanie formatów
oraz zarządzających nimi organizacji wpływa pozytywnie na jakość i
aktualność rozporządzenia. To jest kwestia poświęcenia jakiegoś czasu przez
osobę redagującą to rozporządzenie na dokładne sprawdzenie jakie są aktualne
wersje specyfikacji, kto nimi zarządza itd.
Z kolei uwzględnienie lub nieuwzględnienie SSL, DER czy XLSX powinno wynikać
z charakteru tego rozporządzenia. Jak pisałem, w dotychczasowej postaci (od
2005 roku) jest to trochę groch z kapustą. Z jednej strony “wszyscy wiedzą”,
że jak się przesyła login i hasło do serwera to robi się to po SSL, a SSL
korzysta z certyfikatów w formacie DER. Z drugiej strony jeśli administracja
publiczna działa na podstawie przepisów prawa to albo należy napisać
“korzystamy z powszechnie uznanych standardów” albo napisać konkretnie
jakich.
W zaproponowanym przeze mnie układzie (trzy listy) problem jest łatwy do
rozwiązania – istotne będzie przede wszystkim precyzyjne opisanie protokołów
i formatów, którymi administracja chce “rozmawiać” ze światem zewnętrznym.
Druga lista określi interfejsy między urzędami. Trzecia, najbardziej
otwarta, określi dobre praktyki do stosowania wewnątrz urzędów, jeśli takowe
istnieją, oraz ochroni urzędy przed pułapką vendor lock-in.
Jeśli chodzi o wymienione przez Pana standardy “(i) ONZowskiego Akoma Ntoso,
(ii) GIS, (iii) CVS, (iv) KML, czy (v) Odata” to każdy służy chyba do czego
innego (Akoma Ntoso – publikacja dokumentów oficjalnych; GIS, KML to
geografia; CVS – czy chodziło o CSV?). Należy więc postawić pytanie jaki
format do udostępniania – ale udostępniania CZEGO? Bo inny format będzie
sensowny do publikacji ogólnego opisu np. procedury, inny do publikacji aktu
prawnego, a inny do publikacji mapki geodezyjnej.
Natomiast faktycznie, w wielu przypadkach z punktu widzenia odbiorcy
największą dostępność zapewni publikacja w dwóch formatach – źródłowym do
przetwarzania automatycznego (np. opis miejsca w KML) i w postaci
zwizualizowanej do “szybkiego podglądu” w przeglądarce (np. jako obrazek).
Czyli takie modelowe rozporządzenie powinno zawierać listę rekomendacji w
tej postaci:
Jeśli...
1) chcesz udostępnić pismo ogólne – do publikacji treści pisma użyj HTML z
formatowaniem CSS oraz skanu PDF do publikacji wyglądu pisma (pieczątek itd)
2) chcesz udostępnić mapę geodezyjną – użyj formatu X (nie wiem czego się
tam używa)
3) chcesz udostępnić Y – użyj formatu Y
itd
To nie do końca na temat, ale moim zdaniem dobrze przemyślany i spójny model
zaproponowano w całej architekturze Centralnego Repozytorium Dokumentów –
m.in. rozdzielenie wzorów od formularzy oraz koncepcja centralnych
repozytoriów. Został tam także dostrzeżony problem wizualizacji - w
projekcie rozporządzenia w sprawie pism... a tam §22, który odnosi się
właśnie do kwestii wizualizacji:
http://www.bip.mswia.gov.pl/portal/bip/218/19507
„W przypadku gdy podpisany i doręczony do podmiotu publicznego lub przez
podmiot publiczny dokument elektroniczny jest pismem przeznaczonym do
przeczytania przez człowieka, dokument ten powinien być możliwy do
zwizualizowania bez potrzeby korzystania z centralnego repozytorium lub
lokalnego repozytorium”.;
Jeśli na podstawie tego modelu – który jest neutralny technologicznie -
zaczniemy się teraz zastanawiać jakich konkretnie formatów należy tam
używać, to wyjdzie nam dokładnie pożądana konstrukcja “załącznika nr 2” do
KRI.
From: Igor Ostrowski
Sent: Monday, May 30, 2011 8:16 PM
To: rejestr
Subject: [Rejestr] Fwd: formaty danych
Szanowni Panstwo,
dostałem informację, że nie wszyscy z Państwa otrzymali moja wiadomość w
sprawie formatów danych. Wysyłam jeszcze raz z prośbą o ew. opinie
Pozdrawiam
Igor Ostrowski
Begin forwarded message:
From: Igor Ostrowski <iostrowski w projektpolska.pl>
Date: May 17, 2011 4:25:11 PM GMT+02:00
To: rejestr <rejestr w isoc.org.pl>
Subject: formaty danych
Szanowni Panstwo,
Chciałbym powrócić do dyskusji dot. standardów i formatów danych
udostępnianych przez administrację w ramach ustawy o dostępie do informacji
publicznej. Na ostatnim spotkaniu Premier wyraził gotowość rozmowy o
zmianach w prawie, które zobowiązywałyby podmioty administracji państwowej
do udostępniania danych w formacie umożliwiającym odczyt maszynowy, jeżeli
są w posiadaniu danych w takim formacie (w skrócie xml obok pdf'u).
Rozporządzenie wydane na podstawie art. 18 ustawy o informatyzacji (o czym
mowa w poprzednich mailach - poniżej) wydaje mi się właściwym miejscem do
wprowadzenia norm określających standard udostępnianych danych. W chwili
obecnej MSWiA pracuje nad projektem rozporządzenia "w sprawie Krajowych Ram
Interoperacyjności, minimalnych wymagów dla rejestrów publicznych i wymiany
informacji w formie elektronicznej oraz minimalnych wymagów dla systemów
teleinformatycznych", które ma włąśnie zostac wydane na mocy art. 18.
Projekt znajduje się tu: http://bip.mswia.gov.pl/download.php?s=4&id=8282.
W uwagach do projektu rozporządzenia pojawiają się zarówno zarzuty
merytoryczne, dotyczące przedmiotu regulacji, jak i dotyczące redakcji czy
zakresu oddziaływania.
Podnoszono między innymi, że:
• załącznik nr 2 do projektu rozporządzenia (określającym formaty danych
oraz standardy zapewniające dostęp do zasobów informacji udostępnianych za
pomocą systemów teleinformatycznych używanych do realizacji zadań
publicznych) jest "właściwie przepisany bez zmian z rozporządzenia o
minimalnych wymaganiach z 2005 roku, ze wszystkimi tego konsekwencjami.
Oznacza to, że znajdziemy tam m.in brak precyzyjnego określenia gdzie
właściwie trzeba te formaty stosować, a gdzie nie (A2C, C2A, A2A?)"
• niejasne jest "czy dokumenty wymieniane między komponentami backoffice
urzędu w formacie SQL powinny być teraz eksportowane do formatu CSV
zamaskowanego jako TXT i ponownie importowane;
• "przypadkowy katalog popularnych formatów dokumentów, obrazków i
archiwów, w wielu przypadkach bez żadnej informacji normatywnej (...)
zarówno PDF, ODT jak i OOXML są normami ISO; tymczasem według autora
projektu formatami tymi zarządza nadal Adobe (przekazali do ISO) i Microsoft
(przekazali do ECMA)";
• "brak jakiegokolwiek określenia minimalnych i maksymalnych wersji
poszczególnych formatów, przez co załącznik traci sens jako minimalne
wymagania (baseline); zgodnie z obecnym brzmieniem zaszyfrowany plik
zabezpieczony DRM będzie zgodny, byle tylko nazywał się PDF i jakiś program
go otwierał";
• przewidziano "archaiczne formaty typu RTF"
• jako organizacje zarządzające są wymienione firmy, które stworzyły dany
format, nawet gdy formatem zarządzają już organizacje standaryzujące
• wymienione są formaty niszowe i specjalistyczne (TAR, GZIP) lub
prywatne, funkcjonujące na zasadzie standardu de facto (RAR).
• brak jest popularnych formatów arkuszy kalkulacyjnych - XLS, XLSX, ODS
• pominięcie standardów protokołów komunikacyjnych (ZUS, obywatel)
• pominięto formaty mniej znane, ale powszechnie wykorzystywane (DER do
cert. X.509, OAI-PMH, PKCS#7
Biorąc powyższe pod uwagę zastanawiam się czy jesteśmy w stanie
zarekomendować Premierowi konkretne zmiany w projekcie rozporządzenia, które
umożliwiłyby osiągnięcie podstawowego celu, jakim jest udostępniania danych
w formacie umożliwiającym odczyt maszynowy, jeżeli są w posiadaniu danych w
takim formacie. Najprostrzym rozwiązaniem byłoby zobowiązanie podmiotów do
udostępniania informacji w dwóch a nie jednym formacie wskazanym w
załączniku nr. 2. Warto zastanowić się także nad sensownością wprowadzania
innych standardów: (i) ONZowskiego Akoma Ntoso, (ii) GIS, (iii) CVS, (iv)
KML, czy (v) Odata. Warto także zastanowić się nad innymi problmami
standardów udostępniania danych, związanych z semantyką i strukturą danych.
Będę bardzo wdzięczny za opinię w sprawie.
Pozdrawiam
Igor
Begin forwarded message:
Date: Thu, 28 Apr 2011 23:14:53 +0200
From: "Jarek Deminet" <jarekdem w gazeta.pl>
To: "=?ISO-8859-2?Q?Jacek_Zadro=BFny?=" <jacek.zadrozny w post.pl>
Cc: rejestr-bounces w isoc.org.pl, Justyna.Kucinska w firr.org.pl,
Anna.Rozborska w firr.org.pl, Piotr.Pawlowski w firr.org.pl,
Michal.Dziwisz w firr.org.pl, Jacek.Zadrozny w firr.org.pl,
Piotr.Witek w firr.org.pl, 'rejestr' <rejestr w isoc.org.pl>
Subject: Re: [Rejestr] Fwd: spotkanie z min. M. Bonim
Message-ID: <4DB9D8CD.22410.560B10B w jarekdem.gazeta.pl>
Content-Type: text/plain; charset="iso-8859-2"
OK, nie ma co się spierać.
Jeśli będzie wpisane wymaganie poziomu AAA, to nie znaczy to, że teksty
MUSZĄ być np. w
XML, lecz raczej że jeśli nie są odczytywalne, to powinien być dostępny
tekstowy skrót.
Ale oczywiście trzeba nalegać, żeby jak najwięcej tekstów było
odczytywalnych.
Pozdrawiam
-- Jarek
JZ: niezupełnie. Za ustawą:
"Art. 18. Rada Ministrów, na wniosek ministra właściwego do spraw
informatyzacji, określi w drodze
rozporządzenia:
1) minimalne wymagania dla systemów teleinformatycznych, mając na
uwadze konieczność
zapewnienia:
a) spójności działania systemów teleinformatycznych używanych
do realizacji zadań publicznych
poprzez określenie co najmniej specyfikacji formatów danych oraz
protokołów komunikacyjnych i
szyfrujących, które mają być stosowane w oprogramowaniu
interfejsowym, przy zachowaniu
możliwości nieodpłatnego wykorzystania tych specyfikacji,
b) sprawnej i bezpiecznej wymiany informacji w postaci
elektronicznej między podmiotami
publicznymi oraz między podmiotami publicznymi a organami innych
państw lub organizacji
międzynarodowych,
c) dostępu do zasobów informacji osobom niepełnosprawnym
- z uwzględnieniem Polskich Norm oraz innych dokumentów
normalizacyjnych zatwierdzonych przez
krajową jednostkę normalizacyjną, zachowując zasadę równego
traktowania różnych rozwiązań"
JZ: a zatem chodzi o dostęp do zasobów informacji, a nie do samych
systemów. Aby mieć dostęp
do zasobów informacji osoby niepełnosprawne muszą mieć dostęp
do informacji oraz do systemu
ją serwującego.
Jacek Zadrożny
_____
From: Jarek Deminet [mailto:jarekdem w gazeta.pl]
Sent: Thursday, April 28, 2011 11:15 PM
To: Jacek Zadrożny
Cc: pawel.krawczyk w hush.com; rejestr-bounces w isoc.org.pl; 'Jozef
Halbersztadt'; 'rejestr'; Aleksander Waszkielewicz;
Justyna.Kucinska w firr.org.pl; Anna.Rozborska w firr.org.pl;
Piotr.Pawlowski w firr.org.pl; Jacek.Zadrozny w firr.org.pl;
Piotr.Witek w firr.org.pl; Michal.Dziwisz w firr.org.pl
Subject: Re: [Rejestr] Fwd: spotkanie z min. M. Bonim
OK, nie ma co się spierać.
Jeśli będzie wpisane wymaganie poziomu AAA, to nie znaczy to, że teksty
MUSZĄ być np. w XML, lecz raczej że jeśli nie są odczytywalne, to
powinien
być dostępny tekstowy skrót.
Ale oczywiście trzeba nalegać, żeby jak najwięcej tekstów było
odczytywalnych.
JZ: oczywiście, że nie musi to być XML. To może być PDF, DOC czy ODT.
Jednak
nie zgadzam się, że ma być dostępny skrót. To ma być informacja
ekwiwalentna. Nota bene PDF może być skanem dokumentu i tekstem
jednocześnie. Format na to pozwala.
Jacek Zadrożny
Fundacja Instytut Rozwoju Regionalnego
http://www.firr.org.pl <http://www.firr.org.pl/>
jacek.zadrozny w firr.org.pl
Organizacja Pożytku Publicznego
-------------- następna część ---------
Załącznik HTML został usunięty...
URL:
<http://listy.icm.edu.pl/pipermail/rejestr/attachments/20110429/707cd0ff/attachment-0001.html>
------------------------------
_______________________________________________
Rejestr mailing list
Rejestr w isoc.org.pl
http://listy.icm.edu.pl/mailman/listinfo/rejestr
Koniec Paczka Rejestr, Tom 16, Numer 33
***************************************
--------------------------------------------------------------------------------
_______________________________________________
Rejestr mailing list
Rejestr w isoc.org.pl
http://listy.icm.edu.pl/mailman/listinfo/rejestr
-------------- następna część ---------
Załącznik HTML został usunięty...
URL: <http://listy.icm.edu.pl/pipermail/rejestr/attachments/20110530/2aabe506/attachment-0001.html>
Więcej informacji o liście Rejestr