ESTEEM meeting Sirmione, Novembre 2006 Hotel Terme di Sirmione

Dimensione: px

Iniziare la visualizzazioe della pagina:

Download "ESTEEM meeting Sirmione, 16 17 Novembre 2006 Hotel Terme di Sirmione"

Mariana Motta
8 anni fa
Visualizzazioni

1 ESTEEM meeting Sirmione, Novembre 2006 Hotel Terme di Sirmione NAME ORGANIZATION Tiziana Catarci, Diego Milano, Carola Aiello, Sara Tucci Piergiovanni, Silvia Bonomi Silvana Castano, Stefano Montanelli Valeria De Antonellis, Devis Bianchini, Michele Melchiori Letizia Tanca, Cristiana Bolchini, Carlo Curino, Elisa Quintarelli*, Rosalba Rossato*, Fabio A. Schreiber * solo venerdì UniRM UniMI UniBS PoliMI 16 Novembre 2006 Speaker Contenuti Intervento Tiziana Catarci Welcome, Introduzione, Agenda Presenta lo stato di avanzamento lavori e le scadenze imminenti della fase 1: Attività 1.1: Comparative Analysis of Existing Work fatto Attività 1.2: Requirements Collection for Demonstrator fatto Attività 1.3: Methods and Techniques for ESTEEM Services entro il 31 dicembre Attività 1.4: High Level Design of ESTEEM Architecture entro il 31 dicembre Presentazioni dell attività di ricerca svolta dalle unità Diego Milano Carola Aiello Silvia 1.Trust and Privacy Issues 2. Object Identification Temporal Record Linkage Semantic Communities Support in P2P Environements

Schreiber * solo venerdì UniRM UniMI UniBS PoliMI 16 Novembre 2006 Speaker Contenuti Intervento Tiziana Catarci Welcome, Introduzione, Agenda Presenta lo stato di avanzamento lavori e le scadenze

2 Bonomi Stefano Montanelli Devis Bianchini Cristiana Bolchini Semantic Self-Formation of Communities of Peers Service Discovery in P2P Semantic Communities Context management and integration Presentazione Questionari Carola Aiello Presenta i risultati dell analisi dei requisiti utente. Dai dati raccolti con i questionari emerge che abbiamo a che fare con un pubblico non consapevole: i medici intervistati non distinguono dati e servizi, né hanno chiara la differenza tra il contesto di ricerca di dati/servizi e il motivo della ricerca; di conseguenza i questionari risultano riempiti in maniera confusa ed incompleta. Ciò nonostante è stato possibile ricavare le seguenti informazioni di massima: 1. Tipologia dati scambiati - Epidemiologici - Informazioni farmacologiche - Dati testuali vari - Bibliografia 2. Tipo di accesso (dati) - Pubblico (72,7%) - A pagamento (54,5%) 3. Operazioni effettuate sui dati - Consultazione (100%) - Download (90%) - Integrazione e condivisione (50%) 4. Proprietà dei dati ritenute importanti - Precisione (72,7%) - Aggiornamento (81,8%) - Completezza (63,6%) 5. Motivo/contesto di ricerca di dati e servizi - Aggiornamento 6. Tipo di accesso (servizi) - Pubblico (45,5%) - Sottoscrizione gratuita (54,5%) 7. Proprietà ritenute importanti (servizi) - Aggiornamento (63,6%) - Disponibilità (63,3%) - Completezza (54,5%) 8. Caratteristiche importanti della ricerca (servizi) - Disponibilità (63,6%) - Usabilità (54,5%) - Rapidità di risposta (45,5%)

Dai dati raccolti con i questionari emerge che abbiamo a che fare con un pubblico non consapevole: i medici intervistati non distinguono dati e servizi, né hanno chiara la differenza tra il contesto

3 9. Interesse a personalizzare i dati secondo - Argomenti d interesse (73%) 10. Tipologie di comunità utilizzate - Di fatto (27%) - Di pratica (36%) 11. Informazioni condivise - Gestione del paziente/cartella clinica - Sperimentazioni 12. Interesse per comunità con sottoscrizione - Controllata da un moderatore (55%) 13. Criterio per la formazione di comunità - Interessi scientifici/professionali (82%) - Qualifica professionale (45%) 17 Novembre 2006 Struttura Architettura ESTEEM Diego Milano Avvia una discussione relativa all architettura ESTEEM, cercando di riassumere alcuni commenti emersi durante la giornata precedente. Dalla discussione emerge la necessità di chiarire gli aspetti relativi a alla formazione delle comunità semantiche tramite il manifesto. [Montanelli] spiega che nella fase di invio del manifesto attualmente non è prevista una fase di negoziazione, ma UniMI può lavorare in questa direzione [Bonomi] precisa che le loro tecniche di costruzione della Interest Overlay sono attualmente basate su keyword. Con riferimento alla complessità del matching [Tucci] chiede la dimensione media del manifesto per poter gestire in maniera efficiente la formazione di comunità. [Castano] risponde che il manifesto è una sottoontologia, [Montanelli] precisa che la dimensione media del manifesto è di centinaia di K, e che, per loro esperienza, sotto i 1000 concetti il tempo di matching è nell ordine del millisecondo. [Catarci] chiede cosa fanno i peer che ricevono il manifesto: fanno matching su tutto? [Castano e Montanelli] rispondono di sì, ma spiegano che ci vuole una certa soglia di similarità per aderire. Per quanto riguarda i tempi affermano che non è oneroso (se almeno una delle due è piccola). [Tucci] spiega il meccanismo di gestione di una overlay basato su shuffling: i nodi non hanno una conoscenza completa della topologia della rete, ma solo una vista parziale, cioè una lista di vicini. Periodicamente ed in maniera randomica i nodi scambiano con i vicini una porzione della lista e modificano la propria vista sulla base delle viste che ricevono. [Catarci] chiede cosa succede quando si forma una comunità [Tucci] risponde che di fatto non c è né un inizio, né una fine, semplicemente l evento manifesto nel tempo verrà distribuito nella rete e prima o poi verrà conosciuto dai peer. [Catarci] chiede su cosa viene fatto il matching [Tucci] risponde: il matching viene effettuato sul manifesto di startup, poi spiega ancora lo shuffling

Criterio per la formazione di comunità - Interessi scientifici/professionali (82%) - Qualifica professionale (45%) 17 Novembre 2006 Struttura Architettura ESTEEM Diego Milano Avvia una discussione

4 e che lo stesso meccanismo è utilizzato sia a livello di una overlay globale che per gestire le overlay semantiche relative alle singole comunità. [Catarci] chiede come si caratterizza il peer inizialmente, [Tucci] risponde che all inizio il peer esporta solo il suo IP. [Catarci] chiede come avviene l accrescimento della conoscenza. [Tucci] risponde: 1. all inizio si mantiene una lista con gli identificativi (overlay globale o di connettività) 2. in seguito viene trasmessa una seconda lista relativa alla comunità che si sta formando, tramite il meccanismo di shuffling prima o poi il peer che ha mandato il manifesto si accorge che qualcuno (e chi) ha aderito al manifesto. Viene precisato che un peer che non accetta il manifesto (startup) non sale nella SO, passa il manifesto, ma non lo mantiene. [Castano] precisa che nella loro peer ontology si tiene traccia dei peer più amici (quelli di maggior fiducia, con cui si scambia di più e più frequentemente ). [Tucci] conferma che è possibile utilizzare dei link preferenziali da stabilire all interno delle comunità, ma fa presente che bisogna evitare che la comunità sedimenti, a tal fine almeno una parte dei legami deve essere periodicamente stabilita in maniera randomica. [Catarci] sottolinea che bisogna rappresentare anche servizi e contesto, dove li mettiamo? [Tanca] propone di mettere il contesto da un altra parte perché rappresenta un di più: mi permette quando sono scollegato di avere i dati in locale, di migliorare la query.. Viene accettata la proposta di trasmettere, dopo la formazione della comunità, un secondo manifesto che tratti servizi e contesto. La versione arricchita del manifesto verrà distribuita dal promotore. [Bolchini] fa il seguente disegno per illustrare quanto detto. [Catarci] fa presente che esistono due operazioni trasversali che attraversano gli strati: (i)la formazione e manutenzione della comunità, (ii) il querying.

[Tucci] risponde: 1. all inizio si mantiene una lista con gli identificativi (overlay globale o di connettività) 2.

5 [Tucci] spiega che ogni peer è a sua volta promotore secondo tecniche epidemiche. [Milano] chiede come vengono scambiati gli schemi. [Montanelli] propone di fare inizialmente una probe. [Milano] sottolinea che l ontologia dei peer non arriva fino ai dati, ed è quindi necessario ottenere gli schemi. Dopo una discussione ci si accorda sul seguente meccanismo: una ontology probe query permette di distinguere i peer che possiedono effettivamente dati di interesse. A tali peer si inoltra una schema request. Lo schema ottenuto viene mappato su quello locale, ed il mapping è utilizzato in seguito in fase di querying. [Milano] discute un approccio alla gestione di qualità e trust basato su authority. [Milano] presenta alcune soluzioni relative al querying, tra cui quella proposta nel sistema Piazza. A seguito di una discussione si scarta l ipotesi che i peer inoltrino le query. Si interrogano solo peer con i quali si è stabilito un mapping di schema con il meccanismo discusso in precedenza. Tali peer devono quindi essere mantenuti in una lista separata. [Castano] sottolinea il vantaggio di avere una comunità: in assenza di comunità, quando la query si propaga potrebbe arrivare ad un peer che non conosce il mapping del peer che ha originato la query, nel nostro caso invece i peer condividono l ontologia della comunità quindi i mapping ci sono. [De Antonellis] Fa presente che vanno ancora discusse le modalità di service discovery. Dopo una discussione si approva un meccanismo di probing sulla SFO analogo a quello utilizzato per i dati. La probe query restituisce un mapping, la risposta contiene anche le informazioni necessarie per invocare i servizi concreti. [Curino] Osserva che il meccanismo differisce da quello sui dati perchè ha un passaggio in meno (quello corrispondente alla richiesta degli schemi). Dopo una breve discussione si conferma quanto stabilito in quanto i dati necessari per l invocazione dei servizi possono agevolmente essere inviati in risposta alla probe query. [Bolchini] illustra quanto detto con i seguenti disegni

Dopo una discussione ci si accorda sul seguente meccanismo: una ontology probe query permette di distinguere i peer che possiedono effettivamente dati di interesse.

6 Figura 1 Sequence Diagram Comunication

7 Figura 2 Knowledge Creation

8 Figura 3 - Manifesto CONCLUSIONI Presa visione delle attività della fase 2: [Catarci] precisa che il software non è previsto, ma se una delle unità sviluppa un prototipo (anche parziale) potremmo inserirlo. Prossimo Meeting: Lun. Mar. 7 8 Maggio, Ischia

ma se una delle unità sviluppa un prototipo (anche parziale)

Documenti analoghi

Service discovery in P2P semantic communities

Service discovery in P2P semantic communities Università di Brescia Dipartimento di Elettronica per l Automazione Devis Bianchini, Valeria De Antonellis, Michele Melchiori, Denise Salvi 1 Definizione del