Estudi, disseny i implementacio d’un sistema autom`atic...

Estudi, disseny i implementacio d’un sistemaautomatic extractor de Xarxes Socials

Pablo Ros [email protected]

Ponent: Xavi Canaleta [email protected]

Abstract

Cada dia la xarxa que coneixem amb el nom d’Internet creix amb infor-macio fresca i innovadora. Aquest creixement dificulta trobar la informaciosobre tematiques i arees d’interes o estrategiques per una empresa o un centred’investigacio.

El nostre objectiu es poder extreure les xarxes socials ocultes que estroben a Internet mitjancant els motors de cerca disponibles com Google oYahoo, per tal d’obtenir informacio relacionada amb els individus que volemestudiar i analitzar, d’una manera automatitzada.

Per tant en aquest treball es treballara el web Crawling, per tal d’obtenirinformacio dels motors de cerca; Web Mining per tal d’extreure nous actorsper expandir la xarxa i les seves descripcions semantiques; analisi de la xarxasocial, per tal de crear les relacions entre actors i la visualitzacio de la xarxaper tal de que l’usuari pugui coneixer els resultats.

Resum


Les relacions entre persones i els vincles que es creen entre elles, des delpunt de vista del compartir i de la comunicacio, ens porta cap a un modelclar de xarxa social. Per tant les nostres vides es comporten sota aquestspatrons encara que no en siguem conscients.

Aquestes relacions entre individus podem trobar-les a la xarxa de conei-xement mes gran del mon, Internet. Moltes persones comparteixen el seuconeixement i les seves investigacions en aquest entorn. Aquest fet es positiudes del punt de vista que hi ha mes informacio per consultar, pero es negatiuja que es mes difıcil de trobar.

El nostre objectiu es poder extreure les xarxes socials ocultes que estroben a Internet mitjancant els motors de cerca disponibles com Google oYahoo, per tal d’obtenir informacio relacionada amb els individus que volemestudiar i analitzar, d’una manera automatitzada.

Es preten obtenir una xarxa social amb dos tipus de relacions. Aquellesque ens indiquen afinitat per contacte directe entre dues persones i afinitatper les seves descripcions semantiques. Per cada actor s’extrauran un conjuntde keywords que defineixin aquell actor en la xarxa social i que ens permetrancrear les relacions esmentades.

La visualitzacio de les dades obtingudes d’una manera practica i usableper l’usauri tambe es objectiu d’aquest Projecte Final de Carrera, per tald’implementar un sistema complet, que sigui capac de satisfer tot aquestproces de crawling, web Mining, calcul d’afinitats i representacio visual delsresultats per l’usuari.

Tambe es treballaran els aspectes relacionats al sistema que executaraaquesta aplicacio per tal que els temps de resposta siguin el maxim d’optimspossibles.

Agraıments

Seria poc just acabar aquest Projecte i no agrair a la gent que ha estat almeu costat recolzant-me i animant-me per arribar al final d’aquest projecte.

En primer lloc, mencionar a la Marta, per compartir llargues estones ambmi i el projecte. Amb ella va neixer aquesta idea, quan entre els dos vamdissenyar l’esbos a Cunit, i avui queda finalitzada en aquestes fulles. Ets lameva musa, font d’inspiracio i de motivacio per menjar-me el mon. La tevaforca em fa fort! Gracies Marta.

En segon lloc els meus pares i la meva germana. No hagues estat elmateix aquest Projecte sense la tıpica pregunta “Ya esta acabado?” de lameva mare, ni l’ajuda i suport logıstic del meu pare. I que dir de la petitade la casa, sempre donant un cop de ma quan mes ho necessito i donan’t-meanims quan mes falta fan. Gracies a tots tres!

I per ultim i no menys important, en Xavi. Gracies a ell no nomes s’acabataquest projecte, sino que m’ha acompanyat durant tota l’elaboracio amb unsuport mes enlla de l’imaginable. Les teves idees i aportacions han estat clausper donar-li cara i ulls a tot aquest Projecte. Espero que sigui l’inici d’unllarg camı que hem de recorrer. I encara que sembli que el meu s’acaba aquı,em tens pel que necessitis! I aquesta te la dedico: “una analisi”. GraciesXavi!

Aixı doncs nomes em queda tornar a dir GRACIES a tots i...The show must go on!

Index

Index 1

1 Introduccio 4

2 Xarxes Socials 72.1 Introduccio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.2 Analisi sociologic de Xarxes Socials . . . . . . . . . . . . . . . 8

2.2.1 Nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Poblacions, mostres i lımits . . . . . . . . . . . . . . . 92.2.3 Relacions . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Relacions multiples . . . . . . . . . . . . . . . . . . . . 122.2.5 Escales de mesura . . . . . . . . . . . . . . . . . . . . . 12

2.3 Representacions de Xarxes Socials . . . . . . . . . . . . . . . . 142.3.1 Grafs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.2 Matrius . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4 Terminologia de les xarxes socials . . . . . . . . . . . . . . . . 182.4.1 Mesures de centralitat . . . . . . . . . . . . . . . . . . 18

2.5 Lınies d’investigacio en Xarxes socials . . . . . . . . . . . . . . 192.5.1 Introduccio . . . . . . . . . . . . . . . . . . . . . . . . 192.5.2 Referral Web . . . . . . . . . . . . . . . . . . . . . . . 202.5.3 Flink . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.5.4 Polyphonet . . . . . . . . . . . . . . . . . . . . . . . . 23

2.6 Implementacions comercials de Xarxes Socials . . . . . . . . . 25

3 Analisi de requeriments 283.1 Objectius . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4 Estudi i disseny de la Xarxa Social 314.1 Introduccio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.2 Interrogacio al motor de cerca . . . . . . . . . . . . . . . . . . 31

1

INDEX 2

4.2.1 Accedint al motor de cerca . . . . . . . . . . . . . . . . 324.2.2 Com interrogar el motor de cerca . . . . . . . . . . . . 34

4.3 Web Mining. Extraccio de dades dels actors . . . . . . . . . . 384.3.1 Expansio de la xarxa social . . . . . . . . . . . . . . . 384.3.2 Extraccio de les descripcions semantiques . . . . . . . . 414.3.3 Creant relacions d’afinitat entre actors . . . . . . . . . 454.3.4 Creant relacions semantiques entre actors . . . . . . . . 47

4.4 Disseny del navegador de la xarxa social . . . . . . . . . . . . 504.4.1 Visualitzador del graf . . . . . . . . . . . . . . . . . . . 514.4.2 Nuvol de tags . . . . . . . . . . . . . . . . . . . . . . . 534.4.3 Panell de navegacio . . . . . . . . . . . . . . . . . . . . 55

4.5 Problemes observats i solucions . . . . . . . . . . . . . . . . . 56

5 Implementacio de la Xarxa Social 595.1 Introduccio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 595.2 Plataforma tecnologica . . . . . . . . . . . . . . . . . . . . . . 59

5.2.1 El llengutage de programacio . . . . . . . . . . . . . . 605.2.2 El servidor . . . . . . . . . . . . . . . . . . . . . . . . . 61

5.3 Modularitzacio del sistema . . . . . . . . . . . . . . . . . . . . 615.3.1 Diagrama de moduls . . . . . . . . . . . . . . . . . . . 625.3.2 Diagrama de sequencia . . . . . . . . . . . . . . . . . . 64

5.4 Classes mes rellevants . . . . . . . . . . . . . . . . . . . . . . . 655.4.1 Social Network . . . . . . . . . . . . . . . . . . . . . . 655.4.2 Web Mining . . . . . . . . . . . . . . . . . . . . . . . . 665.4.3 Spider (Google & Yahoo) . . . . . . . . . . . . . . . . . 675.4.4 Conversio de PDF a text . . . . . . . . . . . . . . . . . 675.4.5 Extraccio de Paraules Clau . . . . . . . . . . . . . . . . 685.4.6 Algorismes de Stemming . . . . . . . . . . . . . . . . . 695.4.7 Visualitzacio de la xarxa social . . . . . . . . . . . . . 785.4.8 Multi Proces . . . . . . . . . . . . . . . . . . . . . . . 795.4.9 Debug . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

5.5 Optimitzacions del sistema . . . . . . . . . . . . . . . . . . . . 815.5.1 Execucio multi threading . . . . . . . . . . . . . . . . . 815.5.2 Cache de resultats . . . . . . . . . . . . . . . . . . . . 825.5.3 Accelerador PHP . . . . . . . . . . . . . . . . . . . . . 84

5.6 Limitacions tecnologiques . . . . . . . . . . . . . . . . . . . . 86

6 Resultats 886.1 Xarxes de Nivell 1 . . . . . . . . . . . . . . . . . . . . . . . . 88

6.1.1 Xarxa de [email protected] . . . . . . . . . . . . . . . 886.1.2 Xarxa de [email protected] . . . . . . . . . . . . . . 97

INDEX 3

7 Conclusions 109

8 Lınies de futur 113

9 Cost del Projecte Final de Carrera 115

Bibliografia 116

Capıtol 1

Introduccio

Una possible definicio d’una xarxa social es:Un conjunt ben definit d’actors -individus, grups, organitzacions, comu-

nitats, societats globals, etc.- que estan vinculades unes a altres a traves d’uno un conjunt de relacions socials.

Amb aquesta definicio es facil fer una extrapolacio al nostre dia a dia.Les relacions entre persones i els vincles que es creen entre elles, des del puntde vista del compartir i de la comunicacio, ens porta cap a un model clar dexarxa social. Per tant les nostres vides es comporten sota aquests patronsencara que no en siguem conscients.

Aquestes relacions entre individus podem trobar-les a la xarxa de conei-xement mes gran del mon, Internet. Moltes persones comparteixen el seuconeixement i les seves investigacions en aquest entorn. Aquest fet es positiudes del punt de vista que hi ha mes informacio per consultar, pero es negatiuja que es mes difıcil de trobar.

Moltes vegades coneixem un autor que treballa sobre una tematica delnostre interes. Mitjancant els motors de cerca existents (Google, Yahoo,etc.) podem trobar informacio relacionada amb ell pero perdem de vistatotes aquelles persones que estan relacionades amb el seu treball.

Si ens adonem, veiem que a partir d’un individu extraiem una xarxad’actors que intervenen en el seu treball. En aquest punt ens plantegem elsavantatges de trobar tot aquell individu que estigui relacionat amb el de lanostra cerca. D’aquesta manera podem trobar un ventall de gent relacionadaamb ell i que, segurament, treballen en la mateixa area que ell i ens aportennou coneixement.

Pero una persona pot estar vinculades amb altres que no son tan in-teressants per als nostres objectius. Per aquest motiu a l’hora de trobar elsindividus relacionats hem de poder descriure’ls i introduir aquesta informa-cio a la xarxa social per tal de poder trobar millor les arees d’interes que

4

CAPITOL 1. INTRODUCCIO 5

necessitem.Per tant, d’aquestes xarxes socials “ocultes” a Internet neix la proposta

d’aquest Projecte Final de Carrera. Ens plantegem la creacio d’un sistemacapac d’extreure xarxes socials a partir de persones, essent capacos de des-criure els individus i extraient tota aquesta informacio d’Internet, es a dir,de forma automatitzada.

Davant d’aquesta idea es plantegen multiples problematiques que s’abor-daran en aquest Projecte. En primer lloc les consultes al motor de cerca pertal d’extreure dades correctes, evitant problemes d’ambiguitat de noms. Ensegon lloc el problema de l’extraccio de coneixement a partir dels contingutsexistents en Internet. La diversitat de formats a l’hora de presentar la in-formacio dificulta l’extraccio de dades que descriguin els nostres actors i queens donin informacio correcta de les relacions amb altres individus.

Per altra banda existeix la fase d’analisi de la xarxa per crear els vinclesentre nodes i poder assignar el pes adient a cada relacio.

Per ultim, i no menys important, com representar la xarxa social. Elsistema ha de ser comode i facil d’usar per tal de trobar allo que estemcercant. L’extraccio de la descripcio semantica dels actors ens permetrafacilitar la navegacio per la xarxa amb eines com nuvols de tags que mesendavant descriurem.

Per dur a terme aquesta projecte, ens basarem en sistemes com Referralweb, Polyphonet, Flink entre altres. La seva finalitat es crear xarxes socialsa partir de la informacio publica que hi ha al web a partir dels motors decerca. Aquests sistemes utilitzen un llistat de noms per realitzar consultesals motors de cerca i analitzar les respostes que ofereixen per construir laxarxa social.

En el nostre cas afegim un factor innovador a aquests sistemes: l’extracciode dades semantiques que descriguin al nostre individu, aportant facilitats al’hora de la creacio de vincles entre actors i la navegacio per la xarxa social.

Si mirem l’entorn mes comercial de les xarxes socials podem trobar altrestipus de aplicacions que funcionen a Internet i amb forca exit. Les conegudesMySpace, Orkut, FaceBook son clars exemples. En l’ambit espanyol podemtrobar Neurona o Econozco entre altres. Tots aquests es basen en crear xarxessocials de manera activa, es a dir, les relacions/afinitats es creen a partir deles accions d’inclusio de contactes per part de l’usuari. D’aquesta manera espot explorar la teva xarxa social a partir del teus contactes de primer nivelli aixı iterativament fins a un nivell definit (normalment hi ha uns 6 nivells).

En el nostre cas els actors i els seus vincles els crearem de forma passiva,es a dir, tota la informacio l’extraurem d’Internet sense cap tipus de accioper part dels usuaris que formaran la xarxa social.

Com es pot extreure d’aquestes primeres lınies, es manipularan una gran

CAPITOL 1. INTRODUCCIO 6

quantitat de dades relacionades amb els actors de la xarxa social, i el sistemaha de ser capac de donar respostes rapides als usuaris referents a les sevescerques. No hem de perdre de vista que es un sistema que podria funcionaren Internet i el temps de carrega de la informacio ha de ser optim. Aquestsera un dels punts complexos a tractar.

Per aquests motius tambe forma part d’aquest Projecte l’estudi de l’opti-mitzacio d’aquesta plataforma web per tal de que pugui atendre eficientmenttotes les peticions que rebi. S’estudiara el disseny d’una aplicacio concur-rent, amb sistemes de cache que ens permetin accelerar els temps de respostai treballar amb un servidor adient per les nostres necessitats.

Per tal de definir un escenari on executar aquesta aplicacio, podem supo-sar un entorn universitari on es molt frequent cerques d’informacio relacio-nada amb els temes d’investigacio dels diversos departaments.

Capıtol 2

Xarxes Socials

2.1 Introduccio

La idea basica d’una xarxa social es simple: es tracta d’un conjunt d’ac-tors (o punts, nodes o agents) entre els que existeixen vincles (relacions). Lesxarxes poden tenir molts o pocs actors i una o mes classes de relacions entreparells d’actors.

L’analisi de les xarxes socials ens aporta uns resultats diferents als obtin-guts amb tecniques que es centren en les caracterıstiques dels individus i noen les seves relacions. Aquests resultats en moltes ocasions han estat moltsatisfactoris.

Per tant, la idea central de l’analisi de xarxes resideix en el suposat deque la gent te sentiments, pensa i el que fa te el seu origen i es manifesta enles pautes de les seves relacions que es donen entre actors. D’aquesta maneras’oposa aixı a la idea de que els atributs dels actors individuals siguin la causade les pautes de comportaments i de les estructures socials.

La raca, l’edat, el sexe, la categoria social importen menys que les formesde les relacions mantingudes o mantenibles que son les que realment posicio-nen a les unitats en l’estructura social: el que construeix les posicions socialsson les relacions mutues entre actors, els diferents vincles que els mantenenen xarxes socials.

Per consequent, l’explicacio de comportaments requereix una analisi decom els actors estan connectats els uns amb els altres en les diverses situacionsen els que son observats. L’analisi de xarxes es un conjunt conceptual i demetodes descriptius, estructurals i predictius per aconseguir-ho.

7

CAPITOL 2. XARXES SOCIALS 8

2.2 Analisi sociologic de Xarxes Socials

Les dades sociologiques estan composades per una matriu rectangularamb mesures. Les files de la matriu son els casos, subjectes u observacions.Les columnes son les puntuacions (quantitatives o qualitatives) dels atributs,variables o mesures. Llavors, cada cel·la de la matriu descriu la puntuaciod’algun actor respecte a un atribut.

En el cas de les xarxes socials l’estructura de dades fonamental es aquellaque permet comparar quin grau de similitud hi ha entre els actors en baseals atributs (comparant les files). O potser mes frequentment, examinaremla distancia entre les variables.

Les dades de la xarxa (en la seva forma mes pura) constitueix una matriuquadrada on les files son els casos, subjectes i observacions; i les columnesson el mateix conjunt de casos, subjectes i observacions. En cada cel·la de lamatriu es descriu una relacio entre els actors.

Qui es relaciona amb qui?

Eleccio

Informant Bob Carol Ted Alice

Bob — 0 1 1

Carol 1 — 0 1

Ted 0 1 — 1

Alice 1 0 0 —

Taula 2.1: Matriu de relacions entre actors

Comparant les files de la matriu podem observar que actors es semblena altres. Mirant les columnes podem veure qui es paregut a qui en termesd’haver estat escollit pels altres. Aquestes formes son molt utils per observarles dades, donat que serveixen per veure aquells actors que tenen posicionssimilars en la xarxa. Tambe podem comparar les cel·les que estan per sobrei per sota de la diagonal per mirar la reciprocitat entre les opcions.

Amb aquestes dades posem observar com els actors es descriuen a travesde les seves relacions, no dels seus atributs. I les relacions en si mateixes sontan fonamentals com els actors que es connecten a traves d’elles.

2.2.1 Nodes

Les dades de xarxa es defineixen per actors i per relacions. La part de lesdades de la xarxa corresponents a nodes o actors hauria de ser forca precisa.


L’analisi de xarxes es centra en les relacions entre actors, i no en elsactors individuals i els seus atributs. Aixo significa que els actors sovintno son mostrejats de forma independent, com en molts altres tipus d’estudis.Suposem que estudiem els vincles de l’amistat, per exemple. En Pere ha estatescollit per estar en la mostra. Quan li preguntem a ell, identifica set amics.Ara precisem rastrejar a cada un d’aquests set amics, i s’ha de preguntarsobre els seus vincles d’amistat. Els set amics estan en nostra mostra en tantque Pere ho esta (i viceversa). Per tant, els “elements de la mostra” no sonen cap cas “independents”.

Els estudis de xarxes intenten incloure tots els actors que es mostren enun lımit. Amb frequencia els estudis de xarxes no utilitzen “mostres” enabsolut, al menys en el sentit convencional. Al contrari, intenten inclouretots els actors en una poblacio o poblacions determinades.

2.2.2 Poblacions, mostres i lımits

Degut a que els metodes de xarxes es centren en les relacions entre elsactors, aquests no poden ser mostrejats independentment per incloure’ls coma observacions. Si un actor arriba a ser seleccionat, s’han d’incloure tots elsactors amb els quals aquest te (o pot tenir) relacions.

Els lımits de les poblacions estudiades pels analistes de xarxes podenser, basicament, de dos tipus. El primer d’ells probablement el mes comu,es el que ve creat o imposat pels propis actors. Tots els membres d’unaaula, organitzacio, club, veınatge o comunitat poden constituir una poblaciod’aquest tipus. Son aquests grups o xarxes articulades de manera natural.Per tant, els estudis de xarxes socials tracen sovint els lımits al voltant d’unapoblacio que es coneix, a priori, que es una xarxa. Alternativament, unaanalisi de xarxes pot assumir un punt de vista mes “demografic” per definirels lımits de la poblacio. Podem dissenyar observacions contactant tota lagent que es troba en un area espacial delimitada, o a aquells que tenen unacerta caracterıstica. En aquest cas hi ha motius per sospitar que la xarxaexisteix, pero la entitat a ser estudiada es una agregacio abstracta imposadaper l’investigador.

2.2.3 Relacions

L’altra part de la investigacio de dades reticulars te a veure amb quinsllacos o relacions seran mesurats en els nodes seleccionats. Hem de teniren compte que qualsevol conjunt d’actors pot estar connectat amb diferentstipus de llacos i relacions.


Donat un conjunt d’actors o nodes, hi ha algunes estrategies per decidircom actuar en la recol·leccio de mesures de les relacions existents. Seguida-ment mencionarem diversos tipus de mesures i xarxes.

Metodes de xarxes completes

Requereixen que es reculli informacio sobre els llacos de cada actor ambels altres. Ja que recol·lectem informacio sobre llacos entre parells, les da-des de xarxes completes aporten una fotografia complerta de les relacionsen la poblacio. La majoria dels enfocaments i metodes especials d’analisi dexarxes que veurem, foren desenvolupades per ser usades amb dades de xar-xes complertes. Les dades d’aquestes xarxes son necessaries per definir-lesapropiadament i per mesurar molts dels conceptes estructurals de l’analisi dexarxa (per exemple el grau d’intermediacio)

Les dades de xarxes complertes ens condueixen a descripcions molt po-tents i a analisis d’estructures socials. Malauradament, poden tambe ser moltcostoses i difıcils d’obtenir. Obtenir dades de cada membre d’una poblacio itenir cada rang o ındex de cada un dels altres, poden ser tasques desafiantsper qualsevol grup, excepte per als petits. El treball es fa mes manejabledemanant a informants que identifiquin un nombre limitat d’individus es-pecıfics amb els quals aquests tenen relacions. Llavors, aquestes llistes escompilen i interconnecten. Pero, per a grups grans (per exemple, totes lespersones d’una ciutat) la tasca es impossible.

Per exemple podem examinar el nombre de vehicles que transiten entreparells de ciutats; podem mirar el fluxe de correus electronics entre tots elsparells de treballadors d’empleats d’una companyia; podem dir-li a cada nenen un grup de jocs que identifiqui els seus amics entre els altres.

Metode de “bola de neu”

Aquests comencen focalitzant un actor o conjunt d’actors, a cadascun delsquals se’ls pregunta per alguns dels seus llacos amb altres actors. Llavors, esprenen tots els actors mencionats (que no formin part de la llista original) ise’ls pregunta de nou per alguns dels seus llacos. El proces continua fins queno s’identifiquen nous actors o fins que es decideixi parar-lo.

Hi ha dos grans restriccions:

• En primer lloc, els actors que no estan connectats no es poden descriurea traves d’aquest metode.

• En segon lloc, no hi ha cap forma garantida de trobar tots els individusconnectats dins de la poblacio.


El metode de la bola de neu pot ser molt util per el seguiment de poblacion”especials” (sovint subconjunts de gent numericament petits, mesclats ambaltres mes grans). Les xarxes de contactes de negoci, subcultures desviades,xarxes de parentiu i moltes altres estructures poden ser efectivament ubicadesi descrites a traves de metodes de bola de neu.

Xarxes egocentriques (amb connexions a altres)

Una visio alternativa, a la bola de neu, es comencar amb una seleccio denodes focals (egos), e identificar els nodes amb els que ells estan connectats.Llavors determinem quins dels nodes identificats en la primera fase estanconnectats amb els altres. Aixo pot fer-se contactant cadascun dels nodes; avegades podem demanar a ego que ens informi dels nodes amb els que estaconnectat te llacos amb altres.

Aquest punt de vista pot resultar molt efectiu per obtenir un formulari dedades relacionals de poblacions grans i pot combinar-se amb tecniques basa-des en els atributs. Per exemple, podem prendre una mostra simple aleatoriad’estudiants universitaris homes, i demanar que identifiquin als seus amicsmes propers i quins d’aquest coneixen a altres. Aquest tipus de practica potdonar-nos una imatge bona i fiable dels tipus de xarxes en les quals es trobenels individus. Podem obtenir resultats tals com quants nodes de connexionstenen i fins quins punts aquests nodes formen nuclis forts. Aquestes dadespoden ser molt utils per entendre les oportunitats i restriccions que tenenels individus, com resultat de la forma en la que estan ubicats en les sevesxarxes.

Xarxes egocentriques (nomes individus)

Els metodes egocentrics realment es centren en l’individu mes que en laxarxa com a totalitat. Recol·lectant informacio dels vincles entre els actorsconnectats amb cada individu, podem inclus fer una bona fotografia de lesxarxes locals o veınals d’individus.

Suposem, en canvi, que obtenim informacio dels vincles de l’individu ambels altres, pero no sobre les connexions entre aquests individus. Dades d’a-quest tipus no constitueixen realment dades d’una xarxa com a tal. Es a dir,no poden representar-se com una matriu quadrada de llacos actor * actor.Pero no significa que les dades egocentriques sense connexions entre els altresno serveixen per que els analistes utilitzin un metode estructural o de xarxaper entendre els actors. Podem saber, per exemple, que alguns actors tenenmolts amics molt propers i familiars i altres pocs.

Per exemple, si identifiquem cadascun dels altres connectats a un ego a


traves d’una relacio d’amistat com “parent”, “company de treball”, “membrede la mateixa esglesia” etc. podem construir una fotografia de les xarxes deles posicions socials (mes que les xarxes d’individus) en les quals es trobenimmersos els egos. Aquesta practica, per suposat, assumeix quines categoriescom “parent” son reals i importants per els patrons de interaccio.

2.2.4 Relacions multiples

En un conjunt de dades convencional del tipus actor * atribut, cada actores descrit a traves de moltes variables (i cada variable es atribuıda a diversosactors). En el tipus mes comu de conjunt de dades de xarxes socials sobreactor * relacio. En quan estem interessats en multiples atributs dels actors,estarem interessats en multiples tipus de relacions que connecten a aquestsa la xarxa.

Els actors poden estar enllacats a altres de forma propera en una xar-xa relacional, pero poden estar molt distants d’altres en un xarxa relacionaldiferent. Les ubicacions dels actors en xarxes multirelacionals i la estruc-tura de xarxes compostes de multiples relacions, son una de les arees, mesinteressants i encara relativament poc explorades, de l’analisi social.

2.2.5 Escales de mesura

Generalment es distingeixen tres tipus de nivells de mesura: nominal,ordinal i d’interval. Es util dividir la mesura nominal en variacions binaries ide categoria multiple; tambe es util distingir entre mesures ordinals de rangcomplert i mesures ordinals agrupades.

Mesures binaries de relacions

En la majoria d’ocasions per assignar numeros a relacions es facil distingirentre relacions absents (codificades amb un zero) i llacos que estan presents(codificats amb un u).

Si demanem a informants en una enquesta que comentin “amb quinesd’aquestes altres persones de la llista simpatitza?” estarem fent una mesurabinaria. Cada persona seleccionada de la llista sera codificada amb un u. Elsno seleccionats estaran codificats amb un zero.

La major part del desenvolupament de la teoria de grafs en matematiquesi molts algoritmes per la mesura de propietats d’actors i xarxes, han estatdesenvolupats a traves de dades binaries. Les dades binaries son ampliamentutilitzades en l’analisi de xarxes, aixı que no es poc frequent trobar dadesmesurades en el nivell “mes alt” transformats en puntuacions binaries abans


de procedir a l’analisi. Per fer aixo, simplement se selecciona algun “puntde tall” i es torna a recodificar els casos per sota d’aquest punt amb zeroo per sobre d’ell amb u. Les dades binaries impliquen perdua d’informacio.Molt sovint, el poder i simplicitat de l’analisi de dades binaries compensa laperdua d’informacio.

Mesures nominals de categoria multiple de les relacions

En la recol·leccio de dades podem demanar als nostres informants quemirin una llista d’individus i per cada persona en la llista, quina categoriadescriu millor la seva relacio amb ell: amistat, amor, relacio de negocis,parentiu o cap relacio. Hem de puntuar cada persona en la llista segonstingui una relacio de tipus “1”, “2”, etc. Aquest tipus d’escala nominal oqualitativa (cada relacio de la persona cap al subjecte es codificada pel seutipus, mes que per la seva fortalesa).

A diferencia de les dades binaries nominals (vertader - fals), la mesuranominal de categoria multiple es una seleccio multiple.

Mesures ordinals agrupades de relacions

Una de les primeres tradicions en l’estudi de xarxes socials interroga alsinformants sobre l’ındex en que altres els “agraden”, “desagraden” o els son“indiferents”. El resultat es una escala ordinal agrupada. Sovint, aquesttipus d’escala de tres punts ha estat codificada: -1, 0 i +1, per reflectirrebuig, indiferencia i atraccio, respectivament. Quan es puntua d’aquestaforma, els signes positius i negatius, fan mes facil escriure algoritmes quetindran en compte i descriuran diverses propietats de la xarxa.

Les analisis de xarxes sovint estan involucrades en la descripcio de la“forca” dels llacos. Una dimensio es la frequencia de la interaccio (els actorstenen contacte diariament, setmanalment, mensualment, etc.). Altra dimen-sio es la “intensitat”, la qual sovint reflexa el grau d’implicacio emocionalassociat amb la relacio. Les relacions recıproques tambe semblen ser mesfortes.

Les escales ordinals de mesura contenen mes informacio que les nominals.En canvi amb frequencia es difıcil aprofitar les dades ordinals. Els algoris-mes mes utilitzats per l’analisi de les xarxes socials han estat dissenyats perdades binaries. Les dades ordinals, en consequencia, sovint son convertidesen binaries escollint algun tipus de tall i recodificacio.


Mesures d’interval de relacions

El nivell mes avancat de mesura ens permet discriminar entre relacions in-formades de forma tal que poden validar-se el seu estat, per exemple “aquestllac es dues vegades mes fort que aquest altre“. Els llacos son valorats enescales en les que la diferencia entre un “1” i un “2” mostren la mateixadiferencia real que entre “23” i “24”.

Veritables mesures d’interval de la forca de molts tipus de relacions sonrelativament facils de construir amb una mica d’imaginacio i perseveranca.Demanar als informants que informin dels detalls de la frequencia o inten-sitat dels llacos a traves de metodes com questionaris o entrevistes podenser, en canvi, menys fiables. Mes que preguntar si dues persones es comuni-quen, un pot contar el numero de lliuraments de correu electronic, trucadestelefoniques i correu intern entre ells. En molts casos es possible construirnivells de mesura d’intervals de la forca de relacions utilitzant eines d’obser-vacio.

Les mesures continues de la forca de les relacions permeten l’aplicacio d’unampli rang d’eines matematiques i estadıstiques per la exploracio i analisi dedades. Molts dels algorismes que han estat desenvolupats pels analistes dexarxes socials, originalment pensats per dades binaries, han estat ampliatsper aprofitar la informacio disponible en les mesures d’intervals. On siguipossible, les connexions han de mesurar-se en el nivell de l’interval.

2.3 Representacions de Xarxes Socials

Per fer l’analisi de xarxes socials s’utilitzen dos tipus d’eines matematiquesper representar informacio sobre els patrons de relacions entre actors socials:grafs i matrius. En aquest apartat farem una pinzellada sobre els dos tipusi veurem de quines maneres s’empren en l’analisi de xarxes socials.

L’us d’aquestes tecniques en entorns matematics disposen de subdiscipli-nes dedicades completament a la teoria de grafs i algebra de matrius. Elscientıfics socials han agafat unes quantes eines que pensen que poden ser utilsper descriure i analitzar les estructures de les relacions socials.

2.3.1 Grafs

Els sociolegs empren els grafs per representar els actors en nodes i lesrelacions amb fletxes. Quan els sociolegs van prendre aquesta forma de re-presentacio dels matematics, renombraren els seus grafs a “sociogrames”.

Existeixen moltes variacions en els sociogrames, pero tots ells compar-teixen la caracterıstica comu de l’us d’un cercle etiquetat per cada actor


en la poblacio que descrivim i segments de lınia entre parells d’actors perrepresentar el fet que existeix un vincle entre ells.

Seguidament descriurem els tipus de grafs mes emprats en l’analisi socio-logic.

Figura 2.1: Graf d’una xarxa social

Grafs binaris, orientats i ponderats

En el cas de preguntar als entrevistats “Aquesta persona es o no un amicproper?” estem demanat una resposta binaria: cada persona es o no escollidaper cada entrevistat. Moltes relacions socials poden ser descrites d’aquestaforma: l’unic que importa es si existeix o no el vincle. Una fletxa representaque es va fer una nominacio i cap representa la inexistencia d’una nominacio.

Si haguessim fet la pregunta d’una altra forma: “per cada una de les per-sones d’aquesta llista, indiqui si l’agrada, desagrada o no l’importa” Podem


assignar un + per indicar “atraccio”, zero per indicar “no importa” i un - perindicar “rebuig”. Aquesta classe de dades s’anomenen dades amb signe. Elgraf amb dades orientat utilitza un + en la fletxa per indicar una nominaciopositiva, un - per indicar una nominacio negativa i cap fletxa per indicar unaposicio neutral o indiferent.

En canvi, pot realitzar-se la pregunta des d’una perspectiva diferent: “or-deni tres persones d’aquesta llista segons el grau d’atraccio” Aixo ens donaraordres de posicions o dades ordinals, que descriuen la fortalesa de cada no-minacio d’amistat. Finalment hem pogut preguntar “en una escala de menys100 a mes 100 ( on -100 significa odi a aquesta persona, zero significa quese sent neutral i +100 indica que s’estima a aquesta persona ) com se sentvers...”. Aixo ens donara informacio sobre el valor de cada nominacio en un(al menys suposat) nivell proporcional de mesura. Tant en un graf ordinalcom en un ponderat, podrem col·locar la mesura de la fortalesa de la relacioen la fletxa del diagrama.

Vincles orientats o “recıprocs” en el graf

En l’exemple anterior demanavem a cada membre entrevistat que escollısa aquells del grup que considerava com amics propers. En aquest cas, a cadapersona (ego) se li ha preguntat sobre els vincles o relacions que ells mateixosdirigeixen cap a altres (alters).

Els grafs orientats utilitzen la convencio de que els actors o nodes esconnecten a traves de lınies que tenen punta de fletxa per indicar qui orientael vincle a qui. Aixo es el que fem en els grafs anteriors, on els individus (egos)dirigien les seves nominacions cap als altres (alters). Els grafs de “recıprocs”utilitzen la convencio de que els actors involucrats en la relacio es connectenamb un segment de lınia simple (sense punta de fletxa).

Relacions simples o multiples en el graf

La informacio que hem presentat sobre l’estructura social del nostre grupde persones es molt simple. Es a dir, descriu nomes a un tipus de vincle orelacio (nomenar a un amic proper). A un graf que representa un unic tipusde relacio se l’anomena graf simple. Les estructures socials, en canvi, sonsovint multiples. Es a dir, hi ha moltes formes diferents de vincles entre elsactors socials.

Podem afegir un segon tipus de relacio al nostre exemple, preguntant sies famılia de cada un dels altres. Podem veure que afegint aquest segon tipusde vincle, accentua la fortalesa de les relacions entre els actors (o potser lapresencia d’un vincle familiar expliqui la nominacio como bons amics entre


ells).La problematica existeix en combinar tota aquesta informacio en un ma-

teix graf, ja que el pot fer molt difıcil d’interpretar. En aquest cas s’usenmultiples grafs amb els actors ubicats cada vegada en el mateix lloc.

2.3.2 Matrius

Els grafs constitueixen una manera molt util de representar la informaciosobre xarxes socials. En canvi, quan existeixen molts actors i/o moltes classesde relacions, aquest poden fer-se tan visualment complicats que es fa moltdifıcil identificar estructures. En el seu lloc, tambe es possible representar lainformacio sobre xarxes socials en forma de matrius. D’aquesta manera larepresentacio de la informacio permet la utilitzacio d’eines matematiques ide computacio per identificar estructures.

Bob Carol Ted Alice

Bob — 0 1 1

Carol 1 — 0 1

Ted 0 1 — 1

Alice 1 0 0 —

Taula 2.2: Matriu d’una xarxa social

La matriu d’adjacencia

La forma mes comu de matriu en l’analisi de xarxes socials es una ma-triu simple composta per tantes files i columnes com actors existeixen en elconjunt de dades i on els elements representen els vincles entre els actors. Lames simple i comu de les matrius es la matriu binaria. Es a dir si existeix unvincle, es col·loca un 1 en la cel·la, si no hi ha s’escriu un zero. S’anomenad’adjacencia perque representa qui esta a prop de qui.

La matriu asimetrica ens representa vincles dirigits. Es a dir, l’element(i,j) no necessariament es igual que l’element (j,i). Si els vincles que represen-tem en la nostra matriu foren “vincles recıprocs” la matriu necessariamentseria simetrica; es a dir, l’element (i,j) seria igual a l’element (j,i).

Els grafs dirigits es representen en forma de matriu amb -1, 0 i +1 perindicar relacions negatives, nul·les o neutrals i relacions positives.

Moltes vegades en la representacio de dades de xarxes socials com matrius,la pregunta que sempre sorgeix es: que fem amb els elements de la matriu oni=j? Es a dir, per exemple: En Pere s’ha considerat como amic proper d’ell


mateix? A aquesta part de la matriu se la coneix com la diagonal principal.La majoria de vegades, el valor de la diagonal principal li manca significat is’ignora.

2.4 Terminologia de les xarxes socials

Per la comprensio de les xarxes socials, es necessari coneixer al menys unconjunt de termes basics. Es presenta a continuacio un petit glossari:

• Densitat: mesura la proporcio de relacions existents sobre el total derelacions possibles. Indica la densitat de les relacions en el conjunt dela xarxa.

• Sub-grups (“cliques”) son grups especials, que es caracteritzen per-que cada membre ha de tenir relacio directa amb cadascu dels altresmembres. Es l’estructura que esta mes fortament cohesionada. Esconsiderada la columna vertebral de la xarxa.

• Path o camı: es tracta de la sequencia d’enllacos i actors que connectendos actors no adjacents, sense que es repeteixin cap de ells. La longituddel path esta determinada per el numero d’enllacos. Posa de manifestl’existencia d’una connexio indirecta.

• Distancia geodesica: Ees el path mes curt entre dos nodes o actors d’unaxarxa. Tambe anomenada longitud geodesica, o simplement distancia.

2.4.1 Mesures de centralitat

Mesures destinades a la deteccio i identificacio dels actors centrals o mesimportants d’una xarxa. Aquest tipus de mesures es basen en la teoria degrafs. La idea de centralitat Estudia els actors mes centrals, mes prominents,mes poderosos i prestigiosos. S’utilitzen diversos indicadors i cadascun d’ellsaporta una informacio especıfica sobre les dimensions del prestigi i el po-der. Entre les mesures que s’utilitzen per la seva mesura estan el grau, laintermediacio i la fluıdesa.

Podem definir diverses mesures de centralitat:

• Grau de centralitat (Degree centrality): es una mesura de poder. Siun actor te mes enllacos amb altres actors, tindra diverses formes desatisfer les seves necessitats i ser menys depenent d’altres individus;tindra mes oportunitat d’aprofitar la seva posicio d’intermediari entrealtres actors.


• Grau d’entrada (InDegree): es la unitat mes simple de centralitat.Numero d’actors que es relacionen de forma directa (es contacten) aun determinat actor. Es considera que els actors que son contactatsper molts altres actors son prestigiosos. Possiblement es l’indicadorideal per l’analisi de poder i prestigi.

• Grau de sortida (OutDegree): numero de connexions/relacions directesque s’originen d’un actor cap als altres. Reflexa l’actitud social de cadaactor, aixı com la seva capacitat per accedir a la resta d’actors.

• Intermediacio (“Betweenness centrality”): mesura de poder. Ens in-dica en quina mesura l’actor esta en una posicio intermediaria en lescomunicacions mes curtes entre la resta d’actors. Els actors amb ma-jor intermediacio tenen un gran poder perque controla els fluxos decomunicacions optims.

• Fluıdesa (“Flow betweenness centrality”): expandeix el concepte denivell d’intermediacio. El nivell d’intermediacio nomes pren en con-sideracio el camı mes curt entre dos actor, pero si un actor bloquejaaquest camı, llavors buscara un altra alternativa. Aquesta mesura prenen consideracio quant involucrat esta un actor en les connexions que esdonen entre altres parells d’actors.

• Centralitat de apropament (Closeness): aquests tipus de mesura esbasa en l’apropament o distancia i mesura quant esta de proper unactor de la resta d’actors de la xarxa. Quant mes central sigui l’actor,major sera la seva capacitat d’interaccio amb la resta d’actors.

2.5 Lınies d’investigacio en Xarxes socials

2.5.1 Introduccio

Sobre l’area en la que es desenvolupara aquest Projecte Final de Carre-ra existeixen algunes lınies d’investigacio obertes en les quals es basen elsfonaments de la nostra investigacio. Tal i com s’ha comentat en la introduc-cio els tres sistemes pioners en aquest camp son Referral Web[5], Flink[10] iPolyphonet[14].

El primer sistema que va apareixer dedicat a l’extraccio d’informacio delweb es Referral Web (Kautz & Selamn, 1997) el qual fou dissenyat per ex-treure xarxes socials a partir de consultes al motor de cerques Altavista.Recentment s’han presentat els sistemes Polyphonet (Matsuo, 2006) i Flink


(Mika, 2004) els quals aprofundeixen sobre les conclusions extretes de Refer-ral Web i amplien el potencial d’aquests sistemes afegint noves funcionalitats.

Com es pot veure, es un area d’investigacio pionera i molt jove, on existei-xen molts camps de desenvolupament i investigacio encara per desenvolupar.

En aquest punt explicarem en que consisteixen aquests tres estudis pertal de coneixer millor les lınies d’investigacio obertes en aquest camp.

2.5.2 Referral Web

Referral Web (Kaut & Selamn, 1997)[5] es un dels primers sistemes queutilitza la informacio existent en Internet per crear una xarxa social. Enaquest cas s’utilitzava el motor de cerques Altavista i la xarxa social que esgenerava era egocentrica, es a dir, centrada en un individu determinat.

El sistema proposava que en donar-se d’alta un usuari al sistema, aquests’encarrega de cercar informacio relacionada amb ell en la Web utilitzant elcercador ja esmentat, associant l’usuari amb aquelles persones mencionadesamb mes frequencia al seu voltant. Aquest proces es repeteix iterativamenttantes vegades com es defineixi amb la finalitat d’establir la xarxa socialde l’usuari. Posteriorment la informacio que es recomana a cada personaextreta de documents generats per membres de la xarxa social o proxims ala mateixa.

La idea de Referral Web neix de la teoria que un individu esta connectatamb qualsevol persona del mon a partir de sis graus de separacio. Aquestaidea es una de les principals teories que es van crear relacionades amb lesxarxes socials es la teoria dels sis graus de separacio (six degrees), segonsla qual tota la gent del planeta esta connectada a traves de no mes de sispersones. Es a dir, que aquesta teoria ens parla que qualsevol a la Terrapot estar connectat a qualsevol altra persona del planeta a traves d’unacadena de coneguts que no te mes de quatre intermediaris. Aquesta teoriafou inicialment proposta en 1929 per l’escriptor hongares Frigyes Karinthy enuna curta historia anomenada Chains [8]. El concepte esta basat en la ideaque el numero de coneguts creix exponencialment amb el numero d’enllacosen la cadena, i nomes un petit numero d’enllacos son necessaris per a que elconjunt de coneguts es converteixi en la poblacio humana sencera.

Centrant-nos en el funcionament del sistema, aquest nomes necessitaconeixer el nom de l’ego per poder crear la xarxa social de manera incre-mental. Quan un usuari es registra en el sistema, aquest usa el motor decerca per recuperar els documents web que el mencionen. Llavors els nomsd’altres individus que apareixen en els resultats son extrets mitjancant un re-coneixedor d’entitats (Name Entity Recognition NER) per assegurar un 90%d’encert. El resultat tıpic es una llista de centenars de vincles amb l’individu.


Aquesta llista es refinada amb el coeficient de Jaccard (Jaccard, 1901)[7]aplicat entre l’usuari i cada membre de la llista. Aquest coeficient es calculatdividint el numero de pagines indexades pel motor amb ambdos noms dividitentre el nombre de pagines que contenen cada un dels noms per separat.Aquest proces es aplicat de forma recursiva per un o mes nivells, i el resultates fusionat en la xarxa global.

L’usuari no introdueix cap tipus d’informacio personal en el sistema. Toti aixı, la xarxa conte centenars o milers d’individus que mai s’han registrat enReferral Web. Aixo trenca per primera vegada amb els sistemes comercialson l’usuari crea les relacions amb els altres de forma manual per tal de crearla xarxa social.

Quan la base de dades estava buida, Referral Web podia trigar unes 24hores en generar la xarxa social de nivell 3 per un usuari. La velocitat delspider s’incrementa d’una manera considerable. Si un nou usuari apareixen el sistema, immediatament s’usen les dades internes i el spider funcionaoffline, augmentant la velocitat del proces.

Figura 2.2: Exemple de una consulta a al sistema Referral Web


El problema principal d’aquesta implemetacio es l’ambiguitat de noms.Dues persones amb el mateix nom pero amb cap tipus de relacio poden inter-ferir en els resultats d’una cerca. Per aquest motiu, s’afegeix unes metadadesque identifiquin temes relacionats amb aquest individu per tal d’identificar-loentre aquells que tenen el mateix nom.

En la figura 2.2 podem veure els camps que es demanen per comencar laexploracio en la Web. Entre els camps existent veiem el camp Find expert(s)en the following topic que ens permet trencar l’anbiguitat del noms.

2.5.3 Flink

Flink1 (Peter Mika, 2004)[10] guanyador del primer premi del SemanticWeb Challenge2 de 2004, ens aporta noves idees en l’extraccio de xarxessocials a partir de la informacio emmagatzemada en Internet.

Flink ens mostra una representacio dels vincles professionals i socials exis-tents en la web semantica. Flink te tres objectius:

1. Fer una demostracio de l’us de la tecnologia de la web semantica.

2. Fer un portal on qualsevol persona que estigui interessada en aprendresobre el treball de la comunitat de la web semantica.

3. Obtenir una col·lecio de dades utilitzades per finalitats de l’analisi deles xarxes socials, en particular de l’aprenentage sobre el poder naturali les innovacions de les comunitats cientıfiques.

1http://flink.semanticweb.org2http://challenge.semanticweb.org

http://flink.semanticweb.org

http://challenge.semanticweb.org


Figura 2.3: Arquitectura de Flink des de l’extraccio de metadades fins l’usauri

L’arquitectura de Flink se separa en tres capes segons ens explica el seuautor. Aquestes estan relacionades amb l’adquisicio de metadades, emma-gatzemament i per ultim visualitzacio. Ho podem veure en la figura 2.3 dedalt a baix.

El sistema es capac de visualitzar xarxes socials de la comunitat de webssemantiques. La informacio sobre els investigadors i les seves relacions es ex-treta de la web, dels perfils FOAF3, emails i publicacions. Flink en si mateixutilitza la tecnologia de la web semantica per representar, emmagatzemar lesmetadades.

El proces de Web mining de Flink es molt similar al de Kautz & Selmande Referral Web[5], utilitzant l’analisi de la coocurrencia amb el coeficient deJaccard.

2.5.4 Polyphonet

Per ultim comentarem el sistema Polyphonet (Matsuo, 2006)[14]. Polyp-honet neix dels estudis realitzats per Kautz & Selman[5]. El sistema funciona

3Friend Of A Friend http://www.foaf-project.org/

http://www.foaf-project.org/


amb una llista de noms i a partir d’ells extreu la xarxa social relacionada ambells amb les dades que li retorna el motor de cerca Google.

L’extraccio de la xarxa social s’efectua en dos passos. Un primer on esgeneren els nodes i el segon on es creen els vincles. Per tant una vegada ques’obte la llista de nodes es busca l’afinitat entre ells. En el cas de Polyphonet ia diferencia de Flink i Referral Web, s’usa el coeficient overlap[16] per calcularl’afinitat entre actors. Podem veure la formula matematica en l’equacio 2.1.

afinitat =nX∩Y

min(nX , nY )(2.1)

Un dels problemes que es troben davant d’aquest sistema es l’ambiguetatdels noms. Polyphonet soluciona aquest tema afegint una o diverses paraulesclau que identifiquin el tema en el que s’esta buscant i que defineixi a lapersona. Aquest metode ens aporta resultats pero tambe implica una perduad’informacio valida.

Figura 2.4: xarxa social a traves de tres actors en Polyphonet

Polyohonet tambe introdueix nous algorismes que complementen l’extrac-cio de la xarxa social:

• Extraccio del tipus de relacio, analitzant els resultats extrets i definint-la entre: co-autor, membres del mateix laboratori, membres del mateix


projecte o participants de la mateixa conferencia o workshop. Cadarelacio pot tenir diferents categoritzacons podent ser per exemple: co-autors i membres del mateix laboratori.

• Millorar la escalabilitat reduint el nombre de consultes al motor de cercaquan hi ha xarxes socials molt denses. D’aquesta manera millorem elcost d’execucio del sistema.

2.6 Implementacions comercials de Xarxes So-

cials

En aquesta seccio veurem l’altra cara de les xarxes socials. Amb el boomde l’anomenada Web 2.0 s’ha donat molt d’enfasi a les comunitats d’usuaris.Ara es dissenyen les noves aplicacions Web enfocades a l’usuari com a unitatprincipal. Aixo a fet creixer l’interes de les xarxes socials des del punt devista que els usuaris “creen” el contingut de l’aplicacio amb les seves dades,les seves relacions i tot allo que envolta els seus perfils.

Aquest concepte de xarxa social, es distingeix de la nostra proposta deProjecte Final de Carrera en que les relacions/vincles que es creen son apartir de l’accio de l’usuari. Es a dir, un usuari marca quins son els seuscontactes i, a partir d’aquı, la seva xarxa social creix amb els contactes delscontactes, etc..

L’origen de les xarxes socials en el mon Web, es remunta a 1995 quanRandy Conrads crea classmates4. Amb aquesta xarxa social preten que lagent pugui recuperar o mantenir el contacte amb antics companys de col·legi,institut, universitat, etc.

En 2002 comencen a apareixer llocs web promocionant les xarxes de cer-cles d’amics on-line quan el terme s’aplicava per descriure les relacions enles comunitats virtuals, i es va fer popular en 2003 amb l’arribada de llocstals com Friendster5, MySpace6 i LinkeIn7. La popularitat d’aquests llocsva creixer rapidament i grans companyies han entrat en l’espai de les xarxessocials en Internet. Per exemple, Google llanca Orkut8 el 22 de gener de2004.

En aquestes comunitats, un numero inicial de participants envien missat-ges a altres membres de la seva propia xarxa social convidant-los a unir-se

4http://classmates.com5http://www.friendster.com/6http://www.myspace.com/7http://www.linkedin.com8http://www.orkut.com/

http://classmates.com

http://www.friendster.com/

http://www.myspace.com/

http://www.linkedin.com

http://www.orkut.com/


al lloc. Els nous participants repeteixen el proces, creixent el nombre totalde membres i els enllacos de la xarxa. Els llocs ofereixen caracterıstiquescom actualitzacio automatica de la llibreta de direccions, perfils visibles, lacapacitat de crear nous enllacos mitjancant serveis de presentacio i altresmaneres de connexio social en lınia. Les xarxes socials tambe poden crear-seal voltant a les relacions comercials, com els casos de ReferNet, Shortcut oles espanyoles NoticiasdelVino, eMisterios, puroMarketing, Neurona9 i eCo-nozco10.

Figura 2.5: Neurona.com: Exemple de xarxa social d’un usuari

Les eines informatiques per potenciar l’eficacia de les xarxes socials on-line, operen en tres ambits de forma creuada:

• Comunicacio: ens ajuden a posar en comu coneixements.

• Comunitat: ens ajuda a trobar e integrar comunitats.

• Cooperacio: ens ajuden a fer coses junts.

9http://www.neurona.com/10http://www.econozco.com/

http://www.neurona.com/

http://www.econozco.com/


La gent fan us d’aquests llocs de xarxes socials amb finalitats personals iprofessionals, per a comunicar-se, crear nous contactes de negocis, etc. L’usper gestionar i crear d’una manera facil i eficient les seves xarxes socialsoffline d’un mode on-line.

Altres motivacions d’aquestes xarxes socials es el nou significat de socia-litzar i construir noves comunitats de persones[6]; les xarxes socials fan mesfacil unir-se i connectar amb gent nova o comunitats que tenen, per exemple,una ubicacio geografica similar, i poder compartir amb ells interessos comunsi unir diverses “tribus” urbanes. Els membres dels sites estan ansiosos perincrementar la seva visibilitat dins de la xarxa, i augmentar la seva propiaxarxa per fer-se mes popular i important.

Per tant podem veure amb aquesta petita descripcio quines son les di-ferencies entre el que es proposa aquest Projecte Final de Carrera i el signi-ficat que te actualment en el mon comercial les xarxes socials.

Capıtol 3

Analisi de requeriments


Si ens parem a pensar un segon sobre la informacio que cerquem veuremque existeixen vincles i relacions entre elles que a vegades no som capacos deveure a simple vista. El coneixement neix d’un punt i s’expandeix ampliant-loi completant-lo amb noves idees. Pero sempre queda un vincle entre l’ori-gen i el final que pot aportar-nos informacio fonamental per a les nostresintencions. Per tant analitzant aquesta situacio podem dir que a partir d’unarea, tema o persona, neix una xarxa de coneixement social que ens permetnavegar per tot el que es despren d’aquest origen de coneixement.

La utilitzacio de sistemes d’intel·ligencia ens permeten produir informacioestrategica a partir d’una o diverses fonts. Aquests sistemes han de satis-fer una serie de funcions: obtenir de la forma mes eficient la informacio,analitzar-la i interpretar-la per tal de garantir que es correspon amb el quevolem i comunicar-la rapidament a qui la necessiti. Tot aquest proces conteuna part no automatica que consisteix en la localitzacio i recopilacio de lainformacio assistida per sistemes d’informacio (motors de cerca, metabusca-dors, acces a bases de dades bibliografiques, etc.)

El nostre objectiu es poder fusionar les xarxes socials que existeixen ocul-tes en la informacio publica que ens ofereix Internet, sobre les arees que esdesitja investigar, amb els sistemes d’informacio que intenten gestionar-les,per tal de poder automatitzar tot el proces d’adquisicio de coneixement.

28

CAPITOL 3. ANALISI DE REQUERIMENTS 29

3.1 Objectius

El nostre objectiu es crear una aplicacio capac d’extreure d’Internet xar-xes socials a partir d’un llistat de persones identificades pel seu correu electronic.Per tal de veure les relacions entre elles i la xarxa que es despren d’aquestespersones.

Les afinitats de la xarxa social seran del tipus multiple, contemplant dostipus de relacions amb els actors:

1. A partir dels resultats obtinguts al realitzar les consultes al motorde cerca. Depenent del numero de “hits” en una consulta del tipusresultats(A ∧B) en funcio dels resultats(A).

2. A partir de les descripcions semantiques extretes del actors. De talmanera que poden existir relacions entre dos individus que treballen enel mateix pero no tenen una connexio directa. Aquest tipus de relacioes molt interessant per poder crear nous vincles de treball.

3.2 Metodologia

El proces consta de 4 parts diferenciades. Seguidament es mostren elspassos aproximats que el sistema ha de realitzar per dur a terme tot el proces:

1. Recol·leccio de la informacio: a partir dels resultats obtinguts pelsmotors de cerca extraiem les dades necessaries per poder construir lanostra xarxa social. Aquest proces consta de diverses parts:

• Definicio de les consultes a realitzar als motors de cerca per obtenirdades fiables i relacionades amb la tematica a tractar.

• Utilitzacio d’algoritmes d’interpretacio del llenguatge natural ba-sats en el Web Mining, per l’extraccio d’informacio relacionadaamb els autors en forma d’etiquetes (tags). D’aquesta forma els ac-tors (nodes) de la nostra xarxa social es defineixen semanticamentper tal de crear les relacions d’afinitats i facilitar les tasques denavegacio.

2. Analisi: amb aquesta fase podem observar i estudiar la nostra xarxaamb la informacio que conte la propia xarxa. En aquest punt utilit-zarem diverses tecniques per crear relacions, basant-nos en les dadessemantiques i les seves afinitats. Amb l’analisi podem extreure carac-terıstiques com:

CAPITOL 3. ANALISI DE REQUERIMENTS 30

• Quins son els actors mes influents en la xarxa; quin es el seuimpacte dins de l’estructura social.

• Quins son els centres d’interes de la xarxa social; similituds i agru-pacions per les definicions dels actors.

3. Navegacio per la xarxa social: per ultim s’ha de poder navegar perla xarxa social amb facilitat per poder trobar aquella informacio ne-cessaria. Gracies a la previa clusteritzacio i a la definicio semanticadels actors podrem facilitar la navegacio per la xarxa, utilitzant nuvolsde tags per donar una idea global dels temes de la xarxa segons la sevaimportancia.

Com podem veure el nostre sistema es basa en els actors que creen laxarxa social. Per tant s’aplica un canvi a l’hora de adquirir la informaciodesitjada, doncs el inici de la cerca resideix des d’un nom de persona fins unllistat de noms relacionats amb la tematica a cercar o a partir d’una tematicaconcreta.

Sobre aquestes tecniques ja existeixen estudis relacionats amb elles. Elsmes destacats i amb mes projeccio son REFERRAL WEB (Kautz & Selman1997), POLYPHONET (Matsuo 2003, 2006) i FLINK (Mika 2004). Tots ellshan presentat estudis sobre l’extraccio de xarxes socials a partir dels motorsde cerca.

El nostre treball presenta diverses innovacions respecte aquestes aplicaci-ons:

• Analisi semantica dels actors. Cada dia mes, la Web 2.0 s’apropa ala implantacio de la web semantica i la navegacio per etiquetes (tags).Poder obtenir un llistat de tags relacionats amb els actors amb el seugrau d’importancia i fortalesa dins de la xarxa social ens facilita lestecniques de clusteritzacio i de navegacio per la xarxa social.

• Un sistema de navegacio practic per poder estudiar la xarxa. La defi-nicio dels actors per tags ens permetra poder acotar la nostra xarxa ipoder trobar i navegar per ella amb molta mes facilitat.

• Millores en el cost d’extraccio de dades i en l’ambiguitat de resultats,aplicant algunes de les conclusions exposades en la Revista Redes (dela Rosa, 2007)

Capıtol 4

Estudi i disseny de la XarxaSocial

4.1 Introduccio

En aquest capıtol realitzarem l’estudi i el disseny de l’aplicacio que s’en-carregara d’extreure i manipular la xarxa social a partir de les dades d’In-ternet. Ens centrarem en estudiar els metodes que ens permetran realitzarles diverses fases del proces d’extraccio, avaluant les alternatives i decidintaquella que pugui funcionar millor en el nostre entorn.

El proces d’extraccio de la xarxa social consta de tres fases molt marcades:

1. Interrogacio al motor de cerca: com interaccionem amb el motor pertal d’obtenir els resultats i les dades que ens interessen.

2. Web Mining: per tal d’extreure les metadades dels nous actors de lanostra xarxa social i, per tant, poder construir-la.

3. Visualitzacio de les dades: com navegar per la xarxa social d’una ma-nera optima i clara amb la finalitat de poder trobar allo que estemcercant.

Seguidament ampliarem els punts esmentats per tal d’aprofundir en cadaun d’ells coneixent les seves problematiques i les solucions que proposa aquestProjecte Final de Carrera.

4.2 Interrogacio al motor de cerca

A l’hora d’interrogar el motor de cerca ens hem de plantejar diversosaspectes que son importants. En primer lloc hem de trobar la forma d’accedir

31

CAPITOL 4. ESTUDI I DISSENY DE LA XARXA SOCIAL 32

al motor per tal de poder interrogar-lo. Una vegada hem obert aquest canal,ja ens podem preocupar de quines son les preguntes que li realitzem. Es moltimportant que aquestes preguntes es formulin de la manera mes adient, jaque son les que marcaran l’origen dels nous actors de la xarxa.

Per aquest motiu, el punt crıtic dins d’aquest capıtol sera trobar quinesson les formules adients per interrogar el motor de cerca. Essent conscientsque tots els valors que ens retorni el cercador seran utilitzats per definir lesrelacions entre actors.

4.2.1 Accedint al motor de cerca

El primer pas que hem de realitzar es poder crear un canal de comuni-cacio amb el motor de cerca per tal de poder obtenir respostes a les nostrespreguntes. Ens interessa que per cada consulta que nosaltres realitzem l’a-plicacio ens retorni un llistat d’URLs que mes endavant seran analitzades pelmodul de Web Mining. A mes a mes, dades com el numero de resultats to-tals trobats per el cercador sera informacio que ens servira per poder calcularl’afinitat entre actors.

Figura 4.1: Dades interessants a recollir del motor de cerca

Fins ara no hem especificat quin motor de cerca utilitzar. Entre les op-cions existents: Yahoo, MSN Live i Google, hem avaluat els dos cercadorsamb mes forca en el mercat: Google i Yahoo. En principi ambdos cercadorsdisposaven d’un API per realitzar cerques al motor directament a un WebService que posaven a disposicio dels desenvolupadors.


L’API de Yahoo1 esta disponible i el seu funcionament es molt senzill.Es construeix la consulta i s’envia al web service especificant el numero deresultats que vols obtenir. La resposta es un XML amb les dades del tıtol,descripcio i url, juntament amb altres dades com tipus del fitxer de destı(text, PDF, imatge, etc.), dades de cache del cercador, etc.

En el cas de Google, la seva API2 per realitzar consultes al motor va deixarde ser publica el 5 de desembre de 2006. Malauradament aquest projecte esva comencar a principis del 2007 i no es va poder obtenir una key per utilitzaraquesta API.

Davant d’aquest inconvenient s’ha desenvolupat un sistema alternatiu al’API de Google que realitza una consulta al motor de cerca de Google i espareseja el resultat, obtenint les dades necessaries per a les nostres finalitats:llistat d’url’s i numero de matchings que s’han produıt.

Per decidir quin dels dos sistemes escollir en primer lloc s’ha avaluat eltemps de resposta en ambdos sistemes. El coll d’ampolla de la nostra aplica-cio sera el temps de carrega de les multiples pagines que haurem d’analitzarper realitzar el Web Mining. Per tant hem de minimitzar els temps de res-posta de tots aquells llocs que tinguem controlats i siguin constants, comles consultes al motor de cerca. En la taula 4.1 es pot veure els resultatsobtinguts en realitzar una prova de velocitat de resposta llencant la mateixaconsulta 100 vegades a l’API de Yahoo i a l’API dissenyada per nosaltres deGoogle.

Temps Mitja del temps d’una peticio

Yahoo 85.620 s 0.86 s

Google 43.480 s 0.43 s

Taula 4.1: Temps de resposta de l’API de Yahoo vs API Google

SonClarament es pot observar com els resultats que ofereix l’API de Go-ogle son molt superiors a la de Yahoo, trigant quasi la meitat de temps.Donades aquestes dades, podem recolzar l’opcio de Google, en que actual-ment es el motor de cerques mes utilitzat en el mon.

Per tant, concloent aquest punt ens decantem per l’API desenvolupadaper nosaltres de Google per la seva major velocitat de resposta davant unaconsulta. La nostra API ens retorna el llistat d’URLs relacionades amb lapeticio i el numero total de matchings que s’han realitzat.

1http://developer.yahoo.com/search/2http://code.google.com/apis/soapsearch/

http://developer.yahoo.com/search/

http://code.google.com/apis/soapsearch/


Per poder veure les diferencies de resultats entre les dues APIs es podraseleccionar des del formulari inicial de cerca quina API utilitzar per generarla xarxa social.

4.2.2 Com interrogar el motor de cerca

Una cop decidits els motors de cerca a utilitzar, ara ens centrem en cominterrogar el motor de cerca per tal d’obtenir la informacio el maxim de fiablepossible. El nostre objectiu es aconseguir una llista d’URLs que estiguinrelacionades amb l’actor a analitzar.

Partim doncs del nom i cognom de l’autor per tal d’extreure la sevaxarxa social. Per il·lustrar l’evolucio teorica de l’estudi, ens recolzarem enl’exemple de creacio de la xarxa social vinculada al professor “David Vernet”de la Universitat d’Enginyeria i Arquitectura La Salle. Per tant, utilitzantel seu nom i cognom en el motor de cerca i els resultats obtinguts son elsseguents:

Figura 4.2: Resultats del motor de cerca a “David Vernet”

Analitzem nomes els 5 primers resultats i ja podem veure el primer pro-blema entre ells. Si ens fixem en el 5e resultat, marcat amb un fletxa a lafigura 4.2, veiem que no es refereix al mateix “David Vernet” professor de lanostra Universitat. Casualment existeix un altre actor amb el mateix nom i


en aquest cas concret, analitzant la seva plana personal, tambe es dedica ala investigacio relacionada amb el seu Doctorat.

El problema de l’ambiguitat de noms es un dels mes complicats de solu-cionar. En els estudis comentats anteriorment, Polyphonet i Flink, es trobenamb aquest mateix problema e intenten resoldre l’ambiguitat amb diferentstecniques. En el cas de Polyphonet a la cerca base, es a dir el nom, s’afegei-xen aquelles paraules claus que puguin diferenciar un actor de un altre. En elnostre cas haurıem d’utilitzar el nom de la universitat per tal de poder definiral nostre actor, ja que amb paraules claus com Professor, Doctorat o deriva-des podrıem trobar tambe el resultat incorrecte per “David Vernet”. Aquestsistema ens lliga a coneixer l’entorn dels nostres actors i aixo ens impedeixpoder expandir la xarxa amb fiabilitat. Els actors inicials els podem arribara coneixer i podem acompanyar-los de paraules clau que els defineixin, peroels nous actors de la xarxa no tenen cap paraula clau que els defineixi.

Per tal de poder resoldre aquesta problematica, en el nostre cas utilitza-rem un altre identificador de l’actor: el seu e-mail. Utilitzant el seu correuelectronic ens assegurem que els resultats que obtenim del cercador son 100%relacionats amb aquesta persona. L’e-mail identifica unitariament a una per-sona i no existeix l’ambiguitat[3]. Veiem els resultats del cercador al fer lacerca amb l’email “[email protected]”


Figura 4.3: Resultats del motor de cerca a “[email protected]”

Amb aquests resultats podem observar com tots coincideixen amb el nos-tre actor a analitzar. La composicio de la consulta ignorant l’arroba es de-guda a la varietat de maneres d’escriure un email en les documentacionsacademiques, per exemple: {dave,xavic}@salleurl.edu. Precisament aquestamanera de construir la consulta de cerca provoca que en segons quins casosapareguin resultats no relacionats amb l’actor en questio. Si es dona el casque en una plana web apareix el nom de Dave i una adreca de la Universitatsalleurl.edu, aquesta plana fara maching amb la nostra consulta i el cercadorens la retornara.

Per tant, per reduir al maxim aquests casos intentarem cenyir-nos a aque-lla informacio que es realment rellevant per nosaltres. La informacio rellevant


dels investigadors de l’entorn universitari normalment la trobem en els seusarticles i publicacions. En ells podem trobar les arees tematiques que treba-llen, els seus avencos i tota la informacio important que els defineix. Aquestdocuments acostumen a publicar-se en el format PDF per la seva portabilitatmultiplataforma. Per tant, aprofitant els parametres dels cercadors filtraremper documents PDFs quedant aixı la nostra peticio: “dave” “salleurl.edu”filetype : pdf. Observem els resultats en aquest cas:

Figura 4.4: Resultats del motor de cerca a “dave” “salleurl.edu” filetype :pdf

Per tant la formula que utilitzarem per interrogar el cercador es la seguent:

identificador email + nom domini + filetype : pdf (4.1)

Com a informacio relacionada amb les dues APIs implementades, Yahoo


pot filtrar els resultats per tipus mitjancant el parametre format=pdf, i Go-ogle pot fer el mateix amb filetype:pdf dins de la cadena de cerca. Afegirtambe, que en el cas de Google es forca a treure tots els resultats de la cercaamb el parametre filter=0.

4.3 Web Mining. Extraccio de dades dels ac-

tors

Aquest es un dels punts mes importants del proces. Important perqueengloba molts aspectes que definiran els components finals de la xarxa social.Una vegada obtinguts la llista de URLs relacionades amb l’actor que estemanalitzant el seguent pas es extreure tota la informacio util d’aquesta llistad’URLs. Quan parlem d’informacio util ens referim a extreure possibles re-lacions de l’actor i la seva descripcio semantica per paraules clau (keywords).

El proces de mining consta de diverses parts:

1. Extraccio del contingut a partir d’una URL.

2. Extraccio de nous e-mails candidats a relacions de l’actor analitzat.

3. Normalitzacio del contingut en funcio del seu idioma.

4. Extraccio de paraules clau a partir del seu lexema.

5. Analisi dels vincles d’afinitat entre l’actor i els candidats a relacions,per tal de crear-les i descartar aquells que no en tenen.

6. Analisi de les relacions entre actors a partir de les seves paraules clau.

Com podem veure existeixen moltes fases i seguidament parlarem d’ellesfent una analisi del seu funcionament.

4.3.1 Expansio de la xarxa social

El primer objectiu que tenim es el de poder expandir la xarxa social apartir de l’actor que estem avaluant. Per tant ens interessa extreure totsaquells actors que estiguin relacionats amb aquest individu. Per fer-ho dis-posem de la llista de documents que ens ha retornat el cercador i que sabemque el nostre actor hi ha intervingut d’una manera o una altra.


Extraccio del contingut a partir d’una URL

A partir de la url extraiem el seu contingut. En el cas de Google ensfaciliten les coses ja que existeix el vincle a la informacio del PDF en formathtml (figura 4.5), molt mes facil de parsejar. En el cas de l’API de Yahoo hemde parsejar el document PDF amb les problematiques que aixo comporta.

Figura 4.5: Enllac al contingut del PDF en format HTML de Google

Un document pdf pot ser generat de moltes maneres diferents i el resultatde passar-lo a text mitjancant les eines existents no sempre es satisfactori. Enaquests casos, descartem aquests documents i continuem l’analisi de la restade documents. Al punt 5.4.4 s’explica amb detall quines eines s’utilitzen perconvertir el PDF a text pla.

Extraccio de candidats a relacions

Una vegada tenim el contingut del document en format text pla, podemrealitzar la primera mineria de dades extraient els e-mails que es nombrin aldocument. Partim de la seguent hipotesi:

Hipotesi 4.3.1 Tot correu electronic que aparegui en el contingut del docu-ment es converteix en candidat a relacio amb l’actor analitzat.

Per tant hem de fer una analisi previa de quina es la estructura d’une-mail i que ens podem trobar en el contingut d’un document. L’estandardd’un e-mail es clar: consta del seu identificador unic dins d’un domini unital domini on existeix per una arroba, per exemple: [email protected].

El problema apareix en les formes de representar els e-mails en els articlesi documents d’investigacio. Si nomes hi ha un sol el format es clar, pero siapareixen dos o mes podem veure un format similar a aquest: {xavic,dave}@salleurl.edu. Aixo ens fa estudiar els possibles formats de representacio del’e-mail i amb aixo extraiem els seguents patrons, que ens permeten reconeixerun percentatge molt elevat de correus electronics dels articles d’investigacio:

• Format estandard: identificador @ nom domini.


• Identificadors entre claus i separats per comes, @ nom domini.

• Identificadors entre parentesis i separats per comes, @ nom domini.

Juntament amb aquest proces d’extraccio es realitzen unes ponderacionssobre els e-mails extrets: ponderacio positiva per estar proper a l’e-mail del’actor a analitzar i penalitzacio als e-mails que pertanyen a documents ambuna gran densitat de correus electronics.

Hipotesi 4.3.2 Tot correu electronic que aparegui en la mateixa lınia quel’actor analitzat, considerarem que la seva relacio es mes forta o fins i totque son coautors.

Partint de la hipotesi 4.3.2 podem dir que si dos correus electronics estroben en la mateixa lınia, hi ha una probabilitat molt alta que els dos actorssiguin coautors del document, o tinguin un vincle elevat ja que es nombrenun despres de l’altre. Per tant, aquesta candidatura a relacio es marcadacom coautoria i sera utilitzada a l’hora de definir el vincle d’afinitat entre elsdos actors (punt 4.3.3).

Pero no sempre les coautories es col·loquen a la mateixa lınia. A vegadesels emails estan separats per salts de lınia. Aquesta situacio ens porta areflexionar en quina importancia tenen els e-mails que es troben propers al’actor a analitzar. Sembla que si nombrem diversos e-mails juntament ambel de l’actor analitzat, aquests individus poden tenir un vincle mes fort ambl’actor principal. Per tant aquests emails rebran un pes mes elevat que laresta i que afectara al calcul de l’afinitat.

Hipotesi 4.3.3 Els correus electronics que es trobin propers de l’e-mail del’actor a analitzar rebran mes pes que la resta. Quan ens referim a propersvolem dir 100 caracters abans i despres de l’e-mail de l’actor analitzat.

A l’hora de extreure els e-mails, no s’ha de perdre el context en el quefem l’extraccio, el document. Avaluem un cas trobat en l’estudi, que con-sisteix en un document PDF que llista tots els participants d’un congres3.En aquest cas s’estava avaluant l’actor [email protected] relacio directad’en [email protected]. En aquest document apareixen uns 500 correuselectronics, que amb el metode actual d’extraccio, es converteixen directa-ment en candidats a relacions. Clarament els 500 actors no tenen una afinitatamb l’actor a analitzar, per tant, podem donar menys pes a aquests e-mailsper tal de ser penalitzats a l’hora de calcular la seva afinitat amb l’actoranalitzat.

3http://w3.iec.csic.es/ursi/articulos_coruna_2003/autores/fichas_autores.pdf

http://w3.iec.csic.es/ursi/articulos_coruna_2003/autores/fichas_autores.pdf

http://w3.iec.csic.es/ursi/articulos_coruna_2003/autores/fichas_autores.pdf


Hipotesi 4.3.4 Tots els e-mails que pertanyen a un document amb una den-sitat d’e-mails superior a 20 son penalitzats i tenen menys pes a l’hora decalcular l’afinitat amb l’actor analitzat.

Amb aquests nous actors podrem expandir la xarxa cap al seguent nivell.Encara aixı, el proces que hem realitzat ens ha retornat una llista de candi-dats a relacio i decidirem si ho son o no, una vegada apliquem les formulesd’afinitat que es detallen al punt 4.3.3.

4.3.2 Extraccio de les descripcions semantiques

Una vegada ja hem extret els e-mails del contingut extraurem el conjuntde paraules clau que defineixin al document que estem analitzant.

En aquest apartat definirem les tecniques utilitzades per realitzar el TextMining de la nostra aplicacio. Ens basem en Processos de reconeixementdel Llenguatge Natural (NLP) aplicant diverses tecniques d’analisi de lesparaules per extreure la veritable informacio que conte el document.

Normalitzacio del contingut en funcio del seu idioma

El primer pas consisteix en realitzar un filtrat al document de totes aque-lles paraules, signes i caracters que no ens aporten cap informacio util alnostre estudi. Aquest pas es independent de l’idioma del contingut i es potdur a terme sense la seva analisi previa.

Comencant per normalitzar el contingut del document es realitzaran elsseguents canvis:

• S’eliminara tot tipus de tag html que hagi pogut arribar, per exemple,per causa de utilitzar l’opcio de Google “Versio en HTML”.

• Tot el contingut es convertira a minuscules.

• Els accents i signes ortografics son substituıts per les seves lletres cor-responents. Per exemple: a → a

• Els signes que no siguin alfanumerics son substituıts per espais en blanco eliminats, segons el cas, a excepcio del guio que uneix dues paraules.

Es molt important que el document quedi normalitzat per poder realitzarcorrectament tota la fase d’extraccio de paraules clau. El sistema podriacatalogar com a diferents paraules iguals pero amb diferencies de majusculeso minuscules, accents o simplement perque al final de la paraula l’acompanya


una coma o un punt. Aquestes situacions generen una gran quantitat de sorollen els nostres resultats i es aquest el motiu de la normalitzacio del contingut.

A mes dels casos explicats, existeixen altres tipus de paraules que tambeaporten soroll a l’hora de realitzar l’extraccio de les paraules clau. Aquestesparaules son totes aquelles que no aporten cap tipus d’informacio a un docu-ment pero que son necessaries per la correcta construccio sintactica d’aquest.Ens referim als articles, preposicions, etc. Aquestes paraules reben el nomde Stopwords4. L’eliminacio d’aquestes paraules produira que el contingutresultant sigui informacio util.

Per poder eliminar aquestes stopwords es important coneixer l’idiomaamb el que s’ha escrit el document. Podrıem perdre informacio rellevantsi eliminem paraules que coincideixen en la llista de stopwords d’un idiomadiferent a l’utilitzat en el document. Per tant abans d’aplicar la substituciohem de reconeixer l’idioma utilitzat.

Per fer-ho hem desenvolupat un sistema que es basa en les mateixesstopwords. Partim de la base que dins de la llista de les stopwords tro-bem aquelles paraules que son mes utilitzades en un idioma com per exempleels articles i les proposicions. Per tant si eliminem aquestes paraules delcontingut del document segurament obtindrem un numero elevat de canvis.Seguint aquesta argumentacio, si apliquessim una llista de stopwords d’unidioma diferent al del document el numero d’eliminacions de paraules serainferior al originat per la llista correcta.

Partint d’aquesta base podem deduir que a partir del numero de substi-tucions d’un document amb les diverses llistes de stopwords podem extreurel’idioma utilitzat al document.

numero_eliminacionsES = cleanStopwordsES( contingut );

numero_eliminacionsEN = cleanStopwordsEN( contingut );

if( numero_eliminacionsES > numero_eliminacionsEN )

return languageES;

else

return languageEN;

Com podem veure en el pseucodi en el cas de que el numero de substitu-cions fos igual entre el llenguatge espanyol i l’angles, decidirıem que l’idiomadel document es l’angles ja que existeix molta mes informacio en la xarxa

4Llistes de stopwords de la universitat de Neuchatel, generades a partir de l’estudi degramatiques i llenguatges del departament de computacio http://members.unine.ch/jacques.savoy/clef/index.html

http://members.unine.ch/jacques.savoy/clef/index.html

http://members.unine.ch/jacques.savoy/clef/index.html


en angles que en espanyol. Com es veu el funcionament es molt simple ipodrıem afegir tantes llistes de stopwords com es desitges. El problema esque, a mida que hi ha mes llistes, augmenta el temps de proces per decidirl’idioma del document.

En la seguent taula (4.2) podem veure els resultats d’un test sobre 81documents PDF per garantir el correcte funcionament de l’aplicacio:

Espanyol Angles Total

Documents 40 41 81

Encerts 37 (92%) 41 (100%) 78 (96%)

Taula 4.2: Resultats de l’analisi d’idioma de 100 documents PDF

Com podem veure en els resultats, un 96% d’encert es un valor optim ique ens garanteix un bon funcionament de l’aplicacio. A mes, analitzant elstres documents que fallen, es degut a un problema de codificacio erronea delconversor de PDF a text que del sistema de deteccio d’idioma.

Extraccio de paraules clau a partir del seu lexema

Arribat aquest punt on el contingut extret del document ha estat nor-malitzat degudament, es el moment d’extreure les paraules claus mes relle-vants de cadascun dels fitxers analitzats. D’aquesta manera podem anarrecol·lectant de tots els documents aquelles paraules que mes apareixen pertal de poder representar a un actor a partir d’elles.

Existeixen diversos metodes de Text Mining per dur a terme aquestesfuncions. Com no es l’objectiu d’aquest projecte aprofundir en aquestestecniques, s’ha implementat un metode propi d’extraccio de coneixementsobre el contingut que incorpora algunes de les caracterıstiques d’aquestsmetodes ja estudiats.

El nostre sistema de NLP-IR (Natural Language Process - InformationRecovery) consta de tres parts. La primera es la ja explicada al punt anteriordel filtrat per stopwords i sımbols no alfanumerics. En segon lloc, es trobal’algorisme d’extraccio de keywords per rellevancia que ens retorna un llistatde les paraules mes rellevants del document. I per ultim trobem el Stemmerque s’encarrega d’agrupar les paraules per la seva arrel o millor dit per elseu stem o tema. Seguidament comentem aquests dos ultims metodes ques’engloben dins de l’algorisme que em implementat anomenat RKAS.

L’algoritme d’extraccio de keywords per rellevancia amb stemming (RKAS )consisteix en un automat finit que s’encarrega d’analitzar el document des del’inici fins al final reconeixent les paraules i agrupant-les per ocurrencies. Per


reconeixer un token com a paraula valida ha de tenir una longitud mınimade 3 caracters. D’aquesta manera es reconeixen la majoria de paraules exis-tents. L’algorisme emmagatzema les paraules i va sumant les ocurrencies decadascuna d’elles fins a obtenir el llistat final.

El seguent pas de l’algoritme RKAS consisteix en filtrar aquestes keywordsobtingudes mitjancant l’algorisme de Stemming.

De forma molt senzilla, podem definir la lematitatzio o stemming com elproces de representar mitjancant un unic terme (el lema o stem) totes lespossiblitats flexives d’una paraula.[11] Des del punt de vista linguıstic, unlema es un terme que representa i unifica tots els elements d’un conjunt deparaules morfologicament similars[2]. De forma similar, el stemming redueixun conjutn de paraules al seu stem o arrel comu. Aixı, biblioteca, bibliotecari,bibliotecaria comparteixen la mateixa arrel que es “bibliotec”.

Es possible realitzar el stemming mitjancant un algorisme que utilitziregles gramaticals de derivacio morfologica per l’idioma en questio, o usantun diccionari informatitzat que associı a cada forma el seu lema (paraula)representant. Dins d’aquests ultims, MACO es el lematitzador de referenciaper l’espanyol.

Una diferencia important entre aquestes dues aproximacions es la dificul-tat d’elaboracio, ja que en el cas de la creacio d’un diccionari es necessariun gran esforc de recopilacio per introduir cada paraula i la seva arrel deforma manual (o semiautomatica), la tecnica basada en un algorisme permetrealitzar el stemming declarant simplement una serie de regles linguıstiques.

Els resultats de les dues tecniques son similars dins d’un marge d’error ra-onable. El principal problema dels diccionaris informatitzats es l’ambiguitatsemantica, que nomes pot ser evitada realitzant una analisi sintactica i/osemantica de cada entrada, L’aproximacio basada en regles presenta, a mesde l’inevitable ambiguitat semantica, dos problemes basics: el overstemming(reduir massa, representant amb un mateix stem formes que haurien de serrepresentades amb diversos) i el understemming (reduir poc, al obtenir stemsdiferents per formes que es corresponien unicament amb un).

Un dels primers algorismes de stemming, desenvolupat per l’angles en1980, es deu a Martin Porter[13, 12], pel que es coneix com “Algorisme dePorter”. Aquest actua com un automat d’estats finits que inclou un grupde regles que s’apliquen per eliminar terminacions morfologiques i flexivesde paraules en angles. La seva idea basica era la reduccio del plural alsingular per normalitzar els termes, pel que basicament eliminava les “s”finals. Evidentment, aixo no es suficient quan parlem de llengues romaniques,amb majors variacions morfologiques i flexives. Per aquest motiu han anatapareixent adaptacions de l’algorisme de Porter per altres llengues.

En el nostre sistema contemplem els documents que estan en angles i


espanyol, tal i com hem comentat anteriorment. Per tant hem implementatels dos algorismes de stemming a partir del de Porter. Per tal d’implementar-lo Porter va dissenyar Snowball que es un petit llenguatge de programacioper la manipulacio de strings que permet implementar facilment algorismesde stemming.

Aquest algorisme ens soluciona molts problemes de soroll entre les pa-raules seleccionades, ja que eliminem problemes entre singulars i plurals,masculins i femenins i paraules similars com en el cas de biblioteca i bibliote-cari. D’aquesta manera, la llista de paraules les agrupem per stem i sumemles ocurrencies de totes aquelles que coincideixin amb l’arrel.

4.3.3 Creant relacions d’afinitat entre actors

Una vegada ja hem finalitzat el proces d’extraccio de dades del continguti hem definit els candidats a relacions amb l’actor analitzat, hem de definir sirealment existeix relacio o no. El tipus de relacio que definim en aquest cases la relacio de connexio academica o personal entre actors. Els documentsens han donat un llistat d’actors que poden estar relacionats entre ells i elsdocuments estan relacionats amb el treball/investigacio d’aquell actor. Pertant els vincles poden ser de coautoria, de treballar en el mateix departament,treballar en la mateixa area o que assisteixen als mateixos congressos.

Per trobar aquest parametre que ens quantifiqui el nivell d’afinitat entredos actors utilitzarem les tecniques proposades en Polyphonet[14] i Flink[10],que consisteix en interrogar el motor de cerca emprat per extreure els do-cuments relacionats amb l’autor, per veure quants resultats retorna la uniodels dos autors i la relacio individualment.

Existeixen diverses coeficients per aplicar en aquests calculs[9]: el de Jac-card emprat per Flink i Referral Web[5], Overlap Coefficient utilitzat perPolyphonet[15], matching coefficient, mutual information, Dice coefficient iel cosinus entre altres.

En aquest Projecte Final de Carrera seran implementats diversos d’a-quests coeficients per tal de mesurar l’afinitat, i aixı veure com varia la xarxasocial en funcio d’aquests parametres.

El proces es sempre el mateix: en analitzar un actor s’extreuen els candi-dats a relacio i un a un es calcula l’afinitat amb el actor “pare”. Una vegadaes retorna el coeficient d’afinitat, si es troba per sobre d’un llindar k decidimque existeix un vincle entre els dos actors, sino es descarta.

A vegades la relacio entre dos actors ha estat puntual i els resultats del co-eficient d’afinitat poden comunicar-nos que no existeix relacio entre aquestespersones. Aquesta dada seria incorrecta ja que poden haver estat coautorsd’un article. Per aquest motiu en extreure els correus electronics es marca la


relacio de coautoria en cas de trobar-se els dos e-mails en la mateixa lınia.En cas de ser aixı, per molt que el coeficient d’afinitat sigui inferior al llindark establert la relacio no es descarta.

Seguidament es descriuen les formules dels coeficients implementats.

Nomenclatura

Abans d’explicar les formules dels diferents coeficients implementats, es-pecificarem la nomenclatura que se seguira i que es valida per tot el docu-ment.

Per representar el numero total de resultats que produeix el motor decerca per l’actor X i Y usarem nX i nY respectivament.

Per representar el numero total de resultats generats per la consulta ac-tor(X) AND actor(Y) usarem nX∩Y .

Per representar el numero total de resultats generats per la consulta ac-tor(X) OR actor(Y) usarem nX∪Y .

Coeficient de Jaccard

El coeficient de Jaccard consisteix en relacionar el numero de resultatsproduıts per la consulta de l’actor X i l’actor Y conjuntament, entre elsdocuments on apareixen l’actor X o l’Y.

El coeficient de Jaccard es defineix de la seguent manera:

afinitat =nX∩Y

nX∪Y

(4.2)

Podem veure que si els documents retornats per els dos actors junts son elmateix numero que els elaborats per cada un d’ells individualment, la relacioentre ambdos es maxima. En canvi, aquest coeficient ens pot donar una visioequivocada si l’actor X te molts documents associats i Y pocs, pero aquestspocs son tots relacionats amb X. En aquest cas existeix afinitat entre els dos,pero el coeficient seria baix.

Overlap Coefficient

El coeficient d’overlap consisteix en relacionar el numero de resultatsproduıts per la consulta de l’actor X i l’actor Y conjuntament, entre el mınimdels resultats produıts per l’actor X i l’actor Y.

L’Overlap Coefficient es defineix de la seguent manera:

afinitat =nX∩Y

min(nX , nY )(4.3)


Per tant amb aquest coeficient afinem el problema comentat en el coefi-cient de Jaccard, ja que si un actor te pocs documents, pero en tots ells es fareferencia a l’altre actor, com dividim per el menor dels resultats de l’actorX i Y individualment, l’afinitat seria maxima.

Coeficient del Cosinus

Per ultim el coeficient del cosinus relaciona el numero de resultats produıtsper la consulta de l’actor X i l’actor Y conjuntament, entre l’arrel quadradade la multiplicacio del numero de documents retornat per X per el numerode documents retornats per Y.

El coeficient del Cosinus es defineix de la seguent manera:

afinitat =nX∩Y√nXnY

(4.4)

Amb aquesta alternativa es vol millorar tambe el problema presentat alcoeficient de Jaccard, ja que dividim per l’arrel quadrada de la multiplicaciodels resultats. Aixı aconseguim reduir el numero obtingut per nX∪Y i donemimportancia al calcul de l’afinitat que un actor hagi col·laborat amb moltsmes actors que Y per reduir l’afinitat.

Imaginem que un actor X nomes te un document en comu amb l’actorY, i aquest te 100 documents en total. Amb el coeficient d’overlap l’afinitatseria 1 (maxima), i amb aquest ens diria que l’afinitat seria d’un 0,1.

4.3.4 Creant relacions semantiques entre actors

Una altre tipus d’afinitat entre actors es aquella que podem obtenir apartir de les descripcions semantiques que hem extret de cada un dels in-dividus que formen la xarxa social. Mes enlla de si han treballat junts osi es coneixen, dos actors de la mateixa xarxa social poden estar treballanten les mateixes arees i no tenir cap vincle de relacio directa. Aquests casosconsiderem que son relacions indirectes entre actors pero que tenen una granrellevancia dins de la xarxa social.

Si estem investigant sobre una tematica en concret ens podra ajudar moltpoder navegar per la xarxa a partir de les relacions extretes de les descripcionssemantiques de cada actor, aportant una analisi addicional a l’extreta delsvincles d’afinitat.

Per dur a terme aquest calcul partim de la base de la llista de keywordsobtingudes per cada actor. Aquesta llista ens aporta diferents dades que enspermetran calcular l’afinitat:


• Paraula: es la keyword que apareix als documents de l’actor i que haestat seleccionada entre les mes rellevants (amb mes ocurrencies) dinsdel total de paraules extretes.

• Stem: es el lexema de la paraula i a partir del qual s’ha realitzat l’agru-pacio (cluster) en el proces de extraccio de les descripcions semantiques.

• Ocurrencies: Ens aporta el numero total d’ocurrencies d’aquesta pa-raula dins del conjunt de documents de l’actor.

Amb aquestes dades podem plantejar una formula per calcular l’afinitatentre dos actors, partint de la base que sabem que el numero de paraulesclau de cada actor es igual. Primer de tot definirem el conjunt de keywordsper cada actor.

LX = {stem0, stem1, ..., stemn} (4.5)

LY = {stem0, stem1, ..., stemn} (4.6)

(4.7)

I aquesta es la formula de l’afinitat.

afinitat =

n∑i=1

∃{LXi, LY }

n(4.8)

Amb aquesta formula podrem calcular l’afinitat entre dos actors d’unamanera basica. Ja que ens calcula que per tots els stems de la llista dekeywords de l’actor X si existeix en la llista de keywords de l’actor Y, ifinalment els divideix per el numero de keywords. L’expressio ∃{LXi

, LY } ensretorna 1 si es compleix, altrament 0. Per exemple, si dos actors coincideixenen 5 de 10 keywords, tenen una afinitat del 0,5.

Pero amb aquesta formula no tenim en compte el numero d’ocurrencies enles que apareix aquesta keyword. Ens podem plantejar la pregunta: Te la ma-teixa importancia que coincideixin dues paraules si una te moltes ocurrenciesi l’altra poques? Sembla que no ha de ser aixı, ja que el numero d’ocurrenciesens indica el pes d’aquesta keyword dins de la seva descripcio semantica.

Per tant modifiquem la formula 4.8 per tal d’afegir aquest cas comentat.

afinitat =

n∑i=1

∃{LXi, LY }

occurrencies(LXi)

max(occurrencies(LXi), occurrencies(LYj

))

n(4.9)


On occurrencies(LYj) correspon al numero de ocurrencies de la keyword

de l’actor Y que s’avalua amb la keyword de l’actor X: LXi. Aixı doncs si

les keywords tenen un numero d’ocurrencies molt diferent es veura afectadala nostra formula disminuint l’afinitat entre els dos actors. Seguint ambl’exemple anterior, si de les 5 keywords coincidents assignem els seguentspesos:

afinitat =(50/100) + (80/90) + (10/200) + (33/47) + (6/35)

10= 0.23

(4.10)Veiem com l’afinitat s’ha reduıt del 0.5 al 0.23 degut a la ponderacio de

las keywords per les seves ocurrencies.Dins d’aquest calcul podem afegir un nou factor de ponderacio. Per ara

ens hem fixat en les keywords de l’entorn dels dos actors. Pero per donar meso menys pes a una keyword s’hauria de comparar aquesta en la totalitat deparaules clau de la xarxa. Es a dir, si una paraula es molt comu en la totalitatde la xarxa, vol dir que la majoria dels actors treballen en aquest ambits i pertant es normal que apareguin aquestes paraules en els seus documents. Aixıdoncs, si aquestes paraules son comunes entre tots els actors, seguramentno ens aporten coneixement sobre l’afinitat entre ells. Per exemple, si totsels actors parlen de “Web Mining” no te sentit que existeixi una relaciosemantica entre ells perque tots parlen del mateix.

La nostra analisi de relacions hauria de donar mes rellevancia a aquelleskeywords que es repeteixen entre actors, pero que son molt caracterıstiquesentre ells donant-li un vincle especial entre aquests. Per tant podem modificarla formula 4.9 per tal d’obtenir aquest objectiu:

afinitat =

n∑i=1

∃{LXi, LY }

occ(LXi)

max(occ(LXi), occ(LYj

))

max(occ(LXi), occ(LYj

))

occurrenciesGlobals(LXi)

n(4.11)

Simplificant max(occ(LXi), occ(LYj

)):

afinitat =

n∑i=1

∃{LXi, LY }

occurrencies(LXi)

occurrenciesGlobals(LXi)

n(4.12)

Aixı doncs, retornant a l’exemple que hem fet servir en aquest punt, siresulta que les 5 paraules que coincideixen entre els dos actors, 4 d’elles sonmolt usades en el global de la xarxa social, passa el seguent:


afinitat =(50/1000) + (80/300) + (10/200) + (33/47) + (6/150)

10= 0.11

(4.13)L’afinitat entre els dos actors ha disminuıt a 0.11. Aixı doncs hem passat

s’una afinitat del 50% a una de l’11%, a l’aplicar els nous factors de correcciode l’afinitat entre actors per les seves descripcions semantiques.

S’ha de dir que aquesta formula 4.12 ha estat en constant evolucio en eldesenvolupant d’aquest Projecte Final de Carrera. Aquesta evolucio es laque ens ha permes trobar punts de millora per tal d’afinar aquest valor.

4.4 Disseny del navegador de la xarxa social

Executades les fases d’interrogacio al motor de cerca i del Web Mining,arribem a l’ultima fase del proces: la visualitzacio dels resultats. En aquestProjecte Final de Carrera volem tractar el tema de la visualitzacio de resul-tats des del punt de vista de l’usuari, generant una aplicacio que sigui usablei que permeti poder navegar per la informacio amb facilitat.

Aquest es un punt difıcil degut a la quantitat d’actors que acostuma atenir una xarxa social. Mostrar el graf en la seva totalitat es moltes vegadesimpossible d’interpretar degut a la gran quantitat d’actors i enllacos quepoden arribar a existir.

Per tant, la solucio que proposem intentara aportar les eines suficientsper poder navegar per la xarxa social de la manera mes optima. Per fer-hocrearem tres eines que es mostraran en la interfıcie web:

1. Visualitzador del graf d’un actor: visualitzara els contactes i les relaci-ons d’un actor. En fer click sobre una de les seves relacions, aquest esconvertira en l’actor principal i es mostraran les seves relacions.

2. Nuvol de tags: es mostraran en forma de nuvol les keywords mes relle-vants de tota la xarxa social. Ens permetra filtrar per aquestes paraulesi mostrar nomes aquells actors que fan matching amb ella.

3. Panell de navegacio: per ultim es mostrara un panell de navegacio queens permetra tornar als nodes origen de la xarxa per comencar de noula navegacio per ella. Tambe podrem veure els actors existents en elnivell de l’actor que estem visualitzant.


4.4.1 Visualitzador del graf

La millor forma de representar un graf es de forma visual. D’aquestaexperiencia neix la idea de representar el graf visualment dins de la paginade resultats. Pero la representacio d’un graf quan la seva magnitud es moltgran no serveix de res a l’usuari.

Donat aquest problema ens plantegem quina es la millor manera de re-presentar visualment la xarxa. Les cerques comencen sempre d’un primernode o conjunt de nodes que son l’origen del nostre proces d’extraccio denous actors. Podem suposar que l’usuari voldra coneixer la xarxa social quecreix a partir d’aquests actors i veure quins son els seus vincles i cap a onevolucionen.

Per tant ens centrem en l’actor com element important dins de la xarxa.En cada moment ens interessa veure amb tota la claredat possible la infor-macio relacionada amb l’actor que hem seleccionat. La totalitat de la xarxaes interessant pero poc practica a l’hora de poder navegar per ella.

Aixı doncs en l’eina grafica visualitzarem l’actor que estem interessatsanalitzar (figura 4.6). En ella ens interessa veure l’actor com a centre de laxarxa, les seves relacions i la una petita fitxa descriptiva on es mostra el nomdel node i la seva llista de keywords.

Figura 4.6: Representacio visual de la xarxa de l’actor [email protected]


Per realitzar aquesta feina ens hem basat en el treball de Moritz Stefa-ner5, estudiant del master “Student at the Interface Design Program at FHPotsdam”6. La seva aplicacio feta en flash, i que explicarem com funcionaen el punt 5.4.7, ens aporta altres funcionalitats com un llistat de tots elsactors de la xarxa i la opcio de desfer i refer les nostres accions. Ho podemveure en la figura 4.7.

Figura 4.7: Barra de navegacio del visualitzador d’actors

Per altra banda ens trobem amb el problema dels actors que tenen un grannumero de relacions. En aquests casos la visualitzacio es molt complicada idegut al gran numero d’individus a mostrar en el navegador. Aquests casosens fan veure la impossibilitat de mostrar tota la xarxa en un requadre. Peraquests casos farem servir el panell de navegacio que explicarem al punt 4.4.3.

5http://www.der-mo.net/relationBrowser/index.html6http://design.fh-potsdam.de/studiengaenge/interfacedesign.html

http://www.der-mo.net/relationBrowser/index.html

http://design.fh-potsdam.de/studiengaenge/interfacedesign.html


Figura 4.8: Problemes quan existeixen moltes relacions

4.4.2 Nuvol de tags

Un nuvol de tags (tag cloud en angles) es una representacio visual deles “etiquetes” o paraules clau usades en un lloc web. Generalment aquestllistat de paraules s’ordena alfabeticament i les etiquetes mes usades es re-presenten amb un tipus de lletra de mida mes gran que la resta[4]. Quanse selecciona una etiqueta del nuvol, normalment es mostra una col·lecciod’items relacionats amb aquella etiqueta.

Existeixen tres tipus diferents de nuvols de tags en aplicacions socials.


1. En el primer tipus la mida d’una etiqueta representa el numero devegades que ha estat utilitzat aquest terme per definir un item. Aquestes util per mostrar metadades que agrupen conceptes[1].

2. En segon lloc, i el mes utilitzat, es aquell en que la mida del tag re-presenta el numero de vegades que apareix aquest tag en el contingutanalitzat. Aixı es pot veure facilment les keywords mes rellevants.

3. Per ultim, s’utilitza quan el tag defineix una categoria i la seva midaesta relacionat amb el numero de continguts que te la categoria.

Els tags poden representar-se en ordre alfabetic, en ordre aleatori, orde-nats per ocurrencies o altres tecniques d’ordenacio. La idea es facilitar al’usuari la visualitzacio de la informacio mes rellevant.

En el nostre cas utilitzarem el segon tipus de nuvols de tags. El nostreobjectiu es mostrar les paraules claus extretes dels actors donant mes emfasia aquelles que tenen mes rellevancia i menys a les altres. Amb un cop d’ulles podra veire quines son aquelles paraules que mes s’utilitzen i fer-se unaidea de que parlen els actors extrets en aquesta xarxa.

Veiem un exemple de nuvol de tags a la figura 4.9 on es mostren lesparaules mes repetides que apareixen a la plana web de publicacions de XaviCanaleta7.

Figura 4.9: Exemple de nuvol de tags

7http://www.salle.url.edu/~xavic/papers.htm

http://www.salle.url.edu/~xavic/papers.htm


Pero el nuvol de tags no nomes serveix per poder veure la informaciorellevant facilment, sino que ens servira per filtrar la nostra xarxa social perparaules clau. L’usuari tindra l’oportunitat de seleccionar les paraules clausque s’ajustin amb la seva area d’investigacio, per aplicar un filtre sobre laxarxa social resultant. De tal manera que nomes apareixeran aquells actorsque coincideixin amb les keywords seleccionades.

El nuvol de tags estara composat per les paraules claus extretes delsactors. S’agruparan per lexema, utilitzant les tecniques de stemming co-mentades anteriorment per reduir el soroll en els resultats i s’ordenara al-fabeticament augmentant l’impacte visual de les paraules mes rellevants enel nuvol de tags, igual que en la figura 4.9.

Tal i com hem comentat, el nuvol de tags mostrara les keywords mesrellevants de la totalitat de la xarxa social. Pero un altra funcionalitat in-teressant es mostrar el nuvol de tags relacionat amb l’autor que estem visu-alitzant. Aquest nuvol englobaria les keywords de l’actor analitzat i de lesseves relacions. Pot ser interessant poder veure un nuvol mes acotat dins dela gran xarxa. Gracies a aquesta funcionalitat en tot moment podem alternarentre el nuvol de tags local i el global de la xarxa social.

4.4.3 Panell de navegacio

Per ultim parlem del panell de navegacio. Aquesta funcionalitat ha deser capac de satisfer les mancances de les altres eines i cobrir tot allo queno podem assolir amb elles. A mes, aquest panell ens pot permetre afegirnoves dades que completin tota la informacio que ja hem explicat en els puntsanteriors.

El primer tema que vol abordar aquest panell de control es facilitar al’usuari tornar a l’estat inicial de la xarxa. Es a dir, una vegada naveguesper la xarxa es perden de vista els nodes inicials d’investigacio. Facilmentamb un boto podem recuperar els nodes inicials per tornar a navegar per ellsdes de l’inici.

Per altra banda i per solucionar el problema d’un actor amb moltes re-lacions, apareixera una llista en format text de totes les relacions d’aquestactor, enllacant a la seva fitxa personal. D’aquesta manera es podran veuretots els actors existents per aquell individu amb una densitat de relacionsmolt elevada.

Una altra funcionalitat consistira en veure les estadıstiques i debug delproces d’extraccio de dades. En aquesta seccio podrem veure els temps queha trigat en executar l’algoritme complert, quants documents pdf s’han ana-litzat, el numero d’actors candidats que s’han extret, el numero d’actors finalde la xarxa social. Aquestes dades ens permetran veure diferencies entre els


diferents modes de cerca (usant l’API de Yahoo o de Google), entre les dife-rents formules de calcul d’afinitat, etc.

4.5 Problemes observats i solucions

La intencio d’aquest punt es comentar alguns dels problemes trobats ique no s’han explicat en els punts anteriors. A mida que l’estudi i el desen-volupament de l’aplicacio ha anat evolucionant s’han detectat detalls que espoden considerar puntuals pero que conve documentar.

Com ja s’ha vist, un dels punts mes delicats de tot el proces es el del WebMining. L’analisi de documents PDF no es trivial i s’ha de realitzar a partird’un executable extern a l’aplicacio. La diversitat de formes de generar unPDF es molt gran i aixo porta a que no es compleixi un estandard i pertant que a vegades el proces de transformacio a text sigui incorrecte. Enel cas concret dels fitxers generats amb Latex, els accents es descodifiquenincorrectament produint paraules d’aquest tipus: “proc´es”. Aquest cas s’hatractat en especial per la gran quantitat de documents generats en Latex.

Per altra banda i continuant amb els PDFs, un altre problema que enshem trobat esta relacionat amb les pagines web que per obtenir el PDFs’ha de pagar. Aquestes pagines com springerlink8 o ieeexplore9 son gransrepositoris d’articles i papers que per obtenir-los s’ha de pagar una quota opagar per descarrega.

El problema apareix, quan en fer la peticio al motor de cerca (tant Yahoocom Google) especificant que nomes es volen fitxers PDF i ens retornenenllacos a aquestes pagines. Aparentment els links semblen PDFs pero enrealitat et redirigeixen a una plana HTML. Per exemple:

http://www.springerlink.com/index/J3WGGJWY6JMDF89L.pdf

Aixo provoca que el sistema falli i que d’aquest document no s’extreguicap nou actor, ja que espera trobar un pdf i es troba un HTML. En ca-sos d’haver-hi molts resultats pot arribar a ser menyspreable perdre un dels10 resultats retornats pel cercador, pero si tots els documents pertanyen aaquestes pagines no podrıem extreure cap nou actor, quan en realitat hi hamaterial per analitzar.

La solucio que s’ha plantejat per aquestos casos s’aplica en general alproces. Els motors de cerca quan ens retornen els resultats sempre adjuntenuna petita descripcio dels documents seleccionats. En aquestes descripcionsacostumen a apareixer les paraules properes al terme cercat. Per tan podem

8www.springerlink.com9ieeexplore.ieee.org

http://www.springerlink.com/index/J3WGGJWY6JMDF89L.pdf

www.springerlink.com

ieeexplore.ieee.org


analitzar la plana web de resultats per extreure els primers emails i candidatsa relacions.

Veiem un exemple per explicar la situacio. En el cas de la cerca per“augc” “salleurl.edu” filetype:pdf Veiem a la imatge 4.10 que tres dels cincresultats retornats pertanyen a aquestes webs:

Figura 4.10: Exemple de webs de pagament per PDFs

Pero tambe podem veure que en la mateixa plana de resultats, en lesdescripcions dels resultats, apareixen els e-mails dels coautors dels docu-ments. Aixo ens permetra poder recuperar-los i expandir la xarxa a par-tir d’ells. Si no fessim aquest proces, perdrıem els seguents actors: miq-be,fbabot,augc,[email protected] que nomes apareixen en els documents


emmagatzemats en les webs de pagament.Clarament aquest sistema no ens aporta tota la potencia que te l’analisi

dels documents retornats pel cercador, pero ens poden ajudar a recuperaralguns actors que d’altra manera perdrıem.

Un altre problema observat esta relacionat amb les consultes al cercador.El fet de realitzar una consulta separant l’identificador de l’e-mail amb elseu domini, pot provocar resultats erronis. Veiem un exemple amb la cerca“dave” “salleurl.edu” filetype:pdf en la imatge 4.11

Figura 4.11: Resultats no rellevants en els resultats de Google

El cercador ens ha retornat dins del 10 primers resultats aquest documentque fa matching amb els tres parametres que hem demanat a la cerca dave,salleurl.edu i es un fitxer PDF. Pero no s’esta referint en cap moment [email protected] que es l’actor que cerquem. Aquest problema ens afecta enles descripcions semantiques de l’actor, ja que les paraules extretes d’aquestPDF no estan vinculades amb aquest actor. I per altra banda falseja elnumero de resultats que obtenim per aquest actor.

La solucio per les paraules clau es senzilla. En el moment d’analitzar elsemails candidats a relacions, si en cap lloc del document apareix l’email del’actor a analitzar aquest document es descarta i es deixa d’analitzar. Elproblema del numero de resultats retornats pel cercador no es pot solucio-nar. Com a molt podem restar aquells documents que analitzem que sonincorrectes del total, pero nomes estudiem els 10 primers resultats, la restano. S’ha mirat de perfeccionar la consulta al cercador pero no ens ofereixeneines suficients per poder afinar mes la cerca.

Capıtol 5

Implementacio de la XarxaSocial

5.1 Introduccio

En aquest capıtol abordarem la implementacio de l’aplicacio d’aquestProjecte Final de Carrera tant des del punt de vista del software, com delsistema. Per al correcte funcionament de l’aplicacio s’han estudiat tots elspunts crıtics que poden afectar al rendiment d’aquesta i s’ha intentat opti-mitzar al maxim per garantir el bon funcionament de l’aplicatiu.

Veurem amb detall com ha estat configurat el servidor on correra l’apli-cacio. Totes les aplicacions que donaran suport al codi per millorar la sevaeficiencia i el perque de la seva importancia.

Tambe veurem com s’ha implementat el codi, seguint el model Vista -Controlador, separant la capa de dades, la logica de negoci i la interfıcie del’usuari. Tambe s’explicaran les decisions que s’han pres per tal d’optimitzarel codi i millorar el temps d’execucio del sistema.

Com es podra veure el temps d’execucio del sistema es un punt molt crıtic.El fet que s’hagin de fer peticions web contınues per obtenir els resultats delcercador i els documents PDFs a analitzar, relentitza molt tot el proces. Ames, si els documents ha analitzar son molt grans i amb molt contingut, elparsejat tambe es mes costos. Per tant, el nostre coll d’ampolla es troba enles peticions web que es realitzen per poder expandir la xarxa social.

5.2 Plataforma tecnologica

En primer lloc parlarem de la plataforma tecnologica on s’executara lanostra aplicacio. Es molt important coneixer quin es l’entorn d’execucio i

59

CAPITOL 5. IMPLEMENTACIO DE LA XARXA SOCIAL 60

quins avantatges ens presenta. Parlarem de dos punts importants: el llen-guatge de programacio i el servidor web.

5.2.1 El llengutage de programacio

Quan pensem en entorns web tendim a pensar en llenguatges de progra-macio que ens aportin eines adients per poder desenvolupar una aplicaciofacilment. En el nostre cas ens trobem en una situacio diferent al cas tıpicd’una aplicacio web convencional.

L’aplicacio requereix un gran treball de proces, ja que a mes de les petici-ons de documents a la xarxa, s’han de processar estructures de dades pesadesi que requereixen una bona resposta de proces del software. Per tant podrıemoptar per un llenguatge de programacio compilat com C o C++ per dur aterme aquestes tasques.

Pero la necessitat de programar orientat al 100% cap al web, amb fun-cions que ens permetesin interactuar tant amb el sistema operatiu, com ambInternet, com amb una base de dades i que al final mostri un resultat enHTML. Aquestes raons en fan descartar un llenguatge que no estigui enfocatal web i per tan dos llenguatges compilats esmentats.

Un altra premissa que s’ha marcat aquest projecte es desenvolupar elcodi en un llenguatge que no sigui propietari, que sigui codi obert i que enspermeti modificar el seu core per tal d’adaptar-lo a les nostres necessitats. Ames de potenciar l’us de software lliure que ens aporta avantatges com granscomunitats d’usuaris i de documentacio que et poden ajudar.

Partint d’aquestes premisses es van avaluar els seguents llenguatges: PHP,Python i Java Servlets. Un dels fets que tambe es de destacar dels tresllenguatges nombrats es que son independents de la plataforma d’execucioaixı que son altament portables, degut a que son llenguatges precompilats.

En el cas dels Java Servlets va penalitzar la seva candidatura el fet d’haverd’instal·lar un servidor web Tomcat, amb tots els problemes de configuracioque suposa el mantenir una plataforma Java. A mes, la complexitat a ni-vell de classes per realitzar una operacio vam estimar que penalitzaria elrendiment de l’aplicacio.

Per altra banda entre PHP i Python ambdos son grans candidats perimplementar l’aplicacio. Tenen caracterıstiques molt similars pero es dife-rencien en que PHP esta mes orientat al mon Web i Pyton mes orientat ales aplicacions de proposit general.

Aixı doncs, el llenguatge de programacio escollit sera PHP, tambe perla coneixenca del llenguatge a fons i els moduls que poden suplir les sevesmancances.


5.2.2 El servidor

Actualment ens plantegem dues opcions en l’ambit dels servidors web:un sistema Windows o Linux. Els dos sistemes operatius competeixen entreells, pero en el mon “real”, les grans aplicacions s’executen sobre Linux.

En el nostre cas es van avaluar les dues opcions. La portabilitat de PHPens va permetre poder desenvolupar l’aplicacio en els dos sistemes opera-tius. La implementacio va comencar en Windows pel fet de dispossar d’unaplataforma Apache i l’interpret PHP. Pero a mida que va creixer el sistemai les optimitzacions eren necessaries a nivell de maquina, Windows no ensva donar la oportunitat de configurar-lo amb el detall i la potencia que ensaporta Linux.

Aixı doncs es va portar el codi de Windows a Linux per continuar desen-volupant en el nou entorn. Com comentavem, en ser multiplataforma, lamigracio no va generar cap tipus de problema.

El servidor Linux es una distribucio Ubuntu 7.04 amb kernel 2.6.20. Esva escollir Ubuntu perque era la distribucio que millor funcionava sobre lamaquina que actuara com a servidor: Acer TravelMate 3002 amb 60GB dedisc dur i 1GB de RAM. Aquest servidor sera dedicat i unic per l’aplicacio,per tant tots els recursos estan destinats a l’execucio de l’aplicacio.

El sistema esta configurat perque funcioni amb el servidor Web Apache 2(versio 2.2.3-3.2)1, php 5.2.12 com a modul de l’apache i com a interpret delınia de comandes (CLI), un servidor memcached3 versio 1.1.12 juntamentamb les llibreries per integrar-lo amb PHP i l’accelerador de PHP APC4

versio 3.0.14. Totes aquestes eines instal·lades al servidor estan explicadesamb detall al punt 5.5.

5.3 Modularitzacio del sistema

En aquesta seccio veurem com s’han implementat els moduls del sistemaencarregats de dur a terme tot el proces de l’extraccio de la xarxa social.S’ha intentat realitzar un disseny modular on cada element actuı indepen-dentment als demes i puguin ser intercanviables de tal manera que es puguindesenvolupar en equip qualsevol tipus de millora del sistema.

1http://www.apache.org/2http://www.php.net3http://www.danga.com/memcached/4http://pecl.php.net/package/APC

http://www.apache.org/

http://www.php.net

http://www.danga.com/memcached/

http://pecl.php.net/package/APC


5.3.1 Diagrama de moduls

El sistema s’ha modulat separant aquelles capes mes importants i inde-pendents les unes de les altres. Aixı doncs apareixen 4 moduls importatsdins del desenvolupament:

1. Social Networking: que s’encarrega de gestionar les dades obtingudesdel proces de Crawlin i la mineria de dades, per tal de construir laxarxa social.

2. Crawling: proces que s’encarrega d’interrogar els cercadors web pertal d’obtenir un llistat d’urls i el numero de matchings total que s’haobtingut.

3. Web Mining: l’analisi dels llistats de les urls, extraient tot tipus d’in-formacio com els nous actors o les descripcions semantiques en formesde keywords.

4. Representacio grafica: s’encarrega de mostrar a l’usuari els resultatsobtinguts, es a dir, la xarxa social.

Aquests moduls compleixen el model de programacio MVC (Model ViewerControler) que consisteix en separar les tres capes basiques del model deprogramacio: la capa de dades (Model), la capa de negoci (controler) i lainterfıcie de l’usuari (vista). Veiem un esquema dels quatre moduls a lafigura 5.1.


Figura 5.1: Moduls del sistema

Com funcionen els quatre moduls.

• Social Networking: es el controlador que s’encarrega de gestionar tot elsistema. Rep un actor o una llista d’actors i ens retorna la xarxa socialde la profunditat definida.

• Crawling: Rep un actor i ens retorna una llista d’urls associades aell, extretes d’un cercador web. Tambe retorna el numero de resultatsproporcionats pel cercador.

• Web Mining: Rep una llista d’urls i l’actor associat a aquesta llista. Re-torna els candidats a relacions d’aquest actor i la seva llista de keywordsmes rellevants.

• Representacio grafica: rep una xarxa social i gestiona tots els parametresnecessaris per mostrar el resultat HTML.


Referent a l’abstraccio de la capa de vista, utilitzarem les llibreries d’S-marty5 per poder gestionar el sistema de templates relacionat amb tota lainterfıcie grafica que es mostrara a l’usuari. S’escull Smarty per ser un pro-jecte desenvolupat directament per PHP i el seu gran rendiment davant altressistemes de Plantilles com Power Template o altres.

Un clar exemple de la modularitat del sistema es el Crawling. En elnostre cas tenim implementats dos moduls que s’encarreguen d’interrogar dosmotors de cerca diferents Google i Yahoo. Els dos son diferents internamentpero tenen els mateixos metodes i retornen els mateixos resultats, de talmanera que no influeix en la resta de moduls del sistema.

5.3.2 Diagrama de sequencia

En aquest punt detallem un diagrama de sequencia de la nostra aplicacio.

Figura 5.2: Diagrama de sequencia del sistema

Podem veure com l’actor introdueix el nom o noms dels actors a cercar.Aquestes dades arribem al modul de Social networking que s’encarrega degestionar tots els altres moduls amb l’objectiu d’obtenir la xarxa social. Ve-

5http://smarty.php.net/

http://smarty.php.net/


iem com s’analitzen tots els actors i fins que no s’acaben (depenent de laprofunditat de la xarxa) es van analitzant.

La interaccio amb el Crawler ens dona el llistat d’urls relacionades ambl’actor a analitzar. Aquest llistat es el que enviem cap al modul de web miningque s’encarrega d’analitzar un a un aquests documents PDF i extreure tantels possibles nous actors, com les keywords relacionades amb l’actor.

Per les keywords veiem la interaccio del modul de Stemming que es l’en-carregat de donar-nos el lexema de la paraula per fer les agrupacions perlexema. Totes aquestes dades son retornades al modul de web mining, queun cop hagi analitzat tots els documents, retornara la informacio de l’autoral modul de social networking.

L’afinitat entre actor i candidats a relacions la realitza el modul de socialnetworking, i de nou interactua amb el Crawling per extreure els valors neces-saris per el seu calcul. Afegim aquelles relacions que han estat seleccionadesal seguent nivell de la xarxa per continuar la iteracio fins al nivell definit pelsistema o per l’usuari.

Per ultim s’envia la xarxa social al modul de representacio grafica ques’encarrega de gestionar les dades de la xarxa social per tal de visualitzar-lesen format HTML.

5.4 Classes mes rellevants

En aquesta seccio realitzarem una breu descripcio de les classes mes im-portants de l’aplicacio. Veurem com s’han implementat i quines son les sevesfuncionalitats dins dels moduls explicats anteriorment. Aixı podrem comple-tar la visio del sistema explicada en el punt anterior.

5.4.1 Social Network

Class: socialNetwork.class.phpAquesta Classe es l’encarregada de gestionar tot el sistema. Rep les dades

de l’usuari i gestiona la interaccio amb els altres moduls fins generar la xarxasocial de l’individu o individus a analitzar. Veiem una petita descripcio delsmetodes mes interessants de la classe:

• buildSocialNetwork : rep la llista d’actors introduıda per l’usuari i s’en-carrega de la gestio d’inici a fi de la generacio de la xarxa social. Esl’encarregat d’iterar fins que no hi hagin mes nivells i d’interactuar ambel modul de representacio grafica. Per cada nivell crea tants proce-sos com autors existeixen per tal de fer aquest proces concurrentment.


S’encarrega de gestionar la divisio i fussio d’actors en un nivell i degenerar una unica xarxa social resultant.

• getActor : rep un actor i s’encarrega de gestionar l’analisi d’un actor.Aquest metode es cridat des dels processos que es creen per analitzarels actors concurrentment. Interactua amb el Web Mining per extreureles dades relacionades amb l’actor. Retorna la xarxa social de l’actor.

• setAffinities : rep un actor i el seu llistat de candidats a relacions.S’encarrega de calcular l’afinitat entre els dos individus a partir dela formula definida pel sistema o l’usuari. Aquest proces s’executaconcurrentment i es aquest metode qui s’encarrega de gestionar-ho.

• addSocialNetwork : rep un actor i la seva relacio. S’encarrega d’afegira la xarxa social l’actor si no existeix i la seva relacio. Es cridat alfinalitzar els processos d’afinitats per tal de muntar la xarxa a partirdels resultats de cada thread.

• groupSocialNetworks : rep un vector de xarxes socials i s’encarrega defusionar-los per crear una unica xarxa social. Aquest metode es cridatal finalitzar els processos d’analisi d’actors que retornen la xarxa socialdel actor estudiat. Totes aquestes xarxes es fusionen en una unica quees la xarxa social resultat.

5.4.2 Web Mining

Class: webMining.class.phpAquesta classe s’encarrega de realitzar tota la mineria de dades sobre el

llistat de documents PDFs extrets del motor de cerca, obtenint el llistat decandidats a relacions i la llista de keywords que defineixen semanticamenta l’actor. Veiem una petita descripcio dels metodes mes interessants de laclasse:

• getNewActors : rep un actor i la seva llista de documents associatsobtinguts del motor de cerca. Es el metode principal que s’encarregade gestionar tot el modul de web mining. Itera per cada document is’encarrega d’extreure els candidats a relacions i la llista de keywordsde cada actor.

• extractPdfContent : rep la url d’un document pdf. S’encarrega d’inte-ractuar amb la classe de conversio de PDF a text per tal d’obtenir elseu contingut.


• filterByLanguage: rep el contingut a filtrar. Aquest metode s’encarregaen primer lloc a identificar l’idioma en que esta escrit el document. Apartir d’aquesta informacio sera filtrat per les stopwords corresponents(angleses o espanyoles).

• miningNewEmails : rep el contingut en que s’han de cercar nous e-mails, es a dir, candidats a relacions. A partir d’expressions regulars iles regles definides al punt 4.3.1 s’extreu el llistat de possibles relacions.

5.4.3 Spider (Google & Yahoo)

Class: spider.class.php i spiderYahoo.class.phpEn aquest cas tenim dues classes diferents que tenen la mateixa finalitat:

retornar una llista de documents PDF i el numero de machings totals que hatrobat el cercador utilitzat. La diferencia entre les dues classes es el motorde cerca emprat per fer la cerca. Per tant, els metodes de la classe, a nivellabstracte, son exactament iguals. Veiem una petita descripcio dels metodesmes interessants de la classe:

• crawling : rep un o dos actors i s’encarrega de realitzar una consulta almotor de cerca amb els actors que rep. Aquest es el metode principalde la classe i s’encarrega de realitzar els passos necessaris per generarla llista de documents i extreure el numero de machings total.

• buildUrl : rep un o dos actors i s’encarrega de construir la consulta aexecutar pel cercador. A partir dels dos noms construeix el formatadient per cada motor de cerca per tal de que ens retorni els resultatsdesitjats. En el cas de Google fa la peticio al cercador directament i enel cas de Yahoo es fa al seu web service.

• parseHtml / parseXml : rep el contingut de l’html o del xml depenentdel cercador que estem utilitzant. En el cas de Google rebrem un HTMLper analitzar. A partir de les etiquetes HTML extraiem els enllacos alsdocuments PDF. En el cas de Yahoo es el mateix proces pero amb unxml. En ambdos casos es realitza tambe l’extraccio d’e-mails de lesdescripcions dels resultats.

5.4.4 Conversio de PDF a text

Class: pdf2content.class.phpAquesta classe s’encarrega de convertir el contingut d’un document PDF

a text per tal de ser analitzat el seu contingut. Per dur a terme aquest proces


s’utilitza un executable extern a l’aplicacio, disponible per Linux i Windows,anomenat pdftohtml.

Tambe existeix l’executable pdftotext, el qual seria mes apropiat per lesnostres intencions. Pero les conversions que realitza a text son pitjors queles realitzades a HTML. Per aquest motiu es va escollir passar-ho a HTMLi despres eliminar els tags propis del llenguatge. Tot gira al voltant d’unmetode en la classe:

• convert : rep la url del document PDF i s’encarrega de descarregar elpdf al sistema, executar l’aplicacio per convertir a HTML, filtrar elstags i retornar el contingut.

L’executable utilitzat realitza correctament la conversio en un numeroelevat de documents. Encara aixı falla en alguns, perdent les dades queaquest conte. Per aquestos casos, quan usem el motor de cerca Google,analitzem la conversio que realitza Google del fitxer PDF a HTML que en el100% dels casos es correcta, i d’aquesta manera no perdem cap dada.

5.4.5 Extraccio de Paraules Clau

Class: keywords.class.phpAquesta classe s’encarrega de extreure del contingut d’un document aque-

lles paraules que son mes rellevants i anar generant el conjunt de paraulesclau global de l’actor. Per fer-ho interactua amb les classes de stemming pertal de realitzar l’agrupament de les paraules. Veiem una petita descripciodels metodes mes interessants de la classe:

• miningKeyWords : rep el contingut a analitzar i el seu idioma. S’en-carrega d’extreure les paraules claus relacionades amb el contingut ob-tingut. Es el metode principal de la classe i es l’inici del parseig delcontingut.

• getStemmer : rep l’idioma del contingut i s’encarrega de crear la classede stemming corresponent a l’idioma seleccionat.

• parse words : rep el contingut del document i s’encarrega d’extreure unllistat de totes les paraules del document amb les seves ocurrencies.Aquesta llista es tractada pel metode occure filter.

• occure filter : rep la llista de paraules i el llindar mınim d’ocurrenciesper incloure’l en la llista final de paraules. S’analitzen una a una les pa-raules extraient el seu stem i agrupant-les per aquest. Es va construintla llista de paraules global de l’actor.


• sanitizeContent : rep el contingut del document i s’encarrega de filtrar-lo de caracters no alfanumerics per tal de extreure nomes paraules i nosımbols estranys.

5.4.6 Algorismes de Stemming

Class: stemmerES.class.php, stemmerEN.class.phpS’han implementat dos stemmers: l’angles i l’espanyol. Ambdos imple-

mentats a partir de l’algoritme de Porter funcionen de la mateixa manera.El funcionament es simple i el seu metode stem ens retorna el lexema de laparaula.

Seguidament, veurem en profunditat l’algoritme de stemmer de Porterper a la llengua espanyola. El llenguatge que s’utilitza per codificar-lo essnowball, dissenyat i implementat pel propi Porter[13], i es pot trobar almanual sintactic del llenguatge en la plana web del projecte6.

En aquest punt explicarem com funciona l’algorisme i despres veurem elcodi en snowball. En primer lloc definim aquelles lletres que son consideradescom a vocals:

a e i o u a e ı o u u

Seguidament definim les tres variables amb les que funciona l’algorisme:RV, R1 i R2.

R1 es la regio despres de la primera no vocal que segueix una vocal, o esla regio nul·la del final d’una paraula si no es dona el cas.

R2 es la regio despres de la primera no vocal que segueix una vocal enR1, o es la regio nul·la del final d’una paraula si no es dona el cas.

RV la definim de la seguent manera:

• Si la segona lletra de la paraula es una consonant, RV es la regio quehi ha despres de la seguent vocal consecutiva.

o l i v a t r a b a j o

|...| |.......|

• Si les dues primeres lletres son vocals, RV es la regio de despres de laseguent vocal.

a u r e o

|...|

6http://snowball.tartarus.org/compiler/snowman.html


• Si les dues primeres lletres son una consonant i una vocal, RV es laregio despres de la tercera lletra.

m a c h o

|...|

• En altres casos, RV es tota la paraula.

Seguidament aplicarem sempre quatre passos per realitzar el proces.

Pas 0: Pronoms adjunts

Es busca en la paraula els seguents sufixes:

me se sela selo selas selos

la le lo las les los nos

i seran eliminats, sempre i quan estiguin col·locats despres de:

(a) iendo ando ar er ır

(b) ando iendo ar er ir

(c) yendo precedit de "u"

en la variable RV. En el cas de c, “yendo” ha d’estar dins de RV, pero la“u” que precedeix pot estar fora de la variable. En el cas de a, la eliminaciova acompanyada de la eliminacio de l’accent (per exemple, haciendola -¿haciendo).

Pas 1: Eliminacio dels sufixos estandards

Es cerquen els seguents sufixos i s’executen les seguents accions indicades:

anza anzas ico ica icos icas ismo ismos able

ables ible ibles ista istas oso osa osos osas

amiento amientos imiento imientos

Esborrar si estan continguts a R2

adora ador acion adoras adores aciones ante antes

ancia ancias


Si esta precedit per "ic"



logıa logıas

Reemplacar per "log" si esta contingut a R2

ucion uciones

Remplacar per "u" si esta contingut a R2

encia encias

Remplacar per "ente" si esta contingut a R2

amente

Esborrem si estan continguts a R1

Si esta precedit per "iv"

Esborrar si esta contingut en R2

sino

Si esta precedit per "os", "ic" o "ad"

Esborrar si esta contingut a R2

mente

Esborrem si esta contingut en R2

Si esta precedit per "ante", "able" o "ible"


idad idades

Esborrem si estan contingudes en R2

Si esta precedit per "abil", "ic" o "iv"


iva ivo ivas ivos

Esborrem si estan contingudes en R2

Si esta precedit per "at"


Pas 2: Complement del pas 1

El pas 2 esta dividit en dos: realitzem el pas 2a si no s’ha eliminat capterminacio amb el pas 1.

Pas 2a: Sufixes de verbs que comencem per “y”Cerquem els seguents sufixes en RV, i si els trobem, els eliminem si estan

precedits per “u”


ya ye yan yen yeron yendo yo

yo yas yes yais yamos

Nota: La “u” precedent no ha d’estar dins de RV.Realitzem el pas 2b si el pas 2a s’ha executat, pero no ha eliminat cap

sufix.Pas 2b: Altres sufixos de verbsCerquem els seguents sufixes en RV,i executem l’accio indicada:

en es eis emos

Esborrem i

Si esta precedit per "gu"

Esborrar la u

arıan arıas aran aras arıais arıa areis

arıamos aremos ara are erıan erıas eran

eras erıais erıa ereis erıamos eremos era

ere irıan irıas iran iras irıais irıa

ireis irıamos iremos ira ire aba ada

ida ıa ara iera ad ed id ase iese

aste iste an aban ıan aran ieran asen

iesen aron ieron ado ido ando iendo io

ar er ir as abas adas idas ıas aras

ieras ases ieses ıs ais abais ıais arais

ierais aseis ieseis asteis isteis ados

idos amos abamos ıamos imos aramos ieramos

iesemos asemos

Esborrem

Pas 3: Sufixes residuals

Cerquem tots els seguents sufixes en RV, i executem l’accio indicada.

os a o a ı o

Esborrar si estan continguts a RV

e e

Esborrar si estan continguts a RV i

Si esta precedit per "gu" amb la "u" a RV

Esborrar la "u"


Pas 4: Finalment

Per ultim esborrem els accents i retornem la paraula.

Algorisme Stemming Espanyol en Snowball

routines (

postlude mark_regions

RV R1 R2

attached_pronoun

standard_suffix

y_verb_suffix

verb_suffix

residual_suffix

)

externals ( stem )

integers ( pV p1 p2 )

groupings ( v )

stringescapes {}

/* special characters (in ISO Latin I) */

stringdef a’ hex ’E1’ // a-acute

stringdef e’ hex ’E9’ // e-acute

stringdef i’ hex ’ED’ // i-acute

stringdef o’ hex ’F3’ // o-acute

stringdef u’ hex ’FA’ // u-acute

stringdef u" hex ’FC’ // u-diaeresis

stringdef n~ hex ’F1’ // n-tilde

define v ’aeiou{a’}{e’}{i’}{o’}{u’}{u"}’

define mark_regions as (

$pV = limit

$p1 = limit

$p2 = limit // defaults


do (

( v (non-v gopast v) or (v gopast non-v) )

or

( non-v (non-v gopast v) or (v next) )

setmark pV

)

do (

gopast v gopast non-v setmark p1

gopast v gopast non-v setmark p2

)

)

define postlude as repeat (

[substring] among(

’{a’}’ (<- ’a’)

’{e’}’ (<- ’e’)

’{i’}’ (<- ’i’)

’{o’}’ (<- ’o’)

’{u’}’ (<- ’u’)

// and possibly {u"}->u here, or in prelude

’’ (next)

) //or next

)

backwardmode (

define RV as $pV <= cursor

define R1 as $p1 <= cursor

define R2 as $p2 <= cursor

define attached_pronoun as (

[substring] among(

’me’ ’se’ ’sela’ ’selo’ ’selas’ ’selos’ ’la’ ’le’ ’lo’

’las’ ’les’ ’los’ ’nos’

)

substring RV among(

’i{e’}ndo’ (] <- ’iendo’)

’{a’}ndo’ (] <- ’ando’)

’{a’}r’ (] <- ’ar’)

’{e’}r’ (] <- ’er’)


’{i’}r’ (] <- ’ir’)

’ando’

’iendo’

’ar’ ’er’ ’ir’

(delete)

’yendo’ (’u’ delete)

)

)

define standard_suffix as (

[substring] among(

’anza’ ’anzas’

’ico’ ’ica’ ’icos’ ’icas’

’ismo’ ’ismos’

’able’ ’ables’

’ible’ ’ibles’

’ista’ ’istas’

’oso’ ’osa’ ’osos’ ’osas’

’amiento’ ’amientos’

’imiento’ ’imientos’

(

R2 delete

)

’adora’ ’ador’ ’aci{o’}n’

’adoras’ ’adores’ ’aciones’

’ante’ ’antes’ ’ancia’ ’ancias’// Note 1

(

R2 delete

try ( [’ic’] R2 delete )

)

’log{i’}a’

’log{i’}as’

(

R2 <- ’log’

)

’uci{o’}n’ ’uciones’

(

R2 <- ’u’

)

’encia’ ’encias’


(

R2 <- ’ente’

)

’amente’

(

R1 delete

try (

[substring] R2 delete among(

’iv’ ([’at’] R2 delete)

’os’

’ic’

’ad’

)

)

)

’mente’

(

R2 delete

try (

[substring] among(

’ante’ // Note 1

’able’

’ible’ (R2 delete)

)

)

)

’idad’

’idades’

(

R2 delete

try (

[substring] among(

’abil’

’ic’

’iv’ (R2 delete)

)

)

)

’iva’ ’ivo’

’ivas’ ’ivos’

(


R2 delete

try (

[’at’] R2 delete

)

)

)

)

define y_verb_suffix as (

setlimit tomark pV for ([substring]) among(

’ya’ ’ye’ ’yan’ ’yen’ ’yeron’ ’yendo’ ’yo’ ’y{o’}’

’yas’ ’yes’ ’yais’ ’yamos’

(’u’ delete)

)

)

define verb_suffix as (

setlimit tomark pV for ([substring]) among(

’en’ ’es’ ’{e’}is’ ’emos’

(try (’u’ test ’g’) ] delete)

’ar{i’}an’ ’ar{i’}as’ ’ar{a’}n’ ’ar{a’}s’ ’ar{i’}ais’

’ar{i’}a’ ’ar{e’}is’ ’ar{i’}amos’ ’aremos’ ’ar{a’}’

’ar{e’}’

’er{i’}an’ ’er{i’}as’ ’er{a’}n’ ’er{a’}s’ ’er{i’}ais’

’er{i’}a’ ’er{e’}is’ ’er{i’}amos’ ’eremos’ ’er{a’}’

’er{e’}’

’ir{i’}an’ ’ir{i’}as’ ’ir{a’}n’ ’ir{a’}s’ ’ir{i’}ais’

’ir{i’}a’ ’ir{e’}is’ ’ir{i’}amos’ ’iremos’ ’ir{a’}’

’ir{e’}’

’aba’ ’ada’ ’ida’ ’{i’}a’ ’ara’ ’iera’ ’ad’ ’ed’

’id’ ’ase’ ’iese’ ’aste’ ’iste’ ’an’ ’aban’ ’{i’}an’

’aran’ ’ieran’ ’asen’ ’iesen’ ’aron’ ’ieron’ ’ado’

’ido’ ’ando’ ’iendo’ ’i{o’}’ ’ar’ ’er’ ’ir’ ’as’

’abas’ ’adas’ ’idas’ ’{i’}as’ ’aras’ ’ieras’ ’ases’

’ieses’ ’{i’}s’ ’{a’}is’ ’abais’ ’{i’}ais’ ’arais’

’ierais’ ’aseis’ ’ieseis’ ’asteis’ ’isteis’ ’ados’

’idos’ ’amos’ ’{a’}bamos’ ’{i’}amos’ ’imos’

’{a’}ramos’ ’i{e’}ramos’ ’i{e’}semos’ ’{a’}semos’


(delete)

)

)

define residual_suffix as (

[substring] among(

’os’

’a’ ’o’ ’{a’}’ ’{i’}’ ’{o’}’

( RV delete )

’e’ ’{e’}’

( RV delete try( [’u’] test ’g’ RV delete ) )

)

)

)

define stem as (

do mark_regions

backwards (

do attached_pronoun

do ( standard_suffix or

y_verb_suffix or

verb_suffix

)

do residual_suffix

)

do postlude

)

5.4.7 Visualitzacio de la xarxa social

Class: importGraph.class.phpAquesta classe s’encarrega de rebre una xarxa social i preparar-la per la

seva visualitzacio en l’HTML resultant. Veiem una petita descripcio delsmetodes mes interessants de la classe:

• buildXmlFile: rep una xarxa social i s’encarrega de construir el fitxerXML necessari perque l’aplicacio Flash que mostra la xarxa social lapugui visualitzar. Aquest fitxer es creat i escrit dins del directori detemplates del nostre sistema, amb un identificador que el relaciona ambl’execucio actual de l’aplicacio.


• buildParamsTemplate: rep una xarxa social i s’encarrega de preparartotes les variables necessaries per poder pintar el template que visua-litzara el resultat HTML.

L’eina grafica que s’utilitza per representar la xarxa social es un Flashdissenyat e implementat per Moritz Stefaner7. El seu funcionament es moltsimple i es basa en un fitxer XML que conte la informacio de la xarxa.

Basicament es regeix amb dos estructures diferents: els nodes i les relaci-ons. Un node te la seguent estructura:

<Nodes>

<Person id="[email protected]" name="[email protected]" />




</Nodes>

I les relacions el seguent format:

<Relations>

<Relation fromID="[email protected]" toID="[email protected]"/>



</Relations>

D’aquesta manera el script Flash interpreta el document XML i es capacde construir la xarxa social.

5.4.8 Multi Proces

Class: fork.class.phpAquesta classe s’encarrega de gestionar tot el relacionat amb l’execucio

de processos concurrents i la memoria compartida. Aquesta classe basadaen el desenvolupament de Luca Mariano8, ha estat modificada i adaptada alnostre sistema. Veiem una petita descripcio dels metodes mes interessantsde la classe:

• PHP Fork : Rep el nom amb el que s’identificara el proces en el sistema.S’encarrega de iniciar la classe fork i de reservar la memoria compartidaper aquest proces (100KB).

7http://www.der-mo.net/relationBrowser/index.html8http://phpclasses.masbytes.es/browse/package/1136.html

http://www.der-mo.net/relationBrowser/index.html

http://phpclasses.masbytes.es/browse/package/1136.html


• setVariable: rep un identificador i el valor de la variable a emmagatze-mar. S’encarrega de guardar el valor passat amb el nom de l’identifi-cador en la memoria compartida creada.

• getVariable: rep l’identificador de la variable emmagatzemada en lamemoria compartida i s’encarrega de recuperar-la i retornar el seu valor.

• run: Aquest es el metode on s’implementa l’inici del proces fill. Aquestmetode es heretat i ha d’estar a la classe que exten de la classe fork.

• start : Aquest metode s’encarrega d’executar el proces definit al metoderun.

• stop: Aquest metode finalitza l’execucio del proces i neteja totes lesvariables del sistema creades, com la memoria compartida, semafors iprocessos zombies.

Com ja hem comentat aquesta classe esta preparada per ser heretada, ien la classe filla es on s’ha d’implementar el codi a executar. En el nostre cas,com volem concurrencia en l’analisi d’actors i en el calcul d’afinitats crearemdues classes que heretaran de fork:

1. tActors.class.php: Per gestionar els actors. Crea una nova instancia dela classe socialNetwork per realitzar el proces.

2. tAffinities.class.php: Per gestionar les afinitats. Crea una nova instanciade la classe socialNetwork per realitzar el proces.

5.4.9 Debug

Class: debug.class.php Aquesta classe s’encarrega de recollir parametresque ens permeten veure com es comporta l’aplicacio mentre s’executa. Elproblema principal a l’hora de emmagatzemar les dades es l’us de processosconcurrents per executar l’aplicacio. Per aquest motiu el debug s’emmagatze-ma en la memoria compartida del sistema per tal de recuperar-lo i fusionar-loal final i obtenir les dades globals del sistema. Veiem una petita descripciodels metodes mes interessants de la classe:

1. gTime: ens retorna el temps en microsegons del moment de la crida almetode.

2. setUrlTime: rep una url i un estat que pot ser inici o fi. S’encarregade registrar el temps incial d’un punt identificat per l’url i el seu tempsfinal. S’utilitza per registrar el temps que triga en parsejar una url.


3. setNumThreads : rep un numero de threads i s’encarrega de sumaraquest numero amb l’acumulat per tal de saber-hi quants processoss’han creat al llarg de l’execucio.

4. setTime: rep una etiqueta i un estat que pot ser inici o fi. S’encarregade registrar el temps inicial d’un punt identificat per l’url i el seu tempsfinal. S’utilitza per registrar el temps que triga en parsejar una url.

5. groupDebug rep una llista de debugs i s’encarrega de fusionar els debugsretornats per els diversos processos per tal d’obtenir un debug global.

6. setLevel : Rep un nou nivell i s’encarrega de emmagatzemar aquestavariable en la classe per separar les dades de guardades al debug seg-mentades per nivells.

7. renderDebug : Organitza les dades emmagatzemades i les prepara perser mostrades en un template HTML per ser visualitzades per l’usauri.

5.5 Optimitzacions del sistema

En aquest punt parlarem de les optimitzacions que hem realitzat al sis-tema i al nostre codi per reduir al maxim el temps d’execucio de l’aplicacio.Una aplicacio que pot arribar a funcionar a nivell web ha de donar uns tempsde resposta mitjanamet optims encara que les operacions que realitza siguinmolt costoses.

5.5.1 Execucio multi threading

La idea d’una xarxa social ens fa pensar clarament en una execucio multithreading, ja que podem avaluar diversos actors del mateix nivell alhorareduint el temps d’execucio del sistema. Aquesta es una de les primeresoptimitzacions que es van aplicar al sistema al veure el temps que trigava engenerar una xarxa social de nivell 2.

Per fer un sistema multi threading en PHP s’han d’instal·lar les llibre-ries pcntl9 que s’encarreguen de fer la gestio total de la gestio de processos.Aquestes llibreries implementen a l’estil Unix la creacio de processos, execuciode programa, administracio de senyals i finalitzacio de processos.

El manual de PHP ens recomana que el control de processos hauria d’estardesactivat per un servidor web, ja que podrien produir-se resultats inespe-rats. Per aquest motiu es va recompilar PHP per tenir disponibles l’execucio

9http://es.php.net/manual/es/ref.pcntl.php

http://es.php.net/manual/es/ref.pcntl.php


de scripts des de la lınia de comandes (CLI). Aixı la nostra aplicacio esllancara des del navegador, pero sera executada des de la lınea de comandesmitjancant la funcio system de PHP.

Amb el multi threading, necessitem el complement necessari per recuperarles dades calculades en cada thread. La comunicacio amb el pare es necessariai per aixo necessitem les funcions de gestio de la memoria compartida. Peraixo, a l’hora de recompilar PHP inclourem tambe les llibreries shmop10.Aquestes llibreries son un conjunt de funcions que permeten a PHP llegir,escriure i esborrar de forma senzilla segments de memoria compartida detipus Unix.

Com s’ha vist aquestes llibreries funcionen a partir de les funcions Unixque ens permeten crear nous processos i gestionar la memoria compartida.Aixo fa que el sistema no funcioni en un entorn Windows. Aquest es undels principals motius per el que es va escollir Linux com a plataforma web.Amb aixo tambe fem que el nostre codi deixi de ser multiplataforma i nomesfuncioni en entorns Unix, al menys ara per ara.

L’optimitzacio es nota de forma considerable quan la xarxa comenca atenir un gran numero d’actors. El sistema es converteix en concurrent en dospunts:

• Es crea un nou proces per cada actor.

• Dins de cada actor, es crea un nou proces per cada candidatura derelacio. Aixı si un actor te 500 possibles relacions, es calculen les sevesafinitats de forma concurrent.

Els temps es redueixen fins a la meitat. En el cas de la xarxa de nivell 2d’en Xavi Canaleta passem de 6 minuts 30 segons a 3 minuts 10 segons. Totala gestio de la memoria compartida, el multithreading, etc, encara requereixprou recursos de proces que fan que els temps encara siguin elevats.

5.5.2 Cache de resultats

Una solucio als alts temps que triga el sistema en generar la xarxa sociales l’opcio d’emmagatzemar en cache dades utils i reaprofitables. Per dur aterme aquesta funcionalitat s’ha utilitzat memcached.

Memcached es definit per Danga Interactive11, l’empresa que el desenvo-lupa i mante el projecte sota llicencia BSD com un “sistema distribuıt d’alta

10http://es.php.net/manual/es/ref.shmop.php11http://www.danga.com/memcached/

http://es.php.net/manual/es/ref.shmop.php

http://www.danga.com/memcached/


performance per el cacheig d’objectes en memoria, generic per naturalesa,pero pensat per incrementar la velocitat d’aplicacions web dinamiques”.

La idea es molt simple i a la vegada molt efectiva: un servei que escol-ta en un host i un port especıfic, que pot emmagatzemar cadenes de bytes.D’aquesta manera, podrıem estar guardant en memoria una estructura seri-alitzada de PHP o Java, un string decodejat amb Json, o un document dequalsevol format.

Existeix actualment una implementacio de memcached server que s’exe-cuta sobre Windows i sobre Linux. Ha estat provada en aquest ProjecteFinal de Carrera en les dues plataformes funcionant correctament en ambdosplataformes.

Memcached, a grans trets, emmagatzema les cadenes de bytes (interna-ment anomenats ıtems), en una gran taula de hash, i els mapeja segons laclau que l’associem a l’ıtem.

Aquesta taula de hash adopta una estructura de porcions de memoria demida variable (denominats slabs), amb l’objectiu d’optimitzar l’assignaciode l’espai de memoria. El slab de major mida es d’1 MB, essent aquest lamida maxima que un ıtem pot tenir si vol ser emmagatzemat en Memcached(encara que aquest valor es pot canviar al codi font).

La seva arquitectura escalable ens permet mantenir un pool de mem-cached servers, caracterıstica que be pot ser explotada en moments on laquantitat de connexions no pot ser gestionada per un unic server. En aquestcas el pool optara per l’altre server, balancejant la carrega de connexions.

El protocol per realitzar la comunicacio entre els clients i el servidores forca senzill i basat en comandes. El protocol implementa 3 comandesd’emmagatzemament:

• SET: actualitza l’objecte si existia anteriorment, o l’insereix en cascontrari.

• ADD: agrega l’objecte nomes si no existeix.

• REPLACE: actualiza l’objecte nomes si existeix.

Memcached permet controlar el temps de vida d’un objecte, indicant el“temps d’expiracio” per el mateix, en el moment de realitzar una operaciod’emmagatzematge.

Tambe posseeix una comanda de recuperacio: GET. Podem eliminar unobjecte mitjancant la comanda DELETE. A mes el protocol implementacomandes per recuperar estadıstiques, buidar la cache i utilitzar algun tipusde compressio, entre altres.


Per interactuar amb PHP s’ha d’instal·lar les llibreries que s’encarreguende connectar-se al servidor i enviar-li les comandes necessaries per podertreballar amb ell12.

Una vegada vist com funciona memcached especificarem com hem muntatels servidors en el nostre cas. Nosaltres hem configurat 3 servidors diferentsen el nostre sistema:

1. Actors: on reservem 50 MB de memoria per emmagatzemar les dadesresultants de l’analisi d’un actor per tal de recuperar-lo de nou si esrequerit. Un actor en un cas de moltes relacions pot ocupar 100 KB laseva estructura de dades. Per tant amb 50 MB podem emmagatzemarmes de 500 actors.

2. Urls i altres: on reservem 140 Mb on emmagatzemarem els contingutsdels documents analitzats a partir de les urls extretes del cercador.Aquı es necessita una gran quantitat de memoria ja que els contingutspoden ser molt pesats.

3. Auxiliar de memoria compartida: on reservem 10MB. Aquest espai elreservem per si algun proces de tractament d’actor no te suficient ambels 100Kb de memoria compartida que es defineixen. En aquest cas,abans de perdre la informacio, s’utilitza memcached per fer les funcionsde memoria compartida.

Tal i com s’ha explicat, cada servidor de memcached s’executa amb unproces diferent i cadascun d’ells utilitza un port per escoltar peticions dife-rent.

El temps d’expiracio de la cache esta configurat a 4 hores en els tres tipusde cache creats. Aixı garantim que execucions consecutives utilitzen dadesque estan emmagatzemades a la cache.

La utilitzacio d’aquest sistema augmenta el temps de resposta d’una ma-nera abismal. El proces d’extraccio de la xarxa social d’en Xavi Canaletade nivell dos, passem del 3 minuts i 10 segons a 10 segons. Una reduccioespectacular i comencem a parlar de temps acceptables per una plataformaweb.

5.5.3 Accelerador PHP

Els llenguatges de script, en concret PHP, son considerats mes lents queels llenguatges compilats com C. La necessitat de parsejar el fitxer abans de

12http://es.php.net/manual/es/ref.memcache.php

http://es.php.net/manual/es/ref.memcache.php


l’execucio es la principal rao per aquesta perdua de performance. Es cert quePHP sofreix aquest problema, pero afegint un accelerador (o per ser exactes,un opcpde cache) podem millorar aquestes mancances.

L’execucio d’un script PHP realitza els seguents passos:

1. Carrega els fitxers

2. Parseja el codi font, i el transforma en opcodes (el codi que pot serexecutat per el servidor)

3. S’executen els opcodes.

L’accelerador agafa els opcodes del pas 2 i els cacheja en memoria com-partida o en disc. Aquests opcodes cachejats son directament reutilitzats lapropera vegada que el fitxer PHP es executat, sense la carrega i el parseigdel fitxer un altre cop.

Alguns acceleradors afegeixen un pas d’optimitzacio eliminat codi inne-cessari (bucles buits, variables que no s’usen, etc.) En molts casos, aquestpas optimitzacio no millora molt la seva performance.

Veiem els 3 acceleradors mes interessants (estables, amb manteniment irapids) disponibles:

• APC (open-source)13

• eAccelerator, un derivat de Turck-mmcache (open-source)14

• Zend Platform (comercial)15

Nomes eAccelerator i Zend realitzen l’optimitzacio dels opcodes. En elcas de la plataforma Zend es molt mes que un opcode cache: aquest incloumoltes eines (debugging, monitoritzacio, integracio Java, etc. que poden serinteressants. Pero al ser un producte comercial, i existir alternatives opensource, la descartem en aquest Projecte Final de Carrera.

Obviament l’accelerador millora els temps d’execucio del codi PHP perono dels accessos a disc o de les peticions HTTP que realitzem per obtenirels documents PDF. Encara aixı els parsejats i analisis que es realitzen sobrecada document PDF extrets son molts costosos i en aquest punt veiem lamillora.

Finalment s’han provat els dos acceleradors al nostre sistema. El pro-blema amb eAccelerator es que no dona suport al cache de les aplicacions

13http://pecl.php.net/package/APC14http://eaccelerator.net/15http://www.zend.com/products/zend_platform

http://pecl.php.net/package/APC

http://eaccelerator.net/

http://www.zend.com/products/zend_platform


que s’executen des de la lınia de comandes (php-cli). Tal i com s’ha explicatanteriorment la nostra aplicacio necessita ser executada des de la lınia decomandes per poder utilitzar les llibreries de multi proces i memoria com-partida. Aixı doncs, no s’han pogut realitzar proves de benchmarking ambeAccelerator en el nostre sistema i s’ha descartat com a solucio.

Aixı doncs l’accelerador escollit ha estat APC 3.0.14 (estable), ja quecontempla l’opcio de cache dels executables per lınia de comandes a partirde la versio 3.0.6 activant la directiva d’execucio del php.ini apc.enable-cli =on. Aixı doncs els fitxers es cachegen despres de la seva primera execucio is’emmagatzemen en la memoria del sistema (fins a 30MB). Veiem a la imatge5.3 l’aplicacio d’estadıstiques d’APC.

Figura 5.3: Panell d’estadıstiques d’APC

5.6 Limitacions tecnologiques

Mes enlla de totes les optimitzacions que es puguin realitzar sobre el codii el servidor ara per ara no es eficient el sistema i ens trobem davant d’unalimitacio tecnologica.

Som conscients que el que penalitza el temps d’execucio de l’aplicacio, esel temps de peticions HTTP a documents PDF o al propi cercador. La soluciode l’execucio multi proces es un primer pas cap a una possible solucio mes


complerta i molt mes eficient, la paral·lelitzacio dels processos. Disposar d’uncluster de processadors en permetria poder repartir els processos a executarreduint d’una manera molt elevada el temps d’execucio.

Fent un calcul aproximat, amb un cluster de 5 maquines podrıem dividirel temps d’execucio de l’aplicacio en quasi 4,5. De tal manera que el que aratriga 3 minuts en executar-se, la xarxa de nivell 2 d’en Xavi Canaleta, podriatrigar uns 40 segons. Un temps molt mes raonable que l’anterior.

Igualment, a mida que les connexions a Internet vagin augmentat la sevavelocitat, els temps s’aniran reduint, encara que ara per ara ja estem parlantde temps molt petits.

Capıtol 6

Resultats

En aquest capıtol mostrarem una bateria de resultats extrets de l’aplicacioimplementada. Es fara una breu explicacio de cadascun d’ells ressaltant allomes caracterıstic de cada resultat.

No s’han fet joc de proves amb xarxes de nivell 2 perque les dades son moltextenses i no ens servirien per il·lustrar els casos estudiats i implementats.

6.1 Xarxes de Nivell 1

6.1.1 Xarxa de [email protected]

Veiem el resultat de la xarxa de nivell 1 d’en Xavi Canaleta calculadaamb el coeficient d’Overlap:

{}

Array

(

[[email protected]] => Array

(

[id] => xavic

[domain] => salleurl.edu

[email] => [email protected]

[matchActor] => 8

[relations] => Array

(


(

[id] => dave


88

CAPITOL 6. RESULTATS 89


[coauthor] => 1

[affinity] => 0.875

[level] =>

)


(

[id] => ralsina



[coauthor] => 1

[affinity] => 0.25

[level] =>

)


(

[id] => montero



[coauthor] => 1

[affinity] => 0.625

[level] =>

)

)

[keywords] => Array

(

[alumnos] => Array

(

[occurrence] => 145

[stem] => alumn

)

[sistema] => Array

(

[occurrence] => 106

[stem] => sistem

)


[datos] => Array

(

[occurrence] => 91

[stem] => dat

)

[asignatura] => Array

(

[occurrence] => 78

[stem] => asignatur

)

[realizar] => Array

(

[occurrence] => 67

[stem] => realiz

)

[creditos] => Array

(

[occurrence] => 65

[stem] => credit

)

[informacion] => Array

(

[occurrence] => 58

[stem] => inform

)

[grupo] => Array

(

[occurrence] => 57

[stem] => grup

)

[cada] => Array

(

[occurrence] => 55

[stem] => cad


)

[nota] => Array

(

[occurrence] => 53

[stem] => not

)

)

)


(

[id] => dave



[coauthor] => 1

[affinity] => 0.875

[level] =>

[matchActor] => 29


(

....

)

[keywords] => Array

(

[alumnos] => Array

(

[occurrence] => 258

[stem] => alumn

)

[sistema] => Array

(

[occurrence] => 131

[stem] => sistem

)



(

[occurrence] => 130

[stem] => asignatur

)

[datos] => Array

(

[occurrence] => 124

[stem] => dat

)

[cada] => Array

(

[occurrence] => 79

[stem] => cad

)

[debe] => Array

(

[occurrence] => 72

[stem] => deb

)

[trabajo] => Array

(

[occurrence] => 70

[stem] => trabaj

)

[informacion] => Array

(

[occurrence] => 61

[stem] => inform

)

[creditos] => Array

(

[occurrence] => 58

[stem] => creditos

)


[ejercicio] => Array

(

[occurrence] => 57

[stem] => ejercici

)

)

)


(

[id] => ralsina



[coauthor] => 1

[affinity] => 0.25

[level] =>

[matchActor] => 12


(

...

)

[keywords] => Array

(

[Indice] => Array

(

[occurrence] => 1546

[stem] => indic

)

[cerrar] => Array

(

[occurrence] => 803

[stem] => cerr

)

[coru~na] => Array

(

[occurrence] => 787


[stem] => coru~n

)

[sesiones] => Array

(

[occurrence] => 785

[stem] => sesion

)

[facultad] => Array

(

[occurrence] => 784

[stem] => facult

)

[septiembre] => Array

(

[occurrence] => 783

[stem] => septiembr

)

[autores] => Array

(

[occurrence] => 783

[stem] => autor

)

[ventana] => Array

(

[occurrence] => 778

[stem] => ventan

)

[informatica] => Array

(

[occurrence] => 775

[stem] => informat

)

[universidade] => Array

(


[occurrence] => 773

[stem] => universidad

)

)

)


(

[id] => montero



[coauthor] => 1

[affinity] => 0.625

[level] =>

[matchActor] => 60


(

...

)

[keywords] => Array

(

[trabajo] => Array

(

[occurrence] => 97

[stem] => trabajo

)

[sistema] => Array

(

[occurrence] => 86

[stem] => sistem

)

[facultad] => Array

(

[occurrence] => 58

[stem] => facultad


)

[alumno] => Array

(

[occurrence] => 46

[stem] => alumn

)


(

[occurrence] => 42

[stem] => asignatur

)

[umbral] => Array

(

[occurrence] => 25

[stem] => umbral

)

[canal] => Array

(

[occurrence] => 25

[stem] => canal

)


(

[occurrence] => 23

[stem] => universidade

)

[ejercicio] => Array

(

[occurrence] => 21

[stem] => ejercici

)

) )

)


Podem veure el node pare que es en Xavi Canaleta i despres les sevesrelacions. Si ens fixem totes elles tenen marcat el flag de coautoria i aixoens indica que han passat a ser relacions directament sense calcular l’afinitatentre actors. Per tant, amb aquest exemple no podem veure diferencies entreels diferents tipus d’afinitats.

Tambe observem el conjunt de paraules clau rellevants per l’actor Xa-vi Canaleta. Per cadascuna d’elles es veu el numero d’ocurrencies i el seulexema.

Les relacions de les relacions han estat eliminades per no omplir ambdades innecessaries aquest punt. Les relacions del nivell + 1 de profunditats’analitzen per poder extreure les seves keywords. Pero no s’analitzen lesseves relacions per optimitzar temps. Per aquest motiu les llistes de relacionspoden ser molt extenses.

Temps sense cache

Aquı podem veure el temps que triga estant la cache buida es de 118s.

Temps amb cache

Amb dades en cache el sistema triga 2s en generar la xarxa social.

6.1.2 Xarxa de [email protected]

Aquest actor en concret sofreix el cas del document PDF amb un llistatd’emails. La xarxa sense els filtres d’e-mail queda amb 93 relacions. Veieml’inici de la xarxa:

{}

Array

(


(

[id] => ralsina



[matchActor] => 12


(


(

[id] => xavic




[coauthor] => 1

[affinity] => 0.25

[level] =>

)


(

[id] => dave



[coauthor] => 1

[affinity] => 0.166666666667

[level] =>

)


(

[id] => montero



[coauthor] => 1

[affinity] => 0.833333333333

[level] =>

)


(

[id] => moran



[coauthor] => 1

[affinity] => 1

[level] =>

)


(

[id] => jclaudi




[coauthor] => 1

[affinity] => 0.666666666667

[level] =>

)


(

[id] => xavis



[coauthor] => 1

[affinity] => 0.416666666667

[level] =>

)


(

[id] => ntali

[domain] => emirates.net.ae


[coauthor] => 0.2

[affinity] => 0.05

[level] =>

)


(

[id] => emalaver

[domain] => ing.ula.ve


[coauthor] => 0.2

[affinity] => 0.0666666666667

[level] =>

)


(

[id] => joseangel.garcia

[domain] => .unican.es



[coauthor] => 0.2

[affinity] => 0.0333333333333

[level] =>

)


(

[id] => munilla

[domain] => ic.uma.es


[coauthor] => 0.2

[affinity] => 0.0285714285714

[level] =>

)


(

[id] => manuels

[domain] => eresmas.net


[coauthor] => 0.2

[affinity] => 0.0333333333333

[level] =>

)


(

[id] => macasar

[domain] => diac.upm.es


[coauthor] => 0.2

[affinity] => 0.0666666666667

[level] =>

)

....

Podem veure en aquests ultims actors que la coautoria val 0.2. Aixo voldir que aquest actor ha estat extret d’un document amb molta densitat d’e-


mails i sera penalitzat, multiplicant la seva afinitat per 0.2. Com el filtre nos’ha aplicat surt a la xarxa.

Veiem ara la xarxa amb el filtre aplicat:

{}

Array

(


(

[id] => ralsina



[matchActor] => 12


(


(

[id] => xavic



[coauthor] => 1

[affinity] => 0.25

[level] =>

)


(

[id] => dave



[coauthor] => 1

[affinity] => 0.166666666667

[level] =>

)


(

[id] => montero



[coauthor] => 1


[affinity] => 0.833333333333

[level] =>

)


(

[id] => moran



[coauthor] => 1

[affinity] => 1

[level] =>

)


(

[id] => jclaudi



[coauthor] => 1

[affinity] => 0.666666666667

[level] =>

)


(

[id] => xavis



[coauthor] => 1

[affinity] => 0.416666666667

[level] =>

)


(

[id] => lmvillaverde

[domain] => hotmail.com


[coauthor] => 0.2

[affinity] => 0.2


[level] =>

)


(

[id] => angamar

[domain] => supercable.es


[coauthor] => 0.2

[affinity] => 0.2

[level] =>

)


(

[id] => porche

[domain] => tfo.upm.es


[coauthor] => 0.2

[affinity] => 0.2

[level] =>

)


(

[id] => oscar.giz

[domain] => navegalia.com


[coauthor] => 0.2

[affinity] => 0.2

[level] =>

)


(

[id] => cbernal

[domain] => posta.unizar.es


[coauthor] => 0.2

[affinity] => 0.2


[level] =>

)


(

[id] => teo_bernardino

[domain] => hotmail.com


[coauthor] => 0.2

[affinity] => 0.2

[level] =>

)


(

[id] => antoniojavier.garcia

[domain] => upct.es


[coauthor] => 1

[affinity] => 0.285714285714

[level] =>

)


(

[id] => aalvarez

[domain] => grp.tsc.uvigo.es


[coauthor] => 0.2

[affinity] => 0.2

[level] =>

)

)

[keywords] => Array

(

[Indice] => Array

(

[occurrence] => 1546

[stem] => ındic


)

[cerrar] => Array

(

[occurrence] => 803

[stem] => cerr

)

[coru~na] => Array

(

[occurrence] => 787

[stem] => coru?

)

[sesiones] => Array

(

[occurrence] => 785

[stem] => sesion

)

[facultad] => Array

(

[occurrence] => 784

[stem] => facult

)

[septiembre] => Array

(

[occurrence] => 783

[stem] => septiembr

)

[autores] => Array

(

[occurrence] => 783

[stem] => autor

)

[ventana] => Array

(

[occurrence] => 778


[stem] => ventan

)

[informatica] => Array

(

[occurrence] => 775

[stem] => informat

)


(

[occurrence] => 773

[stem] => universidad

)

)

)

)

Ara obtenim nomes 14 relacions per [email protected]. El filtre haeliminat moltes relacions que no tenen cap sentit. Si ara apliquem a lamateixa xarxa el coeficient del cosinus veurem un canvi en els resultats.

{}

Array

(


(

[id] => ralsina



[matchActor] => 12


(


(

[id] => xavic



[coauthor] => 1

[affinity] => 0.0208333333333


[level] =>

)


(

[id] => dave



[coauthor] => 1

[affinity] => 0.00574712643678

[level] =>

)


(

[id] => montero



[coauthor] => 1

[affinity] => 0.0138888888889

[level] =>

)


(

[id] => moran



[coauthor] => 1

[affinity] => 0.0169491525424

[level] =>

)


(

[id] => jclaudi



[coauthor] => 1

[affinity] => 0.0229885057471

[level] =>


)


(

[id] => xavis



[coauthor] => 1

[affinity] => 0.0297619047619

[level] =>

)

)

[keywords] => Array

....

La reduccio es molt gran. Com ja s’havia comentat el coeficient delcosinus es mes agressiu que el coeficient d’overlap, per tant si algun dels dosactors a relacionar te molts resultats, com es el cas, el coeficient d’afinitat esfa molt petit. Si aixo li sumem que la penalitzacio per document es de 0.2,eliminem molts candidats.

Estudiant aquest cas a fons, el coeficient del cosinus s’apropa mes a larealitat. Dels 93 candidats nomes 7 son realment relacions, per tant nomess’ha perdut una relacio. En canvi, amb el coeficient d’overlap ens surten 14relacions, es a dir, 7 que no ho son en realitat.

Temps sense cache

Aquı podem veure el temps que triga estant la cache buida es de 342s.

Temps amb cache

Amb dades en cache el sistema triga 2s en generar la xarxa social.

Capıtol 7

Conclusions

Els objectius plantejats en aquest Projecte Final de Carrera s’han asso-lit completament a l’haver realitzat l’estudi, disseny i implementacio d’unsistema extractor de xarxes socials.

L’estudi ha comportat una gran feina d’investigacio a l’hora de recollirinformacio diversa per tal de construir aquest sistema que engloba moltesarees diferents i moltes lınies d’investigacio per aprofundir. La gran quantitatde possibilitats d’implementacio a cada modul del sistema ha fet que aquestProjecte es convertıs en una constant investigacio. Podem dir que s’hanestablert unes bases solides del sistema obtenint uns resultats molt positiusi que motiven la continuıtat d’aquesta via de recerca.

El proces d’estudi ha consistit en la constant documentacio sobre lestecniques actuals relacionades amb implementacions similars i amb la im-plementacio de petites eines de test per contrastar aquestes informacionsobtingudes. S’han provat multiples solucions als problemes on a vegades elresultat ha estat satisfactori i en altres no s’ha arribat a bon port.

En el proces de crawling ens adonem de les dificultats de poder extreureinformacio correcta i relacionada amb l’actor que volem analitzar. Els cerca-dors web no faciliten eines de consulta exhaustives i per tant la interrogacioens retorna dades correctes, pero tambe incorrectes, que fan que les dades nosiguin 100% fiables.

A aquesta situacio es suma l’ambiguetat de noms i la informacio irrelle-vant que ens pot retornar Internet. Per tal d’acotar al maxim aquella in-formacio que ens pot aportar quelcom util, es van anHsoalitzar els resultatsobtinguts per les consultes fetes a partir del nom d’una persona. En l’ob-servacio es va veure que un percentatge elevat dels resultats que aportavenconeixement eren documents PDF. Per aquest motiu es va decidir realitzarla cerca sobre aquest tipus de documents, encara que fos mes complicat elproces de mining, ja que un PDF no es text pla com l’HTML.

109

CAPITOL 7. CONCLUSIONS 110

El problema de l’ambiguetat de noms es va resoldre a partir de l’estudidels documents PDF obtinguts. La gran majoria d’ells complien l’estandardde incloure els noms i correus electronics de la gent que havia participat en laseva elaboracio. Per tant, com un e-mail identifica a una unica persona, erauna bona manera de filtrar i solucionar aquest problema. Per altra banda,sorgia un altre problema menys important, ja que una persona pot tenir mesd’un e-mail que l’identifiqui, per tant podem estar perdent una part del seuconeixement. Pero aquest mateix problema ens el trobavem tambe amb elsnoms de persones ja que un mateix nom pot estar escrit de moltes maneres.Per exemple Pablo Ros, el podem trobar com P. Ros, Pablo R., etc. demanera que tambe perdrıem aquests resultats.

Per poder minimitzar aquesta problematica, l’usuari te la opcio d’intro-duir mes d’un correu electronic a l’hora de realitzar la cerca. Aixı, en casde tenir coneixement dels diversos e-mails de la persona, es poden afegir iobtenir els resultats complets per aquell actor.

Un altre tema interessant dins l’estudi del crawling, es la possibilitatd’escollir el motor de cerca per crear la xarxa social. Son interessants elsresultats obtinguts pels dos cercadors: Google i Yahoo, ja que en algunscasos amb el motor de cerca Google s’obtenen xarxes socials mes completes.Des d’un punt de vista extern a aquest treball, ens pot servir per veure lapresencia d’un actor dins dels cercadors mes coneguts.

El seguent pas de l’estudi consisteix en realitzar el web mining sobreels resultats obtinguts en la fase de crawling. Dos dels punts caracterısticsd’aquest Projecte Final de Carrera es la possibilitat d’expandir la xarxasocial d’un individu i l’extraccio de la seva descripcio semantica. Aquestesdues funcionalitats estan englobades dins del web mining dels documentsobtinguts. Aquesta ha estat l’area on s’ha dedicat mes temps d’investigacioi desenvolupament.

En primer lloc, l’extraccio d’e-mails dels documents ha implicat un estudiexhaustiu dels resultats ja que depen d’aquest proces la correcta expansiode la xarxa. El primer problema que vam trobar va ser la diversitat deformes d’escriure un correu electronic. Es van dissenyar diversos patronsd’extraccio de dades per tal de no perdre cap dada i poder emmagatzemar elmaxim d’informacio possible. Una vegada extrets els correus, era necessariponderar-los per poder quantificar la importancia d’un e-mail.

Obviament no te la mateixa importancia un coautor del document que une-mail en un document on el seu contingut nomes son correus electronics (perexemple un llistat d’assistents a un congres). Per tant es necessari distingiraquests tipus de rols que juguen els actors de la xarxa, marcant una serie deregles que donen mes o menys emfasi a un correu electronic.

Per tant, observant els documents veiem que moltes vegades les coautories


es troben en la mateixa lınia o en les lınies inferiors o superiors. Aixı queaquest tipus de patrons son valorats com a relacions directes mes enlla delseu posterior calcul d’afinitat.

Per altra banda els documents amb una gran densitat d’e-mails son pe-nalitzats ja que aquestes llistes d’e-mails no aporten informacio valida alnostre sistema. Potser algun d’aquests e-mails te un bon vincle amb l’actoranalitzat pero sofrira igualment la penalitzacio i podrıem perdre una relaciocorrecta. Aquesta perdua es compensada per l’eliminacio de moltes relacionsinexistents que superen el llindar d’afinitat gracies a que un dels dos actorsdisposa de pocs resultats al motor de cerca.

En l’estudi de l’extraccio de les paraules clau que descriuen un actorsemanticament, s’han anat afegint millores que han augmentat la precisiodels resultats. Es un punt important i difıcil de gestionar ja que el tracta-ment del llenguatge natural no es gens trivial. El primer que es va realitzar vaser l’extractor d’aquelles paraules mes rellevants dins d’un document. Ambaquest pas ja es va veure la necessitat de clusteritzar les dades per alguncriteri, ja que apareixien gran quantitat de plurals, sinonims i paraules deri-vades. La solucio va ser utilitzar l’algorisme de stemming per tal de poderextreure el lexema de la paraula i crear grups per lexemes sumant les sevesocurrencies. S’obtenen resultats molt optims amb aquest sistema.

Per dur a terme el stemming s’ha dissenyat un sistema de reconeixementd’idiomes que ens permet treballar al detall amb aquest document fent op-timitzacions especıfiques amb l’idioma, com l’us de llistes de stopwords queens filtren paraules innecessaries.

La creacio de relacions entre actors ha estat enfocada des de dos puntsde vista. Les relacions directes de coneixement entre actors i les relacions apartir de les keywords extretes que els defineixen.

Per les afinitats directes dels actors s’han utilitzat coeficients d’afinitatexistents que hem combinat amb les dades que ens aporta els motors de cerca.Aixı doncs a partir del numero de resultats que ens pot retornar el cercadord’un actor, de la seva relacio, i de combinacions entre ells, podem calcular laseva afinitat. En aquest proces tenim en compte les ponderacions atorgadesals e-mails i influeixen en aquest calcul, per garantir una relacio, com es elcas de la coautoria, o per penalitzar una relacio com es el cas d’un e-mailestret d’un document que conte un llistat de correus electronics.

Per la relacio entre paraules clau, hem dissenyat una formula propia apartir dels estudis i les proves realitzades al sistema. Hem pogut afinaruna formula que te en compte la similitud de keywords entre actors, la im-portancia de les keywords dins dels documents dels dos actors i per ultimla importancia de la keyword en la totalitat de la xarxa social. Aixı hemobtingut relacions de qualitat entre dos actors i ens aporten una visio molt


bona de la semantica de la xarxa social.Amb totes aquestes funcionalitats obtenim la xarxa social de l’actor o

actors analitzats. El seguent pas del nostre estudi es crear una interfıcieusable perque l’usuari pugui navegar per la xarxa. Aquest punt tambe esdifıcil d’abordar, ja que quan la xarxa creix, el volum de dades acostuma aser molt gran i no es pot mostrar per pantalla.

La solucio que proposem es segmentar la visualitzacio en diverses arees dela pantalla, per tal de deixar en primer lloc un navegador visual de la xarxad’un actor, que ens permeti moure’ns per les seves relacions d’una maneracomoda. El nuvol de tags global i local per poder veure aquelles paraules queson mes rellevants dins de la xarxa social o dins d’un actor en concret. I elpanell de control per poder fer tot allo que el navegador visual no ens permetfer. La combinacio d’aquestes tecniques enfocades sempre a la comoditat del’usuari per usar l’aplicacio.

Amb tot aixo observem un gran problema en el temps d’execucio de l’a-plicacio. Les limitacions tecnologiques ens impedeixen poder augmentar eltemps d’unes operacions que, a priori, son molt costoses. Les peticions ex-ternes de dades i la manipulacio de continguts molt grans fan que el processigui molt costos en termes de temps.

S’ha realitzat una optimitzacio a fons del sistema per tal d’obtenir tempsinferiors. L’aplicacio es concurrent aprofitant tota la potencia de proces dela maquina. S’han afegit sistemes de cache que estalvien peticions repetidesi redueixen els temps en execucions simultanies. El servidor es totalmentdedicat i preparat per l’execucio de la nostra aplicacio.

Aixı doncs, amb l’elaboracio d’aquest Projecte Final de Carrera s’hanestudiat i implementat diverses tecniques de diferents arees de investigacioi hem creat una plataforma solida per obrir una lınia d’investigacio dedi-cada a l’extraccio automatica de xarxes socials, a partir de la informacioemmagatzemada a Internet.

Capıtol 8

Lınies de futur

Aquest Projecte Final de Carrera, com ja hem comentat en altres punts,obre un gran nombre de lınies d’investigacio en les que es poden aprofun-dir per tal de millorar el sistema en cada una de les fases o moduls que elcomposa.

En aquest punt esmentarem algunes de les lınies que es podrien obrir apartir de la base teorica i practica desenvolupada en aquest Projecte. Si enscentrem en els moduls del sistema podem obrir una lınia de investigacio percadascuna d’elles.

Referent al Crawling es poden observar els resultats obtinguts per multiplescercadors fent una analisi de les respostes que ens retornen cadascun. Depe-nent dels resultats, es podrien utilitzar resultats de cercadors diferents ator-gant un pes d’importancia als resultats obtinguts a partir de les descripcionsobtingudes i la posicio dins dels resultats.

Altres investigacions podrien anar dirigides en fer un pas previ a l’analisique realitzem, per tal d’associar a un nom i cognoms un o diversos e-mailsper comencar el nostre proces d’analisi. Aixı podrıem reduir el problema dediversitat d’e-mails per persona i podrıem cercar per noms i cognoms.

Estudiar diferents formes d’interrogar els motors de cerca pot afinar elsdocuments obtinguts i millorar la creacio de la xarxa social.

Referents al modul de Web Mining, una lınia de treball interessant es lacreacio de regles i patrons que ens permetin definir rols als e-mails extrets.De tal manera que ampliem les ponderacions actuals de coautoria i de pena-litzacio per densitat i afegim relacions de treball en el mateix departament,assistencia a congressos, treballar en el mateix departament, etc. El procesd’analisi sobre un e-mail per donar-li un context aportaria molta potenciaals resultats de la xarxa.

En l’apartat de l’extraccio de keywords que defineixen els actors semanticament,podem aportar noves millores que ens permetin afinar i extreure nova infor-

113

CAPITOL 8. LINIES DE FUTUR 114

macio. Es pot estudiar l’extraccio de parells de paraules rellevants en comptesde paraules soles com es fa actualment. O extreure combinacions de paraulessoles, parelles de paraules, i tres paraules juntes mes rellevants per donar mesconsistencia a la importancia de les paraules.

Es poden investigar noves vies de clusteritzacio de les dades a partir designificats de les paraules en comptes de pel seu lexema com es fa actualment,amb la utilitzacio de diccionaris de sinonims. D’aquesta manera agruparıemsinonims i paraules similars en un mateix lloc. Tambe es pot estudiar l’analisia partir d’un parser lexicografic i sintactic que ens permetes detectar subjec-tes i predicats per tal “d’entendre” de que parla el document.

El calcul de l’afinitat, tant la directa com per keywords, es un altra areaque ens obre moltes vies d’investigacio. Variar les formules utilitzades perdefinir les relacions per tal d’observar com respon el sistema, i millorar iafinar aquells casos mes conflictius.

A nivell de la representacio de les dades a l’usuari es poden realitzar estu-dis d’usabilitat i accessibilitat per tal de garantir que el sistema es optim perl’usuari. Realitzar estudis per trobar la millor forma de presentar graficamentles xarxes socials, investigant en la possibilitat de mostrar tota la xarxa i mit-jancant zooms poder apropar-nos i allunyar-nos.

Explotar la possibilitat d’exportar les dades de la xarxa social a multiplesformats per poder realitzar analisis profunds de les estructures creades i ex-treure conclusions amb aplicacions enfocades a l’analisis de xarxes socials.

I per ultim, mes enlla dels moduls de l’aplicacio, una lınea d’investiga-cio d’optimitzacio del sistema on s’executa. Millorar els temps de respostabuscant solucions en la paral·lelitzacio de processos, nous metodes de cache,etc. Tambe provar la implementacio amb altres llenguatges de programaciocompilats per veure les millores i realitzar una API per connectar l’aplicacioamb PHP per visualitzar les dades en format HTML.

Vistes la quantitat de propostes plantejades, des d’aquest Projecte Finalde Carrera es planteja la possibilitat d’obrir una lınia d’investigacio en el de-partament d’informatica d’Enginyeria i Arquitectura La Salle, per tal de dura terme totes aquestes lınies de futur amb el temps, on es pogues col·laborari donar continuıtat a la investigacio realitzada en aquest Projecte.

Capıtol 9

Cost del Projecte Final deCarrera

En aquest punt fem una estimacio aproximada d’hores dedicades a desen-volupar aquest Projecte Final de Carrera. Esta dividit pels punts comentatsen aquesta memoria.

Taula 9.1: Estimacio d’hores dedicades

Hores estimades

Estudi i investigacio 170

Analisi de requeriments 30h

Optimitzacio del sistema 50

Disseny de l’aplicacio 40

Implementacio 270

Elaboracio de la Memoria 100

TOTAL 660

115

Bibliografia

[1] K. Bielenberg. Groups in Social Software: Utilizing Tagging to IntegrateIndividual Contexts for Social Navigation. 2005.

[2] David Crystal. Diccionario de linguıstica y fonetica. Octaedro Editorial,2000.

[3] Rafael M. Gasca Fernando de la Rosa. Extraccion automatica de redessociales.

[4] Martin Halvey and Mark T. Keane. An assessment of tag presentationtechniques. May 2007.

[5] Mehul A. Shah Henry A. Kautz, Bart Selman. The hidden web. AIMagazine, 18(2):27–36, 1997.

[6] Stefan Decker Ina O’Murchu, John G. Breslin. Online social and businessnetworking communities. DERI: Digital Entreprise Research Institute,2004.

[7] P. Jaccard. Distribution de la flore alpine dans la bassin de dranseset dans quelques regions voisines. Bulletin de la Societe Vaudoise desSciences Naturelles, 37:241–272, 1901.

[8] Frigyes Karinthy. Chains, in Everything is Different. Budapest, 1929.

[9] Christopher D. Manning and Hinrich Schutze. Foundations of StatisticalNatural Language Processing. The MIT Press, June 1999.

[10] P. Mika. Flink: Semantic web technology for the extraction and analysisof social networks. Journal of Web Semantics, 3(2), 2005.

[11] M. R. Penabad, M. L. Moreda, A. S. Places, and E. Vazquez. Algorit-mo de stemming para el gallego. Procesamiento del Lenguaje Natural,(35):153–160, 2005.

116

BIBLIOGRAFIA 117

[12] M.F. Porter. An algorithm for suffix stripping. Program, 14:130–137,1980.

[13] M.F. Porter. Snowball: A language for stemming algorithms. 1980.

[14] M. Hamasaki Y. Matsuo, J. Mori. Polyphonet: An advanced socialnetwork extraction system from the web. Porceddings of WWW2006,2006.

[15] Koiti Hasida Mitsuru Ishizuka Yutaka Matsuo, Hironori Tomobe. Fin-ding social network for trust calculation. Proc. ECAI2004, pages 510–514, 2004.

[16] Koiti Hasida Mitsuru Ishizuka Yutaka Matsuo, Hironori Tomobe. Fin-ding social network for trust calculation. In ECAI, pages 510–514, 2004.

Estudi, disseny i implementacio d’un sistema autom`atic...

Documents

Transcript of Estudi, disseny i implementacio d’un sistema autom`atic...