[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