soggia lidia - e-Lite - Politecnico di Torino

Transcript

POLITECNICO DI TORINO
IV Facoltà di Organizzazione d’Impresa e
Ingegneria Gestionale
Laurea in Ingegneria dell’Organizzazione d’Impresa
Tesi di Laurea
Raccolta ed analisi di metadati per
pubblicità contestualizzata:
YouTube, un caso di studio
Relatore:
ing. Fulvio Corno
Tutore aziendale:
ing. Alberto Ciaramella
Candidata:
Lidia Soggia
Marzo 2010
INDICE
1. Introduzione: contesto generale ........................................................................... 1
1.1 Social media ....................................................................................................... 1
- Storia recente ...................................................................................................... 1
- Diffusione e potenzialità ..................................................................................... 3
- Problematiche: sovraccarico informativo .......................................................... 3
2. Contesto specifico ................................................................................................... 5
2.1 Il content based advertising................................................................................ 6
2.2 Il software TraceSense: la semantica per classificare automaticamente i
multimedia ................................................................................................................ 7
2.3 YouTube .............................................................................................................. 9
3. Obiettivi e requisiti della monografia ................................................................ 14
3.1 Obiettivi: ........................................................................................................... 14
- Realizzazione di un’applicazione per l’estrazione di dati da YouTube ............ 14
- Caratterizzazione della base dati ottenuta ....................................................... 14
3.2 Requisiti specifici.............................................................................................. 15
- Individuazione di un dataset reale per la validazione di TraceSense .............. 15
4. Tecnologie utilizzate ............................................................................................ 18
4.1 Strumenti di sviluppo per applicazioni web ..................................................... 18
- Java ................................................................................................................... 18
- Log4J: debug di applicazioni Java ................................................................... 19
- MySQL .............................................................................................................. 20
- AJAX ................................................................................................................. 20
- Servlet ............................................................................................................... 22
- JSON ................................................................................................................. 22
4.2 Web Services: API di Google in linguaggio Java ............................................ 23
5. Strategia di soluzione del problema ................................................................... 32
- Algoritmo utilizzato per estrarre dati dai web services .................................... 33
- Metodologia di spidering incrementale ............................................................ 35
- Interfaccia grafica come strumento di valutazione di TraceSense ................... 36
6. Caratterizzazione della base dati........................................................................ 40
6.1 Presentazione ed interpretazione dei risultati ottenuti dalle statistiche .......... 40
Percentuale del numero di video suddivisi per categoria ................................... 41
Statistiche su alcuni canali “ufficiali”................................................................ 42
Numero medio di video per utente ...................................................................... 44
Suddivisione in categorie dei video inseriti da ogni utente ................................ 44
Numero medio di tag per video e numero di video ............................................. 45
Numero di video suddivisi per anno di inserimento............................................ 46
Co-occorrenze ..................................................................................................... 47
6.2 prestazioni di database di grandi dimensioni .................................................. 49
Conclusioni ............................................................................................................... 51
APPENDICE ............................................................................................................ 54
Sitografia................................................................................................................... 58
1. Introduzione: contesto generale
1.1 Social media
- Storia recente
Sono lontani i tempi in cui il modo più usato per comunicare, in assoluto, era il
telefono. Si assiste oggi alla imperante diffusione dei social network. Questo nuovo
modo di comunicare si è diffuso inizialmente in ambiti informali, poichè ha
rappresentato da subito un legante innovativo tra persone situate da parti opposte nel
mondo, ma anche nella stessa via. Dopo un inizio poco strutturato, questo fenomeno
si è affermato anche in ambiti formali, dall’editoria, alla politica, ai settori scientifici.
La rapidità, economicità e le potenzialità di questi strumenti hanno contribuito a
segnare l’inizio del cosiddetto Web 2.0.
Il termine web 2.0, non comparso prima del 2003, è comunemente associato ad
applicazioni web usate per lo scambio interattivo di informazioni, la collaborazione,
la condivisione di esperienze e conoscenze all’interno di una community.
L’antenato di questa espressione è il Web 1.0, generalmente considerato statico, poco
reattivo ai cambiamenti, unidirezionale, con una gestione centralizzata.
Nel vasto panorama dei social media si distinguono strumenti come: social network
(Facebook, LinkedIn), microblog (Twitter), condivisione di file multimediali
(Youtube, Flickr), discussione (Skype, Yahoo Messenger), blog (MySpace), social
bookmarking (Delicious), wiki (Wikipedia) e molti altri (come raffigurato in
Figura1).
I siti web 2.0 permettono ai loro utenti di interagire con altri utenti o di cambiare i
contenuti del sito web, in contrasto con i siti non interattivi in cui gli utenti si
limitano ad una visualizzazione passiva delle informazioni che gli sono fornite.
Questo fenomeno è destinato a modificare radicalmente il mondo dell’informazione
e della conoscenza. Le informazioni, infatti, vengono costruite sempre più spesso in
modo bottom-up, a partire da contributi individuali di persone comuni, una modalità
opposta a quella tradizionale, definita top-down, in cui le informazioni sono diffuse
da poche fonti (a partire dall’alto).
Ne è conferma il fatto che la BBC ha creato all’interno delle sue redazioni la
posizione di social media editor, un redattore che si occupa specificamente del social
networking. Questa rappresenta una dimostrazione del maggiore impegno da parte
non solo della BBC, ma di molte altre compagnie, oltre che istituzioni, nell’apertura
verso i social media.
È importante evidenziare che questa rivoluzione è prettamente sociale, e non si
riferisce a nessun aggiornamento tecnico specifico, ma a cambiamenti cumulativi nel
1
modo in cui sviluppatori di software e utenti finali usano il web. Infatti, parlare dei
social media come strumenti completamente nuovi è fuorviante.
In realtà, sin dal principio Internet era popolata da chat rooms, forum, blog e
comunicazioni peer to peer. La rivoluzione sociale è rappresentata dal loro utilizzo di
massa, guidato dalle moderne piattaforme di social networking.
L’elemento di innovazione portato dal Web 2.0, indubbiamente più significativo nel
contesto della presente tesi, è il tagging. Consiste nell’attribuire uno o più tags
(parole chiave) ad una risorsa informativa, per descriverne il significato. Questo
procedimento è usato abitualmente per permettere di archiviare fotografie, video,
indirizzi internet e documenti, identificando velocemente l’argomento principale
della risorsa. L’argomento è individuato dal punto di vista degli utenti, senza
l’attribuzione a categorie predefinite, contrariamente ai classici metodi di
caratterizzazione di contenuti.
Figura 1. Panorama dei social media
Fonte: fredcavazza.net
L’uso esteso e sociale del tagging (il social tagging) costituisce una folksonomia,
ovvero un’organizzazione delle risorse costruita dal basso con modalità
emergente. Si oppone alla tassonomia che al contrario è costruita dall'alto attraverso
strutture non modificabili dall'utente.
La diffusione di questo metodo di caratterizzazione dei contenuti ha portato grandi
vantaggi per quanto riguarda l’innovazione del vocabolario. È infatti possibile che
vengano usati nuovi termini entrati nell’uso comune ma non ancora nei vocabolari,
oppure è ancora più semplice che nomi di persone divenute famose da poco tempo
siano usati ampiamente tra i tags. L’altro lato della medaglia è rappresentato
2
dall’eccessiva libertà nella scrittura dei tags. Molto spesso per esprimere lo stesso
significato si usano parole diverse, oppure anche le stesse parole ma con uno spelling
diverso (l’uso o meno del trattino nei nomi composti, errori di spelling, caratteri
speciali, ecc...).
Per cui, se da un lato viene privilegiato l’aggiornamento, dall’altro si genera il
problema della qualità dell’informazione, dovuto alla disomogeneità dei termini
usati.
- Diffusione e potenzialità
Il punto di forza dei social media è sicuramente la distribuzione capillare che hanno
avuto. Sono utilizzati da milioni di persone in tutto il mondo. È ampiamente risaputo
il loro effetto di propagazione delle notizie; è sufficiente, infatti, che un video o un
articolo siano inseriti in rete, perchè un meccanismo virale ne favorisca la diffusione
a macchia d’olio.
I social media si sono diffusi ovunque ci sia una connessione ad internet e,
probabilmente, dovrebbero essere presi in considerazione da tutte le compagnie
pubblicitarie, gli imprenditori e i produttori di contenuti come una parte
fondamentale delle loro comunicazioni. Il web social oriented è oggi, un’opportunità
interessante per molte compagnie, se condotta propriamente.
Le piattaforme tecnologiche devono essere considerate come un mezzo e non un fine,
nei confronti della nuova informazione prodotta e veicolata su internet. Non possono
sostituirsi ai giornali, ma possono avere delle straordinarie potenzialità
per contribuire a una più ampia diffusione dell'informazione a beneficio e vantaggio
della stessa stampa tradizionale. L'importante è trovare il meccanismo che possa
creare una relazione, anche in termini economici, che soddisfi sia chi produce
contenuti come business, sia chi ne usufruisce.
A questo proposito, alcune piattaforme si stanno occupando anche di monetizzare o
valorizzare economicamente i sottoscrittori del servizio, un esempio concreto è
YouTube, (di cui si tratterà più diffusamente nel paragrafo 2.3), che grazie ai
proventi ottenuti dall’inserimento di inserti pubblicitari nei video, remunera gli utenti
più popolari (quelli con più visualizzazioni e voti più alti).
- Problematiche: sovraccarico informativo
Un numero sempre crescente di persone si connettono ad Internet per condurre le
loro ricerche. Le possibilità sia di fruire che di produrre contenuti hanno fatto
crescere a dismisura il numero di siti web.
Questo ha portato alla oggettiva difficoltà di reperire l’informazione realmente utile,
tra una smisurata quantità di informazioni non attinenti a quelle cercate. Spesso i
motori di ricerca non sono in grado di disambiguare i diversi significati dei termini
ricercati. Tutto ciò conduce ad un onnipresente “rumore di fondo” rappresentato
dalle informazioni superflue tra le quali si è costretti a districarsi nel Web, che in
questo caso rappresenta una vera e propria ragnatela.
La ricerca di informazioni contestualizzate è spesso rallentata da strumenti come feed
RSS, e-mail, bookmarks, blog, ecc... Questa grande mole di informazioni, che più
3
passa il tempo, più si accresce a dismisura, genera troppa scelta. È una quantità
talmente vasta che non si riesce a gestire, se non impiegando moltissimo tempo.
È avvenuto un passaggio da un numero di informazioni notevole, ma accettabile,
fornite ogni 24 ore (i giornali), a una quantità di informazioni gigantesca, che
approda in tempo reale e con qualunque mezzo.
Si possono distinguere varie cause del sovraccarico informativo:
•
Un rapido tasso di incremento dell’informazione prodotta
•
La facilità di duplicazione e trasmissione dei dati su Internet
•
L’incremento di canali disponibili (es. telefono, e-mail, SMS, rss)
•
La presenza di informazioni obsolete tra cui cercare
•
Contraddizioni e inesattezze nell’informazione disponibile
•
La mancanza di un metodo per confrontare e processare diversi tipi di
informazioni
•
la progressiva trasformazione degli utenti da passivi ad attivi
Un’ ulteriore difficoltà può essere considerata la configurazione intricata con cui si
presentano molti siti. Una miriade di link tra cui scegliere, che compaiono sullo
schermo. In aggiunta, generalmente alle persone non piace dover scegliere, poichè
scegliere rallenta, fa perdere tempo, e lascia sempre il dubbio di aver preferito
l’opzione peggiore, senza considerare il fatto che non si può conoscere la validità di
molte informazioni. Sorge dunque, anche il rischio di disinformazione.
4
2. Contesto specifico
La crescita esponenziale delle applicazioni basate sugli utenti, come blog, sistemi di
social tagging e simili, ha sicuramente contribuito alla generazione di copiose
quantità di metadati non strutturati.
Per esplorare, analizzare ed interrogare queste raccolte di testi, anche molto vasti, in
continua evoluzione come forum, blog, newsgroup e interviste, si rendono
necessarie delle tecniche di ausilio alla ricerca.
Molti dei termini che vengono usati in questi contesti sono “moderni”, o gergali, o
nomi propri; parole non presenti nei vocabolari, ad esempio perchè sono entrate nel
lessico collettivo a seguito dell’uscita di un film (attori, registi) o in seguito
all’introduzione di un’innovazione, o un marchio commerciale, ecc...
Come accennato in precedenza, grazie al social tagging è possibile creare
un’organizzazione delle risorse costruita dal basso attraverso il contributo delle
persone, chiamata folksonomia.
In rete è quindi presente una grande fonte di sapere popolare che però è difficilmente
strutturabile, per la grande quantità e disomogeneità dei dati.
Sono attualmente in corso degli studi e dei progetti che si propongono di raccogliere
ed elaborare le informazioni presenti nei social media, poichè queste costituiscono
una sorta vocabolario “sociale”, ovvero il reale lessico usato dagli utenti del web.
Per poter strutturare questa immensa mole di informazioni è necessario effettuare
delle operazioni di data mining. Questo termine indica un processo automatico di
raccolta di dati, al fine di estrarre delle informazioni significative di conoscenza,
delle strutture e delle relazioni, chiamati pattern, attraverso degli algoritmi, da un
vasto insieme di dati.
L’uso di questi particolari algoritmi rende possibile utilizzare l’informazione a scopo
descrittivo o previsivo, per usarla come un valido strumento di supporto alle
decisioni.
Per cui, è possibile estrarre elementi di conoscenza a partire da dati privi di una
struttura, attraverso i quali si può pensare di costruire dei tesauri sempre aggiornati,
grazie al continuo apporto di informazioni recenti. Per tesauro si intende una lista di
termini tra i quali sono definite relazioni semantiche, come gerarchia, preferenza,
equivalenza.
Per fare un semplice esempio di come sia possibile attribuire queste relazioni, si può
considerare l'analisi delle co-occorrenze (la frequenza con cui coppie di termini
compaiono in un testo), che consente di studiare le associazioni tra parole,
individuando quelle parole che compaiono più spesso vicine tra loro. Questa analisi,
insieme a molte altre può essere utile alla disambiguazione del significato di alcuni
5
termini nel contesto in cui sono inseriti, e a tracciare una mappa concettuale tra
parole e temi affrontati.
I fattori principali che hanno contribuito allo sviluppo del data mining sono:
•
la grande quantità di dati accumulati in formato elettronico,
•
il basso costo dell’immagazzinamento di dati,
•
i nuovi metodi e tecniche di analisi (come apprendimento automatico,
riconoscimento di pattern).
Il data mining in ambito sociale è un settore in rapido sviluppo. Le interazioni tra gli
individui sono analizzate per conoscere e comprendere le innovazioni, le decisioni e
la risoluzione dei problemi in modo cooperativo. Si cerca anche di interpretare il
modo in cui la struttura delle organizzazioni impatta su questi processi.
Questo tipo di analisi sono attualmente applicate in numerose aree, ad esempio:
•
•
•
nell’e-commerce, per guidare i meccanismi di suggerimento agli acquisti
dalle forze dell’ordine, per comprendere la struttura delle organizzazioni
criminali e terroristiche
nella bibliometria, per analizzare i modelli di distribuzione delle
pubblicazioni scientifiche, per determinarne il loro impatto e l’influenza di
specifici individui
Altre applicazioni specifiche potrebbero riguardare:
•
•
•
•
•
•
•
•
l’individuazione di gruppi di acquirenti interessati ad un prodotto
commerciale e la loro profilazione per potere personalizzare le offerte per
ogni cliente
competitive intelligence: estrazione di documenti da banche dati
internazionali di tipo tecnico-scientifico per individuare le tecnologie
emergenti, le loro relazioni e l’evoluzione temporale
analisi testuale: individuare gli argomenti trattati da un insieme di documenti
e le relazioni che intercorrono tra gli argomenti. Si rivela particolarmente
utile quando si deve analizzare il contenuto di una collezione di documenti
provenienti da fonti eterogenee
apprendimento e analisi di folksonomie e altre strutture dati del Web 2.0
invio personalizzato di news
analisi di blog
previsione del comportamento degli utenti
esplorazione delle strutture sociali nelle community di utenti
2.1 Il content based advertising
Sono definiti content based advertising, o anche pubblicità contestualizzate, quei
messaggi promozionali presenti nelle pagine web, il cui contenuto è connesso a
quello della risorsa informativa a cui sono affiancati. L’obiettivo che si prefigge
questo sistema, è proporre la pubblicità più coerente con il contenuto della pagina
web.
6
Questo tipo di pubblicità si suddivide in due tipologie:
•
Search-based
La pubblicità è associata ai motori di ricerca, un esempio pratico potrebbe
essere rappresentato da una ricerca: digitando le parole “viaggio a Londra” su
un motore di ricerca si otterrebbero, accanto ai risultati, alcuni link
sponsorizzati riguardanti offerte di voli aerei dall’Italia a Londra.
•
Content-based
Questa pubblicità, è invece associata ai siti di contenuti. Proponendo un
esempio simile al precedente, si potrebbe pensare ad un sito, dedicato alle
attrazioni turistiche di Londra, che propone offerte a prezzi scontati di
compagnie aeree che coprono la tratta Italia-Inghilterra.
Alla base del successo della pubblicità contestuale c'è, nella maggior parte dei casi, la
tecnologia sviluppata dai grandi player del settore, quali Google (AdSense), Overture
(Content Match) e Sprinks (ContentSprinks), i quali hanno sviluppato software che,
sfruttando sofisticati algoritmi semantici, sono in grado di analizzare le parole chiave
presenti all'interno di una pagina Web (e la loro rilevanza), per proporre, di
conseguenza, il messaggio pubblicitario più appropriato al contesto, grazie
all’identificazione in modo automatico dell’argomento dei contenuti e del loro
significato. Il vantaggio della pubblicità contestuale, risiede dunque nel fatto che
presenta il messaggio di marketing proprio nel momento in cui l'utente dimostra un
attivo interesse a riceverlo.
L’approccio di queste tecnologie tende ad essere poco invasivo rispetto alla massa
dominante di messaggi promozionali (pop-up e pop-under) colorati, fluttuanti,
animati, sonori, ecc.. che popolano il Web da qualche anno a questa parte. Queste
inserzioni promozionali non sono appannaggio di grandi portali ma sono usate
comunemente soprattutto da quelli di piccole e medie dimensioni, che sfruttano
principalmente il programma AdSense di Google.
2.2 Il software TraceSense: la semantica per classificare
automaticamente i multimedia
Nell’ambito del content based advertising semantico si inserisce il progetto
TraceSense.
TraceSense è un’applicazione (preesistente allo sviluppo di questo lavoro),
sviluppata e brevettata da IntelliSemantic, che interpreta semanticamente e classifica
automaticamente video, foto, podcast o altri contenuti multimediali basandosi
sull’informazione testuale ad essi associata, ad esempio i tags indicati dall’autore o
dai visitatori.
Gli utenti dei fenomeni più popolari del cosiddetto Web 2.0, come YouTube, Flickr,
Delicious, Amazon, utilizzano queste etichette come parole chiave per descrivere i
contenuti che producono e condividono sul web. I tags generati dagli utenti
dovrebbero facilitare quindi la reperibilità delle risorse, tuttavia la libertà lasciata agli
7
utenti che generano i tags porta, insieme alla ricchezza dei molteplici punti di vista,
anche una notevole ambiguità impedendo il pieno riutilizzo di queste informazioni.
Il tirocinio su cui si basa la presente monografia è legato al software TraceSense, in
quanto si prefigge di creare una base dati per la validazione della suddetta
applicazione. Nonostante questo stretto legame, l’interazione con il programma è
stata esigua, fatta eccezione per la fase di testing iniziale del sito web dimostrativo
del software, in cui si è rivelato utile conoscere il funzionamento basilare
dell’algoritmo di interpretazione semantica.
Funzionamento e ambiti di utilizzo
TraceSense permette l’interpretazione e la classificazione semantica dei metadati
associati ai contenuti multimediali tramite un sistema di estrazione, riconoscimento
ed organizzazione degli stessi in domini di conoscenza.
Il software, interpretando tutti i tags utilizzati per descrivere una risorsa, la associa ad
una o più categorie target che ne indicano il significato prevalente, come ad esempio
‘Politica e Sport’, ‘Celebrità e Moda’, ‘Benessere’ e così via, in molteplici
combinazioni.
Le categorie target dipendono dal dominio dell’applicazione; pertanto diversi domini
avranno diverse categorie target costruite intorno a specifici sensi. In tal senso,
Tracesense può adattarsi a qualsiasi dominio della conoscenza.
TraceSense potrebbe essere impiegato in un’ampia gamma di utilizzazioni. Viene di
seguito proposto qualche esempio.
•
TraceSense, classificando i contenuti secondo argomenti specifici, può
fornire in modo totalmente automatico ai media planner indicazioni preziose
per associare la pubblicità adatta ad un determinato target-audience con
sofisticate possibilità di segmentazione del mercato
•
TraceSense potrebbe coadiuvare il lavoro di produttori e distributori di
contenuti multimediali, per classificare l’enorme mole di prodotti immateriali
veicolati, ottenendo in automatico la loro organizzazione, utile per fornire
contenuti adatti ad un certo target o profilare il target secondo specifiche
preferenze
•
TraceSense potrebbe supportare l’auto-organizzazione dei social network
mettendo in relazione persone con interessi comuni
Attualmente l’applicazione funziona con tags in lingua inglese, ma a seconda degli
ambiti di utilizzo è possibile la sua personalizzazione rispetto a categorie o nuovi
sensi che si desiderano individuare.
IntelliSemantic
IntelliSemantic è stata fondata nel 2005. Dal 2005 al 2007 è stata ospitata dall’I3p,
incubatore delle imprese innovative del Politecnico di Torino.
Il core business dell’azienda è concentrato sulla produzione e fornitura di strumenti
per semplificare la ricerca, la navigazione e il ri-utilizzo dell’informazione e della
8
documentazione, a tutti coloro che considerano le basi di dati e le informazioni una
risorsa strategica. I prodotti sono principalmente studiati per aziende, information
provider, studi professionali e società di e-commerce, in un’ottica di sfruttamento
delle potenzialità delle applicazioni web, quali portali, knowledge management
systems e sistemi di business intelligence.
L’azienda si avvale di tecnologie relative alla web search e database search,
conoscenze delle metodologie per la costruzione di ontologie e applicazioni
semantiche, capacità nell’implementazione e integrazione dei web service, e
nell’analisi funzionale, conoscenza dei principi di progettazione basata sull’utente e
dei modelli di e-business.
Fin dalla costituzione della società, IntelliSemantic collabora attivamente nel campo
del web semantico con il gruppo e-Lite del Politecnico di Torino, la cui attività di
ricerca è riconosciuta a livello internazionale.
2.3 YouTube
YouTube è un portale internet di video sharing in cui gli utenti possono guardare,
caricare e condividere video. La compagnia ha sede a San Bruno, in California ed è
stata fondata nel 2005 da tre giovani impiegati di PayPal; Chad Hurley, Steve Chen e
Jawed Karim.
YouTube è l’indiscusso leader dei video online. Utilizza Adobe Flash Video, come
tecnologia per la visualizzazione di una grande varietà di contenuti video generati dai
suoi utenti, tra cui film, spezzoni televisivi, video musicali e video blog. La maggior
parte dei contenuti sono caricati dai singoli utenti, ma sono presenti anche media
importanti come CBS, BBC, Universal Music Group, Sony Music Group e altre
organizzazioni che offrono parte del loro materiale online, all’interno del
programma ‘partnership’ di YouTube (esposto nel seguito del paragrafo).
Nel novembre del 2006, ad un anno dal suo lancio, YouTube è stato acquistato da
Google per 1.65 bilioni di dollari.
Alcune aziende televisive hanno intentato cause contro Google per impedire
all’azienda di continuare a guadagnare denaro dalla pubblicazione di video protetti
da copyright. Il risultato di queste azioni legali è stato l’ordine alla compagnia di
rimuovere più di 100.000 clip dalla rete. A seguito di queste azioni, Youtube ha
sviluppato un servizio chiamato “Youtube Video Identification” che permette di
aiutare i detentori di copyright a proteggere i propri contenuti. Complessi algoritmi
sono applicati alla libreria di clip di Youtube per verificare se qualcuno corrisponde a
quelli protetti da copyright, al fine di ridurre le violazioni. A fine 2008, YouTube ha
raggiunto un accordo con MGM, Lions Gate Entertainment e CBS che permette alle
compagnie di caricare film e show televisivi sul sito, accompagnate dalla pubblicità.
YouTube ha inoltre intrapreso un programma chiamato “Partners Program” (nel
maggio del 2007) che consiste nella retribuzione degli utenti più popolari sul portale,
grazie ai proventi della pubblicità aggiunta da Google AdSense sui video. È stato
quindi il primo social network a consentire agli utenti di guadagnare, ad alcuni
persino migliaia di dollari al mese.
9
Alcuni paesi hanno bloccato l’accesso a YouTube; come la Repubblica Popolare
Cinese, il Marocco, Thailandia e altri paesi, spinti dal timore di non poter controllare
l’afflusso di notizie nel proprio paese.
Statistiche sull’analisi del traffico
La quantità di visitatori del sito è sicuramente sbalorditiva; di seguito si riportano
alcune stime (figura 2) sul numero di visitatori (su base mensile) provenienti dagli
USA.
In figura 3 sono fornite anche stime più ampie, che mostrano chiaramente il rapido
incremento della numerosità di visitatori. Le stime iniziali risalenti all’aprile 2007
sono di circa 57 milioni, mentre quelle di due anni dopo (aprile 2009) si aggirano sui
70-80 milioni. Quindi l’incremento raggiunto è del 30% in due anni.
Queste sono solo stime, e non dati misurati direttamente, bisogna perciò tener conto
dei loro limiti. Ciò nonostante si può affermare che il successo di questo notissimo
sito è il frutto del contributo dei singoli individui sommato, sicuramente, anche alla
redditività di alcuni contenuti che violano di fatto le norme sul copyright (a cui
perlomeno la compagnia sta cercando di porre rimedio con alcune azioni come quelle
descritte precedentemente).
Figura 2. Visitatori mensili Youtube (USA) dal 05/07/09 al 31/12/09.
Fonte: quantcast.com
A tutto questo si aggiunge ovviamente il contributo di Google AdSense, che offrendo
la possibilità di guadagno agli utenti, ne ha incrementato maggiormente lo spirito di
iniziativa, in un’ottica di miglioramento dei contenuti dei propri canali e soprattutto
di numerosità dei video per ogni utente (ogni utente può caricare un numero
10
illimitato di video). Si può infatti notare nella figura 3 come nell’estate del 2007 (in
seguito all’introduzione del programma Partnership) il numero di visitatori sia
aumentato in maniera quasi esponenziale, segno che un giusto equilibrio, anche
economico, tra creatori del servizio di video sharing, e i sottoscrittori, porta a
vantaggi per entrambe le parti. Maggior visibilità per il sito, ed anche un guadagno
per gli utenti attivi. La grande varietà di temi trattati e la possibilità di accedere
semplicemente e gratuitamente a contenuti su argomenti di nicchia, hanno concorso
allo sviluppo di questo grande successo. Grazie alla sua grande popolarità YouTube
ha condotto il video sharing a rappresentare un elemento fondamentale della cultura
internet.
Figura 3. Visitatori mensili Youtube (USA) dal 04/03/07 al 31/12/09.
Fonte: quantcast.com
YouTube è stato riconosciuto come il quarto sito web più frequentato al mondo,
dopo Google, Yahoo! e Facebook.
Viene proposto qualche numero statistico significativo:
•
#1 sito di video più visto sul web
•
#4 sito internet più frequentato
•
300 milioni di visitatori mondiali al mese
•
15 ore di video caricati ogni minuto
•
Tre quarti del materiale proviene dal di fuori degli Stati Uniti
•
La durata media dei video online è di 3.5 minuti
•
Il 77% degli utenti che accedono per guardare un video continuano a
guardarne molti di più
11
Il sito stesso è ottimizzato per catturare l’attenzione dell’utente e indurlo a guardare
più video possibile, grazie soprattutto alla presenza in ogni video di altri video
correlati per argomento. Il concetto sostanziale è quello di avere il pieno controllo su
una televisione completamente gratuita.
Tabella 1. Proprietà dei video, gennaio 2009 (in base al numero di video visti da utenti USA)
Fonte: comScore Video Metrix
Proprietà
Video (000)
Percentuale
di video (%)
14.831.607
100,0
6.367.638
42,9
Fox interactive Media
551.991
3,7
Yahoo!
374.161
2,5
Viacom Digital
287.615
1,9
Microsoft
267.475
1,8
HULU.com
250.473
1,7
Turner Network
195.983
1,3
AOL LLC
184.808
1,2
Disney Online
141.452
1,0
MEGAVIDEO.COM
102.857
0,7
Totale Internet
Youtube
API
Un’altra grande opportunità offerta da Google, e conseguentemente da YouTube,
sono le API.
Le API, acronimo di ‘application programming interface’ permettono di interagire
con dei web services.
Nel caso di YouTube offrono la possibilità di integrare nel proprio sito personale
molte delle funzionalità offerte dal portale, come la visualizzazione di video con
un’interfaccia personalizzata e, funzionalità più rilevante per lo svolgimento di
questa monografia, l’accesso al database di contenuti. La disponibilità di contenuti
offerta non è ovviamente illimitata, questo aspetto verrà analizzato, in seguito, nel
paragrafo 4.2.
Queste possibilità sono riservate a programmatori ed appassionati di informatica, e
non a qualsiasi utente della rete, in quanto si tratta di gestire e modificare del codice
in linguaggi di programmazione (come Java, .NET, PHP o Phyton), e non
semplicemente di copiare e incollare del codice su un sito web o un blog.
12
Ovviamente il colosso statunitense non ha fornito le API per mero altruismo, ma
perchè è sua intenzione (o speranza) confidare nella creatività degli sviluppatori, da
cui si attende qualcosa che sia fruibile da molte persone. Per cui, questa decisione di
rendere più aperto il portale video non è dettata da uno slancio di generosità ma dalla
volontà che ogni video caricato su Internet sia di loro proprietà, in un’ottica di
raggiungimento dell’egemonia totale del settore.
13
3. Obiettivi e requisiti della monografia
3.1 Obiettivi:
- Realizzazione di un’applicazione per l’estrazione di dati da YouTube
L’obiettivo principale che ci si è proposti di raggiungere è stato creare un database
che contenesse metadati relativi ad alcuni contenuti multimediali. Pertanto si è
presentato il problema di trovare una modalità per la creazione di questa base dati.
I contenuti multimediali a cui si è deciso di attingere sono quelli contenuti nei portali
web, che non sono ovviamente distribuiti gratuitamente ai fruitori del servizio.
Vengono però talvolta messe a disposizione delle interfaccie attraverso le quali è
possibile richiedere delle piccole porzioni dei loro contenuti. Per cui si è scelto di
servirsi di una metodologia di spidering incrementale, poichè non è possibile
accedere a tutte le informazioni desiderate, scaricandole “in blocco”. È necessario
interfacciarsi con questi portali, attraverso le loro API, con applicazioni che non
funzionino per un tempo infinito, ma che compiano cicli di start/stop per tenere
traccia delle informazioni che hanno già preso in considerazione.
Questo problema, che può essere applicato a diversi portali web, in questa sede è
stato applicato al caso specifico di contenuti video.
Il primo posto che viene in mente se si cerca un vasto insieme di video non può che
essere Youtube, per cui ci si è indirizzati verso questo famoso portale di contenuti
video. In YouTube, ad ogni video sono associati dei tags (parole) di identificazione
del contenuto. Sono proprio questi tags che vengono “dati in pasto” all’algoritmo
TraceSense come dati di input.
L’output atteso è una classificazione nelle categorie considerate maggiormente
inerenti all’argomento del video. Inizialmente ci si è riferiti alla “Reference guide”
delle API di Youtube, nella quale sono contenuti alcuni esempi di applicazioni Java
per l’interrogazione dei web services. Sulla base di questi esempi si è è preso spunto
per iniziare a scrivere il codice per l’applicazione di nostro interesse.
- Caratterizzazione della base dati ottenuta
Una fase molto importante è stata quella di caratterizzazione della base dati ottenuta.
L’intento era capire che tipo di dati vi erano contenuti; ad esempio se il campione di
dati era stato estratto in modo omogeneo per categoria, la distribuzione del numero di
tags trovati per ogni categoria, quanti video dello stesso utente erano stati presi,
quanti di questi video appartenevano a canali “ufficiali”. Per i dati ottenuti si veda il
paragrafo 6.1.
Inoltre sono state fatte delle statistiche sulle co-occorrenze (tutte le possibili coppie
di tags presenti in ogni video). Queste possono essere usate per fare il tuning (o
taratura) del dizionario. Ovvero, qualora si decidesse di rendere l’algoritmo più
14
specialistico in un qualche settore di interesse, si potrebbero analizzare le cooccorrenze della categoria più affine a questo settore, ed aumentare la focalizzazione
del dizionario usato dall’algoritmo sulle co-occorrenze più frequenti.
Un secondo passo è stato quello di interpretare i risultati osservati in queste
statistiche tramite un’analisi critica.
3.2 Requisiti specifici
Gli obbiettivi principali che si è prestabilito di raggiungere, e comuni allo sviluppo di
applicazioni basate su social media, sono:
•
•
un database di metadati relativi ai video
una metodologia di estrazione del database
Questi due obiettivi sono stati realizzati, nel caso specifico, per interagire con il
software TraceSense. Sono stati infatti utili come supporto al testing di questa
applicazione, presentata nel paragrafo 2.2.
- Individuazione di un dataset reale per la validazione di TraceSense
Nel contesto del content based advertising si inserisce il progetto TraceSense,
realizzato da IntelliSemantic in collaborazione con il Politecnico di Torino, il cui
obiettivo è estrapolare il contenuto da una risorsa telematica attraverso una sua
descrizione, ovvero tramite i suoi tags.
Come è noto la realizzazione di un software, passa attraverso diverse fasi. Il primo
passo consiste nell’analisi dei requisiti e delle funzionalità che il programma dovrà
rendere disponibili. Si passa quindi alla definizione della base dati e alla
progettazione degli algoritmi necessari. Terminate queste attività è possibile iniziare
con la fase di implementazione che, finalmente, comporta la scrittura del codice
sorgente. L’ultima fase, ma non per questo meno importante, è quella del testing e
del tuning dell’applicativo realizzato.
Poichè, allo stato attuale, lo sviluppo di TraceSense si trova in uno stadio stabile, la
maggior parte del lavoro dei suoi sviluppatori si concentra proprio sulle attività di
test e di messa a punto.
È di fondamentale importanza non confondere l’attività di debugging del software
con quella di testing.
Il debugging, in genere, viene svolto contestualmente allo sviluppo del codice
sorgente, in modo da individuare quanto prima i difetti (bug) che inficiano il buon
funzionamento dell’applicazione. Per rendere più agevole il debugging (si pensi ad
esempio che durante le fasi di sviluppo non tutte le funzionalità richieste sono ancora
disponibili), i dati utilizzati non sono dati reali bensì dati di prova.
Non sono rari i casi in cui, al fine di testare un determinato comportamento
dell’applicazione, lo sviluppatore che sta eseguendo il debugging abbia la necessità
di inserire dati creati ‘ad hoc’, spesso molto differenti dai dati che potrebbe estrarre
da un ambiente reale.
15
Lo scopo del testing, a differenza del debugging, è quello di collaudare
l’applicazione nella sua interezza e di verificarne il funzionamento in un ambiente
reale. L’ottica in cui viene svolta tale attività è quindi molto più vicina a quella che
sarà l’esperienza dell’utente finale. È di fondamentale importanza, per tale motivo,
utilizzare un dataset di buona qualità, quanto più possibile variegato e voluminoso.
Così facendo risulta più semplice rendersi conto e venire a capo di eventuali criticità
che difficilmente si sarebbero potute notare in fase di debugging.
Nel caso di TraceSense, poichè è un’applicazione basata su algoritmi semantici, la
qualità dei dati utilizzati nel testing, non solo è più importante che in altri casi, ma è
addirittura fondamentale per verificare il buon funzionamento del software. Per
questo motivo il primo requisito alla base del presente lavoro è stato l’individuazione
di un dataset reale che rendesse quanto più possibile agevole la validazione di
TraceSence.
Fase 1
Gli sviluppatori di TraceSense hanno focalizzato la loro attenzione
sull’identificazione del contenuto di video. Dopo aver sviluppato l’algoritmo che si
occupa della classificazione semantica di un gruppo di tags, si è passati alla fase di
test.
Sono stati effettuato dei test per verificare il comportamento dell’algoritmo su alcuni
video di prova, estratti dal sito internet YouTube. I test sono stati svolti tramite la
visione dei video e la loro classificazione manuale da parte di una persona, che
assegnava ad ognuno una categoria target, senza essere influenzata da nessun
elemento diverso dal video stesso. Le classificazioni assegnate manualmente ad ogni
video sono state poi confrontate con la classificazione elaborata dall’algoritmo. I test
fatti sono stati finalizzati al confronto tra la classificazione fornita da TraceSense e
l’argomento effettivamente identificativo del video, indipendentemente dalla
categoria con cui l’autore del video lo ha classificato al momento della
pubblicazione.
Si è pertanto reso necessario avere a disposizione un database più vasto (e di
conseguenza più variegato dal punto di vista delle tematiche dei contenuti) per poter
valutare il funzionamento dell’algoritmo su un range più esteso di tipologie di
argomenti.
Fase 2
In secondo luogo è sorta la necessità di creare un sito web dimostrativo (chiamato
“Video Content Discovery Demo”) delle funzionalità del sopraccitato algoritmo. Il
sito web è stato ideato per rendere possibile ad un qualsiasi utente di utilizzare
l’algoritmo in modo completamente trasparente, senza doverne conoscere il
procedimento operativo. L’utente, non deve infatti far altro che scegliere un video di
suo interesse tra una “vetrina” di video proposti, a quel punto può guardare il video
ed inoltre ha a disposizione le categorie (ordinate secondo la percentuale di
rilevanza) che sono state determinate per quel video dall’algoritmo.
16
La realizzazione dell’interfaccia grafica del sito web Video Content Discovery Demo
ha comportato inizialmente un’analisi delle funzionalità che si volevano mettere a
disposizione degli utenti, e dell’organizzazione operativa del sito web.
L’accessibilità non è rivolta al grande pubblico, ma solamente a chi ne fa richiesta a
IntelliSemantic, che fornisce, di conseguenza, alle persone interessate username e
password. Questa scelta è stata fatta per permettere l’accesso solamente a chi è
realmente interessato al progetto.
Ovviamente, prima di essere rilasciata, questa demo è servita come utile strumento di
test interno all’azienda, poichè permette di utilizzare in modo più semplice e veloce
l’applicazione TraceSense.
Il fine ultimo di questo dimostrativo è permettere ai soggetti interessati al progetto
Tracesense di potervi interagire, valutarne le potenzialità e proporre nuove idee per
sue future specializzazioni rispetto ad argomenti più ristretti, rispetto a quelli
contenuti nel più grande portale di video esistente, così da incanalare questo progetto
in applicazioni focalizzate su specifici domini della conoscenza.
Fase 3
Come ultimo intento si è voluto caratterizzare la base dati ottenuta nella Fase 1. La
metodologia di popolamento del database non assicura infatti una copertura
omogenea (da un punto di vista degli argomenti oggetto dei contenuti) di tutti i video
presenti su Youtube. Difatti il portale non fornisce la possibilità di accedere
globalmente ai dati. Effettivamente non sarebbe una politica molto conveniente per
l’azienda permettere a qualche altro concorrente di avere una copia di tutti i loro
contenuti. Il portale offre solamente l’acceso a piccole porzioni di dati, pochi video,
per volta.
Per conoscere la tipologia di dati estratti si rende pertanto utile eseguire delle
statistiche che mettano a conoscenza non solo dei dati che si posseggono, ma che
fungano anche da specchio dell’enorme contenuto di YouTube. Ci viene data quindi
la possibilità di osservare come dallo spioncino di una porta, una piccola parte di
quel grande universo che è YouTube.
17
4. Tecnologie utilizzate
Per sviluppare i requisiti esposti nel capitolo 3 è stata realizzata un’idonea
applicazione per l’interazione con i web services di YouTube. L’applicazione è
basata sul linguaggio Java e fa largo uso delle YouTube API. Per la realizzazione del
sito web si è fatto uso della tecnologia Ajax.
Pertanto, nel seguito di questo capitolo verranno illustrati brevemente i principali
strumenti usati per lo sviluppo di applicazioni web, mentre una sezione più ampia
verrà dedicata alle YouTube API.
4.1 Strumenti di sviluppo per applicazioni web
- Java
Java è un linguaggio di programmazione orientato agli oggetti. La piattaforma di
programmazione Java è fondata sul linguaggio stesso, sulla Macchina virtuale Java
(Java Virtual Machine o JVM) e sulle API Java. Java è un marchio registrato di Sun
Microsystems.
Le principali caratteristiche di Java sono:
1. essere completamente orientato agli oggetti
2. essere indipendente dalla piattaforma
Per facilitare il passaggio a Java ai programmatori old-fashioned, legati in particolare
a linguaggi come il C, la sintassi di base (strutture di controllo, operatori e così via) è
stata mantenuta pressoché identica a quella del C.
L'idea alla base della programmazione orientata agli oggetti è di rappresentare, nella
progettazione del software, le entità reali o astratte che compongono il problema
sotto forma di oggetti. Gli oggetti sono caratterizzati da proprietà (definite variabili o
attributi) e da metodi applicabili sugli oggetti stessi, che possono ad esempio
modificarne lo stato o estrarne informazioni.
L'ereditarietà in Java è implementata mediante la parola chiave ‘extends’, applicata
nella dichiarazione di una classe. Ad esempio una classe Quadrilatero può definire
alcuni comportamenti generali per tutte le figure geometriche con 4 lati, tuttavia si
può presentare la necessità di aver bisogno di caratteristiche più specifiche per i
nostri oggetti, quindi si creerà una classe Quadrato che estende la classe Quadrilatero
da cui deriva tutti gli attributi e tutti i comportamenti (i metodi).
Come ambiente di sviluppo, durante il tirocinio, si è utilizzata la piattaforma Eclipse,
con cui è possibile programmare in Java, usufruendo di comode funzioni di aiuto
quali: completamento automatico, suggerimento dei tipi di parametri dei metodi,
18
possibilità di accesso diretto a CVS e riscrittura automatica del codice (funzionalità
questa detta di refactoring) in caso di cambiamenti nelle classi.
- Log4J: debug di applicazioni Java
Log4j è una libreria java, che permette di utilizzare il meccanismo dei log all'interno
di un’applicazione in modo semplice, ma potente. È distribuita sotto licenza della
Apache Fundation ed è completamente open source, anche grazie a questo è divenuta
il più popolare sistema di logging tra gli sviluppatori Java.
Durante il ciclo di sviluppo, test e utilizzo di un componente software, è importante
controllare, a vario livello, il funzionamento dello stesso, per cui risulta utile avere
uno strumento che permetta di sapere, in un determinato istante, in quale stato è il
sistema o, per esempio, quale è il valore di una specifica variabile.
Il fattore probabilmente più importante di Log4j è la capacità di configurare e
modificare dinamicamente il comportamento del sistema di log semplicemente
modificando un file di configurazione esterno all’applicazione, senza la necessità di
riscrivere o ricompilare il codice.
In generale, durante lo sviluppo e il test è utile essere informati sull’intero flusso
applicativo, mentre quando il sistema è stato completamente messo in produzione, è
opportuno monitorare solamente gli eventi più gravi ed imprevisti (le eccezioni o i
fatal error).
Per questo motivo Log4j offre la possibilità di attivare o disattivare, comodamente, il
log dei messaggi.
Combinando questa funzionalità con la possibilità di redirigere in modo dinamico e
composito messaggi verso una o più destinazione appare chiaro quanto sia potente
questo strumento.
Ci sono vari livelli, a cui corrisponde la soglia massima entro cui vengono filtrate le
richieste di log, che vengono presentati di seguito, in ordine decrescente di severità:
•
•
•
•
•
•
•
FATAL: è un livello usato molto raramente e indica errori gravi come il
‘crash’ dell’applicazione
ERROR: è il livello che solitamente è associato alle eccezioni di Java. In
questo livello rientrano gli errori che non creano il ‘crash’ dell’intera
applicazione
WARN: è il livello che indica problemi di minore gravità come la mancanza
o l’inconsistenza di parametri di input. In generale si associano i messaggi di
warning di Java
INFO: è associato agli eventi significativi nel ciclo di esecuzione
dell’applicazione. Solitamente è usato per segnalare eventi di esecuzione
(esempio: startup/shutdown), che devono essere segnalati ma poi non
memorizzati per tanto tempo
DEBUG: è associato agli eventi che accadono in maniera meno frequente ma
comunque utili per eventuali fasi di debugging. È quindi comunemente usato
nella fase di debug del programma
TRACE: Registra alcune informazioni dettagliate. È stato aggiunto nella
versione 1.2.12
ALL: disattiva il tutti i filtri
19
• OFF: disabilita LOG4j
Per fare un esempio, se si sceglie di mettere come soglia il livello INFO, verranno
disabilitate tutte le richieste di DEBUG. È anche possibile implementare nuovi livelli
personalizzati ma, in genere, sono sufficienti quelli preimpostati.
Mentre con i sistemi tradizionali c’è la possibilità di effettuare il logging solo verso
la console, con Log4j le destinazioni (o appender) possono essere molteplici, come
ad esempio la console dell’applicazione, un file e altro ancora.
- MySQL
Come database si è fatto uso di MySQL, che è un relational database management
system (RDBMS) open source, composto da un client con interfaccia a caratteri e un
server. La versione utilizzata è quella attualmente stabile, la 5.1.
Il codice di MySQL è stato sviluppato fin dal 1979 dalla ditta TcX ataconsult, adesso
MySQL AB, ma è solo dal 1996 che è stata distribuita una versione che supporta
SQL. Essendo scritto in linguaggio C e C++, MySQL è disponibile su molti
differenti sistemi operativi.
Infine, il linguaggio SQL di MySQL comprende numerose estensioni che sono
tipiche di altri DBMS, quali PostgreSQL, Oracle e Sybase. In questo modo le query
non standard scritte per altri DBMS in alcuni casi funzionano senza problemi.
Nello svolgimento del tirocinio sono stati utilizzati altri due validi strumenti grafici
forniti da MySQL; MySQL Administrator per l’amministrazione del database, e
MySQL Query Browser per la creazione e l’esecuzione delle query.
Un altro dei programmi più popolari per amministrare i database MySQL è
phpMyAdmin (richiede un server web come Apache HTTP Server ed il supporto del
linguaggio PHP). Si può utilizzare facilmente tramite un qualsiasi browser.
- AJAX
AJAX, acronimo di Asynchronous JavaScript and XML, è una tecnica di sviluppo
per la realizzazione di applicazioni web interattive. Ajax non è una tecnologia
individuale, quanto invece un gruppo di tecnologie utilizzate insieme. Lo sviluppo di
applicazioni HTML con Ajax si basa su uno scambio di dati in background fra web
browser e server, che consente l'aggiornamento dinamico di una pagina web senza
esplicito ricaricamento da parte dell'utente. Ajax è asincrono nel senso che i dati
extra sono richiesti al server e caricati in background senza interferire con il
comportamento della pagina esistente. Normalmente le funzioni richiamate sono
scritte con il linguaggio JavaScript. Tuttavia, e a dispetto del nome, l'uso di
JavaScript e di XML non è obbligatorio.
La tecnica Ajax utilizza una combinazione di:
•
HTML (o XHTML) e CSS per il markup e lo stile;
•
DOM (Document Object Model) manipolato attraverso un linguaggio come
JavaScript o JScript per mostrare le informazioni ed interagirvi;
•
l'oggetto ‘XMLHttpRequest’ per l'interscambio asincrono dei dati tra il
browser dell'utente e il web server;
20
•
in genere viene usato XML come formato di scambio dei dati, anche se di
fatto qualunque formato può essere utilizzato, incluso testo semplice, HTML
preformattato, JSON.
Confronto con applicazioni tradizionali
Le applicazioni web tradizionali consentono agli utenti di compilare moduli e,
quando questi moduli vengono inviati, viene inviata una richiesta al web-server. Il
web server agisce in base a ciò che è stato trasmesso dal modulo e risponde
bloccando o mostrando una nuova pagina. Poichè molto codice HTML della prima
pagina è identico a quello della seconda, viene sprecata moltissima banda. Dato che
una richiesta fatta al web server deve essere trasmessa su ogni interazione con
l'applicazione, il tempo di reazione dell'applicazione dipende dal tempo di reazione
del web server. Questo comporta una maggiore lentezza dell'interfaccia utente.
Le applicazioni Ajax, d'altra parte, possono inviare richieste al web server per
ottenere solo i dati che sono necessari. Come risultato si ottengono applicazioni più
veloci (dato che la quantità di dati interscambiati fra il browser ed il server si riduce).
Anche il tempo di elaborazione da parte del web server si riduce poiché la maggior
parte dei dati della richiesta sono già stati elaborati. Inoltre, per il corretto
funzionamento di Ajax è richiesto che nel client sia attivato Javascript.
Il grande vantaggio di usare Ajax è la grande velocità alla quale un'applicazione
risponde agli input dell'utente.
Nella seguente immagine (figura 4) è presentata una schematizzazione del modo in
cui un'applicazione web tradizionale elabora l'interazione dell'utente sulla sinistra, e
sulla destra viene presentato il modo usato da un’applicazione Ajax.
Figura 4. Confronto nell'elaborazione dell'informazione tra modelli di applicazioni web tradizionali e applicazioni web
Ajax. Fonte: adaptivepath.com
21
- Servlet
La parola servlet deriva da una precedente, applet, che si riferisce a piccoli
programmi scritti in linguaggio Java che si eseguono all'interno di un browser. Per
contrapposizione, una servlet è un programma che si esegue in un server web. L'uso
più frequente delle servlet è generare pagine web in forma dinamica a seconda dei
parametri della richiesta spedita dal browser.
Una servlet è un programma, che risiede su un server, in grado di gestire le richieste
HTTP generate da uno o più client, rispettando determinate regole. Tipicamente le
servlet sono collocate all’interno di Application Server o Web Application Server
come, ad esempio, Tomcat.
All'interno dello stesso server web possono funzionare più servlet associate ad URL
diversi; ognuna di queste servlet può fare elaborazioni diverse ed estenderà le
funzionalità del server web.
Un esempio pratico di utilizzo potrebbe essere un meccanismo di riconoscimento
dell’utente. Digitando un URL viene invocata una servlet, che verifica la correttezza
dei dati inseriti e successivamente indirizza ad una pagina di conferma o di errore, a
seconda del risultato.
È possibile costruire una servlet scrivendo una classe Java (come è stato fatto per la
realizzazione del sito Video Content Discovery Demo) che erediti le caratteristiche
della classe ‘HttpServlet’. Questa può essere richiamata da una pagina Jsp per
effettuare lavori come calcoli, ricerche, elaborazioni di vario genere.
- JSON
Acronimo di JavaScript Object Notation, il JSON è un formato adatto per lo scambio
dei dati in applicazioni client-server. Viene solitamente usato in AJAX come
alternativa a XML. La sua semplicità d’uso ne ha decretato un diffuso utilizzo.
Un esempio di JSON
Viene qui proposto un esempio di utilizzo di JSON all’interno della demo di
TraceSense, per illustrare la strutturazione dei dati. I dati sono composti da una lista
di 2 video (‘videolist’). Per ogni video nella lista sono indicati i dati relativi, come id,
titolo, link all’immagine thumbnail, ed altri.
{
"videolist":[
{"id": "AFtnPrM5iGs",
"title": "SBK 2009 - Portimao Race 1",
"thumb": "http://i1.ytimg.com/vi/LkKQ3wnhZtQ/default.jpg",
"tags": "sbk,
biaggi",
superbike,
portimao,
spies,
haga,
rea,
"description": "SBK 2009 - Portimao Race 1 Highlights",
"category": "Sport"},
22
{"id": "Rc9073pxyzk",
"title": "Digger Phelps Dancing Clemson Official HD",
"thumb": "http://i3.ytimg.com/vi/n94UOSiTbbc/default.jpg",
"tags": "Digger,
Gameday",
Phelps,
Dancing,
Clemson,
ESPN,
"description": "Digger Phelps Dancing at Clemson on ESPN
college gameday.",
"category": "Sport"}
]
}
Confronto con XML e altri linguaggi di markup
XML è un linguaggio di marcatura dalle proprietà mentre JSON non lo è: JSON è un
formato di interscambio di dati. JSON viene considerato più semplice di XML,
perchè ha meno grammatica e riesce più rapidamente, a delineare uno schema della
struttura dati usata nei moderni linguaggi di programmazione. JSON non è
estensibile, e non ha bisogno di definizione di nuovi tags o attibuti per rappresentare i
dati, perchè non è un linguaggio di markup dei dati.
4.2 Web Services: API di Google in linguaggio Java
Le API di YouTube forniscono liste di video, chiamate ‘video feeds’ in base ai
parametri scelti nelle richieste. Molti feeds consistono in una serie di ‘video entries’
(dati relativi ad ogni video). Dunque, le API restituiscono degli oggetti ‘VideoFeed’,
che sono un insieme di oggetti ‘VideoEntry’. Ogni ‘video entry’ corrisponde
esattamente ad un video e contiene le informazioni su quel video.
Estrarre una video entry specifica
Ogni entry presente in un feed contiene un link, che identifica la URL corrispondente
al feed di informazioni su quel particolare video. La URL ha il seguente formato:
http://gdata.youtube.com/feeds/api/videos/videoID
Estrarre gli standard feeds
Le API forniscono anche degli ‘standard feeds’, che rappresentano liste di video
scelte in base ad un insieme di criteri. La URL per gli standard feeds è composta nel
seguente modo:
http://gdata.youtube.com/feeds/api/standardfeeds/FEED_IDENTIFIER
La lista seguente illustra i criteri utilizzabili (e il loro identificativo)
23
Nome del feed
Feed Identifier
Most Viewed
most_viewed
Top Rated
top_rated
Recently Featured
recently_featured
Watch On Mobile
watch_on_mobile
Most Discussed
most_discussed
Top Favorites
top_favorites
Most Responded
most_responded
Most Recent
most_recent
È possibile estrarre standard feeds in base alla regione geografica e alla categoria,
specificando nei parametri sia l’ID della zona, sia il nome della categoria di interesse.
Si può utilizzare il seguente formato:
http://gdata.youtube.com/feeds/api/standardfeeds/localeID/feedID_Category_name
Si propone un esempio che mostra il feed URL per la lista dei video divertenti più
votati in Giappone:
http://gdata.youtube.com/feeds/api/standardfeeds/JP/top_rated_Comedy
Video caricati da uno specifico utente
Per ogni utente di YouTube, le API definiscono un video feed che elenca i video che
l’utente ha pubblicato. La URL per il video feed dei video caricati da un utente può
essere creato come nell’esempio:
http://gdata.youtube.com/feeds/api/users/username/uploads
Ricercare dei video
Si può richiedere un insieme di video che corrispondono ad un particolare termine di
ricerca. Le API di YouTube supportano molti dei parametri usati nelle query
standard di Google, ed inoltre anche dei parametri specificamente legati alla ricerca
nei video. Per esempio, si possono cercare i video pubblicati da un particolare autore
o i video associati ad una specifica categoria di YouTube
Cercare video usando categorie e parole chiave
Si può restringere la ricerca, mostrando solo i video che appartengono ad un dato set
di categorie e/o parole chiave. Bisogna prestare attenzione all’uso di alcune parole,
come ‘comedy’, che possono rappresentare sia una categoria che una parola chiave.
Per distinguere tra categorie e parole chiave, le API usano la convenzione in base alla
quale le parole scritte con l’iniziale maiuscola (es. ‘Comedy’) denotano categorie
24
YouTube, mentre le parole scritte in minuscolo (es. ‘comedy’) indicano parole
chiave.
Le API permettono di ottenere diversi tipi di video feeds:
•
Videos feed
•
Related videos feed
•
Video responses feed
•
Standard feeds
•
User favorites feed
•
Playlist feed
Video feed
Le risposte restituiscono video feeds che contengono al massimo 999 video entries.
Le ricerche possono fare uso di qualsiasi parametro standard delle API di Google o
di parametri personalizzati. Per esempio, la URL seguente richiede tutti i video
correlati alla query "skateboarding dog", ad iniziare dal 21esimo risultato della
ricerca, per un totale di 10 risultati:
http://gdata.youtube.com/feeds/api/videos?
q=skateboarding+dog
&start-index=21
&max-results=10
&v=2
Related videos feed
Il related videos feed contiene una lista di video connessi ad un altro video. Tramite
degli algoritmi YouTube seleziona l’insieme di video correlati. Questo tipo di feed
può contenere un massimo di 100 video.
Video responses feed
Questo feed contiene video che sono stati esplicitamente proposti come video di
risposta ad un altro video. Ogni video può essere inserito come video di risposta ad
un unico altro video, e alcuni video possono non avere video di risposta.
Standard feeds
Gli standard feeds contengono una lista di video che riflette sia il comportamento
degli utenti di YouTube (come video più votati o più visti), sia quello del personale
di YouTube (che seleziona alcuni video, come i video in primo piano e i video adatti
ad essere riprodotti su dispositivi portatili). Molti di questi video sono proposti nella
home page del sito web. Sebbene la società dichiari che gli standard feeds siano
25
aggiornati ogni pochi minuti, da evidenze pratiche durante lo sviluppo della demo del
software TraceSense si è avuta l’impressione opposta, ovvero che, diversamente da
quanto avviene sulla sito web, gli standard feeds non variano anche per diversi
giorni.
Per ottenere uno standard feed è necessario inviare una richiesta HTTP GET alla
URL associata a quel feed. La seguente tabella elenca le URL associate ad ogni
standard feed:
Name
Feed Id
Top rated
top_rated
URL e Descrizione
URL: http://gdata.youtube.com/feeds/api/stand
ardfeeds/top_rated
Descrizione: Questo feed contiene i video
votati maggiormente
Top favorites top_favorites
URL: http://gdata.youtube.com/feeds/api/standard
feeds/top_favorites
Descrizione: Questo feed contiene i video più
scelti come preferiti
Most viewed most_viewed
feeds/most_viewed
guardati più frequentemente
Most popular most_popular
feeds/most_popular
Descrizione: Questo feed contiene i video più
popolari su YouTube, selezionati usando un
algoritmo che tiene conto di molti fattori per
determinare la popolarità generale
Most recent
most_recent
feeds/most_recent
pubblicati più recentemente su YouTube.
Most
discussed
most_discussed
feeds/most_discussed
Description: Questo feed contiene i video che
hanno ricevuto più commenti
Most
responded
most_responded
feeds/most_responded
Description: Questo feed contiene i video che
hanno ricevuto il maggior numero di video di
risposta
26
Recently
featured
recently_featured URL: http://gdata.youtube.com/feeds/api/standard
feeds/recently_featured
Description: Questo feed contiene i video in
primo piano nella home page di YouTube
Videos for
mobile
phones
watch_on_mobile URL: http://gdata.youtube.com/feeds/api/standard
feeds/watch_on_mobile
Description: Questo feed contiene i video adatti
ad essere riprodotti sui dispositivi mobili
Estrarre standard feeds in base alla collocazione geografica
La seguente tabella identifica i paesi per cui le YouTube Data API supportano feeds
localizzati e l’ID della regione associato a ciascuno paese
Country
Region ID
Australia
AU
Brazil
BR
Canada
CA
Czech Republic CZ
France
FR
Germany
DE
Great Britain
GB
Holland
NL
Hong Kong
HK
India
IN
Ireland
IE
Israel
IL
Italy
IT
Japan
JP
Mexico
MX
New Zealand
NZ
Poland
PL
Russia
RU
27
South Korea
KR
Spain
ES
Sweden
SE
Taiwan
TW
United States
US
Le API permettono di estrarre standard feeds relativi ad una regione specifica
inserendo l’ID della regione di interesse nella URL dello standard feed. Il seguente
URL dimostra il formato da usare per il suddetto scopo:
http://gdata.youtube.com/feeds/api/standardfeeds/regionID/feedID?v=2
Per esempio, per ottenere una lista dei video più votati in Giappone, bisogna inviare
una richiesta HTTP GET alla seguente URL:
http://gdata.youtube.com/feeds/api/standardfeeds/JP/top_rated?v=2
Usare il parametro tempo con gli standard feeds
Si deve far notare che molti di questi feeds supportano il parametro tempo nelle
query, che permette di restringere la ricerca solamente ai risultati rilevanti per il
giorno, la settimana o il mese precedenti. Per esempio, per cercare i video più votati
nell’ultimo giorno, si può inviare una richiesta HTTP GET alla seguente URL:
http://gdata.youtube.com/feeds/api/standardfeeds/top_rated?time=today
È anche possibile, tramite API, l’esecuzione dell’upload dei video e le relative
modifiche riguardanti i video caricati, ma l’argomento non verrà trattato in quanto
non è stato oggetto di interesse durante il lavoro svolto nel tirocinio.
Definizione dei parametri delle query
Le API di Youtube supportano i seguenti parametri standard di Google Data
Nome
Definizione
maxresults
Il parametro max-results specifica il massimo numero di risultati che
devono essere inclusi nell’insieme di risposta. Questo parametro lavora
in connessione con il parametro start-index per determinare quali
risultati restituire. Per esempio, per richiedere il secondo set di 10
risultati, ovverosia i risultati da 11 a 20, bisogna settare il parametro
max-results a 10 e il parametro start-index a 11. Il valore di default per
questo parametro è 25, e il valore massimo è 50. Viene raccomandato di
assegnare il valore 10 a max-results se si vuole visualizzare una lista di
video sullo schermo, ad esempio in un blog.
28
start-index Il parametro start-index specifica l’indice del primo risultato che
soddisfa i criteri di ricerca incluso nel set di risposta. L’indice di
partenza è 1, cioè il primo risultato è 1, il secondo risultato è 2, e così
via. Questo parametro lavora in connessione con il parametro maxresults per determinare quali risultati restituire.
v
Il parametro v specifica la versione delle API a cui YouTube deve fare
riferimento per gestire le richieste.
Parametri specifici per le YouTube Data API
orderby Il parametro orderby, specifica il valore che deve essere usato per ordinare
i video nel set di risultati della ricerca. Dei valori validi sono relevance
(importanza attributa da YouTube), published (data di pubblicazione),
viewCount (numero di visite degli utenti) e rating (voti degli utenti).
Inoltre, è possibile richiedere risultati più rilevanti in un linguaggio
specifico
assegnando
al
parametro
il
valore
relevance_lang_languageCode, in cui languageCode è un codice che
rappresenta il linguaggio in due lettere nello standard ISO 639-1. Bisogna
notare che i risultati in altri linguaggi verranno visualizzati ugualmente se
sono molto rilevanti per i termini di ricerca. Il valore di default per questo
parametro è relevance.
q
Il parametro q specifica il termine per la ricerca. La ricerca verrà effettuata
su tutti i metadati dei video che corrispondono alla parola chiave cercata. I
metadati dei video includono il titolo, le parole chiave, la descrizione, lo
username dell’autore, e la categoria di appartenenza. Nelle richieste si
possono anche usare gli operatori booleani NOT (-) e OR (|) per escludere
o cercare video che sono associati con uno o più termini di ricerca.
time
Il parametro time restringe la ricerca di video pubblicati all’interno di un
determinato periodo di tempo. Valori validi per questo parametro sono:
today (1 giorno), this_week (7 giorni), this_month (1 mese) e all_time. Il
valore di default per questo parametro è all_time.
Questo parametro è supportato nelle ricerche di standard feeds; top_rated,
top_favorites,
most_viewed,
most_popular,
most_discussed
e
most_responded.
uploader Il parametro uploader permette di restringere la ricerca ai video degli
affiliati al programma partner di YouTube. Un partner di YouTube è una
persona o un’organizzazione che è stata accettata e partecipa allo YouTube
Partner Program. Il valore del parametro uploader deve essere partner.
In una risposta API, un feed contiene un video di un partner se la video
entry contiene un tag <media:credit> in cui il valore dell’attributo yt:type
è partner.
29
Riferimenti ad alcuni elementi di YouTube usati nell’applicazione
Il tag <yt:statistics> fornisce delle statistiche che riguardano un video o un utente.
Questo tag non è fornito se in una video entry il valore di ‘viewCount’ è 0.
Nome attributo
Formato
Descrizione
Integer
Quando l’attributo viewCount si riferisce ad una
video entry, specifica il numero di volte che un
video è stato visualizzato. Quando l’attributo
viewCount si riferisce ad un profilo utente,
specifica il numero di volte che il profilo utente è
stato visitato.
videoWatchCount Integer
L’attributo videoWatchCount specifica il
numero di video che un utente ha guardato su
YouTube. Questo attributo è presente solamente
quando il tag <yt:statistics> appare nella entry
del profilo di un utente.
subscriberCount
Integer
L’atributo subscriberCount specifica il numero
di utenti di YouTube che si sono iscritti ad un
particolare canale di un utente. Questo attributo è
specificato
solamente
quando
il
tag
<yt:statistics> appare nella entry del profilo di
un utente.
DateTime
L’attributo lastWebAccess indica la data più
recente in cui un particolare utente si è connesso
a YouTube.
Integer
L’attributo favoriteCount specifica il numero di
utenti di YouTube che hanno aggiunto un video
alla loro lista di preferiti. Questo attributo è
specificato soltanto quando il tag <yt:statistics>
appare nella entry del profilo di un utente.
viewCount
lastWebAccess
favoriteCount
Il tag <media:keywords> contiene una lista (separata da virgole) di parole associate
ad un video. La lista è composta al minimo da una parola chiave. Questo campo può
contenere tutti i caratteri UTF-8 validi tranne ‘<’ e ‘>’. Inoltre, ogni parola chiave
può essere lunga al minimo due caratteri e non può superare i 25 caratteri.
Le parole chiave possono contenere spazi, a significare che un termine chiave può
essere più lungo di una singola parola. Per esempio, “crazy,surfing,stunts” e “crazy,
surfing stunts” sono entrambi valori validi per questo tag, ma il primo valore
contiene tre parole chiave, mentre l’ultimo ne contiene solo due ("crazy" e "surfing
stunts").
30
Limiti nel numero di elementi di un feed
Le API di YouTube hanno alcuni vincoli sul numero di video forniti come risultato
di una richiesta. Per gli standard feeds questo limite è 100, mentre per le ricerche
tramite parole chiave il limite aumenta a 1000.
Questi limiti sono stati predisposti, a detta dalla compagnia, perchè loro ritengono
che una persona interessata alla ricerca di un particolare video su un argomento non
arrivi mai a desidare di ottenere più di 1000 risultati. Questo ragionamento può
essere considerato plausibile per quanto riguarda l’interfaccia del sito, mentre per
l’uso delle API il discorso probabilmente potrebbe essere diverso.
Ovviamente è la compagnia che mette a disposizione gratuitamente questi web
services, e non essendo un organizzazione no profit ha tutto l’interesse a non perdere
il suo monopolio nel video-sharing, evitatando di mettersi nella situazione di avere
dei concorrenti.
31
5. Strategia di soluzione del problema
Il risultato che si è voluto ottenere è un database con un vastissimo insieme di
metadati relativi a milioni di video. I dati memorizzati per ciascun video sono stati
registrati in una tabella, di nome video, che contiene i seguenti campi:
Si sono presentati alcuni problemi durante lo sviluppo della soluzione applicativa.
Le politiche di YouTube non permettono di accedere ai dati globalmente, pertanto si
è pensato di implementare una soluzione che, dato il numero immenso di video
presenti sul portale, facesse uso di un approccio di tipo incrementale.
Per superare l’ostacolo dei limiti nel numero di risultati forniti dalle API, sono stati
valutati diversi modi per navigare tra i dati ed espandere via via la ricerca, che
vengono esposti nel seguito del capitolo.
Inoltre, le API non permettono di decidere tra quali campi una ricerca debba essere
fatta; le parole chiave sono ricercate indistintamente tra tutti i metadati (titolo,
descrizione, tags, autore, ecc...). Nei risultati forniti si trovano molti duplicati, che
rallentano la ricerca, perchè creano delle ridondanze.
Per l’estrazione di un set di dati relativi ai video si è fatto riferimento alla reference
guide delle API di YouTube, in cui sono forniti alcuni esempi di codice (sia in Java
che in altri linguaggi).
Si è scelto di partire da uno di questi esempi, scaricando il file relativo: gdatasrc.java-1.33.0.zip (dal seguente link: http://code.google.com/p/gdata-javaclient/downloads/list), che è stato rilasciato l’8 giugno 2009. Questo codice fornisce
una dimostrazione delle funzioni basilari delle API di YouTube, facendo uso della
Java client library.
L’intenzione di partenza è stata di usare questo codice per iniziare a conoscere e
comprendere l’utilizzo dei web services tramite la programmazione Java, e
sperimentare il funzionamento dei metodi forniti. Grazie a questo approccio, la
successiva fase di personalizzazione per l’ottenimento delle informazioni utili al
presente lavoro è risultata più semplice, rispetto al dover partire completamente da
zero. L’esempio contiene dei metodi che permettono di:
32
- Estrarre gli standard feeds
- Cercare un feed
- Cercare un feed usando categorie e parole chiave
- Estrarre i video caricati da un utente
- Estrarre i video preferiti di un utente
- Estrarre i video di risposta ad un video
- Estrarre i commenti di un video
- Estrarre la lista di playlist di un utente
- Estrarre una playlist
- Estrarre la lista di iscrizioni di un utente
- Estrarre il profilo di un utente
Inizialmente, si è provato proprio a compilare il codice dell’esempio, ma ciò non era
possibile, perchè si generava un errore durante il run-time (con la seguente dicitura
“Invalid value for attribute 'name' ”). Questo inconveniente è sorto per un problema
preesistente nel codice dell’esempio che, probabilmente, non era aggiornato agli
ultimi sviluppi di YouTube. Infatti, nell’elenco dei possibili stati in cui si può trovare
un video quando non è riproducibile, indicati dal tag <yt:state>, (INCOMPLETE,
PROCESSING, REJECTED, FAILED, DELETED) mancava l’opzione
RESTRICTED. La soluzione al problema è stata trovata consultando lo YouTube
APIs Developer Forum, si è pertanto riusciti a risolvere il problema modificando il
codice fornito ed aggiungendoci l’opzione RESTRICTED tra i valori possibili per lo
stato di un video.
In seguito al corretto funzionamento del codice di esempio si è potuti entrare in
contatto più stretto con i metodi necessari per recuperare i dati desiderati. Si è creata
una nuova applicazione Java, che su modello dell’esempio attingesse ai dati del
portale.
Inizialmente si è tentato di scaricare i video più visti, però si sono subito riscontrati
dei problemi, in quanto le API fornite non permettono di ricevere più di 100 risultati
(non più di 50 per singola richiesta, per un massimo di 2 richieste) per gli standard
feeds. Quindi si è posto il problema di estrarre un gran numero di video, tra i più
visti, scavalcando quest’ostacolo.
- Algoritmo utilizzato per estrarre dati dai web services
Sono state fatte delle valutazioni per decidere come aggirare il problema dei limiti,
sperimentando diversi criteri di ricerca. Si è notato che con la ricerca per parola
chiave o per categoria questo limite si estendeva a 1000 risultati (sempre con un
massimo di 50 risultati per richiesta, per cui un massimo di 20 richieste), quindi già
un miglioramento rispetto agli standard feeds.
Si è inoltre pensato di realizzare un parser, ovvero un algoritmo di riconoscimento
sintattico del contenuto di una pagina web, però, andando ad analizzare i risultati
33
forniti da Youtube per una ricerca sui video più visti in generale, ci si è imbattuti
all’incirca negli stessi limiti. Un massimo di 115 risultati per gli standard feeds
(invece di 100 con le API), e sempre 1000 risultati per le ricerche con parole chiave.
Quindi, considerando che un parser non avrebbe avuto una durata lunga nel tempo (a
causa della continua variazione della struttura di un sito web), come nel caso dell’uso
delle API, e la pressochè identica granularità dei risultati forniti tra interfaccia del
sito web e API, si è scartata questa ipotesi.
La procedura di spidering usata è illustrata in Figura 5.
Figura 5. Schema della procedura di spidering
Per creare una base dati di partenza composta da argomenti variegati si è iniziato
quindi, estraendo i 1000 risultati di video più visti per ognuna delle 13 categorie in
cui sono classificati i video in YouTube:
- All
- Autos & Vehicles
- Comedy
- Education
- Entertainment
- Film & Animation
- Gaming
34
- Howto & Style
- Music
- News & Politics
- Nonprofits & Activism
- People & Blogs
- Pets & Animals
- Science & Technology
- Sports
- Travel & Events
Non si sono ottenuti esattamente 16.000 video perchè, in primo luogo la categoria
‘All’ contiene video di tutte le categorie e, inoltre, come è stato più volte verificato,
nei risultati di una richiesta spesso lo stesso video compare più volte, anche se questo
in teoria non dovrebbe succedere. Si sono ottenuti un totale di circa 13.000 risultati
diversi.
- Metodologia di spidering incrementale
I risultati ottenuti al punto precedente sono stati la base sulla quale si è costruito il
resto del database. Questi video sono stati salvati in una base dati. La tabella che li
contiene, chiamata ‘video’, ha diversi attributi; ID, titolo, URL, autore, categoria,
descrizione, numero di visualizzazioni e i tags. Inoltre ognuno di questi tag è stato
inserito in una tabella (‘tags’) a parte contenente tutti i tags trovati.
Per cercare di espandere la base dati si è cominciato a fare delle ricerche per tag
(quelli contenuti nell’apposita tabella ‘tags’).
Quindi per ogni tag usato come parola chiave nella ricerca si ottengono al più 1000
risultati (non sempre 1000 perchè alcuni tag possono essere presenti di rado su
YouTube, o nessun risultato quando un tag è stato inserito da un utente, memorizzato
nel nostro database, e poi quel video è stato rimosso dall’utente o da YouTube).
Ogni tag già usato viene segnato tramite un flag nella tabella ‘tags’ e quindi non
viene più cercato.
Inizialmente la selezione dei tags da usare veniva fatta in ordine alfabetico (ad
esempio si prendevano dal database i 100 tag non ancora usati, ed essendo i tag
memorizzati in ordine alfabetico si ricadeva sempre nelle prime posizioni
dell’alfabeto). Successivamente, per ovviare a questo problema è stato implementato
un algoritmo di ricerca random tra le posizioni dei tags nel database, e in questo
modo il campionamento viene effettuato in modo più omogeneo tra le lettere
dell’alfabeto. I video trovati in questo modo sono salvati successivamente nella
tabella dei video e i relativi tags nella tabella dei tags.
Sono state valutate anche altre opzioni, per esempio, considerare i video correlati
(ovvero sullo stesso argomento) ad ognuno dei video presenti nella base dati, ma in
questo modo si rischierebbe di ricadere sempre su video dello stesso argomento e
35
non avere quindi un campione omogeneo di video sulle categorie. Per questo motivo
questa scelta non è stata attuata.
Altre possibilità prese in esame sono state:
•
acquisire i video preferiti di un utente (rischiando nuovamente di ricadere
sempre nel problema precedente, ovvero avere un campione di video
monotematico).
• Considerare i video degli utenti che hanno commentato quel video. In questo
caso però si rischierebbe di andare molto lenti perchè non tutti gli iscritti a
YouTube sono attivi, nel senso di pubblicare dei video.
• Fare le ricerche in base a tutti i video pubblicati dagli utenti (in modo simile a
ciò che si è fatto per i tags), ovvero per ogni utente acquisire i video da lui
caricati.
Questo ultima idea è sopraggiunta dopo le statistiche effettuate sulla base dati, in cui
si è rilevato che nel campione estratto erano presenti circa 2,43 video per utente. Un
numero abbastanza basso, in quanto ogni utente attivo ha molto probabilmente
caricato più di 2 video. Per di più l’utente che si sta usando per fare la ricerca è
sicuramente attivo (infatti ha pubblicato almeno un video dal quale è stata estratto
estratto il suo nickname ed è stato salvato nel database).
Questa opzione è stata presa in considerazione verso il termine del tirocinio ed è
stato implementato nell’applicazione un metodo che permette di avvalersi anche di
questo algoritmo di spidering incrementale. Sono state fatte delle prove e si è notata
una buona velocità di accrescimento della base dati con questo metodo, che potrà
essere usato in futuro se lo si riterrà opportuno.
- Interfaccia grafica come strumento di valutazione di TraceSense
Al termine della realizzazione dell’applicazione si è deciso di creare l’interfaccia
grafica per il sito dimostrativo di Tracesense. L’obiettivo del sito era dimostrare il
funzionamento dell’algoritmo sotto una veste grafica intuitiva e accattivante.
Si è deciso di organizzarlo nel seguente modo:
- una homepage, che serve da filtro per gli utenti che non possono accedervi. In
questa pagina si inseriscono i dati per fare il login; una volta verificati, dal sistema,
username e password si può accedere al sito vero e proprio.
- una seconda pagina (Figura 6) in cui è presente un elenco di video di default, i 100
video più visti. Questi ultimi sono estratti, attraverso l’applicazione Java creata, che
interroga le API di YouTube. La scelta del tipo di feeds può essere facilmente
cambiata in funzione di altri tipi di standard feeds (descritti nel paragrafo 4.2).
Oltre ai video proposti di default è inoltre possibile fare una ricerca per parole chiave
tra tutti i video di YouTube ed ottenere i risultati direttamente nella pagina.
Questo è possibile perchè è stata usata la tecnologia Ajax, che permette di far
cambiare solo parte della pagina dinamicamente, e lasciarne un’altra parte statica
(questa tecnologia è stata approfondita meglio nel paragrafo 4.1).
La ricerca di video per parola chiave viene fatta interfacciando il codice HTML con
una servlet Java.
36
Figura 6. Pagina web con l'elenco dei video
Ogni volta che viene premuto il tasto ‘Invio’ sulla casella di testo della ricerca o che
viene premuto il pulsante ‘Search’, il codice richiama una servlet. Questa si
interfaccia con l’applicazione java, richiamando i metodi di quest’ultima, (lo
scambio di dati è fatto in formato json, formato che è stato descritto più
dettagliatamente nel paragrafo 4.1).
Viene pertanto aggiornato l’elenco dei video. Se nella casella di testo non è presente
nessun testo, la ricerca viene inizializzata come avviene al caricamento della pagina,
ovvero vengono visualizzati i video di default.
Figura 7. Tooltip
Per evitare che titoli troppo lunghi non vengano visualizzati nella loro totalità sotto
l’immagine, si è inserito il tooltip, grazie al quale passando il mouse su una delle
immagini anteprima dei video, si può visualizzare il titolo completo di quel video
(Figura 7).
37
È a questo punto possibile cliccare su un’immagine per selezionare un video da
analizzare. Dopo questo click si viene condotti nella pagina di analisi dettagliata dei
contenuti del video.
Figura 8. Pagina web con l'analisi del singolo video
- un’ultima pagina (Figura 8) in cui sono presentati i dettagli di un singolo video
selezionato. La pagina è divisa in due sezioni (destra e sinistra) per mettere a
confronto i dati forniti dal portale con quelli forniti come risultato dall’algoritmo:
- Sulla sinistra sono presenti i YouTube Data: i dati ottenuti dal portale,
ovvero il titolo, i tags e il video.
- Sulla destra si trovano le Tracesense Categories: è visualizzato il risultato
ottenuto da TraceSense, ovvero le prime tre categorie con maggiore rilevanza.
Nel caso in cui più categorie siano a pari merito, in ognuna delle tre righe
vengono visualizzate tutte le categorie che hanno la stessa importanza.
In questa sezione c’è anche un’altra parte, molto interessante, in cui viene
chiesto un giudizio all’utente che, dopo aver preso visione del video, del
titolo e dei tags deve esprimere il suo giudizio sulla qualità dei risultati
ottenuti da Tracesense, tra le seguenti opzioni:
1. ‘Great, I agree completely with the first definition’
2. ‘Good, I agree with some definition’
3. ‘Bad, completely off the topic’
Questa valutazione è obbligatoriamente fatta a prescindere dalla descrizione del
video, che infatti non è visualizzata, proprio perchè il funzionamento dell’algoritmo
si basa esclusivamente sui tags, e non su altre fonti. Inoltre l’utente potrebbe leggere
solamente la descrizione e non vedere il video, se questa gli fosse fornita.
38
Non viene neanche fornita la categoria originaria del video, assegnata da chi ha
pubblicato il video, perchè potrebbe fuorviare l’utente, ed oltre a non fargli venir
voglia di vedere il video, questa categoria potrebbe non essere realmente quella che
identifica il video.
Una volta dato il giudizio, nella pagina compaiono anche la categoria assegnata
dall’uploader del video (utente che lo ha inserito su YouTube) e la descrizione che
questi ne ha dato. La comparsa di questi elementi è gestita con gli attributi
riguardanti la visibilità, di HTML e CSS.
A questo punto l’utente della demo può porre a confronto la categoria originaria con
quelle attribuite dall’algoritmo e trarre le sue conclusioni.
Inizialmente non venivano visualizzati tutti i video nella pagina, ma rimanevano
frequentemente alcuni spazi vuoti sparsi nella griglia, tra gli altri video. Dopo alcune
ricerche si è compreso il problema. Non tutti i video presenti su YouTube possono
essere inseriti all’interno di altre pagine web (come embedded video). Difatti quando
si pubblica un video si può decidere di impedirgli di diventare un “embedded video”,
e quando si prova a farlo viene visualizzato un messaggio "Embedding disabled by
request".
Si può facilmente ovviare a questo problema aggiungendo ‘&format=5’ alle query di
ricerca per restringere i risultati ai video che possono essere inseriti all’interno di
altre pagine web. In questo modo la griglia di presentazione delle thumbnail dei
video non presenta immagini mancanti.
39
6. Caratterizzazione della base dati
6.1 Presentazione ed interpretazione dei risultati ottenuti dalle
statistiche
Sono state effettuate numerose statistiche sulla base dati ottenuta, e vengono di
seguito presentate le più interessanti. Altri dati raccolti sono riportati in
APPENDICE.
Milioni di video
10
9
5° settimana
8
7
4° settimana
6
3° settimana
5
2° settimana
4
3
1° settimana
2
1
0
0
10
20
30
40
50
60
70
80
Migliaia di tags
Grafico 1. Numero di video (in milioni) e numero di tags (in migliaia) raccolti durante la creazione della base dati
Nel grafico 1 è riportata l’evoluzione della base dati per quanto riguarda la
numerosità di video e tags. Si è calcolato che vengono memorizzati nel database
circa 160 nuovi video al minuto, che sono più di un milione e mezzo di video a
settimana. Dall’andamento del grafico si nota che il numero di video scaricati
inizialmente cresce con una velocità maggiore, mentre successivamente la pendenza
della retta diminuisce, molto probabilmente perchè vengono trovati video che sono
già presenti nella base dati.
I dati sono stati registrati nei giorni lavorativi, in un arco di 5 settimane, durante le
quali si è creata una base dati di più di 9 milioni di video diversi.
40
6.. Caratterizzazione della base dati
Percentuale del numero
umero di video suddivisi per categoria
Tech Travel
1% 2%
Animals
1%
Autos
4%
Sports
7%
Nonprofit
1%
Comedy
7%
Education
2%
People
10%
Autos
Comedy
Education
Entertainment
18%
News
4%
Animals
Entertainment
Film
Games
Music
31%
Film
7%
Games
How to 3%
2%
How to
Music
News
Grafico 2. Percentuale del numero
umero di video suddivisi per categoria
Questa statistica è stata fatta sull’intera base dati acquisita fino al momento
dell’analisi, che comprendeva un totale di 5.200.463 video.
Nel grafico a torta è raffigurata la suddivisione in categorie YouTube del campione
di video analizzati. Ogni spicchio della torta rappresenta una percentuale più o meno
vasta, in base alla numerosità dei video. Questa rappresentazione è interessante per
conoscere la distribuzione dei video in domini di conoscenza.
Si può notare che la percentuale maggiore è detenuta dalla categoria Music, che
rappresenta quasi un terzo del totale. Come si può constatare,
constatare anche dalle parole più
popolari tra i tags dei video di YouTube (rappresentate
(
in Figura 9), la categoria
musicale è sicuramente quella dominante.
Una possibile interpretazione di questo comportamento sociale potrebbe riguardare
sicuramente l’utilizzo che viene fatto principalmente dalle persone di YouTube,
ovvero il sito web è usato in particolar modo per finalità di svago, come fonte di
intrattenimento.
ento. Inoltre, i video musicali sono quelli che si prestano meglio ad essere
riprodotti anche in background sul computer mentre si esercitano altre attività.
Non ultima è da citare l’importanza pubblicitaria che questi contenuti rivestono,
poichè i video musicali
usicali protetti da copyright molto spesso sono correlati a pubblicità
per la vendita della musica proposte da iTunes di Apple. Quindi, il giro d’affari che
costituiscono deve essere abbastanza importante da spingere tutte le case
discografiche a proporre loro stesse i contenuti dei video musicali sul web.
web
Se si considerano insieme le due categorie Film (in cui convergono film e cartoni
animati) e Entertainment (che riguarda soprattutto programmi televisivi e spettacoli),
che sono molto simili per contenuti,
contenuti, si ottiene l’altra grande “fetta” della torta che
racchiude il 25% di video.
41
La popolarità di questo segmento è ovviamente dovuta al suo aspetto di
intrattenimento, come osservato per la categoria musicale. Probabilmente la maggior
parte di questi video riproduce serie televisive, film, tra cui anche alcuni contenuti
protetti da copyright. Delucidazioni sulla politica che Youtube adotta riguardo a
questo tipo di violazioni sono esposte nel paragrafo 2.3. I contenuti protetti da
copyright sono ovviamente visti da moltissime persone e questo ne decreta la loro
popolarità. Le serie televisive per di più, hanno un pubblico “abituale”, ovvero che è
costante nel tempo; persone che magari non hanno il tempo di guardare queste serie
in televisione, possono guardarle su YouTube esattamente nel momento in cui
vogliono, e anche mettere in pausa, saltare delle scene, ecc...Questo è sicuramente
uno degli aspetti che hanno decretato il successo di questa piattaforma multimediale.
La categorie Sports e Comedy occupano entrambe il 7%, e si possono fare
considerazioni analoghe a quelle fatte per le altre forme di intrattenimento, mentre
l’unica altra categoria con un certo peso, circa il 10%, è People.
Questa categoria è solitamente composta da video cosiddetti vlog, ovvero blog
accompagnati dal video di persone che parlano delle proprie esperienze personali o
altri argomenti simili. Considerato il grande numero di utenti del portale non c’è da
stupirsi che molti di questi oltre a guardare filmati partecipino attivamente con
contenuti personali o eventi speciali della propria vita. Questa è esattamente la
filosofia del web 2.0, un luogo in cui si può trasmettere ed apprendere allo stesso
tempo.
Le altre categorie hanno percentuali meno consistenti, tra queste è inclusa anche la
categoria News, ad ulteriore dimostrazione che in questo nuovo paradigma l’attualità
non proviene prevalentemente da fonti “ufficiali”, come testate giornalistiche o
gruppi editoriali, ma sta iniziando la diffusione (bottom-up) delle informazioni a
partire dal basso, dalle persone comuni che documentano ciò che le circonda.
Statistiche su alcuni canali “ufficiali”
Tabella 2. Numero di video pubblicati per i canali "ufficiali"
Canale
Numero di
video pubblicati
1
AlJazeeraEnglish
10652
2
istreamnews
3446
3
BBCWorldwide
4028
4
AssociatedPress
23226
5
Bloomberg
15553
6
itnnews
7
FoxNewsChannel
8
NationalGeographic
1050
756
1185
42
9
newscientistvideo
617
10 Politicstv
807
11 sciencentral
287
12 TheNewYorkTimes
1459
13 TheRealNews
1441
14 Google
1015
15 france24english
2501
16 CNN
2771
17 skynews
970
18 CBS
20569
19 ABCNews
1283
20 NTDTV
7953
È stata fatta un’analisi su un insieme di canali considerati “ufficiali”, nel senso che
non provengono da singoli individui, ma principalmente da canali di informazione o
network televisivi. La lista dei canali è in Tabella 2. Si è considerata l’ipotesi di
scegliere i canali degli utenti partner di YouTube, tramite l’attributo uploader
(descritto nel paragrafo 4.2), ma in realtà non avrebbe avuto la stessa valenza, perchè
i partner sono comunque utenti comuni. L’insieme dei canali è stato scelto,
ovviamente tra quelli in lingua inglese, prendendo spunto da questo sito:
http://www.openculture.com/, che contiene una lista di canali di YouTube sugli
argomenti di attualità, informazione e scientifici.
L’obiettivo dell’analisi di questi canali è stato confrontare il comportamento nel
tagging (ovvero del modo di assegnare i tags ad una risorsa informativa) da parte di
persone che svolgono questo compito come lavoro, rispetto agli altri utenti semplici.
Si sono confrontati il numero di tags medi, massimi e minimi dei video dei canali
“ufficiali” selezionati, con quelli di un ugual numero di video più visti (circa
100.000).
Tabella 3. Confronto di statistiche sui tags tra canali "istituizionali" e video più visti
Canali “ufficiali”
Video più visti
8,97
9,42
Massimo numero di tag
64
123
Minimo numero di tag
1
1
Media di tag
43
Il numero di tag medi per video è molto simile, circa 9, per cui non si possono fare
ragionamenti sulla differenza di proposta dei tags da parte delle due categorie. Il
numero massimo di tag invece cambia, è circa il doppio per i video più visti, ma non
è un numero molto indicativo poichè alcuni utenti mettono un numero di tags molto
alto,, anche se non corrispondono al contenuto, per aumentare la possibilità di
visibilità del video. Il numero minimo di tag è 1, che è anche il numero minore di tag
concesso da Youtube. Tra i video più visti, inoltre c’è
c’è una percentuale di ben il 12%
di video che hanno solo 1 o 2 tag. Per maggiori particolari sulla distribuzione del
numero di tag nel video si può consultare il grafico 11 in appendice.
Numero medio di video per utente
Questa statistica è stata effettuata sull’intera base dati acquisita fino al momento
dell’analisi, che comprendeva un totale di 5.200.463 video.
Il numero medio di video per utente è 2,2738.
Suddivisione in categorie dei video inseriti da ogni utente
Utenti che inseriscono video in categorie
distinte
3 categorie
2 categorie 2%
9%
da 4 a 15 categorie
1%
1 categoria
2 categorie
3 categorie
da 4 a 15 categorie
1 categoria
88%
Grafico 3.. Numero di categorie distinte usate da ciascun utente
La statistica è stata fatta sull’intera base dati acquisita fino al momento dell’analisi,
che comprendeva un totale di 5.200.463 video.
Questa rappresentazione grafica indica la percentuale di utenti che inseriscono i
propri video in un determinato numero di categorie distinte. Ad esempio, ci saranno
utenti che inseriscono tutti i video che pubblicano classificandoli come appartenenti
alla stessa categoria, mentre ci saranno altri utenti che producono video di diversa
natura e si comportoreranno quindi, di conseguenza.
44
È impossibile non notare la preponderanza di utenti che inseriscono i propri video
sempre nella stessa categoria, e per cui
cui si potrebbe immaginare che molti canali siano
monotematici. In realtà bisogna tener conto anche di altri due aspetti.
Riferendoci
iferendoci sempre alla relativa significatività del campione preso in esame (è solo
un campione, e non l’intero database
d
di Youtube), si deve notare che il numero
medio di video per utente è 2,2738. Quindi, sebbene non ci siano nel campione solo
utenti con pochi video, questo aspetto influenza molto i dati.
Bisogna inoltre tenere in considerazione il fatto che molti utenti non sono così
rigorosi nell’assegnazione delle categorie.
categorie Per esempio, se un utente pubblica
solitamente video sulla realizzazione di ricette di cucina assegnandoli alla categoria
‘Howto & Style’,, ed una volta pubblica un video sulle sue vacanze, è possibile che
non lo inserisca nella categoria ‘Travel & Events’.
Si riscontra però, anche un 9% di utenti che inseriscono video in 2 diverse categorie
che, considerando la media di poco più di 2 video ad utente, si può considerare una
buona percentuale.
Numero medio di tag per video e numero di video
40
35
30
25
20
15
n° video( in decine di migliaia)
10
media di tag/video
5
Animals
People
Autos
Film
Music
Comedy
Travel
Sports
Entertainment
Howto
News
Tech
Education
Nonprofit
Games
0
Grafico 4.. Confronto tra numero medio di tags per video e numero di video della stessa categoria
Il grafico in figura illustra l’andamento, suddiviso per categorie YouTube, del
numero
umero medio di tags per video, in confronto alla numerosità dei video.
video
Si nota che il numero medio di tags per video è molto simile per nove categorie
(circa 10 tag per video),, a partire da sinistra, mentre per le successive categorie è un
po’ più alto. Soprattutto per le categorie ‘Games’ e ‘Nonprofit’
‘Nonprofit’ il numero medio di
tags è decisamente maggiore. Per la categoria ‘Games’ vale circa 17 tags/video.
Queste categorie sono entrambe poco presenti, come numerosità, nel campione di
riferimento.
45
Per questo motivo è possibile che le statistiche siano meno rappresentative,
rappresentative, rispetto a
categorie con un numero di video 20 o 30 volte maggiore. Apparte questa
considerazione si potrebbe anche pensare che queste categorie siano normalmente
taggate più minuziosamente, per qualche motivo di carattere specifico.
specifico
Questa distribuzione è stata ricavata a partire dalla tabella che contiene un milione di
video più visti. La tabella usata, ‘videotag_1m’, comprende più di 10 milioni di
record ed ha una chiave primaria formata da due campi: l’ID del video e il tag. Si è
deciso dii utilizzare questa tabella dopo aver fatto successive prove,
prove ed aver
constatato l’impossibilità di lavorare su moli di dati considerevolmente maggiori.
Infatti, se si fosse creata una tabella ‘video-tag’
‘video tag’ per gli oltre 5 milioni di video della
base dati totale,
tale, e considerando un rapporto approssimativo di 1 a 10 tra ‘video’ e
‘video-tag’,
tag’, si sarebbe ottenuta una tabella di circa 50 milioni di record. La memoria
fisica del computer non sarebbe sicuramente riuscita a gestire questo numero di
record.
Numero di video suddivisi per anno di inserimento
Video
2005
2006
2007
2008
2009
0
5
10
15
20
25
30
35
40
Migliaia di video
Grafico 5.. Numero di video suddivisi per anno di inserimento (fino al 31 agosto 2009)
Questa statistica è stata calcolata a partire dal campione dei 100.000 video più visti, e
non su tutti perchè nella tabella della
della base dati di partenza non è presente l’attributo
riguardante la data di inserimento di un video, per cui si è scelto di creare una tabella
che oltre ai dati contenuti in quella di partenza avesse in più il campo data.
La procedura di estrazione della
dell data di ogni video si è rivelata lentissima, perchè per
ogni id di un video deve essere fatta una singola richiesta, ed inoltre molti di questi
video vengono cancellati da YouTube stesso o dai loro autori. Per questo motivo di
tempistiche si è ritenuto che
che una collezione di 100.000 video potesse essere
abbastanza rappresentativa del campione totale.
Nel grafico è rappresentata la numerosità di video in base alla data di pubblicazione
degli stessi su YouTube. Non è motivo di stupore il numero esiguo di video
vide inseriti
nell’anno 2005, come si nota dalla
dalla rappresentazione grafica, in quanto il 2005 è
46
proprio l’anno in cui è stato fondato YouTube, e pertanto non poteva essere
altrimenti.
Per i successivi tre anni si evidenzia una crescita importante del numero di video,
mentre per il 2009 si nota una diminuzione dovuta probabilmente alla data in cui è
stata fatta l’analisi, il settembre 2009, che ha sicuramente influenzato il numero di
video trovati, poichè non sono potuti rientrare tutti i video dei mesi successivi
dell’anno. Tutto ciò non fa che confermare, seppur nella limitatezza della
significatività del campione preso in esame, l’incremento straordinario del numero di
video pubblicati ogni giorno su Youtube.
Co-occorrenze
La tabella delle cooccorenze totali (coppie di tags) è stata creata sulla base dei dati
presenti nella tabella videotag_1m. Questa tabella ha come chiave primaria le coppie
“IDvideo - tag” (una per ogni tag di ogni video) per il milione di video più visti.
Sono state create le coppie di tags presenti in videotag_1m, ma solo per i tags
appartenenti ai 100 mila più ricorrenti. Questo è stato fatto dopo successivi tentativi
fatti inizialmente senza questa limitazione. La query non riusciva ad essere eseguita
neanche in 24 ore, per cui si è ritenuto ugualmente significativo considerare solo i
tags più frequenti, che comunque sono più significativi per l’analisi. Questo ha
permesso anche di lavorare su una tabella molto più piccola perchè non contiene tutte
quelle coppie di tags che compaiono magari in uno o pochi video.
La tabella delle co-occorrenze è formata da tre campi: tag1, tag2 (che insieme
corrispondono alla chiave primaria) e il campo video, che indica il numero di video
in cui quella coppia di termini compare. È stata creata in modo che non ci siano
termini duplicati ma in ordine inverso. Ad esempio, non possono essere presenti
nella tabella coppie “sport-soccer” e “soccer-sport” contemporaneamente. I termini
presenti sono tutti minuscoli, poichè non avvengano altre duplicazioni tra termini
maiuscoli e minuscoli. Questi requisiti sono stati considerati molto importanti, anche
perchè nella fase di taratura dell’algoritmo TraceSense, potrebbero essere fatte delle
assegnazioni manuali di significati che altrimenti richiederebbero moltissimo tempo,
se si dovessero ripetere per caratteri maiuscoli, minuscoli e coppie invertite degli
stessi termini.
Figura 9. Tag cloud delle 10 co-occorrenze più frequenti
47
Questo tag cloud (Figura 9) è stato ottenuto dalle prime dieci co-occorrenze più
popolari. I tags sono separati da un trattino. La più frequente, come si può notare è
“music-video”, il che non stupisce perchè come si è più volte osservato in
precedenza la categoria “Music” è quella più numerosa, ed anche la più popolare.
Ben 5 coppie su 10 riguardano appunto la musica.
Ciò che invece meraviglia è la presenza (anche qui 5 volte su 10) della parola video,
che non contraddistingue un contenuto da un altro, perchè la risorsa informativa
stessa, di ogni contenuto di YouTube, è un video.
Le coppie presenti comunque, riguardano tutte tipi di intrattenimento, come film, o
video musicali. Come ultima osservazione si può guardare alla dimensione del
carattere con cui è scritta la coppia più frequente, “music-video”, che infatti è
presente più del doppio delle volte in cui è presente la seconda (“music-pop”).
È stato ricavato un altro dato utile alla misurazione della efficacia dell’algoritmo. Per
spiegare questa statistica è necessario presentare, a grandi linee, il comportamento
base dell’algoritmo.
Tabella 4. Azioni assegnate ai tags dall'algoritmo
ID Nome
Commento
0
Semantics
Processa i tags attraverso il motore semantico ( azione di
default )
1
Discards
Ignora completamente i tags
2
Remap
Indirizza i tags ad altri tags esistenti
3
Category
Collega i tags alle categorie
4
Senses
Assegna sensi specifici di WordNet ai tags
Per alcune co-occorrenze è stato effettuato un lavoro di mappatura, ovvero, il
significato è stato indirizzato manualmente verso uno dei comportamenti indicati in
Tabella 4. Alcuni tags sono indirizzati al motore semantico, altri a specifici sensi di
WordNet, e così via. Alcuni tags vengono però del tutto ignorati, e su questi che si
concentra la statistica in questione.
WordNet è un database semantico-lessicale per la lingua inglese, che si propone di
organizzare, definire e descrivere i concetti espressi dai vocaboli. L'organizzazione
del lessico si avvale di raggruppamenti di termini con significato affine, chiamati
"synset", a cui si fa riferimento nell’ultima riga della tabella.
Effettuando un esame sull’insieme di circa 2500 co-occorrenze precedentemente
mappate dall’algoritmo, si è riscontrato che il 15,85% sono soggette ad azione
‘Discards’, e quindi non sono utili all’elaborazione dell’algoritmo.
48
6.2 prestazioni di database di grandi dimensioni
La macchina su cui sono state eseguite le elaborazioni è dotata di:
- Processore Pentium 4, 3GHz
- RAM 1 GB
- 1 Hard-disk da 40 GB
- Windows XP Professional, versione 2002 SP3
Lavorare con database di grosse dimensioni, che contengono tabelle di 5-10 milioni
di records richiede lunghi tempi di attesa. Si pensi ad esempio, che per ottenere il
risultato del numero esatto di video presenti nel database, il tempo di risposta è stato
di 40 minuti, quando i video erano circa 2 milioni, ed è andato via via salendo
all’aumentare del numero di video.
Problemi si sono verificati anche con la memoria allocata da Java nell’eseguire le
operazioni di lettura/scrittura da database. Per ovviare a questa difficoltà si è
aumentata la memoria allocata alla Java Virtual Machine, fino ad un massimo di 512
MB, perchè oltre non è stato possibile, in quanto veniva messa fuori uso l’intera
macchina per l’eccessivo spazio riservato a Java. Questo non è stato il solo
provvedimento adottato; si è fatto uso di prepared statement nel codice Java. I
prepared statement permettono di sfruttare al meglio il meccanismo di caching
messo a disposizione dalla maggior parte dei database.
Molti DBMS mantengono in cache le istruzioni SQL precedentemente utilizzate e le
mettono a disposizione qualora venga inviata al DB stesso un'istruzione analoga.
Quindi utilizzando un comando già compilato e ottimizzato si ha un miglioramento
generale delle performance. Tale ragionamento è valido, però soltanto se le istruzioni
pervenute sono esattamente identiche in forma e contenuto. L’astuzia sta nel passare
al database un comando SQL che contenga una serie di variabili, in modo che il DB
possa riutilizzare lo stesso comando ogni volta, senza preoccuparsi dei valori cui le
variabili stesse fanno riferimento.
Un altro modo per ovviare a questi risultati di dimensioni gigantesche è stato l’uso
del comando LIMIT all’interno delle query, che permette di eseguire delle selezioni
di risultati limitandone il risultato a una certa quantità stabilita, a partire dal primo.
La sintassi da utilizzare è la seguente:
SELECT * FROM nome_tabella LIMIT numero_risultati
Un altro uso che ne è stato fatto è quello di scegliere un numero totale di risultati a
partire da un certo numero iniziale. Il formato usato è:
SELECT * FROM nome_tabella LIMIT numero_risultato inizio,
totale_ numero_ risultati
Questo strumento è stato indubbiamente essenziale per lavorare con queste immense
quantità di dati.
49
Come ulteriore accorgimento è stata innalzata la memoria allocata a MySQL
(modificando il file my.ini alla riga innodb_buffer_pool_size, alla quale è stato
assegnato un valore di 256 MB).
L’operazione che ha richiesto tempi più lunghi è stata senz’altro la creazione delle
tabelle delle co-occorrenze, ognuna delle quali ha richiesto fino a 8 ore, ed alcune
molto corpose anche il doppio.
50
Conclusioni
Conclusioni
La capillare diffusione della rete internet, l’immediatezza e la semplicità di utilizzo
dei siti realizzati con nuove tecnologie (es. Ajax), e soprattutto la metamorfosi degli
utenti da semplici fruitori ad autori di contenuti ha portato ad una crescita
esponenziale del numero di informazioni oggi reperibili in rete.
Nella prima parte della monografia l’attenzione è stata focalizzata sulle
problematiche dovute a questo grande aumento di informazioni, che si ripercuotono
sugli utenti finali. Si è evidenziato quanto sia frequente trovarsi di fronte ad una
situazione di sovraccarico informativo, che disturba il reperimento delle informazioni
effettivamente desiderate dall’utente.
Nel seguito si è cercato di proporre possibili soluzioni, essenzialmente in termini di
strumenti informatici, al suddetto problema. Poichè gli algoritmi di ricerca comuni
non sono sufficienti a districarsi in una tale mole di informazioni si è pensato di
avvalersi di algoritmi di tipo semantico, che per loro natura sono più efficienti.
Questo problema si presenta sia per gli utenti che cercano informazioni
contestualizzate, sia per aziende che vogliono posizionare la loro pubblicità sul web
(content based advertising).
Nel caso specifico, si è lavorato intorno ad un algoritmo di analisi testuale
semantica, TraceSense (sviluppato da IntelliSemantic), in un’ottica di creazione di un
dataset (di metadati) utile per la valutazione dell’efficienza dell’algoritmo. Il dataset
desiderato è stato estratto dal portale web YouTube.
Il presente lavoro di tesi ha cercato di mettere in luce gli aspetti essenziali della
realizzazione di applicazioni sviluppate per interagire con i web services di un
portale multimediale.
Nella parte di contesto specifico sono state proposte alcune possibili applicazioni
pratiche per questo tipo di sistemi, e si è descritto in particolare l’ambito del content
based advertising.
Sono emerse le grandi potenzialità di questo tipo di applicazioni, come ad esempio la
possibilità di interrogare database aggiornati dei grandi portali web. La scelta di
usare le API rispetto ad un parser si rivela più semplice e più duratura nel tempo,
perchè i parser sono creati in base alla struttura di un sito in un dato momento, e
appena la struttura cambia, bisogna modificare il parser, invece le API hanno il
grande vantaggio di usare metodi abbastanza durevoli, che non vengono influenzati
dalle modifiche di strutture dei siti.
Le API, però essendo servizi forniti da grandi portali, nel caso di Youtube
gratuitamente, non permettono l’accesso a tutti i loro contenuti. YouTube impone dei
limiti al numero di risultati forniti, che ne impediscono un accesso globale.
Per aggirare questo tipo di problemi si è cercato di procedere con un approccio di
tipo incrementale, ovvero partendo da una base di metadati ottenuti in modo
omogeneo per categoria, si sono sfruttati i dati in possesso per ampliare la
51
Conclusioni
numerosità del campione, usandoli come criteri di ricerca nelle successive
interrogazioni.
Altre limitazioni consistono nell’impossibilità di decidere tra quali metadati
effettuare la ricerca (che viene sempre fatta tra tutti i metadati), e nella presenza di
numerosissimi duplicati tra i risultati, che hanno rallentato nettamente la ricerca.
È stata realizzata un’applicazione Java per raggiungere i suddetti obiettivi, che ha
permesso di ottenere un dataset di circa 9 milioni di video. Si può ritenere
soddisfacente l’esito ottenuto, sia per la mole dei dati accumulata, sia considerando il
tempo di reperimento abbastanza ragionevole; sono stati memorizzati in media circa
160 nuovi video al minuto, ovvero più di un milione e mezzo di video a settimana.
Sono inoltre state effettuate alcune analisi sui dati raccolti, che sono stati oggetto di
statistiche volte principalmente a testarne la bontà. L’obiettivo proposto è stato la
valutazione della qualità del dataset in previsione dei suoi possibili utilizzi. Si sono
realizzate analisi statistiche e sulle co-occorrenze che tendono a dimostrare che il
campione di dati estratti è comunque rappresentativo, e utile per caratterizzare i
video ed assegnarli alle rispettive categorie. Si sono raggiunti questi risultati
nonostante il metodo di estrazione non garantisca di ottenere un campione di dati
omogeneo rispetto all’insieme di partenza (a causa dei limiti imposti da YouTube), e
sebbene le caratteristiche fisiche della macchina sulla quale si è lavorato, memoria e
processore, non fossero ottimali.
Parallelamente è stato realizzato il sito web Video Content Discovery Demo, che
tramite una semplice interfaccia grafica permette di utilizzare il software TraceSense
in modo immediato, oltre ad essere stato un utile strumento di testing dell’algoritmo.
Nel sito sono racchiuse l’interazione con TraceSense, appunto, e con l’applicazione
Java descritta in questo lavoro per l’interrogazione di YouTube.
Il sito è ora disponibile all’indirizzo:
http://www.intellipatent.eu/VideoContentDiscovery/
Riassumendo, il progetto sviluppato può essere suddiviso in tre moduli concettuali:
-
un componente che si occupa di estrarre i metadati da un generico portale di
contenuti (può essere implementato attraverso le API, o attraverso il parsing)
un modulo che si occupa della metodologia di estrazione (come ad esempio lo
spidering incrementale) e di salvare i metadati nel database
un componente (in questo caso TraceSense) che elabora i metadati per
renderli utilizzabili in molteplici ambiti
Alcune possibili modifiche future sono descritte nel seguito.
Poichè TraceSense lavora con termini in inglese, potrebbe essere aggiunto alle query
di ricerca, un parametro che filtri i risultati ai paesi in cui si parla la lingua inglese,
come Stati Uniti o Gran Bretagna. In questo modo si otterrebbero prevalentemente
video con tags in inglese e quindi meglio valorizzabili dall’algoritmo di
categorizzazione.
Nell’applicazione è stata inserita la possibilità di estrarre i video a partire dagli
utenti, invece che dai tags, e qualora lo si ritenesse opportuno potrebbe essere scelta
52
Conclusioni
questa strategia per espandere ulteriormente la base dati acquisita. Inoltre, come si è
potuto verificare, poichè nel dataset sono presenti circa solo 2 video per utente
questa strategia ha dato buoni risultati in termini di velocità di espansione del
dataset.
Alcuni possibili sviluppi futuri potrebbero essere rappresentati dall’uso della lingua
italiana, o dall’uso di vocabolari tecnici specifici per settore (per il cinema, per la
nautica...), questo renderebbe possibile calibrare maggiormente l’efficacia
dell’algoritmo in ambiti più circoscritti.
Oltre ai possibili ambiti di utilizzo presentati nel capitolo 2 (content based
advertising, e-commerce, analisi di blog e altri), ovviamente gli sviluppi
implementativi possono essere molteplici in base alle funzionalità che si desidera
implementare, per cui sono possibili svariati miglioramenti e modifiche in base alle
esigenze specifiche.
53
APPENDICE
APPENDICE
Nonprofit
0%
News
3%
Tech
1%
People
6%
Travel
1%
Animals
2%
Autos
3%
Animals
Autos
Sports
7%
Comedy
11%
Comedy
Education
0%
Education
Entertainment
Film
Games
Entertainment
19%
Howto
Music
Music
37%
News
Film
7%
Nonprofit
People
Howto Games
1%
2%
Sports
Grafico 6.. Numero di video suddivisi per categoria. Calcolata su un campione dei 10.000 video più visti
Tech
1%
People
Nonprofit 5%
0%
Travel
1%
Animals
2%
Autos
3%
Animals
Autos
Sports
7%
Comedy
10%
News
5%
Education
1%
Comedy
Education
Entertainment
Film
Games
Entertainment
20%
Howto
Music
News
Music
33%
Film
6%
Nonprofit
People
Sports
Howto
3%
Games
3%
Tech
Grafico 7.. Numero di video suddivisi per categoria. Calcolata su un campione dei 10.000 video più commentati
54
APPENDICE
Tech Travel
Nonprofit
1%
0%
People
0%
4%
News
Sports
2%
5%
Animals
1%
Autos
2%
Animals
Autos
Education
1%
Comedy
11%
Comedy
Education
Entertainment
Film
Entertainment
17%
Games
Howto
Music
Music
46%
Film
7%
Games
Howto 1%
2%
News
Nonprofit
People
Sports
Tech
Miliardi di visualizzazioni
Grafico 8.. Numero di video suddivisi per categoria. Calcolata su un campione dei 10.000 video più scelti come preferiti
dagli utenti
120
100
80
60
40
20
0
Grafico 9.. Numero di visualizzazioni totali (in miliardi di visite) suddivise per categoria.. Calcolata su un milione di video
più visti
55
APPENDICE
Migliaia di tag distinti
n° di tag distinti
300
250
200
150
100
50
0
Migliaia di video
Grafico 10.. Numero di tags distinti per ogni categoria. Calcolati su 1 milione di video più visti
Distribuzione dei tag nei video
9
8
7
6
5
4
3
2
1
0
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
Grafico 11.. Distribuzione dell'assegnazione di un certo numero di tags ai video. Calcolata sui 100.000 video più visti.
Non sono stati considerati le quantità di tags presenti meno di 100 volte
56
APPENDICE
media di tag/video
18
16
14
12
10
8
6
4
2
0
Grafico 12.. Numero medio di tags per video suddiviso per categorie. Calcolato su 1 milioni di video più visti
57
Sitografia
Sitografia
Clean Cut Media - Influences of Media & Pop Culture on Our Worldview,
http://blog.cleancutmedia.com/
EJO - European Journalism Observatory, http://www.ejo.ch/
Francesco Gavello - Blog Marketing, http://francescogavello.it/
HTML.it , http://www.html.it/
IntelliSemantic - Search Engines and Semantic Solutions Provider,
http://www.intellisemantic.com/
Reelseo - The online video marketer’s guide, http://www.reelseo.com/
Uniciber - Comitato interuniversitario Base dati ed editoria in rete,
http://www.uniciber.it/
YouTube APIs and Tools, http://code.google.com/apis/youtube/overview.html
Wikipedia- L’enciclopedia libera, http://it.wikipedia.org/
58

soggia lidia - e-Lite - Politecnico di Torino

Transcript

Documenti analoghi

Come_scaricare_audio_da_youtube_R3

Clip Culture: sei tu il regista!

La Valle D`Aosta

teleacras.tv - Centro storico Agrigento

film in programmazione al duel village da venerdi 30

Google Reader ha chiuso

pdf_opera_lezione

ORIENTE FAVOLOSO

Extreme 5_11 - Il ponte dei Canais

MUSICHE ARMENE - Osteria di fuori porta