Giuseppe,
ti rispondo su qualche punto particolarmente stuzzicante:
Il pdf, per come la vedo io, non è un formato aperto (di fatto lo è
ma è chiuso nel senso della struttura!) e se anche i pc lo leggono e
lo scrivono, in pratica non posso fare, ad esempio, analisi
statistiche sui contenuti del pdf (quante parole contiene un testo,
quali sono le parole più ricorrenti ecc.), soprattutto se il file è
l'insieme di una serie di scansioni: il testo non è più testo ma
immagine (giusto?);
giustissimo: ma la scelta di un qualsiasi strumento tecnologico
va sempre messa in relazione con lo scopo specifico.
se mi pubblichi un bilancio solo ed esclusivamente in PDF di
fatto mi stai rendendo molto difficoltoso se non praticamente
impossibile analizzare e verificare nel dettaglio le tue cifre:
quindi e' una scelta decisamente molto infelice.
ma se invece mi pubblichi un carteggio manoscritto tra Garibaldi e
Mazzini piuttosto che i diari di scavo del Maiuri a Pompei tra le
due guerre mondiali (comprese tutte le planimetrie e magari pure
con qualche foto), ecco che invece il PDF diventa una scelta
assolutamente ragionevole e meritoria.
(specie se ti assicuri che siano PDF/A)
insomma, va valutato caso per caso; anche il PDF puo' avere
una sua dignita' in certi contesti.
quindi, nella mia ottica, va bene il pdf scaricabile ma io offrirei
all'utente anche formati tipo html (html5 ha fatto passi da gigante
verso il semantic web), xml o csv; un file strutturato mi
permetterebbe, ad esempio di fare un mesh-up tra contenuti presenti a
giro per a rete e crearmi la mia biblioteca personale estraendo, ad
esempio, solo i titoli e gli abstract degli articoli dei convegni che
seguo, con link agli originali.
certamente si: se e' tecnicamente ammissibile pubblicare in
qualche formato facilmente rielaborabile e' sicuramente molto
meglio. e quando e' possibile mettere in piedi servizi di data
harvesting e' meglio ancora.
se poi hai abbastanza fiato e muscoli lasciare libera scelta
tra due o tre formati alternativi sarebbe sicuramente il top.
personalmente raffredderei di molto i sacri entusiasmi per il
semantic web, che troppo spesso come diceva fantozzi "e' una
boiata pazzeca", specie quando viene fatto con i piedi come
troppo spesso accade.
oppure quando finisce col diventare semplicemente un grimaldello
per cercare di spillare sonanti soldini a qualche PA.
(e purtroppo accade pure questo, specie qua in italia).
serebbe sempre opportuno ricordarsi che gli open data nascono
come riuso intelligente di patrimoni informativi gia' esistenti
(perche' prodotti per tutt'altri scopi e finalita') tramite
condivisione libera ed aperta.
insomma e' un modo molto figo per riciclare tutto quello che
hai gia' in casa affrontando solo dei costi marginali.
investire soldi freschi per produrre Open Data fatti ad hoc
e' un'asineria macro-economica di dimensioni colossali.
Lo shp, per come la vedo io, non è un formato standard (almeno fino
a qualche tempo fa non lo era per l'OGC, sinceramente non so se è
cambiato qualcosa), anche se "de facto" lo è diventato
qua stai confondendo concetti che invece vanno tenuti ben separati.
"standard" e' un concetto sempre relativo, e sottintende tutta
una scala gerarchica:
- standard de facto: esiste e prendiamo atto che funziona: stop.
dopo tutto anche csv e txt/tab non hanno nessun documento di
specifica formale alle spalle: eppure funzionano.
- standard codificato: qualcuno ha fissato formalmente una regola;
non e' tanto importante "chi" ha fissato la regola; l'importante
e' che la regola ci sia da qualche parte, e che tutti gli
interessati possano prenderne liberamente conoscenza senza
dovere sottostare a vincoli.
- standard ufficiale: idem come sopra; ma questa volta con il
debito avallo di un ente o organizzazione autorevole.
- standard internazionale: meglio ancora se si tratta di una
organizzazione o consorzio internazionale
- standard univerale: in pratica e' sinonimo di standard ISO,
l'organizzazione che rappresenta tutti i governi del mondo
e che ha autorita' indiscussa ed indiscutibile su qualsiasi
altro organismo.
spesso gli standard percorrono faticosamente tutta la gerarchia
prima di arrivare alla vetta (ammesso che ci arrivino mai).
p.es. KML e' nato come formato codificato in casa Google e
solo successivamente e' stato adottato da OGC.
PDF e' nato in casa Adobe: dopo di che PDF/A e' diventato uno
standard ISO
Spatial SQL, WMS e WFS sono nati dentro ad OGC ma poi si sono
evoluti fino a diventare standard ISO
viceversa l'ubiquo zipfile si basa per intero su qualche appunto
sparso scritto dal signor Phil Karz nel 1989 quando rilascio'
la primissima versione di PkWare.
tra i formati di immagine piu' popolari TIFF sta in piedi
semplicemente in base ad un documento pubblicato inizialmente
da Aldus e poi in seguito da Adobe: cioe' e' esattanebte alla
pari con lo Shapefile di ESRI.
JPEG e JPEG2000 sono il frutto di un consorzietto ad hoc,
seppure internazionale.
dobbiamo arrivare a PNG per trovare finalmente uno standard
a prova di bomba: ISO 15948
se vuoi un mio personalissimo parere, quello piu' flessibile
e che meglio ti garantisce piena interoperabilita' universale
e' proprio TIFF, anche se tra tutti e' quello con ascendenze
meno nobili e blasonate ;-)
soprattutto non è aperto/apribile (si ok, lo è il dbf ma secondo me
non è abbastanza).
Qui entra in gioco anche il discorso sw: il file
.prj, a mio avviso fondamentale, non viene generato da tutti i sw;
qgis lo crea, arc-gis non lo so, di sicuro non open-jump.
essere uno standard significa semplicemente garantire
interoperabilita'; non significa necessariamente eccellenza
tecnica.
l'architettura Shapefile fa acqua da tutte le parti, sembra
quasi un colapasta; criticare SHP e' un po' come sparare
addosso alla Croce Rossa.
ma questo non toglie che sia lo standard de facto nel suo ramo,
e che abbia ben poche alternative realisticamente applicabili.
il file .prj e' un'estensione ESRI non documenta e poco
supportata: e non e' neppure strettamente indispensabile.
molte PA che pubblicano open data sotto forma di shapefile
aggirano elegantemente il problema in modo banalmente
semplice:
- p.es. scrivendo sulla pagina di download qualche utile
noticina relativa al sistema di riferimento
- oppure (meglio ancora) allegando un PDF o un Readme.txt
dentro allo zip in cui vengono riportate sia le condizioni
di licenza che tutti gli altri eventuali metadati.
Tutti questi problemi non li ho se lavoro con altri formati (aperti e
apribili) tipo gml, json ecc.
ti lancio una domanda volutamente provocatoria.
supponiamo che io voglia rilasciare qualche corposo dataset
vettoriale, diciamo qualche centinaio di MB in totale.
posso farlo sotto forma di shapefile, ed in questo modo
saro' sicuro di fare felici e contenti indistintamente tutti
i possibili interessati, a prescindere da quale sw usino.
girera' sicuramente dappertutto, e posso dare per scontato
che lo sapranno usare anche le scimmie sugli alberi.
oppure posso fare una scelta nobilnebte elegabte: decido di
rilasciare tutto come GML ... anzi, meglio ancora come
GML Topology.
questo introduce magari la spiacevole conseguenza che prima
di riuscire a leggere quel pop' di besione di file GML Topo
ci vorranno molte lunghe ore di paziente elaborazione, e
magari servira' pure una macchina particolarmente muscolosa
e con un sacco di RAM.
per non parlare del fatto che molto verosimilmente servira'
qualche sw abbastanza specialistico, sconosciuto ai piu'
e non troppo diffuso, magari anche abbastanza complicatino
da utilizzare: p.es. GDAL da riga di comando.
secondo te, quale tra le due alternative favorira' maggiormente
il reale riutilizzo dei dati da parte del maggior numero di
utenti in modo semplice e con minori complicazioni ?
Infine, se è vero che posso applicare una licenza open ad un dwg,
mi/vi chiedo: ha senso? Non violo i principi base dell'open data
circa
l'usabilità, l'assenza di restrizioni tecnologiche, i formati aperti
ecc.
certo che li viola: tutti quanti ed in un sol colpo.
stai usando un formato chiuso, chiusissimo, che richiede
necessariamente l'uso di sw molto specifico prodotto da
una singola azienda.
farai cosa sicuramente migliore e piu' saggia se ti prendi
la (piccola) briga di esportare quei dati nel formato DXF.
resta il fatto che la perfezione e' sempre un asintoto: la
cosa piu' importante e' fare il primo passettino nella direzione
giusta, poi tutto il resto seguira' inevitabilmente.
ok, rilasciare sotto open data un DWG e' un abominio che grida
vendetta al cielo.
ma intanto hai ottenuto comunque qualcosa di molto significativo;
ora quei dati sono sbloccati, sono diventati liberi, rielaborabili
e pubblicamente condivisibili.
se i tuoi dati sono realmente interessanti qualcun altro si
prendera' sicuramente la briga di convertirli al posto tuo in
un qualche altro formato meno sciagurato ed iniziera' a pubblicarli
a sua volta.
tu molto probabilmente ci farai la misera figuretta dell'incompetente
assoluto, e verrai giustamente ricoperto di improperi e di infamia.
ma comunque il dato liberato finira' prima o poi inevitabilmente
col percorrere la propria strada.
ergo: se per assoluta carenza di risorse finanziarie, di skill
tecnologici e di know how specifico non si riesce materialmente
a fare nulla di meglio ben venga anche lo sventuratissimo DWG
open data.
sara' sempre sicuramente molto meglio che continuare a tenersi
quei dati belli chiusi dentro a qualche polveroso cassetto.
ciao Sandro
_______________________________________________
Gfoss@lists.gfoss.it
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni
dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015
