Stelline, RDF e LInked Data: spunti di riflessione
174 views
Skip to first unread message
Matteo Brunati
Jul 22, 2013, 12:12:19 PM7/22/13
to spaghett...@googlegroups.com
Ciao ragazzi,
un po' che non scrivo ma ci sono: vorrei aprire un thread a parte sui temi che sono già emersi nella discussione su OpenDataGround tra Andrea, Michele ed Irene.[1] ( gran bello scambio, tra parentesi )
Perchè è un fulcro di un mondo di senso che ha bisogno di respirare, e di trovare spiegazioni lucide e coerenti.
E soprattutto basate su fatti concreti, su esperienze dirette, in modo tale da semplificare il caos per chi cerca di affrontare il tema RDF e/o Linked Data da oggi, senza aver vissuto le discussioni di n anni.
Intanto ricordo che durante l'estate il sito http://linkeddata.org/ dovrebbe vedere degli aggiornamenti importanti ( attraverso il programma google summer code, se non erro, ma ricordo di averlo visto in lista ).
Proviamo a partire dalle spalle dei giganti e vedere dove ci porta.
In questa lista ci sono persone che usano tecnologie del semweb, dei Linked Data e RDF, ed altri che possono fare da spalla in un confronto costruttivo, provenienti dal mondo degli sviluppatori, e non solo.
Io direi che vale la pena provare con un confronto costruttivo, specie in questi mesi estivi, dove forse qualcuno ha più tempo ( non io eh eh ).
Parto con una considerazione: quando ho seguito per diversi mesi tutte le call del gruppo di lavoro RDF-WG[2], sono partito da un interesse. Quello di vedere dove si potrebbe andare con un po' di semantica in più, e non tutto lo stack Semweb.
Da quel gruppo di lavoro è nata quella costola, incubata, che ha creato JSON-LD.
Dal mio punto di vista, uno dei componenti tecnologici che potrebbero risolvere molte incompresioni a vantaggio di tutti quanti.
Perchè da appassionato e non accademico, io usavo Simile Exhibit da tempo, e vedevo dei chiari vantaggi per lo sviluppatore medio.
Che però, non era semplice comunicare.
Partirei dallo schema dei destinatari di questa tecnologia[3], che alla fine in quei mesi, non è stata direttamente oggetto del gruppo di lavoro. Il perchè esisteva: non si capiva chi fossero i suoi destinatari.
E comunque, nel gruppo di lavoro, non erano presenti abbastanza stakeholders per portarne avanti gli interessi.
Infatti nel 2011 in UK durante gli Open Data Hackathon, praticamente nessuno tra gli sviluppatori presenti conosceva termini come Linked Data o RDF. Segno che le comunità proprio non si parlavano.
E al W3C ne erano consapevoli.
Sono stati fatti sforzi di inclusione e di dialogo nel frattempo, tra cui la nascita del Community Group come nuovo concetto al W3C.
E' tempo di fare uno sforzo anche qui, nel nostro piccolo, ora che comunque tra dati strutturati presenti in HTML5 ( microdata, RDFa ) e Linked Data con n sintassi possibili o n tecnologie possibili, le vie non sono certo chiare.
Sarebbe un peccato, ed è importante che emerga un racconto condiviso, anche per connessioni nuove, come la visibilità SEO, per dire.[4]
<to be continued, this is an open topic>
Matt
[1] - https://groups.google.com/d/msg/spaghettiopendata/dslO3LT1mes/Hv7uCqu9lTYJ
[2] - http://www.w3.org/2011/rdf-wg/wiki/Main_Page
[3] - http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments
[4] - http://www.dagoneye.it/blog/2013/01/09/dati-strutturati-in-google-quali-recepisce-schema-org-rdfa-e-microdati/
un po' che non scrivo ma ci sono: vorrei aprire un thread a parte sui temi che sono già emersi nella discussione su OpenDataGround tra Andrea, Michele ed Irene.[1] ( gran bello scambio, tra parentesi )
Perchè è un fulcro di un mondo di senso che ha bisogno di respirare, e di trovare spiegazioni lucide e coerenti.
E soprattutto basate su fatti concreti, su esperienze dirette, in modo tale da semplificare il caos per chi cerca di affrontare il tema RDF e/o Linked Data da oggi, senza aver vissuto le discussioni di n anni.
Intanto ricordo che durante l'estate il sito http://linkeddata.org/ dovrebbe vedere degli aggiornamenti importanti ( attraverso il programma google summer code, se non erro, ma ricordo di averlo visto in lista ).
Proviamo a partire dalle spalle dei giganti e vedere dove ci porta.
In questa lista ci sono persone che usano tecnologie del semweb, dei Linked Data e RDF, ed altri che possono fare da spalla in un confronto costruttivo, provenienti dal mondo degli sviluppatori, e non solo.
Io direi che vale la pena provare con un confronto costruttivo, specie in questi mesi estivi, dove forse qualcuno ha più tempo ( non io eh eh ).
Parto con una considerazione: quando ho seguito per diversi mesi tutte le call del gruppo di lavoro RDF-WG[2], sono partito da un interesse. Quello di vedere dove si potrebbe andare con un po' di semantica in più, e non tutto lo stack Semweb.
Da quel gruppo di lavoro è nata quella costola, incubata, che ha creato JSON-LD.
Dal mio punto di vista, uno dei componenti tecnologici che potrebbero risolvere molte incompresioni a vantaggio di tutti quanti.
Perchè da appassionato e non accademico, io usavo Simile Exhibit da tempo, e vedevo dei chiari vantaggi per lo sviluppatore medio.
Che però, non era semplice comunicare.
Partirei dallo schema dei destinatari di questa tecnologia[3], che alla fine in quei mesi, non è stata direttamente oggetto del gruppo di lavoro. Il perchè esisteva: non si capiva chi fossero i suoi destinatari.
E comunque, nel gruppo di lavoro, non erano presenti abbastanza stakeholders per portarne avanti gli interessi.
Infatti nel 2011 in UK durante gli Open Data Hackathon, praticamente nessuno tra gli sviluppatori presenti conosceva termini come Linked Data o RDF. Segno che le comunità proprio non si parlavano.
E al W3C ne erano consapevoli.
Sono stati fatti sforzi di inclusione e di dialogo nel frattempo, tra cui la nascita del Community Group come nuovo concetto al W3C.
E' tempo di fare uno sforzo anche qui, nel nostro piccolo, ora che comunque tra dati strutturati presenti in HTML5 ( microdata, RDFa ) e Linked Data con n sintassi possibili o n tecnologie possibili, le vie non sono certo chiare.
Sarebbe un peccato, ed è importante che emerga un racconto condiviso, anche per connessioni nuove, come la visibilità SEO, per dire.[4]
<to be continued, this is an open topic>
Matt
[1] - https://groups.google.com/d/msg/spaghettiopendata/dslO3LT1mes/Hv7uCqu9lTYJ
[2] - http://www.w3.org/2011/rdf-wg/wiki/Main_Page
[3] - http://www.w3.org/2011/rdf-wg/wiki/JSON_User_Segments
[4] - http://www.dagoneye.it/blog/2013/01/09/dati-strutturati-in-google-quali-recepisce-schema-org-rdfa-e-microdati/
Alfredo Serafini
Jul 23, 2013, 8:23:26 AM7/23/13
to spaghett...@googlegroups.com
Ciao Matteo
beh se e quando si apre una discussione, specie se come dici centrata su una certa operatività e sulle best-practice e metodologie io per quel che vale ci sono, tempi permettendo :-)
beh se e quando si apre una discussione, specie se come dici centrata su una certa operatività e sulle best-practice e metodologie io per quel che vale ci sono, tempi permettendo :-)
Ad esempio visto che citi json-ld notavo su quella lista in questi giorni il tema resuscitato dei framing, e qualcuno che ragionava sulle possibilità di interrogazione ad esso correlate e mi è tornato in mente, visto che citi simile, longwell e il relativo fresnel: riprendere quei temi aggiornandoli un po' nel contesto citato non mi sembra affatto peregrino, tanto per dirne una... (io stesso per quel che vale avrei nel cassetto anche diversi proggettini congelati da più di un annetto, sul tema, magari ne approfitterei egoisticamente per trovare nuovi stimoli e tempo da dedicare... ;-)
Alfredo Serafini
Jul 27, 2013, 2:35:11 PM7/27/13
to spaghett...@googlegroups.com
intanto contribuisco alla discussione con qualcosa che sembrerà un po' offtopic sulle prime:
due paginette estratte dal service manual di gov.uk, molto bello (anzi mò lo linko in un thread a parte).
Parlando di Linked (Open?) Data spesso si perde per strada l'utente finale, e questo a me sembra alquanto surreale. Tanto per cominciare sul piano tecnico vengono qui suggerite come best-practice l'adozione di servizi (e credo l'idea di fondo sia quella più volte qui condivisa che un file scaricabile in multiformato possa essere prodotto a partire da una composizione di servizi e non viceversa), l'adozione di una URI oggettiva e bookmarkable (meglio se in content-negotiation con tanto di file extension simulata) e così via.
La parte più interessante è però credo quella sulla User Experience, tema che a mio avviso inspiegabilmente sembra essere del tutto assente non solo in ambito Linked Data, ma ben più in generale in ambito Open Data... che ne pensate? A mio avviso ribaltare tanto per cominciare la selezione di informazione tramite una co-progettazione (co-selezione?) di servizi potrebbe tanto per dirne una evitare a tutti noi di disperdere energie in cose completamente inutilizzabili (penso a migliaia di grafici tabellari illeggibili ai più, a visualizzatori privi di contesto che somigliano alle vignette di paperino con una "x" in mezzo ad una mappa del deserto e su scritto "voi siete qui", a treemap che piacciono tanto ad esperti e tanto poco ad utenti comuni, e così via) o del tutto inutili (esporre dati che non si possono collegare, che non servono a nessuno e che magari creano rumore soffocando dati di interesse collettivo).
Parlando di Linked (Open?) Data spesso si perde per strada l'utente finale, e questo a me sembra alquanto surreale. Tanto per cominciare sul piano tecnico vengono qui suggerite come best-practice l'adozione di servizi (e credo l'idea di fondo sia quella più volte qui condivisa che un file scaricabile in multiformato possa essere prodotto a partire da una composizione di servizi e non viceversa), l'adozione di una URI oggettiva e bookmarkable (meglio se in content-negotiation con tanto di file extension simulata) e così via.
La parte più interessante è però credo quella sulla User Experience, tema che a mio avviso inspiegabilmente sembra essere del tutto assente non solo in ambito Linked Data, ma ben più in generale in ambito Open Data... che ne pensate? A mio avviso ribaltare tanto per cominciare la selezione di informazione tramite una co-progettazione (co-selezione?) di servizi potrebbe tanto per dirne una evitare a tutti noi di disperdere energie in cose completamente inutilizzabili (penso a migliaia di grafici tabellari illeggibili ai più, a visualizzatori privi di contesto che somigliano alle vignette di paperino con una "x" in mezzo ad una mappa del deserto e su scritto "voi siete qui", a treemap che piacciono tanto ad esperti e tanto poco ad utenti comuni, e così via) o del tutto inutili (esporre dati che non si possono collegare, che non servono a nessuno e che magari creano rumore soffocando dati di interesse collettivo).
É possibile procedere per prototipazione rapida sui dati Linked aggregati nel web? Ovviamente immagino che ciascuno di noi abbia le proprie esperienze in tal senso, forse accogliendo la richiesta di Matteo potremmo cercare di ritagliarne delle best-practice comuni, per proporre una specie di "ricettario" per l'adozione. Matteo che ne pensi? sto andando troppo off-topic? :-)
Matteo Brunati
Aug 5, 2013, 3:43:46 AM8/5/13
to spaghett...@googlegroups.com
macchè off-topic, ottima segnalazione Alfredo.
Continuo sulla fase di brainstorming sul tema best practices, e connessioni utili.
A valle del workshop del 23-24 aprile al W3C, sono nati due nuovi gruppi di lavoro, e questo capita proprio a fagiolo:
Data on the Web Best Practices Working Group Charter - http://www.w3.org/2013/05/odbp-charter.html
"
Ovvero temi di frontiera, che andrebbero a completare quei "buchi" che aumentano la complessità nell'avvicinarsi al tema. Affini anche alle nostre Linee Guida appena pubblicate da AGID, tra l'altro.
La cosa più interessante è che questo gruppo dovrebbe essere agnostico rispetto alle tecnologie coinvolte.
Che mi fa segnare un altro elemento da ordinare poi in un secondo momento: già inserendo gli URI HTTP come chiavi universali nei nostri dati, in qualunque forma essi siano, aiutiamo notevolmente poi lo step dell'integrazione successiva.
( un elemento che ha bisogno di maggiore attenzione, ovvero il livello delle 4 stelline per dire )
In questo senso nelle prossime settimane condivido del lavoro iniziale per avvicinare il passaggio dalle 3 alle 4 stelline.
Altro tema che si potrebbe usare è quello delle ricette, ovvero delle recipes. Al posto del solito manuale, strutturare i passaggi in base a semplici ricette veloci, che risolvano un singolo problema.
Come queste: http://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook
E per chiudere questo rilancio, io ho sempre usato Simile Exhibit come strumento di protipazione per mostrare il valore di architettura informativa schema-less diciamo, da usare da base per mostrare poi lo step verso il mondo linked potenziale. Perchè? Perchè permette di concentrarsi sulle risorse informative, e sulle loro faccette, in maniera totalmente user oriented. E' un approccio da mantenere, IMHO.
matt
Continuo sulla fase di brainstorming sul tema best practices, e connessioni utili.
A valle del workshop del 23-24 aprile al W3C, sono nati due nuovi gruppi di lavoro, e questo capita proprio a fagiolo:
Data on the Web Best Practices Working Group Charter - http://www.w3.org/2013/05/odbp-charter.html
"
The mission of the Data on the Web Best Practices Working Group, part of the Semantic Web Activity, is:
- to develop the open data ecosystem, facilitating better communication between developers and publishers;
- to provide guidance to publishers that will improve consistency in the way data is managed, thus promoting the re-use of data;
- to foster trust in the data among developers, whatever technology they choose to use, increasing the potential for genuine innovation.
The guidance will take two forms: a set of best practices that apply to multiple technologies, and vocabularies currently missing but that are needed to support the data ecosystem on the Web
"Ovvero temi di frontiera, che andrebbero a completare quei "buchi" che aumentano la complessità nell'avvicinarsi al tema. Affini anche alle nostre Linee Guida appena pubblicate da AGID, tra l'altro.
La cosa più interessante è che questo gruppo dovrebbe essere agnostico rispetto alle tecnologie coinvolte.
Che mi fa segnare un altro elemento da ordinare poi in un secondo momento: già inserendo gli URI HTTP come chiavi universali nei nostri dati, in qualunque forma essi siano, aiutiamo notevolmente poi lo step dell'integrazione successiva.
( un elemento che ha bisogno di maggiore attenzione, ovvero il livello delle 4 stelline per dire )
In questo senso nelle prossime settimane condivido del lavoro iniziale per avvicinare il passaggio dalle 3 alle 4 stelline.
Altro tema che si potrebbe usare è quello delle ricette, ovvero delle recipes. Al posto del solito manuale, strutturare i passaggi in base a semplici ricette veloci, che risolvano un singolo problema.
Come queste: http://www.w3.org/2011/gld/wiki/Linked_Data_Cookbook
E per chiudere questo rilancio, io ho sempre usato Simile Exhibit come strumento di protipazione per mostrare il valore di architettura informativa schema-less diciamo, da usare da base per mostrare poi lo step verso il mondo linked potenziale. Perchè? Perchè permette di concentrarsi sulle risorse informative, e sulle loro faccette, in maniera totalmente user oriented. E' un approccio da mantenere, IMHO.
matt
Andrea Raimondi
Aug 8, 2013, 9:16:15 AM8/8/13
to spaghett...@googlegroups.com
Ma che thread fico!! me ne esco veloce sul tema linked e (più che best) frontier practices: Matteo ma un ... YAML-LD ? ... ;)
Alfredo Serafini
Aug 8, 2013, 10:01:39 AM8/8/13
to spaghett...@googlegroups.com
sai che qualcosa sarebbe fattibile in tal senso? :-)
oppure dare nuova linfa al buon vecchio turtle: in questi giorni ho notato diversi dibattiti su applicazioni varie di turtle :-)
oppure dare nuova linfa al buon vecchio turtle: in questi giorni ho notato diversi dibattiti su applicazioni varie di turtle :-)
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Spaghetti Open Data" di Google Gruppi.
Per annullare l'iscrizione a questo argomento, visita https://groups.google.com/d/topic/spaghettiopendata/dmpFK0jtaG0/unsubscribe.
Per annullare l'iscrizione a questo gruppo e a tutti i suoi argomenti, invia un'email a spaghettiopend...@googlegroups.com.
Visita questo gruppo all'indirizzo http://groups.google.com/group/spaghettiopendata.
Per ulteriori opzioni, visita https://groups.google.com/groups/opt_out.
Matteo Brunati
Aug 9, 2013, 10:28:57 AM8/9/13
to spaghett...@googlegroups.com
Arrivo un po' lungo, ma arrivo.
Inseriamo un altro caso pratico, già citato a partire di questo thread.
INPS e Linked Open Data.
La storia merita un thread apposito, per quanto riguarda la condivisione degli strumenti usati per passare da Open a Linked Data, e le difficoltà/impressioni incontrate. E' una cosa importante per tutti, immagino ( ed io ci vorrei fare un pezzo per l'epsiplatform, of course )
Ma vorrei discutere di un elemento as buona pratica, emerso in questa discussione su twitter di ieri sera[0]
In breve: è molto bello che si stiano inserendo i Linked negli Open Data INPS, ma mi sorgono alcuni dubbi implementativi.
Sapendo che la dimensione Linked solitamente fa paura allo sviluppatore medio, è bello poter avere il formato bulk in JSON via API. Il fatto che sia in JSON-LD è un plus, anche se non ho ancora guardato con attenzione la rappresentazione. La domanda ora è: alcuni dataset ora hanno il "formato OWL", rappresentato dall'icona RDF della tripletta e la scritta OWL vera e propria. Come mai scrivere OWL e non RDF?
Ricordandoci che RDF è solo il modello del dato ( che è un grafo, per dire ), e che ha n formati di rappresentazione e serializzazione ( RDF/XML, Turtle, RDFa 1, e 1.1... , N3, JSON-LD... ), mi ha colpito l'estensione ".owl" del file.
Perchè in realtà quei file sono file in formato RDF/XML, modellati in RDF, con l'ausilio di costrutti OWL.
Come emerge anche da discussioni su answers.semanticweb.com[1], è consigliabile usare sempre l'estensione .rdf per i files in formato RDF/XML. Utile sia per i parsers, che per tutti i programmi che leggono RDF.
Poi ovvio, se si modella con Protegè, si salva se non erro il file in .owl, ma è comunque solo lo schema solitamente che si salva, senza gli individui...
Altro dettaglio interessante, questo sì: ogni dataset ha al suo interno anche lo schema dei metadati ( in OWL ).
Lo si vede molto bene con Inspector di Sindice, come i due grafi siano divisi tra schema dei metadati e dati individuali.
http://inspector.sindice.com/inspect?url=http%3A%2F%2Fwww.inps.it%2Fdocallegati%2F%2FMig%2FOpenData%2FQTUKCDZ3.owl&content=&contentType=auto#GRAPH
Di solito esponendo un endpoint SPARQL si evita questa duplicazione, mi piacerebbe sapere la storia dietro a questo sviluppo. Non mi pare di aver visto spesso questo tipo di approccio.
Forse fatto per step incrementali, è comunque utile come pratica da condividere IMHO.
Ultima questione: una rottura, lo so, ma la content negotiation è prevista in un secondo step? E con che strumento eventualmente? ( come Alfredo sa, ho smadonnato qualche mese fa con la versione in PHP delle Linked Data API, Puelia[2], e non son riuscito a farla andare, ma vorrei venirne a capo, riprovandoci... )
Se ho sparato cavolate, chiedo venia, ho bisogno come tutti di ferie, e questa è stata una settimana di fuoco .)
In qualche modo affine e collegato, consiglio comunque come lettura estiva di questo link[3] ( ci farò un sunto prima o poi )
matt
[0] - https://twitter.com/Fildang/status/365015865663565824
[1] - http://answers.semanticweb.com/questions/2680/common-file-format-for-ontologies
[2] - http://code.google.com/p/puelia-php/
[3] - http://lists.w3.org/Archives/Public/public-lod/2013May/0208.html
Inseriamo un altro caso pratico, già citato a partire di questo thread.
INPS e Linked Open Data.
La storia merita un thread apposito, per quanto riguarda la condivisione degli strumenti usati per passare da Open a Linked Data, e le difficoltà/impressioni incontrate. E' una cosa importante per tutti, immagino ( ed io ci vorrei fare un pezzo per l'epsiplatform, of course )
Ma vorrei discutere di un elemento as buona pratica, emerso in questa discussione su twitter di ieri sera[0]
In breve: è molto bello che si stiano inserendo i Linked negli Open Data INPS, ma mi sorgono alcuni dubbi implementativi.
Sapendo che la dimensione Linked solitamente fa paura allo sviluppatore medio, è bello poter avere il formato bulk in JSON via API. Il fatto che sia in JSON-LD è un plus, anche se non ho ancora guardato con attenzione la rappresentazione. La domanda ora è: alcuni dataset ora hanno il "formato OWL", rappresentato dall'icona RDF della tripletta e la scritta OWL vera e propria. Come mai scrivere OWL e non RDF?
Ricordandoci che RDF è solo il modello del dato ( che è un grafo, per dire ), e che ha n formati di rappresentazione e serializzazione ( RDF/XML, Turtle, RDFa 1, e 1.1... , N3, JSON-LD... ), mi ha colpito l'estensione ".owl" del file.
Perchè in realtà quei file sono file in formato RDF/XML, modellati in RDF, con l'ausilio di costrutti OWL.
Come emerge anche da discussioni su answers.semanticweb.com[1], è consigliabile usare sempre l'estensione .rdf per i files in formato RDF/XML. Utile sia per i parsers, che per tutti i programmi che leggono RDF.
Poi ovvio, se si modella con Protegè, si salva se non erro il file in .owl, ma è comunque solo lo schema solitamente che si salva, senza gli individui...
Altro dettaglio interessante, questo sì: ogni dataset ha al suo interno anche lo schema dei metadati ( in OWL ).
Lo si vede molto bene con Inspector di Sindice, come i due grafi siano divisi tra schema dei metadati e dati individuali.
http://inspector.sindice.com/inspect?url=http%3A%2F%2Fwww.inps.it%2Fdocallegati%2F%2FMig%2FOpenData%2FQTUKCDZ3.owl&content=&contentType=auto#GRAPH
Di solito esponendo un endpoint SPARQL si evita questa duplicazione, mi piacerebbe sapere la storia dietro a questo sviluppo. Non mi pare di aver visto spesso questo tipo di approccio.
Forse fatto per step incrementali, è comunque utile come pratica da condividere IMHO.
Ultima questione: una rottura, lo so, ma la content negotiation è prevista in un secondo step? E con che strumento eventualmente? ( come Alfredo sa, ho smadonnato qualche mese fa con la versione in PHP delle Linked Data API, Puelia[2], e non son riuscito a farla andare, ma vorrei venirne a capo, riprovandoci... )
Se ho sparato cavolate, chiedo venia, ho bisogno come tutti di ferie, e questa è stata una settimana di fuoco .)
In qualche modo affine e collegato, consiglio comunque come lettura estiva di questo link[3] ( ci farò un sunto prima o poi )
matt
[0] - https://twitter.com/Fildang/status/365015865663565824
[1] - http://answers.semanticweb.com/questions/2680/common-file-format-for-ontologies
[2] - http://code.google.com/p/puelia-php/
[3] - http://lists.w3.org/Archives/Public/public-lod/2013May/0208.html
Irene Celino
Aug 9, 2013, 11:53:35 AM8/9/13
to spaghett...@googlegroups.com
cavolo, matteo, ma non puoi lanciare il sasso il mio ultimo giorno di
lavoro prima delle ferie... :-P
rispondo in breve con le mie opinioni (tra l'altro, grazie della
segnalazione, mi erano sfuggiti i dati inps in rdf!)
estensione .rdf o .owl: concordo con te, l'estensione corretta è .rdf
(per il malefico rdf/xml); se non ricordo male esistono anche delle
sintassi specifiche di owl che non sono rdf e che hanno estensione
.owl, ma non è questo il caso. ma poi: perchè rdf/xml invece di turtle
(in genere con estensione .ttl)???
ontologia inclusa/separata: anche qui sono d'accordo con te, ma visto
il modo in cui sono stati rilasciati i dati a "chunk" autocontenuti,
mi sembra giusto che schema e dati stiano insieme; se ci fosse una
pubblicazione linked data "con tutti i crismi" il problema
probabilmente non si porrebbe. non sono invece sicura di aver capito
il tuo commento su sparql endpoint (a meno che tu volessi dire: se si
mette tutto quanto in un triple store con davanti un endpoint, poi
ciascuno si tira fuori tutto e solo quello che serve).
content negotiation: sono di nuovo d'accordo con te, ma ancora dipende
da come si vogliono pubblicare i dati. forse nel momento in cui si
vogliono rilasciare dei file separati (ciascuno con schema+dati) la
conneg non è indispensabile, anche se "tecnicamente" sarebbe
indispensabile per chiamarli linked data. ed è vero che la conneg è in
genere un bagno di sangue: io per riuscire a farla come si deve in un
banale tomcat ci ho messo un bel po' (e, se qualcuno interessa, lo ho
spiegato qui: http://iricelino.org/conneg-in-tomcat).
buon agosto a tutti!
irene
> messaggi, invia un'email a spaghettiopend...@googlegroups.com.
http://about.me/iricelino/
" If you understand what you're doing,
you're not learning anything. "
lavoro prima delle ferie... :-P
rispondo in breve con le mie opinioni (tra l'altro, grazie della
segnalazione, mi erano sfuggiti i dati inps in rdf!)
estensione .rdf o .owl: concordo con te, l'estensione corretta è .rdf
(per il malefico rdf/xml); se non ricordo male esistono anche delle
sintassi specifiche di owl che non sono rdf e che hanno estensione
.owl, ma non è questo il caso. ma poi: perchè rdf/xml invece di turtle
(in genere con estensione .ttl)???
ontologia inclusa/separata: anche qui sono d'accordo con te, ma visto
il modo in cui sono stati rilasciati i dati a "chunk" autocontenuti,
mi sembra giusto che schema e dati stiano insieme; se ci fosse una
pubblicazione linked data "con tutti i crismi" il problema
probabilmente non si porrebbe. non sono invece sicura di aver capito
il tuo commento su sparql endpoint (a meno che tu volessi dire: se si
mette tutto quanto in un triple store con davanti un endpoint, poi
ciascuno si tira fuori tutto e solo quello che serve).
content negotiation: sono di nuovo d'accordo con te, ma ancora dipende
da come si vogliono pubblicare i dati. forse nel momento in cui si
vogliono rilasciare dei file separati (ciascuno con schema+dati) la
conneg non è indispensabile, anche se "tecnicamente" sarebbe
indispensabile per chiamarli linked data. ed è vero che la conneg è in
genere un bagno di sangue: io per riuscire a farla come si deve in un
banale tomcat ci ho messo un bel po' (e, se qualcuno interessa, lo ho
spiegato qui: http://iricelino.org/conneg-in-tomcat).
buon agosto a tutti!
irene
> --
> Hai ricevuto questo messaggio perché sei iscritto al gruppo "Spaghetti Open
> Data" di Google Gruppi.
> Per annullare l'iscrizione a questo gruppo e non ricevere più i suoi
> Hai ricevuto questo messaggio perché sei iscritto al gruppo "Spaghetti Open
> Data" di Google Gruppi.
> messaggi, invia un'email a spaghettiopend...@googlegroups.com.
> Visita questo gruppo all'indirizzo
> http://groups.google.com/group/spaghettiopendata.
> Per ulteriori opzioni, visita https://groups.google.com/groups/opt_out.
>
>
--
> http://groups.google.com/group/spaghettiopendata.
> Per ulteriori opzioni, visita https://groups.google.com/groups/opt_out.
>
>
http://about.me/iricelino/
" If you understand what you're doing,
you're not learning anything. "
Matteo Brunati
Aug 9, 2013, 12:04:31 PM8/9/13
to spaghett...@googlegroups.com
Il giorno venerdì 9 agosto 2013 17:53:35 UTC+2, Irene Celino (iricelino) ha scritto:
cavolo, matteo, ma non puoi lanciare il sasso il mio ultimo giorno di
lavoro prima delle ferie... :-P
già :) mea culpa non ho resistito!
ontologia inclusa/separata: anche qui sono d'accordo con te, ma visto
il modo in cui sono stati rilasciati i dati a "chunk" autocontenuti,
mi sembra giusto che schema e dati stiano insieme; se ci fosse una
pubblicazione linked data "con tutti i crismi" il problema
probabilmente non si porrebbe. non sono invece sicura di aver capito
il tuo commento su sparql endpoint (a meno che tu volessi dire: se si
mette tutto quanto in un triple store con davanti un endpoint, poi
ciascuno si tira fuori tutto e solo quello che serve).
esatto, intendevo proprio quello, sono stato troppo conciso... ( stanchezza ) ora basta, mi fermo per un po' .)
buone ferie ragazzi!
matt
Alfredo Serafini
Aug 9, 2013, 12:15:16 PM8/9/13
to spaghett...@googlegroups.com
ciao Matteo, begli spunti :-)
c'è questo bel post di Dave Reynolds (quelli di epimorphic sono gli stessi dietro Elda e Puelia), che credo sia in tema, anche se vecchiotto (del 2009), ma in fondo di questi argomenti che io ricordi se ne parlava parecchio (in maniera tutto sommato molto simile nella sostanza, anche se con piccole differenze tecnologiche) in varie ondate nel periodo 2005/2007, ho una terribile sensazione di deja-vu! :-)
Per quanto concerne i dati consumabili via api:
i dati generici sembrano essere per un json "di servizio":
A quanto sembra la loro idea è proporre delle api sui metadati (json) a partire dalle quali si possa andare a reperire i vari formati di rappresentazione. Per chi volesse invece reperire i dati veri e propri in una "volta sola", li propongono in bulkcon un json-ld, cioè in pratica RDF "trascritto" in json per Linked Data:
rappresenta la "Serie storica mensile dei beneficiari di disoccupazione non agricola - Anni 2007-2009; 1° semestre 2010"
Se guardate dentro ci sono i link ai vari formati (a parte owl, ma credo sia perché aggiunto di recente)
...e forse potrebbe essere utile predisporre per dati di serie storica delle URI con un formato del tipo: http://serviziweb2.inps.it/odapi/catalog/2007/2009/disoccupazione/72
o persino in una forma generale:
il che potrebbe aiutare loro per costruire programmaticamente la cosa, e noialtri per consumare i dati orientandoci solo su quello che serve (i dati statici non servono praticamente più, o vanno richiamati solo quando abbiamo scelto ciò che ci interessa). Giusto una idea.
Un discorso a parte merita quello sullo sparql endpoint: pubblicandolo si potrebbe navigare le risorse con un linguaggio/protocollo progettato proprio per navigare grafi di informazione, quindi se è vero che non va proposto all'utente finale, che non ci fa niente, non capisco perché non renderlo accessibile per gli "utenti-sviluppatori"
Sul fronte esempi di dato statici, stanno qui (lo trascrivo per chi non abbia ancora avuto modo di guradare, sperando di farvi risparmaire tempo):
La cosa che apprezzo è l'utilizzo Limo e delle rappresentazioni orientate ai dati numerici, anche se sottoscrivo qualche perplessità sull'uso di owl, che ti scrivo sotto.
Sapendo che la dimensione Linked solitamente fa paura allo sviluppatore medio, è bello poter avere il formato bulk in JSON via API. Il fatto che sia in JSON-LD è un plus, anche se non ho ancora guardato con attenzione la rappresentazione. La domanda ora è: alcuni dataset ora hanno il "formato OWL", rappresentato dall'icona RDF della tripletta e la scritta OWL vera e propria. Come mai scrivere OWL e non RDF?
Premettendo che il sito credo sia molto ancora work-in-progress, ho dato una occhiata alle tipologie dei dati, e mi sembra del tutto assente il json dai dati statici. Guardando qui e lì un po' a campione, la sensazione generale è che vogliano centrare l'esperienza utente/sviluppatore sulle api e non sui dati statici. Il che, se così fosse, non mi sembra male come approccio: per la maggior parte degli sviluppatori non edotti su grafi o peggio "semantica" (qualsiasi cosa possa voler dire essere esperti di semantica in generale :-) direi che rende possibile consumare i dati tramite i servizi e poi di lì fare mashup, e quindi un quasi-linked data, senza spaventarsi del contesto e dei nomi in gioco. Tra l'altro: ma perché la gente si spaventa se parli di RDF e invece trova naturale collegare progrmmaticamente in una piccola applicazione HTML due json che rappresentano magari dati da fonti date eterogenee e su domini differenti? Prima o poi sarebbe da mettere in una stessa presentazione dei mashup considerabili "normali", e poi iniziare via via ad "irrobustirli" semanticamente, con o senza RDF, tanto per capire se sia un problema di termini, di contesto, o di insofferenza verso un uso consapevole dei modelli dei dati. Se fosse quest'ultima cosa andiamocene tutti a casa, perché ritengo che gli open data tutti e quelli Linked in particolare ci costringeranno via via ad un uso sempre più consapevole dei dati anche e soprattutto in rispetto del loro dominio di appartenenza: che io rappresenti o meno "sintatticamente" qualcosa in RDF o persino in owl, una semantica che sostiene i dati c'è dietro le quinte, e credo dovremmo metterci un po' a riflettere anche su come renderla esplicita all'utente finale, senza costringerlo a diventare né esperto di dominio, né tantomeno di "semantica". Penso non solo all'NLP, ma a cose più terra-terra, come pubblicare insieme ad un file CSV un file gemello per descrivere le colonne utilizzate. Perchè non viene fatto? eppure costa praticamente niente (spesso i metadati ci sono, e si trovano nel formato xml corrispettivo) e sono facilmente consumabili dai vari tool di business intelligence, così come da un qualunque poveraccio che voglia fare la sua ricerca a mano sui dati una-tantum :-)
Ma sto divagando pardon
La divagazione era per dire che credo abbiano prima di tutto e soprattutto un problema di UX: i dati ci sono, spesso anche in formati abbastanza consumabili, ma l'architettura generale del sito non mi informa della cosa, e si rischia di fare un po' di confusione. Ovviamente sto dando ad una analisi di elementi oggettivi un taglio un po' personale, spero che non me ne vogliate ma l'idea è di proporre qualche bonaria critica costruttiva per possibili miglioramenti :-)
Ricordandoci che RDF è solo il modello del dato ( che è un grafo, per dire ), e che ha n formati di rappresentazione e serializzazione ( RDF/XML, Turtle, RDFa 1, e 1.1... , N3, JSON-LD... ), mi ha colpito l'estensione ".owl" del file.
Perchè in realtà quei file sono file in formato RDF/XML, modellati in RDF, con l'ausilio di costrutti OWL.Come emerge anche da discussioni su answers.semanticweb.com[1], è consigliabile usare sempre l'estensione .rdf per i files in formato RDF/XML. Utile sia per i parsers, che per tutti i programmi che leggono RDF.
Poi ovvio, se si modella con Protegè, si salva se non erro il file in .owl, ma è comunque solo lo schema solitamente che si salva, senza gli individui...
Difatti tutto ciò che è linked riguarda esplicitamente o meno grafi, quindi anche parlare di open data dovrebbe portarci naturalmente a parlare di Linked Open Data (a meno che uno non si limiti a scaricare un foglio excel per fare la somma di una colonna :-). Questo mi sembra un punto che forse diamo per scontato ma tastando un po' il polso in giro mi pare non lo sia affatto.
Altro paio di maniche è l'udo o meno di RDF, che non è un formato ma appunto un descrittore del modello dei dati, come dici te. E a quel punto lo puoi serializzare come ti pare, da XML a json-ld, a turtle. OWL è teoricamente più interessante per descrivere in modo esplicito la semantica e i vari vincoli etc, però è generalmente molto ma molto meno riutilizzabile, tanto più che qui ho anche io la sensazione generale che l'espressività OWL non venga praticamente utilizzata. Forse l'idea era partire di qui per aprire a future integrazioni... in ogni caso sottoscrivo la preferenza per la serializzazione RDF (XML ma anche e soprattutto json-ld, così che quelli spaventati dalla semantica la usino senza rendersene conto eheh, fatemi scherzare un po' :-P)
Altro dettaglio interessante, questo sì: ogni dataset ha al suo interno anche lo schema dei metadati ( in OWL ).
Lo si vede molto bene con Inspector di Sindice, come i due grafi siano divisi tra schema dei metadati e dati individuali.
http://inspector.sindice.com/inspect?url=http%3A%2F%2Fwww.inps.it%2Fdocallegati%2F%2FMig%2FOpenData%2FQTUKCDZ3.owl&content=&contentType=auto#GRAPH
si difatti anche -e sopratttuto- qui fossi in loro pubblicherei separandoli i dati veri e propri dalle definizioni di modello
Di solito esponendo un endpoint SPARQL si evita questa duplicazione, mi piacerebbe sapere la storia dietro a questo sviluppo. Non mi pare di aver visto spesso questo tipo di approccio.
Forse fatto per step incrementali, è comunque utile come pratica da condividere IMHO.
L'endpoint non solo evita questa duplicazione, ma rende naturalmente linked qualsiasi dato. Peraltro puoi proiettare i dati partendo da query, quindi è già di fatto una api in content-negotiation (almeno se usi un buon triplestore, o comunque non è complesso mettercela defininedola ad-hoc). In più si può fare inferenze sia via SPARQL, che scrivendo moduli ad hoc talvolta nel triplestore: questo però è più che altro una scelta di chi mantiene i dati, e di quanto voglia iniettare in essi analisi fatte a monte, meglio non divagare.
Pure io ho la sensazione che lo aggiungeranno poi, a naso :-)
Ultima questione: una rottura, lo so, ma la content negotiation è prevista in un secondo step? E con che strumento eventualmente? ( come Alfredo sa, ho smadonnato qualche mese fa con la versione in PHP delle Linked Data API, Puelia[2], e non son riuscito a farla andare, ma vorrei venirne a capo, riprovandoci... )
come detto sopra: sull'endpoint è quasi sempre gratis, altrimenti suggerisco per java cose come jersey, conformi agli standard java.
per Puelia / LInked Data Browser vari: Puelia personalmente l'ho mollato perché -almeno quando lo ho provato- non era proprio il massimo quanto a facile configurabilità: richiedeva un ambiente fatto un minimo su misura, e per di più è scritto in PHP. Il PHP è un linguaggio che ho amato molto in passato, ma secondo me -lo so, mi sto esponendo al rischio di un flame pazzesco sui linguaggi :-D - non è che sia proprio il massimo per elaborazioni del tipo di cui c'è bisogno in ambito linked data. Preferisco qualcosa che giri su piattaforma java per mille motivi (scalabilità, gestione concorrente delle query, possibilità di scrittura language agnostic entro i limiti dei linguaggi supportati da JVM, da scala che adoro e che ho quasi sostituito ormai a java, a groovy, jruby e persino javascript). Insomma per tutti questi motivi suggerisco vivamente Elda, come già detto. Ha le sue pecche, dovute al fatto che è ancora in parte work-in-progress (specie su full-text e template), ma insomma è un progetto più maturo e ci si può ragionare. Per i template hanno recentemente aggiunto velocity, che personalmente (vado a caccia del flame oggi :-) ritengo un pezzo di antiquariato, ma insomma funzionicchia decentemente (lo usano pure per alcuni esempi standard Solr, anche se un po' datati), ma non è complicatissimo scrivere ex-novo nuovi render engine: avevo iniziato un paio di anni fa, ma poi ho dovuto mollare il progetto su cui stavo sviluppandolo e non c'è più stato modo di riprenderlo in mano in altri contesti, non dubito che nel mentre abbiano semplificato notevolmente la cosa, anche se mi pare che sulla ML non se ne parli a un bel po', ma potrei sbagliare. Per la content-negotiation Elda usa jersey, quindi è molto ben gestita, e migliorabilissima.
Altrimenti per navigazioni html più tradizionali si può utilizzare pubby, che richiede meno manutenzioni, anche se mi sembra meno estendibile.
Attendo fiducioso i prossimi sviluppi, non sarebbe male se qualcuno che ci sta lavorando ci desse qualche commento :-)
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Spaghetti Open Data" di Google Gruppi.
Per annullare l'iscrizione a questo argomento, visita https://groups.google.com/d/topic/spaghettiopendata/dmpFK0jtaG0/unsubscribe.
Per annullare l'iscrizione a questo gruppo e a tutti i suoi argomenti, invia un'email a spaghettiopend...@googlegroups.com.
Alfredo Serafini
Aug 9, 2013, 12:25:47 PM8/9/13
to spaghett...@googlegroups.com
sottoscrivo praticamente tutto Irene! :-)
mi lascia perplesso però il fatto che vogliano rilasciare -se lo vogliono- soltanto chunk, perché a naso direi che INPS dovrebbe avere un bel po' di dati, quindi prima o poi dovranno per forza di cose esporli un po' alla volta, e quindi forse è un po' indispensabile gestire a parte la rappresentazione del modello
Per annullare l'iscrizione a questo argomento, visita https://groups.google.com/d/topic/spaghettiopendata/dmpFK0jtaG0/unsubscribe.
Per annullare l'iscrizione a questo gruppo e a tutti i suoi argomenti, invia un'email a spaghettiopend...@googlegroups.com.
Irene Celino
Aug 9, 2013, 12:29:41 PM8/9/13
to spaghett...@googlegroups.com
ah, sono d'accordo anch'io! e sono anche per avere namespace separati
per schema e istanze.
mi immagino però che esporre un "chunk" alla volta faccia meno paura
che chi inizia...
per schema e istanze.
mi immagino però che esporre un "chunk" alla volta faccia meno paura
che chi inizia...
Alfredo Serafini
Aug 9, 2013, 12:31:09 PM8/9/13
to spaghett...@googlegroups.com
verissimo!
per la separazione dei namespace +1000 :-)
Andrea Raimondi
Aug 10, 2013, 12:02:13 PM8/10/13
to spaghett...@googlegroups.com
Caspita...non potrei essere più felice per tutti questi post, per altro super sul punto e molto dettagliati. Per due giorni sono a fare quella cosa che fa Luca Corsato, "ferie" mi pare. Poi vi rispondo con molto piacere su tutto.
Faccio intervenire, per altro, Claudia Corcione, la mia collega che ha coordinato il progetto :)
A presto
Andrea
Faccio intervenire, per altro, Claudia Corcione, la mia collega che ha coordinato il progetto :)
A presto
Andrea
Alfredo Serafini
Aug 12, 2013, 2:39:45 PM8/12/13
to spaghett...@googlegroups.com
grazie!
PS: buone ferie! ;-)
PS: buone ferie! ;-)
Andrea Raimondi
Aug 19, 2013, 11:16:00 AM8/19/13
to spaghett...@googlegroups.com
Buongiorno a tutti,
Avrei voluto scrivervi prima, ma come qualcuno già sa sto impacchettando le cose per trasferirmi in UK dove, tra Oslo e Nottingham, lavorerò ad un progetto di ricerca e al mio PhD. Niente che riguardi l'IT, ma Filosofia della Scienza. Nulla di cui preoccuparsi, tramite Pionero, italianvalley.wired.it/ (a breve) e SOD continuerò a fare il guastafeste.
Un piccolo backdrop: ho lavorato due anni alla Evodevo.it, mi sono occupato principalmente di ontology/data modeling. Ho lavorato per lo stesso periodo con Filippo D'Angelo, ora responsabile opendata INPS, occupandomi della fase di startup dell'istituto su tutti i fronti (analisi dati, modelli, strumenti di accesso, comunicazione, webinar, strategie di apertura, definizioni legali e procedure di trasparenza). È stato un lavoro molto molto lungo, ma soddisfacente. Lungo perché far cambiare direzione ad un'istituto del genere è come voler raddrizzare la torre di Pisa con le mani; lungo perché, per quanto non esiste una vera e propria strategia di governance solida che faccia lavorare gli enti in concerto, l'ecosistema amministrazione è comunque uno scontro di esigenze e obbiettivi differenti. Soddisfacente perché, lo dico con contentezza, non mi aspettavo di poter far tirare su tutte queste cose in "poco tempo". Sono stato, anche a detta di molti, fortunato anche ad aver trovato nell'INPS una persona disposta ad imparare molto e a fare altrettanto.
Veniamo a noi. Premetto che la definizione del modello OWL generale è stata portata avanti per lo più da una mia collega, Claudia Corcione, mentre io lavoravo altri dati delle Aliquote e API (insieme a @Riccardo_Vacca e Riccardo Troccoli), quindi nel caso non dovessi essere esaustivo vi metterò in contatto anche con lei.
Due cose per inquadrare le domande. La fase iniziale di avviamento all'opendata nelle PA italiane è stata caratterizzata da: scarsità di risorse da investire (giornate uomo/function point consuntivabili) difficoltà di comunicazione (mancanza di capacitá di indirizzare problemi sociali e mancanza di strumenti OpenGov admin/citizen) non conoscenza della risorse informative (mancanza di comunicazione inter/intra PA, predominanza del concetto di "raccolta" dati rispetto a quello di "cura"). L'INPS non fa eccezione, anzi, come PA gigantica a volte ha alcuni di questi punti molto estremizzati. Aprire i dati dell'INPS quindi ha significato per lo più dotarsi di:
1. Una buona strategia di apertura [risparmiare soldi, utilizzare ciò che già è in essere, ottimizzare le scelte attuative in modo che massimizzino i principi Open sui quali le scelte si basano ma soprattutto consentano di massimizzare la qualità delle scelte future in agenda; una buona agenda governativa non può e non deve prevedere passi di gambero]
2. Buone pratiche di utilizzo del patrimonio pubblico [essere developers/citizen demand-driven è mandatorio. Liberare dati in un periodo in cui quei dati possono servire a figure professionali diverse può essere un buon modo di "ingaggiare" i cittadini (vedi caso Aliquote INPS o contributi per i lavoratori domestici). Liberare dati in modo che la metodologia di utilizzo e i modelli di riferimento siano di sufficiente qualità (rappresentano davvero tutte le info e siano processabili senza difficoltà) ma al contempo che entrambe le cose non creino un monopolio di concettualizzazione, cioè in sostanza che non si arrivi a prediligere un certo formato o un certo standard solo perché implicitamente si è sempre usato quello (la fossilizzazione della forma, per altro, ha comportato nel tempo che i dipendenti delle PA usano Excel come fosse Photoshop, per cui si arriva per amore della precisione ed eleganza a creare xls talmente barocchi da essere praticamente pattume. E no, openrefine non ce la fa)]
3. Buona comunicazione [fare storytelling del processo di apertura dei dati è fondamentale. Consente all'utente di capire, incasellando tutte le novità in un percorso che ha obbiettivi e milestones precise. Consente alle altre amministrazioni di avere un panorama chiaro di cosa stanno facendo le altre, e migliora lo scambio delle best practice già attuate, nonché il netoworking tra gli opendatari nelle PA]
Questo approccio, secondo me, evita alcuni rischi:
1. Pensare prima di fare consente di non cadere troppo facilmente nelle trappole di alcuni vendor illusionisti. Permette anche di prendere scelte lungimiranti, di modo da evitare di intraprendere un percorso che poi possa presentare un momento di stacco rispetto al panorama generale, che comporterebbe il necessario riadattamento di metodo e strategia con conseguenti costi molto alti (sia politici che economici)
2. Se non ti lasci guidare e non sai ascoltare la domanda non potrai mai sperare che i dati arrivino ad avere un impatto sociale reale sui cittadini. Ad esempio se mi rilasci le tabelle di calcolo per i contributi domestici dopo la scadenza del termine di pagamento hai perso un'occasione per spingere un nuovo modo di gestire le informazioni del settore pubblico. Se non trovi il giusto bilanciamento nel modo in cui i dati devono essere prodotti, rischi di alimentare un'entropia di dati inutilizzabili. Rendere questi interoperabili ha un costo altissimo in giorni uomo, perché è quasi un lavoro di artigianato.
3. Non comunicare bene non significa non comunicare affatto, significa fare danni per lo più. E se i danni avvengono in fase di accordo tra amministrazioni i risultati possono avere un impatto critico sul processo di apertura di tutti gli enti.
Veniamo ai punti:
L'ontologia e i dati Linked
L'ontologia DominioINPS è la prima versione rilasciata di un progetto ancora in essere che subirà diverse fasi di sviluppo nel futuro. La scelta di rilasciare a partire dall'OWL si inscrive nella strategia di implementare il progetto verso due direzioni:
1. Progetti di ricerca sperimentali sui Linked (ma su questo non posso dire di più). L'owl, al contrario dell'RDF, è decisamente più espressivo e permette di modellare anche oggetti complessi come servizi e processi che presentano cardinalitá di organizzazione e temporalità molto difficili da gestire con il solo RDF. Ovviamente il problema non si pone per i dati, ma poiché l'ontologia ha sviluppi ulteriori che prescindono dall'opendata (in senso immediato), rilasciare il download in owl consente di operare su un modello sulla base del quale poter implementare Open Service basati su una semantica solida, in grado di supportare una logica il più possibile complessa. Inoltre, anche in riferimento ai dati, senza proprietà come owl:sameas avremmo grandi difficolta a creare dati linked tra diverse fonti. D'altra parte l'owl non rappresenta un vero ostacolo, perché con due minuti puoi tirarti fuori la serializzazione che preferisci. E la serializzazione RDF/XML da sola non garantisce la consistenza semantica associata ai dati. ad esempio che io dica "andrea mangia una mela" o "una mela mangia una mela" questo comunque rappresenta un rdf valido, ma lil layer semantico predilige sicuramente la prima tripla piuttosto che la seconda. Non rappresenta quindi un vero e proprio impedimento. Irene giustamente sottolineava come il turtle sia effettivamente più espressivo dell'Owl sul versante First Order Logic, nonché più facile da scrivere. Tuttavia implementare una FOL significa anche andare incontro a dei tempi più lunghi di risposta e i dati devono essere curati in modo tale da rendere le FOL inference un vantaggio rispetto alla più "semplice" DLogic. Per questa ragione la prima versione del DominioINPS è stata rilasciata in questo modo. Perché offre una base di modellazione di partenza di buona qualità, sia per quanto riguarda il modello che i dati veri e propri, le cui evoluzioni possono essere schedulate a seconda dei percorsi che si vogliono intraprendere.
Un piccolo inciso per dire che molto spesso si fa confusione tra vocabolari RDF e vere e proprie Ontologie. Se le prime esprimono alcune difficoltà legate alla classificazione tassonomica, le seconde presentano problemi molto più ontologici, cioè legate alle scelte di modellazione delle entità (avvertenza! C'è molto dibattito in merito alla distinzione quindi non mi lapidate :) ). Molto spesso infatti le Ontologie di dominio (come nel caso di INPS) e le task ontologies sono valutate a partire dall'UML di un ontologia fondazionale. Questo livello di precisione nella modellazione si trova per ora solamente in qualche centro di ricerca ma, per chi fosse interessato, vi segnalo quella che è stata la mia Bibbia (http://doc.utwente.nl/50826/1/thesis_Guizzardi.pdf). Giancarlo è un ricercatore molto molto in gamba e ho avuto la fortuna di averlo come prof alla scuola di dottorato dell'FBK sulle Ontologie applicate. Faccio anche notare Alfredo che la riusabilità degli OWL è alta, ma richiede un livello di competenza altrettanto specialistico. Quindi, secondo me, è l'ontology web Language non va usato per "dire" tutto, semplicemente perché una lingua più forbita non significa necessariamente una lingua più significante ma anche solo semplicemente una competenza più alta dei parlanti di quella lingua nell'utilizzo dei significati.
2. La seconda direzione si inscrive invece proprio nel panorama OpenGovData e LOGD. Ci tengo alla distinzione, perché se non si concentrano gli sforzi per separare e standardizzare i dati governativi regnerà sempre il caos a livello di standard. Esempio pratico: come strategia di rilascio ho preferito evitare dataset che fossero classificati con ATECO, semplicemente perché tra "poco" AGID in collaborazione con ISTAT dovrebbe rilasciare il vocabolario ATECO RDF. Dal momento che questo vocabolario e alla base di moltissimi dati, se non ne curassimo un vocabolario semantico perderemmo l'occasione di rafforzare l'interoperabilitá del PSI italiano. Provo a rispondere per punti a tutto, ma siete stati così in gamba che se dimentico qualcosa perdonatemela:
2.1 Gli Owl dei dataset - ogni owl dei dataset ha un ns associato, quindi la separazione tra ns di abstract schema e istanze è già presente. Per comodità potete vedere nel l'ontologia sia i ns di riferimento esterno (tipo DCAT) sia quelli dei dataset (leggermente separati, sono identificati dagli ID che i dataset prensentano all'interno del DB INPS. La sottigliezza sta nel presentare dei dati definiti da un ID unico per qualsiasi tipo di acceso uno effettui: LOD, API o semplice download. Se infatti provate a scaricare una tabella vedrete nella URI di download lo stesso ID che definisce la tabella nell'OWL). Per quanto riguarda i metadati. Poiché allo stato attuale delle cose non è presente content negotiation, i metadati associati all'interno non generano duplicazione. Non tenere conto avrebbe significato il rilascio di dati non consistenti. Ovviamente, come sostenete giustamente, nel momento in cui verrà esposto uno SPARQL, i dati verrano alleggeriti e riconsolidati. Il "chunck autocontenuto" come dice Irene, segue la logica delle "future integrazioni", come dice Alfredo (ma questa logica funziona solo se dietro hai una "buona strategia", cioè se poi l'endpoint me lo apri). Per il momento gli owl dataset devono rispettare i requisiti di primo rilascio e quindi devono avere i metadati al loro interno. Sottilineo anche che se così non fosse, la scelta del modello JSONLD per le API perderebbe di efficacia, almeno in parte. Accenno in breve: la v2 delle API mapperà il modello API LD con il modello DominioINPS, soprattutto per quanto riguarda alcuni vocabolari strutturali, come SDMX, DATACUBE e DCAT (quest'ultimo già impiegato nel bulk). In questo modo si potrá offrire un JSONLD vero e proprio, perche l'impiego che ne è stato fatto nelle API è di tipo "light", come lo chiamo io. ma su questo torno dopo. Sarà quindi possibile sia accedere all'owl come distribution resource, sia avere i dati tramite Bulk sfruttando la capacità del JSONLD di modellare dati linked. Se non ci fossero i metadati del dataset le risorse rappresentate nel bulk non sarebbero definite. Questa soluzione, per altro, secondo me, è più leggera rispetto alla decisione di fare retrieval dei metadati dal l'ontologia generale. È una via percorribile, più elegante, ma può presentare un costo computazionali più alto. Per non parlare di tutte le difficoltà associate ai servizi (soprattutto a livello di WMO) che un ente grande come INPS eroga.
2.2 accessibilità LOD - si, sarà aperto un endpoint e si, DominioINPS avrà al più presto una comoda PURL, così da poter navigare bene i dati anche con roba tipo LODLIVE (che mi fa sempre divertire). La serializzazione RDF ha qui senso, proprio perché in quel momento saranno veri LD on the web. Ma, secondo me, questo è uno step di accessibilità dati, più che di modello, per le ragioni che vi dicevo sopra. Per quanto, come qualcuno ha abilmente colto, ho sempre preferito tagliare lo startup Opendata INPS in senso di sviluppo (caro il mio Alfredo :) ) alcuni strumenti di interrogazione richiedono altrettanto competenza come l'uso dell'Owl. Recentemente stavo studiando qualche soluzione per rendere le query più user friendly. Treasury.io ha adottato una buona soluzione, basata su faceting delle query, che rende ai giornalisti la vita moolto più semplice. Lo sviluppo di un endpoint, quindi, secondo me ha poco senso se non si rende l'interrogazione multimodale.
2.3 copertura legale - Sulla LiMo ho speso un quasi due settimane di notti, per la gloria ovviamente. Mi venne l'idea verso gennaio, perché a forza di studiare leggi, norme e provvedimenti poi cominci a farci l'occhio (miccia scatenante Ernesto Belisario, un amico e un professionista nel suo campo, che mi ha acceso il gene del legal nerd). Stavo cercando un modo per rendere interoperabile le inferenze sulle condizioni legali dei contenuti. Ti ricordi Matteo? su quelle Cc ci stava già lavorando Aaron. Alla fine ho proposto l'idea a Chiara Veninata (ACS) Silvia Mazzini (Regesta) senza il cui aiuto non avremmo messo su nulla (Diego Camarda ci ha dato una grossa mano). Abbiamo fatto tutto sommato un buon lavoro di team, e adesso la LiMo è in valutazione su lov.okfn.org. Sul territorio europeo ne sono presenti tre: la nostra italiana, una francese di un gruppo di ricerca, e una inglese di Leigh Lodds che ora lavora come Consultant all'ODI. La nostra è la più fica ovviamente (scherzo, ma non troppo). Abbiamo quindi deciso di utilizzare la LiMo per coprire le condizioni legali almeno degli OpenGovData, perché cosa si può o non si può fare dev'essere trasparente sempre. Faccio notare che l'individuo limo:license che definisce i temini di DominioINPS sarà online a breve quando anche l'ontologia sarà su LOV. Quindi vi ringrazio per aver apprezzato la cosa, mi fa immensamente piacere. Sottolineo anche un altro aspetto della licenza: i dati sono coperti da IODL2.0 come sapete, l'owl ha la distribuzione CCBYSA. Questo significa che tutto i lavori derivati, versioni più evolute o altro che esce da li deve tornare al Public Sector Domain. Questo garantisce l'auto sostenibilità dell'ontologia come bene comune. Inoltre molti altri enti utilizzano concetti definiti nel modello INPS, e questo inverno, se gli va, potrebbero utilizzare le classi definite ( es. <inps:contributifigurativi> ), migliorando l'interoperabilitá di tutto i dati del settore pubblico. Ovviamente, come forse avete visto, la versione bilingue consente di identificare i contatti necessari per inoltrare ulteriori evoluzioni. Che l'invito sia esteso anche a chi lavora su/con altri enti omologhi a livello europeo mantiene la direzione di valutare le direttive ePSI come un livello di scelte strategiche più che importante. INPS ha infatti cominciato ad aprire seguendo le direttive europee sul riuso nel PSI.
2.4 le API - se parliamo di API vi invito a sentire @Riccardo_Vacca, quello veramente bravo tra i due :) , il progetto nasce dal l'esigenza di harvesting di dati.gov.it per l'aggiornamento dei dati INPS, prima condotto con lunghissime e noiosissime estrazioni (costoso e lento). Quindi come fa vedere giustamente Afredo il paradigma di partenza è REST. Ma detto tra noi non ci soddisfaceva. Primo perché la prima versione avrebbe solo permesso di fare retrieval del datacatalog e dei metadati, secondo perché nel frattempo stavamo sviluppando i linked, e il JSONLD ci è sembrata la scelta strategica e tecnica più adeguata. Nello stesso momento avevano invitato Evodevo al G8 per il tax, trades and Trasparency table per gli opendata. Nelle discussioni dei mesi precedenti si era già parlato della necessità di rilasciare i dati in bulk. Quindi abbiamo pensato di utilizzare una versione "light" di JSONLD, cioè utilizzarlo non per veri e propri linked (la cui mappatura sarebbe avvenuta successivamente), ma per i dati i cui metadati erano embeddati nel dataset. Un piccolo aggiornamento: le API sono "intelligenti", cioè quando anche solo un array di dati è corrotto da un errore di riga, o di contenuto di riga, questo viene isolato con un tag e identificato come "fixing in progress". Due sono le ragioni: trasparenza (se ci sono errori lo devo sapere e dire subito) interpretazione (questo meccanismo previene i casi di interpretazioni errata non voluta dei dati a partire da banali e non voluti errori di trascrizione di riga). Per le altre funzioni vi rimando al reference document. Altro aggiornamento: si, gli owl verranno aggiunti. Le API hanno anche un obbiettivo strategico e politico ben definito (e qui lo confesso un po'):
2.4.1 accessibilità e dati per lo sviluppo: non si può lavorare bene se si è obbligati a scaricare i dati uno per uno. Le api sono fondamentali per aumentare la sostenibilità del lavoro, come la qualità. Senza dati le API perdono di efficacia come mossa orientata a favorire lo sviluppo economico di business basato su opendata. La possibilità per una startup come enigma.io o spaziodati.eu di potersi caricare l'intero OpenDataCatalog INPS e lavoraci aumenta il tempo per la creatività e diminuisce quello di data cleaning, permettendo anche di concentrarsi e studiare il significato dei dati oltre che la loro organizzazione.
2.4.2 competizione e dati per lo sviluppo: non ci può essere vera competizione se non si ha un uguale accesso alle risorse opendata. Il bulk JSONLD permette a tutti di poter testare le proprie capacità, permette alle aziende e alle università di fare ricerca alla pari. Dal momento che un datamarket non si crea da solo, se non permettiamo a chi sa lavorare di far vedere cosa sa fare non avremmo molte possibilità di creare un ecosistema dei dati basato sulla collaborazione di diversi tipi di stakeholders, piuttosto un monopolio di pochi.
2.4.3 quali dati per lo sviluppo: i dati INPS sono considerati high-value dalla G8Opendata Chart (chissà come mai ;) ) e sono altrettanto interessanti da modellare, nonché molto complessi, poiché richiedono uno studio approfondito del dominio. Alfredo fa giustamente notare come INPS abbia molti dati. Verissimo. È ne ha ancora di più di quel che pensate. L'unico modo per averli ora è chiederli. Quindi accesso civico come se non ci fosse domani.
Piccola nota sul finire: purtroppo è complesso far cambiare rotta alle PA per quanto riguarda l'architettura dell'informazione, causa azienda inhouse poco attente agli aggiornamenti normativi e, per gran parte, pigre..più i soliti movimenti politici nelle PA. Il sito non è valorizzato per nulla. Basterebbe molto poco. È qui che entra in gioco il fattore buona comunicazione, quella che serve per intraprendere la fase di startup più OpenGov di un ente. Ma questo, sono convinto, è uno scoglio che richiede un impegno politico che non può essere isolato e sicuramente arriverà gente decisamente più preparata di me questo versante.
Se ho dimenticato qualcosa redarguitemi e vi riscrivo. Riguardo alle novità INPS opendata per inverno 2013 e anno 2014, non lavorando più al progetto, non posso darvi tempi certi. In ogni caso grazie del bel thread, scusate se sono uscito forse un po' dal topic stretto dei LOD, ma un po' di contesto serve per capire i problemi, i punti di forza e le modalità attuative di un progetto che, oltre a dare vita a un discorso di best practice stretta te legato ai LOD, persegue anche i principi dell'opendata per i quali ci stiamo battendo ormai da anni. Rimango comunque sempre a disposizione per qualsiasi altra cosa. A presto.
Andrea
Ps: Matteo quando trovo il tempo provo a mettermi a lavorare su PACO (Public Administration Curricula Ontology), tanto non c'è pericolo che le cose in Italia vadano troppo veloce.
Avrei voluto scrivervi prima, ma come qualcuno già sa sto impacchettando le cose per trasferirmi in UK dove, tra Oslo e Nottingham, lavorerò ad un progetto di ricerca e al mio PhD. Niente che riguardi l'IT, ma Filosofia della Scienza. Nulla di cui preoccuparsi, tramite Pionero, italianvalley.wired.it/ (a breve) e SOD continuerò a fare il guastafeste.
Un piccolo backdrop: ho lavorato due anni alla Evodevo.it, mi sono occupato principalmente di ontology/data modeling. Ho lavorato per lo stesso periodo con Filippo D'Angelo, ora responsabile opendata INPS, occupandomi della fase di startup dell'istituto su tutti i fronti (analisi dati, modelli, strumenti di accesso, comunicazione, webinar, strategie di apertura, definizioni legali e procedure di trasparenza). È stato un lavoro molto molto lungo, ma soddisfacente. Lungo perché far cambiare direzione ad un'istituto del genere è come voler raddrizzare la torre di Pisa con le mani; lungo perché, per quanto non esiste una vera e propria strategia di governance solida che faccia lavorare gli enti in concerto, l'ecosistema amministrazione è comunque uno scontro di esigenze e obbiettivi differenti. Soddisfacente perché, lo dico con contentezza, non mi aspettavo di poter far tirare su tutte queste cose in "poco tempo". Sono stato, anche a detta di molti, fortunato anche ad aver trovato nell'INPS una persona disposta ad imparare molto e a fare altrettanto.
Veniamo a noi. Premetto che la definizione del modello OWL generale è stata portata avanti per lo più da una mia collega, Claudia Corcione, mentre io lavoravo altri dati delle Aliquote e API (insieme a @Riccardo_Vacca e Riccardo Troccoli), quindi nel caso non dovessi essere esaustivo vi metterò in contatto anche con lei.
Due cose per inquadrare le domande. La fase iniziale di avviamento all'opendata nelle PA italiane è stata caratterizzata da: scarsità di risorse da investire (giornate uomo/function point consuntivabili) difficoltà di comunicazione (mancanza di capacitá di indirizzare problemi sociali e mancanza di strumenti OpenGov admin/citizen) non conoscenza della risorse informative (mancanza di comunicazione inter/intra PA, predominanza del concetto di "raccolta" dati rispetto a quello di "cura"). L'INPS non fa eccezione, anzi, come PA gigantica a volte ha alcuni di questi punti molto estremizzati. Aprire i dati dell'INPS quindi ha significato per lo più dotarsi di:
1. Una buona strategia di apertura [risparmiare soldi, utilizzare ciò che già è in essere, ottimizzare le scelte attuative in modo che massimizzino i principi Open sui quali le scelte si basano ma soprattutto consentano di massimizzare la qualità delle scelte future in agenda; una buona agenda governativa non può e non deve prevedere passi di gambero]
2. Buone pratiche di utilizzo del patrimonio pubblico [essere developers/citizen demand-driven è mandatorio. Liberare dati in un periodo in cui quei dati possono servire a figure professionali diverse può essere un buon modo di "ingaggiare" i cittadini (vedi caso Aliquote INPS o contributi per i lavoratori domestici). Liberare dati in modo che la metodologia di utilizzo e i modelli di riferimento siano di sufficiente qualità (rappresentano davvero tutte le info e siano processabili senza difficoltà) ma al contempo che entrambe le cose non creino un monopolio di concettualizzazione, cioè in sostanza che non si arrivi a prediligere un certo formato o un certo standard solo perché implicitamente si è sempre usato quello (la fossilizzazione della forma, per altro, ha comportato nel tempo che i dipendenti delle PA usano Excel come fosse Photoshop, per cui si arriva per amore della precisione ed eleganza a creare xls talmente barocchi da essere praticamente pattume. E no, openrefine non ce la fa)]
3. Buona comunicazione [fare storytelling del processo di apertura dei dati è fondamentale. Consente all'utente di capire, incasellando tutte le novità in un percorso che ha obbiettivi e milestones precise. Consente alle altre amministrazioni di avere un panorama chiaro di cosa stanno facendo le altre, e migliora lo scambio delle best practice già attuate, nonché il netoworking tra gli opendatari nelle PA]
Questo approccio, secondo me, evita alcuni rischi:
1. Pensare prima di fare consente di non cadere troppo facilmente nelle trappole di alcuni vendor illusionisti. Permette anche di prendere scelte lungimiranti, di modo da evitare di intraprendere un percorso che poi possa presentare un momento di stacco rispetto al panorama generale, che comporterebbe il necessario riadattamento di metodo e strategia con conseguenti costi molto alti (sia politici che economici)
2. Se non ti lasci guidare e non sai ascoltare la domanda non potrai mai sperare che i dati arrivino ad avere un impatto sociale reale sui cittadini. Ad esempio se mi rilasci le tabelle di calcolo per i contributi domestici dopo la scadenza del termine di pagamento hai perso un'occasione per spingere un nuovo modo di gestire le informazioni del settore pubblico. Se non trovi il giusto bilanciamento nel modo in cui i dati devono essere prodotti, rischi di alimentare un'entropia di dati inutilizzabili. Rendere questi interoperabili ha un costo altissimo in giorni uomo, perché è quasi un lavoro di artigianato.
3. Non comunicare bene non significa non comunicare affatto, significa fare danni per lo più. E se i danni avvengono in fase di accordo tra amministrazioni i risultati possono avere un impatto critico sul processo di apertura di tutti gli enti.
Veniamo ai punti:
L'ontologia e i dati Linked
L'ontologia DominioINPS è la prima versione rilasciata di un progetto ancora in essere che subirà diverse fasi di sviluppo nel futuro. La scelta di rilasciare a partire dall'OWL si inscrive nella strategia di implementare il progetto verso due direzioni:
1. Progetti di ricerca sperimentali sui Linked (ma su questo non posso dire di più). L'owl, al contrario dell'RDF, è decisamente più espressivo e permette di modellare anche oggetti complessi come servizi e processi che presentano cardinalitá di organizzazione e temporalità molto difficili da gestire con il solo RDF. Ovviamente il problema non si pone per i dati, ma poiché l'ontologia ha sviluppi ulteriori che prescindono dall'opendata (in senso immediato), rilasciare il download in owl consente di operare su un modello sulla base del quale poter implementare Open Service basati su una semantica solida, in grado di supportare una logica il più possibile complessa. Inoltre, anche in riferimento ai dati, senza proprietà come owl:sameas avremmo grandi difficolta a creare dati linked tra diverse fonti. D'altra parte l'owl non rappresenta un vero ostacolo, perché con due minuti puoi tirarti fuori la serializzazione che preferisci. E la serializzazione RDF/XML da sola non garantisce la consistenza semantica associata ai dati. ad esempio che io dica "andrea mangia una mela" o "una mela mangia una mela" questo comunque rappresenta un rdf valido, ma lil layer semantico predilige sicuramente la prima tripla piuttosto che la seconda. Non rappresenta quindi un vero e proprio impedimento. Irene giustamente sottolineava come il turtle sia effettivamente più espressivo dell'Owl sul versante First Order Logic, nonché più facile da scrivere. Tuttavia implementare una FOL significa anche andare incontro a dei tempi più lunghi di risposta e i dati devono essere curati in modo tale da rendere le FOL inference un vantaggio rispetto alla più "semplice" DLogic. Per questa ragione la prima versione del DominioINPS è stata rilasciata in questo modo. Perché offre una base di modellazione di partenza di buona qualità, sia per quanto riguarda il modello che i dati veri e propri, le cui evoluzioni possono essere schedulate a seconda dei percorsi che si vogliono intraprendere.
Un piccolo inciso per dire che molto spesso si fa confusione tra vocabolari RDF e vere e proprie Ontologie. Se le prime esprimono alcune difficoltà legate alla classificazione tassonomica, le seconde presentano problemi molto più ontologici, cioè legate alle scelte di modellazione delle entità (avvertenza! C'è molto dibattito in merito alla distinzione quindi non mi lapidate :) ). Molto spesso infatti le Ontologie di dominio (come nel caso di INPS) e le task ontologies sono valutate a partire dall'UML di un ontologia fondazionale. Questo livello di precisione nella modellazione si trova per ora solamente in qualche centro di ricerca ma, per chi fosse interessato, vi segnalo quella che è stata la mia Bibbia (http://doc.utwente.nl/50826/1/thesis_Guizzardi.pdf). Giancarlo è un ricercatore molto molto in gamba e ho avuto la fortuna di averlo come prof alla scuola di dottorato dell'FBK sulle Ontologie applicate. Faccio anche notare Alfredo che la riusabilità degli OWL è alta, ma richiede un livello di competenza altrettanto specialistico. Quindi, secondo me, è l'ontology web Language non va usato per "dire" tutto, semplicemente perché una lingua più forbita non significa necessariamente una lingua più significante ma anche solo semplicemente una competenza più alta dei parlanti di quella lingua nell'utilizzo dei significati.
2. La seconda direzione si inscrive invece proprio nel panorama OpenGovData e LOGD. Ci tengo alla distinzione, perché se non si concentrano gli sforzi per separare e standardizzare i dati governativi regnerà sempre il caos a livello di standard. Esempio pratico: come strategia di rilascio ho preferito evitare dataset che fossero classificati con ATECO, semplicemente perché tra "poco" AGID in collaborazione con ISTAT dovrebbe rilasciare il vocabolario ATECO RDF. Dal momento che questo vocabolario e alla base di moltissimi dati, se non ne curassimo un vocabolario semantico perderemmo l'occasione di rafforzare l'interoperabilitá del PSI italiano. Provo a rispondere per punti a tutto, ma siete stati così in gamba che se dimentico qualcosa perdonatemela:
2.1 Gli Owl dei dataset - ogni owl dei dataset ha un ns associato, quindi la separazione tra ns di abstract schema e istanze è già presente. Per comodità potete vedere nel l'ontologia sia i ns di riferimento esterno (tipo DCAT) sia quelli dei dataset (leggermente separati, sono identificati dagli ID che i dataset prensentano all'interno del DB INPS. La sottigliezza sta nel presentare dei dati definiti da un ID unico per qualsiasi tipo di acceso uno effettui: LOD, API o semplice download. Se infatti provate a scaricare una tabella vedrete nella URI di download lo stesso ID che definisce la tabella nell'OWL). Per quanto riguarda i metadati. Poiché allo stato attuale delle cose non è presente content negotiation, i metadati associati all'interno non generano duplicazione. Non tenere conto avrebbe significato il rilascio di dati non consistenti. Ovviamente, come sostenete giustamente, nel momento in cui verrà esposto uno SPARQL, i dati verrano alleggeriti e riconsolidati. Il "chunck autocontenuto" come dice Irene, segue la logica delle "future integrazioni", come dice Alfredo (ma questa logica funziona solo se dietro hai una "buona strategia", cioè se poi l'endpoint me lo apri). Per il momento gli owl dataset devono rispettare i requisiti di primo rilascio e quindi devono avere i metadati al loro interno. Sottilineo anche che se così non fosse, la scelta del modello JSONLD per le API perderebbe di efficacia, almeno in parte. Accenno in breve: la v2 delle API mapperà il modello API LD con il modello DominioINPS, soprattutto per quanto riguarda alcuni vocabolari strutturali, come SDMX, DATACUBE e DCAT (quest'ultimo già impiegato nel bulk). In questo modo si potrá offrire un JSONLD vero e proprio, perche l'impiego che ne è stato fatto nelle API è di tipo "light", come lo chiamo io. ma su questo torno dopo. Sarà quindi possibile sia accedere all'owl come distribution resource, sia avere i dati tramite Bulk sfruttando la capacità del JSONLD di modellare dati linked. Se non ci fossero i metadati del dataset le risorse rappresentate nel bulk non sarebbero definite. Questa soluzione, per altro, secondo me, è più leggera rispetto alla decisione di fare retrieval dei metadati dal l'ontologia generale. È una via percorribile, più elegante, ma può presentare un costo computazionali più alto. Per non parlare di tutte le difficoltà associate ai servizi (soprattutto a livello di WMO) che un ente grande come INPS eroga.
2.2 accessibilità LOD - si, sarà aperto un endpoint e si, DominioINPS avrà al più presto una comoda PURL, così da poter navigare bene i dati anche con roba tipo LODLIVE (che mi fa sempre divertire). La serializzazione RDF ha qui senso, proprio perché in quel momento saranno veri LD on the web. Ma, secondo me, questo è uno step di accessibilità dati, più che di modello, per le ragioni che vi dicevo sopra. Per quanto, come qualcuno ha abilmente colto, ho sempre preferito tagliare lo startup Opendata INPS in senso di sviluppo (caro il mio Alfredo :) ) alcuni strumenti di interrogazione richiedono altrettanto competenza come l'uso dell'Owl. Recentemente stavo studiando qualche soluzione per rendere le query più user friendly. Treasury.io ha adottato una buona soluzione, basata su faceting delle query, che rende ai giornalisti la vita moolto più semplice. Lo sviluppo di un endpoint, quindi, secondo me ha poco senso se non si rende l'interrogazione multimodale.
2.3 copertura legale - Sulla LiMo ho speso un quasi due settimane di notti, per la gloria ovviamente. Mi venne l'idea verso gennaio, perché a forza di studiare leggi, norme e provvedimenti poi cominci a farci l'occhio (miccia scatenante Ernesto Belisario, un amico e un professionista nel suo campo, che mi ha acceso il gene del legal nerd). Stavo cercando un modo per rendere interoperabile le inferenze sulle condizioni legali dei contenuti. Ti ricordi Matteo? su quelle Cc ci stava già lavorando Aaron. Alla fine ho proposto l'idea a Chiara Veninata (ACS) Silvia Mazzini (Regesta) senza il cui aiuto non avremmo messo su nulla (Diego Camarda ci ha dato una grossa mano). Abbiamo fatto tutto sommato un buon lavoro di team, e adesso la LiMo è in valutazione su lov.okfn.org. Sul territorio europeo ne sono presenti tre: la nostra italiana, una francese di un gruppo di ricerca, e una inglese di Leigh Lodds che ora lavora come Consultant all'ODI. La nostra è la più fica ovviamente (scherzo, ma non troppo). Abbiamo quindi deciso di utilizzare la LiMo per coprire le condizioni legali almeno degli OpenGovData, perché cosa si può o non si può fare dev'essere trasparente sempre. Faccio notare che l'individuo limo:license che definisce i temini di DominioINPS sarà online a breve quando anche l'ontologia sarà su LOV. Quindi vi ringrazio per aver apprezzato la cosa, mi fa immensamente piacere. Sottolineo anche un altro aspetto della licenza: i dati sono coperti da IODL2.0 come sapete, l'owl ha la distribuzione CCBYSA. Questo significa che tutto i lavori derivati, versioni più evolute o altro che esce da li deve tornare al Public Sector Domain. Questo garantisce l'auto sostenibilità dell'ontologia come bene comune. Inoltre molti altri enti utilizzano concetti definiti nel modello INPS, e questo inverno, se gli va, potrebbero utilizzare le classi definite ( es. <inps:contributifigurativi> ), migliorando l'interoperabilitá di tutto i dati del settore pubblico. Ovviamente, come forse avete visto, la versione bilingue consente di identificare i contatti necessari per inoltrare ulteriori evoluzioni. Che l'invito sia esteso anche a chi lavora su/con altri enti omologhi a livello europeo mantiene la direzione di valutare le direttive ePSI come un livello di scelte strategiche più che importante. INPS ha infatti cominciato ad aprire seguendo le direttive europee sul riuso nel PSI.
2.4 le API - se parliamo di API vi invito a sentire @Riccardo_Vacca, quello veramente bravo tra i due :) , il progetto nasce dal l'esigenza di harvesting di dati.gov.it per l'aggiornamento dei dati INPS, prima condotto con lunghissime e noiosissime estrazioni (costoso e lento). Quindi come fa vedere giustamente Afredo il paradigma di partenza è REST. Ma detto tra noi non ci soddisfaceva. Primo perché la prima versione avrebbe solo permesso di fare retrieval del datacatalog e dei metadati, secondo perché nel frattempo stavamo sviluppando i linked, e il JSONLD ci è sembrata la scelta strategica e tecnica più adeguata. Nello stesso momento avevano invitato Evodevo al G8 per il tax, trades and Trasparency table per gli opendata. Nelle discussioni dei mesi precedenti si era già parlato della necessità di rilasciare i dati in bulk. Quindi abbiamo pensato di utilizzare una versione "light" di JSONLD, cioè utilizzarlo non per veri e propri linked (la cui mappatura sarebbe avvenuta successivamente), ma per i dati i cui metadati erano embeddati nel dataset. Un piccolo aggiornamento: le API sono "intelligenti", cioè quando anche solo un array di dati è corrotto da un errore di riga, o di contenuto di riga, questo viene isolato con un tag e identificato come "fixing in progress". Due sono le ragioni: trasparenza (se ci sono errori lo devo sapere e dire subito) interpretazione (questo meccanismo previene i casi di interpretazioni errata non voluta dei dati a partire da banali e non voluti errori di trascrizione di riga). Per le altre funzioni vi rimando al reference document. Altro aggiornamento: si, gli owl verranno aggiunti. Le API hanno anche un obbiettivo strategico e politico ben definito (e qui lo confesso un po'):
2.4.1 accessibilità e dati per lo sviluppo: non si può lavorare bene se si è obbligati a scaricare i dati uno per uno. Le api sono fondamentali per aumentare la sostenibilità del lavoro, come la qualità. Senza dati le API perdono di efficacia come mossa orientata a favorire lo sviluppo economico di business basato su opendata. La possibilità per una startup come enigma.io o spaziodati.eu di potersi caricare l'intero OpenDataCatalog INPS e lavoraci aumenta il tempo per la creatività e diminuisce quello di data cleaning, permettendo anche di concentrarsi e studiare il significato dei dati oltre che la loro organizzazione.
2.4.2 competizione e dati per lo sviluppo: non ci può essere vera competizione se non si ha un uguale accesso alle risorse opendata. Il bulk JSONLD permette a tutti di poter testare le proprie capacità, permette alle aziende e alle università di fare ricerca alla pari. Dal momento che un datamarket non si crea da solo, se non permettiamo a chi sa lavorare di far vedere cosa sa fare non avremmo molte possibilità di creare un ecosistema dei dati basato sulla collaborazione di diversi tipi di stakeholders, piuttosto un monopolio di pochi.
2.4.3 quali dati per lo sviluppo: i dati INPS sono considerati high-value dalla G8Opendata Chart (chissà come mai ;) ) e sono altrettanto interessanti da modellare, nonché molto complessi, poiché richiedono uno studio approfondito del dominio. Alfredo fa giustamente notare come INPS abbia molti dati. Verissimo. È ne ha ancora di più di quel che pensate. L'unico modo per averli ora è chiederli. Quindi accesso civico come se non ci fosse domani.
Piccola nota sul finire: purtroppo è complesso far cambiare rotta alle PA per quanto riguarda l'architettura dell'informazione, causa azienda inhouse poco attente agli aggiornamenti normativi e, per gran parte, pigre..più i soliti movimenti politici nelle PA. Il sito non è valorizzato per nulla. Basterebbe molto poco. È qui che entra in gioco il fattore buona comunicazione, quella che serve per intraprendere la fase di startup più OpenGov di un ente. Ma questo, sono convinto, è uno scoglio che richiede un impegno politico che non può essere isolato e sicuramente arriverà gente decisamente più preparata di me questo versante.
Se ho dimenticato qualcosa redarguitemi e vi riscrivo. Riguardo alle novità INPS opendata per inverno 2013 e anno 2014, non lavorando più al progetto, non posso darvi tempi certi. In ogni caso grazie del bel thread, scusate se sono uscito forse un po' dal topic stretto dei LOD, ma un po' di contesto serve per capire i problemi, i punti di forza e le modalità attuative di un progetto che, oltre a dare vita a un discorso di best practice stretta te legato ai LOD, persegue anche i principi dell'opendata per i quali ci stiamo battendo ormai da anni. Rimango comunque sempre a disposizione per qualsiasi altra cosa. A presto.
Andrea
Ps: Matteo quando trovo il tempo provo a mettermi a lavorare su PACO (Public Administration Curricula Ontology), tanto non c'è pericolo che le cose in Italia vadano troppo veloce.
Riccardo Grosso
Aug 19, 2013, 11:50:05 AM8/19/13
to spaghett...@googlegroups.com
Buona fortuna ! Caro Andrea Raimondi, la meriti tutta, e grazie per il tuo servizio prezioso che fai al mondo lavorando sulle ontologie !
--
Hai ricevuto questo messaggio perché sei iscritto al gruppo "Spaghetti Open Data" di Google Gruppi.
Per annullare l'iscrizione a questo gruppo e non ricevere più i suoi messaggi, invia un'email a spaghettiopend...@googlegroups.com.
Visita questo gruppo all'indirizzo http://groups.google.com/group/spaghettiopendata.
Per ulteriori opzioni, visita https://groups.google.com/groups/opt_out.
Alfredo Serafini
Oct 23, 2013, 3:20:23 AM10/23/13
to spaghett...@googlegroups.com
si è parlato più volte della opportunità di servizi per lo "status" degli endpoint SPARQL, a quanto pare esiste uno SPARQLES (SPARQL Endpoint Status) :-)
Matteo Brunati
Jun 6, 2014, 3:48:34 AM6/6/14
to spaghett...@googlegroups.com
Aggiungo alla discussione due spunti interessanti, a livello di tema e di implementazioni utili:
e
Energy Buildings Performance Scenarios as Linked Open Data - http://blog.semantic-web.at/2014/06/05/energy-buildings-performance-scenarios-as-linked-open-data/
e
RDF is Critical to a Successful Internet of Things - http://semanticweb.com/rdf-critical-successful-internet-things_b42994
matt
Reply all
Reply to author
Forward
0 new messages