Prototipo di componente software interfacciabile via web service per le funzioni di profilazione utente SC5

Transcript

1 SC5 Prototipo di componente software interfacciabile via web service per le funzioni di profilazione utente Il deliverable SC5 è una relazione tecnica a corredo dei moduli sviluppati nell ambito del Task T3.3, e che si occupano di realizzare le funzioni di profilazione utente. La presente relazione tecnica descrive l implementazione di tutti i componenti software interessati: Profiler, Social Network, Recommender. 1

2 Indice generale INTRODUZIONE AL DOCUMENTO... 5 PARTE I PROFILER Introduzione Descrizione funzionalità Specifiche implementative Interazione Profiler Player Username User Login Interazione Profiler Recommender DatiProfilazione UtentiIds UtentiByProfilo Pesi UtentiByQuestionario Interazione Profiler Social Network Datisocial Interazione Profiler Sensor Network Percorso PARTE II SOCIAL NETWORK Introduzione Scenario applicativo, funzionalità ed architettura Scenario applicativo Funzioni del modulo SN Architettura Workflow tipico d interfacce di comunicazione Implementazione Architettura a tre livelli Strumenti e framework Autenticazione Motore di raccomandazioni social Specifiche dell'interfaccia REST API Introduzione Richiesta connessione social network (social login) Richiesta di informazioni sul profilo social dell'utente Richiesta di informazioni sui messaggi e preferenze dell'utente Contact/Network API User Activities API

3 4.6.1 Get user's Groups Get user's Posts Get user's Events Get user's Twitter mentions Get companies followed Get Photo Albums Get Audio Recordings Get Check-Ins Get Followed Pages Get Videos Get Photos Get Status Messages Notifica di un nuovo utente...44 PARTE III RECOMMEDER SYSTEM Introduzione Sistema di raccomandazione RS per il modulo Storytelling Authoring Contesto Organizzazione interna Modalità di interazione RS per modulo Player Contesto Organizzazione interna Fasi di funzionamento Interfaccia grafica per fornire la raccomandazione Database di supporto Personalizzazione delle raccomandazioni Modalità di interazione

4 Indice delle figure Figura Figura Figura Figura Figura Indice delle tabelle Tabella 1: Interazioni possibili tra Profiler e Player...10 Tabella 2: Interazioni possibili tra Profiler e Recommender...11 Tabella 3: Interazione tra Profiler e Social Network...12 Tabella 4: Interazioni possibili tra Profiler e Sensor Network...13 Tabella 5: Workflow, comunicazione e API modulo SN...18 Tabella 6: Richiesta connessione di un social network...23 Tabella 7: Richiesta profilo social Tabella 8: Data points del JSON globale Tabella 9: API per il recupero dei dati dai social network esterni...29 Tabella 10: JSON_CONTACT Format Tabella 11: Specifica API per iscrizione a gruppi Tabella 12: JSON_GROUP Format...31 Tabella 13: API recupero post dell'utente Tabella 14: JSON_GET_POST Format...32 Tabella 15: Api per recuper eventi in cui è coinvolto l'utente Tabella 16: JSON_EVENT Format Tabella 17: API per verificare i post in cui l'utente è menzionato Tabella 18: JSON_MENTION Format Tabella 19: API per rilevare le compagnie di cui l'utente è "follower"...35 Tabella 20: JSON_FOLLOWED_COMPAGNIE Format...35 Tabella 21: API per rilevare gli album di foto...36 Tabella 22: JSON_PHOTO_ALBUM Format...36 Tabella 23: API per rilevare formati audio...37 Tabella 24: JSON_AUDIO Format Tabella 25: Api per rilevare il check-in dell'utente...38 Tabella 26: JSON_CHECKIN Format...38 Tabella 27: API per rilevare le pagine di cui l'utente è "follower"...39 Tabella 28: JSON_FOLLOWING Format...39 Tabella 29: API per rilevare video...40 Tabella 30: JSON_VIDEO Format Tabella 31: API per rilevare foto...42 Tabella 32: JSON_PHOTO Format Tabella 33: API per rilevare i messaggi di stato...43 Tabella 34: JSON_POST_STATUS Format...43 Tabella 35: Interazione tra Recommender e gli altri moduli

5 INTRODUZIONE AL DOCUMENTO Il documento contiene la descrizione delle architetture e delle caratteristiche funzionali dei moduli software deputati alla gestione della profilazione dell utente e dell adattività del sistema alle caratteristiche dell utente stesso: il profiler, il social network e il recommender system. 5

6 PARTE I PROFILER 1 Introduzione La presente sezione descrive in dettaglio il funzionamento del modulo Profiler, lo scambio dati che avviene con gli altri moduli, sia per il tipo di dati, che per le modalità utilizzate. 6

7 2 Descrizione funzionalità Il Profiler è il sotto-sistema deputato alla gestione dei dati degli utenti del sistema, permettendo l accesso agli stessi da parte di tutti gli altri sottosistemi che fanno parte dell architettura generale del progetto. Esso assume, dunque, una posizione piuttosto centrale all interno dell architettura complessiva del sistema. Vista la notevole complessità dell architettura del progetto, si è pensato di realizzare un'architettura modulare, divisa per sottosistema interrogante. In particolare sono state realizzate delle interfacce che permettono di fornire i servizi necessari ai seguenti moduli: Player; Recommender; Social Network; Sensor Network. Ogni modulo è completamente indipendente dagli altri e offre i webservice richiesti dal particolare sottosistema. Nello specifico, la natura delle interazioni tra i moduli è la seguente: Player Questo è il modulo in cui vengono creati i dati iniziali di profilazione, la componente anagrafica e quella delle preferenze di fruizione dell utente. Tali dati vengono, quindi, inviati al Profiler, che li rende disponibili per tutti gli altri sottosistemi dell architettura. Nel caso in cui l'utente non abbia inserito dati anagrafici, il Profiler provvede a creare un utente fittizio, al fine di individuare il contesto di visita dell'utente. Al termine della procedura di attivazione, il Profiler comunica al dispositivo un identificativo univoco che verrà utilizzato dal dispositivo stesso nelle successive comunicazioni. Recommender Il Recommender ottiene dal Profiler tutte le informazioni sull utente registrato nel sistema NeoLuoghi, in modo da poter selezionare i contenuti aggiuntivi da proporre in base alle preferenze, sia quelle estrapolate dal comportamento assunto durante la visita all interno del parco tematico, sia quelle chiaramente espresse attraverso l interazione con gli altri moduli. Social Network 7

8 Il modulo di social networking memorizza nel Profiler informazioni estratte da social network esterni al sistema Neoluoghi, con lo scopo di avere un corpus informativo che possa aiutare a definire le caratteristiche degli utenti. Sensor Network Il modulo Sensor Network è deputato alla gestione e all analisi delle informazioni rilevate durante la fruizione dell esperienza. Esso invio al Profiler informazioni sui percorsi fruiti dai vari utenti. 8

9 3 Specifiche implementative Il Profiler è stato realizzato in linguaggio PHP e si avvale di un database relazionale MySQL per lo storage dei dati dei profili. Per fornire degli url uniformi e semplici da interpretare, si è utilizzato il servizio di url rewrite di Apache, unitamente a un router in php che, dopo alcuni sanity check, smista le chiamate al modulo opportuno. In questo modo si è mantenuta un'architettura aperta per eventuali aggiunte o modifiche future. Per ogni modulo si è realizzata una pagina HTML per consentire ai partner di testare i webservice tramite un comune browser web, utilizzando dei form parzialmente compilati. In questo modo si fornisce agli sviluppatori un'interfaccia di rapido utilizzo per prendere confidenza col sistema Profiler stesso. Lo storage dei dati avviene in larga parte tramite il formato json, per lasciare libertà di azione ai partner che vogliano aggiungere caratteristiche non previste (entro precisi limiti) ai profili utente. Per semplificare ulteriormente il lavoro di integrazione ai partner è stata prevista una modalità debug, che nel caso le chiamate rilevino un errore, fornisce un messaggio testo chiaro sul motivo dello stesso. Il profiler espone una serie di web service REST tramite i quali è possibile accedere alle risorse da esso gestite: le operazioni che si possono eseguire su tali risorse sono http get, che consente di ottenere una risorsa, e http post, che consente di creare una nuova risorsa. È Rispettando i principi dell approccio restfull, sono state adottate le seguenti convenzioni: È preferito l utilizzo di nomi a quello dei verbi negli URI per accedere alle risorse, ad esempio si utilizza e non ; Si utilizzano i codici di stato http per restituire l esito dell operazione o in caso di errore, in particolare: o o o Nel caso di un errore interno del sistema (come ad esempio timeout sulla connessione al database) sarà restituito il codice di stato http 500 (Internal server error); Nel caso di chiamate post per creare una nuova risorsa verrà restituito il codice http 200 nel caso in cui l operazione sia andata a buon fine; Nel caso di chiamate get per ottenere una risorsa sarà restituito il codice di stato http 404 nel caso in cui la risorsa non esista; 9

10 o o o Nel caso di chiamate get o post in cui si verifica un errore dovuto al formato sbagliato dei dati in input sarà restituito il codice di stato http 400; Nel caso sia utilizzato un metodo che non sia get o post allora viene restituito il codice di stato http 405 (method not allowed); In caso di problemi nell'accesso alla risorsa richiesta, ovvero un codice diverso da 200, nel corpo della risposta http è presente un breve messaggio sull'errore riscontrato che aiuta il debug. Per comodità ed uniformità è utilizzato il formato json sia per i dati in input che per i dati in output. Le risorse accessibili tramite POST prevedono che il nome del parametro in input sia uguale al nome della risorsa richiesta (contenuto nell url): ad esempio la risorsa username richiede un parametro POST di nome username, contenente una stringa JSON con tutti i dati necessari. Nel sorgente delle pagine HTML di test (il cui url è riportato nel testo che segue ogni componente dell'architettura) si può osservare il nome dei parametri corrispondente alla risorsa richiesta. Nello specifico, sono stati realizzati i servizi descritti nelle sotto-sezioni seguenti. 3.1 Interazione Profiler Player Il profiler espone tre risorse username, user, login cui il player può accedere come illustrato nella seguente tabella che riassume l insieme delle operazioni possibili: Tabella 1: Interazioni possibili tra Profiler e Player URI Get Post Put Delete /Luserna X /user X /login X Username Il player accede alla risorsa username per verificare se la username passata in input sia già presente sul server. Il player passa in input un json contenente la username, di cui intende controllare l esistenza, e riceve in output un json contenente la username ricevuta e l esito del controllo: true se non esiste sul server, false altrimenti. 10

11 3.1.2 User NeoLuoghi - Soluzioni per l esperienza culturale nei luoghi elettivi della surmodernità Il player crea una nuova risorsa user utilizzando il metodo http post, passando tutti i dati di registrazione in formato json ed in risposta riceve un json contenente l id del nuovo utente creato. Se il campo credenziali contiene il parametro username vuoto (stringa vuota), allora lo username viene generato automaticamente come stringa casuale Login Il player accede alla risorsa login per autenticarsi al sistema o meglio per controllare se le credenziali passate in input siano valide e per recuperare i dati dello user. Il player passa in input un json contenente la username e la password e riceve in output un json contenente i dati di registrazione dell utente ed il codice http 200(successo) se l operazione è andata a buon fine altrimenti il codice http 401 se l utente non è autenticato. 3.2 Interazione Profiler Recommender Il profiler espone la risorsa datiprofilazione cui il modulo Recommender può accedere come illustrato nella seguente tabella che riassume l insieme delle operazioni possibili: Tabella 2: Interazioni possibili tra Profiler e Recommender URI Get Post Put Delete /datiprofilazione X /utentiids X /utentibyprofilo X /pesi X X / utentibyquestionario X DatiProfilazione Il modulo Recommender recupera la risorsa datiprofilazione utilizzando il metodo http get. Tale metodo restituisce tutti i dati che caratterizzano l utente. 11

12 3.2.2 UtentiIds Il modulo Recommender recupera tutti gli identificativi utente utilizzando il metodo http GET UtentiByProfilo Il modulo Recommender recupera la risorsa utentibyprofilo utilizzando il metodo http GET. L uri cui accedere contiene anche il profilo specifico per cui recuperare la lista di utenti. Il profilo richiesto tramite l'uri deve essere uno tra studente, adulto, adulto esperto Pesi Il metodo pesi, con cui personalizzare la generazione delle raccomandazioni per ogni utente secondo il feedback espresso in merito alle precedenti raccomandazioni, del Recommender consente di leggere e scrivere la risorsa pesi associata a ogni profilo utente, tramite i metodi HTTP GET e POST UtentiByQuestionario Il metodo utentibyquestionario consente di ottenere la lista di id utente in base all'esito del questionario (profili Verticale, Misto, Orizzontale, vuoto). L uri cui accedere contiene anche l esito del questionario con cui filtrare gli utenti. 3.3 Interazione Profiler Social Network Il profiler espone due risorse datisocial, credenzialisocial, cui il modulo Social Network può accedere come illustrato nella seguente tabella che riassume l insieme delle operazioni possibili: Tabella 3: Interazione tra Profiler e Social Network URI Get Post Put Delete /datisocial X Datisocial Il modulo social network crea una nuova risorsa datisocial utilizzando il metodo http post, passando i dati estratti dai social in formato json. L uri contiene anche l id dello user per il quale creare la risorsa datisocial. 12

13 3.4 Interazione Profiler Sensor Network Il profiler espone la risorsa percorso cui il modulo Sensor network può accedere come illustrato nella seguente tabella che riassume l insieme delle operazioni possibili: Tabella 4: Interazioni possibili tra Profiler e Sensor Network URI Get Post Put Delete /percorso X Percorso Il modulo Sensor Network crea una nuova risorsa percorso utilizzando il metodo http post, passando i dati del percorso da salvare in formato JSON. L URI cui accedere contiene anche l id dello user per il quale salvare il nuovo percorso. 13

14 PARTE II SOCIAL NETWORK 1 Introduzione Non puoi evitare la riprogettazione. È una parte naturale della progettazione. Eberhardt Rechtin Definire un architettura per il sistema NeoLuoghi, in conformità con l approccio Unified Process (UP) adottato per lo sviluppo del software del progetto NeoLuoghi, significa definirne: 1. Il contesto in cui il sistema si colloca (catturato e descritto negli scenari d uso di NL); 2. L organizzazione interna del sistema, identificandone i componenti principali e relative specifiche funzionalità, concentrandosi sulla visione d insieme del sistema e astraendo dai dettagli implementativi del componente (black box); 3. Le modalità con le quali i componenti del sistema interagiscono tra di loro per fornire le funzionalità complessive (i casi d uso) del sistema; 4. Le tecnologie software usate per l implementazione dei componenti; 5. Le risorse hardware utilizzate per l esecuzione. L architettura costituisce il fondamento tecnico del progetto; il consolidamento dell architettura avviene solo quando si è certi (tipicamente, tramite sperimentazioni) della sua fattibilità tecnica. L architettura dunque evolve durante lo sviluppo del sistema, per cui il processo di definizione dell architettura è tipicamente evolutivo e iterativo. Le attività di definizione dell architettura iniziano con una definizione ad alto livello dell organizzazione del sistema stesso (vista architettura di alto livello), che, partendo da quanto già realizzato per il punto (i) si focalizza sui punti (ii) e (iii) del processo di sviluppo. A tale scopo, si parte dalla definizione dei principali casi d uso, passando poi alla identificazione delle funzioni principali del componente o modulo di Social Network (nel seguito modulo SN) e le interazioni previste tra questo e gli altri componenti del sistema. Nel presente documento vengono affrontati in dettaglio gli ultimi due aspetti sopra elencati, riferibili ad attività di implementazione, ed accennati brevemente i primi tre aspetti, attinenti alla progettazione. Maggiori dettagli riguardo alla descrizione dei punti (i), (ii) e (iii) sono forniti nel deliverable D3.3, Relazione su modelli di riferimento e specifiche architetturali e funzionali di soluzioni di interazione sociale peer-to-peer per la fruizione emozionale dei Neo- Luoghi. 14

15 2 Scenario applicativo, funzionalità ed architettura 2.1 Scenario applicativo Il modulo SN è un applicazione software realizzata nella forma di un server 1 che implementa il Social Network di NeoLuoghi, un SN turistico geolocalizzato. Il modulo SN registra il comportamento del visitatore durante la fruizione del NeoLuogo ed elabora semplici raccomandazioni inerenti le attività degli utenti sul SN. Inoltre, colloquia con i più comuni SN di terze parti (ad es. Foursquare, Twitter, Tripadvisor, etc.) per i quali l utente visitatore concede esplicitamente l'accesso, estraendone le informazioni necessarie al completamento del profilo utente, nonché eventuali raccomandazioni, se rilevanti. L utente finale impiega il tablet, su cui opera l applicazione Player, per interagire con la SN, ad esempio per dare un like ad un contenuto. Poi il Player notifica questo evento al modulo SN che gestisce appunto la SN di NeoLuoghi (oltre a fare crawling sui SN terzi per ottenere il profilo social dell utente). Quindi l interazione con il tablet da parte del modulo SN è indiretta. 2.2 Funzioni del modulo SN Il modulo SN ha il compito di: 1. Realizzare e gestire il Social Network di NeoLuoghi, un SN turistico geolocalizzato (simile a Foursquare/Swarm) che permette all utente di accedere durante il percorso narrativo anche a momenti di interazione sociale, così come di gioco competitivo, possibilità di postare foto, commenti e di individuare persone con cui incontrarsi durante l esperienza, 2. Raccogliere i dati sui comportamenti ed attività dell utente nei Social Network (dati social, necessari alla definizione delle raccomandazioni), sia dalla SN di NeoLuoghi che dai principali Social Network di terze parti (ad es. Foursquare, Twitter, Tripadvisor, recuperati tramite rispettive API o tramite aggregatori di Social Network, come gnip, LoginRadius o Hootsuite). 3. Normalizzare i dati social, che hanno formati e significati diversi, ed inviarli al sistema che gestisce e mantiene il profilo utente, Profiler, dove potranno in seguito essere prelevati dal Recommender ed usati come tracce di input per la definizione delle raccomandazioni principali (raccomandazioni pure). 4. Elaborare semplici raccomandazioni inerenti le attività degli utente sui SN (raccomandazioni social) ed inviarle al modulo UI Storytelling Player (trovare persone vicine/affini per incontri e condivisione; trovare attività comuni di interesse, come la presenza di un evento/gioco nella zona). 5. Raccogliere le raccomandazioni provenienti da Social Network esterni ed inoltrarle al modulo UI Storytelling Player che le visualizza opportunamente (ad es. tramite lista scorrevole laterale non intrusiva) ed eventualmente cercando di collegarle al POI / 1 Il modulo SN è precisamente un web engine (un web server che espone dei servizi tramite API). 15

16 percorso che l'utente sta visitando). Il modulo SN ha il compito di elaborare semplici raccomandazioni inerenti le attività degli utente sui SN (raccomandazioni social) ed inviarle al modulo UI Storytelling Player. Queste raccomandazioni hanno l obiettivo di trovare persone vicine/affini per condivisione dei contenuti della visita e di trovare attività di interesse comune, come la presenza di un evento nella zona del parco gestito da NeoLuoghi. L algoritmo di raccomandazione social parte dall analisi del profilo social di un utente (cioè dall insieme dei data points, o campi di record, di tutti i social network che sono stati collegati dall utente stesso in fase di registrazione a NeoLuoghi). Tramite query avanzate si estraggono un insieme di parole chiave, o tag, che sintetizzano il profilo social. Ai tag sono associati dei pesi che tentano di stimare la rilevanza dei tag identificati. In sintesi, possiamo identificare una funzione f SN che associa al testo non strutturato estratto dai SN esterni un insieme di parole chiave, o tag, ad ognuna delle quali è associato un valore [0,1] che ne rappresenta il peso (rilevanza). f SN : testo > tag (parole chiave nel testo), peso (rilevanza) A livello di architettura del sistema, per ottimizzare le comunicazioni tra i vari moduli e le interfacce, sono state effettuate le seguenti scelte implementative: Le raccomandazioni social ed i messaggi (ad esempio post, like, commenti 2 ) dai social network (sia esterni che di NeoLuoghi) vengono inviate al modulo Recommender opportunamente formattati. Il modulo Recommeder provvederà poi ad inoltrare questi messaggi al modulo Player (mobile app che lavora sul Tablet), che le visualizzerà in una opportuna sezione della interfaccia utente; Il modulo Player invia al modulo SN tutti i messaggi (ad es. i post inviati dall utente) e le richieste relativi ai SN (interno NL ed esterni); Le risposte dai SN (ad es. i commenti o i post destinati all utente) sono inviate dal Player al modulo Recommender. 2.3 Architettura Il modulo SN interagisce con i seguenti componenti di NeoLuoghi ed esterni: Social Network esterni a NeoLuoghi, ricevendone dati social utili alla comprensione dei comportamenti dell utente e quindi al completamento del profilo; Componente Profiler, al quale l utente invia i dati social raccolti, per completare ed affinare il profilo utente con questo aspetto 3 ; 2 Inclusi i post/like provenienti da SN esterni e relativi al tema NeoLuoghi (menzione di NeoLuoghi, eventualmente anche menzione di POI, titoli dei contenuti di NL). 3 Una parte del profilo utente sarà caratterizzato da aspetti social, sia provenienti da fonti esterne (altri social network, sezioni social di sistemi esterni non social, es. amazon) sia rilevati dal modulo SN stesso (social network di NL locale agli utenti del NeoLuogo, raccomandazioni fatte, post etc). A completare la descrizione, nel profilo utente ci saranno ovviamente altri dati, ed in particolare dati dinamici raccolti dal 16

17 componente Recommender, al quale il modulo SN invia le raccomandazioni social internamente definite o ricevute da SN esterni, componente UI Storytelling Player, con il quale c è una interazione bidirezionale: (a) a questo componente vengono inviati, su richiesta, i dati relativi alle raccomandazioni social, e (b) si raccolgono da questo i dati relativi ai comportamenti dell utente durante la visita riferibili agli aspetti di social interaction (il player invia al modulo SN tutte le richieste relative ai SN (ad es. post, messaggi e notifiche, sia su SN interno di NeoLuoghi che su SN esterni). componente Sensor Network, per la ricezione della posizione dell utente (coordinate geografiche e timestamp). Il modulo SN è composto dai seguenti sotto-componenti: gestore del Social Network di NeoLuoghi, attraverso la realizzazione di una rete sociale georeferenziata, nella quale gioca un ruolo centrale l informazione sulla posizione geografica dell utente, dei suoi pari e dei POI. I Geo Social Network, o reti sociali georeferenziate, possono essere sinteticamente definiti come location-based social services, sistema di raccomandazioni social, che fornisce semplici raccomandazioni relative ai SN, partendo dalla posizione geografica dell utente, sulla base di semplici criteri di similarità. Le raccomandazioni potranno essere fornite nella forma di utenti "vicini" (posizionati in un raggio predefinito rispetto all utente che riceve la raccomandazione) e di lista di POI visitati o valutati come preferiti (liked, recensiti con voto alto, ecc.) da utenti "affini" (cioè con interessi simili). SN crawler, cha ha il compito di recuperare i dati disponibili dai SN esterni per i quali l'utente si è connesso 4, normalizzarli e renderli disponibili in un formato universale al Profiler. 2.4 Workflow tipico d interfacce di comunicazione La tabella seguente schematizza le interazioni tra modulo SN ed altri sistemi (in particolare i sottosistemi di NeoLuoghi), partendo dal workflow generale definito in fase di analisi per la fase di fruizione del sistema NeoLuoghi. UI Storytelling Player, come la posizione geografica, gli interessi dimostrati, le preferenze, i percorsi, l'interazione con i POI dei neoluoghi. 4 Da Foursquare si possono ottenere informazioni georeferenziate e quindi, per il nostro obiettivo, più adatte perchè facilmente collegabili ai POI. Stesso discorso vale (indirettamente) anche per Tripadvisor. Per gli altri SN le informazioni recuperabili attraverso le varie API sono eterogenee in formato e significato. 17

18 Tabella 5: Workflow, comunicazione e API modulo SN Workflow modulo Social Network per NeoLuoghi Step Attore Azioni Dati scambiati API crea user ID NL Registrazione Player social login (connessione account SN esterno), tramite link a modulo SN. Serve anche come notifica al modulo SN di un nuovo utente di NeoLuoghi. Il modulo SN genera un token per lo specifico SN (Facebook, Twitter, Foursquare) user ID NL API social login modulo SN: /loginform?userid=xxx UserId è l'id utente NeoLuoghi base URL: neoapi.rigel.li.it UserId per i test : 10 invia al Profiler dati registrazione user ID NL nessuna interazione con modulo SN Profiler riceve dati registrazione da Player nessuna interazione con modulo SN verifica notifiche nuovi utenti (polling 3 secondi) Creazione profilo utente modulo SN crawling su SN esterni (polling 10 secondi) per recupero e aggiornamento dati social invia a Profiler i dati del profilo social profilo social (formato JSON) API Profiler fornisce accesso ai dati del profilo social di un utente (nessuna interazione prevista al momento con altri componenti di NeoLuoghi) profilo social (JSON) profilo singolo SN (JSON) API modulo SN /sn/profile/snall?userid={userid} /sn/profile/sn/{social}?userid={userid} Definisce le raccomandazione social sulla base di algoritmi interni e di notifiche da SN esterni Definizione e invio Raccomandazioni social modulo SN invia a Recommender le raccomandazioni social (incluse quelle relative a SN di Neo- Luoghi), che il R. girerà al Player riceve da Recommender il feedback su una raccomandazione short test, priorità, timestamp feedback API modulo SN /reco/show/stand? userid={userid}&limit={limit} {limit}=numero di raccomandazioni, opz API modulo SN /reco/save/feed? userid={userid}&recoid={recoid}&feed={f eed} {recoid}=id della raccomandazione {feed}=valore del feedback: 0 o 1 Gestione amministrativa: invio messaggi e post, notifiche eventi. Gestione SN di NeoLuoghi modulo SN Invia e riceve poste e messaggi da/tra utenti delal SN di NeoLuoghi tipo, msg, timestamp, posizione utente (Tipo = post, like, evento, ) API modulo SN neoapi.rigel.li.it/snnl/get? userid={userid} msg={msg}&userid={userid}&type={type }&name={name} {userid}=numero utente neoluoghi {type}=tipo di messagio, {name}=nome utente che ha inviato il msg Definisce le raccomandazioni social specifiche sulla base del comportamento utente in NL (localizzazione geografica) Chiede alla Sensor Network la posizione utente timestamp, lat, lon API Sensor Network 18

19 3 Implementazione 3.1 Architettura a tre livelli Il modulo SN è realizzato nella forma di un web server, adottando anche per questo un architettura a tre livelli (three-tier). Questa scelta porta con sé tutti i vantaggi legati alla modularità del software, in cui ogni singolo modulo svolge solo alcune operazioni ed è perciò più semplice e mantenibile. Inoltre possedendo interfacce ben definite tra un modulo e l altro permette di poter aggiornare o sostituire uno qualsiasi dei livelli in seguito a necessità di aggiornamento, cambiamenti tecnologici o cambiamento dei requisiti. Descriviamo brevemente ogni singolo livello: Livello Presentazione: è l insieme delle applicazioni dedicate alla visualizzazione delle informazioni ed alla interazione con l utente o altri sistemi esterni, ed è cliente della Business Logic, o livello Business. Le principali interazioni tra il modulo di SN ed il mondo esterno avviene tramite comunicazioni con gli altri componenti del sistema NeoLuoghi, implementate con invocazioni di API a Livello Dati. Verrà comunque realizzata una minima User Interface basata su web allo scopo di fornire all operatore umano la possibilità di accedere a funzioni base di gestione, tuning, monitoraggio e statistiche di uso del componente. Livello Business: ospita la Business Logic, realizzata dall insieme dei moduli integrati nell application server. A questo livello sono svolte tutte le operazioni specifiche del modulo SN, inclusa la generazione dei contenuti dinamici che verranno spediti dal web server. Questa componente dunque riceve le richieste, le elabora, accede ai database se necessario, e presenta i risultati. E cliente del modulo di persistenza dei dati. Livello Dati (persistenza dati): prevede un database per la persistenza dei dati locali necessari al funzionamento della Business Logic, e fornisce un interfaccia al Business Layer. E utile separare la gestione dei dati dalla logica dell applicazione al fine di essere indipendenti dal formato di memorizzazione e potersi anche avvalere di più di un database, (nel caso in cui sia necessario l accesso ad informazioni esterne al server locale) senza modifiche al lato applicazione. 3.2 Strumenti e framework Ad un livello di dettaglio di progettazione ancora maggiore, si possono identificare le tecnologie impiegate per l implementazione dei sotto-componenti del modulo SN, risolvendo il punto (iv) del processo di definizione dell architettura descritto all inizio di questa sezione. In particolare, si impiegherà la diffusa piattaforma XAMP (OSX, Apache, MySQL e PHP) che costituisce un valido ambiente di sviluppo per applicazioni server web, basata sul sistema operativo di Apple, il web server open source Apache, con licenza impiegabile anche in ambito commerciale, il diffusissimo database relazionale open source MySQL ed il linguaggio di scripting lato server PHP, nella versione PHP5 con supporto JSON, che verrà impiegato per l implementazione della business logic. 19

20 Per rendere più efficiente lo sviluppo software della business logic verranno inoltre impiegati gli strumenti di sviluppo web Symfony. Symfony è un è un leggero ma potente web framework (insieme di strumenti) per lo sviluppo di applicazioni web creato nativamente per PHP. È rilasciato sotto licenza MIT, dunque open source, e il suo scopo è quello di aiutare gli sviluppatori web a creare potenti applicazioni in breve tempo. Permette uno sviluppo agile per realizzare web application complesse e ricche di funzioni, che fanno uso intensivo di comunicazioni con dati contenuti in database relazionali e non. Basato sull'architettura MVC, ha il supporto per sviluppare in AJAX ed è in fortissima crescita di utenti sviluppatori, quindi sono disponibili manuali tecnici, numerosi esempi e tutorial ed una vasta casistica di problematiche affrontate dalla vasta comunità di utenti, caratteristiche che consentono di essere molto efficienti nonostante la complessità intrinseca e la potenza dello strumento. Tra le caratteristiche più interessanti di Symfony vi sono: Representational State Transfer (REST) per i web services; Supporto per i principali database (MySQL, Oracle, MS SQL Server, PostgreSQL, nosql); Linguaggio di scripting server side Open-source. Symfony si propone di accelerare la creazione e la manutenzione di applicazioni web e di sostituire attività di codifica ripetitive. Symfony ha un basso overhead prestazioni quando utilizzato con una cache bytecode. Fornisce agli sviluppatori il pieno controllo della configurazione: dalla struttura di directory per le librerie di terzi, quasi tutto pu ò essere personalizzato. Per far corrispondere le linee guida di sviluppo delle imprese, Symfony è distribuito con strumenti aggiuntivi per aiutare gli sviluppatori nelle fasi di debug e documentazione. Symfony è fortemente ispirato ad altri framework come Ruby On Rails, Django, e Spring. Fa uso di progetti PHP open source esistenti come parte del framework, tra cui: Propel o Doctrine come layer Object Relational Mapping; PDO, layer di astrazione del database; PHPUnit, un framework per unit test; Twig, un motore di template; Swift Mailer, una libreria . Symfony si avvale anche di propri componenti: Symfony YAML, un parser YAML basata su Spyc, Symfony Event Dispatcher, Symfony Dependence Injector Symfony Templating (un motore di template)- Utilizzando plugin, Symfony è in grado di supportare framework JavaScript e molti altri progetti PHP, come ad esempio: Prototype o jquery, come framework JavaScript; 20

21 Script.aculo.us, per gli effetti visivi; Lessphp, un convertitore CSS; TinyMCE o CKEditor, per Rich Text Editing; TCPDF, una libreria PHP per la generazione di documenti PDF. 3.3 Autenticazione Infine, il meccanismo di sicurezza è implementato tramite autenticazione OAuth 2.0. OAuth è un protocollo aperto, sviluppato da Blaine Cook e Chris Messina a partire dal novembre Tale protocollo permette l'autorizzazione di API di sicurezza con un metodo standard e semplice sia per applicazioni portatili che per pc fisso e web. Per gli sviluppatori di applicazioni è un metodo per pubblicare e interagire con dati protetti. OAuth garantisce ai service provider l'accesso da parte di terzi ai dati degli utenti, proteggendo contemporaneamente le loro credenziali. In altre parole, permette all'utente di dare l'accesso alle sue informazioni presenti, ad esempio, su un sito detto service provider, ad un altro sito, chiamato consumer, senza però condividere la sua identità. 3.4 Motore di raccomandazioni social Abbiamo usato MongoDB come repository di contenuti, per la sua velocità nella memorizzazione dei dati e il supporto per il formato JSON, un formato standard aperto basato su Javascript utilizzato per lo scambio di dati tra applicazioni e servizi Web distribuiti, ampiamente utilizzati da API SN e aggregatori SN. MongoDB è un Database NoSQL orientato ai documenti. MongoDB memorizza i dati non in tabelle come un database relazionale, ma in documenti BSON, una versione binaria di JSON e molto simile alla struttura dell'oggetto. L'utilizzo di MongoDB rende più semplice e veloce l'implementazione. Inoltre, abbiamo utilizzato ElasticSearch per interrogare MongoDB, dal momento che è molto efficace per ricerca di database grandi e complessi, sempre con il supporto JSON. Elasticsearch si presta molto bene ad una varietà di modi interessanti per elaborare la grande quantità di contenuti nei social media. Molti motori di raccomandazione utilizzano Apache Mahout, ma abbiamo preferito ElasticSearch per un sostegno più generale dei dati delle query, mentre Mahout è specializzata sui dati del profilo utente (ad esempio Mahout è in grado di raccomandare gli articoli in base alle preferenze dell'utente). Inoltre, ElasticSearch è dedicato ed ottimizzato per query di dati, ed è un complemento perfetto per MongoDB. Elasticsearch è un search server basato su Java e su Lucene. Esso fornisce un motore di ricerca full-text distribuito con capacità multi-tenant 5 con un'interfaccia web RESTful 5 Si riferisce ad una architettura software in cui una singola istanza del suddetto software gira su un 21

22 e documenti JSON senza schema. Fornisce ricerca scalabile e ricerca quasi tempo reale. Elasticsearch supporta applicazioni distribuite data-intensive e implementa un paradigma computazionale chiamato MapReduce (tramite il plugin Taste di GroupLens). Il plugin Taste per ElasticSearch è basato sull implementazione del filter collaborativo Mahout Taste, e fornisce le seguenti caratteristiche: 1. Gestione dei dati per gli utenti / items / Preferences; 2. Raccomandazione item-based; 3. Raccomandazione basata sull'utente; 4. Utenti / contenuti simili; 5. Analisi del testo. server ed è utilizzata da più di una client organization (tenant). La multi-tenancy rappresenta il concetto opposto all'architettura multi-istanza, nella quale separate istanze del software sono dedicate alle client organization. In un'architettura multi tenant, un'applicazione software è progettata per partizionare virtualmente i suoi dati e la sua configurazione in modo che ogni client lavori con un'istanza virtuale personalizzata. 22

23 4 Specifiche dell'interfaccia REST API 4.1 Introduzione In questa sezione sono documentati i servizi che il modulo SN mette a disposizione attraverso REST API per recuperare i dati social di un utente di NeoLuoghi. Tutti i servizi documentati sono installati sulla macchina di produzione (utilizzata inizialmente come test) raggiungibile via internet attraverso l indirizzo Richiesta connessione social network (social login) Per connettere un utente attraverso un suo account social network esistente, è necessario chiedere un token attraverso il modulo SN. Ogni Social Network ha un token specifico. Quindi per avere per esempio accesso a Twitter e Facebook per un utente saranno necessari due token (quindi 2 richieste di token). Nella tabella seguente è riportata la descrizione di una richiesta di token. Tabella 6: Richiesta connessione di un social network. Step Dettagli API Url input Richiesta di connessione di un social network (social login) L API mette a disposizione un url che genera il form html di associazione di un account social (template di login). il template è generato direttamente e propone tutti i social. /neoluoghi/loginform/?iduser=val1&callbackurl=val2 val1: è il valore del iduser per neoluoghi val2 è l url di ritorno per mandare dopo il login l utente con le informazioni social. (puo essere per esempio una pagina di thankyou) output Se l utente accetta di fare il login, l utente è reindirizzato verso l url di callback con credenziali del social network: callbackurl?iduser={val1}&token={val2}&provider={val3} {val1}: id del l'utente NeoLuoghi {val2}: valore del token per un provider specifico (credential) {val3}: tipo di social dove l utente ha fatto la registrazione per esempio facebook, twitter La figura seguente mostra un esempio di interfaccia per il social login. 23

24 Figura 1: Esempio di implementazione della richiesta di social login. Le API per richiedere dati social sono divise in due categorie, contraddistinte dai seguenti URI: neoapi.rigel.li.it/sn/profile/ e neoapi.rigel.li.it/sn/preference/. Le API di tipo /profile/ restituicono le informazioni relative all'utente ed il suo profilo social per tutti i network per i quali ha consentito l accesso (con il social login). Le API di tipo /preference/ restituiscono tutte le informazioni relative ai contenuti o post o preferenze di un utente per ogni Social Network per il quale in fase di registrazione in NeoLuoghi ha consentito la condivisione. 24

25 4.3 Richiesta di informazioni sul profilo social dell'utente Il profilo esteso (extended profile data) contiene numerose ed utili informazioni sul profilo dell utente in uno specifico social network, come i principali interessi dichiarati, la formazione, le posizioni ricoperte, etc. (nella tabella seguente sono contenuti tutti i data points accessibili). La API /profile/ restituisce il profilo dell utente per tutti i Social Network. La risposta contiene un JSON globale composto di un elemento JSON per ogni Social Network registrato. Tabella 7: Richiesta profilo social. API Endpoint Request Type Input Parameters Error Codes Response neoapi.rigel.li.it/sn/profile/{social}?iduser={iduser} Http Get Request IdUser (value of iduser) SOCIAL (value of the social to retrieve information, for example FACEBOOK or ALL) 403 Forbidden : Your Access Token is invalid 401 unauthorized : Your account does not have permission JSON_{SOCIAL} the value of social is facebook or twitter or all Tabella 8: Data points del JSON globale. Name Type Description ID String Social ID of the user Provider String Social ID Provider of the user Prefix String Prefix of the user FirstName String First Name of the user MiddleName String Middle Name of the user LastName String Last Name of the user Suffix String Suffix of the user FullName String Full Name of the user 25

26 NickName String Nick Name of the user ProfileName String Profile Name of the user BirthDate String Birthdate of the user Gender String Gender of the user Website String Website of the user ->Type String type ->Value String of the user Country String Country of the user ThumbnailImageUrl String Thumbnail Image Url of the user social avatar ImageUrl String Image Url of the user Favicon String Favicon of the user ProfileUrl String Profile Url of the user HomeTown String Home Town of the user State String State of the user City String City of the user Industry String Industry of the user About String Bio of the user TimeZone String Timezone of the user LocalLanguage String LocalLanguage of the user Verified String Verified status of the user UpdatedTime String Updated time of the user Positions Array Job positions of the user Educations Array Education details of the user Language String Language of the user PhoneNumbers Array Phone Numbers of the user IMAccounts Array IM Account usernames of the user Addresses Array Addresses of the user 26

27 MainAddress String MainAddress of the user Created String Date of creation of the user account LocalCity String LocalCity of the user ProfileCity String ProfileCity of the user LocalCountry String LocalCountry of the user ProfileCountry String ProfileCountry of the user RelationshipStatus String RelationshipStatus of the user Quota String Quote of the user InterestedIn String InterestedIn of the user Interests Array Interests of the user Religion String Religion of the user Political String Political Views of the user Sports Array Sports of the user InspirationalPeople Array InspirationalPeople of the user HttpsImageUrl String HttpsImageUrl of the user FollowersCount Integer Followers Count of the user FriendsCount Integer Friends Count of the user TotalStatusesCount Integer Total Statuses Count of the user Associations NumRecommenders Honors Skills String Integer String Array A short-form textarea enumerating the Associations a member has The number of recommendations the member has A short-form text area describing what Honors the member may have Individual skills are structured objects returned as part of profile. 27

28 CurrentStatus String the member's current status, if set the timestamp, in milliseconds, when the member's status was last set Certifications Array Individual certifications are structured objects returned as part of profile Courses Array Course entities of the user Volunteer String Volunteer entities of the user Array Recommendations received by the user Languages Array Languages of the user Hireable Bool Mention user is Hireable or not Age Integer Age of the user Patents String Patents information of the user FavoriteThings String Favorite things of the user ProfessionalHeadline String Professional Headline of the user RecommendationsReceived ProviderAccessCredential Object Provider Access token 4.4 Richiesta di informazioni sui messaggi e preferenze dell'utente La API preferencemessage mette a disposizione 12 tipi di dati valorizzati con la stessa struttura per tutti i Social Network per ogni iduser. La struttura non è sempre valorizzata e dipende dalle credenziali fornite dagli utenti per ogni Social Network. La struttura globale della chiamata é della risposta API /preferencemessage è definita più sotto. Il JSON di risposta è GLOBAL_JSON_PREFERENCE_MESSAGE. Lista delle API di tipo preference: neoapi.rigel.li.it/sn/preference/contact/ neoapi.rigel.li.it/sn/preference/group/ neoapi.rigel.li.it/sn/preference/getpost/ neoapi.rigel.li.it/sn/preference/event 28

29 neoapi.rigel.li.it/sn/preference/mention/ neoapi.rigel.li.it/sn/preference/followedcompanie/ neoapi.rigel.li.it/sn/preference/photoalbum/ neoapi.rigel.li.it/sn/preference/audio/ neoapi.rigel.li.it/sn/preference/checkins/ neoapi.rigel.li.it/sn/preference/following/ neoapi.rigel.li.it/sn/preference/photo/ neoapi.rigel.li.it/sn/preference/poststatus/ neoapi.rigel.li.it/sn/preference/video/ 4.5 Contact/Network API Questa API è usata per recuperi i dati sui contatti del network per ogni social account di un utente, ed è supportata solamente per i SN che forniscono autenticazione OAuth come Facebook, LinkedIn, Twitter, Google, Yahoo, MSN. Tabella 9: API per il recupero dei dati dai social network esterni. API Endpoint Request Type Input Parameters Error Codes Response Neoapi.rigel.li.it/sn/preference/contact?idUser={idUser} Http Get Request iduser 403 Forbidden : Your Access Token is invalid 401 unauthorized : Your account does not have permission JSON_CONTACT Element of the json { contact : JSON_CONTACT} 29

30 Tabella 10: JSON_CONTACT Format Name ID Name ID PhoneNumber ProfileUrl ImageUrl Status Industry Country Gender Description Social ID of the user Name of the Friend/Follower/Connnection Id of the Friend Phone no of the Friend profile url of the Friend image Url of the Friend Current Status message of the Friend Industry of the Friend Country of the Friend Gender of the Friend 30

31 4.6 User Activities API Questa API è usata per ricevere i dati del profilo utente che riguardano le attivitàà di questo sul relativo Social Network. Ci son variazioni sulla base del Social Network investigato: Facebook fornisce user s Groups", posts e events, Twitter fornisce Mentions e Timeline; LinkedIn fornisce followed companies" Get user's Groups Tabella 11: Specifica API per iscrizione a gruppi. API Endpoint Request Type Input Parameters Error Codes Response /neoluoghi/sn/preference/group/?iduser={iduser} Http Get Request iduser 403 Forbidden: Your Access Token is invalid 401 Unauthorized: Your account does not have permission JSON Element of the json { group : JSON_GROUP} Tabella 12: JSON_GROUP Format Name ID Name Type Logo PostalCode Description Description Social ID of the user Group Name Type of the Group URL of the Logo Image Postal code for Group Groups Address A Description of the Group 31

32 Image Country MemberCount URL for Group Image Groups Location Number of members in Group Get user's Posts Tabella 13: API recupero post dell'utente. API Endpoint Request Type Input Parameters Error Codes Response /neoluoghi/sn/preference/post/?iduser={iduser} Http Get Request iduser 403 Forbidden: Your Access Token is invalid 401 Unauthorized: Your account does not have permission JSON_GET_POST (example: sn.preference.post.json) Tabella 14: JSON_GET_POST Format Name ID Name Title StartTime UpdateTime Message Place Picture Description ID of the post Name of the user who has posted Title of the post Start Time of the post Update time of the post Message of the post Place of the post Url of the picture mentioned in the post 32

33 Likes Share Number of likes of the post Number of shares of the post Get user's Events Tabella 15: Api per recuper eventi in cui è coinvolto l'utente. API Endpoint Request Type Input Parameters Error Codes Response /neoapi.rigel.li.it/sn/preference/event/?iduser={iduser} Http Get Request iduser 403 Forbidden: Your Access Token is invalid 401 Unauthorized: Your account does not have permission JSON_EVENT (example: sn.preference.event.json) Tabella 16: JSON_EVENT Format Name Type Read-only Description ID String ReadOnly ID of the Event Name String ReadOnly Name of the Event Privacy String ReadOnly Access Restrictions OwnerName String ReadOnly Name of Event Creator OwnerID String ReadOnly ID of Event Creator UpdatedDate String ReadOnly Last modified date EndTime String ReadOnly End time of Event Description String ReadOnly Event Description StartTime String ReadOnly Start time of the Event 33

34 RsvpStatus String ReadOnly Response status of the event Location String ReadOnly Location of the Event Get user's Twitter mentions Tabella 17: API per verificare i post in cui l'utente è menzionato. API Endpoint Request Type Input Parameters Error Codes Response /neoapi.rigel.li.it/sn/preference/twittmention/?iduser={iduser} Http Get Request iduser 403 Forbidden: Your Access Token is invalid 401 unauthorized: Your account does not have permission JSON_TWITTMENTION Tabella 18: JSON_MENTION Format Name Name ID Text DateTime Likes Place Source ImageUrl Description Name of Mentioner ID of the mention Text of the mention Date and Time of the mention Likes of the mention Place of the mention Source of the mention ImageUrl of the image in the mention 34

35 LinkUrl LinkUrl of the mention Get companies followed Tabella 19: API per rilevare le compagnie di cui l'utente è "follower". API Endpoint Request Type Input Parameters Error Codes /neoapi.rigel.li.it/sn/preference/followedcompagnie/? iduser={iduser} Http Get Request iduser 403 Forbidden: Your Access Token is invalid 401 Unauthorized: Your account does not have permission Response JSON_FOLLOWED_COMPAGNIE Tabella 20: JSON_FOLLOWED_COMPAGNIE Format Name Type Description ID Array ID of the company Name Array Name of the Company 35