Seminari di ingegneria del software Interrogare ontologie costruite

Seminari di ingegneria del software Interrogare ontologie costruite a partire da schemi E/R attraverso gli strumenti Qu. Onto/Mastro Toolkit e Protegè (OBDA plugin)

Obiettivi • Traduzione dei diagrammi ER in DL-Lite. A; • Realizzare le query in sintassi Spar. SQL; • Passare da DL-Lite ad owl in Protegé; • Query in sintassi SPARQL.

Svolgimento del progetto/1 • Traduzione degli schemi ER (le entità, le relazioni e i vincoli presenti) in concetti, ruoli e vincoli delle ontologie, ottenendo dapprima la sintassi tedesca e infine la sintassi funzionale per DL-Lite; • Utilizzando il linguaggio Spar. SQL ho fatto le query richieste ed ho espresso gli eventuali vincoli presenti non esprimibili. • Utilizzato il tool grafico Qu. Onto/Mastrol Tool. Kit ho scritto l’ontologia in sintassi funzionale completa di asserzioni e ho potuto valutare le query Spar. SQL.

Svolgimento del progetto/2 • ho ottenuto le ontologie in sintassi funzionale compatibili per owl e con l’utilizzo di un convertitore per sintassi owl ho ottenuto dei file RDF/XML da porre come input all’editor Protegè. • Con l’utilizzo del tool grafico Qu. Onto/Mastrol Tool. Kit opportunamente abbinato con l’utilizzo di My. SQL ho salvato tutte le asserzioni in un DB ed ho effettuato tutti i mapping utilizzando il plugin OBDA di Protegè • Sempre con l’utilizzo del plugin OBDA e tramite l’utilizzo del reasoner DIG- Server ho fatto le query richieste, lì dove possibile, utilizzando il linguaggio Sparql.

Ontologie vs ER Ontologia → concettualizzazione di un dominio d’interesse espressa in logica, rappresenta il modello concettuale di un mondo, la struttura formale di un pezzo di realtà percepita ed organizzata da chi modella e tenta di formulare uno schema concettuale esaustivo e rigoroso nell’ambito di un certo dominio. E/R → descrive in maniera semanticamente precisa una realtà di interesse Obiettivo: ottenere gli strumenti per una traduzione diretta di ogni costrutto E/R in costrutti per ontologie

Ontologia Un’ontologia è una concettualizzazione del dominio d’interesse espressa in logica. Il dominio di interesse è composto di oggetti ed è strutturato in: • Concetti, i quali corrispondono alle classi e denotano un insieme di oggetti; • Ruoli, i quali corrispondono a relazioni binarie e denotano relazioni binarie tra gli oggetti. Un’ontologia popolata di istanze e completata con delle regole di inferenza viene detta Base di Conoscenza. Per esprimere un’ontologia, si fa uso di formalismi logici basati su classi ed in particolare di logiche descrittive.

Description Logic – DL Logiche progettate in modo specifico per rappresentare e ragionare su basi di conoscenza Una ontologia in logica descrittiva o base di conoscenza è una coppia O =<T, A>, dove T è una TBox, mentre A è una ABox. La Terminological Box (TBox) rappresenta il livello intensionale della conoscenza ed è il modello concettuale, espresso in maniera formale, di un frammento di realtà. L’Assertion Box (ABox) rappresenta il livello estensionale della conoscenza ed è il modello concreto, espresso in maniera formale, di un frammento di realtà in quanto contiene conoscenze sottoforma di asserzioni

Owl (Web Ontology Language) Standard proposto dal W 3 C per la definizione di ontologie per il web semantico, progettato per poter processare le informazioni disponibili sul web. OWL prevede tre livelli di complessità crescente: • OWL Lite, semplice da usare e implementare ma scarsamente espressivo. • OWL DL, abbastanza espressivo, decidibile e dotato di procedure di ragionamento di complessità ormai ben ottimizzate; • OWL Full, molto espressivo ma non decidibile e quindi problematico dal punto di vista della meccanizzazione del ragionamento.

La logica descrittiva DL-Lite A Stesso potere espressivo di OWL DL con la differenza che tramite DL-Lite si può esprimere il costrutto di modellazione degli attributi di ruolo che non possono essere espressi in OWL DL. Sintassi riconosciute per DL-Lite • La sintassi tedesca, prevede la descrizione della TBOX attraverso l’utilizzo di costrutti logici/matematici; • La sintassi funzionale, la quale utilizza costrutti testuali che richiamano all’utilità di ciò che si vuole esprimere

Query Answering/1 Query answering su un’ontologia→ interrogare prima il livello intensionale (TBox), poi il livello estensionale (ABox) →risposte: Certain Answers, cioè le risposte vere in ogni modello dell’ontologia. Problema: nelle ontologie c’è informazione incompleta Soluzione: Open World Assumption, OWA: tutto ciò che è contenuto nell’ontologia è vero, mentre tutto ciò che non vi è contenuto non è né vero né falso, ma semplicemente non si conosce. Basi di Dati → Closed World Assumption, CWA

Esempio Query: q(x): - (Person(x) ∧ ¬ Student(x)) Risposta in caso di CWA: {Paolo, Luisa} Risposta in caso di OWA: {}

OWA: conseguenze Query answering con FOL su basi di conoscenza DL indecidibile Soluzione → considerare un sottoinsieme della FOL che abbia il massimo potere espressivo possibile e che sia decidibile → unioni di query congiuntive (UCQs) e le query congiuntive (CQ) Problema: limiti espressivi. Soluzione: Epistemic Queries Languages (EQLs) Principio base EQLs: su ciò che conosci tu hai un informazione completa sulla quale è possibile applicare l’assunzione di mondo chiuso. EQLs sono decidibili ed hanno potere espressivo analogo alla FOL

Spar. SQL Esempio di linguaggio epistemico: EQL-LITE(UCQ). Caratteristica EQL-LITE(UCQ): atomi sono unioni di query congiuntive Implementazione EQL-LITE(UCQ) → Spar. SQL: linguaggio di interrogazione concreto ontologie in DL-Lite Spar. SQL = SQL + SPARQL sulle

Meccanismo di traduzione da E/R a DL-Lite. A functional-style syntax Class(Iscrizione). Sub. Class. Of(Gruppo Iscrizione) Sub. Class. Of(Individuo Iscrizione) Disjoint. Classes(Gruppo Individuo) Gruppo ⊑ Iscrizione Individuo ⊑ Iscrizione Gruppo ⊑ ¬Individuo Object. Property. Domain(esegue Persona) Object. Property. Range(esegue Iscrizione) ∃ Esegue ⊑ Persona ∃ Esegue ˉ ⊑ Iscrizione Data. Property. Range(codice. Iscrizione rdf: string) Data. Property. Domain(codice. Iscrizione) δ(codice. Iscrizione) ⊑ Iscrizione ρ(codice. Iscrizione) ⊑ xsd: String Object. Property. Data. Range(data. Esegue. Anno rdf: string) Object. Property. Data. Domain(data. Esegue. Anno esegue) δ(Data. Esegue) ⊑ Esegue ρ(Data. Esegue) ⊑ xsd: date

Meccanismo di traduzione cardinalità/1 Persona 1. . n risiede Comune ∃ Persona ⊑ risiede Sub. Class. Of(Persona Object. Min. Cardinality(1 risiede)) 1. . n Persona risiede Comune ∃ Comune ⊑ risiede. Sub. Class. Of(Object. Min. Cardinality(1 Inverse. Object. Property. Of(risiede))Comune)

Meccanismo di traduzione cardinalità/2 Persona 0. . 1 risiede Comune funct(risiede) Functional. Object. Property(risiede) 0. . 1 Persona risiede Comune funct(risiede-) Functional. Object. Property(Inverse. Object. Property. Of(Rapresents))

Limiti nella traduzione/1 Definizione dell’attributo di ruolo Object. Property. Data. Range(da rdf: string) Object. Property. Data. Domain(da risiede) Sub. Object. Property. Of(risiede Object. Property. Data. Some. Value. From(da xsd: any. Type)) Functional. Object. Property. Data(da) ho dovuto togliere il seguente vincolo: Functional. Object. Property(risiede) Sub. Class. Of(Persona Object. Min. Cardinality(1 risiede))

Limiti nella traduzione/2 • Completezza delle generalizzazioni • Espressione dei vincoli di cardinalità, nei casi di cardinalità min/max diversa da 0/1. Quest’ultimo vincolo è esprimibile attraverso una query condizionale, ovvero si fanno restituire tutti gli individui che partecipano alla relazione di cui si vuole testare la molteplicità raggruppati per il campo chiave, poi conta le occorrenza di ognuno e seleziona quelli che non soddisfano la giusta molteplicità. VERIFY not exists( SELECT g. x Gruppo FROM sparqltable( SELECT ? x ? w WHERE{ ? x rdf: type 'Persona'. ? x : formato ? w rdf: type 'Persona'. })g GROUP BY (g. x) HAVING COUNT(*) < 2 ) 2. . n formato Persona

Limiti nella traduzione/3 L’obiettivo è verificare che tutti le iscrizioni individuali e di gruppo formino l'insieme delle iscrizioni e viceversa. Si può verificare che la differenza insiemistica tra Iscrizione/(Gruppo U Individuo) sia vuota. La query spar. SQL booleana relativa a tale vincolo è la seguente VERIFY not exists( ) SELECT iscr. x FROM sparqltable( SELECT ? x WHERE { ? x rdf: type 'Iscrizione'. } )iscr WHERE iscr. x not in (SELECT grp. x FROM sparqltable( SELECT ? x WHERE{ ? x rdf: type 'Gruppo'. } )grp UNION SELECT ind. x FROM sparqltable( SELECT ? x WHERE{ ? x rdf: type 'Individuo'. } )ind ))

Caso di studio: queries Query n° 1 del compito di base di dati del 16/12/2004 B: Calcolare il codice fiscale ed il sesso delle persone che hanno effettuato almeno una iscrizione nel 2003. SELECT p. c, p. s FROM sparqltable( SELECT ? s ? c ? d WHERE { ? x rdf: type 'Persona'. ? x : cod. Fis ? c. ? x : sesso ? s. (? x : esegue ? Iscrizione) : data. Esegue. Anno ? d. } )p WHERE p. d = '2003'

Dalla sintassi funzionale ad un file. owl Problema: I file creati fin’ora non sono “buoni” per essere posti in input a Protegè. Soluzione: Si utilizza un convertitore di sintassi owl Problema: la sintassi funzionale deve essere modificata con piccoli accorgimenti quali l’inserimento di tag o la definizione dei tipi, es. intero va scritto con xsd: int, si deve cancellare tutto ciò che riguarda gli attributi di ruolo perché in owl non sono esprimibili.

. . in Protegè Il file owl ottenuto dal convertitore sarà l’input di Protegè; Necessario mapping, cioè si devono estrarre i dati dal DB per popolare l’ontologia. Es. di mapping: Persona(funct($term)) SELECT term FROM Persona

Protegè • Warning su i tipi di dati; • Problema di accesso ai dati salvati; • Ragionatore DIG-Server “senza viste”; • Minor potere espressivo; • Possibilità di verificare le query EQL;