[LinkedOpenData&Graph] Il Linked Open Data Graph in tempo reale

Ho trovato un interessante progettino su GitHub che utilizza Protovis, libreria JavaScript ed SVG per la web-native visualizations (vedete anche questo interessante studio, A Scalability Study of Web-Native Information Visualization). Questo progetto permette di visualizzare su un grafo tutta la rete dei LOD (Linked Open Data) aggiornata direttamente dal portale CKAN, diventato il punto di riferimento per la registrazione dei datasets “LOD-compliant”.

Il progetto è stato scritto da Ed Summer ed è disponibile a questo link: https://github.com/edsu/lod-graph

Una anteprima dei LOD attualmente disponibili nella rete CKAN, visualizzati sul grafo Protovis di Ed Summer, la potete vedere anche qui: http://inkdroid.org/lod-graph/

Linked Open Data Graph

Se vi volete divertire a generare il grafo sui vostri pc, basta scaricare il progetto da GitHub e lanciare il comando da terminale:

./ckan.py

Lo script Python si connette alle API REST di CKAN, scarica i dati ed aggiorna un file locale ckan.log in cui potrete vedere lo stato di avanzamento delle operazioni (ci mette un po’…). Quando la procedura è ultimata (“finished ckan load” sul log), lo script vi genera un file lod.js in locale, con il JSON contenente tutte le informazioni sui dataset LOD aggiornati (titolo, url, rating, ecc.). Basta aprire la pagina index.html per visualizzare il Linked Open Data Graph su browser.

 

Altri riferimenti utili:

[NO-SQL] Appunti su analisi di performance e comparazione dei database NoSQL

Continuando la trattazione dell’argomento dei Database No-SQL, viste le impressioni e segnalazioni via email dei visitatori di questo blog, condivido un pò di appunti in un documento che potete scaricare qui di seguito:

Database NoSQL-Comparazione tecnologie

Il documento raccoglie le considerazioni e le valutazioni oggettive emerse durante la lettura di articoli e documentazioni online sull’argomento dei DB No-SQL. Nello specifico, l’oggetto di studio è stato MongoDB, confrontandolo con altre soluzioni (relazionali e non) e, in particolare, è stata approfondito il suo possibile utilizzo per la gestione di una struttura a grafo.

NoSQL Model

Ecco l’indice dei paragrafi del documento, sperando vi possa essere utile per spunti o per far nascere riflessioni/discussioni sull’argomento:

  1. I database NoSQL
    1. Perché NoSQL? Il teorema di CAP e il No-SQL data model
    2. Un confronto tra le famiglie di DB NoSQL
    3. I database document-oriented e graph-oriented
  2. Breve introduzione su MongoDB
    1. Principali caratteristiche di MongoDB
    2. Comparazione tra MongoDB e MySQL
    3. Ambiti di utilizzo e realizzazione dei direct graph con MongoDB
    4. Soluzioni ibride: MongoDB + database a grafo + RDF triple store
    5. Analisi delle prestazioni di MongoDB all’aumentare dei documenti memorizzati
  3. Confronto tra le performance di MongoDB e di altri database NoSQL
    1. Confronto MongoDB con vari database NoSQL
    2. Confronto HBase e MongoDB
  4. Analisi di performance dei Graph Database
    1. Elenco e caratteristiche di varie implementazioni di Graph Database
    2. Analisi e confronto delle performance di varie implementazioni di Graph Database
    3. Scalabilità
Database NoSQL-Comparazione tecnologie
Titolo: Database NoSQL-Comparazione tecnologie (0 click)
Etichetta:
Filename: database-nosql-comparazione-tecnologie.pdf
Dimensione: 770 kB

[NO-SQL] Il Teorema di CAP e il No-SQL data model

Volendo continuare la serie sulla “filosofia” NO-SQL e sulle prerogative per cui è necessaria (vedi l’articolo riportato su questo blog, “NO-SQL e introduzione a MongoDB“), estrapolo qui le motivazioni e le caratteristiche lette negli articoli riportati su BigDataNERD:

Perché NO-SQL?

Per poter rispondere alla domanda occorre esaminare il “teorema di CAP” e ricordare che un concetto fondamentale degli RDBMS è quello delle “ACID transactions” (A=Atomicity, C=Consistency, I=Isolation, D=Durability)

  • A come Atomicità. La transazione è indivisibile, ossia o tutti gli statements che la compongono vengono applicati ad un database o nessuno.
  • C come Consistenza. Il database deve rimanere in uno stato consistente prima e dopo l’esecuzione di una transazione, quindi non devono verificarsi contraddizioni (inconsistency) tra i dati archiviati nel DB.
  • I come Isolamento. Quando transazioni multiple vengono eseguite da uno o più utenti simultaneamente, una transazione non vede gli effetti delle altre transazioni concorrenti.
  • D come Durabilità. Quando una transazione è stata completata (con un commit), i suoi cambiamenti diventano persistenti, ossia non vengono più persi.

I più comuni e diffusi RDBMS supportano le transazioni ACID e i principi su esposti sembrerebbero bastare. Ma dov’è il problema?

Nell’era del Web 2.0, le applicazioni devono lavorare su bilioni e trilioni di dati ogni giorno e la scalabilità è un concetto che in tale ambito ricopre un ruolo importantissimo. Per questo motivo i database hanno bisogno di essere distribuiti sulla rete per realizzare una scalabilità orizzontale. Esaminiamo qui il concetto di “CAP theorem” per valutare le caratteristiche di un siffatto sistema di storage distribuito dei dati.

Il teorema di CAP fu teorizzato da Eric Brewer nel 2000 (C=Consistency, A=Availability, P=Partition-Tolerance). Per maggiori informazioni si veda il seguente articolo: ACID vs. BASE il Teorema di CAP (di Stefano Pedone).

Nell’ambito di un sistema di storage distribuito, i 3 principi hanno la seguente definizione:

Consistency: se viene scritto un dato in un nodo e viene letto da un altro nodo in un sistema distribuito, il sistema ritornerà l’ultimo valore scritto (quello consistente).

Availability: Ogni nodo di un sistema distribuito deve sempre rispondere ad una query a meno che non sia indisponibile.

Partition-Tolerance: è la capacità di un sistema di essere tollerante ad una aggiunta o una rimozione di un nodo nel sistema distribuito (partizionamento) o alla perdita di messaggi sulla rete.

Secondo la teoria CAP, è impossibile garantire tutti e tre i principi del teorema di CAP. Infatti, si consideri un sistema distribuito e si supponga di aggiornare un dato su un nodo 1 e di leggerlo da un nodo 2, si verificheranno le seguenti conseguenze:

  1. Il nodo 2 deve ritornare l’ultima “miglior” versione del dato (quella consistente) per non violare il principio della Consistenza
  2. Si potrebbe attendere la propagazione del dato modificato nel nodo 2 e, quest’ultimo, potrebbe mettersi in attesa della versione più aggiornata, ma, in un sistema distribuito, si ha un’alta possibilità di perdita del messaggio di aggiornamento e il nodo 2 potrebbe attenderlo a lungo. Così non risponderebbe alle query (indisponibilità), violando il principio dell’Availability
  3. Se volessimo garantire sia la Consistency che l’Availability, non dovremmo partizionare la rete, violando il principio del Partition-Tolerance

Le web applications progettate in ottica Web 2.0, caratterizzate da architetture altamente scalabili e profondamente distribuite con politiche di prossimità geografica, puntano in maniera forte sulla garanzia di alte prestazioni ed estrema disponibilità dei dati. Si trovano quindi ad essere altamente scalabili e partizionate. La filosofia NO-SQL è sbilanciata verso la ridondanza dei nodi e la scalabilità.

Di seguito, si riporta una tabella dei maggiori database NO-SQL del momento:

Il NoSQL data model può essere implementato seguendo differenti approcci a seconda delle strutture dati con cui si rappresentano i record di dato.

  • Famiglie di colonne o “wide column store” (come Cassandra e HBase): le informazioni sono memorizzate in colonne, in coppie chiave/valore. Tipicamente sono usati nell’ambito della memorizzazione distribuita dei dati;
  • Document Store (come CouchDB, MongoDB): le informazioni sono organizzate in “Document“, rappresentati in XML, JSON o BSON, e l’accesso ai dati avviene attraverso API che interrogano veri e propri dizionari. Sono molto usati nello sviluppo di attuali web applications;
  • Key/Value Store (come Membase, Redis): la struttura dati di memorizzazione è una Hash Table (coppia chiave-valore). Indicate per sistemi di caching o Hash Table distribuite;
  • Graph Data Store (come Neo4J, InfoGrid, OrientDB). Il modello di programmazione è il grafo e l’accesso ad archi e nodi avviene attraverso algoritmi di ricerca su grafo. Tipicamente si usano nei social network.

 

[OpenData&SemanticWeb] Cittadinanza attiva con i Linked Open Data

Grazie al commento all’articolo “[SemanticWeb] DBpedia e il progetto Linked Data” lasciatomi da Michele Barbera (di SpazioDati.eu), sto approfondendo il discorso dei Linked Open Data, e ho letto tre validi e dettagliati riferimenti:

Ho estrapolato alcune informazioni utili per capire l’ambito di applicazione e gli obiettivi del riutilizzo delle informazioni del settore pubblico.

NOTA. I contenuti riportati di seguito vengono elaborati e presentati nel rispetto delle licenze dei riferimenti su citati (nella fattispecie Creative Commons Attribuzione-Non commerciale)

L’obiettivo dei Linked Data è quello di rendere i dati realmente comprensibili ai cittadini tramite applicazioni software sviluppate ad hoc e vedremo cosa vuol dire propriamente questa definizione. Ma è un processo che si attua soltanto se si seguono delle linee guida che permettono alle tecnologie dell’informazione di comprendere i dati e i loro collegamenti, ovvero l’informazione libera deve essere machine readable (che definiremo tecnicamente più avanti) in modo da poter creare una fitta rete di collegamenti e dare un significato al dato stesso (linked data).

 

Da dove nasce? Tutto ha origine dalla dottrina “Open Government” promossa dall’amministrazione Obama (anno 2009), arrivando a coniare la definizione diOpen Government Data, che si sta diffondendo nei paesi industrializzati con l’obiettivo di ottenere l’accesso libero e proattivo ai dati di un ambito specifico: istituzioni politiche e pubblica amministrazione. La dottrina prevede l’apertura di governi e PA verso nuove forme di trasparenza e partecipazione (e collaborazione) dei cittadini alla “cosa pubblica”.
Ma in realtà, la filosofia dell’accesso libero all’informazione nasce già prima, dal movimento Open Source, da termini come copyleft, Web2.0 (e, quindi, social software).
Nel Web tradizionale, la natura della relazione tra documenti è implicita perché l’HyperText Markup Language (HTML) non è in grado di esprimerne la semantica: i collegamenti (link) tra documenti non esprimono il tipo di relazione che li lega.
Tim Berners-Lee, nella sua prima proposta presentata al CERN nel 1989, espresse la necessità di creare un ipertesto globale, dove le informazioni fossero tutte collegate tra di loro, ma dove la ricerca dei contenuti avesse come risultato i documenti che davvero corrispondevano alla esigenze di chi fa la ricerca. Tale ipertesto globale (web semantico) si può creare con un sistema di gestione dell’informazione a grafo, i cui nodi sono collegati da link ipertestuali “etichettati”, ossia con la descrizione del tipo di relazione che si stabilisce tra due nodi. Si passa dal “World Wide Web” visto come una rete di documenti ad una “rete di dati” (Web of Data), dove i dati stessi sono inseriti in un contesto e, dunque, arricchiti di semantica. Cosa ancora più importante è che lo scopo del Web Semantico è quello di dare vita ad una “ragnatela” di dati elaborabili dalle macchine (machine readable, appunto). Il Web Semantico (o web dei dati) è l’obiettivo finale e i linked data offrono i mezzi per raggiungerlo.

 

[SemanticWeb] Microformats: le pagine web acquistano significato

I Microformats permettono di inserire nelle pagine web i cosiddetti “smarter data” (informazioni “intelligenti”). In poche parole, non sono altro che semplici convenzioni per includere dati strutturati nelle pagine web ed arricchirle di informazioni (semantiche). Sono solo alcuni dei possibili semantic markup che hanno, appunto, lo scopo di inserire “conoscenza semantica” nelle nostre pagine. Nel panorama dei microformati ne esistono diversi e alcuni li utilizziamo quotidianamente mentre navighiamo o scriviamo articoli o post online. Alcuni di questi permettono di  ricavare le relazioni tra le persone dai blogrools (link “amici” nei nostri blog), commenti, coordinate ed altre info aggiuntive.

L’utilizzo dei microformats si è diffuso a tal punto che Google stessa dichiara che il 50% delle pagine su Internet contiene questi “semantic markup” e incoraggia a supportare l’iniziativa poiché i microformats migliorano e semplificano la ricerca dei contenuti. Ad esempio, Google appoggia e supporta il microformats hRecipe con l’iniziativa Rich Snippets.

Articoli interessanti su tale iniziativa sono i seguenti:

Rich snippets (microdati, microformati e RDFa) . Da quanto si legge qui, gli snippet, le poche righe di testo visualizzate sotto ogni risultato di ricerca (nei motori come Google), hanno lo scopo di dare agli utenti un’idea dei contenuti della pagina e del motivo per cui sono pertinenti alla query impostata.

Se Google comprende i contenuti delle pagine può creare rich snippet, vale a dire informazioni dettagliate utili per gli utenti che impostano query specifiche. Cioè questi rich snippet consentono agli utenti di capire se il sito è pertinente alla loro ricerca. Si aiuta Google a presentare queste informazioni pertinenti aggiungendo ulteriore codice di markup HTML nelle pagine. Questo codice di markup consente a Google di riconoscere determinati tipi di dati e di visualizzarli nei rich snippet quando opportuno.

Google consiglia di utilizzare i microdati, ma sono supportati tutti i tre formati che seguono. Non occorre conoscere già questi formati, è sufficiente una conoscenza di base del linguaggio HTML.

Esiste anche lo strumento di test dei rich snippet per assicurarsi che Google possa leggere ed estrarre i dati dai markup inseriti su una pagina: Rich Snippets Testing Tool

Nella tabella seguente vengono mostrati i microformati più popolari e le relative iniziative:


Un webservice online molto potente che ci aiuta a rinvenire e interagire con i microformati nelle pagine è microform.at, il quale prende in pasto una URL e rintraccia tutti i microformats presenti sulla pagina con relativo formato.

Facciamo un esempio: se sul sito microform.at inserisco come URL http://it.wikipedia.org/wiki/Calabritto, il webservice mi estrae tutti i microformati presenti nella pagina. In particolare, se scarico il formato KML (Keyhole Markup Language), un linguaggio basato su XML creato per gestire dati geospaziali in tre dimensioni, e lo importo su Google Earth, mi fa vedere su mappa i dati geospaziali acquisiti dalla URL inserita.

Vediamo alcuni microformats:

Friend of a Friend

FOAF (Friend of a Friend ) è una ontologia che descrive le relazioni tra le persone, le loro attività, ecc. Il principio di FOAF viene sfruttato da XFN (XHTML Friends Network) che lo ritroviamo, per esempio, nel plugin “blogroll” di WordPress, e  serve a descrivere le relazioni tra i siti, e relativi autori/proprietari, creando le relazioni tra le persone:

<a href="http://jane-blog.example.org/" rel="sweetheart date met">Jane</a>
<a href="http://dave-blog.example.org/" rel="friend met">Dave</a>
<a href="http://darryl-blog.example.org/" rel="friend met">Darryl</a>
<a href="http://www.metafilter.com/">MetaFilter</a>
<a href="http://james-blog.example.com/" rel="met">James Expert</a>

Per maggiori informazioni su XFN vedi: http://gmpg.org/xfn/intro

Un altro microformats particolarmente usato per inserire informazioni di geolocalizzazione in una pagina web è detto GEO. Si ispira alla omonima proprietà presente nel microformats vCard. Siti popolari, come Wikipedia e Yahoo!, utilizzano geo e altri microformats per esporre informazioni di geolocalizzazione.

<!-- The multiple class approach -->
<span style="display: none" class="geo">
  <span class="latitude">36.166</span>
  <span class="longitude">-86.784</span>
</span>

<!-- When used as one class, the separator must be a semicolon -->
<span style="display: none" class="geo">36.166; -86.784</span>

Altri microformats molto usati (specie da Google) sono quelli che riguardano l’inserimento di commenti, opinioni e recensioni, ricette con ingredienti  e istruzioni, come hRecipe e hReview. Il sito http://www.foodnetwork.com/  utilizza hRecipe e hReview per catalogare le ricette e le recensioni degli utenti.

Info su hRecipe: http://microformats.org/wiki/hrecipe

Info su hReview: http://microformats.org/wiki/hreview

Tra i microformats più famosi non possiamo non citare OpenGraph di Facebook, protocollo che consente a qualsiasi pagina web di diventare un oggetto presente in un grafo sociale.

Il grafo sociale ha lo scopo di rappresentare i legami tra le persone e le azioni che questi hanno con le risorse presenti tra loro e in rete. Il protocollo si attua mettendo nella pagina determinati tag e accedendo alle informazioni e ai dati correlati attraverso le API di Facebook.

 

Concludendo, i microformati, insieme ad altri semantic markup, sono ovunque nelle nostre pagine e permettono di ricostruire relazioni e collegamenti tra persone, risorse, contenuti sparsi sulla rete. Siamo ancora lontani da un processo di standardizzazione, che si spera arrivi con l’HTML5. Al momento navighiamo in un mare di tag che impregnano le nostre pagine web e che cercano di dargli un significato, vitali per l’interpretazione da parte dei software e per attuare quello che è definito machine learning.