Metodologie per la gestione di
conoscenza ontologica
Prof. M.T. PAZIENZA
a.a. 2008-2009
Sommario
• Introduzione
• Linguaggi per la gestione delle ontologie
• Valutazioni (delle ontologie, dei tool basati
su ontologie e degli ontology editors)
• Ontology Driven Software Engineering
Introduzione
Il processo di sviluppo di sistemi software è un’attività
importante e complessa che richiede la partecipazione e
la collaborazione di team fisicamente distribuiti durante
tutta la fase dello sviluppo del sistema.
Grandi capacità umane, tempo e sforzi sono necessari nel
creare, disegnare, scrivere, testare e mantenere sistemi
software.
La eterogeneità delle competenze dei team partecipanti e la
complessità dei prodotti sviluppati richiede che lo
sviluppo software sia un processo (di grandi dimensioni)
intensivo e basato su conoscenza.
Introduzione
I sistemi software sono sempre più alimentati da
quanto è pubblicato sul Web.
Tali sistemi devono gestire/interagire con dati di
sorgenti eterogenee che possono essere
sconosciute in fase di sviluppo del software; è per
questo che si cercano nuove tecnologie per il
supporto al SE (software engineering) in questi
contesti.
Introduzione
Noto adagio:
« tutte le esigenze software del mondo sono già
state soddisfatte e scritte in software esistente da
qualche parte »
Se fosse reso agevole l’accesso a tali funzionalità da
servizi web, le modalità di realizzazione del
software sarebbe completamente stravolte e, forse,
semplificate!
Ciò spiega l’interesse in metadati, ontologie formali
e linguagi per il SW.
Alcune keyword (attive da circa 20 anni)
Knowledge-based Software Engineering - include:
ragionamento automatico e software design,
rappresentazione della conoscenza, information retrieval,
visualization, …
Goal-Driven Requirements Engineering - la ricerca in
quest’area ha considerato la modellazione basata su UML
(Unified Modeling Language) di un dominio come parte
delle architetture software
Faceted Software Classification – ha come obiettivo
facilitare il riuso di componenti software associando ad
esse alcune keyword che poi sono organizzate in facets
Introduzione
A fronte delle attività connesse a tali temi si è diffusa, anche
nella pratica, una comune attitudine a modellare i domini in
maniera formale o semiformale. La MDA (Model Driven
Architecture) è un esempio di tale approccio anche se ancora
non viene supportato automaticamente il controllo di
consistenza e la validazione.
Aumentare la formalizzazione aiuta a limitare l’ambiguità ed a
migliorare la qualità dei sistemi complessi. Con un supporto
formale i tool diventano più astratti, e come conseguenza, i
metodi sono più « difficili » da implementare e la libertà di
espressione di un ingengere ne risulta limitata.
MDA
MDA incoraggia un approccio model driven alla SE
attraverso:
• la specificazione del sistema in maniera indipendente
dalla piattaforma su cui alla fine sarà sviluppato
• la specifica delle piattaforme per sè che individua gli
artefatti software specifici per quelle piattaforme
• il supporto alla trasformazione delle specifiche di un
sistema in specifiche per lo sviluppo in particolari
piattaforme.
SW e SE
Le tecnologie del SW (Semantic Web) possono migliorare (da
MDA ad ODA) il SE supportando la rappresentazione non
ambigua della terminologia di dominio, e permettendo il
controllo automatico della consistenza e validazione delle regole
(pre-condizioni e post-condizioni) , oltre a supportare la
mediazione e trasformazione della terminologia basata su
conoscenza.
In tal modo si ottiene un aumento della scalabilità e compatibilità
delle componenti.
Problema:
Difficoltà nella costruzione e manutenzione di ontologie di
metadati.
SW e SE
Come caratterizzare il SW in termini di SE uso?
• come « classificatore » per raggruppare tools e
tecniche correlate per modellare rigorosamente la
semantica durante le fasi di specificazione e disegno
del ciclo di vita del software
• come « meccanismo » per descrivere rigorosamente,
identificare, scoprire e condividere artefatti all’interno
di sistemi, sottosistemi e team di disegno sia in fase di
disegno che a runtime.
SW e SE
Come caratterizzare il SW in termini di SE uso?
Il SW può essere visto come un set di corpora formali di contenuti
interrelati, riusabili e che possono essere uulteriormente
classificati come:
• « passivi » -dati in forma di:
1. Documenti piatti e dati – HTML, XML, …
2. Documenti, dati generati dinamicamente –via JSP, PHP, …
3. Metadati – RDF. OWL,…
4. Media, pictures, music,…
5. Databases
• « attivi » funzionalità presentate come:
1. Web services, semantic web services,..
2. Componenti funzionali referenziati come frammenti con
contenuti passivi (JavaSCRIPT, Java applets, …)
Sia gli attivi che i passivi possono essere descritti usando tecniche
ontologiche
SW e SE
Come caratterizzare il SW in termini di SE uso?
Se è vero che sia gli attivi che i passivi possono
essere descritti usando tecniche ontologiche, è
pur vero che la loro distinzione è
importantissima nel SE.
Il ruolo del SW è catalizzante, ovvero se non è
detto che esso sia l’elemento più potente in un
qualsiasi sistema, è pur vero che senza il SW
la potenza di qualunque altro elemento non
può esprimersi al massimo!
Ontologie e modelli formali di
specifica
Le ontologie possono essere considerate come un
modello descrittivo rigoroso di per sè. Il loro
obiettivo di supportare la condivisione di
conoscenza tra agenti, umani e sistemi automatici
si realizza attraverso la rappresentazione esplicita
della semantica usando formalismi logici.
Questi formalismi si rivelano particolarmente utili
per il supporto alle interrogazioni ed al reasoning a
runtime e migliorare la qualità ed il costo
all’intero processo di sviluppo.
Ontologie e modelli formali di specifica (2)
Qualità:
1. Controllo della conformità ai requisiti e verifica della consistenza
2. Supporto alla categorizzaizone ed alla identificazione
3. Specificazione formale
4. Capacità di catturare, relazionare e gestire informazioni e modelli
di sistemi a livello multiplo e da più punti di vista
5. Aumento della espressività semantica attraverso la copertura di
concetti non presenti nei tool attualmente
6. Riduzione dell’ambiguità di disegno
7. Sintassi unica per la scrittura dei tool (OWL può essere
considerato come standard nella scrittura)
8. Facilitare il disaccoppiamento tra diversi livelli di astrazione per
una modellazione effettiva.
Ontologie e modelli formali di specifica (3)
Costo:
1. Riduzione nei costi di manutenzione attraverso un
sostanziale aumento nella consistenza
2. Aumentata potenzialità di riuso, sostituzione ed
estensione attraverso una attività di content discovery
sul Semantic Web
Questi vantaggi si possono raggiungere inserendo ontologie
descrittive direttamente nel disegno dei sistemi. In tal
modo sarebbe possibile supportare il cross-referencing
ed il checking tra le descrizioni del disegno e le
ontologie relative migliorando così oltre alla qualità ed
al costo anche la manutenibilità dei sistemi
Supporto al ciclo di vita del software
L’uso di ontologie, e metadati può supportare il ciclo di vita del
software fornendo una standardizzazione della terminologia,
delle relazioni e delle regole valide in uno specifico dominio. La
standardizzazione:
1.
2.
Supporta la generazione di modelli di dominio
Riduce i problemi di inconsistenza tra differenti artefatti
generati durante lo sviluppo
3. Facilità la tracciabilità degli artefatti
4. Aumenta l’interoperabilità
5. Supporta il riuso di componenti esistenti
6. Fornisce interfacce semantiche alla descrizione architetturale
Corpora di contenuti riusabili
Poichè le tecnologie del SW usano una
rappresentazione delle informazioni basata su
triple, da sempre si considera il SW come un
framework relazionale specializzato.
Da un punto di vista relazionale si possono
considerare un paio di interpretazioni:
• Collezione di intra-webs semantici
• Un unico semantic web
Corpora di contenuti riusabili
• Collezione di intra-webs semantic
Ontologie formali distinte anche se collegate a
differenti comunità di interesse, ovvero gruppi di
ricercatori con la responsabilità del controllo e
della gestione di tali webs. Questi gruppi per
definizione sono molto consapevoli della necessità
della consistenza e della qualità dei dati, ma
possono non desiderare che le loro informazioni
siano parte di una struttura più grande.
Corpora di contenuti riusabili
• Un unico Semantic Intra-Web
Una collezione globale di tanti Semantic Webs pubblici e
nient’altro in un unico spazio web a cui ci si possa riferire.
Allo stato attuale è ragionevole porsi nella prima ipotesi,
anche se nella seconda sarebbe più agevole un qualunque
approccio di estrazione di conoscenza, processi di
esplorazione, mining, …che, però sarebbe molto più
difficile da realizzare da un punto di vista di SE.
Esempio di SW in SE (1)
Developing and managing software components in an
ontology-based application server (1)
Le funzionalità di un application server sono sviluppate e
mantenute grazie a tool di amministrazione e file di
configurazione corrispondenti; però in tale approccio il
modello concettuale sottostante le diverse configurazioni
è totalmente implicito; per cui è difficile ritrovare parti
specifiche così come è difficle validarle e mantenerle.
Una architettura ontology-driven (ODA) può supportare lo
sviluppo e l’amministrazione delle componenti di un
application server.
Esempio di SW in SE (1)
Developing and managing software components in an
ontology-based application server (2)
In un ambiente ODA, un’ontologia cattura proprietà,
relazioni, e comportamenti di componenti, tutte info
necessarie ai processi di sviluppo ed a scopi di
amministrazione dei sistemi.
Poichè una ontologia descrive formalmente il modello su
basi logiche, esso può essere interrogato, pre-controllato
per la consistenza sia durante lo sviluppo che runtime.
System architecture di un ontologybased application server
Esempio di SW in SE (2)
Semantic management of web services (1)
Web Services standard adottano una descrizione che è intercambiabile in modo
da permettere a sviluppatori differenti di usare proprie implementazioni per
la stessa descrizione di un servizo web. Come contropartita, però, si ha che
pur essendo i vari standard complementari tra loro , essi possono in parte
sovrapporsi portando alla eventualità di descrivere servizi web inconsistenti
e tale inconsistenza è difficilmente riconoscibile.
Ciò è legato al fatto che non esiste nessun modello formale coerente dei WS. Il
riconoscimento di tale problema e la sua risoluzione è tuttora un problema
risolto manualmente dagli sviluppatori con nessun supporto automatico! (es.
Web shop con pagamenti con carta)
Di qui la necessità di una gestione semantica dei servizi web
Esempio di SW in SE (2)
Semantic management of web services (2)
Sviluppatori ed amministratori di servizi web hanno
bisogno di predire o almeno di poter osservare
completamente come più servizi web si comportano,
interagiscono, o possono entrare in conflitto.
Sarebbe importante per loro poter interrogare un sistema
per la gestione semantica dei sw.
Le ontologie sono l’ovvia scelta per l’integrazione di
informazione concettuale grazie alla capacità di gestire
semantica formale altre a supportare il motore
inferenziale per il ragionamento automatico e
l’interrogazione di descrizioni semantiche.
Riferimenti
• W3C document: « Ontology Driven Architectures
and Potential Uses of the Semantic Web in Systems
and Software Engineering », 2006
http://www.w3.org/2001/sw/BestPractices/SE/ODA/