PERSONAL ONTOLOGY STUDIO ED IMPLEMENTAZIONE NELL AMBITO DEL PROGETTO TIM

P ^ERSONAL O ^NTOLOGY

STUDIO ED IMPLEMENTAZIONE NELL’AMBITO DEL PROGETTO TIM

Corso di Seminari di Ingegneria del Software Professore Giuseppe De Giacomo

A.A. 2006-2007

Raffaele Giuliano, Marco Piva, Fabio Terella, Emanuele Tracanna

I ^{L PROGETTO} TIM

Ricerche recenti hanno evidenziato la necessità di passare da sistemi focalizzati sulla semplice gestione dei dati

personali (PIM – Personal Information Management) a

sistemi focalizzati sulla gestione dell’interazione personale.

Per rispondere a questa esigenza, il progetto TIM (Task- centered Information Management) si pone come obiettivo quello di realizzare un PIMS (Personal Interaction

Management System) ovvero un sistema in grado di supportare l’utente nell’esecuzione dei propri tasks, alleggerendone il carico cognitivo.

S TRUTTURA DI UN PIMS

3

C OMPONENTI PRINCIPALI DI UN PIMS

Componenti principali di un PIMS sono:

1. un Recogniser che trova frammenti di informazioni grezze semanticamente significativi e che possono essere utilizzati per le azioni dell’utente.

2. una Personal Ontology che contiene la conoscenza specifica dell’utente.

3. un Task Inferencer che sulla base dei dati riconosciuti dal recogniser e prelevati dall’ontologia, considerando anche la loro provenienza, suggerisce i prossimi

task/azioni da eseguire.

L ^A P ^ERSONAL O ^{NTOLOGY IN} TIM

Cosa intendiamo con il termine Personal?

Un’ontologia è personale nel senso che riflette la vista che l’utente ha del suo dominio di interesse: può essere usata, infatti, per dare un significato semantico alle informazioni contenute nei documenti dell’utente.

Nell’ambito del progetto TIM l’ontologia personale gioca un ruolo fondamentale e di duplice valenza:

• può essere vista come un utile archivio delle

informazioni correlate alla vita privata e professionale dell’utente

• può assumere un’importanza notevole nel supportare i tasks dell’utente tramite l’inferenza dei tasks stessi

5

L ^A P ^ERSONAL O ^{NTOLOGY IN} TIM

Punto di partenza per il nostro lavoro è stata un’ontologia personale sviluppata da un gruppo di ricerca di Atene:

essa contiene un nucleo di concetti generali che può essere arricchito per venire incontro a molti stereotipi di utente o profili individuali.

Nel nostro lavoro, ci siamo concentrati sul profilo utente del docente/ricercatore universitario modificando il

dominio di partenza.

L ^A P ^ERSONAL O ^{NTOLOGY DI} A ^TENE

L’ontologia iniziale conteneva circa 90 concetti, raggruppati in due

macroconcetti:

• Thing: racchiude concetti che

possono essere considerati esseri viventi (Living Thing), oggetti

materiali (Non Living Thing) ed oggetti con significato più astratto.

• Value_Class: racchiude dati

strutturati o tipi di dato complessi (ad es.: Zip_Code, Date o ISBN)

7

M ODIFICHE ALLA P ^ERSONAL O ^{NTOLOGY DI} A ^TENE

Per riferirci al nostro dominio di interesse abbiamo tralasciato alcuni concetti dell’ontologia per noi non rilevanti (ad es.

Animal), e ne abbiamo aggiunti degli altri:

• Travel: concetto che rappresenta le missioni dei docenti e dei ricercatori

• Moving: rappresenta gli spostamenti effettuati all’interno di una certa missione

Per poter utilizzare il sistema si è reso necessario riscrivere l’ontologia in OWL DL, dato che quella fornitaci era nel

formato .pont e .pins di Protégé.

L A TRADUZIONE DA OWL ^A DL-L ^ITE A

Primo passo del nostro lavoro è stato tradurre l’ontologia da OWL a DL-LiteA.

OWL

Non adatto a rappresentare ontologie con grandi

quantità di istanze nell’ABox a causa

dell’esponenzialità del reasoning (coNP-HARD)

DL-LiteA

Adatto a modellare vari linguaggi per ontologie, modelli concettuali (ER) e formalismi orientati agli oggetti (UML), tenendo bassa la complessità computazionale del

reasoning (LOGSPACE)

9

L A TRADUZIONE DA OWL ^A DL-L ^ITE A

Per la traduzione abbiamo seguito le regole seguenti relative ai singoli costrutti:

δ: indica il dominio dell’attributo (classe cui esso appartiene) ρ: indica il range dell’attributo (tipo di dato nel set dei tipi xsd) Attributi :

Molteplicità 1..*:

Molteplicità 0..1:

L A TRADUZIONE DA OWL ^A DL-L ^ITE A

Associazioni:

Molteplicità [classeA]_0..*__1..*_[classeB]

Molteplicità [classeA]_0..*__0..1_[classeB]

Molteplicità [classeA]_1..*__0..*_[classeB]

Molteplicità [classeA]_0..1__0..*_[classeB]

11

L A TRADUZIONE DA OWL ^A DL-L ^ITE A

SUBSET TRA ASSOCIAZIONI:

IS-A TRA CLASSI:

DISGIUNZIONE TRA CLASSI:

P ROBLEMI NELLA TRADUZIONE

SOLUZIONE: Scrivere un ruolo con nome univoco per ogni classe in gioco!

Problemi causati da ruoli che presentavano nel dominio o nel range l’unione di più classi.

13

P ROBLEMI NELLA TRADUZIONE

Problemi causati da attributi che presentavano nel dominio l’unione di più classi (cioè attributi con lo stesso nome in classi diverse).

T RADUZIONE DEI RUOLI INVERSI

Per quel che riguarda i ruoli inversi ci siamo serviti

dell’operatore ^– di DL-LiteA, omettendo nella traduzione i ruoli denotati con inverseOf…

Nell’esempio: inverseOfStartDate diventa in DL-LiteA startDate ^–

15

TB OX GENERATA DAL P ^LUGIN

Possiamo confrontare la TBox generata dal Plugin con la nostra traduzione DL-LiteA

• i concetti vengono identificati nella TBox del plugin con l’asserzione AtomicConcept

• le associazione vengono identificate con l’asserzione AtomicRole

• per il dominio degli attributi, per cui noi abbiamo utilizzato il simbolo δ laTBox del plugin utilizza

l’asserzione CAdomain(), mentre per il range, che è stato da noi indicato con ρ, il plugin utilizza l’asserzione

TB OX GENERATA DAL P ^LUGIN

17

TB OX GENERATA DAL P ^LUGIN - P ^ROBLEMI

Le asserzioni che non sono espressioni valide in DL- LiteA, non

vengono inviate per niente al

reasoner e viene generato un

warning per segnalare i problemi

TB OX GENERATA DAL P ^LUGIN - P ^ROBLEMI

19

Nello specifico i warnings generati dal plugin sono dovuti alle seguenti tipologie di asserzioni OWL non esprimibili in DL- LiteA:

• Transitività di alcuni ruoli (ad es. sibling nella classe Person)

• Attributi con domino costituito dall’unione di più classi (ad es. nameValue)

• Ruoli con dominio/range costituito dall’unione di più classi (ad es. website)

Come si comporta il plugin di fronte a questi problemi?

TB OX GENERATA DAL P ^LUGIN - P ^ROBLEMI

Il plugin aggira i problemi precedentemente elencati comportandosi nel seguente modo:

• Ignora le proprietà di transitività dei ruoli

• Ignora le asserzioni che definiscono il dominio degli attributi

“problematici” (mantenendo comunque i vincoli sul range e gli eventuali vincoli di funzionalità)

• Ignora le asserzioni che definiscono il dominio/range dei ruoli che hanno rispettivamente nel dominio/range l’unione di più classi

S PECIFICA DEL DB

Abbiamo ipotizzato di avere a disposizione varie sorgenti di dati da cui potere attingere non collegate fra loro. Nello specifico abbiamo assunto di avere tabelle provenienti da:

- un DB dell’università (Professore_Table, Ricercatore_Table, Corso_Table, Team_di_progetto_Table, Progetto_Table, Meeting_Table) da cui possiamo

prendere informazioni riguardo i docenti, i ricercatori, i corsi tenuti nell’università, i progetti in cui i docenti e i ricercatori sono coinvolti, la composizione del team di progetto e i meeting che si svolgono relativamente ad un progetto.

- un repository di contatti personali (Rubrica_Table, Email_Table,

Telefono_Table) da cui si possono reperire informazioni circa i contatti dell’utente, con date di nascita, codici fiscali, professioni ecc.

- modelli che l’utente (in particolare un docente o un ricercatore) deve compilare per una missione nell’ambito di un progetto (Missione_Table, Spesa_Table, Spostamento_Table) che contengono nello specifico, le missioni, le spese effettuate nella missione e gli spostamenti che avvengono nell’ambito della missione.

- un DB contenente informazioni sulle conferenze, gli articoli presentati e gli autori degli stessi (Conferenza_Table, Articolo_Table, Autori_Articolo_Table).

21

E LENCO DELLE T ^{ABELLE DEL} DB

P OPOLAZIONE DEL DB

Per la popolazione del DB ci siamo serviti di script PHP che generano query SQL di inserimento da inviare al DBMS MySQL (versione 5.0.45), su cui il nostro

database è memorizzato.

La popolazione è stata effettuata in modo pseudo-

randomico affinché fosse eterogenea e al tempo stesso sufficientemente significativa per l’esecuzione dei

mapping.

23

M ^{APPING TRA} DB ^E O ^NTOLOGIA

Un insieme di mapping assertions può essere suddiviso in due sottoinsiemi:

• uno per i cosiddetti typing mappings: ovvero quelle asserzioni usate per assegnare tipi di dato appropriati ai vari campi delle tabelle del DB. I valori memorizzati nel DB vengono interpretati in funzione dei tipi usati nell’ontologia e la loro utilità è evidente in tutti i casi in cui i tipi di dato delle sorgenti non corrispondono

direttamente con i tipi di dati dell’ontologia.

• uno per i data-to-object mappings: asserzioni usate per mappare i dati nel DB alle istanze di concetti, ruoli

M ^{APPING TRA} DB ^E O ^NTOLOGIA

Perché il collegamento effettuato tramite i mappings abbia la giusta rilevanza, è importante sottolineare che facciamo l’assunzione che il DB sia indipendente dall’ontologia: in altre parole il nostro scopo è collegare l’ontologia ad una collezione di dati già esistente e che non è stata pensata per popolare i concetti dell’ontologia stessa.

Si sono dunque rese necessarie delle assunzioni che permettessero di collegare correttamente i campi del DB nei concetti dell’ontologia, anche lì dove non sussistevano corrispondenze immediate.

25

M ^{APPING TRA} DB ^E O ^NTOLOGIA

Tali assunzioni, derivate dalla cosiddetta “conoscenza dell’esperto del dominio”, sono:

• Nella tabella TEAM_DI_PROGETTO_TABLE abbiamo assunto che il campo PARTECIPANTE_ID sia il codice di un professore o di un ricercatore

• Nella tabella MISSIONE_TABLE abbiamo assunto che il campo UNITA_ORGANIZZATIVA sia un dipartimento accademico

• Nella tabella PROGETTO_TABLE abbiamo assunto che il campo PROVENIENZA_FONDI contenga il nome di un progetto

M ^{APPING TRA} DB ^E O ^NTOLOGIA

Le regole usate per la scrittura dei mappings sono le seguenti:

Istanza di concetto

Class(funct(VAR)) : nel caso che il mapping interessi un concetto dell’ontologia è sufficiente utilizzare un funtore (funct) cui si passa il campo del DB (VAR) che è necessario per costruire univocamente l’istanza.

27

M ^{APPING TRA} DB ^E O ^NTOLOGIA

Attributo

attr(funct(VAR),VAR_ATTR): nel caso in cui bisogna mappare un

attributo di concetto si usa una relazione binaria attr tra l’istanza della classe di

interesse, identificata tramite il funtore, e il campo del DB, VAR_ATTR che indica

l’attributo da mappare.

Associazione

ASSOC(funct(VAR), funct2(VAR2)): nel caso in cui si debba mappare un’associazione tra due classi le cui istanze sono identificate,

rispettivamente, dai funtori funct e funct2, si utilizza una relazione

M ^{APPING TRA} DB ^E O ^NTOLOGIA - E ^SEMPIO

29

Esempio di Typing Mapping

MAPPING PER LA TABELLA PROFESSORE_TABLE

CREATE TABLE IF NOT EXISTS PROFESSORE_TABLE (

PROFESSORE_ID VARCHAR(32), NOT NULL,

CODICE_FISCALE VARCHAR(32),

NOME VARCHAR(64),

COGNOME VARCHAR(64),

DIPARTIMENTO VARCHAR(256),

PRIMARY KEY (PROFESSORE_ID) )

M_t1 : SELECT PROFESSORE_ID FROM PROFESSORE_TABLE xsd:string M_t2 : SELECT CODICE_FISCALE FROM PROFESSORE _TABLE xsd:string M_t3 : SELECT NOME FROM PROFESSORE _TABLE xsd:string

M_t4 : SELECT COGNOME FROM PROFESSORE _TABLE xsd:string

M_t5 : SELECT DIPARTIMENTO FROM PROFESSORE _TABLE xsd:string

M ^{APPING TRA} DB ^E O ^NTOLOGIA - E ^SEMPIO

Esempio di Data-to-object Mapping

M_m9: SELECT * FROM

PROFESSORE_TABLE WHERE

CODICE_FISCALE IS NOT NULL

Person(cf(CODICE_FISCALE)),

PersonName(persName(NOME, COGNOME)), firstName(persName(NOME, COGNOME), NOME), surname(persName(NOME, COGNOME), COGNOME),

PERSON-NAME(cf(CODICE_FISCALE), persName(NOME, COGNOME)), AcademicDepartment(academicDepartment(DIPARTIMENTO)),

nameValue(academicDepartment (DIPARTIMENTO), DIPARTIMENTO)

I ^L P ^LUGIN OBDA ^PER P ^ROTÉGÉ

Ci siamo serviti dell’editor di ontologie Protégé con un plugin aggiuntivo, OBDA plugin

(Ontology Based Data Access), che permette all’utente di:

‒ descrivere le sorgenti di dati

‒ descrivere i mappings che connettono le sorgenti di dati e le entità dell’ontologia

‒ inviare le descrizioni di questi componenti ad un reasoner OBDA

‒ interrogare tale reasoner e vedere il risultato

31

I ^L R ^EASONER OBDA: DIG-MASTRO

Mastro è il solo reasoner che, oltre ad eseguire i tradizionali task di reasoning, è costruito

appositamente per operazioni

OBDA ed incorpora facilitazioni per specificare sorgenti di dati e

mappings.

DIG-MASTRO permette a Mastro di interagire con qualsiasi client

conforme all’estensione OBDA per l’interfaccia DIG, un’interfaccia http/XML standardizzata per i reasoner delle logiche descrittive.

D ^EMO

• Illustrazione ontologia su Protégé

• Illustrazione del pannello in cui sono stati inseriti i mappings

• Illustrazione della sincronizzazione tra plugin e DIG- MASTRO e visualizzazione della TBox generata

• Illustrazione di queries SPARQL di esempio, tramite

l’apposito pannello: discussione della loro espansione e dei risultati ottenuti

33