[Semi-OT] Licenze chiuse e dati aperti

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[Semi-OT] Licenze chiuse e dati aperti

Giuseppe Naponiello
Buongiorno a tutti,
per sicurezza in oggetto ho specificato "semi-ot", nel caso fossi completamente off topic vi chiedo scusa!
Il problema che mi è stato posto, e che mi ha trovato un po' spiazzato, è il seguente:
Mario crea un dato, geografico ma non solo, con un software chiuso, mettiamo uno shp fatto con arc-gis o, meglio, un dwg. 
Carica questo file sul web, in un suo repository e ci appiccica una licenza libera, mettiamo cc-by. Io scarico il dwg, me lo faccio convertire da un mio amico in dxf, con qualche magheggio lo importo in postgres e, via geoserver, lo pubblico sul mio webgis con cc0, citando la fonte come chiesto dalla licenza iniziale.
Vi chiedo:
1. una licenza libera o open data è compatibile con un dato creato con software chiuso? 
2. Non c'è qualche limitazione presente nelle licenze tipo eula legate al riutilizzo, opere derivate et similia?
3. A parte tutte le considerazioni di tipo filosofico, posso creare dati aperti con software chiusi? Intendo se c'è qualche considerazione di tipo tecnico che sconsiglia l'utilizzo di sw chiuso a favore di quello aperto.

Alla prima domanda ho fatto notare che una licenza open data per sua natura non può essere applicata a tutti i file ma solo a quelli con determinate caratteristiche: uno shp non può essere open data, json e csv, ad esempio, si. Giusto?
Alle altre 2 non ho saputo ripondere...

Ciao a tutti

-beppe-
--
Giuseppe Naponiello

Arc-Team srl
piazza Navarrino, 13 - 38023Cles (TN) 
C.F. e P. IVA IT-01941600221 
cell.
 +393476846599
mail: [hidden email]
pec: [hidden email]
www.arc-team.com
http://arc-team-open-research.blogspot.it/

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [Semi-OT] Licenze chiuse e dati aperti

a.furieri
On Thu, 30 Apr 2015 11:22:53 +0200, Giuseppe Naponiello wrote:

> Buongiorno a tutti,
> per sicurezza in oggetto ho specificato "semi-ot", nel caso fossi
> completamente off topic vi chiedo scusa!
> Il problema che mi è stato posto, e che mi ha trovato un po'
> spiazzato, è il seguente:
> Mario crea un dato, geografico ma non solo, con un software chiuso,
> mettiamo uno shp fatto con arc-gis o, meglio, un dwg. 
> Carica questo file sul web, in un suo repository e ci appiccica una
> licenza libera, mettiamo cc-by. Io scarico il dwg, me lo faccio
> convertire da un mio amico in dxf, con qualche magheggio lo importo
> in
> postgres e, via geoserver, lo pubblico sul mio webgis con cc0,
> citando
> la fonte come chiesto dalla licenza iniziale.

Giuseppe,

questo non lo puoi fare perche' violi la licenza.
se tu passi a CC0 (public domain) da quel punto in poi rendi invisibile
l'attribuzione alla fonte iniziale.
devi continuare ad usare CC-BY, perche' anche chi casomai riutilizza
i tuoi dati modificati e' comunque tenuto legalmente a citare la
fonte iniziale.

puoi "salire in alto", introducendo qualche ulteriore vincolo:
"se volete riusare i miei dati modificati invece di quelli originali
allora vi beccate una CC-BY-SA" :-)
ma non puoi mai rilassare i vincoli di partenza.


> Vi chiedo:
> 1. una licenza libera o open data è compatibile con un dato creato
> con software chiuso? 
>

le mele sono mele, le pere sono pere, i gatti sono gatti, i cani
sono cani, il software e' software, i dati sono dati.
che c'azzecca il dato con il sw che l'ha prodotto oppure con
quello che utilizzarai per la fruizione ? nulla di nulla

licenze sw e licenze dati viaggiano su piani distinti e separati.


> 2. Non c'è qualche limitazione presente nelle licenze tipo eula
> legate al riutilizzo, opere derivate et similia?
>

dipende ovviamente dalla eula e da come e' scitta: in genere no,
non ci sono limitazioni relative ai dati che produci con un sw.
li usi con quel che ti pare meglio (se riesce a leggerli).


> 3. A parte tutte le considerazioni di tipo filosofico, posso creare
> dati aperti con software chiusi? Intendo se c'è qualche
> considerazione di tipo tecnico che sconsiglia l'utilizzo di sw chiuso
> a favore di quello aperto.
>

prendi il caso di un file XML, meglio ancora GML: se e' pienamente
conforme alle specifiche non contiene nessun elemento che ti consenta
di capire con quale sw particolare e' stato prodotto.
al massimo ci potrai trovare dentro un commento che dice "by pinco
1.0";
ma quel commento l'avresti anche potuto aggiungere o rimuovere
facilmente
con un banale text editor senza alterare minimante il contenuto vero e
prorpio, non e' un elemento significativo
idem dicasi per JPEG, PNG, TIFF, Shp etc etc etc

l'unico problema tecnico reale puo' nascserse quando un sw non genera
dei files perfettamente coerenti con le specifiche.
allora si che rischi di avere problemi che ne limitano la reale
interoperablita'
ma questo ovviamente dipende dal singolo sw e magari anche dalla
specifica versione, non ha assolutamente nulla a che vedere con la
dicotomia open vs closed.

quando si parla di dati le uniche domande tecnicamente sensate sono:
- e' un formato aperto, pubblicamente documentato e non gravato
   da brevetti ?
- oppure e' un formato chiuso, oscuro e protetto da vincoli ?

comunque assai spesso usare sw open per creare open data e' un'opzione
che non ha solo un mero valore "filosofico".
se usi sw open sei sempre sicuro di usare formati aperti e documentati;
e presumibilmente l'implementazione sara' altamente interoperabile.
cosa non sempre ovvia e scontata con i sw proprietari.


> Alla prima domanda ho fatto notare che una licenza open data per sua
> natura non può essere applicata a tutti i file ma solo a quelli con
> determinate caratteristiche: uno shp non può essere open data, json e
> csv, ad esempio, si. Giusto?
>

no, sbagliatissimo :-D

gli shapefiles possono essere ottimi open data, e di fatto quasi tutti
i materiali gis-like che trovi in giro come open data sono proprio
in formato shp.
e' vero che il formato SHP e' stato "inventato" da ESRI; ma e'
anche vero che tutta la documentazione tecnica relativa e' sempre
stata abbondamente pubblica, in forma gratuita e senza nessun
vincolo di brevetto o di copyright.
ergo: shapefile e' un legittimo "formato aperto" a tutti gli effetti

la stessa identica cosa avviene per TIFF (inventato inizialmente
da Adobe) e per PDF (sembre made in Adobe): in entrambi i casi
le specifiche tecniche del formato sono sempre state pubbliche
e non gravate da brevetti, e quindi sono formati aperti.
addirittura il PDF nella variante PDF/A oggi e' diventato uno
standard internazionale ISO

altre aziende hanno preferito seguire strade diverse: puo'
essere interessante il caso AutoDesk.
il formato DWG e' sempre stato chiuso e blindato; e quindi
e' decismente pessimo come materiale open data
viceversa il formato DXF e' sempre stato pubblicamente
documentato, e la stessa AutoDesk ha inivitato esplicitmanete
gli sviluppatori indipendenti ad adottarlo come formato
aperto ed interoperabile.
ergo DXF puo' essere considerato un ragionevole candidato
per un rilascio open data.

ciao Sandro
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [Semi-OT] Licenze chiuse e dati aperti

Giuseppe Naponiello
Ciao Alessandro,

se tu passi a CC0 (public domain) da quel punto in poi rendi invisibile
l'attribuzione alla fonte iniziale.
devi continuare ad usare CC-BY, perche' anche chi casomai riutilizza
i tuoi dati modificati e' comunque tenuto legalmente a citare la
fonte iniziale.
 
verissimo, non ci avevo mai pensato, forse perché non mi è mai capitato...se anche io cito la fonte per correttezza, chi utilizza dopo di me i miei dati in CC0 non è tenuto a farlo e quindi violo la licenza iniziale...perfetto, chiarissimo ;)

Sul resto della tua risposta ci sono alcuni punti che non mi tornano...forse perché, da buon novellino, ho una visione ancora un po' rigida della questione.
I miei dubbi nascono intorno alla definizione di Open Data, in particolare al discorso della neutralità "rispetto agli strumenti tecnologici necessari per la fruizione dei dati stessi...", e aggiungiamoci anche il discorso del formato aperto che forse io confondo con "apribile"!!!
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?); 
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.

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, e 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. Come fa giustamente notare Andrea Borruso [0] distibuire shp come open data, può creare problemi.
Credo sia capitato un po' a tutti di dover "cercare" la proiezione giusta per shapefile che non avevano un sistema dichiarato, finché siamo in Italia ok, a me è capitato di lavorare con dati armeni, ed ho avuto un po' di problemi!
Altro esempio legato agli shapefile è quello dell'encoding: dovevo importare degli shp in una tabella postgis ma mi dava errore sull'encoding dello shapefile (il db era utf8), il proprietario non sapeva manco cosa fosse un encoding, per me era la prima volta che avevo 'sto problema quindi ho perso tempo per cercare di capire la codifica dello shapefile (si ok, la codifica è legata sia al sw che al sistema operativo, bastava capire queste 2 cose e risolvevo subito, ma 7 anni fa non ero così sveglio! Si ok, posso settare la codifica del mio shapefile, ma il problema non si pone per chi lo sa, e non credo che la maggior parte degli utenti che usano quotidianamente un gis lo sappia...e in ogni caso il problema resta).
Tutti questi problemi non li ho se lavoro con altri formati (aperti e apribili) tipo gml, json ecc.

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.

Mi scuso per la lunga mail ma sto cercando di convincere una PA a rilasciare i dati in formati aperti ma se ho delle lacune in materia, o sono ancora un po' confuso su alcuni aspetti, come faccio a convincerli? 

;)




Il giorno 30 aprile 2015 12:13, <[hidden email]> ha scritto:
On Thu, 30 Apr 2015 11:22:53 +0200, Giuseppe Naponiello wrote:
Buongiorno a tutti,
per sicurezza in oggetto ho specificato "semi-ot", nel caso fossi
completamente off topic vi chiedo scusa!
Il problema che mi è stato posto, e che mi ha trovato un po'
spiazzato, è il seguente:
Mario crea un dato, geografico ma non solo, con un software chiuso,
mettiamo uno shp fatto con arc-gis o, meglio, un dwg. 
Carica questo file sul web, in un suo repository e ci appiccica una
licenza libera, mettiamo cc-by. Io scarico il dwg, me lo faccio
convertire da un mio amico in dxf, con qualche magheggio lo importo in
postgres e, via geoserver, lo pubblico sul mio webgis con cc0, citando
la fonte come chiesto dalla licenza iniziale.

Giuseppe,

questo non lo puoi fare perche' violi la licenza.
se tu passi a CC0 (public domain) da quel punto in poi rendi invisibile
l'attribuzione alla fonte iniziale.
devi continuare ad usare CC-BY, perche' anche chi casomai riutilizza
i tuoi dati modificati e' comunque tenuto legalmente a citare la
fonte iniziale.

puoi "salire in alto", introducendo qualche ulteriore vincolo:
"se volete riusare i miei dati modificati invece di quelli originali
allora vi beccate una CC-BY-SA" :-)
ma non puoi mai rilassare i vincoli di partenza.


Vi chiedo:
1. una licenza libera o open data è compatibile con un dato creato
con software chiuso? 


le mele sono mele, le pere sono pere, i gatti sono gatti, i cani
sono cani, il software e' software, i dati sono dati.
che c'azzecca il dato con il sw che l'ha prodotto oppure con
quello che utilizzarai per la fruizione ? nulla di nulla

licenze sw e licenze dati viaggiano su piani distinti e separati.


2. Non c'è qualche limitazione presente nelle licenze tipo eula
legate al riutilizzo, opere derivate et similia?


dipende ovviamente dalla eula e da come e' scitta: in genere no,
non ci sono limitazioni relative ai dati che produci con un sw.
li usi con quel che ti pare meglio (se riesce a leggerli).


3. A parte tutte le considerazioni di tipo filosofico, posso creare
dati aperti con software chiusi? Intendo se c'è qualche
considerazione di tipo tecnico che sconsiglia l'utilizzo di sw chiuso
a favore di quello aperto.


prendi il caso di un file XML, meglio ancora GML: se e' pienamente
conforme alle specifiche non contiene nessun elemento che ti consenta
di capire con quale sw particolare e' stato prodotto.
al massimo ci potrai trovare dentro un commento che dice "by pinco 1.0";
ma quel commento l'avresti anche potuto aggiungere o rimuovere facilmente
con un banale text editor senza alterare minimante il contenuto vero e
prorpio, non e' un elemento significativo
idem dicasi per JPEG, PNG, TIFF, Shp etc etc etc

l'unico problema tecnico reale puo' nascserse quando un sw non genera
dei files perfettamente coerenti con le specifiche.
allora si che rischi di avere problemi che ne limitano la reale
interoperablita'
ma questo ovviamente dipende dal singolo sw e magari anche dalla
specifica versione, non ha assolutamente nulla a che vedere con la
dicotomia open vs closed.

quando si parla di dati le uniche domande tecnicamente sensate sono:
- e' un formato aperto, pubblicamente documentato e non gravato
  da brevetti ?
- oppure e' un formato chiuso, oscuro e protetto da vincoli ?

comunque assai spesso usare sw open per creare open data e' un'opzione
che non ha solo un mero valore "filosofico".
se usi sw open sei sempre sicuro di usare formati aperti e documentati;
e presumibilmente l'implementazione sara' altamente interoperabile.
cosa non sempre ovvia e scontata con i sw proprietari.


Alla prima domanda ho fatto notare che una licenza open data per sua
natura non può essere applicata a tutti i file ma solo a quelli con
determinate caratteristiche: uno shp non può essere open data, json e
csv, ad esempio, si. Giusto?


no, sbagliatissimo :-D

gli shapefiles possono essere ottimi open data, e di fatto quasi tutti
i materiali gis-like che trovi in giro come open data sono proprio
in formato shp.
e' vero che il formato SHP e' stato "inventato" da ESRI; ma e'
anche vero che tutta la documentazione tecnica relativa e' sempre
stata abbondamente pubblica, in forma gratuita e senza nessun
vincolo di brevetto o di copyright.
ergo: shapefile e' un legittimo "formato aperto" a tutti gli effetti

la stessa identica cosa avviene per TIFF (inventato inizialmente
da Adobe) e per PDF (sembre made in Adobe): in entrambi i casi
le specifiche tecniche del formato sono sempre state pubbliche
e non gravate da brevetti, e quindi sono formati aperti.
addirittura il PDF nella variante PDF/A oggi e' diventato uno
standard internazionale ISO

altre aziende hanno preferito seguire strade diverse: puo'
essere interessante il caso AutoDesk.
il formato DWG e' sempre stato chiuso e blindato; e quindi
e' decismente pessimo come materiale open data
viceversa il formato DXF e' sempre stato pubblicamente
documentato, e la stessa AutoDesk ha inivitato esplicitmanete
gli sviluppatori indipendenti ad adottarlo come formato
aperto ed interoperabile.
ergo DXF puo' essere considerato un ragionevole candidato
per un rilascio open data.

ciao Sandro
_______________________________________________
[hidden email]
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



--
Giuseppe Naponiello

Arc-Team srl
piazza Navarrino, 13 - 38023Cles (TN) 
C.F. e P. IVA IT-01941600221 
cell.
 +393476846599
mail: [hidden email]
pec: [hidden email]
www.arc-team.com
http://arc-team-open-research.blogspot.it/

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [Semi-OT] Licenze chiuse e dati aperti

Maurizio Napolitano-2
In reply to this post by Giuseppe Naponiello
> Vi chiedo:
> 1. una licenza libera o open data è compatibile con un dato creato con
> software chiuso?

Dipende dai termini di uso.
Nel tuo caso specifico e nella maggior parte dei software desktop non
ci sono vincoli su quanto generato dai software.
Nel caso invece dei software cloud (twitter, facebook, gmail ecc...)
dato che vengono offerti come servizi, allora vengono messi vincoli
sui dati.
Ripeto: non è assolutamente il tuo caso


> 2. Non c'è qualche limitazione presente nelle licenze tipo eula legate al
> riutilizzo, opere derivate et similia?

solo nei software as service come segnalati sopra

> 3. A parte tutte le considerazioni di tipo filosofico, posso creare dati
> aperti con software chiusi? Intendo se c'è qualche considerazione di tipo
> tecnico che sconsiglia l'utilizzo di sw chiuso a favore di quello aperto.

Certo che puoi, quello che non puoi è fare il giochino di cambiare licenza
(da cc-by a cc0)

> Alla prima domanda ho fatto notare che una licenza open data per sua natura
> non può essere applicata a tutti i file ma solo a quelli con determinate
> caratteristiche: uno shp non può essere open data, json e csv, ad esempio,
> si. Giusto?

no
Una licenza definisce i termini di riuso dei dati.
L'open data però chiede di offrire neutralità tecnologica e quindi
formati aperti
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [Semi-OT] Licenze chiuse e dati aperti

Andrea Peri
In reply to this post by Giuseppe Naponiello
Ciao,

formato aperto e' inteso nel senso di formato "documentato".

O, in altri termini, che leggendo un documento liberamente scaricbaile
puoi venire a sapere come e' fatto internamente.
Per questo e' detto aperto.

Te invece intendi "aperto" nel senso che e' apribile da un editor di testo.
:)

Ti diro' di piu':

se io ti faccio un formato testo , con un sacco di numeri codificati
con una codifica che conosco solo io e che non documento da nessna
parte.
Per te e' aperto perche' lo leggi con il text-editor, ma pero' vedi
dentro un sacco di numeri imbrigliati in una codifica criptica.
E non riesci a tirarci fuori niente.

Quindi: aperto e' intsso nel senso di "documentato", non di testuale
anziche' binario.

Per cui lo shapefile e' aperto, ilgm e' aperto, il dxf e' aperto.
Il DWG non lo e' perche' non ci sono documenti che ne spieghino la struttura.

Ciao,,
A.



Il 30 aprile 2015 15:31, Giuseppe Naponiello <[hidden email]> ha scritto:

> Ciao Alessandro,
>
>> se tu passi a CC0 (public domain) da quel punto in poi rendi invisibile
>> l'attribuzione alla fonte iniziale.
>> devi continuare ad usare CC-BY, perche' anche chi casomai riutilizza
>> i tuoi dati modificati e' comunque tenuto legalmente a citare la
>> fonte iniziale.
>
>
> verissimo, non ci avevo mai pensato, forse perché non mi è mai capitato...se
> anche io cito la fonte per correttezza, chi utilizza dopo di me i miei dati
> in CC0 non è tenuto a farlo e quindi violo la licenza iniziale...perfetto,
> chiarissimo ;)
>
> Sul resto della tua risposta ci sono alcuni punti che non mi tornano...forse
> perché, da buon novellino, ho una visione ancora un po' rigida della
> questione.
> I miei dubbi nascono intorno alla definizione di Open Data, in particolare
> al discorso della neutralità "rispetto agli strumenti tecnologici necessari
> per la fruizione dei dati stessi...", e aggiungiamoci anche il discorso del
> formato aperto che forse io confondo con "apribile"!!!
> 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?);
> 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.
>
> 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, e 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. Come fa giustamente notare Andrea Borruso [0]
> distibuire shp come open data, può creare problemi.
> Credo sia capitato un po' a tutti di dover "cercare" la proiezione giusta
> per shapefile che non avevano un sistema dichiarato, finché siamo in Italia
> ok, a me è capitato di lavorare con dati armeni, ed ho avuto un po' di
> problemi!
> Altro esempio legato agli shapefile è quello dell'encoding: dovevo importare
> degli shp in una tabella postgis ma mi dava errore sull'encoding dello
> shapefile (il db era utf8), il proprietario non sapeva manco cosa fosse un
> encoding, per me era la prima volta che avevo 'sto problema quindi ho perso
> tempo per cercare di capire la codifica dello shapefile (si ok, la codifica
> è legata sia al sw che al sistema operativo, bastava capire queste 2 cose e
> risolvevo subito, ma 7 anni fa non ero così sveglio! Si ok, posso settare la
> codifica del mio shapefile, ma il problema non si pone per chi lo sa, e non
> credo che la maggior parte degli utenti che usano quotidianamente un gis lo
> sappia...e in ogni caso il problema resta).
> Tutti questi problemi non li ho se lavoro con altri formati (aperti e
> apribili) tipo gml, json ecc.
>
> 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.
>
> Mi scuso per la lunga mail ma sto cercando di convincere una PA a rilasciare
> i dati in formati aperti ma se ho delle lacune in materia, o sono ancora un
> po' confuso su alcuni aspetti, come faccio a convincerli?
>
> ;)
>
>
> [0]
> http://blog.spaziogis.it/2013/03/19/2013-anno-degli-opengeodata-lentusiasmo-mio-e-calante/
>
>
> Il giorno 30 aprile 2015 12:13, <[hidden email]> ha scritto:
>>
>> On Thu, 30 Apr 2015 11:22:53 +0200, Giuseppe Naponiello wrote:
>>>
>>> Buongiorno a tutti,
>>> per sicurezza in oggetto ho specificato "semi-ot", nel caso fossi
>>> completamente off topic vi chiedo scusa!
>>> Il problema che mi è stato posto, e che mi ha trovato un po'
>>> spiazzato, è il seguente:
>>> Mario crea un dato, geografico ma non solo, con un software chiuso,
>>> mettiamo uno shp fatto con arc-gis o, meglio, un dwg.
>>> Carica questo file sul web, in un suo repository e ci appiccica una
>>> licenza libera, mettiamo cc-by. Io scarico il dwg, me lo faccio
>>> convertire da un mio amico in dxf, con qualche magheggio lo importo in
>>> postgres e, via geoserver, lo pubblico sul mio webgis con cc0, citando
>>> la fonte come chiesto dalla licenza iniziale.
>>
>>
>> Giuseppe,
>>
>> questo non lo puoi fare perche' violi la licenza.
>> se tu passi a CC0 (public domain) da quel punto in poi rendi invisibile
>> l'attribuzione alla fonte iniziale.
>> devi continuare ad usare CC-BY, perche' anche chi casomai riutilizza
>> i tuoi dati modificati e' comunque tenuto legalmente a citare la
>> fonte iniziale.
>>
>> puoi "salire in alto", introducendo qualche ulteriore vincolo:
>> "se volete riusare i miei dati modificati invece di quelli originali
>> allora vi beccate una CC-BY-SA" :-)
>> ma non puoi mai rilassare i vincoli di partenza.
>>
>>
>>> Vi chiedo:
>>> 1. una licenza libera o open data è compatibile con un dato creato
>>> con software chiuso?
>>>
>>
>> le mele sono mele, le pere sono pere, i gatti sono gatti, i cani
>> sono cani, il software e' software, i dati sono dati.
>> che c'azzecca il dato con il sw che l'ha prodotto oppure con
>> quello che utilizzarai per la fruizione ? nulla di nulla
>>
>> licenze sw e licenze dati viaggiano su piani distinti e separati.
>>
>>
>>> 2. Non c'è qualche limitazione presente nelle licenze tipo eula
>>> legate al riutilizzo, opere derivate et similia?
>>>
>>
>> dipende ovviamente dalla eula e da come e' scitta: in genere no,
>> non ci sono limitazioni relative ai dati che produci con un sw.
>> li usi con quel che ti pare meglio (se riesce a leggerli).
>>
>>
>>> 3. A parte tutte le considerazioni di tipo filosofico, posso creare
>>> dati aperti con software chiusi? Intendo se c'è qualche
>>> considerazione di tipo tecnico che sconsiglia l'utilizzo di sw chiuso
>>> a favore di quello aperto.
>>>
>>
>> prendi il caso di un file XML, meglio ancora GML: se e' pienamente
>> conforme alle specifiche non contiene nessun elemento che ti consenta
>> di capire con quale sw particolare e' stato prodotto.
>> al massimo ci potrai trovare dentro un commento che dice "by pinco 1.0";
>> ma quel commento l'avresti anche potuto aggiungere o rimuovere facilmente
>> con un banale text editor senza alterare minimante il contenuto vero e
>> prorpio, non e' un elemento significativo
>> idem dicasi per JPEG, PNG, TIFF, Shp etc etc etc
>>
>> l'unico problema tecnico reale puo' nascserse quando un sw non genera
>> dei files perfettamente coerenti con le specifiche.
>> allora si che rischi di avere problemi che ne limitano la reale
>> interoperablita'
>> ma questo ovviamente dipende dal singolo sw e magari anche dalla
>> specifica versione, non ha assolutamente nulla a che vedere con la
>> dicotomia open vs closed.
>>
>> quando si parla di dati le uniche domande tecnicamente sensate sono:
>> - e' un formato aperto, pubblicamente documentato e non gravato
>>   da brevetti ?
>> - oppure e' un formato chiuso, oscuro e protetto da vincoli ?
>>
>> comunque assai spesso usare sw open per creare open data e' un'opzione
>> che non ha solo un mero valore "filosofico".
>> se usi sw open sei sempre sicuro di usare formati aperti e documentati;
>> e presumibilmente l'implementazione sara' altamente interoperabile.
>> cosa non sempre ovvia e scontata con i sw proprietari.
>>
>>
>>> Alla prima domanda ho fatto notare che una licenza open data per sua
>>> natura non può essere applicata a tutti i file ma solo a quelli con
>>> determinate caratteristiche: uno shp non può essere open data, json e
>>> csv, ad esempio, si. Giusto?
>>>
>>
>> no, sbagliatissimo :-D
>>
>> gli shapefiles possono essere ottimi open data, e di fatto quasi tutti
>> i materiali gis-like che trovi in giro come open data sono proprio
>> in formato shp.
>> e' vero che il formato SHP e' stato "inventato" da ESRI; ma e'
>> anche vero che tutta la documentazione tecnica relativa e' sempre
>> stata abbondamente pubblica, in forma gratuita e senza nessun
>> vincolo di brevetto o di copyright.
>> ergo: shapefile e' un legittimo "formato aperto" a tutti gli effetti
>>
>> la stessa identica cosa avviene per TIFF (inventato inizialmente
>> da Adobe) e per PDF (sembre made in Adobe): in entrambi i casi
>> le specifiche tecniche del formato sono sempre state pubbliche
>> e non gravate da brevetti, e quindi sono formati aperti.
>> addirittura il PDF nella variante PDF/A oggi e' diventato uno
>> standard internazionale ISO
>>
>> altre aziende hanno preferito seguire strade diverse: puo'
>> essere interessante il caso AutoDesk.
>> il formato DWG e' sempre stato chiuso e blindato; e quindi
>> e' decismente pessimo come materiale open data
>> viceversa il formato DXF e' sempre stato pubblicamente
>> documentato, e la stessa AutoDesk ha inivitato esplicitmanete
>> gli sviluppatori indipendenti ad adottarlo come formato
>> aperto ed interoperabile.
>> ergo DXF puo' essere considerato un ragionevole candidato
>> per un rilascio open data.
>>
>> ciao Sandro
>> _______________________________________________
>> [hidden email]
>> 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
>
>
>
>
> --
> Giuseppe Naponiello
>
> Arc-Team srl
> piazza Navarrino, 13 - 38023Cles (TN)
> C.F. e P. IVA IT-01941600221
> cell. +393476846599
> mail: [hidden email]
> pec: [hidden email]
> www.arc-team.com
> http://arc-team-open-research.blogspot.it/
>
> _______________________________________________
> [hidden email]
> 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



--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [Semi-OT] Licenze chiuse e dati aperti

a.furieri
In reply to this post by Giuseppe Naponiello
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
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [Semi-OT] Licenze chiuse e dati aperti

Andrea Peri
Aho Alessandro,
parla meglio del gml topology eh ?

Va bene che il GML topology, ovvero la estensione topologica del GML,
seppur codificata nello standard GML 3.1, non sia mai stata utlizzata
da nessuno al mondo , salvo una piccola amministrazione regionale sita
nell'italia centrale.

Il fatto che esista un unico software al mondo in grado di decodificarlo.
Che nessuna mente umana riesca a comprenderlo direttamente.
Che chi si e' cimentato nella sua comprensione sperando di riuscire a
scrivere una procedura automatica di decodifica, sia stato poi
ricoverato in una struttura riabilitativa per sindroni di stress
mentale.

Non vuol mia dire che fa schifo eh ?
eh ?

Anzi', esso e' l' apoteosi della strutturazione.
Pensa che schiccheri a se avessimoinserito un file in GML topologico
dentro la sonda voyager per dire agli extraterrestri dove si trovava
la terra.
Altro che dischetto con sopra impressa una immagine del sistema solare.
Puah !

:)

A.


Il 30 aprile 2015 18:39,  <[hidden email]> ha scritto:

> 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
> _______________________________________________
> [hidden email]
> 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



--
-----------------
Andrea Peri
. . . . . . . . .
qwerty àèìòù
-----------------
_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

p

a.furieri
On Thu, 30 Apr 2015 21:08:15 +0200, Andrea Peri wrote:
> Aho Alessandro,
> parla meglio del gml topology eh ?
>
> Va bene che il GML topology, ovvero la estensione topologica del GML,
> seppur codificata nello standard GML 3.1, non sia mai stata utlizzata
> da nessuno al mondo , salvo una piccola amministrazione regionale
> sita
> nell'italia centrale.
>

ma guarda che combinazione: era giunta vagamente anche a me una voce
su qualcosa del genere. :-)


> Il fatto che esista un unico software al mondo in grado di
> decodificarlo.
> Che nessuna mente umana riesca a comprenderlo direttamente.
> Che chi si e' cimentato nella sua comprensione sperando di riuscire a
> scrivere una procedura automatica di decodifica, sia stato poi
> ricoverato in una struttura riabilitativa per sindroni di stress
> mentale.
>
> Non vuol mia dire che fa schifo eh ?
> eh ?
>
> Anzi', esso e' l' apoteosi della strutturazione.
>

mai detto cha fa schifo; e confermo sinceramente che e' realmente
un mirabile capolavoro di eleganza formale e concettuale.
... magari lascia un po' a desiderare come usabilita' pratica quando
i datasets cominciano a contenere piu' di poche migliaia di features,
ma dopo tutto nessuno e' perfetto.


> Pensa che schiccheri a se avessimoinserito un file in GML topologico
> dentro la sonda voyager per dire agli extraterrestri dove si trovava
> la terra.
> Altro che dischetto con sopra impressa una immagine del sistema
> solare.
> Puah !
>
> :)
>

dai, se sono alieni minimamente rispettabili sicuramente hanno gia'
scoperto come si fa a deformare l'iperspazio usando l'annichilazione
materia-antimateria per viaggiare a velocita' iperluminale, dispongono
di siluri fotonici e di phasers, sono perfettamente in grado di usare
il teletrasporto ed i raggi sia traenti che deflettori.

quindi pare legittimo ipotizzare che dispongano anche di computer
iperveloci ad altissimo parallelismo basati sull'effetto tunnel
quantistico e che utilizzino banchi di memoria ottica olografica
di capacita' quasi infinita.

vedrai che loro ci riescono agevolmente a decodificare quel GML
Topology in meno di un'ora; forse addirittura anche in meno di dieci
minuti, dipende solo da quanto e' avanzata la loro tecnologia. :-D


_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [Semi-OT] Licenze chiuse e dati aperti

geodrinx
In reply to this post by a.furieri


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).

Alessandro,  qua scatta un applauso con "standing ovation" da parte mia.
Sono sicuro che in molti seguiranno il mio esempio e arriveremo alla "oola" di gratitudine nei tuoi riguardi.

Finalmente una voce libera  :)

A quando, le folle grideranno compatte "Basta con XML come metadati" ?
E anche "Viva il ReadMe.txt"  oppure  "Finiamola con l'XTD e la sem-antìca burocratese".

 
sarebbe 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.


Parole sante !

Meno tag e più sostanza !

:)

_______________________________________________
[hidden email]
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
Reply | Threaded
Open this post in threaded view
|

Re: [Semi-OT] Licenze chiuse e dati aperti

Giuseppe Naponiello

Grazie a tutti per la pazienza con cui mi avete risposto, ora ho le idee molto più chiare!

Però c'è ancora qualcosa che mi sfugge, ma mi rendo conto che è un mio problema ;)

Andrea, non volevo ridurre il discorso a "è open se si può aprire con un editore di testo", il mio era più un tentativo di trovare il modo per avere un accesso più agevole sia al dato che al metadato, così da poter automatizzare eventuali procedure...ho in mente, ad esempio, le richieste "json" a geoserver, formato di cui sto "abusando" per le cose su cui sto lavorando.

Alessandro, sono d'accordo sull'esempio che hai fatto sui PDF ma, se avessi materiale storico importante pianificherei la possibilità, ad esempio, di una trascrizione, l'ho fatto per un paio di progetti e la cosa ha funzionato... quello che voglio dire è che, secondo me, con un minimo di sbattimento in più si possono facilmente trovare altre soluzioni.

Ripeto, la mia esperienza da pseudo-progammatore-fai-da-te è limitata rispetto alla vostra, e posso non rendermi conto dei problemi oggettivi legati allo sviluppo e al mantenimento di un sistema di gestione dati ma mi sono ritrovato spesso a dover gestire dati eterogenei forniti da persone diverse in diversi formati, dai dwg ai file di photoshop, e mi sono reso conto che pianificando bene il workflow in fase di progettazione, anche il mantenimento risulta più agevole.

In archeologia, ad esempio, gestiamo tante liste, tabelle ecc., quindi mi chiedo: se tanto devo lavorare con excel, cosa mi costa salvare anche in csv? Oppure, se metto su un webgis, quasi sempre passo da geoserver o mapserver, quindi perché non fornire i dati, oltre che in shp, in formati alternativi tipo json? E perché non sfruttare anche wms o wfs? Non credo "costi" tanto.

Per un sistema che sto sviluppando abbiamo deciso con i responsabili del progetto di fornire agli utenti (ad esempio le ditte archeologiche) dei "template" per i dati, sia alfanumerici che vettoriali, in diversi formati, (ad esempio oltre al classico shp forniremo anche un file sqlite); in questo modo da un lato sono sicuro di avere dei dati coerenti con il db che li deve gestire (a meno che l'utente non faccia strane cose sui file originali!), dall'altro diamo la possibilità all'utente di conoscere formati con cui, probabilmente, non ha mai lavorato.

Un sistema che mi piace moltissimo per come è stato strutturato è confiscatibene.it., ecco, secondo me un servizio di open data dovrebbe essere così!

Grazie ancora per la stimolante chiaccherata

;)

-beppe-


Il giorno 3 maggio 2015 17:30, Geo DrinX <[hidden email]> ha scritto:


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).

Alessandro,  qua scatta un applauso con "standing ovation" da parte mia.
Sono sicuro che in molti seguiranno il mio esempio e arriveremo alla "oola" di gratitudine nei tuoi riguardi.

Finalmente una voce libera  :)

A quando, le folle grideranno compatte "Basta con XML come metadati" ?
E anche "Viva il ReadMe.txt"  oppure  "Finiamola con l'XTD e la sem-antìca burocratese".

 
sarebbe 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.


Parole sante !

Meno tag e più sostanza !

:)



--
Giuseppe Naponiello

Arc-Team srl
piazza Navarrino, 13 - 38023Cles (TN) 
C.F. e P. IVA IT-01941600221 
cell.
 +393476846599
mail: [hidden email]
pec: [hidden email]
www.arc-team.com
http://arc-team-open-research.blogspot.it/

_______________________________________________
[hidden email]
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