Linee Guida per la Valorizzazione del Patrimonio Informativo Pubblico (2016) 35
ASPETTI LEGALI E DI COSTO
LICENZE
Figura 7: Licenze aperte e non aperte per i dataset
La Figura 7 mostra le licenze più usate per l’Open Data.
Esse appartengono a tre categorie principali:
- il pubblico dominio o “waiver” 12 dove il dichiarante
“apertamente, pienamente, permanentemente,
irrevocabilmente e incondizionatamente rinuncia,
abbandona e cede ogni proprio diritto d’autore e
connesso, ogni relativa pretesa, rivendicazione,
causa e azione, sia al momento nota o ignota
(includendo espressamente le pretese presenti come
quelle future) relativa all’opera”. Rientrano in questa categoria la CC0 della famiglia delle licenze
internazionali Creative Commons 51 e l a O p e n Data Commons – Public Domain Dedication
License (ODC-PDDL) 52 per i dataset/database; - le licenze per l’open data con richiesta di attribuzione, che
consentono di condividere, adattare e creare anche
per finalità commerciali con il solo vincolo di
attribuire la paternità del dataset. Rientrano in
questa categoria la licenza CC-BY della famiglia
Creative Commons 51, la IODL (Italian Open Data License) nella sua versione 2.0 53 e la Open Data Commons Attribution License (ODC-BY) per
dataset/database 54. - le licenze per l’open data con richiesta di attribuzione e condivisione allo stesso modo, che consentono di
condividere, adattare e creare anche per finalità commerciali nel rispetto però di due vincoli: a)
attribuire la paternità del dataset; b) distribuire eventuali lavori derivati con la stessa licenza che
governa il lavoro originale. Rientrano in questa categoria la licenza CC-BY-SA della famiglia
Creative Commons la IODL nella sua versione 1.0 55 e la Open Data Commons Open Database
License (ODbL) 56 utilizzata dal progetto OpenStreetMap (OSM). In relazione a quanto sopra riportato, tenuto conto del contesto normativo di riferimento, delle
indicazioni in tema di licenze contenute nella Comunicazione della Commissione 2014/C - 240/01
e dei principi di indisponibilità dei beni del demanio culturale espresso negli artt. 10 e 53 del Codice
12 Essendo internazionale, è assoggettato ai vincoli imposti dal diritto nazionale, è bene quindi verificare la sua compatibilità con il
contesto in cui si utilizza. AZIONE 12: ASSICURATI DI ASSEGNARE UNA LICENZA AI DATASET… L’informazione sul tipo di licenza è
metadato indispensabile per
determinare come poter riutilizzare
il dataset. Deve pertanto essere
sempre specificata indicando, il nome, la versione e fornendo il riferimento
al testo della licenza. Nel contesto
dei dati aperti, considerando la
definizione Open Data fornita dal
CAD e dall’Open Knowledge
Foundation (OKFN), per cui un
dato è aperto se è “liberamente usabile, riutilizzabile e ridistribuibile da chiunque per
qualsiasi scopo, soggetto al massimo alla
richiesta di attribuzione e condivisione allo
stesso modo, le sole licenze ammesse
per abilitare l’effettivo paradigma
dell’Open Data sono classificate
come mostrato in Figura 6. Come
evidenziato in figura, tutte le licenze che non consentono lavori derivati,
anche per finalità commerciali, i.e.,
licenze che riportano chiaramente
clausole Non Commercial - NC e/o
Non Derivative – ND e/o ogni altra
clausola che limita la possibilità di
riutilizzo e ridistribuzione dei dati,
non possono essere ritenute valide
per identificare dataset aperti. Linee Guida per la Valorizzazione del Patrimonio Informativo Pubblico (2016) 36 dei beni culturali (D.lgs. 22 gennaio 2004, n. 42), si ritiene opportuno fare riferimento ad una
licenza unica aperta, che garantisca libertà di riutilizzo, che sia internazionalmente
riconosciuta e che consenta di attribuire la paternità dei dataset (attribuire la fonte).
Pertanto, si suggerisce l’adozione generalizzata della licenza CC-BY nella sua versione 4.0,
presupponendo altresì l’attribuzione automatica di tale licenza nel caso di applicazione del
principio “Open Data by default”, espresso nelle disposizioni contenute nell’articolo 52 del
CAD. Si raccomanda inoltre di gestire l’attribuzione della fonte indicando il nome dell’organizzazione
unitamente all’URL della pagina Web dove si trovano i dataset/contenuti da licenziare. Infine, nell’applicazione della licenza si ricorda che non si può disporre/attribuire diritti più ampi
rispetto alla licenza di partenza (e.g., non si può attribuire un pubblico dominio - o waiver - a un
dataset ottenuto da una fonte a cui è associata una licenza che richiede attribuzione). A completamento dell’argomento, si evidenzia l’opportunità di verificare gli aspetti relativi a: • titolarità dei dati secondo la competenza amministrativa; • elaborazione di un’opera derivata, con il conseguente onere di citazione della fonte originale
del dataset e di specifica attribuzione all’opera derivata; • finalità per i quali i dati sono stati creati che eventualmente non consentono di renderli
automaticamente disponibili in open data; • responsabilità del titolare rispetto al riutilizzo dei dati da parte di terzi e, nel caso, specificare una nota legale, che integra e accompagna la licenza. COMPATIBILITÀ TRA LICENZE Un’indicazione di compatibilità tra le licenze Open Data indicate in Figura 7 è riportata nella seguente tabella13: Licenza opera derivata Licenza opera originaria CC0 CC-BY CC-BY-SA IODL v. 2.0 IODL v. 1.0 ODbL CC0 CC-BY CC-BY-SA IODL v. 2.0 IODL v. 1.0 ODbL Tabella 1: Compatibilità tra licenze La creazione di un’opera derivata e la sua pubblicazione è possibile La creazione di un’opera derivata potrebbe essere possibile ma vi è incertezza (ad esempio sui diritti licenziati) circa l’effettiva
compatibilità o altri problemi (problema di stratificazione delle attribuzioni), oppure sul tipo di prodotto derivato (e.s. per la
ODbL le modifiche dei dati sono rilasciabili solo con ODbL mentre i prodotti derivati come le mappe con ogni altra licenza). La creazione di un’opera derivata sotto la licenza proposta è impossibile
- Creative Commons, http://creativecommons.org
- Open Data Commons, ODC-PDDL, http://opendatacommons.org/licenses/pddl/summary/
- Italian Open Data License (IODL) 2.0, http://www.dati.gov.it/iodl/2.0/
- Open Data Commons, ODC-BY http://opendatacommons.org/licenses/by/summary/
- Italian Open Data License (IODL) 1.0, http://www.formez.it/iodl/
- Open Data Commons, ODbL, http://opendatacommons.org/licenses/odbl/
13 Lo schema proposto in tabella è tratto principalmente da: Federico Morando, “Interoperabilità giuridica: rendere i dati (pubblici)
aperti compatibili con imprese e comunità online”, JLIS.it Italian Journal of Library and Information Science, Gennaio 2013,
http://leo.cineca.it/index.php/jlis/article/download/5461/7928 e modificato secondo gli aggiornamenti delle licenze considerate.
Linee Guida per la Valorizzazione del Patrimonio Informativo Pubblico (2016) 37
ASPETTI DI COSTO DEL DATO
In linea con quanto previsto dalla direttiva comunitaria, il citato articolo 7 del D. Lgs. 36/2006
prevede inoltre casi specifici per i quali è possibile determinare tariffe superiori ai costi marginali in deroga
al principio generale di rendere disponibili i dati gratuitamente o a costi marginali, ovvero:
- alle biblioteche, comprese quelle universitarie, di musei e archivi;
- alle amministrazioni e agli organismi di diritto pubblico che devono generare utili per coprire
una parte sostanziale dei costi inerenti allo svolgimento dei propri compiti di servizio pubblico; - ai casi eccezionali relativi a documenti per i quali le pubbliche amministrazioni e gli organismi di
diritto pubblico sono tenuti a generare utili sufficienti per coprire una parte sostanziale dei costi
di raccolta, produzione, riproduzione e diffusione. In tutti i tre casi, i Ministeri competenti, di concerto con il Ministero dell’economia e delle finanze,
sentita AgID, determinano, con appositi decreti, i criteri generali per le tariffe e le relative modalità di
versamento, mantenendo aggiornate le stesse ogni due anni. Nel primo caso, l’importo delle tariffe
comprende i costi di raccolta, produzione, riproduzione, diffusione, conservazione e gestione dei
diritti, maggiorati, nel caso di riutilizzo per fini commerciali , di un congruo utile da determinarsi in
relazione alle spese per investimenti sostenute nel triennio precedente. Negli altri due casi l’importo
delle tariffe comprende i costi di raccolta, produzione, riproduzione, diffusione, maggiorati di un
congruo utile, da determinarsi con appositi decreti, nei casi di riutilizzo per fini commerciali e i n relazione alle spese per investimenti sostenute nel triennio precedente. Nei tre casi di cui sopra, in
presenza di riutilizzo dei dati per scopi non commerciali è prevista una tariffa differenziata da
determinarsi con le modalità suddette secondo il criterio della copertura dei soli costi effettivi
sostenuti dalle amministrazioni.
Alla data di pubblicazione delle presenti linee guida, non si riscontrano ancora casi specifici di
applicazione dei suddetti principi di tariffazione. Nei casi eccezionali di applicazione di tariffe superiori ai costi marginali, va tenuto conto
delle indicazioni contenute nella Comunicazione della Commissione 2014/C - 240/01,
“Metodo del recupero dei costi”. Inoltre, è possibile avvalersi di metodi di analisi dei costi
(e.g., Activity Based Costing, che assegna costi ai prodotti, servizi, progetti e compiti sulla base sia
delle attività svolte per gli stessi sia delle risorse consumate per tali attività) che siano oggettivi, trasparenti e verificabili. A seguito di tale analisi, l'amministrazione può considerare un modello di
business per la determinazione delle tariffe. Un elenco non esaustivo di possibili modelli di business
è riportato nelle linee guida per la valorizzazione del patrimonio informativo pubblico (anno 2014) - Questi modelli sono stati presentati nel progetto europeo Share-PSI 2.0, nell’ambito del
workshop “A Self Sustaining Business Model for Open Data” 58 e possono ancora essere
considerati un riferimento per gli scopi del presente aggiornamento delle linee guida. - Agenzia Per l’Italia Digitale, “Linee guida per la valorizzazione del patrimonio informativo pubblico (anno
2014), http://www.agid.gov.it/sites/default/files/linee_guida/patrimoniopubblicolg2014_v0.7finale.pdf
(Maggio 2014) - https://www.w3.org/2013/share-psi/workshop/krems/report
AZIONE 13: DEFINISCI GLI ASPETTI DI COSTO PER I DATI…
Premesse le azioni di condivisione dei dati tra pubbliche amministrazioni per finalità
istituzionali (artt. 50 e 58 del CAD), che avvengono esclusivamente a titolo gratuito, nel
caso dell’Open Data si suggerisce azioni volte a renderli disponibili esclusivamente a
titolo gratuito. Tuttavia, è prevista la possibilità di richiedere per il riutilizzo dei dati un
corrispettivo specifico, limitato ai costi sostenuti effettivamente per la riproduzione, messa a disposizione e divulgazione dei dati. In tali casi, come previsto dall’art. 7 del D.Lgs 24
gennaio 2006, n. 36, AgID determina, su proposta motivata del titolare del dato, le tariffe
standard da applicare, pubblicandole sul proprio sito istituzionale. sulla base del “Metodo dei costi marginali” esplicitato nella Comunicazione della
Commissione 2014/C - 240/01 contenente, tra gli altri, gli orientamenti sulla tariffazione
AZIONE 13: DEFINISCI GLI ASPETTI DI COSTO PER I DATI…
Premesse le azioni di condivisione dei dati tra pubbliche amministrazioni per finalità
istituzionali (artt. 50 e 58 del CAD), che avvengono esclusivamente a titolo gratuito, nel
caso dell’Open Data si suggerisce azioni volte a renderli disponibili esclusivamente a titolo
gratuito. Tuttavia, è prevista la possibilità di richiedere per il riutilizzo dei dati un
corrispettivo specifico, limitato ai costi sostenuti effettivamente per la riproduzione, messa
a disposizione e divulgazione dei dati. In tali casi, come previsto dall’art. 7 del D.Lgs 24
gennaio 2006, n. 36, AgID determina, su proposta motivata del titolare del dato, le tariffe
standard da applicare, pubblicandole sul proprio sito istituzionale.
sulla base del “Metodo dei costi marginali” esplicitato nella Comunicazione della
Commissione 2014/C - 240/01 contenente, tra gli altri, gli orientamenti sulla tariffazione 4.
Linee Guida per la Valorizzazione del Patrimonio Informativo Pubblico (2016) 38
PUBBLICAZIONE E DATI.GOV.IT
PUBBLICAZIONE DEI DATI
Elementi architetturali
I principali livelli architetturali che compongono una soluzione per la pubblicazione e interrogazione
di dati aperti possono essere istanziati in diverso modo a seconda delle capacità economiche e
tecniche delle amministrazioni, nonché della qualità del servizio che si vuole offrire agli utenti. Si
distinguono due livelli: livello di front-end e livello infrastrutturale.
Il livello di front-end consiste di una parte di presentazione che può essere sia un sito Web, sia una
sezione in un sito esistente. In questa parte rientrano tutti quegli strumenti che consentono di (i) dare
massima visibilità ai dataset disponibili e (ii) di interagire in maniera “user-friendly” con gli utenti
stessi, per esempio per capire quali dati sono di loro interesse, quali nuovi dati sono richiesti, quali
suggerimenti vogliono dare per migliorare anche la qualità dei dati.
Il livello di presentazione si completa con l’interfaccia di accesso via Web per interrogazioni puntuali
sui dati e metadati. Questa ha come obiettivo quello di aumentare l’interazione machine-to-machine
attraverso il dispiegamento di una piattaforma di esposizione dati basata su API di servizio (o Open
Data Service). Nel caso di dati dei livelli 4 e 5 del modello per i dati, l’interfaccia di accesso via Web è
rappresentata dallo SPARQL endpoint.
AZIONE 14: PUBBLICA I DATI MA SOLO DOPO AVER COMPLETATO LE
AZIONI PRECEDENTI…
Prima di pubblicare i dati, assicurati di aver completato queste azioni precedenti e quindi:
AZIONI 1 e 2: di aver chiari i principi delle normative in materia di dati pubblici e loro
riutilizzo
AZIONI 3 e 4: di aver compreso e selezionato il livello più appropriato del modello per i
dati e i metadati , tenendo conto che il requisito minimo per i dati è il livello 3
AZIONE 6 – censimento: di aver identificato nel censimento dei dati la domanda e
l’impatto sociale ed economico che possono e riescono a generare
AZIONE 6 – analisi giuridica delle fonti: di aver verificato eventuali limitazioni
giuridiche (proprietà dei dati, privacy, ecc.)
AZIONE 5: di aver predisposto i metadati secondo il profilo DCAT-AP_IT
AZIONE 9: di aver pianificato le attività in modo da mantenere i dati costantemente
aggiornati e da garantire altri aspetti di qualità (i.e.., completezza, accuratezza, coerenza)
AZIONE 10: di aver descritto i dati di riferimento e "core" secondo i modelli indicati
nell’architettura di riferimento per l’informazione del settore pubblico
AZIONE 11: di aver predisposto i dati con almeno un formato aperto machine-readable
AZIONE 12: di aver assegnato una licenza aperta, possibilmente quella raccomandata
dalle presenti linee guida (CC-BY 4.0)
Durante la fase di pubblicazione è necessario garantire agli utenti la possibilità di ottenere
i dati in bulk, ovvero fornirli in blocco in un file o insieme di file, senza richiedere
credenziali di accesso (a meno di farlo per mere iniziative conoscitive dell’utenza che
dovranno essere comunque esplicitate, dando all’utente la possibilità di rifiutare e/o
rimanere anonimo), e di interrogare il dato mediante la messa a disposizione di API
(Application Programming Interface) che possono essere usate anche per acquisire
piccole porzioni dei dati.
Nel caso di pubblicazione di LOD è necessario garantire che gli URI dei dati siano
persistenti e deferenziabili e che uno SPARQL endpoint sia presente per abilitare funzioni
di interrogazione.
Infine, assicurati di documentare i dati pubblicati in dati.gov.it (AZIONE 15).
Linee Guida per la Valorizzazione del Patrimonio Informativo Pubblico (2016) 39
In generale, si raccomanda di:
(i) assegnare ai dataset nomi autoesplicativi per comprenderne il principale contenuto;
(ii) fornire, ove possibile, descrizioni testuali dei dataset;
(iii) mettere in evidenza la licenza in uso in forma “human e machine-readable”;
(iv)fornire, ove possibile, strumenti di visualizzazione e navigazione, anche georiferita,
dei dati, che possano facilitare la lettura degli stessi;
(v) fornire, ove possibile, statistiche di uso, accesso e produzione;
(vi)fornire notifiche di cambiamenti nel sito web, di aggiornamenti ai dataset (e.g., RSS
feed);
(vii) fornire strumenti per rendere le interrogazioni più agevoli , anche per utenti non del
tutto esperti. Nel caso dei dati dei livelli 4 e 5 non si può pubblicare solo dataset RDF
ma è bene mettere in evidenza la presenza dello SPARQL endpoint (i.e., servizio
Web che accetta interrogazioni SPARQL, le risolve e restituisce i risultati in
output), pubblicando il link di accesso, fornendo altresì un ampio insieme di
“query” di esempio che con pochi click possono essere eseguite producendo risultati
disponibili in diversi formati di più facile e comune utilizzo (e.g., CSV, JSON, XML,
HTML)
Nei casi di amministrazioni di minori dimensioni o amministrazioni che non siano nelle
condizioni di poter fornire un servizio con le caratteristiche sopra elencate , si consiglia di
implementare azioni di sussidiarietà verticale (ad esempio, i comuni di medio-piccole
dimensioni possono riferirsi alla Regione di appartenenza) o di unirsi in iniziative comuni.
Le iniziative OpenCoesione14 e Linked Open Data della Camera dei Deputati 15 offrono buoni esempi
e buone pratiche per applicare le suddette raccomandazioni.
Il livello infrastrutturale è rappresentato dall’infrastruttura che ospita i dati e i metadati. Nel caso di dati
aperti, tenuto conto della loro natura intrinseca, ovvero dati tipicamente non riferibili a singole
persone e per i quali solitamente non si richiede il soddisfacimento di specifici requisiti di protezione
dei dati personali, tecnologie basate sul paradigma del cloud computing pubblico (o di comunità come
il cloud del Sistema Pubblico di Connettività) possono essere facilmente impiegabili al fine di ospitare
le infrastrutture per la pubblicazione di dati aperti.
Soluzioni Open Data per i portali Web
Si raccomanda di non creare tanti portali diversi per singole iniziative ma, ove possibile, di
raccordarle per facilitare il reperimento e il riutilizzo dei dati da parte degli utenti finali.
Di seguito si riportano alcune possibili soluzioni per la creazione di piattaforme di pubblicazione dei
dati.
SOLUZIONE NATIVA. Viene creato un portale ad-hoc o creata un'apposita sezione di un portale
esistente. In questo caso, la creazione non differisce dalla creazione di un sito Web classico16.
ESTENSIONE SOLUZIONE CMS ESISTENTE. Molto spesso l'amministrazione gestisce già un sito Web,
realizzato mediante l’uso di un CMS, che vuole estendere con una sezione dedicata agli Open Data. La
criticità in questo caso è data dall'aggiunta di una componente semantica all'interno della
configurazione del CMS stesso. In questo ambito, merita una menzione il progetto Apache Stanbol 17
che mira a dare supporto in questo senso.
UTILIZZO DI PIATTAFORME ESTERNE. Viene utilizzata una piattaforma che integra già funzionalità per la
catalogazione, visualizzazione, ricerca e interrogazione dei dati. In alcuni casi queste piattaforme sono
disponibili in modalità cloud computing. Gli strumenti di questo tipo più utilizzati sono CKAN,
DKAN, Socrata. Essi si prestano anche per essere facilmente integrati con portali già esistenti.
14 http://www.opencoesione.gov.it/
15 http://dati.camera.it/sparql
16 Si applicano anche le raccomandazioni delle linee guida di design per i siti web delle PA, http://designer.italia.it/
17 https://stanbol.apache.org/
Linee Guida per la Valorizzazione del Patrimonio Informativo Pubblico (2016) 40
Requisiti per la pubblicazione di dati di livello 4 e 5
I Linked Data utilizzano URI per risolvere il problema dell'identità; gli URI devono essere persistenti e
dereferenziabili.
Una politica per garantire URI persistenti e fornire aspetti di naming è proposta dalla commissione
europea con il documento sulle “10 regole per URI persistenti” 59. Facendo riferimento a tale
documento, per la creazione di URI persistenti sono da evitare quelli che contengano:
• nome del progetto/ufficio/unità amministrativa che detiene la risorsa per evitare problemi
derivanti dalla fine del progetto stesso o fusioni o chiusure di uffici nell’organizzazione;
• numeri di versione;
• identificatori esistenti che in passato sono stati utilizzati per identificare risorse differenti;
• riferimenti generati in modo automatico e incrementale a meno che non vi sia la garanzia che
il processo non venga mai più ripetuto o, se ripetuto, generi sicuramente gli stessi identificatori
per gli stessi dati di input;
• stringhe rappresentanti “query” a database;
• estensione del file.
Sono, invece, da ritenersi buone pratiche le seguenti:
• strutturare l’URI come segue:
http://{dominio}/{tipo}/{concetto}/{riferimento}
dove gli elementi che compongono la URI sono:
o Dominio: il dominio Web su cui reperire la risorsa
o Tipo: l’elemento che specifica il tipo di risorsa. Dovrebbe poter assumere un numero
limitato di valori come “doc” se la risorsa identificata è un documento descrittivo,
“set” se la risorsa è un dataset, “id” o “item” se la risorsa è un oggetto del mondo reale
o Concetto: il tipo di un oggetto del mondo reale
o Riferimento: lo specifico elemento, termine o concetto che rappresenta la risorsa
• costruire URI per più formati al fine di identificare al meglio la risorsa
• collegare tra loro le rappresentazioni multiple della stessa risorsa
• implementare il codice di risposta 303 per gli oggetti del mondo reale (si veda sotto “content
negotiation” e “dereferenziazione” degli URI)
• utilizzare servizi dedicati
Si raccomanda di considerare anche la possibilità di mantenere URI persistenti mediante
w3id.org 60, ovvero un servizio per applicazioni Web che fornisce meccanismi sicuri e permanenti
di re-direzione, garantendo l’uso di URI sempre riferibili a siti web funzionanti. Il servizio è
mantenuto dal W3C Permanent Identifier Community Group.
Inoltre, facendo uso di URI HTTP per identificare le risorse RDF, si potrebbe incorrere in URI
ambigue, ovvero URI che rappresentano sia entità del Web Semantico, sia risorse Web (ad esempio,
pagine Web, file, ecc.). A tal riguardo occorre gestire le richieste HTTP sulla base del loro tipo: queste
possono richiedere dati (e.g., l'attributo “Accept” della richiesta valorizzato con
“application/rdf+xml”) oppure risorse Web (e.g., l'attributo “Accept” della richiesta valorizzato con
“text/html”). Questo processo è anche detto “ content negotiation ”. Esistono strumenti quali Pubby,
ELDA, LodLive che integrano nativamente la “content-negotiation”.
Infine, esistono situazioni, tipicamente con accesso da Web browser, in cui è richiesta una risorsa (non
ambigua) del Web Semantico come se questa fosse una pagina HTML. In questi casi si può rispondere
all'utente con una pagina Web informativa relativa alle informazioni associate all'entità identificata con
quell'URI. Questa operazione è detta dereferenziazione degli URI.
Il W3C ha pubblicato un rapporto tecnico dettagliato 61 sulla dereferenziazione delle URI e sulla
“content negotiation” al quale si consiglia di far riferimento.
59. ISA and W3C, “Study on persistent URIs, with identification of best practices and recommendations on the
topic for the MSs and the EC”, https://joinup.ec.europa.eu/sites/default/files/c0/7d/10/D7.1.3%20-%20Study
%20on%20persistent%20URIs.pdf
60. W3C Permanent Identifier Community Group, “Permanent Identifiers for the Web”, https://w3id.org/, 2016.
61. W3C, “Cool URIs for the Semantic Web, https://www.w3.org/TR/cooluris/, 3 Dicembre 2008.