Serviciu Web de Analiza Statistica Presei Online
Lista Figurilor
Fig. 1.1.1 Rezultatul studiului referitor la conținutul media online (a) 14
Fig. 1.1.2 Rezultatul studiului referitor la conținutul media online (b) 14
Fig. 2.1.1 Bytecode-ul în limbaj de asamblare pentru „Hello World” 20
Fig. 2.5.1 Rezultatul realizării unui document XML, utilizând Jsoup (1) 26
Fig. 2.5.2 Rezultatul realizării unui document XML, utilizând Jsoup (2) 26
Fig. 2.5.3 Modelul conceptual REST 28
Fig. 3.1.1 Pagina de start a aplicației web 32
Fig. 3.1.2 Modul de selecție și de aplicare a filtrelor 32
Fig. 3.1.3 Rezultatul cererii formulate în Fig. 3.1.2 33
Fig. 3.1.4 Opțiunea de detaliere a unei porțiuni din grafic 34
Fig. 3.2.1 Schema bloc funcțională a sistemului Media Analytics 34
Fig. 3.3.1 Antetul unui feed RSS 37
Fig. 3.3.2 Conținutul canalului RSS (1) 37
Fig. 3.3.3 Conținutul canalului RSS (2) 37
Fig. 3.3.4 Lista portalurilor de știri, reprezentată în baza de date 38
Fig. 4.1.1 Structura unei liste de corespondență, utilizată în analiza conținutului vizual 46
Fig. 4.1.2 Rezultatele studiului Nielsen/SocialGuide 47
Lista Tabelelor
Tabelul 3.3.1 Lista portalurilor de știri analizate 36
Introducere
Motivația temei
Premergător realizării prezentei lucrări de diplomă, am desfășurat un studiu privitor la conținutul media online, din care a rezultat că în mediul online există o cantitate însemnată de informație, dar care este utilizată un interval de timp relativ restrâns, după care interesul utilizatorului scade, iar informațiile stocate în Internet nu se mai folosesc.
Studiul a fost realizat utilizând Google Trends API. Acesta a presupus accesarea serviciului Google Trends oferit de către Google și evidențierea interesului manifestat de publicul larg cu privire la un anumit subiect, într-un interval temporal ales arbitrar.
În cadrul studiului s-au ales următoarele date de intrare:
intervalul temporal vizat: Ianuarie 2014 – Ianuarie 2015;
regiunea vizată: România;
subiectul vizat: Simona Halep.
Google Trends este un serviciu web, proprietate a companiei Google, care pe baza motorului de căutare cu același nume, indică cât de des un anumit termen este căutat în raport cu volumul total de căutări în diferite regiuni ale lumii și în diferite limbi. Pentru vizualizarea rezultatelor este utilizat un sistem de coordonate carteziene, în care abscisa reprezintă intervalul de timp specificat, iar ordonata redă cât de des un termen este căutat în raport cu numărul total de căutari, la nivel global.
Având în vedere aceste caracteristici, Google Trends devine relevant în studiul tendințelor existente la un moment dat în mediul online. Astfel, aplicând serviciul mai sus menționat asupra datelor de intrare specificate, obținem rezultatele reprezentate în Fig. 1.1.1, respectiv Fig. 1.1.2.
Fig. 1.1.1 Rezultatul studiului referitor la conținutul media online (a)
Fig. 1.1.2 Rezultatul studiului referitor la conținutul media online (b)
Dacă luăm în considerare Fig. 1.1.1, se observă că punctul maxim de interes manifestat de către utilizatori privind subiectul Simona Halep, în intervalul temporal vizat, este înregistrat în perioada 1-7 iunie 2014, în care numărul de căutări ale termenului în raport cu volumul total de căutări în contextul regional al României, atinge valoarea limită superioară de 100. Depășind această perioadă, se inregistrează un trend descendent până la următorul eveniment definitoriu, care o are în centru pe Simona Halep.
Pe de altă parte, activând opțiunea de a arăta cele mai importante titluri ale știrilor în intervalul temporal vizat, Google Trends asociază fiecărui eveniment major, o știre dintr-un cotidian important, realizând astfel o corelație între punctele maxime de interes, respectiv evenimente importante și informațiile referitoare la acestea, stocate în mediul online. Astfel, dacă privim Fig. 1.1.2, observăm că punctul maxim de interes mai sus menționat este corelat cu un eveniment relatat într-un articol publicat online de către platforma de știri USA Today: „Maria Sharapova beats Simona Halep in French Open Final”.
Rezultatele studiului au evidențiat comportamentul consumatorului de conținut media online, dar și faptul că, aplicând acest algoritm în care corelația dintre un eveniment important și informațiile referitoare la acesta se face prin asocierea în mod aleator a unei știri cu evenimentul respectiv, se ajunge în situația în care o cantitate însemnată de informație stocată online nu mai este folosită ulterior.
În acest context, este necesară realizarea conceptuală și implementarea unui serviciu web de achiziție și analiză statistică a conținutului media online, care să permită stocarea unei cantități însemnate de informație într-o bază de date și analiza ulterioară a acesteia. Serviciul web și-ar demonstra utilitatea în situația în care o companie ar vrea să vadă ce impact produce o campanie de marketing în presa online și implicit cum influențează aceasta interesele companiei (i.e., este vorba despre realizarea unor corelații între subiecte). De asemenea, acest sistem de analiză ar putea fi utilizat în mod subiectiv, atunci când de pildă un politician vrea să vadă cât de des este menționat în articolele de știri, în campania electorală.
Se vizează realizarea unui sistem expus utilizatorului sub forma unui serviciu web ce poate fi accesat programatic, în sensul că un utilizator poate avea acces la acesta folosind diferite utilitare software. În cadrul acestei lucrări de diplomă s-a implementat o interfață web care exemplifică funcționalitatea unui astfel de sistem.
Obiective
În contextul în care în mediul online există o însemnată cantitate de informație media, folosită un interval temporal determinat doar de comportamentul utilizatorului, este necesară realizarea conceptuală și implementarea unui serviciu web de achiziție și analiză statistică a conținutului media online, care să permită stocarea unei cantități însemnate de informație într-o bază de date și analiza ulterioară a acesteia, ilustrând totodată conceptul de „big data”. „Big data” descrie seturi ample de date, care pot fi analizate programatic, pentru a descoperi modele, tendințe și asocieri, în special cu privire la comportamentul uman și la interacțiunile interumane.
Obiectivul central al acestei lucrări de diplomă este de a expune utilizatorului, prin intermediul unei interfețe web, diferite opțiuni de analiză asupra conținutului media achiziționat în prealabil și stocat într-o bază de date (i.e., vezi CAPITOLUL 4, subsecțiunea 4.1). Dintre acestea amintim: analiza sentimentelor, realizarea unor corelații, sau chiar metoda de counting.
De altfel, prezenta lucrare de diplomă își propune ca pe lângă realizarea conceptuală și implementarea sistemului de analiză a presei scrise online, să asigure corpusul de text necesar în proiecte ulterioare, ce vizează dezvoltarea sistemelor de recunoastere automată a vorbirii. În corelație cu activitatea desfășurată de laboratorul de cercetare SpeeD (Speech and Dialogue), analiza ar putea fi extinsă la presa audiovizuală. Astfel s-ar putea dezvolta un sistem care în loc să achiziționeze corpus de text, ar face achiziția și analiza de conținut audiovizual (i.e., articole de știri în format video și/sau audio).
Sumarizarea lucrării de diplomă
În secțiunea curentă a acestei lucrări de diplomă a fost discutată motivația care a condus la realizarea acestei lucrări, dar și principalele obiective urmărite.
Capitolul 2 urmărește introducerea unor noțiuni generice despre tehnologiile software utilizate în realizarea proiectului.
Capitolul 3 va fi oferi o privire de ansamblu asupra sistemului Media Analytics, în sensul că va fi prezentat modul în care sistemul de analiză este expus utilizatorului, arhitectura sistemului, dar și componenta ce vizează achiziția datelor.
Capitolul 4 urmărește să scoată în evidență contribuțiile personale ale studentului, prezentând în detaliu componenta ce vizează analiza datelor, generarea și vizualizarea rezultatelor.
Capitolul 5 reprezintă ultima parte a lucrării de diplomă și va cuprinde o secțiune de concluzii la care s-a ajuns în urma realizării proiectului de diplomă, o secțiune ce presupune rezumarea contribuțiilor personale ale studentului, respectiv o ultimă secțiune în care sunt prezentate eventualele îmbunătățiri și funcționalități ce pot fi adăugate ulterior sistemului.
Tehnologii software
Java
Java este un limbaj de programare de uz general, concurent, bazat pe clase, obiect-orientat și special conceput astfel încât sa aibă cât mai puține dependențe de implementare. Acesta a fost menit să permită dezvoltatorilor de aplicații să scrie o singură dată codul, ca mai apoi să poată rula aplicația oriunde – este vorba despre conceptul WORA („write once, run anywhere”), ce presupune ca o aplicație Java al cărei cod a fost compilat în prealabil, să poată fi rulată pe orice platformă care suportă JVM (Java Virtual Machine), fără a fi nevoie de o recompilare a codului.
Prin caracterul său inovativ, Java aduce laolaltă proprietăți prezente în alte limbaje de programare, dintre care amintim:
obiect-orientat;
portabil;
securizat;
capabil să ruleze mai multe fire de execuție;
aplicabil în Internet;
ușor de utilizat.
În continuare, voi prezenta ce impact are fiecare dintre aceste proprietăți în realizarea unui proiect software de mare anvergură.
Obiect-orientat
Multe limbaje pioniere, precum C și Pascal, au fost limbaje de programare procedurale. Procedurile (adesea numite funcții) erau blocuri de cod care făceau parte dintr-un modul sau dintr-o aplicație. Procedurile primeau parametri, de regulă tipuri primitive de date, cum ar fi tipuri întregi, caractere, șiruri de caractere, valori în virgulă mobilă. Deoarece codul era tratat separat față de date, apărea necesitatea utilizării structurilor de date, iar procedurile iși puteau schimba oricând conținutul. Aceasta a constituit o sursă de apariție a problemelor, întrucât anumite proceduri puteau avea efecte neprevăzute asupra altor zone ale programului, iar depistarea procedurii care producea aceste probleme implica un consum semnificativ de timp, în special în cazul programelor mari.
Java este un limbaj de programare obiect-orientat. Un astfel de limbaj manipulează obiecte, care conțin atât date (variabile membru), cât și cod (metode). Fiecare obiect aparține unei anumite clase, care este o schiță ce descrie ce variabile membru și ce metode poate oferi acel obiect. În Java, aproape fiecare variabilă este un obiect de un anumit tip sau altul – de exemplu String.
În prezent există o serie de limbaje de programare orientate pe obiect. Unele dintre ele, cum ar fi Smalltalk sau Java sunt proiectate din start sa fie orientate pe obiect, spre deosebire de altele, cum ar fi C++, care este hibrid, parțial obiect-orientat și parțial procedural. In C++ încă se pot suprascrie conținutul structurilor de date și obiectele, cauzând defectarea aplicației. Java, în schimb, interzice accesul direct în memorie, ceea ce il face un sistem mult mai robust.
Portabil
Majoritatea limbajelor de programare sunt proiectate pentru un anumit tip de microprocesor, respectiv pentru un anumit sistem de operare. Atunci când codul sursă este compilat, este de fapt convertit în cod mașină, care poate fi executat doar pe un anumit tip de microprocesor, acest cod fiind extrem de rapid.
Pe de altă parte, există și limbaje de programare care produc cod interpretabil. Codul este citit de o aplicație software (interpretorul), care realizează operații specifice asupra acestuia. De multe ori, codul interpretat nu are nevoie să fie compilat – acesta este translatat în cod masină pe masură ce este executat. Din acest motiv, codul interpretat este destul de lent, dar de multe ori portabil pe diferite sisteme de operare și arhitecturi de microprocesor.
Java preia avantajele celor două tehnici, astfel că un cod Java este compilat într-un cod mașină independent de platforma de rulare, care este numit Java bytecode. Un interpretor special, numit Java Virtual Machine (JVM), citește bytecode-ul și îl procesează. Fig. 2.1.3 arată codul de asamblare al unei aplicații simple Java. În cazul acesta, bytecode-ul indicat prin săgeată este reprezentat sub formă de text, însă atunci când este compilat, va fi reprezentat sub formă de bytes, pentru a conserva spațiul.
Fig. 2.1.3 Bytecode-ul în limbaj de asamblare pentru „Hello World”
Modul de abordare al Java oferă anumite avantaje spre deosebire de alte limbaje de programare care produc cod interpretabil. În primul rând, codul sursă este protejat, astfel că nu poate fi văzut sau modificat – doar bytecode-ul este vizibil utilizatorilor. În al doilea rând, mecanismele de securitate pot scana bytecode-ul în vederea verificării modificărilor survenite sau dacă codul este malițios, complementând astfel celelalte mecanisme de securitate ale Java. În plus, un cod sursă Java poate fi compilat o singura data, dupa care poate rula pe orice sistem ce suporta JVM (i.e., este vorba despre principiul „write once, run anywhere”). O aplicație este portabilă atunci când nu este necesară decât scrierea acesteia o singură dată, dupa care poate fi rulată pe o gamă largă de sisteme.
Securizat
Deoarece applet-urile Java sunt descărcate de la distanță și executate într-un browser, securitatea datelor este de mare interes în Java. Bineînțeles că nu este de dorit ca applet-urile să acceseze documentele personale sau să șteargă fișierele utilizatorilor.
La nivel de API există restricții puternice de securitate asupra applet-urilor în ceea ce privește manipularea fișierelor și accesul în rețea, precum și suport pentru semnături digitale pentru a verifica integritatea codului descărcat, iar la nivel de bytecode se fac verificări evidente privitoare la acțiuni malițioase, cum ar fi manipularea stivei sau bytecode invalid.
În Java, mecanismele de securitate asigură protecția împotriva încălcărilor accidentale sau intenționate de securitate, dar este important de precizat că niciun sistem nu este perfect. Cea mai slabă verigă din lanțul sistemului este reprezentată de JVM, deoarece o mașină virtuală cu deficiențe de securitate cunoscute este predispusă la atacuri informatice.
Capabil să ruleze mai multe fire de execuție
În C există conceptul de procese multiple. O aplicație se poate împărți în mai multe copii separate, care rulează simultan. Fiecare copie reproduce codul și datele, rezultând în creșterea consumului de memorie, iar crearea fiecărui proces implică un apel către sistemul de operare, care consumă deopotrivă ciclii suplimentari.
O abordare mult mai bună este de a utiliza mai multe fire de execuție, denumite pe scurt threaduri, care folosesc mai puțină memorie și totodată solicită mai puțin microprocesorul. Java are suport pentru multiple fire de execuție, implementat chiar in limbaj. Acest suport este ușor de folosit în Java, iar implementarea de threaduri în aplicații și applet-uri este destul de uzuală.
Aplicabil în Internet
Java a fost proiectat să susțină programarea în Internet. Java API asigură suport extins pentru rețea, de la socket-uri și adrese IP, până la URL(Uniform Resource Locator) și HTTP (Hyper Text Transfer Protocol). Dezvoltarea unei aplicații web în Java este relativ simplă, iar codul este complet portabil între diferite platforme de lucru.
Java include de asemenea suport pentru programare mai complexă în Internet, cum ar fi remote-method invocation (RMI), CORBA și Jini. Aceste tehnologii de sisteme distribuite fac din Java o alegere atractivă pentru sistemele distribuite de mare amploare.
Ușor de utilizat
Java a fost dezvoltat pornind de la limbajul C++, considerat a fi un limbaj de programare complex, cu caracteristici precum moștenirea multiplă, șabloane și pointeri, care sunt elemente contraproductive. Java, pe de altă parte, este mai apropiat de un limbaj obiect-orientat „pur”. Accesul la pointeri de memorie a fost eliminat, utilizând în schimb referințe către obiecte. De asemenea suportul pentru moștenirea multiplă a fost îndepărtat, ceea ce implică o viziune mult mai clară în ceea ce privește realizarea și utilizarea claselor.
În contextul Java, interfața de programare a aplicațiilor (API), este o colecție predefinită de pachete, clase și interfețe cu metodele, câmpurile și constructorii acestora. Similar unei interfețe cu utilizatorul, ce facilitează interacțiunea dintre om și computer, un API poate fi considerat o interfață software care facilitează interacțiunea.
În Java, cele mai comune sarcini de programare sunt realizate prin intermediul claselor și pachetelor din API, care sunt utile în minimizarea numărului de linii scrise în porțiunile de cod.
Java Development Kit (JDK) este format din trei componente de bază, după cum urmează:
Compilatorul Java;
Mașina virtuală Java (JVM);
Interfața de programare a aplicațiilor în Java (API).
Interfața de programare a aplicațiilor în Java, inclusă în JDK, descrie funcția fiecărei componente constituente – o mare parte dintre aceste componente sunt predefinite și utilizate frecvent. Astfel, programatorul este capabil să utilizeze codul prescris, prin intermediul API-ului Java. După referirea claselor și pachetelor disponibile din API, programatorul poate apela foarte ușor codul asociat acestora, necesar implementării.
În afara faptului că API-urile ajută programatorii să determine funcțiile claselor și pachetelor, prin intermediul acestora pot fi determinați parametri sau alte informații necesare implementării codului Java predefinit în cadrul acelor API.
Sumarizând cele prezentate în această sub-secțiune, Java oferă dezvoltatorilor software multe avantaje. În timp ce o mare parte dintre acestea sunt prezente în alte limbaje de programare, Java le combină într-un singur limbaj, îndeplinind toate criteriile necesare implementării unui proiect software complex.
Web crawlers, RSS feeds
Un crawler web este o aplicație software independentă care navighează sistematic prin Internet, de obicei cu scopul de a indexa paginile web. El mai este numit și "Web spider", "Automatic Indexer" sau "Web Scutter". Motoarele de căutare utilizează un astfel de serviciu pentru a-și actualiza conținutul din baza de date și pentru actualizarea indecșilor unor site-uri web. De asemenea crawler-ele pot fi folosite pentru validarea ancorelor web sau a codului HTML.
Un crawler web pornește de obicei de la o listă cu legături ale unor pagini web pe care trebuie să le viziteze. Pe măsură ce crawler-ul vizitează o pagină web, identifică toate legăturile din acea pagină, și le adaugă în lista de legături pe care urmează să le viziteze. Paginile pot fi vizitate recursiv după un anumit set de reguli.
Un volum mare de date implică o limitare a crawler-ului la a descărca un număr limitat de pagini web într-un anumit timp, așa că el este nevoit să prioritizeze ordinea de parsare și descărcare a paginilor web. De asemenea generarea legăturilor pe partea de server aduce o nouă dificultate crawler-elor web, deoarece acestea pot ajunge să descarce pagini duplicate.
Prin urmare, un crawler realizează „harta” unui site web, punând la dispoziția utilizatorului, sub forma unui arbore ierarhic, toate legăturile către paginile ce intră în componența site-ului web. Totuși, această abordare nu este potrivită atunci când se dorește automatizarea unui proces de achiziție, deoarece un crawler web nu oferă opțiuni de condiționare a introducerii de conținut nou în baza de date, rezultând la fiecare rulare ulterioară a procesului, conținut duplicat (i.e., vezi CAPITOLUL 3, subsecțiunea 3.3).
Pe de altă parte, RSS (Rich Site Summary) este o familie de formate de fluxuri web, realizate în format XML și folosite pentru Web Syndication. RSS este folosit (printre altele) pentru știri, weblog-uri și podcasting.
Web feed-urile oferă conținut web sau sumare de conținuturi web, împreună cu legături către conținutul complet al respectivei surse de informații și alte metadate. RSS oferă această informație sub forma unui fișier XML, numit feed RSS, webfeed, stream RSS sau canal RSS.
În plus, față de facilitarea partajării știrilor (termen american: "syndication"), feed-urile web permit cititorilor fideli anumitor pagini să fie informați la actualizarea conținutului de pe aceste pagini web, prin folosirea unui soft special numit aggregator.
În timp ce partea cea mai importantă a mass-mediei încă încearcă să înțeleagă potențialul RSS, redactorii de știri folosesc RSS ca să ocolească sursele de știri tradiționale. Prin sistemul RSS, utilizatorii și jurnaliștii au la dispoziție surse constante de știri, fără să mai fie nevoiți să petreacă timp căutând.
Din punct de vedere programatic, informațiile structurate sub forma unui fișier XML pot fi extrase relativ ușor printr-un proces de parsare a fișierului, folosind un API Java specializat. Acest subiect va fi detaliat în secțiunea care vizează achiziția datelor.
Baze de date, PostgreSQL
În sensul cel mai larg, o bază de date reprezintă o colecție de date corelate din punct de vedere logic, care reflectă un anumit aspect al lumii reale și este destinată unui anumit grup de utilizatori. În acest sens, bazele de date pot fi create și menținute manual (e.g, fișele de evidență a cărților dintr-o bibliotecă, așa cum erau folosite cu ani în urmă) sau computerizat, așa cum sunt majoritatea bazelor de date folosite în momentul de față. O definiție într-un sens mai restrâns a unei baze de date este următoarea:
O bază de date este o colecție de date creată și menținută computerizat, care permite operații de introducere, ștergere, actualizare și interogare a datelor.
Față de vechile metode de înregistrare a datelor privind diferite activități pe documente scrise sau chiar în fișiere pe disc, sistemele de baze de date oferă avantaje considerabile, ceea ce explică utilizarea extinsă a acestora. Câteva dintre avantajele oferite sunt prezentate în continuare.
Compactitate ridicată: volumul ocupat de sistemele de baze de date este mult mai redus decât volumul ocupat de documente scrise sau de fișiere necorelate.
Viteză mare de regăsire și actualizare a informațiilor.
Redundanța scăzută a datelor memorate, care se obține prin partajarea datelor între mai mulți utilizatori și aplicații. În stocarea pe fișe sau în fișiere a datelor, fiecare aplicație conținea propriile seturi de date. În sistemele de baze de date, mai multe aplicații pot folosi date comune, memorate o singură dată. De exemplu, o aplicație de personal și o aplicație de rezultate la examene dintr-o universitate care exploatează o singură bază de date, pot folosi aceleași informații referitoare la structurarea facultăților și a secțiilor.
Posibilitatea de introducere a standardelor privind modul de stocare a datelor, ceea ce permite interschimbul informațiilor între diferite organizații.
Menținerea integrității datelor prin politica de securitate (drepturi de acces diferențiate în funcție de rolul utilizatorilor), prin gestionarea tranzacțiilor și prin refacerea datelor în caz de funcționare defectuoasă a diferitelor componente hardware sau software.
Independența datelor față de suportul hardware utilizat: sistemele de gestiune a bazelor de date oferă o vedere externă a datelor, care nu se modifică atunci când se schimbă suportul de memorare fizic, ceea ce asigură imunitatea structurii bazei de date și a aplicațiilor la modificări ale sistemului hardware utilizat.
PostgreSQL este un sistem de gestionare a bazelor de date relaționale, care pune accent pe extensibilitate și asigurarea conformității cu standardele. Ca server de baze de date, funcția sa principală este de a stoca datele în siguranță și de a pune la dispoziția altor aplicații software aceste date, atunci când sunt formulate cereri în această privință. Poate trata sarcini de lucru, de la aplicații ce vizează un singur computer, până la aplicații ample, care rulează în Internet și implică accesarea concurentă de către mai mulți utilizatori a aceleași baze de date.
PostgreSQL implementează majoritatea standardelor SQL:2011 și oferă o serie de avantaje care vin în sprijinul dezvoltatorilor software, în detrimentul altor sisteme de gestionare a bazelor de date.
Fiind un sistem open-source de gestionare a bazelor de date relaționale, PostgreSQL nu este controlat de nicio corporație sau orice altă entitate privată, punând la dispoziția utilizatorilor codul sursă al sistemului. Prin aceasta, PostgreSQL preîntâmpină problemele legate de supra-implementare vizate de unii furnizori de baze de date proprietare și permite dezvoltatorilor să realizeze cercetări de concept și numeroase implementări provizorii, fără a impune costuri de acordare a licenței software.
De asemenea, acest sistem de gestionare a bazelor de date oferă fiabilitate și stabilitate, acesta fiind un avantaj major atunci când se dorește implementarea unor soluții software expuse utilizatorilor sub forma unui serviciu. În plus, Postgres este aplicabil tuturor platformelor (i.e., este cross-platform), fiind nativ compatibil cu aproape orice sistem Unix și Windows și este conceput pentru medii de lucru ce implică un volum mare de date (i.e., folosește o strategie de stocare a datelor bazată pe versionarea înregistrărilor pentru evitarea problemelor de concurență, numită MVCC – Multiversion Concurrency Control).
Servicii de indexare a datelor
Conceptul de indexare folosit pentru căutarea datelor este definit ca fiind procesul de adnotare a informației existente într-o colecție de date, prin adăugarea de informații suplimentare relative la conținutul acesteia, informații numite și indici de conținut. Această etapă este necesară accesării colecției de date, deoarece permite catalogarea automată în funcție de conținut a datelor.
Așadar, un index dintr-o bază de date reprezintă o structură de date care sporește viteza operațiilor de interogare cu scopul de a recupera datele, în detrimentul creșterii capacității de stocare necesară menținerii structurii de indecși.
Sistemele de gestionare a bazelor de date relaționale precum MySQL, dispun de un serviciu de indexare a datelor de tip „Full Text”. Acesta este rapid, însă nu este la fel de ușor de configurat precum librăriile dedicate, compatibile Java (e.g., Apache Lucene).
Apache Lucene este o librărie software open source, care oferă servicii de extragere a datelor dintr-o colecție de date (i.e., indexare, căutare, ierarhizare a rezultatelor), scrisă inițial în Java de către Doug Cutting și adaptată ulterior altor limbaje de programare, inclusiv C#, C++, Python, Ruby, PHP, Perl și Delphi. În timp, s-a dovedit a fi adecvată pentru orice aplicație care necesită implementarea unui serviciu de indexare și căutare într-o bază de date. Lucene a fost recunoscut pentru utilitatea sa în implementarea motoarelor de căutare în Internet, dar și local, pe un singur site.
Elementele fundamentale care stau la baza Lucene sunt: indexul, documentul, câmpul și termenul.
Un index conține o secvență de documente.
Un document conține o secvență de câmpuri.
Un câmp conține o secvență de termeni.
Un termen este un șir de caractere.
În momentul în care se dorește indexarea datelor, este creat un index ce va fi populat cu elemente de tip document. Elementele de tip document vor conține câmpurile după care se indexează colecția de date, denumite arbitrar de către utilizator și având în componență elemente de tip text: pereche de șiruri de caractere, primul fiind numele câmpului, iar cel de-al doilea textul cuprins în câmpul respectiv – astfel sunt luați în evidență termenii asupra cărora se vor realiza cereri de căutare.
Indecșii Lucene se încadrează în familia de indecși cunoscuți ca „indecși inversați”. Acest lucru se datorează faptului că indecșii pot lista, pentru un anumit termen, documentele care îl conțin, iar această abordare este inversă relației naturale, în care documentele listează termeni, tocmai pentru a accelera procesul de căutare într-o bază de date indexată.
În contextul prezentei lucrări de diplomă, Lucene s-a dovedit a fi adecvat procesului de indexare desfășurat asupra bazei de date populate în prealabil cu conținut media. Aceasta datorită flexibilității în implementare și caracteristicilor sale particulare. În schimb, menținerea indecșilor unei astfel de baze de date implică duplicarea datelor și stocarea acestora pe disc, ceea ce presupune asigurarea unui spațiu de stocare considerabil și reprezintă dezavantajul major al unui astfel de serviciu.
XML, HTML, JS, REST
XML (Extensible Markup Language), descendent al SGML (Standard Generalized Markup Language) este un meta-limbaj utilizat în activitatea de marcare structurală a documentelor. Acesta definește un set de reguli pentru crearea formatelor text ce permit structurarea datelor, scopul său primar fiind de a pune accent pe simplitate, universalitate și ușurința utilizării sale în Internet. Deși XML se concentrează în principal pe documente, acesta este utilizat pe scară largă pentru reprezentarea structurilor de date arbitrare, cum ar fi cele utilizate în serviciile web.
Un document XML este format din marcaje (tag-uri) și date caracter și este structurat sub forma unui arbore ierarhic. Cuvântul marcaj (markup) a fost folosit inițial pentru a descrie anumite adnotări (i.e., note marginale în cadrul unui text) cu intenția de a indica tehnoredactorului cum trebuie listat un anumit pasaj. Generalizând, marcajul poate fi definit drept orice acțiune de a interpreta explicit o porțiune de text. Un marcaj (tag) este un șir de caractere delimitat de caracterele "<" și ">" (e.g., nodul rădăcină, descendenții acestuia, atributele fiecărui element). Datele caracter reprezintă conținutul marcajelor. Un exemplu al utilizării marcajelor în cadrul unui fișier XML poate fi vizualizat în Fig. 2.5.4, respectiv Fig. 2.5.5.
Orice aplicație XML derivă dintr-un fișier text și poate fi creată foarte simplu utilizând orice editor de text, în care se include marcajul specific XML: <?xml version='2.0' encoding='utf-8'?> pentru a specifica tipul documentului, precum și marcajul ce definește arbitrar nodul rădăcină: <news-counts> … </news-counts> sau <metadata> … </metadata>, conform exemplelor prezentate în Fig. 2.5.4, respectiv în Fig. 2.5.5.
Pe de altă parte, dacă se dorește dezvoltarea unei aplicații ce necesită structurarea și actualizarea permanentă a datelor, dacă se ia în considerare folosirea XML, atunci utilizarea editoarelor de text nu mai reprezintă o soluție viabilă. Există în acest scop utilitare Java capabile să creeze, să actualizeze și să parcurgă documentele XML pentru a oferi rezultate concludente utilizatorului (e.g., XML DOM Parser, Jsoup). În informatică, parcurgerea și analizarea unui text, cu identificarea atomilor care îi corespund, în raport cu o gramatică formală poartă numele de parsare. Un parser este o componentă a unui interpretor sau compilator, în cadrul cărora identifică structura textului de intrare și o aduce într-o formă potrivită pentru prelucrări ulterioare. În conjucție cu utilizarea formatului XML, prin parsare pot fi extrase sub formă de text valorile atributelor aflate sub incidența anumitor marcaje. Dacă considerăm ca exemplu documentul XML prezentat în Fig. 2.5.5, pot fi extrase prin parsare valorile atributelor count, respectiv date, ce intră sub incidența marcajului <item></item> și mai departe valorile atributelor link și title aflate sub incidența marcajului <news></news>.
Bineînțeles, folosind astfel de utilitare, se poate pleca de la proiectarea unui model simplu de document XML, conform Fig. 2.5.4 și se poate ajunge la forme complexe ale documentului XML, conform Fig. 2.5.5.
Fig. 2.5.4 Rezultatul realizării unui document XML, utilizând Jsoup (1)
Fig. 2.5.5 Rezultatul realizării unui document XML, utilizând Jsoup (2)
HTML (HyperText Markup Language) este o formă de marcare orientată către prezentarea documentelor text pe o singura pagină, utilizând un software de redare specializat, numit agent utilizator HTML, cel mai bun exemplu de astfel de software fiind browserul web. HTML furnizează mijloacele prin care conținutul unui document poate fi adnotat cu diverse tipuri de metadate și indicații de redare. Indicațiile de redare pot varia de la decorațiuni minore ale textului, cum ar fi specificarea faptului că un anumit cuvânt trebuie subliniat sau că o imagine trebuie introdusă, până la scripturi sofisticate, hărți de imagini și formulare. Metadatele pot include informații despre titlul și autorul documentului, informații structurale despre cum este împărțit documentul în diferite segmente, paragrafe, liste, titluri etc. și informații cruciale care permit ca documentul să poată fi legat de alte documente pentru a forma astfel hiperlink-uri (sau web-ul).
Ca și în cazul XML, un document HTML poate fi citit și editat utilizând un editor de text simplu. Totuși scrierea și modificarea paginilor în acest fel solicită cunoștințe solide de HTML și este consumatoare de timp. Editoarele grafice cum ar fi Macromedia Dreamweaver, Adobe GoLive sau Microsoft FrontPage permit ca paginile web sa fie tratate asemănător cu documetele Word, dar cu observația că aceste programe generează un cod HTML care este de multe ori de proastă calitate.
Componența unui document HTML este:
versiunea HTML a documentului
zona head cu etichetele <head></head>
zona body cu etichetele <body><body> sau <frameset></frameset>
Toate paginile HTML încep și se termină cu etichetele <html> și </html>. În interiorul acestor etichete găsim perechile <head>, </head> și <body>, </body>. head conține titlul paginii între etichetele <title> și </title>, descrieri de tip <meta>, stiluri pentru formatarea textului, script-uri și legături către fisiere externe (de exemplu script-uri, fișiere de tip CSS sau favicon). Etichetele de tip meta conțin cuvinte cheie, descrierea paginii, date despre autor, informații utile motoarelor de căutare și au următorul format: <META NAME=”nume” CONTENT=”continut”>, iar body găzduiește practic toate etichetele afișate de browser pe ecran.
Elementele de marcare în HTML pot descrie o marcare structurală (e.g., <h1></h1>), o marcare pentru prezentare (e.g., <strong></strong>), marcare pentru hyperlink sau pot descrie elemente speciale (i.e., widget).
În contextul realizării sistemului de analiză a presei scrise online, utilizarea formatului HTML a vizat atât extragerea integrală a textului și a metadatelor (e.g., autor, categorie) din paginile HTML ale știrilor, folosind pentru parsare utilitarul Jsoup, cât și crearea paginii web a aplicației folosind NetBeans și descrierea manuală a documentului HTML.
JS (JavaScript) este un limbaj de programare obiect orientat, bazat pe conceptul prototipurilor. Este folosit mai ales pentru introducerea unor funcționalități în paginile web, codul Javascript din aceste pagini fiind rulat de către browser. Limbajul este binecunoscut pentru folosirea sa în construirea siturilor web, dar este folosit și pentru accesul la obiecte încastrate (embedded objects) în alte aplicații.
Cea mai des întâlnită utilizare a JavaScript este în scriptarea paginilor web. Programatorii web pot îngloba în paginile HTML script-uri pentru diverse activități cum ar fi verificarea datelor introduse de utilizatori sau crearea de meniuri și alte efecte animate.
Browserele rețin în memorie o reprezentare a unei pagini web sub forma unui arbore de obiecte și pun la dispoziție aceste obiecte script-urilor JavaScript, care le pot citi și manipula. Arborele de obiecte poartă numele de Document Object Model sau DOM. Există un standard W3C pentru DOM-ul pe care trebuie să îl pună la dispoziție un browser, ceea ce oferă premiza scrierii de script-uri portabile, care să funcționeze pe toate browserele. În practică, însă, standardul W3C pentru DOM este incomplet implementat. Deși tendința browserelor este de a se alinia standardului W3C, unele din acestea încă prezintă incompatibilități majore, cum este cazul Internet Explorer.
O tehnică de construire a paginilor web tot mai întâlnită în ultimul timp este AJAX, abreviere de la „Asynchronous JavaScript and XML”. Această tehnică constă în executarea de cereri HTTP în fundal, fără a reîncărca toată pagina web, și actualizarea numai anumitor porțiuni ale paginii prin manipularea DOM-ului paginii. Tehnica AJAX permite construirea unor interfețe web cu timp de răspuns mic, întrucît operația (costisitoare ca timp) de încărcare a unei pagini HTML complete este în mare parte eliminată.
REST este acronimul de la Representational State Transfer și reprezintă un model architectural pentru crearea serviciilor web.
Serviciile web de tip REST folosesc toate componentele ce au făcut web-ul un mare succes, aplicând arhitectura web-ului asupra serviciilor web. Deși REST nu este un standard, el se folosește de standarde (e.g., HTTP, URI – Uniform Resource Identifier, XML/HTML/JPEG). Practic REST presupune construirea unui serviciu web folosind HTTP, XML și URI așa cum a fost construit și web-ul.
În REST este vorba despre arhitectură, nu despre design. REST este un set de reguli la care o arhitectură ar trebui să se conformeze. Pentru că nu este suficient de detaliat pentru a defini o arhitectură reală vom spune despre REST că este un stil arhitectural. Web-ul este un exemplu real de arhitectură care urmează în linii mari regulile REST.
O arhitectură este construită din diferite componente proiectate (design pieces). Aceste componente interacționează unele cu altele, în diverse moduri. Orice componentă poate trimite un mesaj la orice altă componentă iar regulile referitoare la semnificația mesajului sau felul în care mesajul este tratat să rămână la latitudinea emițătorului și receptorului.
Într-o arhitectură REST se deosebesc două trăsături importante :
datele asupra cărora clientul îi spune serverului să opereze se află în URI
operația pe care serverul o face asupra datelor este descrisă direct de metoda HTTP
REST este o altă abordare a serviciilor web. Din punct de vedere tehnic, arhitectura de tip REST se descrie prin câteva noțiuni de bază : resursă, URI, reprezentare, interfață uniformă. Într-o arhitectură de tip REST totul este o resursă. Orice poate fi referit ca un obiect este o resursă. În general tot ce poate fi stocat în calculator și reprezentat ca un flux de octeți este o resursă. Legarea acestor componente într-un mod cât mai eficient duce la crearea unei arhitecturi REST. O imagine de ansamblu asupra serviciilor de tip REST este prezentată în diagrama de mai jos:
Fig. 2.5.6 Modelul conceptual REST
REST a fost utilizat în conjucție cu JavaScript pentru implementarea funcției de analiză a sistemului descris în această lucrare de diplomă.
O privire de ansamblu asupra sistemului. Achiziția datelor
Având în vedere motivația temei de diplomă, precum și obiectivele prezentate în CAPITOLUL 1, pentru a spori gradul de utilizare a conținutului media online, este necesară realizarea conceptuală și implementarea unui serviciu web de achiziție și analiză statistică a acestui tip de informație. În continuare, vom numi acest serviciu web: Media Analytics.
Funcționalitatea sistemului
Media Analytics este expus utilizatorului sub forma unei pagini web (i.e., aplicație web), care realizează interfața dintre acesta și componenta de analiză. Această pagină poate fi vizualizată prin accesarea linkului următor: http://dev.speed.pub.ro:10082/MediaAnalytics-Search/ .
Pentru exemplificarea funcției de analiză asupra datelor, utilizatorul are la dispoziție o fereastră de căutare care conține o serie de opțiuni pentru filtrarea rezultatelor: selectarea portalului de știri, selectarea categoriei, dar și a intervalului temporal pentru care se dorește analiza datelor.
În momentul de față, utilizatorul serviciului are la dispoziție trei portaluri de știri asupra cărora se poate desfășura procesul de analiză: Adevărul.ro, Wall-Street.ro, respectiv Evz.ro. De asemenea, pentru fiecare ziar în parte, au fost extrase categoriile, astfel încât să fie posibilă aplicarea de filtre și pe acestea.
Bineînțeles, dacă se dorește analiza asupra tuturor ziarelor, respectiv tuturor categoriilor, aplicația web pune la dispoziția utilizatorului opțiunea de a selecta toate ziarele, respectiv toate categoriile.
Intervalul temporal asupra căruia poate fi desfășurată analiza datelor nu depinde de data publicării articolelor achiziționate în prealabil, însă pentru obținerea unor rezultate concludente este de preferat să avem în vedere ceea ce se află stocat în baza de date. În momentul de față, baza de date conține articole publicate în cele trei ziare, începând cu data de 1 ianuarie 2012. Baza de date este actualizată constant, prin intermediul funcției de achiziție automată a articolelor. Fig. 3.1.7 prezină pagina de start a aplicației web, iar Fig. 3.1.8 prezintă modul de selecție și de aplicare a filtrelor.
Fig. 3.1.7 Pagina de start a aplicației web
Fig. 3.1.8 Modul de selecție și de aplicare a filtrelor
Odată ce utilizatorul a creat structura de filtre dorită, selectând în primul rând termenul/termenii căutați, apoi portalul/portalurile de știri, categoria și intervalul de timp vizat, poate lansa cererea către serviciul de analiză a presei scrise online prin apăsarea „butonului” Search. Serverul va întoarce în pagină rezultatul cererii, care va fi afișat în cadrul unui grafic. Pentru acest grafic, abscisa reprezintă intervalul de timp vizat, iar ordonata redă numărul de articole în care au fost găsiți termenii căutați, pentru fiecare zi din intervalul specificat. Rezultatul cererii formulate în Fig. 3.1.8 poate fi vizualizat în Fig. 3.1.9.
Fig. 3.1.9 Rezultatul cererii formulate în Fig. 3.1.2
Din figura de mai sus, se poate observa că intereseul opiniei publice, exprimat prin intermediul articolelor din presa scrisă online, este concentrat pe mai multe intervale temporale, înregistrând un vârf în data de x (de modificat cand schimb imaginea). Acest lucru poate fi urmărit prin selectarea punctelor înregistrate pe grafic, pentru fiecare zi în parte (e.g., Fig. 3.1.10).
Utilizatorul are opțiunea de a mări orice zonă de pe grafic pentru a inspecta în detaliu rezultatul oferit. Acest lucru se poate face atât prin folosirea butonului Zoom poziționat în partea stânga sus, cât și prin derularea convenabilă a intervalului temporal, utilizând instrumentele din partea de jos a graficului.
Atât urmărirea pantelor înregistrate pe grafic, cât și opțiunea de zoom pot fi vizualizate în Fig. 3.1.10.
În această sub-secțiune a fost detaliat modul în care serviciul Media Analytics este expus utilizatorului. Prin interfața web intuitivă și ușor de utilizat, acesta poate efectua o analiză bazată pe metoda de tip counting (i.e., vezi CAPITOLUL 1, subsecțiunea 4.1.3). Rezultatul analizei poate fi vizualizat prin intermediul unui grafic afișat în cadrul paginii web.
Fig. 3.1.10 Opțiunea de detaliere a unei porțiuni din grafic
Arhitectura sistemului
Schema bloc functionala a sistemului „Media Analytics” este descrisa in Fig. 3.2.11.
Fig. 3.2.11 Schema bloc funcțională a sistemului Media Analytics
Media Analytics este un sistem complex de achiziție și analiză a presei scrise online, care din punct de vedere arhitectural este constituit din patru componente principale:
Componenta ce vizează achiziția și preprocesarea conținutului media;
Componenta de indexare a bazei de date;
Interfața grafică;
Componenta ce facilitează căutarea în baza de date indexată.
Dintre acestea, componentele ce vizează achiziția și preprocesarea conținutului media, respectiv indexarea bazei de date, au fost realizate ca parte a unui alt proiect și nu fac obiectul acestei lucrari de diplomă. Prin urmare, această lucrarea de diplomă își propune să realizeze o prezentare succintă a acestora.
Conform Fig. 3.2.11, serverul media reprezintă orice entitate care furnizează conținut media online (e.g., portaluri de știri). Achiziția și preprocesarea conținutului media sunt realizate de două subcomponente distincte, dar care iau parte la același proces: colectarea datelor. Prin urmare, acestea au fost grupate într-o singură componentă și anume componenta ce vizează achiziția și preprocesarea conținutului media. Această componentă are rolul de a colecta conținut media (i.e., corpus de text) furnizat de o serie de portaluri de știri, dar și metadate ale articolelor achiziționate, pe care apoi le stochează într-o bază de date. Concurent are loc un proces de „curățare” de text, ce vizează printre altele restaurarea și uniformizarea diacriticelor conform UTF-8 (acolo unde este cazul), transformarea numerelor în cuvinte (i.e., 20 este transformat în douăzeci etc.), respectiv scrierea desfășurată a abrevierilor și acronimelor (i.e., RO este transformat în România, ONU este transformat în Organizația Națiunilor Unite, etc.).
Pentru că interogarea unei baze de date ample în vederea căutării unor termeni ar dura foarte mult, este necesară implementarea unei componente de indexare a bazei de date (i.e, vezi CAPITOLUL 2, subsecțiunea 2.4). Dacă nu se folosea indexarea, la căutarea unui termen, baza de date ar fi fost accesată inutil și astfel timpul în care era întors rezultatul ar fi fost mult prea mare. Prin urmare, a fost dezvoltată o componentă de indexare, care poate indexa datele fie în mod automat – concurent cu achiziția datelor, fie retrospectiv, pe o bază de date creată în prealabil. Indecșii creați în urma procesului de indexare sunt stocați fizic pe disc, formând o bază de date indexată, ce va fi folosită în procesul de analiză.
Media Analytics, privit ca serviciu web, rulează pe un server dedicat. Acesta este serverul Media Analytics, către care se vor îndrepta toate cererile HTTP venite din partea utilizatorilor. Dacă un utilizator dorește efectuarea unei analize (e.g., vezi subsecțiunea 3.1 a acestui capitol), atunci acesta va accesa baza de date indexată prin intermediul unei cereri de tip HTTP GET, îndreptată către serverul Media Analytics. Serverul va interoga colecția de indecși și va răspunde în cel mai scurt timp, returnând rezultatul analizei în cadrul aplicației client ce rulează în browserul utilizatorului (i.e., este vorba despre interfața web).
Datorită funcțiilor distincte pe care le îndeplinesc, cele patru componente pot fi grupate în două module: modulul de achiziție a datelor, respectiv modulul de analiză a datelor. Modulul de achiziție a datelor conține componenta ce vizează achiziția și preprocesarea conținutului media și componenta de indexare a bazei de date, iar modulul de analiză a datelor include interfața grafică, respectiv componenta ce facilitează căutarea în baza de date indexată.
Componenta ce vizează achiziția și preprocesarea conținutului media
Achiziția conținutului media
În scopul implementării componentei de achiziție a conținutului media s-au studiat două opțiuni: utilizarea unui crawler web, respectiv utilizarea feed-urilor RSS.
S-a pornit prin a studia capabilitățile unui crawler web, iar în urma analizei acestora s-a constatat că un astfel de serviciu realizează harta completă a unui site web, fără a oferi însă posibilitatea de a automatiza procesul de achiziție. Limitarea acestuia a rezultat din faptul că accesarea paginilor HTML se făcea retrospectiv, fără a avea opțiunea de a condiționa strict introducerea de conținut nou în baza de date. Prin urmare, stocarea conținutului media într-o bază de date era greu de gestionat.
A fost abordată cea de-a doua variantă: utilizarea feed-urilor RSS. Așadar, operația de achiziție a conținutului media constă în colectarea informațiilor furnizate de o serie de portaluri de știri, prin intermediul feed-urilor RSS. Feed-urile RSS sunt expuse utilizatorilor în format XML, ce oferă o reprezentare structurată a datelor, fiind ușor de parcurs și de interpretat (i.e., vezi CAPITOLUL 2, subsecțiunile 2.2, respectiv 2.5). Aceasta constituie un avantaj major în extragerea informațiilor vizate. Extragerea acestor informații presupune aplicarea unor operații de parsare a paginilor XML, folosind o librărie Java dedicată (i.e., este vorba despre XML DOM Parser). Astfel, pot fi preluate o serie de metadate asociate articolelor, printre care se regăsește și data publicării acestora. Data publicării articolelor constituie un element extrem de important în analiza datelor, deoarece aceasta este folosită pentru a condiționa introducerea de conținut nou în baza de date și ajută la formarea unui „timeline” pentru datele colectate.
Pentru achiziție s-a avut în vedere o serie de portaluri de știri, care au fost analizate din punct de vedere structural și dintre care doar trei s-au dovedit a fi corespunzătoare în cadrul procesului de parsare: Adevarul.ro, EvenimentulZilei.ro, respectiv Wall-Street.ro. Rezultatul acestei analize este redat în Tabelul 3.3.1.
Tabelul 3.3.1 Lista portalurilor de știri analizate
În esență, Media Analytics este un sistem automat de analiză a presei scrise online și din acest motiv, componentele constituente ale acestuia trebuie să îndeplinească această funcție. Pe de altă parte însă, atât achiziția cât și indexarea datelor pot fi realizate și într-o manieră retrospectivă (i.e., achiziția datelor se poate face retrospectiv, prin accesarea arhivelor de știri puse la dispoziție de portaluri, iar indexarea poate avea loc asupra unei baze de date creată anterior).
În continuare, voi exemplifica modul în care are loc achiziția datelor, luând ca referință feed-ul RSS al ziarului Adevărul. Structura documentului XML asociat acestui feed RSS este prezentată în cele ce urmează.
Orice document XML destinat unui serviciu conține un antet, acesta fiind de fapt nodul rădăcină al documentului, în care regăsim informații privind tipul și versiunea serviciului oferit (i.e., în acest caz este vorba despre serviciul RSS, iar informațiile sunt definite prin intermediul atributelor din marcajul <rss></rss> și reprezentate în Fig. 3.3.12).
Fig. 3.3.12 Antetul unui feed RSS
Mai departe, conținutul canalului RSS este delimitat de marcajul <channel></channel>. Acesta poate fi vizualizat în Fig. 3.3.13, respectiv Fig. 3.3.14.
Fig. 3.3.13 Conținutul canalului RSS (1)
Fig. 3.3.14 Conținutul canalului RSS (2)
Secțiunea prezentată în Fig. 3.3.13 conține informații referitoare la configurația paginii web ce expune utilizatorului serviciul RSS pentru portalul de știri Adevărul (e.g., titlul și linkul către această pagină, limba în care sunt afișate datele, un câmp TTL, relații de legătură ce trimit către cotidianul Adevărul, etc), iar Fig. 3.3.14 prezintă structura efectivă a feed-ului RSS. Se observă că fiecare articol este încadrat de marcajele <item></item>, ce conține metadate descrise de marcaje specifice (e.g., titlul și linkul către articolulul respectiv, scurtă descriere, data publicării, etc.).
Reamintim în această secțiune că Media Analytics este integral implementat în Java. Prin urmare, detaliile privind componentele sistemului vor fi strict legate de acest limbaj de programare. De asemenea, codul integral al sistemului a fost încărcat pe GitHub și poate fi vizualizat accesând referința către acesta.
Prin parsarea documentului XML sunt extrase metadatele ce caracterizează o știre (i.e., este vorba despre title, link, description, pubDate). Acestea sunt preluate de sub marcajul <item></item> și sunt introduse în baza de date. După cum am precizat în paragrafele anterioare, pubDate joacă un rol important în automatizarea achiziției de conținut media, deoarece prin aceasta se stabilește un „lastDate” funcție de care este condiționată introducerea de conținut nou în baza de date.
În scopul accesării serviciului RSS pentru fiecare portal de știri, în baza de date a fost implementat un tabel sub forma unei liste de site-uri ale cărui înregistrări constituie informații de legătură (e.g., numele portalului de știri și linkul asociat, linkul către fluxul RSS, intervalul de update al fluxului RSS, etc.). Acest tabel este reprezentat în Fig. 3.3.15.
Fig. 3.3.15 Lista portalurilor de știri, reprezentată în baza de date
Orice interogare a bazei de date presupune realizarea unei conexiuni cu aceasta. Conectarea la o bază de date se realizează exclusiv prin intermediul JDBC. JDBC (Java DataBase Connectivity) este o interfață standard SQL de acces la baze de date. Acesta furnizează un acces uniform la baze de date relaționale. JDBC este constituit dintr-un set de clase și interfețe scrise în Java, furnizând un API standard pentru proiectanții de aplicații ce utilizează baze de date. Acest lucru face posibilă scrierea aplicațiilor de baze de date folosind un API Java pur.
Înainte de realizarea conexiunii trebuie încărcat driverul pentru baza de date. Acest lucru se face prin apelarea metodei Class.forName()(e.g., Class.forName(“org.postgresql.Driver”);). Având în vedere că în JDBC o bază de date este identificată printr-un URL, dacă se folosește PostgreSQL, URL-ul se poate găsi sub una dintre formele:
jdbc:postgresql:database
jdbc:postgresql://host/database
jdbc:postgresql://host:port/database
unde parametrii specificați au următoarea semnificație: host reprezintă numele de host al severului (i.e., implicit acesta este localhost), port reprezintă numărul de port deschis pe server, caracteristic bazei de date (e.g., în mod implicit, pentru PostgreSQL, are valoarea 5432), iar database este numele bazei de date. În afară de acești parametrii standard de conexiune pot fi specificați o serie de parametrii care permit de pildă selectarea utilizatorului bazei de date în numele căruia se face conexiunea, parola asociată acestuia, dar și parametrii specifici unei conexiuni SSL (Secure Sockets Layer). Mai departe, pentru conectarea efectivă la baza de date, utilizatorul trebuie să obțină de la JDBC o instanță de tip Connection. Pentru aceasta, trebuie folosită metoda DriverManager.getConnection(), astfel:
Connection db = DriverManager.getConnection(url, username, password) ;.
Pentru a asigura portabilitatea aplicației a fost dezvoltat un modul în Java ce oferă posibilitatea configurării acesteia, indiferent de sistemul pe care rulează (i.e., config.Finals.java) dar și un alt modul prin intermediul căruia pot fi manipulate baze de date (i.e., controllers.DatabaseController.java). Prin urmare parametrii necesari conexiunii cu baza de date vor fi preluați dintr-un fișier de configurare.
Parsarea unui feed RSS începe prin interogarea bazei de date, mai precis tabelul sites, de unde este preluat linkul către feed-ul RSS. Această operație se realizează executând un sql querry în Java. Mai departe, acest link este utilizat pentru conectarea la feed-ul RSS al portalului de știri. Având în vedere că obiectul rssFeedLink este de tip URL și conține linkul feedului RSS, conectarea la acesta este realizată prin deschiderea unui stream de date:
InputStream stream = rssFeedLink.openStream();
iar pentru accesarea și manipularea documentului XML, acesta din urmă trebuie încărcat într-un obiect de tip XML DOM:
Document doc = dBuilder.parse(stream);
Ulterior este creată o listă de noduri, pentru a putea selecta din document informațiile vizate (i.e., în cazul de față, elementele de sub marcajul <item></item>):
NodeList nList = doc.getElementsByTagName("item"); și prin parcurgerea acestei liste sunt selectate metadatele menționate în paragrafele anterioare. Odată preluate din documentul XML, acestea sunt introduse în baza de date, pentru fiecare articol în parte.
Pentru manipularea articolelor a fost creată clasa Stire, având un constructor ce preia ca parametri title, url, siteId, unde title reprezintă titlul știrii, url reprezină URL-ul știrii, iar siteId este un element care păstrează o evidență a portalurilor de știri, pentru a ști exact de pe ce site a fost extrasă știrea respectivă (i.e., vezi Fig. 3.3.15).
Pentru fiecare știre există un URL, acesta reprezentând link-ul către pagina HTML a știrii. Paginile HTML trebuie parsate la rândul lor, pentru extragerea textului propriu-zis al știrilor, dar și a altor metadate care nu sunt specificate în mod obișnuit în feed-ul RSS (e.g., autor, categorie). Pentru a obține toate aceste informații s-a studiat în detaliu structura paginii HTML. De asemenea s-au căutat variante în care formatul paginii web este cât mai „curat” (i.e., majoritatea paginilor HTML în care sunt reprezentate articolele conțin reclame sau videoclipuri care trebuie ignorate în procesul de parsare) și în acest scop, acolo unde este cazul, în loc să se acceseze pagina web a știrii, se ia în considerare versiunea printabilă a acesteia. Desigur, acest procedeu nu este convenabil în cazul în care pagina printabilă conține insuficiente metadate comparabil cu pagina web propriu-zisă a știrii. Această situație este întâlnită și în cazul editorialului Adevărul: câmpul ce conține autorul este dificil de parsat, deoarece este încadrat între marcaje <div></div> multiple, iar categoria este absentă în versiunea printabilă.
În urma analizei, s-a luat decizia de a accesa pagina web a știrii și s-au observat următoarele:
categoria poate fi extrasă direct din URL-ul știrii
autorul este indicat prin marcajul <span class="a-name"></span>
descrierea și textul știrilor se regăsesc sub marcajele <h2 class="articleOpening">, respectiv <div class="article-body"></div>
Prin urmare s-a dezvoltat un parser HTML dedicat care extrage aceste metadate din corpul paginii HTML. Procesul de parsare este similar cu cel folosit în cadrul documentelor XML, folosind însă utilitarul Java Jsoup.
Astfel, categoria în care se încadrează articolul vizat este extrasă direct din URL. Dacă considerăm arbitrar un articol publicat pe portalul Adevărul, URL-ul acestuia este de forma:
http://adevarul.ro/category/additional-info/article title_Id/index.html
și poate fi prelucrat în Java, având în vedere faptul că orice URL poate fi reprezentat sub formă de string, iar un string poate fi împărțit într-o serie de stringuri constituente.
(1)String linkUnparsed = stire.getUrl().toString();
(2)String linkParsed[] = linkUnparsed.split("\\/");
(3)category = linkParsed[3];
(4)stire.setCategory(category);
În primă instanță este obținut URL-ul știrii, care este convertit în String, preluat mai departe și parsat după elementul despărțitor „/”, obținând un vector ale cărui elemente sunt stringurile constituente (i.e., http:,blank, adevarul.ro, category). În final, pentru obținerea câmpului category, este preluat elementul de pe poziția a patra din vector (i.e., category) și introdus în baza de date ca metadată.
Pentru selectarea celorlalte metadate, conținutul paginii HTML este încărcat într-un document, care urmează să fie parsat:
Document newsDoc = Jsoup.connect(stire.getUrl().toString()
+ "?mobile=0").get();
Este vizată varianta desktop a știrilor și în acest scop este dezactivată opțiunea mobilă predefinită prin adăugarea la URL a particulei „?mobile=0”. Într-un paragraf anterior am specificat modul în care este regăsit autorul articolului în pagina HTML. Atunci când un parser traversează un document de orice tip, folosește un selector cu o sintaxă bine definită. Pentru HTML, această sintaxă presupune interpretarea marcajelor și atributelor specifice atsfel:
#id: găsește elementele după ID-ul specificat, e.g. #logo
.class: găsește elementele după numele clasei, e.g. .a-name, .articleOpening
[attribute]: găsește elementele cu atributul, e.g. [href]
Bineînțeles, se pot realiza combinații precum el#id, el.class, el[href](e.g., div#logo, div.a-name, div.articleOpening, a[href]).
În concluzie, autorul, decrierea și textul articolelor au fost extrase astfel:
În cazul în care se dorește descărcarea retrospectivă a articolelor, sunt accesate arhivele portalurilor de știri și este desfășurat un proces similar de parsare a paginii web asociate. Procedeul însă este mai complex, în sensul că au loc o serie de operații de formare a URL-ului ce caracterizează o astfel de pagină, astfel încât să fie corespunzător modelului caracteristic fiecărui site. Prin urmare au fost create parsere dedicate pentru achiziționarea retrospectivă a știrilor pentru fiecare portal de știri în parte. Structura acestui URL pentru cotidianul Adevărul este reprezentată mai jos:
Preprocesarea conținutului media
În ceea ce privește calitatea textului achiziționat, acesta poate fi afectat de erori de formatare atunci când este încărcat pe pagina web a portalului de știri. De cele mai multe ori se întâmplă ca anumite paragrafe ale textului să conțină puține cuvinte, iar dacă sunt reprezentate în format justified atunci aceste cuvinte apar spațiate pe un singur rând. De asemenea, textul poate devia de la standardul UTF-8, astfel că nu mai este respectată o uniformitate a caracterelor (e.g., în reprezentarea ASCII a caracterelor nu există diacritice). Un alt aspect important care trebuie luat în considerare este că anumite site-uri nu oferă text formatat cu diacritice, iar acestea trebuie restaurate.
Pentru a evita stocarea în baza de date a unui text ce prezintă una sau mai multe dintre problemele descrise mai sus, a fost implementată o soluție prin care este realizată „curățarea” textului. În acest scop s-a folosit un utilitar complex de NLP dezvoltat de laboratorul SpeeD (i.e., este vorba despre utilitarul JavaNLP2, implementat sub forma unei librării Java). Acest utilitar realizează printre altele reducerea spațierii între cuvinte la un singur spațiu, restaurarea diacriticelor, adaptarea textului la standardul UTF-8 astfel încât să fie asigurată o uniformitate a caracterelor, scrierea detaliată a abrevierilor și acronimelor, precum și transformarea numerelor în cuvinte.
Procesul de „curățare” a textului este foarte important în analiza datelor. În acest context, trebuie realizată o uniformizare a textului achiziționat de pe site-urile media, pentru a asigura o căutare mult mai clară și relevantă a datelor în colecția de indecși.
Componenta de indexare a bazei de date
În subsecțiunea 3.2 a acestui capitol, ce vizează descrierea arhitecturii sistemului, a fost evidențiată importanța implementării unei componente de indexare a datelor. Indexarea datelor aparține de asemenea modulului de achiziție (i.e., conform clasificării efectuate în finalul subsecțiunii 3.2) și poate fi realizată concurent cu achiziția datelor, dar și retrospectiv, pe o colecție de date creată în prealabil.
Indexarea datelor presupune stocarea pe disc a unui structuri de indecși ce va conține informații de tip document. Documentul reprezintă o colecție de câmpuri care pun în evidență metadatele supuse procesului de indexare, precum și conținutul propriu-zis al acestora (i.e., termenii ce alcătuiesc un câmp). Alegerea metadatelor ce sunt supuse procesului de indexare se face în funcție de cerințele aplicației ce facilitează operația de căutare în baza de date indexată. De pildă, în cadrul serviciului Media Analytics a fost indexat conținutul articolelor de știri (i.e., textul știrilor) – deoarece termenii sunt căutați în corpul știrii, data publicării, categoria în care se poate încadra un termen căutat și identificatorul portalului de știri – deoarece acestea sunt filtre aplicate în procesul de căutare, titlul și descrierea articolului de știri – pentru dezvoltarea ulterioară a serviciului. Modul în care este realizat procesul de indexare este prezentat mai jos.
Pentru fiecare știre în parte, metoda addToIndex adaugă la colecția de indecși, în document, informațiile specificate, în următoarea manieră: primul parametru al constructorului TextField reprezintă numele câmpului și descrie ce metadate au fost indexate în câmpul respectiv, cel de-al doilea parametru reprezintă conținutul metadatelor care se indexează, iar ultimul parametru este o directivă specifică Lucene. writer este o instanță a clasei IndexWriter, care scrie efectiv datele indexate într-un director. Colecția de indecși rezultată va fi folosită mai departe de modulul de analiză a datelor, ce va fi descris în secțiunea următoare a lucrării de diplomă.
Analiza datelor, generarea și vizualizarea statisticilor
Mecanisme de analiză a datelor
Analiza sentimentelor
Analiza sentimentelor (sentiment analysis sau opinion mining) se referă la utilizarea prelucrării limbajului natural, analizei de text precum și lingvisticii computaționale pentru a identifica și extrage informații cu caracter subiectiv din materiale sursă. La modul general analiza sentimentelor urmărește să identifice atitudinea unei anumite persoane (atitudine exprimată în scris sau oral) referitoare la o anumită topică sau la contextul unui document. Atitudinea poate fi propria judecată , starea emoțională sau comunicarea emoțională intenționată de autor.
O sarcină de bază a acestui tip de analiză este de a clasifica polaritatea unui text dat, la nivel de document, propoziție sau trăsatură distinctivă/aspect – dacă opinia exprimată în legătură cu respectivul document, propoziție sau trăsatura distinctivă/aspectul unei entități este pozitivă, negativă sau neutră. La nivel superior, o clasificare a sentimentelor „dincolo de polaritate” caută, de exemplu stări emoționale precum furie, tristețe sau fericire.
Primele cercetări în acest domeniu îi aduc în prim-plan pe Turney și Pang, care au aplicat diferite metode pentru a determina polaritatea recenziilor unor produse, respectiv filme. Activitatea s-a desfășurat la nivel de document. Polaritatea unui document se poate clasifica de asemenea pe o scară multiplă, direcție adoptată de către Pang și Snyder (printre alții). Pang a extins sarcina de bază privind clasificarea unei recenzii de film de la a fi pozitivă sau negativă la estimarea unor evaluări pe o scară de la 3 la 4 stele, în timp ce Snyder a desfășurat o analiză în profunzime asupra recenziilor unor restaurante, estimând evaluări privind diferite aspecte ale restaurantului dat, precum calitatea mâncării și atmosfera (pe o scară de la una la cinci stele). Chiar dacă în cele mai multe metode de clasificare statistică, clasa neutră este ignorată, în ipoteza că textele neutre din punct de vedere al polarității se află în apropiere de granița de clasificator binar, mai mulți cercetători sugerează că, la fel ca în orice problemă de polaritate, trebuie identificate trei categorii de funcții ale proceselor afective. Mai mult, se poate demonstra că anumiți clasificatori, cum ar fi Max Entropy sau clasificatorul SVM (Support Vector Machine), pot beneficia de introducerea clasei neutre pentru a îmbunătăți acuratețea generală a clasificării.
O metodă diferită de determinare a sentimentului este folosirea unui sistem de clasificare în care pentru cuvintele asociate frecvent cu un sentiment negativ, neutru sau pozitiv, se stabilește un număr pe o scară de la -10 la 10 (cel mai negativ către cel mai pozitiv) și atunci când un fragment de text nestructurat este analizat utilizând NLP (Natural Language Processing), conceptele rezultate în urma analizei vor fi la rândul lor analizate pentru înțelegerea cuvintelor și modului în care acestea se raportează la conceptele respective. Mai departe, fiecare concept primește un scor bazat pe gradul în care cuvintele analizate se raportează la conceptul respectiv, dar si pe scorul propriu fiecărui cuvânt, stabilit anterior. Acest lucru permite înțelegerea mai aprofundată a analizei sentimentelor, bazată pe o scară în 11 puncte.
O altă direcție de cercetare este identificarea gradului de subiectivitate/obiectivitate al unui text. În acest caz, sarcina este de a determina dacă un text dat (uzual o propoziție) este obiectiv sau subiectiv. Această chestiune poate fi uneori mai dificilă decât clasificarea polarității: subiectivitatea cuvintelor și frazelor poate depinde de contextul în care apar, iar documentele cu caracter obiectiv pot conține propoziții subiective (e.g., un articol de știri citând opiniile celor intervievați). Mai mult, după cum s-a menționat de către Su, rezultatele depind în mare măsură de definiția subiectivității abordată în momentul adnotării textelor. Totuși, Pang a arătat că eliminarea propozițiilor obiective dintr-un document înainte de a-i clasifica polaritatea, poate ajuta la îmbunătățirea performanței.
Un model de analiză mai atentă a sentimentelor se bazează pe analiza trăsăturilor/aspectului. Aceasta se referă la determinarea opiniilor sau sentimentelor exprimate în legătură cu diferite trăsături sau aspectul unei entități (e.g., un telefon mobil, un aparat foto digital sau o bancă). Trăsătura sau aspectul constituie un atribut sau o componentă a unei entități (e.g., ecranul unui telefon mobil, calitatea imaginii unui aparat de fotografiat). Această chestiune implică câteva sub-probleme: identificarea entităților relevante, extragerea trăsăturilor/aspectelor ce țin de acestea și determinarea dacă o opinie exprimată în legătură cu fiecare trăsătură/aspect este pozitivă, negativă sau neutră.
Abordările existente în analiza sentimentelor pot fi grupate în patru categorii principale: detectarea cuvintelor cheie, afinitate lexicală, metode statistice și tehnici la nivel de concept. Detectarea cuvintelor cheie clasifică textul în conformitate cu categorii afective bazate pe prezența cuvintelor emotive distincte, precum fericit, trist, speriat sau plictisit. Afinitatea lexicală nu numai că detectează cuvintele emotive distincte, dar și asociază prezumtiv cuvintelor arbitrare, o „afinitate” pentru anumite emoții. Metodele statistice se bazează pe elemente de machine learning, precum LSA (Latent Semantic Analysis), SVM, BOW (bag of words)și SO – PMI (Semantic Orientation – Pointwise Mutual Information). Metode mai sofisticate incearcă sa detecteze posesorul unui sentiment (i.e., persoana care menține acea stare afectivă) și ținta (i.e., entitatea spre care este îndreptată starea afectivă). Pentru a extrage opinia din context și a obține trăsatura asupra căreia se îndreaptă, sunt folosite relații gramaticale între cuvinte. Relațiile de dependență gramaticală sunt obținute prin parsarea în profunzime a textului. Spre deosebire de metodele pur sintactice, tehnicile la nivel de concept se bazează pe elemente de reprezentare a cunoștințelor, precum ontologii și rețele semantice, fiind de asemenea capabile să detecteze semantici exprimate într-o manieră subtilă, e.g., prin analiza unor concepte care nu transmit în mod explicit informații relevante, dar care sunt implicit legate de alte concepte care fac acest lucru.
În afară de tehnicile software folosite în analiza sentimentelor, este necesară și intervenția factorului uman, în condițiile în care sistemele automate nu sunt în măsură să analizeze tendințele dezvoltate de un comentator individual, acestea fiind clasificate incorect din punct de vedere al sentimentelor exprimate.
Acuratețea unui astfel de sistem de analiză se referă, în principiu, la cât de bine clasificările acestuia sunt în acord cu aprecierile factorului uman. Astfel, potrivit cercetărilor, în mod obișnuit, evaluatorii umani convin în 79% din situații.
Dacă punem în conjuncție analiza sentimentelor si Web 2.0, în contextul dezvoltării platformelor sociale precum blogurile sau rețelele sociale, opinia exprimată online s-a transformat într-un fel de monedă virtuală pentru întreprinderile care vor să-și comercializeze produsele, să identifice noi oportunități și să își gestioneze reputația. Deoarece întreprinderile urmăresc automatizarea procesului de „filtrare a zgomotului”, înțelegerea conversațiilor, respectiv identificarea conținutului relevant și folosirea adecvată a acestuia, societatea se orientează spre domeniul analizei sentimentelor.
Problema este că cei mai mulți algoritmi de analiză a sentimentelor folosesc termeni simpli pentru a exprima sentimentul despre un produs sau serviciu. Cu toate acestea, factorii culturali, nuanțele lingvistice și contextele diferite, fac extrem de dificilă sarcina de a transforma un fragment de text scris într-un simplu sentiment pro sau contra. Faptul că de multe ori oamenii nu sunt de acord cu privire la sentimentul exprimat în legatură cu fragmentul de text dat, ilustrează cât de dificilă este pentru un computer aceasta sarcină de a clasifica în mod corect opiniile exprimate. Cu cât fragmentul de text este mai scurt, cu atât sporește dificultatea acestei sarcini; din acest motiv se impune realizarea analizei asupra unui corpus mare de text.
Analiza sentimentelor poate fi efectuată, de asemenea, asupra conținutului vizual (i.e., imagini, videoclipuri). Una dintre primele abordări în această direcție este SentiBank, care pentru reprezentarea conținutului vizual pune în corespondență adjective și substantive, formând liste de corespondență. Structura unei astfel de liste poate fi vizualizată în Fig. 4.1.16.
Fig. 4.1.16 Structura unei liste de corespondență, utilizată în analiza conținutului vizual
Conform Fig. 4.1.16, o listă de corespondență oferă informații în legătură cu procesul de analiză a conținutului vizual, specificând asocierea adjectiv-substantiv, adoptată pe baza analizei a „i” imagini, precum și un scor ce exprimă sentimentul transmis, unde „i” este un număr natural diferit de zero.
Realizarea unor corelații
Un alt tip de analiză ce poate fi efectuată asupra conținutului media este realizarea unor corelații între subiecte de interes general sau între entități media.
În anul 2013, cercetătorii americani au efectuat un studiu care a confirmat corelația între Twitter și audiențele TV (Television).
Potrivit platformei de analiză media SocialGuide, în 2012, 32 de milioane de utilizatori unici din S.U.A au scris pe Twitter despre programele TV agreate.
Prin analiza postărilor de pe Twitter despre programele live TV, studiul a confirmat o relație de legătură între Twitter și audiențele înregistrate de programele TV. Studiul a identificat de asemenea Twitter ca fiind una dintre cele trei variabile statistic semnificative (în plus față de evaluările din anul precedent și cheltuielile de publicitate) ce se aliniază cu audiența TV. Andrew Somosi, CEO al SocialGuide afirma la momentul respectiv: „Ne așteptam sa observăm o corelație între Twitter și audiența TV, însă acest studiu cuantifică tăria acestei relații.”.
Corelația este influențată în mare parte de creșterea semnificativă a consumului de conținut media și de avântul tehnologic în ceea ce privește dispozitivele electronice. Cercetătorii au estimat că 80% din posesorii americani de tablete și smartphone-uri care urmăresc programe TV, își folosesc dispozitivele în acest scop cel puțin de câteva ori pe lună. De asemenea, 40% din utilizatorii de tablete și smartphone-uri vizitează rețelele sociale în timp ce urmăresc programele TV.
Este important de remarcat cât de bine se aliniază Twitter la audiențele înregistrate de programele TV. Studiul Nielsen/SocialGuide a confirmat că sporirea volumului de posturi pe Twitter se află în corelație cu creșterea audienței programelor TV pentru diferite grupe de vârstă, dezvăluind o corelație puternică în cazul publicului mai tânăr. Mai exact, cercetătorii au constatat că pentru tinerii cu vârste între 18 și 34 de ani, o creștere de 8.5% în volumul posturilor de pe Twitter (i.e., reprezentată cu albastru în Fig. 4.1.17), corespunde unei creșteri de 1% a audienței TV pentru episoadele în premieră a serialelor. Pe de altă parte, o creștere de 14.0% în volumul posturilor de pe Twitter (i.e., reprezentată cu albastru în Fig. 4.1.17) este asociată cu o creștere de 1% a audienței programelor TV, oferite de publicul cu vârste între 35 și 49 de ani, reflectând o relație mai puternică între Twitter și TV, pentru publicul mai tânăr.
Mai mult, corelația dintre posturile de pe Twitter și audiențele TV se consolidează în cazul episoadelor plasate la mijlocul sezonului (i.e., reprezentate cu verde în Fig. 4.1.17), pentru ambele categorii de vârstă. O creștere de 4.2%, respectiv 8.4%, în volumul posturilor de pe Twitter, este asociată cu o creștere de 1% a audiențelor TV pentru categoria 18-34 ani, respectiv 35-49 de ani. Rezultatele studiului sunt prezentate în Fig. 4.1.17.
Realizarea unor corelații între subiecte presupune analiza simultană a două sau mai multe subiecte de interes general, expuse în mass-media. Analiza efectuată poate fi o analiză a sentimentelor asupra subiectelor vizate, de unde poate rezulta impresia generală a publicului cu privire la acestea, sau o analiză de tip „counting”.
Corelațiile între subiecte își demonstrează utilitatea atunci când companiile își propun analize și studii de piață, dar și cercetări de marketing, situații în care realizarea unor corelații cu privire la concurență, sau corelații între evenimente definitorii pentru respectivele companii se dovedesc a fi de o importanță majoră.
Fig. 4.1.17 Rezultatele studiului Nielsen/SocialGuide
Metoda de counting
Această metodă de analiză presupune determinarea frecvenței de apariție a unor termeni în mediul online, analizând în general interesul utilizatorilor cu privire la acei termeni și pe baza analizei se pot face previziuni în timp real.
Google utilizează o formă a acestei metode în cadrul serviciului Google Trends, în care sunt cuantificate căutarile unice în legătură cu anumiți termeni și prin analiza acestora sunt oferite previziuni, dar și o viziune retrospectivă asupra evenimentelor importante care au marcat opinia publică.
Caracterul predictiv al Google Trends a fost observat în diferite arii ale științelor sociale. De exemplu, prin monitorizarea numărului de căutări pe Google pentru termeni aflați în conjucție cu prevenirea și vindecarea gripei, au fost observate focare de gripă în curs de dezvoltare. Aceasta demonstrează importanța unei astfel de analize în observarea și prevenția unor evenimente care pot avea un impact major în viața cotidiană.
Metoda de counting vizează, de asemenea, evidențierea interesului manifestat de către utilizatori în legatură cu anumite subiecte expuse în mass-media. Analiza este realizată prin estimarea numărului de apariții ale unor termeni în articole distincte publicate în mediul online. În acest mod, se poate aprecia zona de interes către care se orientează mass-media într-un anumit interval temporal și cum influențează informația expusă opinia utilizatorilor.
Componenta ce facilitează căutarea în baza de date indexată
Componenta ce facilitează căutarea în baza de date indexată a fost creată pentru a implementa funcția de analiză a sistemului Media Analytics, respectând specificațiile modelului arhitectural REST (i.e., vezi CAPITOLUL 2, subsecțiunea 2.5).
Pentru ca această componentă să-și îndeplinească funcțiile, este necesar ca celelalte două componente (i.e., componenta ce vizează achiziția și preprocesarea conținutului media, respectiv componenta de indexare a bazei de date) să conlucreze pentru asigurarea unei baze de date indexată. Această componentă a fost implementată cu ajutorul utilitarului Lucene, care stă de altfel la baza procesului de indexare a datelor.
Atunci când un utilizator dorește să efectueze o analiză a conținutului media, putem spune că acesta construiește, în pagina web, o structură de filtre. Fizic, această structură de filtre este creată de către componenta ce facilitează căutarea în baza de date indexată.
În momentul în care este solicitată analiza datelor, componenta de căutare accesează și citește colecția de indecși prin intermediul metodei createIndexSearcher(), reprezentată în fragmentul de cod de mai jos. În cadrul acestei metode, pe baza directorului fizic care conține colecția de indecși, este creat un director virtual (i.e., dir). Acest director va fi folosit în continuare pentru realizarea operațiilor ulterioare de citire și de căutare a indecșilor.
Structura de filtre este creată progresiv, pe baza criteriilor de căutare introduse în pagina web de către un utilizator. Criteriile de căutare sunt de fapt atributele clasei Query, care caracterizează orice interogare efectuată în pagina web. Atributele (e.g., keywords, newspapers, category, startDate, endDate) sunt definite ca liste ce conțin elemente de tip String, deoarece procesul de căutare suportă introducerea de termeni multiplii (i.e., utilizatorul poate căuta un termen compus din mai multe cuvinte, poate filtra căutarea după toate ziarele, respectiv toate categoriile).
Din punct de vedere programatic, structura de filtre este o instanță a clasei BooleanQuery, necesară în orice sistem care utilizează filtre în căutarea datelor. Spunem că procesul de formare a acestei structuri este progresiv, deoarece pe măsură ce utilizatorul selectează criterii de căutare a datelor, noi termeni sunt adăugați în acel obiect de tip BooleanQuery. Acest procedeu poate fi exemplificat luând în considerare un fragment de cod din metoda search(), care primește ca parametru o instanță a clasei Query și returnează numărul de ocurențe ale termenilor căutați.
Fiecare element keyword din lista keywords (i.e., atribut al clasei Query) este adăugat acelui booleanQuery, sub forma unui obiect de tipul TermQuery, cu specificația că pentru acesta se folosește clauza Occur.MUST. Clauza specifică modul în care are loc căutarea în indecși a termenilor adăugați. În acest caz, Occur.MUST poate fi interpretat ca un ȘI logic, impunând ca rezultatul să conțină obligatoriu toți termenii căutați, nu numai unul dintre aceștia (i.e., la polul opus se află Occur.SHOULD ,interpretat în mod similar ca fiind un SAU logic ). Keyword reprezintă cuvântul introdus în câmpul de căutare din pagina web. În mod similar, în booleanQuery se adaugă și celelalte criterii (i.e., newspapers, category, etc.), până când se obține structura de filtre completă. Este important de menționat că pentru toate filtrele s-a folosit clauza Occur.MUST, astfel că utilizatorul va trebui să formuleze de fiecare dată o structură de filtre completă. În caz contrar, atunci când se va face căutarea nu va fi respectată structura lui booleanQuery, iar rezultatul căutării va fi necorespunzător (i.e., va fi afișat un grafic fără niciun element).
Căutarea se face prin intermediul metodei search() specifică utilitarului Lucene, care primește ca parametri o structură de filtre de tip BooleanQuery (e.g., booleanQuery) și un obiect de tip TopScoreDocCollector (e.g., collector). Acest collector înregistrează numărul de apariții ale termenilor căutați în colecția de indecși.
Metodele amintite mai sus (i.e., createIndexSearcher(), respectiv search()) aparțin clasei MediaSearcher().
Conceptele ce caracterizează modelul arhitectural REST au fost prezentate în CAPITOLUL 2, subsecțiunea 2.5 a prezentei lucrări de diplomă. Reamintim că într-un serviciu bazat pe modelul arhitectural REST totul este o resursă, care este identificată printr-un URI. De asemenea, datele asupra cărora clientul îi spune serverului să opereze se află în URI, iar operația pe care serverul o face asupra datelor este descrisă direct de metoda HTTP specificată (e.g., PUT, GET, POST, DELETE). HTTP GET accesează resursa (i.e., o citește) fără a o altera.
Orice serviciu bazat pe REST și implementat în Java (i.e., prin intermediul librăriei Jersey), folosește așa numitele adnotări, pentru a-și accesa resursele. Acestea sunt reprezentate prin indicativul „@”, urmat de o directivă specifică (e.g., @PATH(/path), @GET, @Produces( MediaType.TEXT_PLAIN), @Consumes(type)). Toate aceste adnotări sunt aplicate unei metode Java, care va fi în final apelată în browser prin accesarea unui URL specific.
@PATH setează calea pentru URL-ul de bază folosit pentru a accesa serviciul (i.e., aceasta este doar o particulă a URL-ului – nu este suficient să fie specificată doar calea).
@GET indică faptul că metoda va răspunde unei cereri de tip HTTP GET.
@Produces specifică ce tip de MIME (Multipurpose Internet Mail Extensions) este produs în urma apelării metodei (i.e., în cazul de mai sus este produs text (“text/plain”).
@Consumes specifică ce tip de MIME este consumat de metoda respectivă.
Media Analytics este realizat în concordanță cu modelul arhitectural REST. În consecință, clasa care implementează serviciul de căutare și de analiză a datelor este conformă acestui model. Este vorba despre clasa Searcher, adnotată corespunzător prin @Path("/searcher").
Searcher() conține metoda search(), adnotată @Path("/search"), care preia ca parametru un obiect de tip HttpServletRequest și returnează un String. Metoda răspunde cererilor de tip HTTP GET, consumă text și produce un document XML. Prin @Context, Jersey va apela metoda la fiecare request venit din partea unui client (i.e., are loc injectarea câmpurilor aflate în context). Modul în care sunt realizate aceste adnotări, este redat în fragmentul de cod de mai jos:
Orice cerere venită din partea unui client va fi interpretată ca fiind un request. Prin intermediul JavaScript, structura de filtre este preluată din pagina web și descompusă în elementele constituente (i.e., keyword, category, newspaper, etc.). Elementele structurii de filtre sunt extrase din documentul HTML asociat paginii web, prin selectarea indentificatorului corespunzător, astfel: keyword = document.getElementById(“keyword”).value;, unde document face referire la documentul HTML, iar elementul la care se referă este un div, indentificat printr-un id specific (e.g., în acest caz, „keyword”). Aceste elemente au rolul de a forma, împreună cu un URL de bază, URL-ul caracteristic utilizat pentru accesarea serviciului. URL-ul de bază este de forma:
http://dev.speed.pub.ro:10082/MediaAnalytics-Search/rest/searcher/search , în care particulele constituente sunt definite anterior în două fișiere XML (i.e., context.xml, respectiv web.xml). Acest URL este reținut de variabila baselink. Pentru obținerea URL-ului caracteristic, elementele structurii de filtre extrase anterior sunt concatenate succesiv, utilizând simboluri specifice (e.g., „?”, „&” ):
…
URL-ul astfel obținut va fi accesat pentru a trata request-ul. În acest scop, este creată o variabilă de tip XMLHttpRequest: var xmlHttp = new XMLHttpRequest(); și este accesat URL-ul creat anterior: xmlHttp.open("GET", baselink + termination, false);. Urmează ca request-ul să fie trimis către serverul Media Analytics: xmlHttp.send();. Deoarece sunt utilizate cereri de tip XMLHttpRequest, răspunsul întors de către server ajunge tot în interiorul scriptului, unde urmează sa fie procesat.
În acest context este apelată metoda Searcher.search() (i.e., adnotată prin @Path("/search")) care decapsulează request-ul în elementele sale constituente (i.e., keyword, category, newspaper, etc.), instanțiază un obiect din clasa MediaSearcher și inițiază căutarea în baza de date indexată.
Analiza datelor
Algoritmul implementat în cadrul sistemului Media Analytics vizează analiza sentimentelor conform metodei de counting (i.e., prezentată în subsecțiunea 4.1.3 a acestui capitol).
Acesta presupune preluarea intervalului temporal specificat de către un utilizator în pagina web și returnarea, pentru fiecare zi din interval, a numărului de elemente ce sunt în concordanță cu structura de criterii și filtre construită.
Pe baza rezultatului obținut în urma căutării, pentru fiecare zi din intervalul temporal specificat, este completată o matrice cu M linii și N coloane (i.e., unde M reprezintă numărul de zile din intervalul temporal, iar N=2). Matricea este completată pe linii astfel:
array =
unde un element al matricei reprezintă data calendaristică, iar un element indică numărul de ocurențe din data respectivă.
Am ales o reprezentare matriceală a rezultatului, pentru a structura cât mai bine datele și pentru a putea păstra corespondența „dată calendaristică – număr de ocurențe”, necesară mai departe în analiza datelor.
REST permite ca resursele să aibă diferite reprezentări (e.g., text, XML, JSON, etc.). Clientul REST poate solicita o reprezentare specifică prin intermediul protocolului HTTP. Pentru ca serviciul Media Analytics să fie conform modelului arhitectural REST, am ales ca răspunsul primit în urma cererii HTTP GET să fie reprezentat sub forma unui document XML.
Documentul XML este creat utilizând metode specifice din librăria Java DOM Parser. În primă instanță este preluată matricea de rezultate și este parcursă pe linii. Apoi, pentru fiecare linie (i.e., vector) din matrice, sunt extrase părțile componente (e.g., v[0] = 2012.01.01 , v[1] = 33) și sunt adăugate ca atribute ale marcajului <item></item> din documentul XML. Operația se realizează până la epuizarea liniilor din matrice. În final, ca răspuns la cererea HTTP GET, se obține un document XML cu structura din Fig. 4.3.18.
Fig. 4.3.18 Răspunsul sistemului în urma unei cereri de tip HTTP GET
Se observă că elementul rădăcină al documentului XML este indicat prin intermediul marcajului <news-counts></news-counts> și înglobează rezultatul căutării între marcajele <item></item>.
Pentru a interpreta rezultatul căutării este necesar ca răspunsul sub formă de XML să fie întors în JavaScript pentru a fi procesat. Acest lucru are loc în mod automat, având în vedere că răspunsul este de tip XMLHttpRequest(). Răspunsul este reținut de variabila responseText și este parsat în vederea extragerii atributelor de sub marcajul <item></item> (i.e., dată, număr de ocurențe):
//variabilă ce reține toate elementele marcate prin <item></item>.
Putem spune că în urma parsării documentului XML în JavaScript, au fost obținute elementele necesare și suficiente pentru a reprezenta grafic rezultatul analizei: data calendaristică, respectiv numărul de ocurențe din data respectivă.
Reprezentarea grafică a rezultatului se face prin intermediul unui script implementat în JavaScript. Este vorba despre un API pus la dispoziție de Google, ce facilitează reprezentarea grafică a datelor de intrare: Annotation Chart.
Annotation Chart este doar un suport pentru reprezentarea grafică a datelor. Pentru afișarea în mod dinamic a graficului am avut în vedere modificarea scriptului pus la dispoziție de catre Google, astfel încât să fie îndeplinite funcțiile sistemului Media Analytics.
Pentru manipularea graficului este necesară definirea unui secțiuni în pagina HTML (e.g., sugestiv <div id="chart_div" style='width: 900px; height: 400px;'></div>)) asupra căreia este aplicat scriptul care generează reprezentarea grafică (i.e., drawChart()). După cum am precizat, datele extrase din documentul XML sunt oferite ca parametri în API-ul Google Annotation Chart. Pentru ca afișarea grafică a analizei să se facă în mod dinamic (i.e., graficul să se transforme în concordanță cu modificarea criteriilor de căutare) am iterat prin elementele documentului XML, am extras datele necesare și le-am transmis ca parametri în cadrul graficului. Modul în care am realizat aceste operații este redat în fragmentul de cod de mai jos:
De asemenea, în reprezentarea grafică a analizei nu am folosit opțiunea de adnotare a graficului, deoarece momentan aceasta nu corespunde modului de implementare a sistemului.
Reprezentarea grafică a analizei efectuate (i.e., analiza sentimentelor bazată pe metoda de counting) are loc efectiv în urma apelării metodei draw(data, options) din cadrul API-ului Google Annotation Chart: chart.draw(data, options);.
Interfața grafică
Media Analytics este expus utilizatorului sub forma unei aplicații web, care realizează interfața dintre acesta și componenta de analiză.
Pentru structurarea paginii web am folosit HTML, iar pentru separarea conținutului HTML de stilul de afișare în pagină am utilizat CSS (Cascaded Style Sheet)
Publications List
[Burileanu, 2008] Corneliu Burileanu, Cristina-Sorina Petrea, Andi Buzo, Horia Cucu, Alina Pașca, “Report on building a tool for Romanian spontaneous speech recognition,” The Phonetician, ISSN 0741-6164, No. 97 / 2008-I-II, pp. 68-98, 2008.
[Burileanu, 2010a] Corneliu Burileanu, Andi Buzo, Cristina-Sorina Petre, Diana Ghelmez-Hanes, Horia Cucu, “Romanian Spoken Language Resources and Annotation for Speaker Independent Spontaneous Speech Recognition,” ICDT 2010, pp.7-10, Athens, Greece, 2010.
[Burileanu, 2010b] Corneliu Burileanu, Cristina-Sorina Petrea, Andi Buzo, Horia Cucu, “Speech Recognition Experiments Starting from Isolated Words for Spoken Romanian Language,” Multilinguality and Interoperability in Language Processing with Emphasis on Romanian, Romanian Academy Publishing House, Bucharest, ISBN: 978-973-27-1972-5, pp. 231-244, 2010.
[Petrea, 2010] Cristina-Sorina Petrea, Andi Buzo, Horia Cucu, Miruna Pașca, Corneliu Burileanu, “Speech Recognition Experimental Results for Romanian Language,” ECIT 2010, ISSN: 2069-038X, pp. 13, Iași, Romania, 2010.
[Buzo, 2011a] Andi Buzo, Horia Cucu, Corneliu Burileanu, Miruna Pașca, Vladimir Popescu, “Word error rate improvement and complexity reduction in automatic speech recognition by analyzing acoustic model uncertainty and confusion,” SpeD 2011, ISBN: 978-1-4577-0439-0, pp. 67-74, 2011.
[Buzo, 2011b] Andi Buzo, Horia Cucu, Corneliu Burileanu, “Improving automatic speech recognition robustness for the romanian language,” EUSIPCO 2011, ISSN: 2076-1465, pp 2119-2122, 2011.
[Cucu, 2011a] Horia Cucu, Andi Buzo, Corneliu Burileanu, “Optimization methods for large vocabulary, isolated words recognition in Romanian language”, University Politehnica of Bucharest Scientific Bulletin, Series C, no. 2, ISSN: 1454-234x, pp. 179-192, Bucharest, 2011.
[Cucu, 2011b] Horia Cucu, Laurent Besacier, Corneliu Burileanu, Andi Buzo, ”Enhancing Automatic Speech Recognition for Romanian by Using Machine Translated and Web-based Text Corpora,” SPECOM 2011, pp. 81-88, Kazan, Russia, 2011.
[Cucu, 2011c] Horia Cucu, Laurent Besacier, Corneliu Burileanu, Andi Buzo, ”Investigating the Role of Machine Translated Text in ASR Domain Adaptation: Unsupervised and Semi-supervised Methods,” ASRU 2011, Hawaii, United States of America, to appear 2011.
References
[9am] 9am online newspaper (http://www.9am.ro)
[Bahl, 1991] Bahl, L.R., et al., “Multonic Markov Word Models for Large Vocabulary Continuous Speech Recognition,” IEEE Transactions on Speech and Audio Processing, 1993, vol. 1, no. 3, pp. 334-344, 1991.
[Baker, 1975] Baker, J., “The DRAGON system – an overview,” IEEE Transactions on Acoustics, Speech, and Signal Processing, vol. 23, no. 1, pp. 24-29, 1975.
[Baker, 1989] Baker, J., “DragonDictate – 30K: Natural language speech recognition with 30,000 words,” Eurospeech 1989, pp. 161-163, 1989.
[Baum, 1972] Baum, L.E., “An inequality and associated maximization technique in statistical estimation for probabilistic functions of Markov processes,” Inequalities, vol. 3, no. 1, pp. 1-8, 1972.
[Bertoldi, 2009] Bertoldi, N., Haddow, B., Fouet, J.-B., “Improved Minimum Error Rate Training in Moses,” The Prague Bulletin of Mathematical Linguistics, pp. 1-11, February 2009.
[Beulen, 1997] Beulen, K., Bransch, E., Ney, H., “State tying for context dependent phoneme models,” Eurospeech 1997, pp. 1179-1182, 1997.
[Bick, 2010] Bick, E., Greavu, A., “A Grammatically Annotated Corpus of Romanian Business Texts,” Multilinguality and Interoperability in Language Processing with Emphasis on Romanian, Romanian Academy Publishing House, Bucharest, ISBN: 978-973-27-1972-5, pp. 169-182, 2010.
[Billa, 2002] Billa, J., Noamany, M., Srivastava, A., Liu, D., Stone, R., Xu, J., et al., “Audio indexing of Arabic broadcast news,” ICASSP 2002, pp. 5-8, 2002.
[Bisani, 2003] Bisani, M., Ney, H., “Multigram-based grapheme-to-phoneme conversion for LVCSR,” Eurospeech 2003, pp. 933-936, Geneva, Switzerland, 2003.
[Bisani, 2008] Bisani, M., Ney, H., “Joint-sequence models for grapheme-to-phoneme conversion,” Speech Communications, vol. 50, no. 5, pp. 434–451, 2008.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Serviciu Web de Analiza Statistica Presei Online (ID: 150444)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.