Metodologie per la gestione di conoscenza ontologica

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
• Documenti piatti e dati HTML, XML,
• Documenti, dati generati dinamicamente via JSP,
  PHP,
• Metadati RDF. OWL,
• Media, pictures, music,
• Databases
•  attivi funzionalità presentate come
• Web services, semantic web services,..
• 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à
• Controllo della conformità ai requisiti e
  verifica della consistenza
• Supporto alla categorizzaizone ed alla
  identificazione
• Specificazione formale
• Capacità di catturare, relazionare e gestire
  informazioni e modelli di sistemi a livello
  multiplo e da più punti di vista
• Aumento della espressività semantica attraverso
  la copertura di concetti non presenti nei tool
  attualmente
• Riduzione dellambiguità di disegno
• Sintassi unica per la scrittura dei tool (OWL può
  essere considerato come standard nella scrittura)
• Facilitare il disaccoppiamento tra diversi
  livelli di astrazione per una modellazione
  effettiva.

15
Ontologie e modelli formali di specifica (3)

• Costo
• Riduzione nei costi di manutenzione attraverso un
  sostanziale aumento nella consistenza
• 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
• Supporta la generazione di modelli di dominio
• Riduce i problemi di inconsistenza tra differenti
  artefatti generati durante lo sviluppo
• Facilità la tracciabilità degli artefatti
• Aumenta linteroperabilità
• Supporta il riuso di componenti esistenti
• 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/20
  01/sw/BestPractices/SE/ODA/