Simulazione dell`evoluzione del Trust all`interno di una comunità di

Transcript

UNIVERSITÀ DEGLI STUDI DI MILANO
Facoltà di Scienze Matematiche, Fisiche e Naturali
Dipartimento di Tecnologie dell’Informazione
Corso di Laurea in Informatica
"Tecniche di Trust Management per la
gestione di Metadati: Un tool di
simulazione dell'evoluzione del trust
all'interno di una comunità di utenti"
Relatore: Chiar.mo Prof.
Ernesto Damiani
Correlatore: Dott.
Paolo Ceravolo
Anno Accademico 2004/2005
AUTORE
ALESSIO CURCIO
Matr. 621527
____________________________________________________________________
II
____________________________________________________________________
RINGRAZIAMENTI
Ringrazio il Chiar.mo Prof. Ernesto Damiani per avermi aiutato ed accolto come
tesista; in particolare ringrazio il mio relatore, Dott. Paolo Ceravolo per il tempo
dedicato a me e alla mia tesi e per avermi seguito con interesse, disponibilità e
spirito collaborativo.
Ringrazio i miei genitori per avermi dato la possibilità di arrivare fin qui e per
essermi stati sempre vicini e Micol per avermi incoraggiato e sostenuto in tutti
questi anni.
Ringrazio Marco Viviani, Alberto Colombo e Fulvio Frati per i consigli e la
disponibilità.
III
____________________________________________________________________
PAROLE CHIAVE
Web Semantico
Trust
Simulazione
IV
____________________________________________________________________
“Trust is the result of a risk successfully
survived”
A.Gibb
V
____________________________________________________________________
Indice dei capitoli
Capitolo 1
Il web semantico
Introduzione
1.1 Il web semantico: Knowledge management
1.1.1 Web semantico
1.1.2 I metadati
1.1.3 Linguaggi per il web semantico
1
2
3
5
7
1.1.3.1 Resource Description Framework:RDF
1.1.3.2 Extensible Modelling Language:XML
1.1.3.3 Ontology Web Language:OWL
7
20
24
1.2 Ontologie
1.3 Applicazioni del web semantico
25
30
Capitolo 2
L’uso del trust negli ambienti centralizzati e distribuiti
2.1 Definizione di trust
2.2 Metriche di trust
2.2.1 Approcci centralizzati
2.2.2 Approcci distribuiti
2.3 Il problema della computazione del trust
35
37
39
44
50
Capitolo 3
Simulazione dell’evoluzione del trust in una comunità
di utenti.
3.1 Obiettivi del progetto
3.2 Il modello
3.2.1 Formalismo di descrizione degli utenti
3.2.2 La funzione di accesso
3.2.3 Funzione di correttezza del voto espresso
3.2.4 Scelta della funzione statistica:la gaussiana
3.2.5 Schema del modello per la simulazione
52
53
53
55
57
57
59
VI
____________________________________________________________________
3.3 Simulazione
3.3.1 Definizione e scopo
3.3.2 Modelli fornali
3.3.3 Tipi di simulazione
3.3.3.1 Il tempo
3.3.4 Strutture di modelli di simulazione
3.3.5 Pianificazione
3.4 Ingegnerizzazione
3.4.1 Scelta delle tecnologie
3.4.1.1 Java
3.4.1.2 XML
3.4.2 Scelta dell’interfaccia
3.5 Aggregatore del trust
3.5.1 Definizione di aggregatore e proprietà
3.5.2 Operatori di aggregazione
3.5.3 Aggregatori creati per la simulazione
3.6 Progetti collegati
62
62
65
66
66
67
68
68
73
73
75
78
78
78
81
84
85
Capitolo 4
Trust Simulator in funzione
4.1 Interfaccia utente
4.1.1 Creazione dei componenti
4.1.1.1 Schema
4.1.1.2 Usergroup
4.1.1.3 Project
87
87
87
88
89
4.1.2 I l Run della simulazione
90
4.1.2.1 Simulation Configuration
4.1.2.2 Usergroups
4.1.2.3 Assertions Trust
4.1.2.4 General Info
90
91
93
94
Capitolo 5
Conclusioni
5.1 Prove di evoluzione del sistema
5.1.1 Scelta del contesto di esempio per la simulazione
5.1.2 La composizione della popolazione
5.1.2.1 Prima simulazione
97
97
98
100
VII
____________________________________________________________________
5.1.2.2 Seconda simulaizone
5.1.2.3 Terza simulzione
5.1.2.4 Quarta simulaizone
5.1.2.5 Osservazioni sulla composizione della popolazione
5.1.3 La composizione delle risorse
5.1.3.1 Simulazione
5.1.3.2 Osservazioni sulla composizione delle risorse
5.1.4 Utenti anonimi ed aggregatori
5.1.4.1 Simulazione uno
5.1.4.2 Simulazione due
5.1.4.3 Osservazione su utenti anonimi ed aggregatori
5.2 Sviluppi futuri
100
101
103
105
105
105
107
107
107
109
111
111
VIII
____________________________________________________________________
Indice delle figure
CAPITOLO 1.
FIGURA 1.1. MODELLO DEL WEB SEMANTICO ................................................................ 4
FIGURA 1.2. GRAFO RDF DELL’ESEMPIO DI ASSERZIONE RDF ....................................... 9
FIGURA 1.3. NUOVA RISORSA NELL’ASSERZIONE RDF ................................................ 10
FIGURA 1.4. GRAFO RELAZIONE NON BINARIA . .......................................................... 13
FIGURA 1.5. ESEMPIO DI MODELLO DI CLASSIFICAZIONE . ............................................ 14
FIGURA 1.6. DIAGRAMMA RDFS:CLASS E RDF:PROPERTY . .......................................... 18
FIGURA 1.7. DIAGRAMMA DELLA GERARCHIA DELLE CLASSI DI RDF(S) . .................... 19
FIGURA 1.8. CLASSI . ............................................................................................... 27
FIGURA 1.9. PROPRIETÀ ED ATTRIBUTI . .................................................................... 27
FIGURA 1.10. ASSIOMI . .......................................................................................... 28
FIGURA 1.11. INDIVIDUI . ........................................................................................ 28
CAPITOLO 2.
FIGURA 2.1. CATEGORIE DI RATING.......................................................................... 38
FIGURA 2.2. PAGE RANK. ........................................................................................ 43
FIGURA 2.3. : PGP .................................................................................................. 45
CAPITOLO 3.
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
3.1.
3.2.
3.3.
3.4.
3.5.
3.6.
TRE STATI DELLE ATTIVITÀ DI UN UTENTE. ............................................. 54
PROBABILITÀ DI ACCESSO..................................................................... 56
PROFILO UTENTE ED ASSERZIONI. ......................................................... 56
CORRETTEZZA DEL VOTO ESPRESSO. ...................................................... 57
LA GAUSSIANA..................................................................................... 58
CASI D’USO. ........................................................................................ 70
CAPITOLO 4.
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
4.1.
4.2.
4.3.
4.4.
4.5.
4.6.
IMPOSTAZIONI DELLO SCHEMA .............................................................. 87
SCHERMATA DEGLI USERGROUP. ........................................................... 88
DEFINIZIONE DI UN PROGETTO ............................................................... 89
CONFIGURAZIONE DELLA SIMULAZIONE..................................................
90
VISUALIZZAZIONE GRAFICO ROLES DISTRIBUTION DEGLI USERGROUP .. 91
VISUALIZZAZIONE GRAFICO EXPERTISE DEGLI USERGROUP ...................... 92
IX
____________________________________________________________________
FIGURA
FIGURA
FIGURA
FIGURA
4.7. SCHERMATA ASSERTIONS TRUST........................................................... 93
4.8. SCHERMATA GENERAL INFO. ................................................................ 94
4.9. VISUALIZZAZIONE GRAFICO PRECISION. ................................................. 95
4.10. VISUALIZZAZIONE GRAFICO RECALL. .................................................... 96
CAPITOLO 5.
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
FIGURA
5.1.
5.2.
5.3.
5.4.
5.5.
5.6.
5.7.
TRUSTWORTHINESS “IDEALE” ............................................................... 99
RECALL “IDEALE”................................................................................ 99
PRECISIONE “IDEALE” .......................................................................... 99
TRUSTWORTHINESS “ESPERTI NON EQUAMENTE DISTRIBUITI”................. 100
RECALL “ESPERTI NON EQUAMENTE DISTRIBUITI” ............................. 101
PRECISION “ESPERTI NON EQUAMENTE DISTRIBUITI” ............................. 101
TRUSTWORTHINESS “ESPERTI BEN DISTRIBUITI E GENERICI BEN
DISTRIBUITI” ...................................................................................... 102
5.8. RECALL “ESPERTI BEN DISTRIBUITI E GENERICI BEN DISTRIBUITI”. .......... 102
5.9. PRECISION “ESPERTI BEN DISTRIBUITI E GENERICI BEN DISTRIBUITI”........ 103
5.10. TRUSTWORTHINESS “ESPERTI NON EQUAMENTE DISTRIBUITI E GENERICI NON
EQUAMENTE DISTRIBUITI”. .................................................................. 104
5.11. RECALL “ESPERTI NON EQUAMENTE DISTRIBUITI E GENERICI NON
EQUAMENTE DISTRIBUITI” ................................................................... 104
5.12. PRECISION “ESPERTI NON EQUAMENTE DISTRIBUITI E GENERICI NON
EQUAMENTE DISTRIBUITI”. .................................................................. 104
5.13. TRUSTWORTHINESS .......................................................................... 106
5.14. RECALL. ......................................................................................... 106
5.15.
5.16.
5.17.
5.18.
5.19.
5.20.
5.21.
PRECISION ...................................................................................... 107
TRUSTWORTHINESS SIMULAZIONE UNO .............................................. 108
RECALL SIMULAIZONE UNO............................................................... 108
PRECISION SIMULAZIONE UNO. .......................................................... 109
TRUSTWORTHINESS SIMULAZIONE DUE............................................... 110
RECALL SIMULAIZONE DUE. .............................................................. 110
PRECISION SIMULAIZONE DUE............................................................ 110
X
____________________________________________________________________
Indice delle tabelle
CAPITOLO 3.
FIGURA 3.1. OWA................................................................................................... 83
CAPITOLO 5.
FIGURA 5.1. PARAMETRI SIMULAZIONE “IDEALE” ...................................................... 98
FIGURA 5.2. PARAMETRI SIMULAZIONE “ESPERTI NON EQUAMENTE DISTRIBUITI” ....... 100
FIGURA 5.3. PARAMETRI SIMULAZIONE “ESPERTI BEN DISTRIBUITI E GENERICI BEN
DISTRIBUITI” ...................................................................................... 103
FIGURA 5.4. PARAMETRI SIMULAZIONE “ESPERTI NON EQUAMENTE DISTRIBUITI E
GENERICI NON EQUAMENTE DISTRIBUITI”.............................................. 104
FIGURA 5.5. PARAMETRI DELLA SIMULAZIONE...................................................... 106
FIGURA 5.6. PARAMETRI DELLA SIMULAZIONE UNO ................................................ 108
FIGURA 5.7. PARAMETRI DELLA SIMULAZIONE DUE ................................................. 109
XI
____________________________________________________________________
XII
____________________________________________________________________
Capitolo 1.
Il web semantico.
Introduzione
La gestione della conoscenza è un argomento che va assumendo sempre maggior
rilievo, facedosi da tramite all’integrazione di varie ricerche.
Oggi il web è forse il maggiore contenitore di conoscenza ed è quello più
frequentemente utilizzato da una vasta gamma di utenti. Il web, però, per sua natura
decentralizzato, rende d’importanza fondamentale l’interoperabilità delle
applicazioni a livello semantico e tecnologico.
Una esigenza fondamentale per l’evoluzione del web è quella di rappresentare la
conoscenza in maniera comprensibile alla macchina e di renderla di immediata
reperibilità.
Da sempre il W3C sviluppa tecnologie (linee guida, specifiche, software e
strumenti) per portare il web al massimo del suo potenziale, definendo protocolli
comuni che ne favoriscano l’evoluzione e l’interoperabilità. Gli obiettivi a lungo
termine del W3C sono coerenti con le motivazioni iniziali che hanno portato alla
nascita del web.
Possiamo riassumere come obiettivi a lungo termine del W3C i seguenti:
• Universal access: Rendere il web accessibile a tutti, promuovendo tecnologie che
tengano conto delle notevoli differenze in termini di formazione, capacità, risorse, e
limitazioni fisiche degli utenti di tutto il mondo.
• Semantic web: Sviluppare un ambiente software che consenta ad ogni utente di
fare il miglior utilizzo possibile delle risorse disponibili sul web
• Web of trust: guidare lo sviluppo del web tenendo in attenta considerazione gli
aspetti innovativi che questa tecnologia solleva in campo legale, commerciale e
sociale.
Il reperimento di risorse sul web è oggi diventato una via di mezzo tra la ricerca
delle informazioni e l’apprendimento del contesto in cui l’informazione si trova,
poiché l’utente richiede di selezionare informazioni di volta in volta più complesse
e complete in modo da ottenere come risultato di una ricerca le informazioni il più
possibile coerenti con ciò che ha cercato.
Il W3C considera l’ideale evoluzione del Web da machine-representable a machineunderstandable. L’idea è di generare documenti che possano al tempo stesso essere
letti ed apprezzati da esseri umani, ma anche acceduti ed interpretati da agenti
automatici alla ricerca di contenuti. Il Web si deve dunque dotare di una
sovrastruttura semantica utilizzabile dalle applicazioni, in modo da poter svolgere
1
____________________________________________________________________
quelle funzioni che oggi debbono essere fatte a mano o codificate dentro ai
programmi.
Questo porta alla definizione di un programma denominato web semantico, in cui
esprimi le risorse fondamentali del web non siano rappresentate da semplici testi
(all'interno dei quali le informazioni stanno nascoste e richiedono un umano), ma da
affermazioni (informazioni non ambigue, che esprimono relazioni tra oggetti,
risorse, esseri umani, fatti del mondo reale, e che possono essere utilizzate anche da
applicazioni automatiche).
Nel momento in cui inizio a realizzare inferenze però, ho da considerare anche il
problema della veridicità delle informazioni, e della loro affidabilità. Il passo
successivo allora è creare una rete di affermazioni di affidabilità e fiducia (trust)
sulle collezioni, in cui viene espresso il valore di affidabilità delle affermazioni
contenute, e attraverso sistemi di sicurezza e crittografia rendere più affidabile il
sistema di affermazioni. Il web of trust è allora il passo ultimo per permettere la
creazione di significato utile, automatico, affidabile su documenti e cose del mondo
reale.
Questa tesi si propone quindi di creare un tool che permetta di generare asserzioni
che permettano di dare una semantica a delle risorse e al tempo stesso garantirne il
trust.
1.1. Il web semantico: Knowledge management
I processi di fondamentale importanza nel Knowledge Management sono la
possibilità di reperire le fonti di conoscenza rilevanti per il problema specifico, e
fornire le fonti di conoscenza da utilizzare per risolvere i problemi.
In un sistema di Knowledge Management possiamo individuare cinque processi
fondamentali:
1. Acquisizione della conoscenza: catturando le competenze degli esperti, operando
deduzioni da fatti concreti, etc.
2. Rappresentazione della conoscenza: memorizzazione delle regole
3. Elaborazione della conoscenza: manipolazione della conoscenza memorizzata,
per derivare dipendenze o consistenza di regole
4. Condivisione della conoscenza: mediante la ricerca di regole che soddisfano la
query dell’utente.
5. Utilizzo della conoscenza: per risolvere il problema contingente, eventualmente
annotando la conoscenza esistente, in modo da renderne disponibile di nuova.
1-L'inferenza è il processo con il quale da una proposizione accolta come vera, si passa a una proposizione la cui verità è
considerata contenuta nella prima.Inferire è quindi trarre una conclusione. Inferire X significa concludere che X è vero; un
inferenza è la conclusione tratta da un insieme di fatti o circostanze.
2
____________________________________________________________________
Il Web, e in particolare il Semantic Web, che ne è la naturale evoluzione, costituisce
un indispensabile componente per supportare gran parte di questi processi. In
questo contesto, come verrà dettagliato in seguito, viene utilizzato un formalismo
per rappresentare, in forma molto semplice, dei fatti, sui quali è possibile operare
delle inferenze. Un elemento significativo è che la conoscenza codificata nel web è
rappresentata in maniera elaborabile dalla macchina, e quindi può essere utilizzata
da componenti automatizzati, denominati agenti software.
La ricerca di informazioni è uno dei principali punti deboli del web, nonostante il
gran numero di motori di ricerca esistenti, che sono poveri di semantica sia in fase
di indicizzazione che in fase di ricerca. In fase di indicizzazione, essi utilizzano o
moduli compilati dai fornitori di informazioni, che spesso non consentono di
specificare metainformazioni come l’ autore, le parole chiave, etc., o strumenti
automatici (spider) per accedere alle pagine ed estrarre semantica. Talvolta, anche
le informazioni contenute nei tag <meta> vengono di fatto ignorate. In fase di
ricerca, viene consentito di combinare le parole con operatori di contesto (“tutte le
parole”, “una parola qualunque”, “nel titolo”), ma in definitiva il risultato scaturisce
sempre da una ricerca sulla presenza di parole chiave e dall’ identificazione dei
documenti più affini alla domanda posta.
L’ esistenza di proposizioni più ricche dal punto di vista espressivo permette invece
agli utenti di ritrovare in maniera più facile ed efficace le informazioni necessarie
per risolvere i problemi. Tra l’altro, la presenza di queste proposizioni condizionali
consente di indicizzare le risorse esistenti sul web in maniera più ricca rispetto al
metodo tradizionale di associare alle risorse parole chiave o concetti. Diventa allora
possibile formulare richieste più sofisticate, migliorando sia la precisione delle
risposte ottenute, che il richiamo dei documenti pertinenti.
1.1.1 Web semantico
“The Semantic Web is the representation of data on the World Wide Web. It is a
collaborative effort led by W3C with participation from a large number of
researchers and industrial partners. It is based on the Resource Description
Framework (RDF), which integrates a variety of applications using XML for syntax
and URIs for naming.”
"Il Semantic Web è un'estensione del Web attuale in cui alle informazioni sono date
un senso, un significato ben definito, migliorando in questo modo la cooperazione
tra i computer e le persone." -- Tim Berners-Lee, James Hendler, Ora Lassila, The
Semantic Web, Scientific American, May 2001
Secondo una traduzione di primo acchito, si potrebbe pensare che il Semantic Web
stia a indicare il “Web che ha significato”, oppure il “Web che è significativo”.
Certo, detta in questi termini, la traduzione non potrebbe essere appagante. Bisogna,
perciò, tradurre Semantic Web come quel procedimento in base al quale vengono
applicati al World Wide Web i principi della semantica. Dal greco “sema’ino”
(indico), la semantica è lo studio del dei processi di costituzione del significato
all’interno del linguaggio. Anche se è difficile spiegare con semplici parole che
3
____________________________________________________________________
cosa sia effettivamente il Web Semantico (come ha ammesso lo stesso Tim
Berners-Lee), si può dire che esso costituisca una modalità nuova per dare ai dati
(presenti in rete) maggior significato.
La sfida dei prossimi anni è quindi il Semantic Web, che, nella visione di BernersLee, ha una architettura a livelli (Figura 1.1).
Figura 1.1: Modello del web semantico
Per chiarezza di terminologia, va ricordato che la filosofia di base del Web è quella
di uno spazio informativo universale, navigabile, con un mapping da URI (Uniform
Resource Identifier) alle risorse. Nel contesto del Semantic Web, il termine
semantico assume la valenza di "elaborabile dalla macchina" e non intende fare
riferimento alla semantica del linguaggio naturale e alle tecniche di intelligenza
artificiale. Il Semantic Web è, come l’ XML, un ambiente dichiarativo, in cui si
specifica il significato dei dati, e non il modo in cui si intende utilizzarli. La
semantica dei dati consiste nelle informazioni utili perché la macchina possa
utilizzarli nel modo corretto, eventualmente convertendoli.
Come chiaramente descritto da Tim Berners Lee, il Semantic Web potrà funzionare
solo se le macchine potranno accedere ad un insieme strutturato di informazioni e a
un insieme di regole di inferenza da utilizzare per il ragionamento automatico. La
sfida del semantic web, quindi, è fornire un linguaggio per esprimere dati e regole
per ragionare sui dati, che consenta l’esportazione sul web delle regole da
qualunque sistema di rappresentazione della conoscenza.
Esaminando più in dettaglio la Figura 1.1, si può notare il ruolo di base giocato da
XML (con Name Space e xmlschema), che consente di dare ai documenti una
struttura arbitraria, mentre RDF può essere usato per esprimere il significato,
asserendo che alcuni particolari elementi hanno delle proprietà (p.es. autore-di).
Un terzo componente è l’ Ontology Vocabulary (livello ontologico), inteso come il
contenitore che definisce in modo formale le relazioni fra i termini. Una ontologia
permette di descrivere le relazioni tra i tipi di elementi (per es. "questa è una
proprietà transitiva") senza però fornire informazioni su come utilizzare queste
4
____________________________________________________________________
relazioni dal punto di vista computazionale. Le ontologie possono svolgere un ruolo
fondamentale nel migliorare il funzionamento del Web (ricerca di concetti,
collegamento delle informazioni contenute in una pagina alle strutture di
conoscenza associate, etc.). Il linguaggio definito dal W3C per definire ontologie
strutturate, in architettura web, per consentire una migliore integrazione dei dati tra
applicazioni in settori diversi è OWL (Ontology Web Language).
Il livello logico è il livello immediatamente superiore al livello ontologico. A questo
livello le asserzioni esistenti sul Web possono essere utilizzate per derivare nuova
conoscenza. Tuttavia, i sistemi deduttivi non sono normalmente interoperabili, per
cui, secondo Berners-Lee, invece di progettare un unico sistema onnicomprensivo
per supportare il ragionamento (reasoning system), si potrebbe pensare di definire
un linguaggio universale per rappresentare le dimostrazioni. I sistemi potrebbero
quindi autenticare con la firma digitale queste dimostrazioni ed esportarle ad altri
sistemi che le potrebbero incorporare nel Semantic Web.
La firma digitale (digital signature) è di significativa importanza in diversi strati nel
modello astratto del Semantic Web. La crittografia a chiave pubblica è una tecnica
nota da qualche anno, ma non si è ancora diffusa su larga scala come ci si poteva
attendere.
Nella visione di Berners-Lee, un elemento che potrebbe aver giocato contro la
diffusione di questa tecnica è che essa è a "grana grossa", imponendo una scelta
binaria tra fiducia o non fiducia (trusted/not trusted), mentre sarebbe necessaria una
infrastruttura in cui le parti possano essere riconosciute e accettate come credibili in
specifici domini. Con una granularità più fine come questa, la firma digitale
potrebbe essere utilizzata per stabilire la provenienza delle ontologie e delle
deduzioni, oltre che dei dati.
L’ intera comunità scientifica sta investendo molte energie nel settore del Semantic
Web.
1.1.2 I metadati
Nel navigare sul web, si seguono dei link, che portano a quella che formalmente
viene detta risorsa (resource) identificata univocamente da un URI. Nel linguaggio
corrente una risorsa viene anche detta “documento”, per mettere in evidenza il fatto
che sia leggibile da un essere umano, o “oggetto”, per mettere in evidenza che è
leggibile da una macchina. Qualunque sia il termine utilizzato, la risorsa non è una
entità a sé, ma è accompagnata da informazioni che la descrivono. Le informazioni
sulla risorsa vengono generalmente dette Metadati.
Si può quindi dire che i metadati sono informazioni, comprensibili dalla macchina,
relative a una risorsa web o a qualche altra cosa. Il punto chiave è costituito
appunto dal fatto che i metadati sono comprensibili dalla macchina (machine
understandable). Di conseguenza, i metadati costituiscono un tipo di informazione
che può essere utilizzata dai software agent, per fare un uso appropriato delle
risorse, rendendo più semplice e veloce il funzionamento del Web, aumentando la
nostra fiducia in esso. A titolo di esempio, quando si reperisce un documento (o un
oggetto) sul web, utilizzando il protocollo HTTP, è possibile che il server invii
alcune informazioni sulla risorsa, quali la sua data di aggiornamento, la data
5
____________________________________________________________________
massima di validità dell’ informazione, il suo autore, etc. Quindi il Web, come
insieme di risorse e di informazioni sulle risorse (cioè metadati) è già una realtà alla
quale siamo abituati.
Va tenuto presente che i metadati sono dati, e questo fatto ha alcune conseguenze:
• possono essere memorizzati come dati, in una risorsa, che può quindi contenere
informazioni relative a se stessa o ad un’altra risorsa. I metadati relativi ad un
documento possono essere contenuti nel documento, oppure contenuti in un
documento separato, oppure essere trasferiti a corredo del documento.
• possono essere descritti da altri metadati, e così via.
I metadati costituiscono il più grosso punto debole del Semantic Web, e questo lo si
può capire in modo intuitivo fin da subito.
I metadati costituiscono una difficoltà perché sono molto costosi da produrre e
possono risultare imprecisi. Se la produzione dei metadati avviene attraverso
un’indicizzazione manuale, questa risulterà costosa in termini di tempo e costiuomo. Inoltre quando l’indicizzazione non è fatta da persone motivate e addestrate
può risultare piuttosto imprecisa, perché vissuta come obbligo ed eseguita di fretta.
La creazione dei metadati è un’attività molto importante ma allo stesso tempo molto
complessa e ciò è tipicamente motivato dalle molteplici interpretazioni che un
metadato può presentare.
I metadati non hanno tutti lo stesso valore, alcuni valgono più di altri. Un metadato
descrive la struttura di una classe, di un tipo di dato. Ma può farlo in due modi
molto diversi. Il modo più agevole consiste semplicemente nel riempire il valore di
un campo, di una proprietà della classe (una Persona che si chiama "Paolo"). In
questo caso si attribuisce solo un valore ad una struttura, ma non si indica nulla di
preciso. Se si trovasse un altro metadato per la persona di nome Paolo non si
saprebbe mai se è la stessa persona o sono due diverse. Altrimenti un metadato può
puntare ad una risorsa e utilizzare quella per definire il valore della proprietà di una
classe (una persona che si chiama "http:/dominio.nomi.com/#Paolo"). In questo
caso il metadato compie un'operazione molto più precisa, in quanto va ad
individuare qualche cosa di univoco, di cui si potrà sapere con esattezza quali altri
metadati sono stati espressi. Il meccanismo è ancora più potente se si indica la
localizzazione di risorse fisiche, come pagine web, immagini, documenti.
Il problema che subito si pone, nella localizzazione dei contenuti, è quello
dell’evoluzione dei contenuti stessi. Come sappiamo il Web è dinamico, cioè
cambia molto rapidamente, dal momento che si interviene quotidianamente su di
esso con:
• Aggiunta di nuove pagine;
• Modifica delle pagine esistenti: tali variazioni possono avvenire ad intervalli
regolari o in qualunque momento, e riguardare parti non inerenti al contenuto
informativo (come la correzione di errori di sintassi, il cambiamento di
formattazione) oppure coinvolgere dati significativi;
• Rimozione di pagine (o di interi siti).
Tutto questo, in aggiunta alla mancanza di un controllo centralizzato, fa sì che i dati
possano essere
• Inconsistenti, per la mancanza di vincoli di qualunque tipo;
• Inaffidabili, perchè non sono controllati in alcun modo;
6
____________________________________________________________________
• Non disponibili, se la pagina in cui sono contenuti è rimossa.
Pertanto è possibile distinguere i metadati, in base ai dati che essi strutturano, in
metadati vivi e morti. È diverso definire un metadato per un documento di cui si
possiede in locale una copia piuttosto che di un documento di cui si possiede una
URL, una localizzazione nella rete. Nel primo caso si è certi di poter effettivamente
disporre di quel documento, nel secondo caso si rischia che l’URL non localizzi
nulla: si sa i link invecchiano piuttosto facilmente. Nel primo caso però è possibile
che si forniscano informazioni vecchie, nel secondo i dati saranno aggiornati in
tempo reale. Qui le scelte dipendono molto da cosa si intende fare e dai mezzi che si
hanno a disposizione. Una via di mezzo può essere quella di registrare sia una URL
sia una copia in cache, alla Google, per intendersi.
1.1.3 Linguaggi per il web semantico
1.1.3.1 Il Resource Description Framework(RDF)
“The Semantic Web provides a common framework that allows data to be shared
and reused across application, enterprise, and community boundaries. […] It is
based on the Resource Description Framework (RDF), which integrates a variety of
applications using XML for syntax and URIs for naming.”
Tim Berners-Lee, James Hendler, Ora Lassila
RDF (Resource Description Framework)
Il mattone fondamentale su cui poggerà l’intera sovrastruttura del Web Semantico è
RDF (Resource Description Framework, ovvero “Struttura finalizzata alla
Descrizione di Risorse”) che è il modello proposto dal W3C per consentire
l’aggiunta di semplici meta-informazioni semantiche a documenti web arbitrari. È
bene precisare subito che RDF è un modello astratto di descrizione delle risorse e
può dunque essere indifferentemente rappresentato in modi (ovvero, sintassi) e
forme diverse (ad es. in forma grafica): la scelta del W3C di adottare XML come
sintassi privilegiata per RDF (da cui deriva la dicitura “RDF/XML”) è dovuta
esclusivamente a ragioni di praticità, legate alla facilità di veicolare (ai fini della
serializzazione, trasmissione ed elaborazione) i contenuti RDF nella forma standard
e ben supportata di XML.
Il meccanismo per la descrizione di risorse di RDF è neutrale (general-purpose)
rispetto ai domini applicativi, cioè non è rivolto ad un particolare dominio di
applicazione, né definisce a priori il vocabolario e la semantica di qualche dominio,
ma il suo scopo essenziale è proprio quello di essere adattabile alla descrizione di
informazioni relative ad un qualsivoglia dominio.
Riepilogando, RDF è lo strumento basilare per la codifica, lo scambio e il riutilizzo
di metadati strutturati, e consente la condivisione di conoscenza tra applicazioni che
interagiscono tra loro, scambiandosi sul Web informazioni machineunderstandable: esso non specifica un meccanismo per il ragionamento automatico,
7
____________________________________________________________________
ma si limita a costituire una base al di sopra della quale tale meccanismo può essere
costruito.
Tre sono i tipi di oggetti fondamentali con cui RDF lavora : Risorse, Proprietà ed
Asserzioni.
-Una Risorsa è una qualunque cosa che possa essere nominata per mezzo di un
URI: una risorsa può essere un'intera pagina web, o solo una sua parte (ad es. uno
specifico elemento HTML o XML) oppure può anche essere un'intera collezione di
pagine (ad es. un intero sito web). Una risorsa può inoltre essere un oggetto
materiale non direttamente accessibile via Web (ad es. un libro o perfino una
persona fisica). Infine, anche entità del tutto immateriali (quali, ad esempio, la
proprietà “avere come autore”) possono essere considerate delle Risorse.
-Una Proprietà specifica una caratteristica di una risorsa, definendo una relazione
binaria tra la risorsa stessa ed un’altra risorsa oppure tra la risorsa e valori atomici
(espressi nella forma di tipi di dati primitivi definiti in XML Schema).
-Una Asserzione è una frase con una struttura fissa, composta da: un Soggetto
(ovvero, una risorsa), un Predicato (ovvero, una proprietà) ed un Complemento
oggetto (che può essere costituito indifferentemente da una Risorsa o da un
Letterale – cioè una stringa di caratteri o qualche altro tipo primitivo di XML
Schema -). Un’asserzione in RDF è quindi una Tripla (Subject, Predicate, Object)
in cui subject e predicate devono essere obbligatoriamente delle risorse mentre
object (cioè il valore della proprietà, property value) può essere sia una risorsa che
un letterale.
La cosa interessante di questo modo di rappresentare la conoscenza è che il
Complemento oggetto può a sua volta essere visto come il Soggetto di una nuova
tripla. Questa tecnica permette quindi di rappresentare situazioni anche molto
articolate. In situazioni nelle quali vi sia una certa proprietà con molti valori, ci si
può sempre ricondurre alla situazione (Soggetto, Proprietà, Complemento Oggetto).
Il modello dei dati di RDF è molto simile al modello Entity-Relationship (proprio
della modellazione di Database Relazionali) e può essere visto come un’estensione
del modello ER al web; infatti RDF si basa sui concetti di Entità e di Relazione, con
la differenza che in RDF quest’ultimo concetto, grazie all’utilizzo di URI, è stato
elevato allo stesso livello delle Entità, nel senso che anche le Relazioni possiedono
una propria specifica identità, indipendente dalle entità che mettono in relazione; in
questo modo non è necessario che tutte le informazioni su un’entità siano definite in
un unico luogo e chiunque può dire tutto su tutto ("anything can say anything about
anything").
Esempi di Asserzioni RDF
Sia data la frase in linguaggio naturale: “www.miosito.it ha per autore Mario
Rossi”, si riconoscono:
http://www.miosito.it/
Ha_Autore
“Mario Rossi”
Soggetto (Risorsa)
Predicato (Proprietà) Oggetto (Letterale)
8
____________________________________________________________________
Cioè: la proprietà “Ha_Autore” (che supponiamo essere definita nel namespace
http://esempio.it/proprieta/ per rappresentare la relazione binaria “avere come
autore”) della risorsa “http://www.miosito.it/” vale “Mario Rossi” (inteso come
stringa di caratteri) .
Ciascuna asserzione RDF può essere rappresentata graficamente con un grafo RDF,
che è un grafo orientato in cui il nodo di partenza di ogni arco rappresenta il Subject
dell’asserzione, l’arco stesso il Predicate e il nodo di arrivo l’Object. I nodi ovali
identificano le Risorse, mentre quelli rettangolari indicano i Letterali.
Il grafo RDF associato all’esempio (Directed Labeled Graph o DLG) sarà dunque:
Figura 1.2: Grafo RDF dell’esempio di asserzione RDF
Per serializzare questo grafo nella sintassi RDF/XML ci si deve riferire al
namespace "http://www.w3.org/1999/02/22-rdf-syntax-ns#” (con prefisso rdf) la cui
URL contiene un documento che definisce i nomi di tag usati da RDF/XML: i tag
<rdf:RDF> (che deve sempre costituire l’elemento radice di un documento
RDF/XML) e <rdf:Description> (attraverso il quale vengono fatte le asserzioni)
appartengono a tale namespace.
Esistono poi due modi per identificare il Subject; infatti, a seconda che la risorsa da
descrivere sia gia esistente o sia ancora da creare, possiamo:
-assegnare il nome della risorsa che vogliamo descrivere (cioe l’URI che la
identifica) all’attributo rdf:about del tag <rdf:Description>
-assegnare un letterale all’attributo rdf:ID del tag <rdf:Description>, cosi facendo,
il nome specificato diventa il nome locale di una risorsa per la quale non esiste
ancora una URI.
Per il nostro esempio avremo così:
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:d="http://www.esempio.it/proprieta/">
<rdf:Description rdf:about="http://www.miosito.it"> SOGGETTO
<d:Ha_Autore> PREDICATO
Mario_Rossi OGGETTO (Letterale)
</d:Ha_Autore> PREDICATO
</rdf:Description>
</rdf:RDF>
9
____________________________________________________________________
I nomi delle proprietà usati per descrivere delle risorse (nell’esempio, Ha_Autore)
devono essere sempre associati ad un namespace (in questo caso,
http://www.esempio.it/proprieta/) a cui solitamente viene assegnato un prefisso
(nell’esempio, d): così facendo possono essere utilizzati nel documento RDF/XML
come tag espressi in forma <Prefisso:NomeProprietà>
Si
noti
che
il
fatto
di
usare
una
URI
(quale
http://
www.esempio.it/proprieta/Ha_Autore), e non un semplice letterale, per nominare
una proprietà presenta grandi vantaggi: il significato (ovvero, la semantica) della
proprietà può essere descritta dettagliatamente all’interno della pagina identificata
dalla URI stessa; inoltre, una volta referenziata con una URI, quella proprietà potrà
essere usata da chiunque, in una qualsiasi pagina del Web. Semantico per descrivere
una qualsiasi cosa, mantenendone però il significato originale e con in più la
certezza di non incorrere in un conflitto di nomi.
Tornando all’esempio, possiamo poi pensare di trasformare il letterale “Mario
Rossi” in una vera e propria risorsa a sé stante: è sufficiente introdurre una nuova
risorsa con URI, ad esempio, http://www.miosito.it/Mario_Rossi.
Il vantaggio di questa operazione di trasformazione è dato dalla possibilità di usare
la nuova Risorsa Mario_Rossi come soggetto per nuove asserzioni in grado di
specificarne (oltre al nome) anche altre proprietà, ad es. l’indirizzo e-mail.
Quello che si ottiene è un insieme non ordinato di asserzioni, in cui di volta in volta
una Risorsa può ricoprire il ruolo di Soggetto o di Oggetto:
Nota: stiamo ipotizzando che le tre Proprietà Ha_Autore, Ha_Nome, Ha_Email
siano
tutte
definite
all’interno
dello
stesso
namespace
http://www.esempio.it/proprieta/ il cui prefisso è d).
La nuova rappresentazione grafica sarà:
Figura 1.3: Nuova risorsa nell’asserzione RDF
Poiché è un fatto piuttosto usuale quello di dichiarare contemporaneamente più
asserzioni
sulla
stessa
risorsa
(nell’esempio
in
esame,
http://www.miosito.it/Mario_Rossi), la sintassi RDF/XML permette di raggrupparle
assieme, annidandole all’interno dello stesso tag <rdf:Description>.
La struttura delle asserzioni specificate all’interno del tag <rdf:Description> (ed
aventi come soggetto quello specificato negli attributi di <rdf:Desctription>) è del
tipo:
10
____________________________________________________________________
<predicate>object</predicate>
Ma quando, come accade per l’Asserzione n.1, l’object è una URI (e non un
semplice letterale), questa va inserita direttamente nel tag <predicate> attraverso
l’attributo rdf:resource.
In sintassi RDF/XML avremo pertanto:
<rdf:Description rdf:about="http://www.miosito.it">
<d:Ha_Autore rdf:resource="http://www.miosito.it/Mario_Rossi"/>
</rdf:Description>
<rdf:Description rdf:about="http://www.miosito.it/Mario_Rossi">
<d:Ha_Nome>Mario Rossi</d:Ha_Nome>
<d:Ha_Email>[email protected]</d:Ha_Email>
</rdf:Description>
</rdf:RDF>
Contenitori RDF
Si può talvolta presentare la necessità di descrivere una risorsa attraverso una
proprietà che assume più valori (ad es. una squadra composta da più giocatori). Per
rappresentare situazioni di questo genere abbiamo a disposizione i Contenitori RDF,
che possono essere di 3 tipi:
Bag (rdf:Bag)
Lista non ordinata di risorse o letterali, in cui sono ammessi valori duplicati.
Sequence (rdf:Seq)
Lista ordinata di risorse o letterali, in cui sono ammessi valori duplicati.
Alternative (rdf:Alt)
Lista di risorse o letterali tra loro alternativi: la Proprietà deve assumere uno ed uno
soltanto dei valori specificati in questa lista di possibili valori.
Per poter utilizzare oggetti di questo tipo è necessario introdurre una risorsa fittizia,
la quale assumerà il ruolo di Contenitore e andrà successivamente descritta
attraverso le usuali asserzioni RDF.
Reificazione
Con il termine reificazione si indica il processo di trasformazione di una asserzione
(ovvero di una frase) in una Risorsa: grazie a tale trasformazione risulterà possibile
rappresentare in RDF anche delle “asserzioni su asserzioni”, ovvero delle citazioni,
quali, ad esempio: “Tizio afferma che Caio è l’autore di http://www.caio.it”. Per
riportare in RDF tale citazione, occorre innanzitutto introdurre una nuova risorsa
(mediante l’attributo rdf:ID) che rappresenti la frase più interna: “Caio è l’autore di
http://www.caio.it“ e su questa nuova risorsa, intesa come Subject, andrà
specificata la proprietà “Affermata_Da” avente “Tizio” quale Object.
In sintassi RDF/XML abbiamo:
11
____________________________________________________________________
<rdf:Description rdf:ID="Frase">
<rdf:type rdf:resource="http://www.w3.org/1999/02/22-rdf-syntaxns#Statement"/>
// queste ultime linee possono essere abbreviate con
// <rdf:Statement rdf:ID="Frase">
<rdf:subject rdf:resource="http://www.caio.it"/>
<rdf:predicate rdf:resource="http://www.esempio.it//proprieta/Ha_Autore/"/>
<rdf:object rdf:resource="http://www.persone.it/Caio"/>
</rdf:Description>
<rdf:Description rdf:about="#Frase">
<d:Affermata_Da rdf:resource="http://www.persone.it/Tizio"/>
</rdf:Description>
</rdf:RDF>
Dunque, la nuova risorsa online (che è stata chiamata “Frase”) è stata creata
definendola (mediante la Proprietà rdf:type) come una istanza della classe
rdf:Statement: in questo modo abbiamo indicato che tale nuova risorsa è una
asserzione. Successivamente abbiamo specificato il Soggetto (con la proprietà
rdf:subject), il Predicato (con rdf:predicate) e l’Oggetto (con rdf:object) di tale
Risorsa-Asserzione. Infine, abbiamo dichiarato che la risorsa con identificatore
locale “Frase” è stata asserita dalla risorsa http://www.persone.it/Tizio.
Relazioni Non Binarie
Il modello di dati RDF supporta intrinsecamente solo relazioni binarie; ovvero,
un'asserzione RDF specifica una relazione tra due sole risorse. La tecnica
raccomandata per rappresentare in RDF relazioni di ordine superiore (usando solo
relazioni binarie) è di usare una risorsa intermedia (Blank node) avente proprietà
addizionali che forniscano le rimanenti relazioni.
Frequentemente si hanno esempi di relazioni non-binarie quando si tratta con delle
unità di misura: ad esempio, non è corretto (ed anzi può condurre ad insidiose
ambiguità) indicare il prezzo di un certo prodotto con solo un numero (per es.
"100"): occorre specificare esplicitamente anche quale è la valuta usata (Euro,
Dollaro, Sterlina, … ).
Nel grafo RDF occorre dunque introdurre un nodo intermedio addizionale, che
presenti una relazione (arco) in grado di specificare il tipo di valuta:
12
____________________________________________________________________
Figura 1.4: Grafo relazione non binaria
In sintassi RDF/XML avremo:
<RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:d="http://www.esempio.it/proprieta">
<rdf:Description rdf:ID="Prodotto xxxxx">
<d:prezzo rdf:parseType="Resource">
<rdf:value>100</rdf:value>
<d:valuta rdf:resource="http://www.esempio.it/Euro"/>
</d:prezzo>
</rdf:Description>
</RDF>
L'attributo parseType modifica l'interpretazione del contenuto dell'elemento e
dovrebbe avere uno dei valori “Literal” o “Resource” (il valore è case-sensitive).
Il valore “Literal” specifica che il contenuto dell'elemento deve essere trattato
come un letterale RDF/XML (ovvero il contenuto non deve essere interpretato da
un processore RDF); il valore “Resource” specifica che il contenuto dell'elemento
deve essere trattato come se fosse il contenuto di un elemento <rdf:Description>.
Oppure, utilizzando l’attributo rdf:nodeID (che permette di dare un identificativo ad
un nodo):
<RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:d="http://www.esempio.it/proprieta">
<rdf:Description rdf:about="Prodotto xxxxx">
<d:prezzo rdf:nodeID="abc"/>
</rdf:Description>
<rdf:Description rdf:nodeID="abc">
<rdf:value>100</rdf:value>
<d:valuta rdf:resource="http://www.esempio.it/Euro"/>
</rdf:Description>
</RDF>
Confronto tra RDF e XML
La struttura di un documento XML è quella di un albero, mentre il modello di dati
di RDF è costituito da un grafo orientato, con archi etichettati.
Nel contesto del Web Semantico, rileviamo inoltre come, nel momento in cui si
rende necessaria la rappresentazione di una realtà di interesse e non di un dato,
viene meno il modello gerarchico e classificatorio dell’albero, in favore di un
modello relazionale e predicativo.
La struttura di un documento XML è una strutturazione ad albero di modi di
predicazione, adatti a soggetti sempre meno numerosi, a partire da classi più
generali via via attraverso differenziazioni e successive fino a giungere alla più
determinata possibile al di sotto della quale non esistono più ulteriori specie, ma
solo individui.
13
____________________________________________________________________
Un esempio di classificazione:
Figura 1.5: Esempio di modello di classificazione
Osservando questo schema rileviamo come, dal punto di vista strutturale, non vi sia
alcuna differenza fra la relazione che intercorre, ad esempio, tra Animali e
Carnivori e quella che intercorre fra Piante e Rami: in entrambi i casi si è di fronte
semplicemente a due relazioni di subordinazione. Dunque, benché esista una chiara
differenza fra il concetto di parte e quello di sottoinsieme (un carnivoro è un
animale, un ramo non è una pianta), l’albero porfiriano non offre alcuna possibilità
di segnalarla.
Il modello ad albero si rivela pertanto insufficiente allo scopo di rappresentare un
insieme di conoscenze, non perché sia privo di contenuto semantico, ma piuttosto
perché di tale semantica non viene definita alcuna regola di interpretazione, perché
il modello appare insufficiente di fronte all’insieme delle possibili relazioni fra i
concetti. La caratteristica dunque che più di ogni altra costituisce un limite alle
capacità rappresentative di XML, ma soprattutto dell’intera tradizione del modello
ad albero, è l’assenza di relazioni interpretabili. Nello sforzo di definire un modello
per la rappresentazione della conoscenza, si è constatato quanto sia cruciale la
questione dei tipi di relazioni, e la possibilità stessa di distinguere e definire
tipologie diverse di relazione, sia dal punto di vista del significato che ad esse si
associa, sia dal punto di vista delle proprietà di tali relazioni e della definizione di
un dominio e di un range di applicabilità.
RDF Schema
Quando scriviamo una frase in linguaggio naturale, usiamo parole che
convenzionalmente sono associate ad uno specifico significato. Questo significato è
fondamentale per la comprensione delle asserzioni, e, nel caso di applicazioni RDF,
è cruciale per stabilire il trattamento corretto che si intende indicare.
RDF consente di definire un semplice modello dei dati per descrivere proprietà di
risorse e relazioni tra le risorse stesse, ma senza contemplare livelli di astrazione
differenti: le risorse e le loro relazioni sono tutte organizzate allo stesso livello di
astrazione, in un grafo piatto. In altre parole, RDF non permette di definire tipi (o
“classi”) di risorse con loro proprietà specifiche e, a tal fine, RDF è stato arricchito,
per mezzo di RDF Schema, con un semplice sistema di tipi (che ricorda i sistemi di
14
____________________________________________________________________
tipi dei linguaggi di programmazione object-oriented). Una risorsa può, per
esempio, essere definita come istanza di una classe (o di più classi) e le classi
possono essere organizzate in modo gerarchico, permettendo di derivare, per
ereditarietà, nuova conoscenza. Altra lacuna di RDF (alla quale RDF Schema
intende porre rimedio) è quella di non fornire alcun meccanismo per definirne i
vincoli d’applicabilità delle Proprietà, per organizzarle gerarchicamente.
Per poter utilizzare gli strumenti offerti da RDF Schema è necessario riferirsi
esplicitamente al Namespace "http://www.w3.org/2000/01/rdf-schema#" , al quale è
comunemente assegnato l’alias “rdfs”.
I concetti messi a disposizione da RDF Schema sono quelli di:
Classe e sotto Classe (rdfs:Class, rdfs:subClassOf)
Sotto Proprietà (rdfs:subPropertyOf)
Dominio e Codominio di una Proprietà (rdfs:domain, rdfs:range)
Commenti, Etichette ed Informazioni Addizionali (rdfs:comment, rdfs:label,
rdfs:seeAlso)
In RDF Schema, una classe è una qualunque risorsa che abbia una proprietà
rdf:type il cui valore sia rdfs:Class (che a sua volta è una risorsa definita nel
namespace di RDF Schema).
Ad es. per creare una classe “Animale” (paradigma astratto di tutti gli animali del
mondo) basta asserire che ex:Animale rdf:type rdfs:Class ( in cui ex è inteso essere
il prefisso per una generica URI di esempio) cioè :
<rdfs:Class rdf:ID="Animale"/>
N.B. questa è una abbreviazione del codice RDF/XML
<rdf:Description rdf:ID="Animale">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>
Possiamo ora dire che “la classe Cane è sottoclasse della classe Animale”:
ex:Cane rdfs:subClassOf ex:Animale
cioè
<rdfs:Class rdf:ID="Cane">
<rdfs:subClassOf rdf:about="#Animale"/>
</rdfs:Class>
Ed anche che “Fido è un Cane”:
ex:fido rdf:type ex:Cane
cioè
<ex:fido rdf:ID=”Cane”/>
È bene avere ben chiara la differenza tra le due proprietà rdf:type (definita in RDF)
e rdfs:subClassOf (definita in RDF Schema): rdf:type può essere letta come “essere
15
____________________________________________________________________
istanza di” ed è impiegata per definire istanze di classi (es. “Fido è una particolare
istanza della classe Cane”), mentre rdfs:subClassOf è impiegata per definire
sottoclassi di classi (es. “la classe Cane è sottoclasse della classe Animale”).
Occorre fare attenzione quando si definiscono nuove classi: la nuova classe sarà una
istanza particolare di rdfs:Class, dunque si dovrà usare rdf:type. rdfs:subClassOf è
transitiva e consente di definire relazioni di sovra/sotto-insieme fra le classi.
Uno schema RDF rappresenta anche la sede in cui vengono documentate le
definizioni ed i vincoli d’uso delle proprietà che caratterizzano le classi.
In RDF tutte le proprietà devono essere definite come istanze della classe
rdf:Property, ad es.
ex:essere_Parente_Di rdf:type rdf:Property
cioè
<rdf:Property rdf:ID="essere_Parente_Di"/>
RDF Schema fornisce un modo per specializzare, come avviene per le classi, anche
le proprietà: ciò si ottiene usando la proprietà rdfs:subPropertyOf, ad es.
ex:essere_Fratello_Di rdfs:subPropertyOf ex:essere_Parente_Di
cioè
<rdf:Property rdf:ID="essere_Fratello_Di">
<rdfs:subPropertyOf rdf:resource="#essere_Parente_Di"/>
</rdf:Property>
RDF Schema offre inoltre degli strumenti linguistici (le proprietà rdfs:domain e
rdfs:range)per limitare il campo d'applicabilità delle varie proprietà definite a
livello utente, consentendo di porre, per ciascuna di esse, vincoli sul loro Dominio
(quali classi siano da considerare lecite come Soggetto della proprietà) e sul loro
Codominio (quali classi siano da considerare lecite come Valore, ossia come
complemento oggetto, della proprietà).
Ad esempio, se volessimo definire una nuova proprietà ha_Autore, imponendo che
essa possa avere come soggetto esclusivamente degli oggetti Libro e come valore
unicamente delle istanze della classe Persona, potremmo scrivere:
ex:Libro rdf:type rdfs:Class
Libro è una Classe
ex:Persona rdf:type rdfs:Class
Persona è una Classe
ex:ha_Autore rdf:type rdf:Property
ha_Autore è una Proprietà
ex:ha_Autore rdfs:domain ex:Libro
ha_Autore ha per Dominio istanze di Libro
ex:ha_Autore rdfs:range ex:Persona
ha_Autore ha per Codominio istanze di Persona
cioè
<rdfs:Class rdf:ID="Libro"/>
<rdfs:Class rdf:ID="Persona"/>
<rdf:Property rdf:ID=”ha_Autore”>
<rdfs:Domain rdf:about=”#Libro”>
<rdfs:Range rdf:about=”#Persona”>
16
____________________________________________________________________
</rdf:Property>
Abbiamo pertanto esplicitato esattamente il modo in cui la proprietà ha_Autore
mette in relazione oggetti della classe Libro con oggetti della classe Persona.
Ricordiamo che il valore (ma non il Soggetto!) di uno statement RDF può anche
essere costituito da un letterale; per questo motivo, la proprietà rdfs:range può
anche essere usata per indicare che il valore di una proprietà è dato da un tipo
particolare di letterale; ad esempio, volendo specificare che la Proprietà
anno_Di_Nascita (che si applica a risorse appartenenti alla classe Persona) ha come
valore un letterale “intero” (integer) secondo la definizione di XML Schema,
potremmo scrivere:
ex:anno_Di_Nascita rdf:type rdf:Property
ex:anno_Di_Nascita rdfs:domain ex: Persona
ex:anno_Di_Nascita rdfs:range xsd:integer
cioè
<rdfs:Datatype rdf:about="&xsd;integer"/>
<rdf:Property rdf:ID=”anno_Di_Nascita”>
rdfs:Domain rdf:about=”#Persona”>
rdfs:Range rdf:about=”&xsd;integer”>
</rdf:Property>
Benché l’URI http://www.w3.org/2001/XMLSchema#integer, che identifica il “tipo
di dato” integer, possa essere usata senza affermare esplicitamente in RDF Schema
che essa identifica un “tipo di dato”, tuttavia è consigliabile farlo comunque,
utilizzando la classe rdfs:Datatype.
Si presti attenzione al fatto che questa asserzione non costituisce una definizione di
un nuovo tipo di dato, in quanto non esiste alcuna possibilità di definire “tipi di
dato” in RDF Schema: l’asserzione presentata documenta solamente l’esistenza di
un “tipo di dato”, definito esternamente a RDF Schema, che può però essere usato
nello schema attraverso il suo riferimento URI.
Riepilogando, gli statements in uno Schema RDF sono sempre e solo delle
descrizioni, che possono anche essere considerate vincolanti, ma soltanto se
l’applicazione che li tratta è stata progettata per seguire questa interpretazione. RDF
Schema è un linguaggio dichiarativo che si limita a fornire un mezzo per affermare
informazioni addizionali sui dati, ma sono le singole applicazioni che stabiliscono
individualmente come affrontare l’eventualità che i dati non siano conformi agli
Schemi. RDF Schema mette a disposizione altre proprietà per fornire ulteriori
informazioni, come:
- rdfs:comment
Può essere usata per fornire una descrizione di una risorsa, in una forma che sia
leggibile da un utente.
- rdfs:label
Può essere usata per fornire una versione del nome di una risorsa che risulti più
facilmente comprensibile da un utente.
- rdfs:seeAlso
Può essere usata per indicare un’altra risorsa che potrebbe essere in grado di fornire
informazioni aggiuntive relativamente alla risorsa in esame.
17
____________________________________________________________________
- rdfs:isDefinedBy (è una sotto proprietà di rdfs:seeAlso)
Può essere usata per indicare un’ulteriore risorsa che definisca ulteriormente la
risorsa in esame (S rdfs:isDefinedBy O). La risorsa O può anche non essere
reperibile, e nel caso lo fosse, su di essa non sono imposte regole di formattazione.
Nello schema delle classi base di RDF/RDF Schema(figura 1.6), gli archi
rdfs:subClassOf indicano una relazione di sottoclasse (la freccia punta verso la
superclasse) e gli archi rdf:type indicano “questo oggetto è una istanza della classe
… ” (la freccia punta verso la classe). Ovviamente le istanze della classe rdfs:Class
sono, a loro volta, delle classi.
Tale diagramma mostra come sia la classe rdfs:Class che la classe rdf:Property
sono sottoclassi della classe delle risorse rdfs:Resource. In questo modo, ciascuna
Classe (istanza della classe rdfs:Class) e ciascuna proprietà (istanza della classe
rdf:Property) saranno automaticamente anche delle risorse (ciò è comprensibile
poiché in RDF una proprietà è sempre considerata una risorsa). La classe rdfs:Class
è una classe definita come istanza di se stessa.
Figura 1.6: Diagramma rdfs:Class e rdf:property
Un diagramma più completo della gerarchia di classi di RDF/RDF Schema è invece
il seguente:
18
____________________________________________________________________
Figura 1.7: Diagramma della gerarchia delle classi di RDF(S)
Questo diagramma viene anche detto il “Meta-Schema” (o lo “Schema degli
Schemi”).
Carenze di RDF Schema
RDF Schema è sufficientemente generale per creare ontologie, ma il numero ridotto
di proprietà e classi predefinite lo rendono, a volte, poco utilizzabile praticamente.
Ad esempio, mediante RDF Schema è possibile dichiarare che la proprietà
essere_Fratello_Di è una sottoproprietà di essere_Parente_Di, dunque esprimendo,
mediante una asserzione RDF, che “B è fratello di A”, un sistema inferenziale
basato su RDF Schema sarebbe in grado di rispondere correttamente alla domanda
“B è parente di A?”.
Non altrettanto può dirsi del caso in cui volessimo interrogare il sistema dopo aver
espresso, con due asserzioni RDF, una situazione in cui “A è antenato di B” e “B è
antenato di C”: alla domanda “A è antenato di C?” il sistema non sarebbe in grado
di rispondere, poiché per mezzo del solo RDF Schema non è possibile qualificare
come transitiva la proprietà essere_Antenato_Di.
La creazione di ontologie è una attività concettualmente complessa e raffinata, che
prevede sia profonde conoscenze sul dominio che si intende modellare, sia sugli
strumenti linguistici che vengono impiegati per farlo. Le ontologie possono essere
classificate, in prima battuta, in due grandi famiglie: alla prima appartengono
ontologie, che potremmo chiamare di dominio stretto, che permettono la creazione
di tassonomie le quali, pur avendo una validità generale, risultano però ristrette ad
un ben specifico dominio (ad es., quello dei veicoli a motore).
Alla seconda famiglia appartengono ontologie, che chiameremo generali, che si
preoccupano di fornire un vocabolario di uso così generale da essere utilizzabile per
creare, in modo molto più agevole ed efficace, le ontologie di dominio stretto.
RDF(S) fanno parte di questa seconda famiglia, ma il loro vocabolario presenta
rilevanti lacune espressive, ed è pertanto opportuno estenderlo con ulteriori
19
____________________________________________________________________
strumenti linguistici ed è proprio a questo fine che sono stati sviluppati altri
linguaggi.
In aggiunta alle basilari capacità espressive offerte da RDF Schema per descrivere i
vocabolari RDF, sene possono infatti individuare altre che risultano assai utili,
benché non strettamente necessarie (considerando che, come abbiamo visto, alcuni
utili applicazioni sono già state implementate sulla base del solo RDF Schema):
queste capacità addizionali potranno essere incluse in successivi sviluppi di RDF
Schema, o in linguaggi basati su RDF.
Tra le capacità extra, non fornite da RDF Schema ma dai linguaggi per definire
ontologie, menzioniamo la possibilità di specificare che:
-Esistono vincoli sulla Cardinalità delle proprietà.
-Una data proprietà può essere Transitiva
-Una data proprietà ha una Chiave (identificatore univoco) per istanze di una
particolare classe.
-Due diverse classi (aventi riferimenti URI diversi) rappresentano in realtà il
medesimo concetto.
-Due diverse Istanze (aventi riferimenti URI diversi) rappresentano in realtà lo
stesso individuo.
-Nuove classi sono definite per Combinazione di altre classi (ad esempio, mediante
l’Unione o l’Intersezione).
-Due classi sono Disgiunte, ovvero nessuna risorsa può essere istanza di entrambe
le classi.
1.1.3.2 Extensible Markup Langage (XML)
XML e l’interoperabilità sintattica
Al pari di HTML, anche XML (eXtensible Markup Language) discende da SGML
(Standard Generalized Markup Language), madre di tutti i linguaggi di markup.
Nato come raccomandazione del W3C nel 1998, XML, assieme alle numerose
tecnologie ad esso collegate, ha beneficiato di un consistente supporto industriale ed
ha determinato una profonda rivoluzione nel mondo del software (non solo in
ambito web) tanto da essere da alcuni ribattezzato “L’ASCII del terzo millennio”.
Vediamo brevemente come si presenta un documento XML: innanzitutto
osserviamo che si tratta di un file di puro testo (può essere facilmente prodotto con
un qualunque text-editor) ed è pertanto assolutamente platform-independent.
Notiamo poi che questa caratteristica gli conferisce una migliore resistenza ai danni:
a differenza di molti formati compressi o proprietari per i quali la perdita anche di
un solo byte può rendere illeggibile l’intero documento, in XML (essendo plain
text) la perdita di alcuni byte non preclude la leggibilità della parte di testo
rimanente. In XML i nomi dei tag non sono predeterminati (come in HTML) ma
possono essere scelti arbitrariamente, un documento XML consiste così in un
insieme correttamente annidato di tag aperti e chiusi, detti elementi: se esso rispetta
tutte le regole sintattiche di XML (quali: chiusura di ciascun tag aperto, i tag aperti
per ultimi devono chiudersi per primi, nomi dei tag scelti in conformità con
particolari specifiche, etc.) allora viene definito well-formed (ossia ben formato
sintatticamente e dunque leggibile da un qualunque parser XML).
Gli elementi sono quindi i blocchi base di ogni documento XML e quella che si
viene a creare è una struttura ad albero.
20
____________________________________________________________________
Un esempio è il seguente codice XML:
<?xml version="1.0" encoding="ISO-8859-1"?>
<LIBRO>
<TITOLO> I Promessi Sposi </TITOLO>
<AUTORE>
<NOME> Alessandro </NOME>
<COGNOME> Manzoni </COGNOME>
<DATA_DI_NASCITA> 1785-03-07 </DATA_DI_NASCITA>
</AUTORE>
<PREZZO> 10 </PREZZO>
</LIBRO>
Ogni documento XML inizia con la dichiarazione di aperture che indica la versione
delle specifiche (in questo caso la 1.0) e il tipo di caratteri utilizzati (ISO-8859-1:
Latin-1/West European).
Ciascun elemento può inoltre avere (all’interno del tag di apertura) un numero
arbitrario di coppie attributo-valore che consentono di qualificare ulteriormente
l’informazioni in esso contenuta, ad esempio:
<PREZZO valuta=”Euro”>10</PREZZO>
1
XML non fa elaborazioni, ma sono i Parser XML che permettono ad una
applicazione di accedere direttamente ai dati XML. Ogni parser deve per lo meno
recuperare e leggere il documento XML, assicurarsi che il documento soddisfi
determinati canoni di struttura (ben formato, valido), rendere disponibile
all’applicazione il contenuto del documento.
XML Schema Definition (XSD)
Finora ci siamo limitati ad analizzare l’aspetto sintattico dei documenti XML, ora
invece ci occuperemo di come sia possibile esprimere delle specifiche sulla loro
struttura dati, così da permettere un controllo più approfondito sulla loro
rispondenza alle nostre aspettative (o, per meglio dire, alle aspettative delle
applicazioni incaricate di processarli). I documenti che, oltre ad essere leggibili
(ovvero sintatticamente corretti), risultano conformi a tali specifiche vengono
definiti validi (ossia accettabili dal punto di vista del loro contenuto informativo).
1 Esistono due modelli di Parser XML: il modello tree-based (DOM - Document Object Model) e sisto quello event-based
(SAX - Simple Api for XML). Il primo genera in memoria una versione ad albero del documento di partenza, sulla quale
lavora l'applicazione; il secondo genera eventi man mano che incontra gli elemento xml, inviandoli all'applicazione che li
interpreterà.
21
____________________________________________________________________
XML Schema è stato appositamente elaborato dal W3C per consentire di descrivere
2
la struttura dei documenti XML, con maggiore espressività rispetto al DTD ed in
maniera più aderente alle necessità degli sviluppatori.
La sua particolarità è quella di essere descritto attraverso una sintassi XML: ciò non
deve stupire in quanto XML è un metalinguaggio e può quindi essere utilizzato per
rappresentare altri linguaggi di markup.
Tutti i documenti XSD devono presentare un elemento root (radice) di nome
schema
e
devono
fare
riferimento
al
namespace
http://www.w3.org/2001/XMLSchema# (di norma il prefisso utilizzato è xsd).
XML Schema consente la definizione di:
elementi, attributi e relazioni (come le DTD)
tipi di dato
vincoli (range, lunghezza stringa, precisione decimale, …)
XSD riconosce un certo numero di tipi semplici, a loro volta suddivisi tra tipi
semplici primitivi e tipi semplici derivati: questi ultimi sono ottenuti a partire dai
tipi semplici primitivi, attraverso forme di restrizione o di generazione di liste.
Essi comprendono un insieme di tipi di dato comunemente usati in programmazione
(quali Boolean, sting, float, ….): possono essere utilizzati come contenuto testuale
di elementi o attributi ma non possono contenere al loro interno la definizione di
altri elementi o attributi.
Se desideriamo definire elementi che possano contenere al loro interno non solo
testo, ma anche altri elementi o attributi dobbiamo creare un tipo complesso: ad
esempio, se volessimo progettare uno schema da associare all’elemento AUTORE
(incontrato precedentemente) potremmo definire un tipo complesso Type_Autore
come una sequenza di elementi semplici presenti al suo interno, in questo modo:
<xsd:complexType name="Type_Autore">
<xsd:sequence>
<xsd:element name="NOME" type="xsd:string" />
<xsd:element name="COGNOME" type="xsd:string" />
<xsd:element name="DATA_DI_NASCITA" type="xsd:date" />
</xsd:sequence>
</xsd:complexType>
2 DTD( TD Document Type Definition). Fino al 2 Maggio 2001 (data di rilascio della raccomandazione del W3C che
definisce la grammatica XML Schema Definition), DTD è stato l’unico vero standard di validazione del contenuto XML.
Occorre precisare fin da subito che DTD era preesistente ad XML e non era stato originariamente concepito come linguaggio
di descrizione per documenti XML; ne consegue che quando DTD viene impiegato per descrivere strutture dati XML esso
presenta significative lacune espressive (in particolare per quanto riguarda i tipi di dati primitivi che mette a disposizione) ed
inoltre la sua sintassi è diversa da quella di XML.
Per questi motivi, benché DTD sia molto conosciuto ed importante dal punto di vista “storico”, ai fini della validazione XML
è oggi senz’altro da preferire l’utilizzo di XML Schema che è stato espressamente progettato per questo scopo.
22
____________________________________________________________________
Limiti delle DTD: non supportano i namespace, non sono scritti in XML, non sono
estensibili, non specificano tipi di dato.
Namespace in XML
Abbiamo visto come la produzione di documenti XML lasci molto spazio al libero
arbitrio, in particolare nella scelta dei nomi da assegnare a tag e attributi: al fine di
facilitare lo scambio di dati in formato XML tra applicazioni diverse evitando
problemi determinati dalla possibile collisione di nomi, è stato introdotto il concetto
di namespace [21] (spazio di nomi). L’idea è quella di associare a ciascuna
collezione di nomi (internamente priva di conflitti) un nome che sia universale e
persistente. I nomi dei tag saranno dunque espressi nella forma:
PREFISSO:NOME_DEL_TAG in cui PREFISSO indica a quale namespace
appartiene il tag NOME_DEL_TAG.
Prima però di poter usare un namespace è necessario dichiararlo e ciò può essere
fatto indicandolo, ad esempio nel tag radice, nell’attributo riservato xmlns (Xml
Namespace).
Vantaggi di XML
Riassumiamo ora brevemente alcuni dei vantaggi offerti da XML:
-Ampi ambiti di utilizzo, grazie ai tag personalizzati
-Attitudine ad essere impiegato come formato per lo scambio dei dati tra
applicazioni e sul web
-Netta distinzione tra contenuto informativo (dati memorizzati nel file XML) e sua
presentazione
-Possibilità di verificare la validità della struttura dei dati di un documento XML
rispetto ad un insieme di regole liberamente definite mediante DTD (Document
Type Definition) o XML-Schema
-Possibilità di essere processato in modo semplice per eseguire le elaborazioni sui
dati (quali ordinamenti, filtraggi, riorganizzazioni, ….)
-Realizza un solido livello di interoperabilità sintattica (ma non semantica, vedi
paragrafo successivo)
Carenze semantiche di XML
I documenti XML hanno una loro semantica che rimane però implicita e pertanto,
non essendo definita formalmente, essa può eventualmente essere indovinata e
compresa solo dall’uomo, ma non dalla macchina. Le applicazioni che devono
scambiarsi dati in formato XML devono condividere a priori ed off-line la
conoscenza della semantica dei vari tag, infatti non esiste un meccanismo per
consentire alle applicazioni di scoprire, in un documento XML la cui semantica non
sia nota a priori, quali entità rappresentino i singoli tag e di indagare la natura delle
relazioni semantiche tra i vari tag innestati. I nomi dei tag, che spesso permettono
agli esseri umani di intuirne il significato, non sono infatti significativi per il
computer ed inoltre l’innestamento tra elementi può rappresentare molteplici
relazioni semantiche, senza però poterle specificare esplicitamente
Una ulteriore limitazione è data dal fatto che le applicazioni che trattano documenti
XML non sono capaci di trarre da essi nuova conoscenza, a meno che non siano
stati precedentemente programmati in modo opportuno, dunque la nuova
conoscenza non viene dedotta partendo solo ed esclusivamente dall’informazione
23
____________________________________________________________________
contenuta nei documenti XML, ma è necessario uno specifico intervento esterno
che sia antecedente al momento dell’elaborazione. Quello che si desidera è invece
un linguaggio che codifichi l’informazione in modo tale da avere sistemi diversi
che, basandosi unicamente sulla pura informazione contenuta nel documento,
possano inferire correttamente nuova conoscenza senza utilizzare nulla di esterno.
Un altro problema è costituito dal fatto che possono essere date diverse
rappresentazioni XML di una stessa informazione e le applicazioni si costruiscono
internamente delle strutture dati ad albero differenti per ciascuna di queste
rappresentazioni.
Da quanto esposto consegue che XML può essere considerato il mattone del
“Syntactic Web” (nel quale i costrutti sintattici sono dotati di significato implicito
solo in virtù di accordi off-line inaccessibili alle macchine), ma non potrà essere il
building block del “Semantic Web”.
Questo compito, nelle intenzioni del comitato W3C, sarà infatti affidato al
successivo livello.
1.1.3.3 Ontology Web Language(OWL)
L’OWL (Ontology Web Language) è un linguaggio per definire ed istanziare
ontologie Web. “Ontologia” è un termine preso in prestito dalla filosofia che si
riferisce alla scienza della descrizione dei tipi di entità esistenti nel mondo reale e
del modo in cui esse sono tra loro relazionate. Un’ontologia OWL può includere la
descrizione di classi, proprietà e delle loro istanze. A partire da una siffatta
ontologia, la semantica di OWL specifica come derivare le sue logiche
conseguenze: fatti non letteralmente presenti nell’ontologia ma implicati da essi.
Queste implicazioni possono essere basate su un singolo documento o su documenti
multipli, magari distribuiti sulla rete, che sono stati “fusi” tra loro per costituire un
unico insieme di fatti sui quali “ragionare”.
Ma perché le attuali tecnologie non sono sufficienti? E cosa offrono le ontologie
che XML e XML Schema non sono in grado di fornire?
• XML rende disponibile una mera sintassi superficiale per strutturare i documenti,
ma non impone nessun vincolo semantico sul loro significato.
• XML Schema è semplicemente un linguaggio per regolamentare la struttura dei
documenti XML e estendere l’XML attraverso i datatype..
• RDF è un modello basato sui dati (data-modello) dedicato agli oggetti (“risorse”)
ed alle relazioni intercorrenti fra essi; fornisce una semplice semantica e può
rappresentare questi data-modelli in sintassi XML.
• RDF Schema è, in fine, un vocabolario per descrivere proprietà e classi di risorse
definite in RDF, con una semantica basata quasi esclusivamente su gerarchie di
generalizzazione/specializzazione.
L’OWL offre, in aggiunta alle caratteristiche citate, nuovi vocabolari per
rappresentare le entità del dominio in esame: relazioni tra classi (es. predicare la
disgiunzione), cardinalità (es. “esattamente uno”), uguaglianza, una maggiore
24
____________________________________________________________________
tipizzazione delle proprietà e delle loro caratteristiche (es. “simmetria”,
“transitività”), classi enumerative, e così via.
Il linguaggio OWL prevede tre sottolinguaggi secondo un livello progressivamente
più elevato di espressività:
• OWL Lite è adatto a quegli utenti che necessitano di una classificazione in
gerarchie e di semplici vincoli. Per intendersi, sebbene OWL Lite supporti i vincoli
di cardinalità, esso consente solo valori di 0 o 1. È previsto che saranno presto
disponibili tool per supportare questa versione più semplice del linguaggio e che
quindi essa potrà imporsi come strumento leader nella definizione (e migrazione) di
tesauri e tassonomie.
• OWL DL è stato progettato per quegli utenti che vogliono la massima espressività
senza perdere in completezza computazionale (è garantito che tutte le implicazioni
saranno computate) e in decidibilità (tutte le computazioni saranno completate in un
tempo finito) nei “sistemi di ragionamento”. L’OWL DL include tutti i costrutti del
linguaggio al pari delle loro restrizioni, quale la separazione dei tipi: una risorsa
dichiarata come classe non può essere allo stesso tempo un individual o una
proprietà, ed una proprietà non può essere contemporaneamente anche una classe o
un individual. L’OWL DL è così denominato per la sua affinità con le description
logics, un campo di ricerca che studia una particolare porzione decisionale della
logica di base. Esso è stato progettato proprio per supportare il settore delle
description logic esistente, e possiede specifiche proprietà computazionali per i
“sistemi di ragionamento”.
• OWL Full si rivolge agli utenti che vogliono la massima espressività e la “libertà
sintattica” di RDF, pur rinunciando alle garanzie computazionali. Ad esempio, in
OWL Full una classe può essere trattata simultaneamente come una collezione di
individual e come un singolo. OWL Full consente ad un’ontologia di accrescere il
significato del vocabolario predefinito (RDF o OWL) a disposizione. È piuttosto
improbabile che tutti i software per la gestione delle ontologie saranno in grado di
supportare tutte le caratteristiche di OWL Full.
1.2. Ontologie
Nella filosofia, l'ontologia, la branca più fondamentale della metafisica, è lo studio
dell'essere o dell'esistenza nonché delle sue categorie fondamentali. In ambito
tecnico il termine è stato ripreso restringendo il suo significato ad una generica
specificazione di termini e relazioni da utilizzarsi nell'ambito di un dato dominio.
Prendiamo ora come esempio alcune definizioni di letteratura:
25
____________________________________________________________________
La definizione di Ontologia secondo Gruber
La definizione più citata di ontologia fu data da Tom Gruber nel 1993. Un'ontologia
è una esplicita specificazione di una concettualizzazione. La definizione di Gruber
costruisce l'idea che la formalizzazione del dominio di conoscenza inizia con la
concettualizzazione del dominio [Genesereth e Nilsson 1987], cioè è
l'identificazione degli oggetti che si è ipotizzato esistano nel mondo e delle relazioni
tra loro.
Secondo Gruber un'ontologia è una quintupla composta di classi, istanze, funzioni,
relazioni, assiomi. Le classi corrispondono alle entità del dominio, le istanze sono
gli oggetti che stanno nel dominio, le funzioni e le relazioni collegano le entità al
dominio, ed in fine gli assiomi che limitano il senso e l'uso delle classi, istanze,
funzioni e relazioni.
La definizione di Ontologia secondo Guarino
Un'ontologia secondo Guarino, è invece: un set di assiomi logici progettati per
considerare il senso di un vocabolario.
Da questa definizione nasce la relazione tra una concettualizzazione e l’ontologia
che la specifica e la formalizza. La definizione di Gruber è così stata estesa
prendendo non solo la concettualizzazione ma anche il linguaggio usato per
descriverla ed un insieme di assiomi associati con essa. In questo senso un'ontologia
è un linguaggio dipendente mentre una concettualizzazione è un linguaggio
indipendente.
L’RDF pur essendo un linguaggio potente per la rappresentazione della conoscenza,
non ha modo di operare in modo autonomo delle inferenze o delle deduzioni
ragionate. Per questo occorre un livello ulteriore del web semantico che permettta di
associare a dei concetti a regole logiche di uso, nasce così l’ontologia.
Nell'ambito informatico, una ontologia è il tentativo di formulare uno schema
concettuale esaustivo e rigoroso nell'ambito di un dato dominio; si tratta
generalmente di una struttura dati gerarchica che contiene tutte le entità rilevanti, le
relazioni esistenti fra di esse, le regole, gli assiomi, ed i vincoli specifici del
dominio.
La costruzione di un’ontologia non è altro che la definizione dei caratteri
fondamentali di quanto può venire accettato in un determinato mondo possibile,
sottoinsieme, nel nostro caso, dei possibili mondi di significato del web semantico.
Un’ ontologia è un vocabolario che contiene collezioni di asserzioni, che
definiscono le relazioni tra i concetti e specificano le regole logiche per ragionare su
di essi .
Elementi di un’ontologia:
Classi
Generalmente organizzati in tassonomie. La “classe” viene utilizzata in senso lato
per descrivere i concetti (le classi di individui) che si vuole rappresentare (es.
PERSONA, GENITORE, MADRE…).
26
____________________________________________________________________
FEMMINA
DONNA
PERSONA
GENITORE
MADRE
PADRE
Figura 1.8: Classi
Proprietà e attributi
Rappresentano le relazioni esistenti tra le classi del dominio
(es. “le MADRI sono GENITORI”, “i GENITORI hanno figli che sono
PERSONE”…).
FEMMINA
PERSONA
ha_figli
DONNA
MADRE
GENITORE
(1,n)
is_
a
PADRE
Figura 1.9: Proprietà ed attributi
• Il legame tra MADRE e GENITORE (is_a) indica che “le MADRI sono
GENITORI” e definisce una gerarchia tra concetti, provvedendo una base per
l’eredità di proprietà: un concetto specifico eredita le proprietà del concetto più
generale che lo sussume.
• E’ possibile rappresentare anche proprietà più complesse della relazione is_a.
• Ad esempio, è possibile definire la proprietà ha_figli, che connette le due classi
GENITORE e PERSONA, specificando degli attributi che ne vincolano
l’applicazione: v/r denota una restrizione sulle classi che possono soddisfare la
proprietà, mentre (1,n) rappresenta una restrizione di cardinalità.
• L’esempio può essere letto come “un GENITORE è una PERSONA che ha
almeno 1 figlio e tutti i figli che ha sono PERSONE”.
Assiomi
• Vengono utilizzati per modellare in maniera esplicita espressioni in ogni caso
vere.
• Possono essere utilizzati per diversi scopi: definire il significato dei vari
componenti dell’ontologia, definire relazioni complesse, verificare la correttezza
dell’informazione specificata o dedurre nuova informazione.
(es. disjoint (MADRE, PADRE) esprime il fatto che un elemento della classe
PADRE non può mai essere anche un elemento della classe MADRE).
27
____________________________________________________________________
GENITORE
MADRE
PADRE
Figura 1.10: Assiomi
Individui
Sono i singoli oggetti contenuti in una classe, a vari livelli di generalità, a seconda
dello scopo dell’ontologia.
FEMMINA
PERSONA
DONNA
GENITORE
GENITORE
PADRE
MADRE
Luisa, Anna,
Maria,…
Luca,
Mario,
…
Figura 1.11: Individui
Linguaggio
Una volta selezionati i componenti dell’ontologia occorre definirli in maniera
esplicita. E’ possibile distinguere ontologie diverse sulla base del linguaggio
utilizzato per definirne i componenti:
Informali: espresse tramite linguaggio naturale
• Semi-formali: espresse tramite linguaggio artificiale definito formalmente
• Formali: espresse in un linguaggio dotato di semantica formale, teoremi e
proprietà quali validità e completezza.
•
Le ontologie possono differire non solo nel contenuto ma anche nella loro struttura
ed implementazione. Un primo aspetto di diversificazione è senza dubbio il livello
di descrizione.
La modalità di costruzione di un’ontologia varia a seconda di chi si occupa di
realizzarla. In particolare un’ontologia può assumere la forma di:
• un semplice lessico o vocabolario controllato,
• un tesauro organizzato in categorie,
• una tassonomia dove i termini sono relazionati gerarchicamente, ognuno dei quali
possiede proprietà che lo distinguono dagli altri,
28
____________________________________________________________________
• ontologie propriamente dette, nelle quali si possono definire proprietà e concetti, e
dove questi ultimi possono avere relazioni con nome (named relationship) con altri
concetti come ad esempio “cambia l’effetto di” e “compra da”.
Un altro aspetto importante da considerare è l’ambito concettuale delle ontologie.
Queste possono variare in relazione al dominio di riferimento ed alla natura del
contenuto. La distinzione più evidente che si può operare è tra:
•
•
ontologie di scopo,
ontologie di dominio.
Si chiamano ontologie di scopo (task ontology) quelle che rappresentano la struttura
dei processi produttivi, mentre quelle che forniscono le descrizioni degli oggetti
specifici dell’applicazione sono dette di dominio (domain ontology). Queste ultime
stabiliscono le relazioni che si possono osservare quando le informazioni da
modellare sono espresse in linguaggio naturale.
Un’altra distinzione si basa sull’istanziazione. Tutte le ontologie possiedono due
componenti fondamentali. La prima è quella che è stata chiamata la componente
terminologica. Questa è approssimativamente quello che conosciamo come schema
di un database relazionale o di un documento XML. Essa definisce i termini e la
struttura dell’area di interesse per la quale l’ontologia è stata scritta. La seconda
componente, quella asserzionale, popola l’ontologia con entità che manifestano una
determinata definizione terminologica. Queste entità possono essere considerate o
come concetti o come entità individuali, ovvero come entità che vanno istanziate o
che non derivano da nessuna concettualizzazione. Il limite tra il trattare qualcosa
come concetto o come individual è come al solito molto sottile e dipende
tipicamente dalle specifiche necessità.
Infine quello che rende due ontologie diverse tra loro è il linguaggio utilizzato per
la specifica. Le ontologie, infatti, non sono costruite tutte allo stesso modo. E’
possibile utilizzare diversi linguaggi, inclusi quelli di logica generale come il
Prolog. Tuttavia, i più utilizzati sono quelli che sono stati concepiti (e qualche volta
ideati) appositamente per la creazione delle ontologie.
Il modello della Open Knowledge Base Connettivity (OKBC) e linguaggi come KIF
(e il suo immediato successore CL – Common Logic) ne sono i primi esempi: essi
sono diventati la base per nuovi linguaggi ontology-oriented. Ci sono anche diversi
linguaggi dedicati alla costruzione delle description logic. Tra di essi troviamo
Loom e DAML+OIL, il quale si è evoluto nello standard per la descrizione delle
ontologie: OWL, l’Ontology for Web Language. Ogni applicazione, ogni intenzione
di scopo applicata ad un dominio, utilizzerà una sua propria ontologia. Nasce quindi
la difficoltà di collegare fra loro le varie ontologie, conciliando le diverse
semantiche utilizzate. L'operazione che consiste nel collegare ontologie che
definiscono gli stessi oggetti ma con una semantica differente è chiamata Mapping.
Si potrebbe pensare di risolvere il problema attraverso la definizione di una
Ontologia Globale; questa soluzione presenterebbe il grande vantaggio di richiedere
un unico mapping: ogni diverso schema dovrebbe mapparsi soltanto all'ontologia
globale che funzionerebbe così come una lingua universale, traduzione universale
dei vari linguaggi usati. Questo tipo di soluzione si baserebbe su transazioni di
29
____________________________________________________________________
comunicazione punto a punto e comporterebbe un accordo totale, ad ogni livello,
sul significato della semantica utilizzata.
Ovviamente questa visione è improponibile. L'accordo su tutto non è pensabile e,
qualora fosse anche raggiunto, sarebbe incapace di dare risposta a quei naturali
mutamenti del dominio descritto che inevitabilmente sorgono nel tempo.
1.3. Applicazioni del web semantico
3
È Tim Berners-Lee a chiarire che non esiste una precisa Killer Application del web
semantico, ciò a motivo del fatto che è esso stesso una applicazione rivoluzionaria
ed è una infrastruttura di portata generale, della quale si gioveranno molte delle
applicazioni già esistenti e sulla quale potranno essere sviluppate applicazioni a tal
punto innovative da essere oggi difficilmente immaginabili. Possiamo comunque
elencare alcuni dei principali campi applicativi che trarranno i maggiori benefici
dalla costruzione del web semantico:
-Sviluppo di software ad agenti intelligenti
Essi sono in grado di eseguire in modo personalizzato, trasparente ed autonomo,
transazioni complesse, sollevando l’utente dall’onere di dover ricercare le
informazioni sui vari passi delle differenti procedure e liberandolo dalla necessità di
districarsi tra moduli software incompatibili tra loro.
Ad esempio, un agente che arriva al sito di una clinica ospedaliera potrà non solo
(come accade oggi) leggerne le parole chiavi (trattamento, medicine, terapia, ecc..),
ma capirà anche che il Dr. Rossi è lo specialista nel campo che ci interessa (es.
Oculistica) e lavora nella clinica, ad esempio, il Lunedì mattina e il Venerdì
pomeriggio; l’agente sarà così in grado di fissare, senza la nostra supervisione, un
appuntamento che risulti compatibile con gli impegni memorizzati nella nostra
agenda personale.
Un altro esempio può essere la pianificazione di una vacanza: la prenotazione di
viaggio e albergo, come pure l’organizzazione dell’agenda delle escursioni e delle
visite ai musei, potranno essere resi molto più semplici grazie a software di questo
tipo che, opportunamente informati sulle proprie preferenze, lasceranno all’utente il
solo compito di scegliere tra le varie opzioni risultanti.
Anche agenti che non erano progettati per lavorare assieme possono scambiarsi sia
dei dati, se questi sono dotati di semantica, sia le “prove” delle loro risposte (ossia
la catena di deduzioni logiche per mezzo della quale sono state ottenute), a patto
che tali dimostrazioni vengano comunicate attraverso l’apposito linguaggio
unificante del web semantico.
3 Una killer Application di una tecnologia è l’applicazione che porta l’utente a provarla e poi ad usarla con assiduità (ad es. il
telefono cellulare può essere considerato la Killer Application della tecnologia senza fili).
30
____________________________________________________________________
-Servizi di Ricerca
"The web is getting fat": se ne parla ormai da anni, il web sta diventando troppo
grande, ingrassando al ritmo di decine di migliaia di pagine al giorno. Ingrassano i
database di pubblicazione, ingrassano gli archivi e il numero di informazioni lievita
paurosamente. La sua incontrollabilità inizia a disturbare, i sistemi di ricerca
tradizionali segnano il passo e si fanno sempre più pressanti gli allarmi per un
miglior controllo dei contenuti. Inoltre gli utenti cominciano a mostrarsi
insofferenti.
Il loro livello di attenzione è un bene prezioso, da non dilapidare: è forse il bene più
prezioso in rete, più di tutti gli indicatori economici standard, più dei contatti e più
delle visite. L'utente ha una sola esigenza ormai: vuole raggiungere in poco tempo
l'informazione che cerca e quella soltanto, il resto è rumore, il resto non è più solo
superfluo, ma inizia a diventare fastidioso. In questo contesto si inserisce la
proposta di un web semantico popolato da asserzioni, nel quale non verranno più
indicizzate le parole-chiave, ma gli oggetti RDF. Potrà così essere superato l’attuale
approccio sintattico basato su keywords, cosicché pagine sintatticamente diverse ma
semanticamente correlate potranno essere restituite assieme come risultato di una
ricerca. Ugualmente, i search-engines saranno capaci di distinguere tra pagine
sintatticamente simili ma differenti dal punto di vista del contenuto, così da evitare,
ad esempio, che effettuando una interrogazione con la keyword “Dante”
(intendendo il grande scrittore) vengano restituiti tra i risultati della ricerca
documenti non rilevanti (ad es. quelli contenenti dei riferimenti ad omonimi oppure
a strade, scuole, fondazioni intitolate al Sommo Poeta). Inconvenienti di questo tipo
sono oggi assai frequenti, stante l’impossibilità di selezionare un particolare
significato da attribuire alla stringa “Dante”. L’efficienza dei motori di ricerca
migliorerà a tal punto da presentare il web come un gigantesco database, piuttosto
che come un gigantesco libro; essi saranno infatti in grado di rispondere a query
complesse, del tipo: aziende (soggetto) che hanno come servizio (predicato) la
fornitura di scarpe (oggetto).
Ad oggi, effettuare interrogazioni di questo tipo non é possibile, nel senso che si
possono solamente proporre tutte assieme le tre keywords “azienda”, “servizio” e
“scarpe”, ma non potremo mai esprimere il legame fra di esse, ed è proprio questa
la causa delle imprecisioni degli odierni motori di ricerca. Grazie alla possibilità
offerte dall’allargamento/restringimento semantico delle query verrà inoltre favorita
la navigazione per prossimità semantica piuttosto che quella basata sul caotico
attraversamento dei link.
-E-commerce
L’uso delle ontologie potrà facilitare la comunicazione machine-based tra venditore
e compratore, consentendo il riutilizzo su mercati diversi delle stesse descrizioni.
- Integrazione di DataBase
Sono applicazioni particolarmente rilevanti in ambito aziendale laddove è richiesta
la condivisione di informazioni tra sistemi informativi eterogenei (integrazione dei
dati B2B, Business to Business). Mentre in un database locale il significato di ogni
singolo campo è ben noto a tutti, nei database appartenenti al Web Semantico
ognuno può assegnare un nome ai propri campi con un proprio significato.
31
____________________________________________________________________
- Web services
Il web si sta evolvendo dall’essere un fornitore di documenti ed immagini all’essere
un fornitore di servizi: uno dei requisiti per lo sviluppo dei web services è la
capacità di descrivere l’interfaccia, ovvero l’aspetto estreno mediante il quale
comunicano le applicazioni. Esattamente come, fin dai primi tempi del web, le
interfacce di programmazione sono state accessibili mediante HTML Form, così ora
i programmi possono scambiarsi le informazioni utilizzando protocolli come
4
SOAP .
La potenza dei Web Services risiede non solo nella loro interoperabilità ed
estensibilità, ma anche nel fatto che possono essere combinati, in modo da ottenere
servizi complessi, semplicemente facendo interagire un insieme di programmi che
forniscono, ognuno, un servizio semplice.
Uno dei problemi di fondo è la comunicazione tra i Web services stessi. Il problema
può essere risolto solo se si dispone di un adeguato vocabolario, o, meglio, di
ontologie. Grazie alle ontologie, le descrizioni dei servizi offerti diverranno più
ricche di semantica e potranno essere interpretate in modo piu completo dagli agenti
intelligenti.
Altro problema è quello della localizzazione, da parte di agenti software, di un
servizio che esegua una specifica funzione: servizi e agenti possono infatti
depositare in elenchi sul web(tipo pagine gialle) le descrizioni delle loro funzioni,
ma è necessario che queste siano espresse in un linguaggio comune che ne permetta
un facile reperimento.
Nell’ottica delle architetture orientate ai servizi web, la modellazione dell’ontologia
diventerà un aspetto di fondamentale importanza.
- Domotica
Con gli URI, si è detto, è possibile nominare qualunque cosa, anche gli oggetti
fisici, e dunque si può usare RDF per descrivere anche dei dispositivi(quali
televisori, impianti stereo, cellulari, …., ma anche semplici elettrodomestici, quali,
ad es. tostapane,…). Ciascuno di questi è cioè in grado di dichiarare, nel linguaggio
comune di RDF, le proprie funzionalità e modalità di controllo: su queste basi si
può realizzare quella che viene detta “automazione domestica” (o “domotica”),
ovvero la configurazione semplice e personalizzata del funzionamento integrato di
più apparecchi.
4 SOAP
(Simple Object Access Protocol) è un protocollo leggero (sviluppato da Microsoft) per lo scambio di informazioni tra
applicazioni in un ambiente decentralizzato e distribuito.SOAP si basa principalmente sul protocollo HTTP (HyperText
Transfer Protocol) e su XML.
32
____________________________________________________________________
A questo obiettivo è rivolto lo sviluppo di uno standard, basato su RDF, detto
5
CC/PP (Composite Capability / Preference Profile) che si prefigge di descrivere
sia le capacità funzionali dei diversi dispositivi (ad es., le dimensione dello
schermo), sia le preferenze dell’utente.
- e-Learning
Organizzare una piattaforma di e-learning secondo strutture ontologiche può portare
immediati vantaggi, in quanto organizzando i vari materiali didattici in unità
(learning objects ), ogni singola unità può essere collegata alle altre e ricomposta in
un nuovo corso. Esistono già alcune applicazioni: http://edutella.jxta.org e
http://www.merlot.org.
- Voice Browsing
Finora siamo abituati ad accedere alle risorse di Internet attraverso un PC e ad un
software di navigazione ipertestuale e multimediale (noto come “Browser”), questo
tipo di approccio potrebbe però presto essere affiancato da esso vocale ai contenuti
web dotati di una interfaccia vocale (detta VUI, “Vocal User Interface”).
È possibile distinguere tre componenti fondamentali necessari alla realizzazione del
Voice Browsing: il primo é il sistema di ascolto (software di speech recognition),
che effettua la trasformazione del segnale acustico di input, prodotto da un utente
umano, in una stringa testuale. Il secondo componente é un sistema di
comprensione per l’estrazione dei dati rilevanti nell’ambito del testo riconosciuto e
la loro interpretazione semantica. La comprensione di una richiesta consente la
ricerca delle relative informazioni e la successiva preparazione di una informazione
di riscontro: il Web Semantico costituisce la fonte informativa su cui eseguire la
ricerca automatizzata. Il terzo é invece un sistema di uscita con tecnologia TTS
(Text To Speech) grazie al quale l’informazione testuale viene trasformata (grazie a
software di speech synthesis) in comunicazione verbale di output che può essere
resa disponibile anche su dispositivi mobili privi di schermo. In questo modo,
l’informazione di Internet è fruibile in qualunque luogo, in qualunque istante e su
qualunque apparecchio.
La rappresentazione della conoscenza è un campo che attualmente sembra avere la
reputazione di essere all'inizio interessante, ma che non sembra scuotere il mondo
così come speravano alcuni dei proponenti. Esso aveva senso ma era di uso limitato
su piccola scala, ma mai su larga scala. Questo è esattamente lo stato in cui era il
settore dell'ipertesto prima del Web. Ogni settore ha fatto alcune assunzioni
centralistiche se non in filosofia, in implementazioni, che hanno impedito una
diffusione globale. Ma ogni settore era basato sull'idea della rappresentazione della
conoscenza.
5 Graham Klyne, Franklin Reynolds, Chris Woodrow, Hidetaka Ohto, Johan Hjelm, Mark H.
Butler, Luu Tran, “Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 1.0”, W3C
Recommendation , 15 gennario 2004. http://www.w3.org/TR/2004/REC-CCPP-struct-vocab-20040115/
33
____________________________________________________________________
Il Web Semantico rappresenta ciò che potremo avere se realizzeremo lo stesso
processo di globalizzazione di Rappresentazione della Conoscenza che il Web
inizialmente realizzò per l'Ipertesto. Una delle migliori cose sul Web è che ci sono
tante cose differenti per tante persone differenti. Il Web Semantico che sta per
venire moltiplicherà questa versatilità per mille. Per alcuni, la caratteristica
principale del Web Semantico sarà la facilità con la quale il PDA, il laptop, il
desktop, il server e l'auto comunicheranno l'un l'altro. Per altri, essa sarà
l'automazione di decisioni aziendali che precedentemente dovevano essere svolte in
modo laborioso. Per altri ancora, essa sarà l'abilità di dare la fiducia a documenti sul
Web e la facilità con la quale potremo trovare le risposte alle nostre domande - un
processo che è attualmente realizzato con frustazione.
In futuro dato un ampio Web semantico di dichiarazioni, l'odierna tecnologia dei
motori di ricerca applicata alle pagine HTML presumibilmente tradurrà
direttamente in indici fatti non di parole, ma di oggetti RDF. Questo permetterà una
ricerca del Web molto più efficiente come se esso fosse un gigantesco database,
piuttosto che un gigantesco libro.
Qualunque sia la causa, già ognuno può trovare una ragione per supportare questa
grande visione del Web Semantico. Sicuramente è una lunga strada da percorrere e non esiste garanzia che la percorreremo - ma già abbiamo fatto un pò di
progresso.
34
____________________________________________________________________
Capitolo 2.
L'uso del trust in ambienti centralizzati o
distribuiti.
2.1. Definizione di TRUST
Uno degli interrogativi più importanti legati al web semantico riguarda la fiducia
che si può riporre in un tale sistema. Chi può dare fiducia al sistema di asserzioni
che compongono il web semantico? Poiché esiste la regola "ogni cosa può dire ogni
cosa su ogni cosa", chi può fermarmi? A questo punto assume forte rilevanza il
livello di Trust, composto principalmente da tecnologie per la gestione della Firma
Digitale e dal così detto “Web of Trust”.
Basata su lavori in matematica e crittografia, la firma digitale fornisce la prova che
una certa persona ha scritto (o è d'accordo con) un documento o dichiarazione. Così
vengono firmate digitalmente le dichiarazioni RDF. In questo modo si può essere
sicuri dell’identità di chi le ha scritte (o almeno confermato la loro autenticità).
È chiamato “Web of Trust” quella prospettiva che vorrebbe associare ai
collegamenti tra i nodi della rete un grado di affidabilità, che si possa propagare
parallelamente ai collegamenti tra i nodi. Per esempio Dici al tuo computer che tu
hai fiducia nel tuo migliore amico, Robert. Robert sembra essere piuttosto popolare
sul Web e ha fiducia di molte persone. E naturalmente, tutte le persone di cui ha
fiducia, hanno fiducia di un altro gruppo di persone. Ognuna di queste persone ha
fiducia in altre persone e così via. Queste relazioni di fiducia formano il "Web of
Trust", e ognuna di queste relazioni è associata a un grado di fiducia (o di sfiducia).
Le manifestazioni del trust sono facili da riconoscere perché le sperimentiamo e ci
basiamo su di esse ogni giorno, ma allo stesso tempo il trust è difficile da definire
poiché si presenta in molte forme differenti. La letteratura sul trust può anche essere
abbastanza confusa a riguardo poiché il termine è utilizzato in una grande varietà di
significati. Presentiamo quindi diverse definizioni:
Definizione 1 (Reliability Trust) Il trust è la probabilità soggettiva attraverso la
quale un individuo, A, si aspetta che un altro individuo, B, esegua una determinata
azione che fa si che la sua attività sia efficiente.
Questa definizione include il concetto di dipendenza sul gruppo di trust e la
probabilità di affidabilità del party stesso. Secondo Falcone e Castelfranchi
infatti[1] avere alto trust su di una persona non significa necessariamente che si sia
disposti ad entrare in una situazione di dipendenza da essa.
35
____________________________________________________________________
Definizione 2 (Decision Trust) Il trust qualcosa o qualcuno al quale un certo
gruppo di persone vorrebbe dipendere in una certa situazione con una sensazione
di relativa sicurezza, anche se sono possibili conseguenze negative.
L’aspetto vago di questa definizione la rende più generale. Include infatti
implicitamente ed esplicitamente l’aspetto di una nozione di trust nella quale ha
importanza anche la dipendenza sull’entità o sul gruppo di appartenenza,
l’affidabilità dell’entità o del gruppo, l’utilità nel senso che una utilità positiva
scaturisce da un guadagno positivo, ed infine un certo rischio accettato da un
gruppo di persone, viste esperienze precedenti.
La difficoltà di catturare la nozione di trust in modelli formali in un modo
significativo deve quindi prendere in considerazione sia il rischio che l’affidabilità.
Definizione 3 (Reputazione) La reputazione è ciò che è generalmente detto o
creduto del comportamento di una persona o di una cosa.
Questa definizione corrisponde alle ricerche in campo delle reti sociali, la
differenza sostanziale tra trust e reputation si può esemplificare come segue:
1-“Credo in te per la tua buona reputazione”
2-“Ti credo nonostante la tua cattiva reputazione”
Assumendo che le due affermazioni siano relative ad identiche transazioni, la 1
assume che la parte che deve dare trust è a conoscenza del trust della controparte.
La 2 sottolinea che la parte giudicante ha una conoscenza privata del soggetto da
giudicare, attraverso esperienza diretta per esempio, ed ha prevalenza anche sul
giudizio generale di un gruppo di persone.
Questo sottolinea quanto il Trust sia in ultima analisi un fenomeno personale e
soggettivo che è basato su diversi fattori evidenti, e che alcuni di essi hanno più
peso di altri.
La Reputation invece assume più il senso di una misura collettiva di veridicità
basata su esperienze o votazioni di membri in una certa comunità.
Altre definizioni piu generali:
Definizione 4 "Ottenere la fiducia del consumatore on-line per la trasparenza e
l'affidabilità della propria attività on-line è un fattore fondamentale. Ovvero la
convinzione relativa alla bontà delle qualità di una persona o di un servizio, o
anche la fede in un comportamento; la convinzione relativa al soddisfacimento di
certe aspettative in certe condizioni, oppure la convinzione relativa all'abilità e alle
buone intenzioni associate all'altro attore di un rapporto di tipo commerciale. In
altre parole, il grado di affidabilità associato da un cliente alle dichiarazioni
espresse da un venditore in grado di soddisfare specifici bisogni del mondo reale."
36
____________________________________________________________________
Definizione 5 Nell'ambito della crittografia, una web of trust (rete di fiducia) è un
concetto utilizzato da PGP, GnuPG, e altri sistemi compatibili con OPEN PGP per
stabilire l'autenticità dell'associazione chiave pubblica-utente. Sotto alcuni aspetti è
un'alternativa all'affidarsi esclusivamente ad una certificate authority (o a una
gerarchia di esse) tipico dei sistemi PKI centralizzati. Così come ci sono moltissime
reti di computer, ci sono molte reti di fiducia indipendenti, e ogni utente (attraverso
il suo certificato d'identità) può essere parte e fungere da collegamento tra molte di
esse.
Il problema del trust è assai complesso poiché porta a diversi dilemmi:
1-Quali elementi informativi sono più adatti per misurare il trust?
2-Come possono essere catalogate e raccolte queste informazioni?
3-Quale modello è migliore per computare il trust?
4-Come passare da una vista teorica ad una reale applicazione?
5-Sicurezza delle “opinioni”, fidarsi di votazioni false?
6-Definire il trust a vari livelli:server,client e agent.
7-Occorre tenere conto del tempo che passa per il calcolo del trust?( forgetting
factor, aging factor or fading factor….).
2.2 Metriche di TRUST
Le metriche di trust possono essere molteplici e differenti, sono infatti emersi un
buon numero di sistemi per il management del trust, che raccolgono e computano i
valori di trust espressi dal network su cui una comunità è basata.
Quando la comunità è costituita su modelli del tipo client-server, esiste una terza
parte che certifica il trust e raccoglie le votazioni per formare una visuale globale.
E-bay, Amazon e Sladshot sono sistemi che utilizzano feedback dagli utenti per
raccoglierli in un DataBase centralizzato. In questo caso tutti gli utenti hanno la
possibilità di accedere ai dati relativi al trust direttamente dal database centralizzato.
Quando la comunità è distribuita sul modello P2P la sfida di gestire i feedback dagli
utenti diviene molto più difficile. Non c’è un database centralizzato del trust, e, la
raccolta, gestione, aggregazione del trust deve essere concepita in modo distribuito.
In questo caso il sistema diviene più vulnerabile alla falsificazione ed agli attacchi,
ed il modello computazionale assai più complesso.
37
____________________________________________________________________
Classificazione generale in categorie di rating:
Figura 2.1:Categorie di rating
Soggettivo e specifico: misure usate per esempio in questionari di controllo dove
viene chiesto di esprimere una opinione su una certa cosa scegliendo da una certa
scala di valori.
Soggettivo e generale: misure utilizzate per esempio su e-bay.
Che utilizza il Feedback Forum on eBay che dà la possibilità a compratore e
venditore di votarsi reciprocamente come positive, negative, or neutral (i.e. 1, -1, 0).
Il totale viene poi calcolato sommando i valori. C’è inoltre una history del
comportamento dei soggetti con il numero di 0,1,-1(6 mesi fa,1mese fa e 1
settimana fa). È primitivo e può avere poco significato.
Oggettive e specifiche: usate per misure di test per prodotti oggettivamente
misurabili(verificati sul campo, reale qualità dell’oggetto).
Oggettive e generali: misure sulle reali caratteristiche di un oggetto(punteggi per
ogni caratteristica, medie , pesi diversi….).
_
Il modo più semplice di dare un rating è quello di e-bay come somma di
rating(postivi-negativi) totale, poi ci può essere un sistema più corretto che effettua
una media dei voti(Amazon), oppure una media pesata di voti in cui mettere anche
il parametro tempo(età del rating differenza col rating precedente…).
Qualunque modello scelto per misurare il trust deve garantire:
1. Accuratezza per performance di lunga durata. Il sistema deve riflettere la
confidenza di un certo voto dato. Deve anche avere la capacità di distinguere tra una
nuova entità di qualità sconosciuta ed una entità con scarsa performance a lungo
termine.
2. Pesare il comportamento corrente. Il sistema deve riconoscere e riflettere I trend
recenti nella performance di una entità. Per esempio, una entità che ha avuto un
comportamento buono per lungo tempo e comincia a calare bruscamente deve
essere velocemente riconosciuta come non affidabile.
3. Robustezza contro gli attacchi. Il sistema dovrebbe resistere ai tentativi, da parte
di terse parti, di manipolare i punteggi di trust.
38
____________________________________________________________________
4. Non eccessiva influenzabilità. Aggiungere ogni singolo voto non dovrebbe
influenzare il voto totale in modo significativo.
2.2.1 Approcci centralizzati
Un gestore di reputazione ad approccio centralizzato è un servizio indipendente che
si tiene al corrente della qualità, della credibilità e della reputazione di ogni
elemento in un insieme. Tipicamente si ha la necessità di valutare siti web, aziende,
prodotti o anche persone. Più genericamente qualunque cosa che possa essere
osservata prima di effettuare delle transazioni che la riguardino è soggetta a
reputazione.
Diverse esigenze hanno prodotto modelli per la gestione della reputazione; nel
seguito vengono presentate alcuni dei principali sistemi commerciali ad approccio
centralizzato che fanno uso di reputazione.
eBay
eBay [2] è un'asta elettronica dove ogni utente registrato che desideri vendere un
prodotto, può indire un'asta specificando i dettagli del prodotto e il prezzo base dal
quale partire. Chi sia interessato all'acquisto, dopo essersi anch'egli registrato al
servizio, ha modo di proporre un prezzo e, nel caso in cui vinca l'asta, ha il diritto (e
dovere) d'acquisto. I pagamenti avvengono in modo diretto o tramite un servizio
messo a disposizione di eBay stesso, chiamato ePay, che come una banca
elettronica, permette di trasferire denaro in modo semplice, tramite carta di credito.
eBay è stato uno dei primi siti a tener traccia della reputazione dei vari utenti che
partecipano al servizio.
Dal momento che le transazioni avvengono tra sconosciuti spesso di diversi paesi, è
infatti necessario che ci sia un metodo per valutare la credibilità dei partecipanti.
Che fare infatti, se chi vende non spedisce effettivamente la merce? Che fare se chi
compra non paga?
Ad ogni acquisto, il compratore fornisce a eBay un giudizio esteso e uno sintetico
sul venditore. Il giudizio sintetico può assumere i valori di buono, medio e scarso,
mentre il giudizio esteso è una frase che ne spieghi le ragioni. Possibili compratori
si possono sentire tranquillizzati dal riscontrare che le recenti transazioni del
venditore sono terminate con la soddisfazione dei clienti precedenti.
D'altra parte i venditori sono incentivati a mantenere un buon comportamento da
questo sistema, poichè basta una sola cattiva esperienza per rovinare la reputazione
di un venditore. eBay ha quindi un gestore di reputazione centralizzato con utenti
registrati non anonimi, cosa che implica il fatto di non poter abbandonare l'account
nemmeno in caso di pessima reputazione. Questo meccanismo è supportato inoltre
da un'assicurazione che copre parte dei danni dovuti ad un suo eventuale cattivo
funzionamento.
39
____________________________________________________________________
Siti esperti
Dove si scambiano informazioni e consigli su aree di interesse comuni tra più
soggetti.Votazioni per diverse caratteristiche che una spiegazione data da un
soggetto deve avere (chiarezza, comprensività, leggibilità, tempestività) più un
numero che demarca il prestigio(media voti ricevuti per le risposte). Metodo usato
da Allexpert.
Epinions
Epinions [3] permette di esprimere opinioni su una serie vastissima di prodotti e di
servizi in vendita in rete, dai computer palmari ai musei di NewYork. Chi abbia
necessità di acquistare un prodotto in Internet si trova spesso nella condizione di
non sapere di chi fidarsi e nel timore di spendere più denaro del necessario e di non
acquistare la scelta migliore. Epinions, grazie ai contributi degli utenti, riesce ad
attribuire una reputazione ai vari prodotti in vendita e permette di confrontarne le
caratteristiche, così da permettere di valutare la scelta migliore. Scelto il prodotto è
possibile continuare la navigazione controllando le valutazioni dei siti che lo
vendono, trovando, inoltre, un confronto sui prezzi. Questo sito ha introdotto per la
prima volta il concetto di credibilità associato agli utenti che scrivono i commenti ai
prodotti, in modo da ridurre o evitare del tutto commenti faziosi. Ogni commento
può essere giudicato utile o meno da parte degli altri lettori, giudizio che serve a
modificare la credibilità di chi lo ha scritto. Gli utenti che hanno acquisito una
credibilità molto alta hanno maggior peso nella valutazione complessiva e hanno
diritto a maggior visibilità nell'elenco dei giudizi estesi. Questo modello, chiamato
gestione a doppia reputazione, è diventato attualmente lo standard de facto,
dimostratosi infatti un'ottima soluzione.
Amazon
Amazon.com [4], una delle aziende che per prima ha sfruttato il commercio
elettronico diventando un riferimento mondiale per la vendita on-line di libri, ha da
subito incluso la possibilità di lasciare ai lettori la libertà di aggiungere commenti ai
libri in vendita. Purtroppo questa idea, che poteva apparire ingenuamente un modo
per migliorare il servizio e per coinvolgere gli utenti, si è rivelata essere un'arma
molto potente utilizzabile contro autori e libri. Infatti è capitato che alcuni libri e
alcuni autori venissero presi di mira da loro detrattori ed insultati pubblicamente,
con devastanti conseguenze sulle vendite. A questi commenti seguivano
tipicamente elogi e panegirici da parte di amici, mandando in confusione i
compratori. Ora vengono effettuati dei controlli ed è stata introdotta la doppia
reputazione.
Google
Google [5] è un motore di ricerca tra i più efficienti ed innovativi: restituisce la lista
delle pagine che soddisfano la ricerca sulla base di un valore di qualità che dipende
dal numero di documenti che si riferiscono alla pagina stessa. Questa soluzione,
difficilmente estendibile ad altri ambienti, è stata sfruttata da alcune aziende che
sono riuscite ad aumentare la propria reputazione, e quindi la probabilità di
comparire nelle ricerche, creando migliaia di pagine piene di riferimenti ai prodotti
da pubblicizzare(Questo sistema è detto PageRank).
40
____________________________________________________________________
Google PageRank
Google utilizza una tecnologia basata su hardware e software avanzato. La velocità
con cui possono essere eseguite le ricerche è attribuibile in parte all'efficienza
dell'algoritmo di ricerca e in parte all'elevato numero di PC collegati in rete, che,
insieme, contribuiscono a creare un motore di ricerca superveloce. Il nucleo
principale del software è rappresentato da PageRank, che consiste in un sistema che
permette di classificare le pagine Web in ordine di importanza. Il sistema è stato
sviluppato da Larry Page e Sergey Brin all'Università di Stanford. PageRank
continua ad essere l'elemento chiave degli strumenti di ricerca di Google.
Basato sullo specifico carattere "democratico" del Web, PageRank sfrutta la
vastissima rete di collegamenti associati alle singole pagine per determinarne il
valore. In pratica, Google interpreta un collegamento dalla pagina A alla pagina B
come un "voto" espresso dalla prima in merito alla seconda. Tuttavia, non si limita
a calcolare il numero di voti, o collegamenti, assegnati a una pagina. Oltre a
effettuare questo calcolo, Google prende in esame la pagina che ha assegnato il
voto. I voti espressi da pagine "importanti" hanno più rilevanza e quindi
contribuiscono a rendere "importanti" anche le pagine collegate. PageRank assegna
ai siti Web importanti e di alta qualità un "voto" più elevato di cui Google tiene
conto ogni volta che esegue una ricerca. È evidente che oltre ad essere importanti,
le pagine devono corrispondere ai termini ricercati. Quindi, Google integra
PageRank con sofisticate procedure di ricerca testo per trovare le pagine che sono
rilevanti e rispondono ai criteri di ricerca indicati. Google non si limita solo ad
esaminare il numero di volte in cui una parola specifica è presente nella pagina, ma
esamina tutti gli aspetti del contenuto della pagina (e dei contenuti delle pagine
correlate ad essa) per stabilire se risponde o meno ai criteri di ricerca indicati. I
complessi metodi di ricerca automatici di Google sono studiati per limitare al
minimo le interferenze degli utenti. Sebbene vengano visualizzati annunci
pubblicitari accanto ad alcuni dei risultati più rilevanti, Google non vende spazi
pubblicitari all'interno dei risultati (cioè i clienti non possono acquistare un
PageRank superiore). Le funzioni di ricerca di Google offrono un sistema semplice,
onesto ed obiettivo per trovare siti Web di alta qualità contenenti dati rispondenti a
quelli ricercati.
Slashdot
Slashdot [6], forum di discussione, permette agli utenti di definire, per ogni
commento, un giudizio. In modo da permettere la visione selettiva delle migliaia di
mail che vengono pubblicate quotidianamente. Ad ogni utente registrato viene
associata una reputazione, denominata karma, che viene modificata sulla base dei
giudizi espressi dai lettori sui suoi messaggi. Un buon comportamento innalza il
karma, e i messaggi avranno maggior peso, e pertanto avranno maggior probabilità
di essere effettivamente letti.
TrustRank (evoluzione del PageRank)
Lo scopo del TrustRank[7] è quello di aiutare nella classificazione di una pagina o
di un sito web. Il processo per definire se una pagina è considerabile come web-
41
____________________________________________________________________
spam, o comunque per la sua corretta classificazione qualitativa, può essere
sintetizzato in 3 passi:
-L’algoritmo prima seleziona un gruppo di pagine delle quali non è chiaro lo “spam
status” (definite seed).
-Un esperto umano esamina le pagine e comunica all’algoritmo quali posso essere
definite spam (bad pages) e quali no (good pages).
-L’algoritmo identifica le altre pagine sulla base della classificazione umana
iniziale.
Basi del trustRank
La determinazione certa di una pagina può provenire esclusivamente dalla
soggettiva valutazione umana, l’esperto in questione viene definito Oracolo.
Da questo è possibile comunque generare un semplice algoritmo che assegna una
valore binario pari a 0 se la pagina contiene spam (bad page), oppure pari a 1 se la
pagina è da considerarsi di buona qualità o senza spam (good page).
L’intervento dell’Oracolo come detto porta via molto tempo ed è anche costoso in
altri termini, non è possibile un suo intervento costante. Per diminuire gli interventi
dell’Oracolo è possibile adottare una tecnica basata sull’esperienza che ogni singolo
navigatore del web può avere: una
pagina buona difficilmente punta a una pagina cattiva. Questo perché l’autore di
una pagina con una qualità elevata difficilmente ha interesse che venga collegata
con pagine con una qualità minore o nulla. Per questo motivo le tecniche di spam
hanno cominciato ad adottare dei sistemi per collegare pagine che a prima vista
sembrano buone, a pagine contenenti web-spam, con varie tecniche:
-Introduzione nei siti che offrono la possibilità ai visitatori di inserire commenti, di
un numero elevato di link verso le pagine cattive (questo problema viene risolto con
la moderazione dei commenti o con la futura introduzione del tag link
rel=”nofollow” –NDR). Tecnica valida anche per forum o web chat.
-Creazione di pagine che offrono contenuti validi, ma che hanno un elevato numero
di link nascosti verso siti equivoci. Questa tecnica viene definita Honey Pot. Per
avvalorare questa tecnica chi crea queste pagine inserisce anche numerosi link verso
pagine buone.
-Creazione di directory basate sui risultati dei principali motori di ricerca, che
utilizzano dei motori chiamati spam-engine, per piazzarsi nei primi posti delle
ricerche.
In questi casi di esempio, adottando un algoritmo che funzioni da Oracolo,
potrebbero crearsi situazioni equivoche. Se abbiamo un sito di 100 pagine, con 70
pagine buone (quindi con valore binario pari a 1) e 30 pagine cattive (con valore
binario pari a 0), si avrà un indice di fiducia intermedio. In questo caso solo
l’occhio umano riesce a stabilire una verità certa.
42
____________________________________________________________________
Figura 2.2:Page rank
Inverse PageRank
Una tecnica valida per stabilire la qualità di un sito potrebbe venire dall’inversione
della tecnica del PageRank. Ovvero dare una preferenza positiva a quella pagine
dalla quale è possibile raggiungere molte altre pagine, basandosi quindi sul numero
dei link uscenti (outbound links).
High PageRank
Per realizzare questa tecnica è stata effettuata una query su un motore di ricerca che
utilizza PageRank come tecnica. Ogni risultato avrà vicino risultati con PageRank
simile. Questo perché il PageRank si propaga tra i link. Pagine con un elevato
PageRank saranno collegate a pagine con un PageRank simile.
Sperimentazione del TrustRank
Per valutare l’algoritmo TrustRank, il team ha usato l’indicizzazione del motore di
ricerca Altavista. Per ridurre la complessità del sistema i test si sono svolti
prendendo in considerazione la totalità di ogni sito web, e non ogni singola pagina
che lo compone. Quindi diversi miliardi di pagine sono stati raggruppati in
31.003.946 siti, usando uno degli algoritmi proprietari di Altavista.rticolo scritto da
Simone Messina – www.officialsm.net
Osservazione: un terzo dei siti selezionati non avevano alcun tipo di classificazione,
questo perché l’algoritmo PageRank che propaga la fiducia si basa sulla presenza di
link tra i siti. Ma questi siti comunque avevano un indicizzazione bassa, non è stato
difficile quindi separare manualmente siti
buoni e siti cattivi. Questo tipo di controllo ha portato via delle settimane, ulteriore
conferma
dell’impossibilità dell’intervento completamente manuale. Con la crescita smisurata
delle fonti e dei siti sul web i motori di ricerca giocano un ruolo fondamentale per la
ricerca e soprattutto l’effettivo
successo nella ricerca di informazioni. Il web-spam demolisce questa capacità di
successo nella ricerca di informazioni utili. I motori di ricerca quindi devono
necessariamente evolvere. Il sistema TrustRank, anche in combinazione al
PageRank o altri algoritmi potrebbe contribuire a questa evoluzione.
43
____________________________________________________________________
2.2.2 Approcci distribuiti
Tutti gli approcci visti precedentemente richiedono la presenza di un server
centralizzato che possa associare ad ogni utente un valore di reputazione, univoco e
super partes. Queste soluzioni, per quanto interessanti, non sono applicabili ad
ambienti distribuiti, come ad esempio le reti peerto-peer. Esistono poche soluzioni
proposte per ambienti distribuiti e solo poche di queste effettivamente
implementate. Segue una descrizione di PGP che implementa Web of Trust[1], un
modello di reputazione storico da cui nessun'altro nuovo modello può prescindere.
Successivamente vengono descritti Poblano, Global Trust e Free Heaven.
PGP
Un approccio decentralizzato storico è stato implementato in Pretty Good Privacy
[8] un sistema crittografico a chiavi asimmetriche. PGP è una pietra miliare nella
storia dei sistemi crittografici perchè ha permesso alle grandi masse che popolano
Internet di utilizzare per la prima volta gratuitamente e con semplicità la crittografia
di grado militare. PGP è nato principalmente per crittare e-mail usando chiavi
asimmetriche ma supporta anche la crittografia simmetrica, principalmente per la
crittazione di file locali.
La crittografia asimmetrica prevede che ci sia un mittente e un destinatario, dotati di
una propria chiave pubblica, di una propria chiave privata e della chiave pubblica
dell'altro.
Il sistema prevede che per mandare un messaggio crittato ad un utente il messaggio
di testo debba venire crittato usando la chiave pubblica del ricevente. Un'altra
caratteristica estremamente interessante di questo software è che permette di
firmare i messaggi in modo da garantire, oltre alla riservatezza, anche l'autenticità
del mittente.
44
____________________________________________________________________
Figura 2.3: PGP
La Figura 2.3 illustra lo schema utilizzato per la firma digitale e per la crittazione:
Alice, che vuole spedire un messaggio firmato e crittato a Bob, procede come
segue:
1. Alice recupera la chiave pubblica di Bob.
2. Alice firma il messaggio con la propria chiave privata.
3. Alice critta il messaggio firmato con la chiave pubblica di Bob.
4. Alice spedisce il risultato dell'operazione precedente a Bob.
5. Bob riceve il messaggio e lo decritta con la propria chiave privata, l'unica in
grado di decifrare il messaggio.
6. Bob verifica la firma digitale con la chiave pubblica di Alice.
Si nota da questo schema come il rapporto tra la chiave pubblica e privata sia stretto
e al contempo complementare.
Quello che questo schema non dice come Alice e Bob possano scambiarsi la chiave
pubblica in modo sicuro. Infatti, se Alice spedisse la propria chiave pubblica a Bob
in un canale insicuro, non darebbe a Bob la garanzia di ricevere la chiave esatta. Un
possibile attacco chiamato man in the middle prevede infatti che un terzo
partecipante si collochi nel mezzo della trasmissione, facendosi credere Alice a
Bob, e viceversa.
Risultato di questa situazione, dovuta al fatto che né Bob né Alice hanno avuto
modo di cambiarsi in modo sicuro la chiave pubblica, e che tutte le transazioni
successive sono diventate a rischio. Si consideri che uno scenario di questo genere è
ben lungi dall'essere inattuabile: spesso i messaggi crittati passano via mail
attraverso un certo numero, più o meno fisso, di server SMTP.
All'attaccante basterebbe quindi prendere possesso di uno di questi nodi e
modificare le regole di trasferimento in modo da attuare le modifiche necessarie ai
messaggi.
Se ci fosse un'autorità di cui tutti conoscono la chiave pubblica allora lo scambio
delle chiavi sarebbe semplice, poichè ad Alice basterebbe crittare la propria chiave
pubblica con quella pubblica dell'autorità (Certification Authority), in modo che
essa soltanto possa decifrare il messaggio. La Certification Authority restituirebbe
ad Alice un certificato che ne autentichi la chiave pubblica, che può essere esibito a
45
____________________________________________________________________
suo fianco. PGP non adotta questa tecnica, essendo un'architettura distribuita:
preferisce che l'autenticazione avvenga tramite catene di utenti. L'idea di fondo è
che, supponendo che Alice abbia la certezza di aver ricevuto proprio la chiave
pubblica di Bob, potrebbe lei stessa fornire un certificato firmato per quella chiave.
A questo punto, un terzo amico di Alice, che di lei ha massima fiducia, potrebbe,
verificando la firma digitale, riconoscere l'autenticità della chiave pubblica di Bob e
trasferirne di conseguenza la fiducia. In questo modo sono state create delle catene
di migliaia di chiavi. Alla creazione di un certificato che autentichi una chiave
pubblica, è possibile scegliere il livello di fiducia da attribuire alla chiave. La
ragione per cui è necessario introdurre diversi livelli è per dare delle limitazioni alla
proprietà altrimenti transitiva della fiducia, molto pericolosa quando le catene si
allungano a dismisura. Certe volte infatti, pur essendo necessario includere una
chiave nel proprio key ring, non si può avere la certezza assoluta di aver ricevuto la
chiave dell'individuo a cui si pensa appartenga. Seguono i quattro livelli ammessi,
con una breve descrizione.
-Non definito : non ci sono dati per attribuire alcuna fiducia alla chiave.
-Nessuna : la chiave pubblica non deve essere considerata valida e i certificati
prodotti da questa non devono essere presi in considerazione.
- Marginale : la chiave deve essere creduta quando introduce un'altra, ma deve
restituire un certificato di fiducia marginale.
-Completa : massima fiducia nella chiave. Ogni chiave firmata da questa deve
essere presa in considerazione.
Detto questo rimane il problema di stabilire quando una chiave, con diverse firme,
può essere considerata valida o meno. Ovviamente se tutte le firme fossero di
completa fiducia e di chiavi a loro volta certificate, il dubbio non si porrebbe.
Accade spesso però che alcune firme siano di reputazione marginale. In questo caso
vengono contate e sulla base del loro valore, in relazione ad alcune variabili
configurabili dall'utente che riflettono il suo scetticismo, si decide quale valore di
fiducia attribuire alla chiave.
Il risultato di questa operazione è un livello di fiducia associato ad ogni certificato,
che prevede tre livelli:
-Non definito : non si sa se il certificato sia valido.
-Marginale : si è abbastanza sicuri che il certificato sia valido.
-Completo : si ha la certezza assoluta che la chiave appartenga all'utente che la
dichiara propria.
Il meccanismo di gestione delle chiavi a fiducia marginale è però risultato troppo
complesso e soggetto a variabili locali, quindi ne viene sconsigliato l'utilizzo, se
non in casi di necessità. Le grandi comunità che adottano questo sistema, come ad
esempio Debian, usano certificare le chiavi sempre con la massima fiducia e infatti
prevedono che i possessori delle chiavi si incontrino personalmente mostrando le
proprie credenziali (carta d'identità o passaporto).
Poblano
Poblano [9] È un modello di fiducia sviluppato da Sun Microsystem espressamente
per ambienti distribuiti peer-to-peer in architetture JXTA [10]. Come accennato,
46
____________________________________________________________________
questi ambienti non prevedono delle strutture centrali che possano fungere da
autorità e il problema di non aver strumenti per valutare la fiducia di un
partecipante alle transazioni è presente e pressante. L'idea, come nel modello PGP,
è quella di creare una catena di nodi reciprocamente connessi da un legame di
fiducia, definito come un valore compreso tra -1 e 4, con questi significati:
Valore Significato
-1 Sfiducia
0 Ignora
1 Fiducia minima
2 Fiducia media
3 Fiducia buona
4 Massima fiducia
Nel modello viene specificato come viene trasferita la fiducia e come associare un
valore ad un server, tuttavia Poblano non ha riscosso molte approvazioni da parte
della comunità scientifica.
Global Trust Model
Il modello Global Trust assume per semplicità che esistano due soli valori di fiducia
e che i nodi, per ogni transazione, possano comportarsi correttamente oppure no.
Un'altra assunzione importante è che il numero di nodi scorretti sia basso e che per
un osservatore non sia possibile determinare quale di due parti sia disonesta in una
transazione non andata a buon fine. Il metodo proposto utilizza delle griglie di
routing, chiamate P-Grid, che permettono di gestire le comunicazioni dei nodi
mantenendo la struttura scalabile e distribuita. Le operazioni ammesse in questa
griglia sono la ricerca di chiavi e l'inserimento di valori associati a chiavi
particolari.
L'idea di base è di fare in modo che i valori di fiducia vengano inseriti in più copie
(repliche) in questa struttura ed estratti per effettuare delle valutazioni statistiche
sulla reputazione di qualche agente. Il modello non è mai stato implementato.
Free Heaven
Free Heaven [11] È un sistema di condivisione risorse anonimo e distribuito che
cerca di garantire la libertà di espressione degli individui. Il modello adotta una
definizione di fiducia, necessaria per stabilire delle connessioni sicure: ogni nodo
infatti, afferma di garantire un certo comportamento, verificato nel tempo. La
reputazione di ogni nodo viene così determinata dalla serietà con la quale vengono
mantenuti gli impegni presi, facilmente verificabili, essendo misurabili in termini di
persistenza di file. Ogni nodo infatti deve dichiarare, nel momento in cui accetta di
mantenere una chiave, il tempo per il quale è disposto a farlo. Questa chiave viene
periodicamente controllata, per verificarne la presenza. Free Heaven non ha
sviluppato una metrica particolarmente interessante né tantomeno portabile ad altri
ambienti, essendo molto semplice verificare l'integrità di ogni nodo. Da questo fatto
deriva che i meccanismi di propagazione della fiducia sono minimali. Del resto
l'obiettivo del modello è di garantire persistenza dei file in modo anonimo e non si
47
____________________________________________________________________
pone come risultato da perseguire la valutazione della fiducia di ogni nodo, essendo
questa funzionale soltanto alla correttezza di un comportamento gestito
internamente.
FOAF
Il progetto FOAF [12]costituisce un interessante esperimento, il tentativo di
costruire un vocabolario comune per lo sviluppo di comunità online, legate da un
clima di fiducia costruito (parzialmente o interamente) sulla Rete attraverso una
catena di relazioni. FOAF (Friend-of-a-Friend) è il nome-acronimo del personaggio
misterioso a cui capitano tutte le vicende raccontate nelle leggende metropolitane
di mezzo mondo; ma è anche il nome di un progetto (FOAF-project.org) di
semantic web che punta a creare una rete mondiale di amici-di-amici utilizzando un
vocabolario comune, un dialetto XML (o un vocabolario RDF) chiamato FOAF: a
essere codificati in formato standard sono dati personali e relazioni tra persone
(gruppi di persone, comunità, aziende).
In un file FOAF vengono inseriti la descrizione di un singolo e una lista di contatti
(friends): amici, collaboratori, colleghi, ecc. L'idea di fondo è quella che per cercare
una persona si possa fare come nella vita di tutti i giorni, muovendosi tra le
conoscenze: questa persona ha collaborato con un amico con cui ho lavorato, per
cui potrebbe interessarmi contattarlo... Il tutto si basa su un file di metadati RDF
legato ad una pagina personale, che oltre a specificare dati e caratteristiche della
persona, permette di ricostruire un elenco di altre pagine e dei relativi metadati (la
rete di amici). Per generare automaticamente la propria descrizione in formato
FOAF è sufficiente compilare i campi presenti in un apposito servizio di FOAF-amatic. Il progetto FOAF mira a costruire nuove opportunità di sviluppo per le
comunità online. E dal punto di vista del Web Trust garantisce una trasparenza del
percorso di individui e gruppi di individui, favorendo una crescita di credibilità e
fiducia nelle relazioni interpersonali sviluppate sulla Rete.
Si cerca di usare il Web per creare spazi in cui le persone sono interconnesse in una
sorta di grande mappatura, che possa coinvolgerle già a partire dal semplice
contatto, giungendo fino ai rapporti di amicizia più stretti. Del resto, l'inventore
dell'acronimo FOAF, lo studioso di folclore americano Jan Harold Brunvald,
riteneva che l'analisi della diffusione di una leggenda metropolitana permettesse di
studiare come gruppi sociali o comunità differenti comunicassero tra loro: una
leggenda che ha origine, per esempio tra gli studenti dei licei, può successivamente
diffondersi in ambienti completamente diversi, come quello delle casalinghe.
Conoscere il "percorso" che una determinata leggenda ha seguito da una comunità
all'altra può aiutarci a comprendere la natura dei loro rapporti
Uno studio:P2PRep [13]
In Gnutella, ogni server ha associato un identificativo (ServentID) che viene
comunicato agli altri durante l'invio di messaggi QueryHit, come stabilito dal
protocollo. L’approccio proposto richiede la persistenza degli identificativi dal
momento che è l'unico modo per mantenere la storia di un servent nell'arco di tutte
48
____________________________________________________________________
le sue transazioni. La persistenza di un ServentID non influisce sull'anonimato
dell'utente dal momento che si comporta come uno pseudonimo opaco e non è
associato in modo inequivocabile a nomi o indirizzi IP. La persistenza di un
ServentID non influisce sull'anonimato dell'utente dal momento che si comporta
come uno pseudonimo opaco e non è associato in modo inequivocabile a nomi o
indirizzi IP.
In un ambiente tipo Gnutella un servent p che desideri cercare una risorsa genera un
messaggio broadcast (Query) e seleziona dalla lista di coloro che rispondono (che
chiameremo offerenti) un nodo al quale si connetterà per prelevare i file scelti. La
scelta tipicamente viene effettuata sulla base del nome della risorsa, della velocità à
dichiarata, ed eventualmente da dati aggiunti dall'implementazione (come ad
esempio quelli definiti dall'estensione BearShare che permettono di selezionare
nodi che abbiano effettivamente disponibilità di accettare nuove connessioni) e
della dimensione. Si noti che non c'è alcuno strumento per valutare a priori la
qualità di una risorsa. In certi casi, risulta ragionevole scegliere la risorsa più
comune in rete, nell'ipotesi evoluzionista che venga più facilmente distribuita la
versione qualitativamente superiore. Inoltre, qualora la transazione non dovesse
terminare in modo corretto, sarebbe sempre possibile proseguire lo scaricamento del
file da un altro servent.
Purtroppo questa tecnica palliativa non offre reali garanzie, e la quantità di file privi
di senso con nomi allettanti distribuiti in rete ne è la dimostrazione.
L’approccio, chiamato P2PRep, permette ad un servent p di chiedere alla comunità
quale sia la reputazione di altri servent, tramite la spedizione di un messaggio
broadcast (Poll) che esprime la volontà di indire una votazione. L'idea fondamentale
è la seguente: ogni servent, una volta ottenuto un insieme di risposte ad una Query
seleziona un sottoinsieme degli offerenti e genera un messaggio broadcast diretto a
tutta la comunità, per ottenere informazioni sulla loro reputazione. Tutti i nodi
riceventi possono rispondere esprimendo le loro opinioni, costruitesi nel tempo e
con l'esperienza diretta, dando a p la possibilità di effettuare un miglior
raffinamento della scelta iniziale e ridurre i rischi legati alle transazioni.
Sono stati presentati due tipi diversi di protocollo, una versione base e una
avanzata. La versione base assume che i votanti non dichiarino la loro identità. La
versione avanzata richiede che ciascun voto sia accompagnato da un identificativo
del servent votante, così da poter valutare la credibilità del votante. In effetti, con
questo secondo meccanismo è possibile attribuire un peso differente ai voti, sulla
base della credibilità stessa dei votanti. Naturalmente, essendo la qualità di un
server non necessariamente correlata alla sua abilità di fornire delle indicazioni
utili, si parlerà di due tipi di esperienze differenti: la reputazione vera e propria
legata alla distribuzione delle risorse, e la credibilità, che riflette l'abilità di un nodo
di esprimere giudizi utili e veritieri.
Il protocollo viene leggermente complicato dal fatto che è necessario aggiungere
delle condizioni per ridurre le possibilità di violazioni. Per ridurre la vulnerabilità
ad attacchi, è prevista la possibilità di effettuare dei controlli sull'identità dei votanti
tramite connessioni dirette.
Per riuscire ad ottenere la sicurezza sufficiente, è necessario utilizzare in modo
massiccio la crittografia asimmetrica, così da riuscire a garantire l'integrità dei
pacchetti (firma digitale) e la confidenzialità (crittazione). A questo scopo, il
49
____________________________________________________________________
protocollo richiede infatti che l'identificativo di servent sia funzione della chiave
pubblica di una coppia di chiavi persistente. In questo modo è possibile controllare
l'identità di un servent verificando la sua conoscenza della chiave privata associata
in modo indissolubile all'identificativo.
La chiave pubblica, che può essere resa nota tramite messaggio QueryHit, può
essere utilizzata infatti per crittare una sequenza casuale di dati, decrittabile soltanto
dal possessore della rispettiva chiave privata.
Ad ogni votazione, viene generata un'altra coppia di chiavi, in modo da
massimizzare laddove possibile l'anonimato e rendere complesso risalire alle
votazioni indette da un determinato servent.
2.3 Il problema della computazione del trust
Esistono due problemi fondamentali per la gestione delle informazioni di trust su
metadati: come raccoglierli e come aggregarli. La raccolta dei dati può essere
effettuata sia in modo implicito che esplicito, atttraverso cioè la registrazione di
votazioni consapevoli dell’utente o attraverso l’interpretazione delle azioni
dell’utente(ad esempio se ha cliccato o no su di un link, se è rimasto per un certo
tempo su di una risorsa...).
Una volta che sono stati ottenuti questi valori occorre decidere quale aggregazione
utilizzare. Prima di tutto occorre considerare che tipo di sistema stiamo osservando,
cioè se si tratta di un sistema con utenti anonimi o autenticati. Nel primo caso ogni
comportamento degli utenti contribuisce allo stesso modo per il calcolo di un unico
valore totale di trust; nel secondo caso le votazioni devono essere aggregate
secondo il livello dell’utente(il ruolo e le conoscenze ad esso legate ad esempio) e
successivamente a livello globale.
Nel nostro progetto gli utenti sono autenticati e tipizzati a seconda del loro ruolo,
questo fa si che ci siano diversi livello di trust associati a seconda delle conoscenze
dell’utente, il trust sarà quindi maggiormente influenzato dagli utenti con un trust di
ruolo con valori elevati.
Esistono diversi principi per computare il trust e la reputation:
Somma o media dei voti
Si tratta semplicemente di voti positivi e negativi separatamente, calcolando un
punteggio totale come il punteggio positivo meno quello negativo.
Modelli Bayesiani
Prende input (0,1) e calcola punteggi in base a procedimenti statistici sommando
punteggi a priori e a posteriori.
Modelli discreti
Trust espresso con valori non numerici: Very Trustworthy, Trustworthy,
Untrustworthy and Very Untrustworthy.Non computabili, hanno significati vago.
50
____________________________________________________________________
Modelli di fiducia
Sempre legati alla statistica ma la somma totale delle probabilità non è 1, cioè si dà
spazio ad eventuali situazioni di incertezza.
Modelli Fuzzy
Rappresentazione in concetti linguistici dove alcune funzioni descrivono a quale
grado un soggetto può essere definito affidabile o non affidabile.
Modelli di Flusso
Ottenuti valori da iterazioni di loop di link o da lunghe sequenze di link.
51
____________________________________________________________________
Capitolo 3.
Il progetto: Simulazione dell'evoluzione del
Trust all'interno di una comunità di utenti
3.1.
Obbiettivi del progetto
Il modello che è stato creato ha l’obiettivo di definire una simulazione che emuli
l’interazione tra utenti di una piattaforma di knowledge management.
La simulazione ha l’obiettivo di evidenziare l’evoluzione della conoscenza
organizzativa nel tempo a partire dall’accesso alla base documentale, fondato sulla
discriminazione del profilo di conoscenza dei componenti l’organizzazione (gli
utenti del sistema).
Questo modello si colloca nel contesto del Trust Manager, meglio descritto nel
documento Adding a Trust Layer to Metadata Generators[19]. In breve il Trust
Manager è un sistema che aggrega asserzioni prodotte da diversi client (ogni client
produce asserzioni con relativo valore di trust) e le fornisce ad un navigatore con il
valore di trust aggregato.
I client producono asserzioni con un valore di trust correlato, questo valore di trust
dipende da una descrizione del ruolo dell’utente che sta producendo tali asserzioni.
La descrizione del ruolo contiene in pratica i concetti per i quali l’utente è dichiarato
esperto.
Una volta che le asserzioni sono fornite ad un navigatore con il loro valore di trust
finale (ottenuto dall’aggregazione dei voti provenienti dai client) il navigatore può
ordinare le risposte alle query degli utenti in base al valore di trust delle asserzioni.
Gli utenti del navigatore possono a loro volta consultare la base di asserzioni (tramite
delle query al navigatore) e implicitamente giudicare la bontà della risposta attraverso
il loro comportamento (uso o non uso dei documenti correlati alle asserzioni prodotte
come risposta). Questi voti impliciti degli utenti del navigatore sono a loro volta
ricevuti e valutati dal trust manager ed aggregati per produrre un nuovo valore di trust
delle asserzioni.
52
____________________________________________________________________
3.2. Il modello
La base di conoscenza dell’organizzazione è descritta semanticamente rispetto ad
una ontologia (o tassonomia) di dominio che descrive sia il contenuto semantico dei
documenti veri ei propri sia il profilo di conoscenza degli utenti del sistema in
esame. In questo modello non si terrà conto delle modalità di realizzazione di questa
indicizzazione.
Il risultato deve essere comunque la descrizione degli utenti e della base
documentale rispetto alla stessa ontologia, questo al fine di poter misurare una
distanza semantica tra gli utenti e le asserzioni disponibili che descrivono la base
documentale.
La misura della distanza semantica dovrà basarsi su principi e algoritmi specifici e
comunque non saranno discussi in questo documento. Il modello che si intende
realizzare è indipendente dalla misura realizzata, ma questa è un input fondamentale.
L’interazione di cui si vuole tenere traccia è l’espressione di un voto di correttezza
che l’utente può esprimere rispetto alle asserzioni semantiche presenti nella base di
conoscenza. Sostanzialmente l’utente dovrebbe avere un sistema di ricerca
semantica, quindi un’applicazione che gli permetta di esprimere la sua soddisfazione
(si/no) sulla correttezza della asserzione semantica trovata (si intende l’asserzione
semantica che lega il documento al concetto dell’ontologia). In questo modo sarà
possibile individuare la componente della base di conoscenza più efficacemente
rappresentata e strutturata, e la sua evoluzione nel tempo dipendentemente
dall’evoluzione dell’insieme degli utenti.
Sottolineiamo che il maggior interesse di questa lavoro di ricerca si concentra sul
formalismo per descrivere gli utenti. Modelli per studiare l’evoluzione delle idee
sono già stati proposti. Tuttavia in questi modelli la descrizione del comportamento
degli utenti è sicuramente semplicistica (generalmente la probabilità che si convinca
di una idea). Questi modelli non si incontrano con la ricchezza descrittiva utilizzata
per caratterizzare gli utenti nella letteratura della teoria dell’ organizzazione e delle
reti sociali.
Il nostro primo obiettivo è perciò quello di definire un formalismo di descrizione
degli utenti più ricco e flessibile.
3.2.1 Formalismo di descrizione degli utenti
La prima soluzione ipotizzata è quella di descrivere un utente come un automa a
stati finiti. Questa soluzione è probabilmente insufficiente per descrivere gli utenti.
Ci si aspetta infatti che in letteratura gli utenti vengano descritti anche in base alle
iterazioni che hanno con gli altri utenti. Questo formalismo non considera che
l’azione di un utente possa influenzare quella degli altri. È tuttavia un buon inizio
sul quale vale la pena lavorare con un primo lavoro di tesi che ci permetta di
53
____________________________________________________________________
esplorare le soluzioni implementative per realizzare applicazioni basate su un
formalismo di descrizione degli utenti.
Automi a stati finiti
Secondo questo formalismo, un utente è descritto in base agli stati in cui si situa
durante la sua attività lavorativa. Ogni stato è relativo ad un’attività differente. Nel
nostro esempio esistono tre stati: Ricerca, Stesura e Riflessione. In fase di ricerca
l’utente naviga le asserzioni e legge i documenti ad esse correlati. In fase di stesura
l’utente produce asserzioni.
Figura 3.1: I tre stati dell'attività di un utente
La figura 1 mostra i tre stati dell’attività di un utente. Ogni stato è collegato con altri
tramite una freccia, ad ogni freccia è associata la probabilità che l’utente ha di
passare da uno stato all’altro. Questa probabilità dipende dal tempo trascorso, come
è mostrato qui sotto:
Ricerca => Ricerca = P = P0(-T ricerca)
Ricerca => Stesura = P = P1(T ricerca)
In fase di Riflessione l’utente non compie alcuna azione. In fase di Stesura e di
Ricerca è necessario applicare delle ulteriori funzioni per capire su quali asserzioni
l’utente andrà ad agire.
Esistono due funzioni: Acesso f(d) e Correttezza g(d). La funzione f(d) individua
su quali asserzioni viene compita un azione. Nel caso della Stesura l’azione sarà
scrivere asserzioni; nel caso della Ricerca l’azione corrisponderà alla navigazione
delle asserzioni, e alla lettura dei documenti correlati. La funzione g(d) individua la
correttezza dell’azione prodotta; nel caso della Stesura la correttezza dell’asserzione
rispetto alla realtà, nel caso della Ricerca la correttezza del voto che l’utente
esprime sull’asserzione. Vi è poi da considerare un tempo di delay, che descrive la
velocità con cui un utente cambia stato, rappresenta cioè quanto un utente è attivo(a
livello di produzione e consultazione delle asserzioni).
54
____________________________________________________________________
3.2.2 La funzione “accesso” alla base documentale: f(d).
Ogni utente accede solamente ad una parte della base documentale. I motivi che
producono questo fenomeno sono molteplici:
1-la competenza dell’utente è un elemento che limita naturalmente la sua interazione
con la base documentale, un esperto di agenti software produrrà, ricercherà e
accederà con maggiore frequenza documenti relativi allo sviluppo di codice che non
a documenti relativi alle tematiche, ad esempio, del turismo;
2- il ruolo di un utente, che guida la crescita professionale, determina la tipologia di
documenti: un project manager sarà principalmente interessato a documenti
riguardanti la generalità dei progetti piuttosto che a documenti riguardanti lo
sviluppo di singole attività o task.
È indispensabile quindi introdurre una funzione1 che descriva la probabilità di
accesso alla base documentale in funzione della distanza concettuale. La dipendenza
dalla distanza semantica permette di avere una funzione che sia indipendente
dall’individuale competenza, essendo questa rappresentata nella distanza semantica
tra l’utente e la base di conoscenza. È pur vero che la misura di evoluzione di
conoscenza organizzativa si baserà (si veda successivamente) sull’accesso alla base
documentale, dipenderà quindi dalla capacità interattiva del singolo utente (dal
numero di ricerche effettuate, o meglio, dal numero di voti relativi alla bontà delle
asserzioni presenti nella base di conoscenza), tuttavia questo aspetto non è
attualmente modellizzabile. Il modello quindi conterrà utenti che interagiscono
equivalentemente alla base di conoscenza.
In
Figura 3.2 una rappresentazione possibile della probabilità di accesso alle asserzioni
in funzione della distanza semantica tra il profilo dell’utente e l’asserzione stessa. La
forma indica questo possibile comportamento: l’utente interagisce principalmente
con le asserzioni più vicine a lui, tuttavia ha una probabilità diversa da zero di
accedere anche ad asserzioni distanti dal suo profilo.
1
La funzione esprime la probabilità nell’unità di tempo. Quest’osservazione vale per tutte le funzioni di probabilità
introdotte.
55
____________________________________________________________________
Figura 3.2: probabilità di accesso
Il passo successivo è la costruzione di un insieme ordinato di asserzioni semantiche,
ordinate rispetto alla distanza semantica dall’utente.
In figura 3.3 è schematizzato il seguente processo: ad ogni utente è associato un
profilo, rispetto a questo specifico profilo si costruisce l’insieme costituito da una
serie di insiemi di asserzioni, ognuno di questi contiene le asserzioni che
corrispondono alla fissata distanza semantica dall’utente.
Figura 3.3: profilo utente ed asserzioni prodotte
Avendo le asserzioni che si trovano alla distanza d dal profilo dell’utente, e quindi
anche il loro numero, è possibile quantificare il numero di accessi, e quindi di voti2,
che l’utente specifico effettua in quell’insieme:
2
Si sta supponendo che ad ogni accesso corrisponda un voto che definisca la bontà o meno dell’asserzione, se
questo non fosse vero sarebbe sufficiente aggiungere una funzione che esprima la probabilità di esprimere un
voto all’accesso. Anche questa funzione potrebbe dipendere dalla distanza concettuale, in quanto è
ragionevole supporre che all’aumentare della distanza la disponibilità di esprimere un voto diminuisca. Il
modello comunque risulterebbe scalato per questa funzione.
56
____________________________________________________________________
N(di) = J(di)* f(di)
3.2.3 Funzione di “correttezza” del voto espresso: g(d).
Ad ogni voto espresso dagli utenti corrisponde anche una probabilità di giustezza,
ovvero la probabilità che il voto sia giusto (chiaramente la probabilità che sia
sbagliato è il complementare di questo rispetto ad 1). La probabilità di correttezza
dipende giustamente dalla distanza concettuale. In figura è rappresentata una
possibile funzione che rappresenti questa probabilità. Come si vede la funzione ha
valori alti per distanze basse, e valori bassi, diversi da zero, anche per valori di
distanza concettuale alta. Questa funzione g(d) dovrebbe essere indipendente
dall’utente (si assume costante il comportamento).
Figura 3.4: la funzione di correttezza del giudizio
Il numero di voti corretti sarà espresso dal prodotto tra il numero di voti espressi
N(di) e la probabilità di voto corretto g(di):
C(di) = N(di) * g(di) = J(di)* f(di) * g(di)
3.2.4 Scelta della funzione statistica: la gaussiana
La curva cosiddetta normale venne sviluppata nel 1733 da DeMoivre, come
un'approssimazione alla distribuzione binomiale. I suoi scritti vennero persi fino al
1924, quando Karl Pearson li ritrovò. Laplace utilizzò la curva normale nel 1783 per
descrivere la distribuzione degli errori. Nel 1809, Gauss la impiegò nell'analisi di
dati astronomici. La curva normale viene spesso chiamata "distribuzione gaussiana",
anche se più precisamente dovrebbe essere citata come "distribuzione di GaussLaPlace".
La normale è la distribuzione statistica più famosa ed utilizzata. Le tre ragioni
principali sono: essa si adatta bene alla rappresentazione grafica di molti fenomeni
fisici, biologi, sociali, ecc.
57
____________________________________________________________________
si adatta bene alla rappresentazione grafica di molti fenomeni fisici,
biologi, sociali, ecc.;
• è fondamentale in inferenza statistica;
• è una conseguenza del teorema centrale limite.
•
La formula matematica che descrive la funzione della densità di probabilità normale
è la seguente:
dove µ e σ rappresentano la popolazione media e lo scarto quadratico medio (o
deviazione standard). L'equazione della funzione di densità è costruita in modo tale
che l'area sottesa alla curva rappresenti la probabilità. Perciò, l'area totale è uguale a
1.
Figura 3.5: La gaussiana
Per la Gaussiana, nell’intervallo entro le due deviazioni standard che si trovano attorno
alla media (tra >-? e >+?) abbiamo il 68,3% della massa della distribuzione, entro le 4
deviazioni standard (tra >-2? e >+2?) abbiamo il 95,4 % e entro le sei deviazioni
standard (tra >-3? e >+3?) abbiamo il 99,7%. Questa è detta legge 3 sigma.
58
____________________________________________________________________
3.2.5 Schema del modello per la simulazione
Il modello della simulazione si basa sul presupposto di dover emulare i
comportamenti di utenti o gruppi di essi che si muovono ed interagiscono all’interno
di un sistema di knoweledge management eseguendo determinate azioni dipendenti
dal loro ruolo.
I soggetti di queste azioni sono gli user, raggruppati in usergroup che rappresentano
sottoinsiemi di utenti dalle caratteristiche comuni, all’interno di una popolazione più
vasta. Ogni usergroup ha un determinato ruolo e comportamenti (schema). Le azioni
che possono essere eseguite sono caratterizzate da un behaviour, che è il
comportamento che uno user può assumere in quegli stati. L’insieme degli stati è
definito da una macchina a stati finiti che ne descrive le relazioni.
Uno usergroup si muove all’interno di una macchina a stati finiti a seconda di uno
schema, che è un “filtro” che sovrapposto alla macchina a stati finiti descrive come
passare da uno stato ad un altro.
<Schema name="ruolo1" state_diagram="http://
XMLDatabase\treeStateDiagram.xml">
<ArcValues>
<State name="creation">
<Arc destination="research" value="0.3" />
<Arc destination="creation" value="0.4" />
<Arc destination="wait" value="0.3" />
</State>
<State name="research">
</State>
<State name="wait">
</State>
</ArcValues>
<Rules />
</Schema>
Esempio di schema
Usergroup con lo stesso diagramma di stati finiti possono avere invece schemi
diversi.
Al fine della simulazione tutti questi componenti sono riorganizzati all’interno di un
project che contiene tutti i parametri per effettuare la simulazione vera e propria.
Definiamo ora uno per uno i componenti della simulazione:
1- Macchina a stati finiti
Rappresenta il contenitore degli stati e degli archi (grafo). Ogni stato ha un nome ed
è legato ad un behaviour.
59
____________________________________________________________________
<StateDiagram name="wait-write-read">
<State name="creation">
<Behaviour name="Behaviour_Writer" />
<Arc destination="research" />
<Arc destination="creation" />
<Arc destination="wait" />
</State>
<State name="wait">
<Behaviour name="Behaviour" />
</State>
<State name="research">
<Behaviour name="Behaviour_Evaluator" />
</State>
</StateDiagram>
2- Il behaviour è la serie di azioni che un soggetto compie quando si trova in un
certo stato.
3- Usergroup per definirlo sono necessari:una macchina a stati finiti che caratterizza
le azioni che possono compiere gli utenti, lo schema che rappresenta come muoversi
tra gli stati, il ruolo che rappresenta la visione che ha lo usergroup della concept list.
Esempio usergroup
<usergroup name="usergoup2" delay="5000" type="registered">
<state_machine url="http://XMLDatabase\treeStateDiagram.xml" />
<schema url=" http://XMLDatabase\Schema_Ruolo1.xml" />
<user number="3" />
<role url=" http://XMLDatabase\XMLDatabase\esperto reti.xml" />
</usergroup>
60
____________________________________________________________________
4- Il ruolo definisce i concetti con relativo valore di trust, specifici per un
determinato tipo di utente.
Esempio ruolo
<role name = "hardware expert" >
<concept_list name = "conceptList1" namespace = "http://
XMLDatabase\conceptList1.cpl" />
<trust value = "0.8">
<concept name
<concept name
<concept name
<concept name
<concept name
<concept name
<concept name
<concept name
<concept name
</trust>
<concept name
<concept name
<concept name
<concept name
<concept name
</trust>
<concept name
<concept name
<concept name
<concept name
<concept name
</trust>
</role>
=
=
=
=
=
=
=
=
=
"video card hardware" />
"mouse hardware" />
"hard-disk hardware" />
"hard-disk controller" />
"memory hardware" />
"overheating" />
"power supply" />
"ram malfunction" />
"cluster" />
=
=
=
=
=
"video drivers" />
"mouse driver" />
"cd/dvd controller" />
"cd/dvd driver" />
"bios malfunction" />
=
=
=
=
=
"security" />
"network configuration" />
"virus" />
"O.S. corrupted" />
"software not compatible" />
5- Gli usergroup raggruppano gli user secondo caratteristiche comuni (stesso
schema, state machine, delay, e tipo user registrato) e hanno la forma xml seguente:
Esempio usergroup
<usergroup name="hardware expert" delay="1000" type="registered">
<state_machine url="http:\\XMLDatabase\Computer tecnical
support\wait_write_read.std" />
<schema url="http:\\XMLDatabase\Computer tecnical
support\generic_schema.scm" />
<user number="4" />
<role url="http:\\XMLDatabase\Computer tecnical support\hardware
expert.rl" />
</usergroup>
61
____________________________________________________________________
Il project raccoglie tutte le informazioni necessarie alla simulazione. Per effettuare la
simulazione vera e propria è necessario il comando Run Simulation.
Prima della simulazione è necessario impostare alcuni parametri quali:
-tempo di aggregazione che stabilisce ogni quanti secondi avviene il procedimento
di aggregazione.
-firma stabilisce se gli utenti possono firmare le asserzioni create o lette, impedendo
che lo stesso utente possa più volte valutare una asserzione. Rende il sistema chiuso,
dopo il voto di tutti gli users il sistema rimane fermo, a meno della presenza di utenti
anonimi che continuerebbero a votare in quanto sprovvisti di firma.
-aging stabilisce se fare invecchiare le asserzioni non votate da tempo
-discard prende in considerazione il fatto che un utente potrebbe scartare delle
asserzioni (uno pseudo voto negativo).
-pesato
-non pesato
Il progetto viene salvato in un file xml dalla forma seguente
Esempio di progetto
<project name="Computer technical support"
conceptList_Url="http:\\XMLDatabase\Computer tecnical
support\Computer tecnical support.cpl">
<userGroups trustAnonUser="0.0">
<userGroup url="http:\\XMLDatabase\Computer tecnical
support\generical technicians Usergroup.usg" />
support\hardware expert Usergroup.usg" />
support\network expert Usergroup.usg" />
support\software expert Usergroup.usg" />
</userGroups>
</project>
3.3. Simulazione
3.3.1 Definizione e scopi
Per simulazione si intende un modello della realtà che consente di valutare e
prevedere lo svolgersi dinamico di una serie di eventi susseguenti all'imposizione di
certe condizioni da parte dell'analista o dell'utente. Un simulatore di volo, ad
esempio, consente di prevedere il comportamento dell'aeromobile a fronte delle sue
caratteristiche e dei comandi del pilota.
62
____________________________________________________________________
Le simulazioni sono uno strumento sperimentale molto potente e si avvalgono delle
possibilità di calcolo offerte dall'informatica; la simulazione, infatti, non è altro che
la trasposizione in termini logico-matematica-procedurali di un "modello
concettuale" della realtà; tale modello concettuale può essere definito come l'insieme
di processi che hanno luogo nel sistema valutato e il cui insieme permette di
comprendere le logiche di funzionamento del sistema stesso.
Una simulazione viene utilizzata per:
- Generazione di una storia artificiale del sistema
- Studio e valutazione delle caratteristiche del sistema (analisi delle prestazioni)
- Risposta alla domanda “cosa accade se…”
- Progetto: analisi di sistemi “ipotetici”
- Confronto tra due o più sistemi
- Ottimizzazione: determinare valore ottimale di parametri
- Determinare i punti critici (bottlenecks)
- Capacity planning
- Previsionale: predire le prestazioni del sistema nel futuro
La simulazione è utile nel caso in cui il sistema non esista ancora(non posso usare
benchmarks), o per valutare sistemi diversi nelle stesse condizioni(stabilite appunto
dalla simulazione), permette di valutare eventi rari o rischiosi ed infine può
permettere una buona accuratezza.
I vantaggi di una simulazione di un sistema sono:
• Test di sistemi prima di investire sulle strutture
• Possibilità di espansione e compressione del tempo simulato
• Possibilità di capire le cause di eventi
• Esplorare e valutare nuove politiche di gestione
• Diagnosi di problemi
• Identificazione di requisiti
• Comprensione del sistema
Purtroppo ci sono anche degli svantaggi:
• Costo: costruzione dei modelli lunga e non banale
• Interpretazione dei risultati lunga e complessa
• Vengono in aiuto
– Simulatori (primitive e strutture dati)
– Ambienti di simulazione (che includono strumenti per l’analisi dell’output)
Prima di effettuare la simulazione è necessario creare un modello. Definiamo ora
alcuni concetti fondamentali per la comprensione di una simulazione:
• Sistema: collezione di componenti (elementi, entità) interdipendenti che
interagiscono fra loro in accordo a specifiche predefinite.
• Creazione di un modello: rappresentazione del sistema
63
____________________________________________________________________
• Obbiettivo: studio del comportamento del sistema e delle relazioni fra le sue
componenti.
• Processo di creazione ed uso del modello:
1. Definizione
2. Parametrizzazione
3. Valutazione
È inoltre necessario definire il livello di astrazione del modello(livello di dettaglio di
rappresentazione) e definire degli obbiettivi.
È norma utilizzare modelli semplici e facilmente risolubili specie nelle prime fasi di
progetto di sistema.
Come costruire il modello?
La costruzione di un modello di sistema può essere una rappresentazione astratta
oppure una formalizzazione di osservazioni empiriche.
Con il modello è possibile organizzare le conoscenze, comprendere al meglio i
componenti e le loro relazioni per approfondire e facilitare l’analisi del sistema.
Occorre prevedere una certa modificabilità del modello, indispensabile in fase di
progetto e per venire incontro a possibili necessità di valutare alternative, per questo
possono essere impiegati diversi modelli a seconda degli obiettivi prefissi.
Per costituire un modello è necessario astrarre il sistema reale definendone le
caratteristiche, la complessità/semplicità, la fedeltà, il tipo di tempo simulato.
Ogni sistema simulato ha delle caratteristiche quali:
–Variabili di stato del sistema:che descrivono lo stato del sistema al tempo
(simulato) t, e al livello di definizione sufficiente per l’analisi. Queste permettono di
interrompere e riprendere la simulazione.
– Evento è un cambiamento nello stato del sistema che avviene in un certo istante t
Un evento può essere di tipo endogeno (riguarda variabili interne al modello)
oppure esogeno (riguarda variabili esterne al modello).
– Entità sono oggetti esplicitamente definiti nel modello, possono essere dinamici
(es. clienti) o statici (es. server).Possono competere per ottenere le risorse ed essere
accodati nelle corrispondenti code di attesa
– Attributi sono valori locali delle entità
-Risorse sono entità che forniscono servizi passivi o attivi ad entità dinamiche (che
possono richiedere una o più unità della risorsa). Le risorse richieste, se occupate,
possono determinare un’attesa in coda oppure possono fornire servizi in parallelo
(server parallelo).
– Liste sono strutture usate per implementare code, possono essere mantenute
ordinate, secondo i valori di attributi per ragioni di efficienza
64
____________________________________________________________________
– Attività periodo di tempo di durata pre-determinata caratterizzato da attività in
corso, ovvero collezione di operazioni che trasforma lo stato di una componente.
Nella simulazione a eventi discreti (DES) le attività fanno avanzare il tempo
simulato t. Può essere caratterizzata da distribuzione statistica.
– Ritardo (delay) Durata indefinita di un’attività, legata alle condizioni e
all’evoluzione del sistema (attesa).
3.3.2 Modelli formali
I modelli formali possono essere di diversi tipi:
1–Modelli a tempo continuo/discreto
Il tempo continuo (continuous-time model) rappresenta lo stato del sistema definito
sempre in ogni istante t, il tempo discreto (discrete-time model), invece, lo stato del
sistema definito in istanti di tempo discreti: t, t+1…
2–Modelli a stato continuo/discreto
I modelli a stato stato continuo (continuous-state o –event model) utilizzano variabili
di stato continue (Es. livello del liquido in un bacino idrico) e possono essere
approssimati da modelli a eventi discreti.
I modelli a stato discreto (discrete-state o -event model) utilizzano variabili di stato
discrete e cambiano valori in corrispondenza di eventi discreti (Es. numero di
persone in attesa alla posta).
3–Modello deterministico/probabilistico
Per modello deterministico intendiamo che esiste una dipendenza deterministica
output(input k)= x, per quello probabilistico abbiamo almeno una variabile casuale
output(input k)= x1, x2, x3…
4–Modello statico/dinamico
Nei modelli statici lo stato del sistema non dipende dal tempo, in quelli dianamici lo
stato (o almeno una variabile di stato) dipende dal tempo.
5–Modello lineare/non lineare
Un modello lineare ha un output che segue una forma lineare del tipo output(x)=
k*x, quello non lineare ha una forma del tipo output(x) ¹ k*x.
6–Modello aperto/chiuso
In un modello chiuso non esistono variabili esterne, es. nuovi job non entrano o
escono dal sistema, in quello aperto esistono variabili esterne, es. esistono “source”
e “sink” per i job.
7–Modello stabile/instabile
65
____________________________________________________________________
Un modello stabile ha un comportamento che converge allo stato stazionario, uno
instabile ha un comportamento che cambia continuamente.
I possibili modelli del sistema:
• Modello matematico, statistico e di input/output
–Descrivono input e output del sistema attraverso relazioni matematiche o statistiche
• Modello descrittivo
• Modello di simulazione a eventi discreti
–Rappresentazione dettagliata della struttura interna del modello.
3.3.3 Tipi di simulazione
-Emulazione: simulazione che coinvolge componenti del sistema hw e firmware
es. emulatore di terminale hw, emulatore di processore: emula un instruction set di
un altro processore.
–MonteCarlo simulation: non esiste o non è rilevante l’asse del tempo. Viene
utilizzata per modellare fenomeni che non cambiano nel tempo e richiede
generazione di numeri pseudo-casuali, può anche valutare espressioni non
probabilistiche.
- Trace-driven simulation: si tratta di una simulazione basata su una sequenza di
eventi ordinati per tempo registrati dal sistema reale (traccia).
Una trace-driven simulation risulta credibile, perchè non basata su ipotesi e
distribuzioni di input, con essa è possibile fare una buona analisi di sensitività in
quanto ci sono minori variabilità (varianza minore) che permettono una stima più
accurata e/o veloce.
Gli svantaggi riguardano la complessità del modello, che risulta maggiore (di solito),
in oltre è difficile ricavare una traccia rappresentativa dei carichi possibili
(soprattutto per sistemi diversi e molto dinamici). La traccia può essere lunga e
legata alla situazione in cui è registrata, problema della scelta della parte di traccia
da utilizzare, inoltre occorrono tracce diverse per ogni diverso carico (workload).
-Discrete-event simulation (DES): è una simulazione che usa un modello del
sistema a tempo discreto. È l’opposto di continuous-event simulation, può essere
basata su stato continuo o discreto. Le variabili di stato cambiano solo in
corrispondenza ad eventi discreti, determinati a loro volta da attività e ritardi.
3.3.3.1 Il Tempo
Di fondamentale importanza per l’avanzamento dello stato del sistema è la quantità
tempo.
Il tempo simulato può essere:
– reale: tempo del sistema da simulare
– simulato: tempo rappresentato nel modello (clock : variabile del modello il cui
valore è il tempo simulato corrente)
– di esecuzione : tempo di elaborazione del programma di simulazione
66
____________________________________________________________________
I meccanismi di avanzamento del tempo in simulazione possono essere:
– per intervalli fissi (unit-time): si incrementa il clock di una quantità fissa D e si
esamina il sistema per determinare gli eventi che devono aver luogo per i quali si
effettuano le necessarie trasformazioni. Questo approccio tratta tutti gli eventi con
tempo di occorrenza. In questo tipo di avanzamento eventi con diversi tempi di
occorrenza possono essere trattati come eventi simultanei.
– per eventi (event-driven): si incrementa il clock fino al tempo di occorrenza del
prossimo (primo) evento. Gli incrementi possono risultare irregolari, posso
considerare come simultanei eventi che hanno lo stesso tempo di occorrenza.
3.3.4 Strutture di modelli di simulazione
Esistono essenzialmente quattro metodologie:
-Simulazione per Interazione tra Processi
Il flusso di esecuzione di un processo in esecuzione emula il flusso di un oggetto
(entità) attraverso il sistema . L’esecuzione procede finché il flusso non viene
bloccato, ritardato, terminato o inizia una nuova attività . Quando il flusso di
un’entità viene bloccato, il tempo di simulazione avanza al tempo di inizio previsto
dalla prima successiva entità in esecuzione.
-Simulazione per scheduling di eventi
Si avanza il tempo simulato al tempo del prossimo evento successivo (di solito il
termine o l’inizio di un’attività). Si ha una lista ordinata di eventi e scheduler di
eventi. Il termine di un’attività coincide con la nuova allocazione di risorse rilasciate
tra le entità in attesa o con lo scheduling di nuove attività casualmente determinate.
Lo scheduler di eventi mantiene struttura di lista ordinata per tempo simulato
(multi-linked) di eventi futuri (schedulati, cancellati, rinviati, bloccati), gestisce
l’avanzamento del tempo simulato.
La routine di evento aggiorna le variabili di stato e aggiorna la lista di eventi
(inserisce, cancella, o rinvia eventi).La routine di inizializzazione definisce lo stato
iniziale del sistema, le sequenze dei numeri pseudo-casuali, ecc.
Esistono poi altre routine quali: routine di gestione degli eventi, report generator,
routine di trace, procedure per notificare eventi o stime a run-time, gestione
dinamica della memoria e garbage collection.
67
____________________________________________________________________
3.3.5 Pianificazione della simulazione
Primo passo necessario è la formulazione del problema, occorre quindi definire e
verificare la corretta e completa formulazione del problema attraverso un dialogo tra
cliente e analista.
Importante è anche la definizione delle assunzioni delle specifiche e delle definizioni
del sistema adottate.
Primo passo necessario è la definizione degli obiettivi, si procede quindi alla
preparazione di una proposta per definire gli obiettivi, le risposte attese dalla
simulazione, gli scenari oggetto di indagine, i tempi necessari, le risorse necessarie, i
costi e infine le fasi dell’analisi.
Si procede poi con l’astrazione del modello concettuale che definisce relazioni
logiche, matematiche e causali delle componenti e strutture del sistema. Occorre
decidere il livello di astrazione del modello, definire componenti, attributi,
caratteristiche funzionali, relazioni.
Un’altra fase importante è la raccolta dei dati, utile per caratterizzare il carico
(workload characterization), analizzare e indagaree sui dati che caratterizzano il
modello, stabilire le discipline di accesso e servizio, definire i tempi medi di
permanenza, attesa e servizio.
Il quarto passo è la codifica del modello, il modello concettuale ottenuto viene
codificato in una forma interpretabile dal calcolatore, ottenendo un modello
operazionale. Le tecniche di codifica possono avere diversi approcci quali: objectoriented, simulazione distribuita, ambienti di simulazione.
Si passa quindi alla verifica e validazione del modello, più in particolare è la
verifica della correttezza del modello operazionale (soluzione) del modello, la
convalida del modello concettuale come adeguata rappresentazione del sistema o la
convalida della adeguatezza di: modello, obbiettivi, risultati
Il sesto passo è il progetto degli esperimenti di simulazione che prevede la
lunghezza della simulazione, il numero di prove, la simulazione a termine o
stazionaria e gli esperimenti pilota.
Si passa infine all’esecuzione ed all’analisi dei dati ed alla stesura della
documentazione.
Per completare il tutto si effettua una analisi di sensitività che definisce la scelta del
metodo di analisi, gli intervalli di confidenza e stimatori, l’interpretazione dei
risultati e l’analisi comparativa.
3.4 Ingegnerizzazione
Aspetto fondamentale del progetto è il collegamento con il tool Semantic Navigator
e con il tool T.A.M (Truted assertion maker). La simulazione ottenuta infatti dal
modello creato servirà a testare e verificare l’evoluzione del trust all’interno di un
sistema.
68
____________________________________________________________________
Requisiti:
-Deve permettere di modellizzare il comportamento di un utente(o un gruppo di
utenti) in base al ruolo.
-Deve utilizzare una funzione di verità.
-Deve permettere di impostare il numero di utenti da simulare.
-Deve permettere di creare gruppi di utenti caratterizzati dal ruolo o da altre
caratteristiche comuni.
-Deve avere una interfaccia GUI per permettere di effettuare una simulazione
complessa in modo semplice.
-Lo stesso utente non si puo trovare in più di uno stato contemporaneamente.
-In base ad una certa probabilità l’utende cambia stato.
-Deve simulare le scritture di asserzioni degli utenti.
-Deve simulare la lettura delle asserzioni ed il conseguente voto degli utenti.
-Deve simulare tempi di delay o wait in cui l’utente è inattivo.
-Dovrebbe utilizzare tecnologie indipendenti e opensource.
-Deve utilizzare uno schema XML che rappresenta gruppi di utenti ed un relativo
schema.
-Deve produrre dati utili.
-Deve utilizzare XML.
-Deve avere una guida per l’utente
-Deve prendere in considerazione il concetto di “distanza” tra i concetti su cui
l’utente si esprime ed i concetti a lui congeniali a seconda del suo ruolo (expertise).
69
____________________________________________________________________
CASI D’USO
Figura 3.6: Casi d’uso
Il Caso d’uso di figura 3.6 rappresenta le azioni necessarie per la creazione di un
progetto.
Un utente può:
-creare un nuovo progetto(new project) significa aggiungere gli usergroup già
esistenti(implica che siano caricabili da file), settare la concept list alla quale i ruoli
dovranno fare riferimento.
-creare un nuovo usergroup(new usergroup) significa settare il numero degli user
con le stesse caratteristiche, settare la state machine ed il relativo schema, settare il
ruolo e il delay, cioè la velocità con cui ogni user cambia stato dopo aver eseguito
una certa azione.
-creare uno schema(new schema) significa creare una corrispondenza con una state
machine e definire i valori di probabilità per il cambiamento di stato.
-caricare un progetto(load project) , uno schema o uno usergroup esistente
significa visualizzarlo nelle sue caratteristiche e dare la possibilità all’utente di
modificarlo.
-caricare uno usergroup(load usergroup), già creato in precedenza.
70
____________________________________________________________________
-il save as e il save permettono all’ utente di salvare su file il project, usergroup o
schema correnti.
Gli stati in cui i soggetti della simulazione possono trovarsi sono rappresentati da
una o più macchine a stati finiti, che possono differire anche nel numero e nel tipo di
stato in cui possono trovarsi.
Per descrivere le probabilità di accesso tra uno stato e l'altro, si sovrappone alla
macchina a stati finiti un filtro Schema, caratteristico di un certo gruppo di
soggetti.(quindi più gruppi di soggetti possono condividere la stessa macchina a stati
finiti, ma differire nello schema di probabilità).
La creazione della popolazione di soggetti è gestita a gruppi con caratteristiche
simili, come gli stati e i comportamenti da eseguire in quegli stati, schema, e visione
del mondo descritta da un Ruolo. La visione del mondo rappresenterebbe qual è il
loro punto di vista sull' insieme delle degli oggetti su cui possono operare (nel caso
specifico della nostra simulazione, la conoscenza è relativa al rapporto trust-concetto
ontologico).
Una volta lanciata la simulazione, ogni soggetto, si muove negli stati eseguendo un
behaviour previsto dallo stato, (per esempio può trattarsi di produzione di un
asserzione, e un altro soggetto trovarsi nella valutazione dell' asserzione).
Il sistema riguardante la selezione del concetto da utilizzare per produrre l ‘
asserzione o per giudicarne una, è relativo a quelle curve decisionali di cui abbiamo
discusso nel nostro incontro, per la precisone si utilizza un generatore di numeri
pseudo casuali con caratteristiche di distribuzione normale (più in particolare una
mezza gaussiana) dove verso la media , si concentra la maggioranza delle scelte che
ci aspettiamo da quel tipo di soggetto(concetti più vicini al suo ruolo , concetti con
trust più alto).
Può essere salvato un progetto di simulazione intero per poter ripetere la
simulazione già impostata. Spiegando meglio: io posso,dati una certa popolazione e
comportamenti, ottenere risultati diversi, a seconda del seme che utilizzo, che nel
caso generale è l'istante in cui viene lanciata la simulazione, altri parametri che
potrebbero cambiare il risultato della simulazione sono ad esempio le impostazioni
dei parametri quali l’uso o meno della firma, l’invecchiamento delle asserzioni ecc.
Il modello scelto per ora non prevede perturbative derivanti da interazioni di tipo
“sociale”, in quanto il modello diventerebbe ancora più complesso.
Occorre comunque riportare le possibili implicazioni di “interferenze” che si
potrebbero creare all’interno di una comunità di utenti:
Se venisse resa pubblica l’identità di colui che ha creato l’asserzione si potrebbero
avere ripercussioni sul comportamento degli utenti. Ci saranno infatti degli utenti
che supporteranno le idee del creatore dell’asserzione in quanto lo conoscono
personalmente, hanno simpatie per il soggetto o ricordano esperienze positive
precedenti a lui collegate(si può arrivare alla situazione in cui difenderebbero a
spada tratta le idee di un certo soggetto senza valutarne la veridicità). All’opposto ci
può essere una schiera di detrattori che vorranno, di proposito abbassare il trust
dell’asserzione di un certo soggetto perché non lo conoscono, hanno avuto
71
____________________________________________________________________
precedenti esperienze negative con il soggetto o per semplice antipatia nei suoi
confronti. Queste perturbative nella realtà possono esserci ed essere molto forti,
tanto da poter falsare il valore di veridicità del sistema intero.
Consideriamo ora ambienti P2P in cui vengano utilizzati meccanismi come FOAF. Il
progetto FOAF costituisce un interessante esperimento, il tentativo di costruire un
vocabolario comune per lo sviluppo di comunità online, legate da un clima di fiducia
costruito (parzialmente o interamente) sulla Rete attraverso una catena di relazioni.
In un file FOAF vengono inseriti la descrizione di un singolo e una lista di contatti
(friends) : amici, collaboratori, colleghi, ecc. L'idea di fondo è quella che per cercare
una persona si possa fare come nella vita di tutti i giorni, muovendosi tra le
conoscenze: questa persona ha collaborato con un amico con cui ho lavorato, per cui
potrebbe interessarmi contattarlo... Il tutto si basa su un file di metadati RDF legato
ad una pagina personale, che oltre a specificare dati e caratteristiche della persona,
permette di ricostruire un elenco di altre pagine e dei relativi metadati (la rete di
amici). Con questo meccanismo gli utenti possono quindi scambiarsi opinioni sulle
asserzioni chiedendo alla rete dei soggetti un parere sulla veridicità. Da questo si
può capire che tipo di relazioni ed interdipendenze complesse possono crearsi
all’interno di una comunità di utenti che devono esprimersi sulla veridicità di una
asserzione basandosi sulle esperienze di altri soggetto della rete.
Il linguaggio scelto per sviluppare il tool è Java, indipendente dalla piattaforma su
cui dovrà funzionare, altro linguaggio utilizzato per la costituzione dei componenti è
XML.
72
____________________________________________________________________
3.4.1 Scelta delle tecnologie
3.4.1.1 Java
Java è un linguaggio di programmazione sviluppato dalla Sun Microsystem.
Inizialmente progettato come linguaggio per programmare elettrodomestici
"intelligenti" come, ad esempio, i videoregistratori, dal 1995, anno della sua uscita,
ha suscitato un'interesse crescente che a tutt'oggi non accenna a diminuire, grazie ad
un insieme di caratteristiche, che adesso analizzerò, che lo pongono ai massimi
livelli fra gli strumenti di programmazione, per la rete e non solo.
Proprietà di Java
Java è stato definito un'evoluzione del C++. Del resto, quest'ultimo linguaggio è
stato preso come modello per lo sviluppo di Java, analizzandone pregi e difetti, al
fine di ereditare i primi eliminando gli ultimi. Questo però non basta a spiegare il
successo di Java e l'interesse suscitato pressoché in ogni campo di applicazione, da
quello scientifico a quello aziendale.
Java ha il merito di possedere sinergicamente diverse caratteristiche positive, alcune
ereditate dai linguaggi considerati migliori (non solo dal C++), altre introdotte ex
novo:
•
•
•
•
•
Possiede un ambiente di programmazione object oriented
E' un linguaggio multipiattaforma ed indipendente dal processore
E' multithreaded
E' dinamico e adotta la garbage collection
E' verificabile
Ambiente di programmazione object oriented
L'idea di fondo della programmazione orientata agli oggetti è basata sulla logica di
sviluppare l'applicazione tramite oggetti abilitati a comunicare l'un l'altro sfruttando
particolari meccanismi. Un oggetto permette di incapsulare dati e metodi che
agiscono sui dati. Tali metodi possono essere invocati anche automaticamente, in
funzione del verificarsi di particolari eventi. Ad esempio, un controllo di input, un
bottone, può essere implementato come oggetto. Fra le proprietà di questo oggetto ci
sarà il colore, la dimensione, la posizione all'interno del form che lo contiene, la
stringa di caratteri contenente il messaggio informativo ('Ok', 'Esci', 'Annulla', ecc.),
fra i metodi, quello per abilitare/disabilitare il bottone e quello per renderlo
visibile/invisibile, fra gli eventi, quelli collegati al click sopra il bottone col tasto
destro del mouse, al click col tasto sinistro, al solo passaggio sopra con il mouse. Gli
oggetti sono raggruppati in un insieme, che prende il nome di classe. Per continuare
73
____________________________________________________________________
con l'esempio, tipicamente un oggetto bottone apparterrà alla classe dei controlli di
I/O video, assieme agli oggetti menu, etichetta, campo di input, ecc.
Assieme alle classi, nella programmazione orientata agli oggetti si hanno le
superclassi e le sottoclassi. La classe dei controlli, ad esempio può avere come
superclasse quella di tutti i controlli del sistema, che includono oltre ai controlli di
I/O, anche i form, i dialog, gli altri tipi di finestre, ecc. Come sottoclasse può avere
quella dei controlli particolari di una versione passata del sistema (come avviene per
i controlli in ambiente Windows, che esistono nella versione a 16 bit per Windows
3.1 ed in quella a 32 bit per Windows 95). La caratteristica di tutti gli oggetti
appartenenti ad una classe è di ereditare metodi, proprietà ed eventi della
superclasse che li contiene.
Java è un linguaggio completamente orientato agli oggetti.
Un programma Java è un insieme di classi, appartenenti alla "Java class library", e
programmare in Java significa principalmente saper utilizzare le classi esistenti e
saperne scrivere di nuove. I vantaggi di un simile ambiente di programmazione sono
essenzialmente quelli della riduzione e del riciclo del codice.
Linguaggio multipiattaforma ed indipendente dal processore
I programmi, o applet, Java una volta scritti, vengono compilati in bytecode, un
livello intermedio tra il codice macchina nativo del processore (che ovviamente
varia al variare di questo), ed il sorgente Java. Il vantaggio principale derivante da
questa traduzione è insito nella sua indipendenza dal processore, che permette di
eseguire il codice così com'è su qualsiasi macchina che disponga dell'interprete Java,
senza la necessità di ricompilarlo (come avviene invece con linguaggi come il C++,
il Delphi o altri comunemente usati). In un ambiente eterogeneo come Internet, in
cui comunicano ed interagiscono macchine diverse, dotate di processori e sistemi
operativi differenti, tale caratteristica si traduce nella possibilità di eseguire lo stesso
codice Java ovunque, giacché tutti i browser più diffusi dispongono dell'interprete.
Linguaggio multithreaded
Gli attuali sistemi operativi sono detti multitasking, in quanto sono capaci di
eseguire più processi (task) contemporaneamente. Quello che avviene, a meno che
non si disponga fisicamente di un sistema multiprocessore, è che il sistema simula
l'esecuzione contemporanea di più processi suddividendoli in quanti di tempo
piccolissimi ed eseguendo questi ultimi in modo da alternare, in maniera
estremamente rapida, l'esecuzione ora di un processo ora di un altro. Tale alternanza
di processi sul processore non è casuale, bensì risponde a precise politiche di
gestione dei processi, caratterizzati da priorità diverse e soggetti a possibili
interruzioni straordinarie. Java rende possibile agire attivamente su tali politiche
gestendo le unità di base a cui il sistema operativo alloca il tempo di CPU,
denominate thread, specificandone le priorità e gestendone la sincronizzazione.
Linguaggio dinamico
74
____________________________________________________________________
Essendo Java un linguaggio object oriented, deve sostanzialmente manipolare un
insieme di oggetti. Dal punto di vista della gestione della memoria questo pone
diversi problemi, primo fra tutti, quello relativo agli sprechi di memoria dovuti alla
presenza di oggetti inutilizzati. Java risolve questo problema gestendo la memoria in
maniera dinamica. Quando un programma viene lanciato, viene reperita la memoria
libera per instanziare gli oggetti. Durante l'esecuzione tali oggetti vengono creati e
distrutti, occupando e liberando dinamicamente la memoria necessaria per ogni
singolo oggetto, così da avere, in ogni momento, occupate solo le risorse
effettivamente utilizzate dal sistema.
Una simile gestione era già possibile in linguaggi come il C++, ma comportava un
ruolo attivo da parte del programmatore, che doveva effettuarla manualmente
inserendo nel codice le opportune istruzioni e, pertanto, mantenendo traccia di tutti
gli oggetti attivi in un dato momento dell'esecuzione. L'automatismo introdotto da
Java diventa ancora più apprezzabile con programmi complicati e di una certa
dimensione, dove le possibilità di commettere errori aumentano.
Per allocare dinamicamente la memoria Java utilizza due metodi di garbage
collection:
•
•
Compaction
Marking & sweeping
Compaction identifica una tecnica di deframmentazione della memoria, volta cioè
ad eliminare la presenza di piccole quantità di memoria libera sparse qua e là,
compattandole in un'unica area contigua.
Marking & Sweeping, identifica un processo ricorsivo atto a marcare gli oggetti in
uso al fine di poterli distinguere da quelli inutilizzati, che così possono essere
eliminati.
La garbage collection era già stata introdotta da linguaggi come lo Smalltalk ed il
Lisp. Questi imponevano al sistema di bloccare il processo ad intervalli di tempo
prestabiliti, al fine di consentire il controllo e l'applicazione della tecnica. La natura
multithread di Java ha permesso di evolverla, spostando l'esecuzione dei controlli e
delle azioni da compiere su un thread diverso e con priorità inferiore a quello
dell'applicazione vera e propria, realizzando quella forma di parallelismo descritta
precedentemente ed evitando così di bloccare il processo.
3.4.1.2 XML
Già descritto nel capitolo 1 riportiamo ora glia aspetti positivi del linguaggio.
Per la sua natura ibrida, che rende i documenti simili a database, XML è sempre
più usato per gestire basi di dati e per trasmettere informazioni tra diverse
applicazioni.
75
____________________________________________________________________
Un database può essere visto come un insieme di oggetti che contengono le
informazioni e le funzioni necessarie alla loro gestione; in particolare, conterrà
tabelle di dati e query per estrarle. I programmi che usano queste informazioni
aggiungono funzionalità utili alla modifica e alla consultazione dei dati da parte
dell’utente finale. Una tabella, a sua volta, suddivide le informazioni in unità
chiamate record, ciascuna delle quali è composta da un certo numero di campi. Ogni
campo contiene un’unità indivisibile di informazione, la cui natura (tipo, lunghezza
e via dicendo) è determinata a priori secondo una precisa struttura ed è valida per
tutti i record.
Con XML (Extensibile Markup Language), invece si usa un approccio differente.
XML è nato per rappresentare i documenti in forma elettronica e dispone di un
meccanismo efficiente per descrivere il contenuto di un testo; è in grado di includere
al proprio interno informazioni di altro tipo, come file multimediali, che però
resteranno nel loro formato originale.
Per quanto sia possibile definire con precisione il contenuto logico del documento,
attraverso una definizione di tipo di documento (DTD) o uno schema XML, nulla
vieta di farne a meno, se il file che si crea rispetta le regole fondamentali di XML. Il
testo è racchiuso all’interno di elementi che possono ripetersi con regolarità,
ricreando lo schema classico della griglia di una tabella di database, o contenere una
serie di informazioni che si susseguono con una struttura ad albero in un ordine
apparentemente casuale, ma in realtà guidato dalla logica dell’applicazione che lo
deve gestire. La caratteristica di XML grazie alla quale possiamo trattare un
documento come una tabella di database è che ogni suo elemento descrive il proprio
contenuto, che si usi o meno una DTD o uno schema. Grazie a questa
autodescrizione è possibile localizzare al suo interno ogni singolo elemento che ci
interessa, esaminarne il contenuto, elaborarlo ed eventualmente formattare il
risultato dell’elaborazione per la presentazione a video e/o a stampa.
Rispetto a un database tradizionale, XML offre qualcosa in più e qualcosa in meno.
Esso ha, per esempio, la possibilità di fare riferimento a fonti di informazione
esterne: si possono costruire documenti prendendo dei pezzi ora da una sorgente ora
da un’altra e ricombinarli secondo le necessità. Non si tratta di una semplice
operazione di copia e incolla: ogni cambiamento nella sorgente si riflette nel
documento che la usa. È già notevole la quantità di utilizzi offerta da questa
caratteristica; se poi si pensa che la sorgente non deve essere necessariamente un
altro documento XML, ma potrebbe trattarsi di un database o un’applicazione che
genera in tempo reale le informazioni, si capisce la grande potenza di questa tecnica.
Purtroppo, la potenza genera complessità; per questo motivo, di solito, questa
tecnica viene usata con attenzione. La conversione di documenti XML è
un’operazione molto semplice, grazie a un linguaggio collegato chiamato XSL che
definisce i fogli stile da applicare al documento. Grazie a XSL, formattare i dati
estratti da un documento XML per presentarli all’utente può essere molto più
semplice dell’analoga operazione compiuta su una tabella di database;
sfortunatamente, nel caso di estrazioni complesse, il procedimento risulta
significativamente più lento.
76
____________________________________________________________________
XML è un valido supporto ai database e rispetto alle visioni tradizionali consente di
realizzare architetture semplificate sia concettualmente sia tecnicamente. Opera
indifferentemente sia con basi di dati strutturate sia con insiemi di documenti non
strutturati, evitando l’uso di protocolli o convenzioni. Il fatto che molti database
inizino a fornire il supporto per XML significa che ormai si deve considerare la
tecnologia matura per ogni genere di applicazione e che il valore delle realizzazioni
basate su XML non decrescerà nel tempo; al contrario, sono sempre più numerosi i
campi di applicazione in cui questa tecnologia ha già dato buoni frutti. Inoltre,
permette di trattare i dati sotto differenti aspetti, aumentando la loro flessibilità e, di
conseguenza, il loro valore.
XML nel middleware
Sempre più vendor includono nei loro prodotti il supporto a XML; questo non
riguarda solo le suite di office automation, ma anche i database. Ci si potrebbe
stupire di questa scelta poiché, come abbiamo visto, XML è in una certa misura
alternativo ai DB strutturati in modo tradizionale; tuttavia accade sempre più spesso
di vederlo usato come vettore di informazioni tra applicazioni. Nel campo del
middleware, infatti, XML offre grande versatilità e semplifica le comunicazioni. Si
immagini di avere la necessità di trasferire dei dati estratti dall’applicazione A
all’applicazione B. Normalmente si deve mettere mano al codice di almeno una delle
due applicazioni, creare la procedura di estrazione dei dati da A e, se possibile,
inserirli nella base di dati di B; questo comporta lo studio delle applicazioni e delle
loro basi di dati. Sebbene concettualmente semplici, queste operazioni causano
spesso seri problemi nella pratica, soprattutto quando le applicazioni sono state
sviluppate da due team diversi o la loro documentazione non è sufficiente; quando
girano su due sistemi operativi diversi, i problemi aumentano ancora. XML aiuta a
prevenire almeno una parte di questi problemi: infatti, sarà sufficiente che ogni
programma possieda una funzione di esportazione dei dati in XML e una di
importazione. Entrambe le operazioni devono valere per documenti XML formattati
secondo una o più DTD pubbliche. Il lavoro di conversione e quindi la necessità di
conoscere i formati usati dalle applicazioni è lasciato a una terza applicazione, che
normalmente è disegnata come un plug-in, da creare di volta in volta secondo le
necessità.
XML e i documenti
XML dimostra una buona potenza anche nel trattamento di basi di dati non
strutturate; per esempio, quelle relative a documenti di testo che quotidiani, riviste e
in genere società editrici accumulano nel tempo sotto forma di archivi elettronici. E’
possibile dare un nuovo valore a queste informazioni, scomponendole (pur
conservando l’unità logica del documento) in parti riutilizzabili e di facile
manutenzione. Questi concetti sembreranno quasi banali a quanti, soprattutto nel
campo dell’editoria, usano abitualmente SGML, da cui XML discende, ma usando
quest’ultimo la gestione delle informazioni risulta ulteriormente semplificata.
Naturalmente questi vantaggi non si applicano solo all’editoria, ma a tutte le realtà
che producono documentazioni voluminose. Strutturare con XML i documenti
77
____________________________________________________________________
richiesti dalle norme di qualità ISO, per esempio, consente di trasformare un’attività
di certificazione nella creazione di informazione.
Manuali più o meno complessi possono essere aggiornati e tradotti con efficienza e
possono anche offrire i propri paragrafi ad altri manuali. Inoltre, XML permette di
creare indifferentemente versioni cartacee o elettroniche dei documenti senza
necessità di riformattarli, con un notevole risparmio di costi e di tempo rispetto agli
attuali processi di pubblicazione. XML è usato con interesse sempre maggiore su
Web, dove l’abitudine di suddividere i dati in tanti piccoli file HTML non permette
di svolgere agevolmente molte operazioni, come la stampa o la ricerca. A prezzo di
un tempo d’attesa iniziale più lungo, con XML è possibile trasferire sul browser un
documento e poi mostrarlo in base alla strategia di accesso e all’impostazione
grafica; è facile poi creare differenti percorsi di consultazione. In questo caso trattare
i documenti come una base di dati consente di realizzare con facilità operazioni
altrimenti complesse, come le ricerche all’interno del testo, la creazione di
segnalibri, la stampa e via dicendo. In generale, questa architettura ha impieghi
molto vasti; può essere adottata per esempio anche dalle applicazioni client/server
che vogliono migrare verso un’interfaccia Web.
3.4.2 Scelta dell’interfaccia
L’interfaccia scelta per il tool è di tipo GUI(in inglese Graphical User Interface,
abbrev. GUI) e mira a consentire all'utente di interagire col tool manipolando
graficamente degli oggetti, svincolandolo dal dover imparare una serie di comandi
da impartire con la tastiera.
La forma di GUI scelta è a pannelli, che permette all’utente di definire i parametri
necessari alla simulazione. E’ inoltre possibile caricare progetti già preimpostati per
generare immediatamente una simulazione senza preoccuparsi di impostare alcun
parametro.
3.5. Aggregatore del trust
3.5.1 Definizione e proprietà degli aggregatori
In una situazione abbastanza informale, il problema della aggregazione consiste in
aggregare tuple ennarie di oggetti tutti appartenenti ad un set determinato, in un
singolo oggetto dello stesso tipo. Nel caso di operatore di aggregazione matematica
questo set è l’insieme dei numeri reali. In questo caso, un operatore di aggregazione
è semplicemente una funzione, che assegna un numero reale ad una tupla ennaria
(x1,x2,…xn) di elementi:
78
____________________________________________________________________
Per chiamare tale operatore aggregatore esso deve soddisfare delle proprietà.
PROPRIETA’ MATEMATICHE
1-Condizioni limite: nel caso peggiore e migliore ci aspettiamo che una
aggregazione:
La prima significa che se osserviamo una tupla con risulatati completamente
negativi, falsi o non soddisfacenti il risultato aggregato sarà ancora completamente
negativo, falso o non soddisfacente.
La seconda al contrario significa che osserviamo una tupla con risulatati
completamente positivi, veri o soddisfacenti il risultato aggregato sarà ancora
completamente positivo, vero o soddisfacente.
2-Monotonicità: ci aspettiamo che se un argomento della tupla aumenta allora anche
il valore finale aggregato cresca(o almeno non diminuisca, rimanendo uguale).
3-Continuità: la funzione di aggregazione è continua rispetto ad ognuna delle
variabili che la compone. Questa proprietà garantisce che la funzione sia robusta,
consistente e non caotica.
4-Associatività: una proprietà interessante è la capacità di aggregare per gruppi. Ci
aspettiamo che la scelta del gruppo non influenzi il risultato finale. Per tre argomenti
ad esempio si può scrivere:
5-Simmetria: conosciuta come proprietà commutativa,. L’ordine degli argomenti
non influenza il risultato. Questa proprietà è sottointesa quando l’aggregazione è
fatta di argomenti con la stessa importanza. Per ogni permutazione σ of {1,2, … , n
} l’operatore soddisfa:
6-Elemento assorbente: se l’operatore di aggregazione ha un elemento assorbente a,
allora può essere usato come voto di eliminazione o veto:
79
____________________________________________________________________
7-Elemento neutro: se l’operatore di aggregazione ha un elemento neutro e, allora
può essere usato come argomento che non dovrebbe avere alcuna influenza
sull’aggregazione:
8-Idempotenza: conosciuta come unanimità o accordo. Se aggreghiamo n volte lo
stesso valore ci aspettiamo di ritrovare il valore iniziale:
9-Compensazione: conosciuta anche come regola di Pareto. Ci aspettiamo che il
risultato totale della aggregazione sia più basso del valore massimo aggregato e più
alto del valore minimo aggregato:
10-Controbilanciamento: chiamiamo controbilanciamento o compensazione il
comportamento di un operatore che decresce il valore finale se ci sono argomenti
che vanno nella direzione opposta:
11-Rafforzamento: con questa proprietà vogliamo indicare che un insieme di
punteggi alti si rinforzano tra loro dando un risultato più affermativo che quello che
darebbero tanti voti individuali da soli. Allo stesso modo un insieme di voti bassi ha
la tendenza a dare un risultato molto più negativo che tanti voti singoli negativi.
12-Invarianza: quando aggreghiamo numeri (x1,x2, …,xn) che rappresentano misure
di un certo tipo dobbiamo specificare la scala in cui queste misure vengono fatte.
Vogliamo quindi che la funzione di aggregazione rispetti quindi la scala data.
Avremo quindi:
PROPRIETA’ COMPORTAMENTALI
1-Comportamento decisionale: è utile avere la possibilità di esprimere il
comportamento della necessità di prendere decisioni di un certo tipo. Per esempio:
tollerante, ottimistico, pessimistico o restrittivo.
2- Interoperabilità dei parametri: è auspicabile che i parametri abbiano per lo più la
stessa interpretazione semantica. Questa proprietà proibisce l’utilizzo della
metodologia black box.
80
____________________________________________________________________
3- Pesi sugli argomenti: è cruciale avere la possibilità di esprimere pesi sugli
argomenti. Questo può essere spiegato come attribuzione di privilegi ad alcuni di
essi.
3.5.2 Operatori di aggregazione
La media aritmetica
La statistica ci fornisce diversi concetti di media e, quella che spesso si definisce
"tradizionale" è la media aritmetica. Si consideri una serie di n termini x1, x2, ..., xn,
la media aritmetica,
simboli:
, è data dalla somma dei termini diviso il loro numero; in
Questo operatore è interessante perchè produce un valore aggregato che è inferiore
al valore più grande e superiore al valore più piccolo. Così il risultato
dell’aggregazione è un valore centrale. Questa proprietà è conosciuta come
compensazione. La media gode delle proprietà monotonicità, continuità, simmetria,
associatività e idempotenza ma non ha né elemento neutro né assorbente e non ha
proprietà comportamentali.
La media pesata
Quando i valori xi, (i = 1, ..., n) non hanno tutti la stessa importanza (lo stesso
"peso") la media aritmetica semplice viene sostituita dalla media pesata (o media
ponderata), cioè da quella media che considera ogni singolo valore in relazione al
suo "peso"(come indicato sotto con w).
La mediana
La mediana è un indice di posizione e si definisce come quel valore che bipartisce la
distribuzione ordinata in senso non decrescente delle modalità di un carattere. Per
cui al primo gruppo apparterranno le osservazioni inferiori o uguali alla mediana, al
secondo gruppo le osservazioni superiori o uguali alla stessa.
Minimo e Massimo
81
____________________________________________________________________
Anche il minimo ed il massimo sono operatori di aggregazione base. Il minimo dà il
valore più piccolo del set mentre il massimo dà il più alto valore del set. Essi non
danno un valore “di mezzo” ma possono essere veramente significativi in diversi
contesti. Questi aggregatori hanno le proprietà monotona, simmetrica, associativa,
idempotente.
Media geometrica
Media geometrica o proporzionale. Dati n numeri a1,a2,a3,…an si chiama loro
media geometrica il numero:
Ci si può facilmente convincere che, dati due numeri distinti, la loro media
geometrica è minore della loro media aritmetica.
Infatti:
Media armonica
La media armonica
è ... il reciproco della media aritmetica dei reciproci.
Particolarmente utile per qualche tipo di variabili come ad esempio per calcolare la
velocità media lungo un percorso.
OWA (Ordered Weighted Average)
Gli operatori di media ordinata pesata sono stati introdotti da Yager [20] per fornire
un mezzo di aggregazione di voti associati alla soddisfazione, permettendo di
utilizzare criteri multipli.
Dove σ è una permutazione che ordina gli elementi: x σ(1)≤ x
sono tutti non negativi (wi≥0) e la loro somma è uguale ad 1.
σ(2)
≤…≤
x σ(n).
I pesi
82
____________________________________________________________________
Questo operatore è molto utile, grazie alla sua versatilità, ed è stato ulteriormente
sviluppato dando luogo a diverse famiglie parametrizzate di aggregatori ed include
ben noti aggregatori come: il massimo, il minimo, la mediana, la media aritmetica.
Per ottenere questi particolare operatori possiamo scegliere semplicemente
particolari pesi:
Tabella 3.1 : OWA
Gli operatori OWA sono commutative, monotoni, idempotenti ed hanno un
comportamento compensativo. Questa ultima proprietà traduce di fatto che
l’aggregazione fatta da un OWA è sempre tra il massimo ed il minimo.
In pratica un operatore OWA di dimensione n è una funzione F : Rn → R, che ha
associati n vettori.
con
e
Inoltre
Dove bj è il jesimo elemento più grande del bag <a1…..,an>
Per esempio assumiamo
allora
Un aspetto fondamentale di questo operatore è il passaggio di riordinamento, in
particolare un aggregato ai non è associato ad un particolare peso w i ma piuttosto un
peso è associato ad una particolare posizione ordinata dell’aggregato.
83
____________________________________________________________________
WOWA (Weighted Order Weighted Average)
L’operatore WOWA è una funzione di aggregazione che generalizza la media pesata
e l’operatore OWA. Per mezzo di due diversi vettori di pesi, l’operatore permette la
fusione di un dato set di valori numerici considerando sia l’importanza delle sorgenti
che hanno fornito i dati (come nella media pesata) ed il grado di compensazione o
differenza tra i valori grandi ed i valori piccoli (come nell’operatore OWA).
3.5.3 Aggregatori creati per la simulazione
Gli aggregatori creati per la simulazione sono:
Discard dà la possibilità di differenziare voti positivi da pseudo voti negativi
(asserzioni scartate). Questo nella prospettiva di avere un browser di asserzioni che
consente di eliminare da un elenco di asserzioni, restituite dopo un processo di
ricerca, alcuni risultati non ritenuti significativi.
Nel caso del discard si ha che le votazioni sia positive sia negative che avvengono
nel quanto di tempo di aggregazione vengono inserite in due code distinte.
Il calcolo per entrambe avviene secondo questa formula:
TotalWeight = ! Expertise RELEVANCE
Expertise RELEVANCE
Totalweight
AverageTrustComponent = ! Expertise " TrustWeight
TrustWeight =
Dove per Expertise intendiamo un valore (compreso tra 0 e 1) che rappresenta la
conoscenza di determinati concetti relativi al ruolo dell’utente e per Relevance
intendiamo un parametro settabile, dall’utente della simulazione, che rappresenta
quanto è rilevante (in misura esponenziale) l’expertise dell’utente simulato.
Si otterranno così valori compresi tra 0 e 1 per i voti positivi e tra 0 e -1 per quelli
pseudo-negativi. L’aggregazione finale avviene secondo questa formula:
A.T . =
(AvgTrustComponent + * PosVotes )+ (AvgTrustComponent ! * DiscVotes )
PosVotes + DiscVotes
Dove A.T. è Average Trust, AvgTrustComponent+/- è la media pesata dei voti
positivi/scartati, PosVotes e DiscVotes sono rispettivamente il numero di voti
positivi e di voti negativi dell’ultimo periodo di tempo prima dell’aggregazione.
L’A.T. verrà poi moltiplicata per un fattore di crescita compreso tra 0 e 1 settato in
fase di avvio della simulazione, che limita la possibile crescita o decrescita del
valore per ogni aggregazione.
FinalTrust = StartTrust + (A.T . ! GrowthFactor )
84
____________________________________________________________________
Aging prevede la possibilità di far “invecchiare” il valore delle asserzioni. Quando
le asserzioni non vengono votate da tempo questo meccanismo fa si che il loro
valore decresca gradualmente finché non vengono votate ancora almeno una volta.
La componente positiva dei voti è ottenuta in modo del tutto analogo a quella
dell’aggregatore Discard mentre la componente di invecchiamento viene ottenuta
seguendo questo ragionamento:
#E = ExpectedvalueT "10!T "1 " ExpectedvalueT "9!T 0
Se "E ! 0 allora il trust finale dell’asserzione deve essere:
FinalTrust = StartTrust + (!E * AgingFactor )
Dove per T-10 intendiamo il tempo dieci “istanti” fa T0 indichiamo questo
momento…ecc si ottiene cioè traslando di uno e aggiungendo il valore attuale.
In questo caso il valore deve essere fatto decrescere per il valore pari alla differenza
qui sopra, sempre moltiplicato per un fattore compreso tra 0 e 1(AgingFactor) che
stabilisce di quanto il trust può decrescere(ad esempio ho stabilito che al massimo
può invecchiare di uno 0,01).
Per entrambi gli aggregatori il tempo di aggregazione scandisce ogni quanto avviene
il calcolo del valore aggregato. É importante calibrare in modo corretto questo
valore per sincronizzarlo con quelli che sono i tempi di produzione degli utenti
(quanto sono attivi e reattivi).
Ad esempio, un tempo di aggregazione troppo breve rispetto all’attività dell’utente
fa sì che, nel caso dell’aging il valore invecchi troppo rapidamente (molti zero nel
valore atteso di voti), nel caso del discard non ci sarebbe molta differenza a parte
vedere meno voti nel quanto di tempo previsto dall’aggregazione (sarebbe come
vedere aggiornamento in tempo reale del valore di trust).
3.6. Progetti collegati
I progetti correlati sono tutti appartenenti al progetto KIWI (Knowledge-based
Innovation for the Web Infrastructure) i cui obiettivi sono:
mettere a punto le tecniche necessarie per ricavare interattivamente dalle
ontologie generali di dominio delle rappresentazioni personalizzate di spazi
concettuali "centrati sull'utente", cioè riferiti al ruolo e alla visione del mercato di
singoli e delle piccole organizzazioni, ed utilizzare queste rappresentazioni per
accedere ai dati attraverso concetti familiari all'utente, con granularità controllata;
•
le visioni locali della conoscenza di dominio saranno espresse attraverso profili
dinamici degli utenti, anch'essi rappresentati sotto forma di metadati basati su XML
•
85
____________________________________________________________________
e parametrizzati rispetto alle specifiche esigenze informative al momento
dell'accesso;
le viste personalizzate sui metadati RDF così ottenute saranno poi usate per
l'accesso navigazionale e cooperativo, basato sulla conoscenza, alle informazioni
Web da parte di utenti umani e di agenti software che usino protocolli "leggeri"
basati su XML come il Simple Object Access Protocol (SOAP), nonchè per
l'alimentazione di vari tipi di cruscotti di monitoraggio, sistemi di reporting e di
supporto alle decisioni. La personalizzazione delle ontologie di dominio sulla base
dei profili utente sarà inoltre utilizzata per permettere di esprimere e imporre
politiche di controllo dell'accesso innovative perchè basate sulla semantica dei dati,
cioè sui concetti usati per indicizzarli rispetto all'ontologia di dominio e alle viste
personalizzate calcolate su di essa.
•
86
____________________________________________________________________
Capitolo 4.
Il Simulatore in funzione
4.1. Interfaccia utente
L’interfaccia utente è stata pensata in modo da suddividere la simulazione in due
parti distinte: una rappresenta la creazione dei componenti del sistema da simulare
(entità statica), che verranno raggruppati in un “Project”, l’altra il run effettivo della
simulazione (entità dinamica).
4.1.1 Creazione dei componenti
Per componenti si intendono tutte le entità che interagiscono all’interno del sistema
da simulare.
4.1.1.1
Schema
Figura 4.1: Impostazioni dello schema
87
____________________________________________________________________
Lo schema rappresenta un “filtro” che sovrapposto alla macchina a stati finiti
descrive la probabilità, che un utente simulato ha, di muoversi tra gli stati della
macchina stessa. È quindi necessario definire una macchina a stati finiti (premendo
il bottone Set state Machine) per poter creare uno schema vuoto.
Successivamente, perché lo schema risulti valido, è necessario definire tutte le
probabilità dei cammini in uscita da ciascuno stato, ovviamente la somma delle
probabilità degli archi uscenti da un nodo è 1.
4.1.1.2
Usergroup
Figura 4.2: Schermata degli Usergroup
Lo usergroup è l’entità più importante in quanto descrive le caratteristiche che
definiscono il tipo di popolazione attiva nel sistema. Si vedrà nel capitolo 5 quanto
composizioni diverse di popolazione possano influire sul risultato della simulazione.
Uno Usergroup rappresenta un sottoinsieme della popolazione simulata con
caratteristiche uguali quali:
- Interest Variance rappresenta quanto l’utente simulato tende a scegliere concetti
in cui ha più expertise. Più il parametro tende a zero e più sceglierà concetti con
expertise alto, più si avvicina a 1 e più espanderà il suo interesse verso tutti i
concetti.
- User Delay è il valore che definisce la velocità, in milllisecondi, di interazione
dell’utente. Descrive ogni quanto tempo un utente simulato passerà da uno stato
ad un altro ed eseguire un’azione.
- User Type definisce se l’utente simulato è considerato conosciuto dal
sistema(registered) oppure è estreno al sistema(anonymous).
88
____________________________________________________________________
-
-
Treshold value definisce la “prudenza” dell’utente simulato. Sotto una certa
soglia di expertise l’utente decide di non esprimere giudizi sulle asserzioni. Più il
valore è alto, più l’utente è prudente nel valutare/scrivere le asserzioni (si astiene
dal giudizio di concetti con valori di expertise sotto il valore definito) e
viceversa.
Set State Machine definisce la macchina a stati finiti che rappresenta gli stati in
cui l’utente simulato si può trovare e le relative azioni.
Set Schema aggiunge lo schema che caratterizza come l’utente simulato si
muove tra gli stati. Deve essere completamente compatibile con la macchina a
stati finiti.
Set Group Role definisce le conoscenze degli utenti simulati riguardanti la
Concept List. Nel caso di un utente registrato, rappresenta la figura professionale
riconosciuta all’interno del sistema, nel caso dell’utente anonimo sono le
effettive conoscenze non certificate e non risconosciute dal sistema.
I parametri restanti definiscono il nome dello Usergroup ed il numero di utenti che
ne fanno parte.
4.1.1.3
Project
Figura 4.3: Definizione di un project
Il project raccoglie tutti i componenti necessari alla simulazione, inanzitutto la
Concept List (è l’insieme dei concetti che possono essere utilizzati nella creazione
delle asserzioni) sui cui si basano tutti i ruoli del progetto.
89
____________________________________________________________________
Anonymous users default expertise definisce come il sistema considera la
componente di expertise degli utenti anonimi.
Forced Treshold stabilisce un limite forzato di expertise al di sotto del quale la
creazione o votazione di asserzioni viene inibita.
Con Add, Remove ed Edit usergroup è possibile aggiungere, rimuovere ed editare
gli usergroup, questo è permesso se gli Usergroup hanno nomi diversi e se il ruolo è
compatibile con la Concept List.
4.1.2 Il Run della simulazione
4.1.2.1
Simulation Configuration
Figura 4.4: Configurazione della simulazione
Dopo avere creato e salvato il project è possibile lanciare la simulazione con il
comando Run. Prima di avviare la simulazione è necessario impostare alcuni
parametri di fondamentale importanza:
Aggregator config
- Type definisce il tipo di aggregatore(discard o aging) utilizzato per il calcolo del
trust.
- Use weighted positive vote stabilisce se pesare o no i voti positivi dati alle
asserzioni.
90
____________________________________________________________________
-
-
Use weighted discarded stabilisce se pesare o no i discard dati alle asserzioni.
Weight Relevance definisce quanto è rilevante (in misura esponenziale)
l’expertise dell’utente simulato.
Growth weight fattore di crescita compreso tra 0 e 1, che limita la possibile
crescita o decrescita del valore per ogni aggregazione.
Aging Weight fattore di discesa compreso tra 0 e 1, che limita la possibile
crescita o decrescita del valore per ogni aggregazione.
Assertion evaluation permette di decidere se le asserzioni prodotte o votate da un
utente simulato vengono etichettate con una segnature. Con signature spuntato
un utente simulato non potrà votare più volte un’asserzione.
Activation interval definisce ogni quanti secondi l’aggregatore entra in
funzione.
Resources List
- Con i bottoni Add, Remove e Edit Resources è possibile definire le
caratteristiche delle risorse che potranno essere valutate dagli utenti simulati. Se
una risorsa contiene uno o più concetti della Concept List significa che sono i
concetti che effettivamente caratterizzano quella risorsa e starà agli utenti
simulati riconoscerne la presenza.
4.1.2.2
UserGroups
Figura 4.5: Visualizzazione grafico Roles Distribution degli usergroup
91
____________________________________________________________________
In questa fase di simulazione è possibile visualizzare alcune delle caratteristiche
statiche del sistema quali: “Roles distribution”, “Usergroups”, “User roles
recognized by system” e “Population experise”.
In figura 4.5 è mostrato un esempio di “Roles distribution”, che in particolare
rappresenta, con un grafico a torta,. la composizione dei ruoli rispetto alla
popolazione totale. Questo grafico mostra esplicitamente anche i ruoli degli utenti
anonimi.
Il grafico “Usergruops” rappresenta invece la composizione degli Usergroup rispetto
alla popolazione totale, senza distinguere i gruppi di utenti anonimi.
Il grafico “User roles recognized by system” mostra come il sistema vede la
popolazione. In questo caso c’è una distinzione tra ruoli registrati e ruoli anonimi,
infatti i ruoli anonimi vengono raggruppati in un’unica entità anonima.
A seconda della composizione della popolazione questi tre grafici possono risultare
identici o molto diversi tra loro.
Figura 4.6: Visualizzazione grafico Expertise degli usergroup
In figura 4.6 è mostrato il grafico “Population expertise” che permette di confrontare
l’expertise di ogni Usergroup, relativa ai singoli concetti della Concept List, tra loro
e rispetto alla expertise media della popolazione del sistema.
92
____________________________________________________________________
4.1.2.3
Assertions Trust
Figura 4.7: Schermata Assertions Trust
Il pannello “Assertions Trust” permette di visualizzare le singole risorse
precedentemente generate all’interno del “Simulation Configuration” in modo da
poterne osservare, nel pannello “Concepts Contained”, i concetti effettivamente
contenuti all’interno di essa e nel pannello “Assertions”, le asserzioni create
dinamicamente dagli utenti simulati.
La selezione di ogni singola asserzione del pannello “Assertions” produce un grafico
“Assertion Trust” che mostra l’andamento del trust nel tempo.
Nel pannello “Assertion Statistics” compaiono inoltre alcuni parametri che
caratterizzano l’evoluzione del valore di trust dell’asserzione.
93
____________________________________________________________________
4.1.2.4
General Info
Figura 4.8: Schermata General Info
Il pannello General Info dà la possibilità di visionare l’andamento del sistema nel
tempo secondo tre punti di vista.
Il primo di questi è “System Trustwothiness” (mostrato in figura 4.8), che disegna in
tempo reale, il livello di veridicità del sistema calcolato come rapporto tra la somma
dei trust delle asserzioni corrette e la somma dei trust di tutte le asserzioni.
Il secondo grafico è “Precision” (mostrato in figura 4.9) che disegna nel tempo il
rapporto tra il numero di asserzioni che dovrebbero comparire e il numero delle
asserzioni che sono effettivamente comparse. Questo calcolo mette in luce quanto la
popolazione è capace di individuare i concetti effettivamente rilevanti delle risorse.
Più questo valore è alto, più la popolazione è precisa.
94
____________________________________________________________________
Figura 4.9: Visualizzazione grafico Precision
L’ultimo grafico che è possibile analizzare è “Recall” (mostrato Figura 4.10). Il
valore di richiamo è inteso come il rapporto tra il numero delle asserzioni corrette
che effettivamente compaiono e il numero delle asserzioni corrette che dovrebbero
comparire, quindi mostra la frazione di asserzioni classificate come esatte e rilevanti
(cioè realmente relative ad una risorsa).
95
____________________________________________________________________
Figura 4.10: Visualizzazione grafico Recall
96
____________________________________________________________________
Capitolo 5.
Conclusioni.
5.1 Prove di evoluzione del sistema
In questo capitolo si considererà un esempio di un possibile sistema reale. Le prove
di simulazione serviranno per sperimentare quali parametri influenzano in modo
significativo i risultati presi in considerazione come output del simulatore attuale.
Con queste simulazioni non si vuole dare una valutazione quantitativa di un sistema
reale, in quanto il simulatore è composto in parte da algoritmi non ancora
sufficientemente complessi da rappresentare in maniera verosimile la realtà, anche
se ne copre molti aspetti.
5.1.1 Scelta del contesto di esempio per la simulazione
Il contesto preso in esame per la simulazione rappresenta una società che si occupa
di manutenzione e riparazione di computer. Le risorse analizzate sono quindi i
computer arrivati che necessitano di riparazioni, mentre gli utenti simulati sono i
tecnici ai quali vengono sottoposte queste risorse per stabilire quali sono i
malfunzionamenti. La “Concept List” considerata è un insieme di termini legati ai
malfunzionamenti più comuni rilevabili su un computer, per semplicità se ne è
scelto un numero molto limitato. Sono qui elencati i concetti considerati:
- Video card hardware
- Video drivers
- Virus
- Mouse hardware
- Hard-disk controller
- Hard-disk hardware
- Network configuration
- O.S. corrupted
- RAM malfunction
-Mouse driver
- Software not compatible
- Security
- Memory hardware
- Overheating
- CD/DVD controller
- CD/DVD driver
- Power supply
- Bios malfunction
- Cluster
I tecnici scrivono e valutano asserzioni legate ai malfunzionamenti delle risorse e
dopo un certo numero di interazioni vengono evidenziate quelli che secondo la
popolazione del sistema sono i problemi più plausibili.
Per simulare in modo più completo l’utente si è cercato di far sì che questi ultimi
valutino i concetti della “Concept List” anche in base ad un “interesse” legato alle
proprie conoscenze.
97
____________________________________________________________________
Come accennato nel capitolo 4 l’output della simulazione è rappresentato da tre
grafici (“System Trustworthiness”, “Precision”, “Recall”) grazie ai quali si
evidenziano alcune delle caratteristiche del sistema in evoluzione nel tempo. Il
grafico “System Trustworthiness” permette di valutare quanto la popolazione del
sistema sia in gardo di garantire l’affidabilità delle asserzioni prodotte. Questo
valore è il rapporto tra la somma del trust delle asserzioni corrette e la somma del
trust di tutte le asserzioni. Il grafico “Precision” evidenzia quanto la popolazione sia
capace di individuare solo i concetti effettivamente rilevanti delle risorse. Questo
valore è calcolato come rapporto tra il numero delle asserzioni corrette rispetto al
numero totale delle asserzioni prodotte.
Il grafico “Recall” è inteso come il rapporto tra il numero delle asserzioni corrette
che effettivamente compaiono e il numero delle asserzioni corrette che dovrebbero
comparire, quindi mostra la frazione di asserzioni classificate come esatte e rilevanti
(cioè realmente relative ad una risorsa).
5.1.2 La composizione della popolazione
Con le seguenti quattro simulazioni si mostra quale rilevanza riveste la distribuzione
della conoscenza della popolazione rispetto alla “Concept List”.
5.1.2.1 Prima simulazione
La prima simulazione prevede che gli utenti simulati siano tutti esperti, cioè che
abbiano expertise elevata rispetto ai concetti che più gli competono, e ruoli che
coprono in maniera uniforme tutta la “Concept List” in modo da rappresentare una
situazione ideale. Riportiamo nella tabella i parametri della prima simulazione
chiamata “Ideale”.
Usergroups
Role
N°
Hardware expert 10
Software expert 10
Network expert 10
Number
40
Aggregator
Parameter
Value
Type
Discarded
Relevance Weight
1.0
Growth Weight
0.4
Aging Weight
0.1
Aggregation interval
1 sec.
Resources List
% of correct concepts
15%
Forced concepts
None
Tabella 5.1: Parametri simulazione “Ideale”
98
____________________________________________________________________
I grafici risultanti dalla simulazione sono i seguenti:
Grafico 5.1: Trustworthiness “Ideale”
Grafico 5.2: Recall “Ideale”
Grafico 5.3: Precision “Ideale”
Come prevedibile si può notare che sia la trustworthiness, sia la recall tendono ad 1,
mentre la precision ha un valore molto elevato.
99
____________________________________________________________________
5.1.2.2 Seconda simulazione
La seconda simulazione prevede che gli utenti simulati siano esperti, ma, solo in
alcuni concetti della “Concept List”, quindi la conoscenza non è distribuita
uniformemente.
Riportiamo nella tabella i parametri della seconda simulazione chiamata per le sue
caratteristiche “Esperti non equamente distribuiti”.
Usergroups
Role
N°
Software expert 10
Network expert 10
Number
40
Aggregator
Parameter
Value
Type
Discarded
Relevance Weight
1.0
Growth Weight
0.4
Aging Weight
0.1
1 sec.
Resources List
15%
Forced concepts
None
Tabella 5.2: Parametri simulazione “Esperti non equamente distribuiti”
Grafico 5.4: Trustworthiness “Esperti non equamente distribuiti”
100
____________________________________________________________________
Grafico 5.5: Recall “Esperti non equamente distribuiti”
Grafico 5.6: Precision “Esperti non equamente distribuiti”
Come si può notare sia la trustworthiness, sia la precision tendono a valori elevati,
mentre la recall ha un valore scarso.
5.1.2.3 Terza simulazione
La terza simulazione è simile a quella “Ideale” con l’introduzione di una
componente di popolazione con esperienze generiche (con expertise medio 0.35)
distribuite su tutta la “Concept List”.
Riportiamo nella tabella i parametri della terza simulazione chiamata per le sue
caratteristiche “Esperti ben distribuiti e Generici ben distribuiti”.
Usergroups
101
____________________________________________________________________
Role
Software expert
Network expert
Hardware expert
Generical
technician
Number
60
N°
10
10
10
30
Aggregator
Parameter
Value
Type
Discarded
Relevance Weight
1.0
Growth Weight
0.4
Aging Weight
0.1
1 sec.
Resources List
15%
Forced concepts
None
Tabella 5.3:
Parametri simulazione “Esperti ben distribuiti e Generici ben distribuiti”
Grafico 5.7: Trustworthiness “Esperti ben distribuiti e Generici ben distribuiti”
Grafico 5.8: Recall “Esperti ben distribuiti e Generici ben distribuiti”
102
____________________________________________________________________
Grafico 5.9: Precision “Esperti ben distribuiti e Generici ben distribuiti”
Come si può notare sia la trustworthiness, sia la recall tendono a valori elevati,
mentre la precision ha un valore medio.
5.1.2.4 Quarta simulazione
La quarta simulazione è simile alla simulazione “Esperti non equamente distribuiti”
con l’aggiunta di tecnici generici con expertise non uniforme come quella degli
esperti.
Riportiamo nella tabella i parametri della terza simulazione chiamata per le sue
caratteristiche “Esperti non equamente distribuiti e Generici non equamente
distribuiti”.
Usergroups
Role
N°
Software expert 10
Network expert 10
Generical
30
technician
Number
40
Aggregator
Parameter
Value
Type
Discarded
Relevance Weight
1.0
Growth Weight
0.4
Aging Weight
0.1
1 sec.
Resources List
15%
Forced concepts
None
Tabella 5.4:
Parametri simulazione “Esperti non equamente distribuiti e Generici non equamente
distribuiti”
103
____________________________________________________________________
Grafico 5.10: Trustworthiness “Esperti non equamente distribuiti e Generici non
equamente distribuiti”
Grafico 5.11: Recall “Esperti non equamente distribuiti e Generici non equamente
distribuiti”
Grafico 5.12: Precision “Esperti non equamente distribuiti e Generici non equamente
distribuiti”
Come si può notare la trustworthiness ha un valolre medio-alto, la recall tende a
valori medi, mentre la precision ha un valore molto scarso.
104
____________________________________________________________________
5.1.2.5 Osservazioni sulla composizione della popolazione
Confrontando i grafici delle quattro simulazioni si può notare che la Recall è
influenzata dalla uniformità di distribuzione delle conoscenze sulla “Concept List”.
All’aumentare della distribuzione sulla “Concept List”, si ha un miglioramento del
valore finale di recall. Questo risultato è anche influenzato da un parametro legato
ad un intervallo di “interesse” che potrebbe spingere un utente a valutare concetti
che meno gli sono congeniali, infatti, all’allargarsi dell’interesse la recall sale,
mentre allo stringersi verso i concetti più legati al ruolo, la recall diminuisce.
Il parametro Precision invece, è influenzato per la maggior parte dal livello di
expertise medio del sistema, lo si può notare nei risultati diversi ottenuti tra la
simulazione uno e la simulazione tre. Si può anche notare quaesto aspetto
confrontando i grafici della simulazione due e della simulazione quattro. Nella
simulazione due si nota una precision molto elevata, questo è dovuto ad un forte
interesse degli esperti solo rispetto ai concetti che gli competono fortemente. Nella
quattro, invece, la semplice aggiunta di utenti generici ha portato ad un crollo della
precision dovuta al fatto che i loro interessi sono più ampi e meno sicuri (quindi
hanno commesso più errori).
Il parametro Trustworthiness, come osservabile da tutte e quattro le simulazioni è
influenzato quasi esclusivamente dal fatto che esistano contemporaneamente due
fattori negativi quali la non completa distribuzione delle conoscenze sulla “Concept
List” e l’abbassamento del expertise media di tutta la popolazione.
5.1.3 La composizione delle risorse
Con la seguente simulazione si mostra quale rilevanza riveste la distribuzione delle
risorse nel caso in cui la popolazione non abbia conoscenze ben distribuite sulla
“Concept List”. Non si sono considerate altre configurazioni di utenti, in quanto, una
data una buona distribuzione degli utenti sulla “Concept List”, una qualsiasi
configurazione dei concetti delle risorse avrebbe dato gli stessi risultati.
Confronteremo quindi una nuova simulazione con la simulazione degli “Esperti non
equamente distribuiti e Generici non equamente distribuiti” (trattata nel paragrafo 5.1.2.4).
5.1.3.1 Simulazione
La simulazione intende dimostrare la caduta del rendimento finale del sistema nel
caso in cui i concetti delle risorse fossero molto distanti dalle conoscenze della
popolazione.
Vengono riportati nella pagina successiva i parametri relativi alla simulazione.
105
____________________________________________________________________
Usergroups
Role
N°
Software expert 10
Network expert 10
Generical
30
technician
Number
20
20
Aggregator
Parameter
Value
Type
Discarded
Relevance Weight
1.0
Growth Weight
0.4
Aging Weight
0.1
1 sec.
Resources List
Forced concepts
0%
Hard-disk hardware,
Hard-disk controller
0%
Video card hardware,
power supply
Tabella 5.5: Parametri della simulazione
I grafici ottenuti per questa simulazione sono:
Grafico 5.13 :Trustworthiness
Grafico 5.15 :Recall
106
____________________________________________________________________
Grafico 5.14 :Precision
5.1.3.2 Osservazioni sulla composizione delle risorse
Questi grafici ottenuti mostrano come il sistema risulti molto sensibile al tipo di
concetti contenuti nelle risorse, infatti nel caso in cui le risorse sono per la
maggioranza di competenza della popolazione si ha un sistema molto simile a quello
descritto nella simulazione “Ideale” descritta nel paragrafo 5.1.2.1, quindi un
sistema molto performante. Nel caso in cui la composizione delle risorse fosse molto
distribuita si ha una situazione molto simile alla simulazione descritta nel paragrafo
5.1.2.4, dove già si notava un forte abbassamento della qualità dei risultati prodotti
dal sistema. Nel caso invece analizzato in questo paragrafo si nota il caso estremo in
cui il sistema produce risultati non utili.
5.1.4 Utenti anonimi e aggregatori
Gli utenti anonimi sono una componente della popolazione che apre il sistema verso
una situazione più dinamica ma meno controllabile. Si è deciso di cambiare
approccio riguardo al sistema considerato sino ad ora, dove c’erano solo utenti
autenticati che davano la loro opinione sui problemi dei computer analizzati. Ora
passiamo ad una situazione in cui ad esempio abbiamo un forum di utenti anonimi
che rispondono a problematiche relative a malfunzionamenti di computer esposti da
altri utenti dello stesso forum.
Si è pensato di modellare due simulazioni in cui lo stesso gruppo di utenti anonimi
agisce, ma con la differenza nell’utilizzo dell’aggregatore che effettua il calcolo dei
valori di trust delle asserzioni.
5.1.4.1 Simulazione uno
Questa simulazione prende in considerazione utenti anonimi con aggregatore
“discard”, dove gli utenti sono liberi sia di votare positivamente le asserzioni che di
scartare le asserzioni che non considerano interessanti o veritiere.
107
____________________________________________________________________
Si è considerata una popolazione di utenti anonimi con media di expertise di circa
0.35 e conoscenze ben distribuite.
I parametri della simulazione sono i seguenti:
Usergroups
Role
N°
Anonymous
30
users
Number
40
Aggregator
Parameter
Value
Type
Discarded
Relevance Weight
1.0
Growth Weight
0.3
Aging Weight
0.1
2 sec.
Resources List
15%
Forced concepts
None
Tabella 5.6: Parametri della simulazione uno
I risultati della simulazione sono:
Grafico 5.16 :Trustworthiness simulazione uno
Grafico 5.17 :Recall simulazione uno
108
____________________________________________________________________
Grafico 5.18 :Precision simulazione uno
5.1.4.2 Simulazione due
Questa simulazione prende in considerazione utenti anonimi con aggregatore
“aging”, dove gli utenti sono liberi sia di votare positivamente le asserzioni ma non
di scartare le asserzioni che non considerano interessanti o veritiere. La componente
negativa del valore di trust aggregato è dato dall’invecchiamento.
Si è considerata una popolazione di utenti anonimi con media di expertise di circa
0.35 e conoscenze ben distribuite.
I parametri della simulazione sono i seguenti:
Usergroups
Role
N°
Anonymous
30
users
Number
40
Aggregator
Parameter
Type
Relevance Weight
Growth Weight
Aging Weight
Resources List
15%
Value
Aging
1.0
0.3
0.1
2 sec.
Forced concepts
None
Tabella 5.7: Parametri della simulazione due
109
____________________________________________________________________
I risultati della simulazione sono:
Grafico 5.19 :Trustworthiness simulazione due
Grafico 5.20 :Recall simulazione due
Grafico 5. 21 :Precision simulazione due
110
____________________________________________________________________
5.1.4.3 Osservazioni sugli utenti anonimi e sugli aggregatori
Dai risultati ottenuti si può notare che l’unica differenza ottenuta è nel tempo di
convergenza ad uno della trustworthiness, in particolare con aggregatore di aging si
è avuto un tempo di convergenza minore rispetto alla simulazione con aggregatore
discard. In più la trustworthiness nel caso del discarded non è arrivata ad uno.
5.2 Sviluppi futuri
Per questo tool di simulazione integrato nell’ambito del progetto K.I.W.I. sono
previsti futuri miglioramenti degli algoritmi scelti per l’aggregazione, e una più
precisa profilazione degli utenti che permetterà di definirne al meglio i
comportamenti.
Il tool così migliorato permetterà di testare il tool in una situazione più realistica.
111
____________________________________________________________________
CITAZIONI
[1] R. Falcone and C. Castelfranchi. Social Trust: A Cognitive Approach, pages 55–
99.Kluwer, 2001
[2] ebay. http://www.ebay.com.
[3] Epinions. http://www.epinions.com.
[4] ] Amazon.com. http://www.amazon.com.
[5] www.google.com/intl/en/technology/
[6] http://slashdot.org/
[7] www.officialsm.net/articoli/trustrank_for_dummies.pdf
[8] http://www.pgpi.org/
[9] Poblano - a distributed trust model for peer-to-peer networks.
http://www.jxta.org/project/www/docs/trust.pdf.
[10] www.jxta.org
[11] R. Dingledine, M.J. Freedman, and D. Molnar. The free haven project:
Distributed
anonymous storage service. In Proc. of the Workshop on Design Issues in Anonymity
and Unobservability, Berkeley, California, USA, July 2000.
[12] www.foaf-project.org
[13] R. Aringhieri, E. Damiani, S. D. C. D. Vimercati, S. Paraboschi, and P.
Samarati. Fuzzy Techniques for Trust and Reputation Management in Anonymous
Peer-to-Peer Systems. Journal of the American Society for Information Science and
Technology, 57(6), April 2006.
[14] jena.sourceforge.net
[15] java.sun.com/
[16] jakarta.apache.org/tomcat/
[17] www.mysql.com
[18] www.w3.org/DSig
[19] Paolo Ceravolo, Ernesto Damiani, and Marco Viviani. Adding a Trust Layer to
Metadata Generators
[20] Yager, R. R., On ordered weighted averaging aggregation operators in multicriteria decision making
FONTI
- A. Abdul-Rahman and S. Hailes. Supporting Trust in Virtual Communities. In
Proceedings of the Hawaii International Conference on System Sciences, Maui,
Hawaii, 4-7 January 2000 2000.
- K. Aberer and Z. Despotovic. Managing trust in a peer-2-peer information system.
In Henrique Paques, Ling Liu, and David Grossman, editors, Proceedings of the
Tenth International Conference on Information and Knowledge Management
(CIKM01), pages 10–317. ACM Press, 2001.
112
____________________________________________________________________
- E. Damiani et al. A Reputation-Based Approach for Choosing Reliable Resources
in Peer-to-Peer Networks. In Proceedings of the 9th ACM conference on Computer
and Communications Security (CCS’02), pages 207–216. ACM, 2002.
- A. Jøsang, E. Gray, and M. Kinateder. A Survey of Trust and Reputation Systems
for Online Service Provision
- R. Levien. Attack Resistant Trust Metrics (to appear). PhD thesis, University of
California at Berkeley, 2004.
-Rainer Burkhardt. UML: Uni_ed Modeling Language. Addison-Wesley, 1997.
- D.Gambetta. Can we trust? In Trust: Making and Breaking Cooperative Relations,
Oxford, 1990.
- Philip R. Zimmermann. The Of_cial PGP User's Guide. MIT Press, Cambridge,
MA, USA, 1995.
- Alfarez Abdul-Rahman. The pgp trust model. In EDI-Forum: The Journal of
Electronic Commerce, April 1997.
- Alfarez Abdul-Rahman and Stephen Hailes. A distributed trust model. pages
48ñ60.
- Yager, R. R., On ordered weighted averaging aggregation operators in multicriteria decision making, IEEE transactions on Systems, Man and Cybernetics 18,
183-190, 1988.
- W3C Signed RDF Workshop, A Position Paper.Martin Lee, AND Data Ltd.
- RDF Schema Specification 1.0, W3C Candidate Recommendation 27 March 2000.
http://www.w3.org/TR/rdf-schema/
WordNet
a
Lexical
Database
http://www.cogsci.princeton.edu/~wn/online/
- http://www.w3.org/TR/WD-rdf-syntax-971002/#signing
for
English.
- The Reputation, Opinion, Credibility and Quality (ROCQ) Scheme_ Anurag Garg
Roberto Battiti
Dipartimento di Informatica e Telecomunicazioni, Universit di Trento,
- Accuracy of Metrics for Inferring Trust and Reputation in Semantic Web-based
Social Networks Jennifer Golbeck, James Hendler University of Maryland, College
Park
- A Classification Scheme for Trust Functions in Reputation-Based Trust
management Qing Zhang, Ting Yu , and Keith Irwin Department of Computer
Science North Carolina State University
113
____________________________________________________________________
- Trust Modeling for Security Architecture Development Donna Andert,
RobinWakefield, and JoelWeise, Professional Services Security Practice Sun
BluePrints™ OnLine—December 2002
- Certifying Trust Ilari Lehti and Pekka Nikander Helsinki University of
Technology, Department of Computer Science
- Framework for the Semantic Web: An RDF Tutorial STEFAN DECKER,
PRASENJIT MITRA, AND SERGEY MELNIK Stanford University
- Berners-Lee, James Hendler, Ora Lassila, “ The Semantic Web”, Scientific
American,
17
Maggio
2001
http://www.scientificamerican.com/article.cfm?articleID=00048144-10D2-1C7084A9809EC588EF21&catID=2
Tim
Berners-Lee,
“Semantic
http://www.w3.org/DesignIssues/Semantic.html
Web
roadmap”,
1998.
-Tim Berners-Lee, “Why RDF model is different from the XML model”, Settembre
1998 http://www.w3.org/DesignIssues/RDF-XML.html
- The semantic web Home Page, W3C Consortium http://www.w3.org/2001/sw/
- The web Ontology Group Home Page(Web Ont), W3C Consortium
http://www.w3.org/2001/sw//WebOnt
- Semantic Web Activity Statement http://www.w3.org/2001/sw/Activity
-Web Ontology Language OWL Home Page http://www.w3.org/2004/OWL
- http://logicerror.com/signYourPage
-www.w3.org/2000/10/swap/doc/Trust
-XML. Riferimento al sito http://www.w3.org/XML/
- Strutturare la conoscenza:XML, RDF, Semantic Web Oreste Signore W3C Office
in Italy e ISTI-CNR
114

Simulazione dell`evoluzione del Trust all`interno di una comunità di

Transcript

Documenti analoghi

SEMANTIC WEB

Lettera di manleva

TERZA A Allegato n 2 Simulazioni terza prova

Strutturare la conoscenza: XML, RDF, Semantic Web

simulazione III prova - Liceo artistico "A. Modigliani"

IMUN : Italian Model United Nations

SP-2800P USB SPEAKER SET

RDF Triple Store: Virtuoso - Corso di Laurea in Ingegneria Informatica

VIRTUOSO DB:CARATTERISTICHE

Piano Strategico ICT sanità