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

 

La start-up sei tu. La vita come impresa e il network sociale professionale

Ho letto un libro interessante, suggeritomi da @PepperZen, e scritto dal cofondatore e presidente di LinkedIn, Reid Hoffman, in collaborazione con Ben Casnocha.

Ecco il titolo: Teniamoci in contatto. La vita come impresa (traduzione dell’originale “The start-up of you”).

Questo libro è concepito come un dono che gli autori hanno voluto fare ai lettori, offrendo strumenti per migliorare la realtà non solo lavorativa, ma anche quotidiana, le relazioni con le persone con cui ci troviamo a contatto. Il tema predominante è quello delle start-up, iniziative che nascono per attitudine, grazie ad una mentalità imprenditoriale e ad una fitta di rete di contatti. Dove si rischia e si sa da dove attingere per ricavare informazioni, ovvero dal network di persone che ci circondano. Nel libro vengono date varie “dritte” su come creare e gestire il proprio network, usandolo come propria arma per passare da un Piano A ad un piano B e costruendosi un piano di “salvataggio” (detto Z). Interessanti sono anche le motivazioni che hanno portato all’adozione di determinate scelte nell’ambito dei social network, come LinkedIn – per esempio, il discorso dei gradi di separazione – e gli esempi di vita di alcuni personaggi che hanno fondato le loro start-up, divenute poi grandi società famose in tutto il mondo.

Ecco la mission di Hoffman e Casnocha con la scrittura di questo libro:

Per Ben e per me, questo libro rappresenta uno dei nostri doni alla società, per ricambiare ciò che abbiamo ricevuto. Siamo convinti che gli strumenti forniti in queste pagine possano migliorare sia la tua vita sia la società. A volte ricambiare può significare semplicemente diffondere idee dense di significato.

Per una sintesi e una recensione del libro, vi invito a leggere questo articolo: Il libro “Teniamoci in contatto”, molto più di un libro.

Cito un passo che mi ha particolarmente colpito durante la lettura:

Diventa una persona a cui le altre persone del tuo network siano motivate a rivolgersi in relazione a determinati argomenti. Rendi noti ai tuoi collegamenti i tuoi interessi e le tue competenze scrivendo blog post ed email, o creando gruppi di discussione. Quando le persone si rivolgono a te per ottenere informazioni, tu acquisti al tempo stesso informazioni da loro.

Per finire, trasmettere informazioni interessanti al tuo network in modalità push incrementa le probabilità che tu ottenga informazioni ricollegabili alla serendipity. Pubblica un articolo, manda una citazione via email, inoltra un’offerta di lavoro e fai piccoli doni di altro tipo alla tua rete. I tuoi amici lo apprezzeranno, e tu renderai più probabile che quelle stesse persone ti ricambino mandando a te informazioni in futuro.

Sperando di farvi cosa gradita e utile e di scambiare con voi informazioni che ci arricchiscano a vicenda, ho sottolineato ed estratto delle frasi che ho reputato importanti man mano che leggevo e vorrei condividerle qui con voi. Buona lettura!

Continua la lettura

Libertà di informazione? Rettifica dei contenuti online, anche se veritieri

Vi riporto l’appello pubblicato sul sito di Wikipedia, in merito al disegno di legge sulle intercettazioni telefoniche, telematiche e ambientali. Una legge che, se approvata, imporrebbe ad un sito di informazione (o anche ad un semplice blog) di rettificare i contenuti in seguito ad una segnalazione, entro 48 ore. Per le grosse piattaforme come Wikipedia, ad esempio, questa cosa sarebbe ingestibile e potrebbe comportarne anche la chiusura. Un attacco a quella che conosciamo (conoscevamo?) come libertà di informazione.

Ecco l’appello di Wikipedia:

Gentile lettrice, gentile lettore,

il comma 29 del disegno di legge in materia di intercettazioni telefoniche, telematiche e ambientali (rif.) – se approvato dal Parlamento italiano – imporrebbe ad ogni sito web, a pena di pesanti sanzioni, di rettificare i propri contenuti dietro semplice richiesta di chi li ritenesse lesivi della propria immagine.

Wikipedia riconosce il diritto alla tutela della reputazione di ognuno – già sancito dall’articolo 595 del Codice Penale italiano – ma con l’approvazione di questa norma sarebbe obbligata ad alterare i contenuti delle proprie voci indipendentemente dalla loro veridicità, anche a dispetto delle fonti presenti e senza possibilità di ulteriori modifiche. Un simile obbligo costituirebbe una limitazione inaccettabile all’autonomia di Wikipedia, snaturandone i principi fondamentali.

Wikipedia è la più grande opera collettiva della storia del genere umano, in continua crescita da undici anni grazie al contributo quotidiano di oltre 15 milioni di volontari sparsi in tutto il mondo. Le oltre 925 000 voci dell’edizione in lingua italiana ricevono 16 milioni di visite ogni giorno, ma questa norma potrebbe oscurarle per sempre.

L’Enciclopedia è patrimonio di tutti. Non permettere che scompaia.

Questo, invece, è quanto riportato nel disegno di legge (da notare le frasi sottolineate!!!):

La IX Commissione, esaminato, per le parti di propria competenza, il nuovo testo del disegno di legge recante: «Norme in materia di intercettazioni telefoniche, telematiche e ambientali» (n. 1415-B Governo), premesso che:

    • il testo approvato dal Senato reca modifiche al comma 29 dell’articolo 1, in base alle quali si precisa che i giornali quotidiani e periodici diffusi per via telematica sono compresi nell’ambito dei siti informatici ai quali è esteso l’obbligo di rettifica delle informazioni ritenute non veritiere o lesive della reputazione dei soggetti coinvolti, mediante la pubblicazione, entro quarantotto ore dalla richiesta, delle dichiarazioni o rettifiche con le stesse caratteristiche grafiche, la stessa metodologia di accesso al sito e la stessa visibilità della notizia cui si riferiscono;
    • la formulazione del testo, come modificato dal Senato, non esclude il rischio, già evidenziato nel parere espresso dalla Commissione sul disegno di legge in prima lettura presso la Camera dei deputati, che l’obbligo di rettifica ricada, per la generalità dei siti informatici, piuttosto che sugli autori dei contenuti diffamatori, sui gestori di piattaforme che ospitano contenuti realizzati da terzi, i quali, in considerazione del volume dei contenuti ospitati dalla piattaforma, non sarebbero in grado di far fronte a tale obbligo;
    • occorre invece ribadire l’esigenza che l’obbligo di rettifica, di cui all’articolo 8 della legge 8 febbraio 1948, n. 47, come modificato dal comma 29 dell’articolo 1 del disegno di legge in esame, sia riferito esclusivamente ai giornali e periodici diffusi per via telematica e soggetti all’obbligo di registrazione di cui all’articolo 5 della citata legge n, 47 del 1948;

[SemanticWeb] DBpedia e il progetto Linked Data

Condivido con voi un articolo interessante su DBpedia, che potete leggere al seguente link: https://webwatching.eustema.it/dbpedia-il-cuore-del-web-semantico/

Su questo blog, ho già citato DBpedia all’interno dell’articolo:

————————–

[Articolo tratto da WebWatching Eustema]

DBpedia è attualmente uno dei più importanti progetti legati al Web semantico, di cui oggi parliamo proprio per capire come internet stia evolvendo verso una dimensione più intelligente, basata sui dati collegati tra loro in modo strutturato (“Linked Open Data“).

Il progetto DBpedia consiste nella trasposizione in dati strutturati di tutto l’enorme patrimonio di conoscenze di Wikipedia, in modo che tali dati siano collegabili ad altri insiemi di dati ed utilizzabili in modo automatico dalle applicazioni. DBpedia è considerata da Tim Berners Lee (l’inventore del Web) come una delle parti più importanti proprio del progetto Linked Data, basato su RDF, il formato standard del Web semantico.

In parole povere, il formato RDF permette di “dare senso” alle informazioni, suddividendole in unità minime (“statement”), dette “triple”, ciascuna definita da 3 elementi(soggetto – predicato – oggetto) che consentono di creare relazioni con altre informazioni. Il soggetto è una risorsa, il predicato è una proprietà e l’oggetto è un valore (e quindi anche il puntamento  ad un’altra risorsa). Un esempio di tripla è “Umberto_Eco” “è_autore_di” “Il_nome-della_rosa”.

Lo stato dell’arte di DBpedia è il seguente: a settembre 2011 (ultimi dati disponibili) comprendeva più di 3.64 milioni di elementi, 1.83 milioni dei quali classificati in un’ontologia consistente, incluse 416.,000 persone, 526.000 luoghi, 106.000 album musicali, 60.000 film, 17.500 videogiochi, 169.000 organizzazioni, 183.000 specie animali e 5.400 patologie. Il tutto in 97 lingue e con link a 6,2 milioni di link ad altri dataset. Questi ultimi comprendono, tra gli altri,  GeoNames (il database con oltre 10 milioni di nomi geografici), il Progetto Gutenberg (una biblioteca con i testi dei libri di pubblico dominio), Musicbrainz (enciclopedia della musica), il CIA World Fact Book, eccetera, oltre a numerosi dataset ontologici che consentono di creare correlazioni tra i vari domini di conoscenza. Tutto in licenza Creative Commons.

Anche in Italia, naturalmente, sta crescendo DBpedia, con oltre 1 milione di entità estratte da Wikipedia in lingua italiana e nell’ambito del progetto Linked Open Data Italia. Quest’ultimo comprende, per ora, qualche dataset di un certo rilievo, come Dati.camera.itMusei Italiani e Scuole Italiane.

Link utili su questo argomento

L’attuale “nuvola” dei Linked Open Data (clicca sul link per ingrandire)

Volunia: Marchiori dice addio

In questo blog si è già parlato di Volunia, il motore di ricerca innovativo tutto italiano ideato da Massimo Marchiori e delle difficoltà di decollare per mancanza di investimenti forti (ahimè, siamo in Italia) e di difficoltà organizzative. Marchiori dice addio, scrivendo un articolo e spiegando le sue ragioni. Ora cosa succederà al progetto Volunia? Penso che l’idea morirà insieme al suo creatore. Qualcuno la definisce “la solita italianata”, io marcherei la frase “fuga di cervelli”. Si perchè geni come Marchiori non sono fatti per rimanere in Italia.

Ecco di seguito l’articolo di Marchiori:

La vita è fatta di storie. E la storia che sto per raccontarvi non è tutta la storia che potrei raccontare, anzi (quella completa sarebbe lunga come un libro), ma contiene gli elementi principali.

Cominciamo dalla fine: non sono più direttore tecnico di Volunia. E non solo: non dirò più una sola parola tecnica, non darò più un’idea, non contribuirò alla manutenzione ed al miglioramento né del codice che ho scritto, né degli algoritmi che ho dato al progetto, e non ne creerò mai più di nuovi. A meno che la situazione non cambi.

Per capire come questo sia potuto succedere, occorre tornare indietro, all’inizio della storia.

Volunia
Volunia, è risaputo, nasce qualche anno fa, da una serie di mie idee che ho concretizzato in un progetto strutturato e ambizioso. Un progetto, a mio avviso, troppo bello per non essere realizzato; e dal potenziale enorme. Decisi così di mettermi in gioco, buttandomi anima e corpo in quest’avventura, anche a costo di enormi sacrifici personali.

Quello che però forse non sapete è che io non sono l’Amministratore Delegato di Volunia. In altre parole, non sono io il numero uno della società. Perché ho accettato allora? Perché in tutta la mia vita finora, avevo sempre lavorato con persone che mettevano in prima piano passione, fiducia, onestà. E poi, perché mi sono lasciato convincere da una argomentazione tutt’ora vera: che il progetto non sopravviverebbe senza di me. Ho creato un team e l’ho guidato nella costruzione da zero del sistema, ho affrontato le difficoltà di una startup e cercato soluzioni a mano a mano che la complessità aumentava,  sempre con la visione del progetto globale.

Sebbene fossi consapevole che lasciare la carica di Amministratore Delegato ad altri avrebbe potuto rivelarsi una scelta delicata da un punto di vista strettamente economico, ho accettato di impegnarmi in questo progetto perché quello che faccio nella vita – Volunia incluso –  non ha lo scopo primario di “fare i soldi”. Se il mio obiettivo fosse l’arricchimento personale, avrei da tempo abbandonato l’Università e l’Italia e accettato una delle offerte provenienti dall’estero. Mi sono invece immerso anima e corpo in questo progetto per la bellezza di far progredire il mondo del web, per il piacere di dare una scossa al futuro e fare qualcosa di utile.

Ed anche per altri motivi, come quello di dare stimoli all’Italia, mostrare che si deve cercare di innovare, e non serve necessariamente scappare da questo Paese per farlo..

Vero che un progetto del genere, per avere successo, deve generare utili. Avevo ideato questa parte del progetto in maniera precisa e scrupolosa, con idee specifiche ed algoritmi opportuni (che, ripeto, ora non darò più a Volunia) ma lo scopo finale era proporre agli utenti della rete modi nuovi di concepire il web e di sfruttarne le potenzialità.
Così, mi sono fidato, accettando di non essere il numero uno. Mi sono occupato di quello che era fondamentale: la direzione tecnica di Volunia.

Una direzione tecnica dovrebbe realizzare in completa autonomia le proprie idee innovative, nella maniera migliore ed il più efficientemente e rapidamente possibile. Così sarebbe ovviamente dovuto essere. Ma non è andata così, ed i risultati si sono visti.
Finora non ho parlato, sopportando molte avversità per il bene ultimo del progetto, ma gli ultimi avvenimenti mi impongono di intervenire.

Continua la lettura

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/06/11/volunia-marchiori-dice-addio/.

[DB] Perché denormalizzare una basedati?

Prima di parlare della denormalizzazione di una basedati, ricordiamo cos’è la sua normalizzazione: è il procedimento che ha come conseguenza la riduzione della ridondanza all’interno del database, e che quindi consente un risparmio in termini di spazio occupato. Tale operazione andrebbe eseguita in fase di progettazione, riuscendo quindi subito ad identificare i dati raggruppabili in tabelle separate da mettere in relazione. Effettuare subito questo procedimento porta anche ad una migliore comprensione del database e dei legami che intercorrono tra le varie tabelle.

Ci sono tre diverse forme di normalizzazione (dette forme normali di Boyce e Codd):

  • la 1° Forma Normale (1NF) consiste nel fare in modo di non presentare gruppi di attributi che si ripetono (ossia ciascun attributo è definito su un dominio con valori atomici) e nel far esistere una chiave primaria per ciascuna relazione (ossia esiste un insieme di attributi, che identifica in modo univoco ogni tupla della relazione)
  • una volta portato il database alla 1° Forma Normale, dobbiamo portarlo alla 2° Forma Normale (2NF), ossia per ogni relazione tutti i campi non chiave dipendono funzionalmente dall’intera chiave composta e non da una parte di essa.
  • la 3° Forma Normale (3NF) si ha quando la relazione è, innanzitutto, in 2° forma normale e tutti gli attributi non-chiave dipendono dalla chiave soltanto, ossia non esistono attributi che dipendono da altri attributi non-chiave.

Per definizione, una relazione R è in forma normale di Boyce e Codd (BCNF) se e solo se è in 3NF e, per ogni dipendenza funzionale non banale X –> Y,  dove X è una superchiave per R.

In questo modo si riducono ulteriormente sia la ridondanza dei dati nelle tabelle che la possibilità di errori umani in fase di inserimento dei dati.

La denormalizzazione, invece, è il processo che permette di ottimizzare le performance in lettura di un database aggiungendo ridondanza nei dati o raggruppandoli. Tale operazione viene effettuata spesso per risolvere l’inefficienza dei database relazionali, visto che, se normalizzati, possono soffrire di pesantezza nel caricamento dei dati.

Quando si valuta la normalizzazione tra le alternative di progettazione di una basedati, è utile tenere presente le diverse tecniche che consentono di denormalizzare intenzionalmente un database. La denormalizzazione intenzionale dei dati può essere motivata dal rilevamento di problemi di prestazioni oppure nel caso in cui si desideri semplificare la creazione di report ad-hoc. I problemi di prestazioni derivano dalle query per le quali, in produzione, è richiesto un numero troppo elevato di join di tabelle con un accesso intensivo al disco. Lo scopo della creazione di report ad-hoc è consentire anche agli utenti finali di eseguire query non strutturate, in quanto è possibile che utenti finali poco esperti non siano certi delle procedure necessarie per ottenere informazioni da più tabelle correlate.

Continua la lettura

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/06/07/db-perche-denormalizzare-una-basedati/.

La raccomandazione e il gioco dell’oca

La raccomandazione (di Alberto Moravia)

Disoccupato e sfinito, indossando sotto l’unica giubba, l’unica camicia e l’unica cravatta, quella inamidata dal sudore, questa ridotta ad una corda, la testa piena di nebbia e le grinze della pancia che mi giocavano a tresette, pensai bene di consultarmi con un amico mio. Quest’amico si chiamava Pollastrini ed era autista presso due vecchie signorine che avevano una macchina più vecchia di loro e se ne servivano sì e no due volte alla settimana: un posto ideale. Lo trovai al garage, che rimestava nel cofano; come mi vide, subito comprese dalla mia faccia che stavo male e, prim’ancora che parlassi, mi diede una sigaretta. L’accesi con mano tremante e gli spiegai la cosa. Lui si grattò la testa, perplesso, e poi rispose:

E’ un brutto momento, non c’è lavoro e meno ce ne sarà in futuro; qui si parla che se continua questa bella abitudine che ha la gente di guidarsi la macchina da sé, la categoria degli autisti padronali dovrà scomparire…però, io sai che faccio? Ti mando dall’avvocato Moglie, che a suo tempo fu tanto buono con me. – Aggiunse che questo Moglie conosceva mezza Roma, che, se poteva un favore lo faceva e che, insomma, da cosa nasce cosa. Così dicendo, era andato alla cabina del garage e lì telefonò all’avvocato.

Il tram della circolare apparve, pieno zeppo dentro e con la gente appesa fuori sui predellini. Mi attaccai anch’io e così appeso, mi feci tutti i Lungoteveri fino a piazza Cavour. Arrivo, smonto, corro, salgo otto capi di scala in un palazzo signorile, suono, una cameriera mi fa entrare in una anticamera grande e bella, con due specchi incorniciati d’oro e due consolle di marmo giallo. Subito dopo l’avvocato si affacciò e mi invitò ad entrare dicendo:

– Sei fortunato, mi hai preso in tempo, stavo per andare in Tribunale. –

Era un uomo piccolo, con la faccia larga e gialla, e gli occhi neri come il carbone. Disse scartabellando non so che scartafaccio:

– Dunque, tu ti chiami Rondellini Luigi. –

Protestai con vivacità: – No, mi chiamo Cesarano Alfredo…ha telefonato per me Pollastrini… per una raccomandazione.. –

– E chi è Pollastrini?. –

Mi si annebbiò la vista e risposi con un fil di voce: – Pollastrini Giuseppe…l’autista delle signorine Condorelli.-

L’avvocato si mise a ridere, con un riso, per la verità, gentile, e disse:

– Ma sì certo… devi aver pazienza…lui ha telefonato e io gli ho parlato…tutto vero…ma sai com’è?… gli ho parlato e risposto con la mente ad altro, così che, quando ho buttato giù il telefono, mi sono domandato: ma chi era? Che ha detto? Che gli ho risposto? Ora tu sciogli il mistero: Dunque, se ben ricordo, Cesarano, tu vuoi una raccomandazione per diventare giardiniere al Comune? –

Continua la lettura

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2012/06/06/la-raccomandazione-e-il-gioco-delloca/.

[Security] OAuth: siamo noi ad autorizzare l’accesso ai nostri dati

Cosa accade quando sui social network, come Facebook o Twitter, diamo l’autorizzazione alle applicazioni di accedere ai nostri dati (profilo, info, foto, ecc.)? Semplicemente è come se gli lasciassimo la porta di casa aperta, senza chiuderla a chiave. Infatti, dietro viene utilizzato spesso un protocollo che è chiamato OAuth (open authorization) e di cui descrivo il flusso operativo, senza entrare troppo in dettagli tecnici.

Facebook ha già implementato il protocollo OAuth 2.0 e Twitter, fino a poco tempo fa, usava OAuth 1.0a (definito da RFC 5849). Comunque, il paradigma di autorizzazione è uguale per entrambe le versioni e riguarda lo scambio di informazioni (chiamato spesso “dance“) tra una applicazione client che necessita di accesso ad una risorsa protetta su un server provider e un utente finale (end-user), che ha bisogno di autorizzare l’accesso alle sue risorse protette a tale applicazione client (senza condividere username e password).

OAuth fornisce, dunque, un modo per autorizzare una applicazione ad accedere ai dati che sono stati memorizzati su un servizio online, senza fornire username e password personali. La specifica IETF OAuth 2.0 Protocol descrive il meccanismo di autorizzazione come segue:

  •  l’end-user autorizza l’accesso ad una applicazione (client) ad alcuni dati (scope) gestiti da un servizio web (resource owner)
  • Invece di chiedere le credenziali, il client ridireziona l’end-user verso il resource owner e l’end-user autorizza uno scope direttamente al resource owner: il client identifica se stesso con un client identified univoco e l’end-user lo autorizza;
  • assumendo che l’end-user abbia autorizzato il client, il client notifica e manda un authorization code di conferma all’end-user di avvenuta autorizzazione dello scope; c’è un problema: l’identificatore inviato dal client non è necessariamente segreto, dunque un client malintenzionato potrebbe avere fraudolentemente identificato se stesso e mascherarsi da client autorizzato (trusted publisher);
  • Il client presenta l’authorization code insieme al proprio identificativo e il corrispondente client secret al resource owner e riceve indietro un access token. La combinazione di client identifier, client secret e authorization code assicura che quel resource owner possa positivamente identificare il cliente e autorizzarlo. Questo access token può opzionalmente avere vita breve ed essere refreshato dal client.
  • il client usa l’access token per fare richieste fino a quando l’access token non viene revocato (dall’end-user) o scade.

OAuth permette, dunque, anche di revocare da parte di un end-user l’autorizzazione al client.

Continua la lettura

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