Metodologie per la gestione di conoscenza ontologica Prof. M.T. PAZIENZA a.a. 2008-2009.

Presentazione sul tema: "Metodologie per la gestione di conoscenza ontologica Prof. M.T. PAZIENZA a.a. 2008-2009."— Transcript della presentazione:

1 Metodologie per la gestione di conoscenza ontologica Prof. M.T. PAZIENZA a.a. 2008-2009

2 Sommario Introduzione Linguaggi per la gestione delle ontologie Valutazioni (delle ontologie, dei tool basati su ontologie e degli ontology editors) Ontology Driven Software Engineering

3 Introduzione Il processo di sviluppo di sistemi software è unattività 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.

4 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.

5 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 laccesso a tali funzionalità da servizi web, le modalità di realizzazione del software sarebbe completamente stravolte e, forse, semplificate! Ciò spiega linteresse in metadati, ontologie formali e linguagi per il SW.

6 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 questarea 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

7 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 lambiguità 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.

8 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.

9 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.

10 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 allinterno di sistemi, sottosistemi e team di disegno sia in fase di disegno che a runtime.

11 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

12 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 lelemento più potente in un qualsiasi sistema, è pur vero che senza il SW la potenza di qualunque altro elemento non può esprimersi al massimo!

13 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 allintero processo di sviluppo.

14 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 dellambiguità 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.

15 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

16 Supporto al ciclo di vita del software Luso 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.Supporta la generazione di modelli di dominio 2.Riduce i problemi di inconsistenza tra differenti artefatti generati durante lo sviluppo 3.Facilità la tracciabilità degli artefatti 4.Aumenta linteroperabilità 5.Supporta il riuso di componenti esistenti 6.Fornisce interfacce semantiche alla descrizione architetturale

17 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

18 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.

19 Corpora di contenuti riusabili Un unico Semantic Intra-Web Una collezione globale di tanti Semantic Webs pubblici e nientaltro 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.

20 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 lamministrazione delle componenti di un application server.

21 Esempio di SW in SE (1) Developing and managing software components in an ontology-based application server (2) In un ambiente ODA, unontologia 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.

22 System architecture di un ontology- based application server

23 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

24 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 lovvia scelta per lintegrazione di informazione concettuale grazie alla capacità di gestire semantica formale altre a supportare il motore inferenziale per il ragionamento automatico e linterrogazione di descrizioni semantiche.

25 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/ http://www.w3.org/2001/sw/BestPractices/SE/ODA/