Politecnico di Milano Scuola di ingegneria industriale e Corso ......Politecnico di Milano Scuola di...

Politecnico di MilanoScuola di ingegneria industriale e

dell’informazioneCorso di Laurea Specialistica in Ingegneria

Informatica

Ontology Design Pattern conun’applicazione a problemi di pianificazione

Relatore : Tesi di Laurea di :Prof. Marco Colombetti Massimiliano Bianchi, matricola n. 754988

Anno Accademico 2011/2012

Ai miei genitori.

Ringraziamenti

Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Marco Colombetti, rela-tore della mia tesi, per l’aiuto e il sostegno fornitomi durante la stesura del lavoro.

Ringrazio con affetto la mia famiglia per avermi sostenuto ed incoraggiato pertutto il mio percorso scolastico.

Ringrazio i colleghi universitari per aver condiviso con me questo questo percorsodi conoscenza e tutti gli amici e amiche per essermi stati vicino nei momenti dibisogno.

Indice

Elenco delle figure 9

1 Introduzione 11

2 Stato dell’arte 132.1 Ontology Design Patterns . . . . . . . . . . . . . . . . . . . . . . 132.2 Tipologie di ODPs . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3 Logical ODP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.4 Logical ODPs esistenti . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4.1 Disgiunzione del complemento . . . . . . . . . . . . . . . 172.4.2 OnlynessIsLoneliness . . . . . . . . . . . . . . . . . . . . . 182.4.3 Sinonimo o equivalenza . . . . . . . . . . . . . . . . . . . 192.4.4 Definizione di classi ibride per risolvere il problema di di-

sgiunzione dovuto a sussunzione . . . . . . . . . . . . . . 202.4.5 Definizione di classe allargata per risolvere il problema di

disgiunzione dovuto a sussunzione . . . . . . . . . . . . . 212.4.6 Pattern per la relazione di arità n . . . . . . . . . . . . . 222.4.7 Sommarizzazione di una relazione inversa di arità n . . . . 232.4.8 Relazione simmetrica di arità n . . . . . . . . . . . . . . . 242.4.9 Normalizzazione . . . . . . . . . . . . . . . . . . . . . . . . 252.4.10 Partizione . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4.11 Asserzioni per la negazione delle proprietà . . . . . . . . . 272.4.12 Adrian Walker 2 . . . . . . . . . . . . . . . . . . . . . . . 282.4.13 Context Slices . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Pianificazione di blocchi con Context Slices 313.1 Dominio di interesse . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.1.1 Dominio considerato . . . . . . . . . . . . . . . . . . . . . 323.2 Modello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

3.2.1 Caso base di studio . . . . . . . . . . . . . . . . . . . . . . 323.3 Modello con Context Slices . . . . . . . . . . . . . . . . . . . . . 33

3.3.1 Classi del modello . . . . . . . . . . . . . . . . . . . . . . . 343.3.2 Relazioni del modello . . . . . . . . . . . . . . . . . . . . . 34

INDICE 7

3.3.3 Rappresentazioni grafiche . . . . . . . . . . . . . . . . . . 353.3.4 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 363.3.5 Numero individui e asserzioni . . . . . . . . . . . . . . . . 363.3.6 Rappresentazione con più stati e oggetti . . . . . . . . . . 36

4 Modelli alternativi 374.1 Modello con reificazione delle relazioni . . . . . . . . . . . . . . . 37

4.1.1 Classi del modello . . . . . . . . . . . . . . . . . . . . . . . 384.1.2 Relazioni del modello . . . . . . . . . . . . . . . . . . . . . 384.1.3 Rappresentazioni grafiche . . . . . . . . . . . . . . . . . . 394.1.4 Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . . 394.1.5 Numero individui e asserzioni . . . . . . . . . . . . . . . . 404.1.6 Rappresentazione con più stati e oggetti . . . . . . . . . . 404.1.7 Confronto con modello con Context Slices . . . . . . . . . 41

4.2 Modelli ad intervalli . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.1 Scelte di analisi . . . . . . . . . . . . . . . . . . . . . . . . 424.2.2 Modello ad intervalli base . . . . . . . . . . . . . . . . . . 434.2.3 Modello ad intervalli esteso . . . . . . . . . . . . . . . . . 474.2.4 Modello a stati analogo al modello ad intervalli esteso . . 51

5 Conclusioni e sviluppi futuri 53

A 57A.1 SWRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A.2 Protégé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57A.3 GrOWL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58A.4 Sintassi OWL Manchester . . . . . . . . . . . . . . . . . . . . . . 58

B 59B.1 Modello a stati Context Slices . . . . . . . . . . . . . . . . . . . . 59B.2 Modello a stati con reificazione delle relazioni . . . . . . . . . . . 61B.3 Modello ad intervalli base . . . . . . . . . . . . . . . . . . . . . . 64B.4 Modello ad intervalli base . . . . . . . . . . . . . . . . . . . . . . 67B.5 Modello a stati esteso . . . . . . . . . . . . . . . . . . . . . . . . . 71

Elenco delle figure

2.1 Problema e soluzione in GrOWL del pattern Disgiunzione del com-plemento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.2 Soluzione 1 in GrOWL del pattern OnlynessIsLoneliness . . . . . 182.3 Soluzione 2 in GrOWL del pattern OnlynessIsLoneliness . . . . . 192.4 Soluzione 3 in GrOWL del pattern OnlynessIsLoneliness . . . . . 192.5 Soluzione 4 in GrOWL del pattern OnlynessIsLoneliness . . . . . 202.6 Soluzione in GrOWL del pattern Sinonimo o equivalenza . . . . . 202.7 Problema in GrOWL del pattern “Definizione di classi ibride per

risolvere il problema di disgiunzione dovuto a sussunzione” . . . . 212.8 Soluzione in GrOWL del pattern “Definizione di classi ibride per

risolvere il problema di disgiunzione dovuto a sussunzione” . . . . 212.9 Esempio pianta carnivora con le classi ibride . . . . . . . . . . . . 212.10 Soluzione GrOWL del pattern “Definizione di classe allargata per

risolvere il problema di disgiunzione dovuto a sussunzione” . . . . 222.11 Esempio pianta carnivora con la classe allargata . . . . . . . . . . 222.12 Problema GrOWL del Pattern per la relazione di arità n . . . . . 232.13 Soluzione GrOWL del Pattern per la relazione di arità n . . . . . 232.14 Grafico UML della soluzione della Sommarizzazione di una rela-

zione inversa di arità n . . . . . . . . . . . . . . . . . . . . . . . . 242.15 Soluzione GrOWL della Sommarizzazione di una relazione inversa

di arità n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 242.16 Grafico UML della soluzione del pattern Relazione simmetrica di

arità n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.17 Soluzione GrOWL del pattern Relazione simmetrica di arità n . . 252.18 Prima della normalizzazione . . . . . . . . . . . . . . . . . . . . . 262.19 Dopo la normalizzazione . . . . . . . . . . . . . . . . . . . . . . . 262.20 Soluzione GrOWL del pattern Partizione . . . . . . . . . . . . . . 272.21 Soluzione UML del pattern Partizione . . . . . . . . . . . . . . . 272.22 Soluzione GrOWL del pattern Asserzioni per la negazione delle

proprietà . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.23 Soluzione UML del pattern Asserzioni per la negazione delle pro-

prietà . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282.24 Context Slices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

ELENCO DELLE FIGURE 9

2.25 Esempio Context Slices . . . . . . . . . . . . . . . . . . . . . . . . 30

3.1 Stati del modello Context Slices . . . . . . . . . . . . . . . . . . . 333.2 Rappresentazione del modello Context Slices in GrOWL . . . . . 353.3 Rappresentazione OntoGraf del modello Context Slices . . . . . . 35

4.1 Rappresentazione del modello con reificazione dei fatti in GrOWL 394.2 Rappresentazione OntoGraf del modello con reificazione dei fatti . 404.3 Tabella del confronto tra modello Context Slices e con reificazione

dei fatti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.4 Stati del modello ad intervalli . . . . . . . . . . . . . . . . . . . . 444.5 Intervalli del modello . . . . . . . . . . . . . . . . . . . . . . . . 444.6 Rappresentazione del modello ad intervalli in GrOWL . . . . . . . 464.7 Rappresentazione OntoGraf del modello ad intervalli . . . . . . . 464.8 Intervalli del modello con più intervalli . . . . . . . . . . . . . . . 484.9 Tabella degli intervalli di clear . . . . . . . . . . . . . . . . . . . 484.10 Rappresentazione del modello con più intervalli in GrOWL . . . . 504.11 Rappresentazione OntoGraf del modello con più intervalli . . . . . 504.12 Intervalli in stati . . . . . . . . . . . . . . . . . . . . . . . . . . . 524.13 Rappresentazione OntoGraf del modello con gli stati . . . . . . . 52

10 ELENCO DELLE FIGURE

Capitolo 1

Introduzione

Le ontologie sono nate nell’ambito dell’Intelligenza Artificiale con lo scopo di faci-litare la condivisione e il riutilizzo della conoscenza su larga scala (World Wide),sia da parte di utenti umani che da sistemi applicativi. Dall’inizio degli anni no-vanta questo tema è diventato il cardine della ricerca in campi come l’ingegneriadella conoscenza, l’integrazione informatica, i sistemi di Cooperative Informatione Information Retrieval, il commercio elettronico e il Knowledge Management.

Con il termine ontologia, in ambito informatico, ci si riferisce ad un tentativodi formulare uno schema concettuale esaustivo e rigoroso nell’ambito di un da-to dominio; si tratta generalmente di una struttura dati gerarchica che contienetutte le entità rilevanti, le relazioni esistenti fra di esse, le regole, gli assiomi ed ivincoli specifici del dominio.

Uno degli aspetti più importanti delle ontologie riguarda la loro creazione cheè conseguenza di un processo complesso e dipendente dal dominio considerato.Negli ultimi anni, assumendo l’esistenza di classi di problemi che possono essererisolte applicando delle soluzioni comuni, si è pensato alla creazione di piccoleontologie da utilizzare come blocchi di costruzione nell’Ontology Design giungen-do alla creazione di design patterns per creare ontologie denominate OntologyDesign Patterns (ODPs).

In questo contesto è stato creato il portale web ‘OntologyDesignPatterns.org’[2] interamente dedicato agli ODPs per il Web Semantico. Il sito web, sviluppatonel contesto del progetto Neon [17], di cui il maggior esponente è il professorAldo Gangemi dell’Istituto ISTC-CNR di Roma, presenta un catalogo ufficiale diODPs contenente diversi ODP creati per poter essere riutilizzati nella creazionedi ontologie. Gli ODPs sono di diversi tipologie.

Il lavoro di questa tesi consta di due parti collegate. Inizialmente prevede un’a-nalisi del portale web nella ricerca di un Pattern da utilizzare nel dominio della

12 Introduzione

pianificazione di blocchi, campo di notevole rilevanza nell’intelligenza artificialee successivamente prevede ulteriori analisi nella ricerca del miglior pattern peril dominio della pianificazione di blocchi prendendo in considerazione l’analisi didiversi modelli con differenti modalità di rappresentazione.

Nel Capitolo 2 si approfondisce lo stato dell’Arte analizzando il portale degliODPs ed in particolare ci si sofferma sulla particolare tipologia di Logical Desi-gn Patterns. Vengono analizzati tutti i diversi Logical ODPs presenti nel sito emostrati seguendo un’unica modalità di rappresentazione.

Nel capitolo 3 si presenta il dominio di applicazione della pianificazione di bloc-chi e si considera la creazione di un modello basandosi sul particolare LogicalODP denominato Context Slices ( presente nel catalogo analizzato nel capitoloprecedente) che fornisce una rappresentazione degli oggetti del modello conte-stualizzati in una certa situazione. Per quanto riguarda il mondo dei blocchi siè pensato ad una contestualizzazione dei blocchi nei vari istanti di tempo e vie-ne presentato un semplice modello composto da tre blocchi e due stati. Vengonocomunque presentate considerazioni sulla possibilità di avere più blocchi e/o stati.

Nel capitolo 4, nella speranza di trovare degli ontology designs patterns prefe-ribili in termini di minor numero di asserzioni e semplicità di lettura/scritturadell’ontologia stessa, si presentano dei modelli alternativi per la rappresentazionedei blocchi nel dominio prendendo in considerazione l’idea di reificare le azionipiuttosto che contestualizzare gli oggetti. Si analizza, inoltre, il mondo dei blocchisecondo una differente configurazione temporale ad intervalli. Vengono dunquefatte delle considerazioni sui vari modelli per trovare la migliore soluzione per ildominio.

Il capitolo 5, infine, riguarda le conclusioni e alcuni spunti per futuri sviluppialla luce dei risultati ottenuti.

Nell’appendice A ci sono le descrizioni degli strumenti utilizzati nella realizza-zione dei modelli, mentre nell’appendice B ci sono le implementazioni degli stessimodelli.

Capitolo 2

Stato dell’arte

In questo capitolo si passano in rassegna gli aspetti più importanti che hannoconsentito di approfondire la conoscenza di base e dare la possibilità di effettuarela ricerca. Si fornisce una descrizione approfondita degli Ontology Design Pat-terns, se ne analizzano le diverse tipologie ed in particolare ci si focalizza sullaparticolare tipologia di ODPs logici.

2.1 Ontology Design PatternsIn informatica le ontologie sono comunemente applicate nel campo dell’intelligen-za artificiale e nella rappresentazione e condivisione della conoscenza. Servonoper descrivere il modo in cui diversi schemi vengono combinati in una strutturadati contenente tutte le entità rilevanti e le loro relazioni in un dominio. Sebbe-ne l’approccio originale dell’ontology engineering fosse quello di creare ontologiecome componenti portatili in grado di condividere e riutilizzare una conoscenzacomune tra più sistemi AI [16], uno degli aspetti più trascurati delle ontologiecomputazionali è la riusabilità. Molte ontologie esistenti o risultano complesseda comprendere o sono troppo grandi per poter essere riutilizzate per creare altreontologie. Alcune forniscono indicazioni su come riutilizzare le esistenti risorse diconoscenza come input per una fase di concettualizzazione ma, nonostante ciò,non chiarificano le implicazioni nel riutilizzo delle stesse nell’intero processo [14].Ad esempio [12] descrive nel dettaglio come costruire un’ontologia dal nuovo madà poche indicazioni su come riutilizzarla in altre ontologie.

Negli anni 2000, il successo di piccole ontologie come SKOS [10] e FOAF [11]ha mostrato l’efficienza delle piccole ontologie portatili e riutilizzabili. Da qui,assumendo che esistono classi di problemi che possono essere risolte applicandosoluzioni comuni, sono stati creati gli ODP.

Gli ODP sono piccole ( o abilmente modularizzate ) ontologie contenenti esplici-

14 Stato dell’arte

ta documentazione di design logici e le migliori pratiche di reingegnerizzazione.Questi componenti sono artefatti che codificano una descrizione di qualche mon-do ( possibile, impossibile, attuale, ecc.) per qualsivoglia scopo. Hanno unastruttura logico-linguistica e devono corrispondere sia ad un dominio che ad uncodominio; permettono la descrizione di entità i cui attributi e le relazioni sonodi interesse in un certo dominio a causa della loro importanza nel dominio stes-so per un qualche motivo (per esempio query, ricerca,integrazione, matching ecc.).

Come ogni altro artefatto hanno un ciclo di vita: sono progettati, implemen-tati, valutati, corretti, riutilizzati, ecc.. Necessitano di specifiche funzionalità peressere implementati in repositories, per essere catalogati e di forum di valutazionee strumenti per crearli.

In linea di principio gli ODP non dipendono da nessun linguaggio specifico di rap-presentazione. Si prende dunque OWL come linguaggio di riferimento in quantoè il linguaggio utilizzato come standard dalla compagnia del W3C per la descri-zione di ontologie. In OWL è possibile controllare la consistenza, classificare ecreare molte queries ma non tutto è permesso e, ad esempio, quando si cerca diriutilizzare parti di un grande insieme di conoscenza a volte sorgono dei problemidi consistenza. Attraverso l’utilizzo di piccole ontologie come gli ODP si cercanodi risolvere questi problemi.

2.2 Tipologie di ODPsIn [9] sono stati individuate sei famiglie di ontology Design Patterns: Structural,Correspondence, Content, Reasoning, Presentation e Lexico-Syntactic.

• Gli ODP strutturali includono gli ODP logici e architetturali.

– I Logical Ontology Design patterns(L ODPs) sono costrutti logici ocomposizioni degli stessi. Sono strutture indipendenti dal contenutoe sono espressi solo attraverso un vocabolario logico. Possono essereapplicati più di una volta nella stessa ontologia per risolvere proble-mi di modellizzazione simili. Si possono informalmente dividere in 2tipi: macro logiche che provvedono short cut per modellare espres-sioni logiche ricorrenti ( ad esempio la combinazione della restrizioneowl:allValuesFrom con la retrizione owl:someValuesFrom) e patternsdi trasformazione che traducono espressioni logiche di un linguaggioin un altro ( ad esempio il pattern della relazione di arità n, presentatoin seguito, è un pattern di trasformazione da un costrutto della logicadel primo ordine in OWL DL).

– Gli ODP architetturali riguardano l’intera forma dell’ontologia; il lo-ro scopo è porre i vincoli per rappresentare come l’ontologia dovrebbe

2.3 Logical ODP 15

apparire. Si possono dividere in interni ( devono essere utilizzati esclu-sivamente quando si costruisce un’ontologia) e in esterni ( in terminidi costrutti meta livelli).

• Gli ODPs di reasoning sono applicazioni di ODP Logici che servono perottenere risultati di reasoning, basati sul comportamento implementato nelreasoning engine. Quando dichiarati all’inizio di un’ontologia permettonoal sistema di decidere quale servizio di reasoning utilizzare nell’ontologiastessa per risolvere queries, valutazioni ecc. Esempi di ODP di Reasoningsono : classificazione, sussunzione, materializzazione ecc..

• I Correspondence ODP includono gli ODP di reingegnerizzazione e di map-patura. Gli ODP Reengineering danno ai designers le soluzioni al problemadella trasformazione di un modello concettuale, che può anche non essereuna risorsa ontologica, in una nuova ontologia. Sono regole di trasforma-zione applicate per creare una nuova ontologia partendo da elementi di unmodello sorgente. Si distinguono in 2 tipi: patterns di reingegnerizzazionedegli schemi ( ad esempio la trasformazione di un meta modello DL non-OWL in un’ontologia OWL DL) e patterns di fattorizzazione che danno aidesigners le regole per trasformare ad esempio un’esistente ontologia OWLDl in una nuova ontologia OWL DL. I Mapping Ontology Design Patternsdefiniscono le possibili relazioni semantiche tra elementi mappabili come adesempio in [17].

• I Presentation ODPs trattano l’usabilità e la leggibilità delle ontologie dalpunto di vista dell’utente. Esempi di Presentation ODP sono Naming ODPe Annotation ODP che forniscono ad esempio indicazioni su come crearenomi per i namespaces, files e elementi delle ontologie in generale.

• I Lexico-Syntactic ODP sono strutture linguistiche o schemi costituiti daalcune parole che seguono un ordine specifico e che permettono di genera-lizzare ed estrarre alcune conclusioni dal significato che esprimono.

• I Content Ontology Design Patterns sono istanze di Logical ODP o lorocomposizioni. Sono dipendenti dal dominio e risolvono problemi di mo-dellizzazione del dominio. Influenzano la parte specifica dell’ontologia chetratta il relativo problema di modellizzazione. Alcuni esempi sono Salesorder, research topic, timeinterval,etc..

2.3 Logical ODPCome brevemente accennato nel paragrafo precedente, i Logical Ontology Desi-gn Patterns sono delle composizioni di costrutti logici che servono per risolvereproblemi di espressività. Vengono espressi solo in termini di vocabolario logico


poiché il loro insieme di predicati è vuoto. Da una parte sono indipendenti dauno specifico dominio di interesse, dall’altra dipendono dall’espressività del for-malismo logico che è usato per la rappresentazione. Aiutano a risolvere problemidi design dove le primitive della rappresentazione del linguaggio non supportanodirettamente certi costrutti logici. Ad esempio se il linguaggio per la rappresen-tazione è OWL e il designer necessita di rappresentare una relazione tra più di 2elementi, è necessario un Logical ODP per esprimere una relazione n-ary usandosolo le classi e le primitive della relazione binaria.

I Logical ODPs vengono divisi in due categorie: Logical macros e Transformationpatterns.

• Le macro logiche ( Logical macros) provvedono una “shortcut” per mo-dellare un’espressione logica intuitiva ricorrente. Ad esempio la macro (∇R.C significa “ogni R deve essere una C” ed è formalmente rappre-sentata da “∃R.T1 � ∀R.C ” che nel linguaggio OWL è espressa co-me la combinazione della restrizione owl:allValuesFrom con una restrizioneowl:someValuesFrom.

• I patterns di trasformazione ( Transformation patterns ) traducono un’e-spressione logica da un linguaggio logico ad un altro. La semantica delprimo è approssimata per trovare un trade-off tra requisiti ed espressioni.Un esempio è la relazione di arità n che non può essere espressa diretta-mente in OWL. Un’approssimazione in OWL di questa relazione avvieneattraverso la creazione di una nuova classe che rappresenti la relazione stessae indichi gli argomenti attraverso delle proprietà.

L’applicazione dei Logical ODPs ha conseguenze sui risultati e sull’efficienza delleprocedure di ragionamento. I Logical ODPs possono essere usati per documen-tare scelte di design e per ideare metodi per creare ontologie poiché provvedonoai designers delle soluzioni per rappresentare espressioni complesse.

Il sito web [2] presenta un catalogo ufficiale di tutti gli ODP pubblicati e cer-tificati. Qualsiasi utente, dopo una registrazione gratuita al sito può presentareil proprio Content ODP. Per presentare un proprio Content ODP l’utente deverispettare dei vincoli : ogni Content ODP deve essere associato ad un’implemen-tazione OWL, almeno un esempio di istanziazione OWL , un diagramma UML, ladescrizione di tutti i componenti dell’ontologia, il dominio, almeno una domandadi competenza e uno scenario, un modello sorgente del modello da cui il patternè stato estratto/reingegnerizzato. Una volta presentato il Pattern viene valutato,con dei criteri presentati in [3] da dei membri del Comitato di Qualità i quali,dopo aver verificato la qualità del pattern proposto, lo inseriscono nel catalogo.Nonostante queste indicazioni si è notato che gli ODP Logici presenti sul sito web[2] non presentano sempre tutto ciò che viene richiesto e non sempre nella stessa

2.4 Logical ODPs esistenti 17

forma di rappresentazione. Si è dunque proseguito in un’analisi degli ODP Logiciuniformandoli sotto un’unica modalità di visualizzazione grafica.

2.4 Logical ODPs esistenti

Sul sito web [2] sono stati inseriti 13 diversi Proposed Logical ODP. I prossimiparagrafi corrispondono allo studio di ciascuno di questi ODP. Per ogni ontolo-gia è presente una descrizione verbale seguita da una rappresentazione graficadel problema e della soluzione dello stesso utilizzando la sintassi grafica GrO-WL[glossario], un linguaggio di rappresentazione grafica delle ontologie OWL.Ove possibile è presente una rappresentazione del problema e della soluzione uti-lizzando la logica SROIQ(DL) ( logica che sta alla base del linguaggio OWL 2 DL[8] e raccomandazione W3C ufficiale dal 27 ottobre 2009 ) o il linguaggio RDF.

2.4.1 Disgiunzione del complemento

Si tratta dell’antipattern ( problema che si incontra frequentemente nello sviluppodei programmi) della disgiunzione del complemento. Quando si vuole afferma-re che 2 classi C1 e C2 non possono condividere istanze, invece di definire C1come logica negazione di C2, si deve affermare che C1 e C2 sono disgiunti. InSROIQ(DL) il problema si presenta come: C1 ≡ ¬C2 .

La soluzione è C1 disjointWith C2 con DisCla(C1,C2) con C1 uC2 v ⊥ .In fig. 2.1 c’è la rappresentazione GrOWL del problema e della soluzione.

Figura 2.1: Problema e soluzione in GrOWL del pattern Disgiunzione delcomplemento


2.4.2 OnlynessIsLonelinessSi tratta dell’antipattern che si crea quando inizialmente si afferma che un’istanzadi classe C1 può essere collegata con la relazione R solo all’istanza di classe C2(restrizione universale), poi che un’istanza di classe C1 può essere collegata conla relazione R solo all’istanza di classe C3 (un’altra restrizione universale) e infinesi conclude che C2 e C3 sono disgiunti.In RDF il problema si presenta come :C1 subClassOf R only C2; C1 subClassOf R only C3; C2 disjointWith C3. Perovviare a questo problema sono state proposte diverse soluzioni:

1. Si trasformano le restrizioni universali in una sola che si riferisce alla di-sgiunzione di C2 e C3.

In RDF diventa : C1 subClassOf R only (C2 or C3); C2 disjointWithC3.La fig. 2.2 rappresenta tramite sintassi GrOWL la soluzione.

Figura 2.2: Soluzione 1 in GrOWL del pattern OnlynessIsLoneliness

2. Si sopprime la disgiunzione degli assiomi

3. Si creano due sottoclassi di C1.La soluzione in RDF è :C1.1 subclassOf C1 ; C1.1 subclassOf R only C2 ; C1.2 subclassOf C1; C1.2subclassOf R only C3 ; C2 disjointWith C3.

La fig. 2.3 rappresenta tramite sintassi GrOWL la soluzione.

4. Si crea una nuova classe C4.La soluzione in RDF è :



C4 isEqualTo C2 or C3; C1 subclassOf R Only C4; C2 disjointWith C3.

La fig. 2.4 rappresenta tramite sintassi GrOWL la soluzione.


5. Si creano due sottoproprietà di R.La soluzione in RDF è :R2 subpropertyOf R; R3 subpropertyOf R; C1 subclassOf R2 Only C2; C1subclassOf R3 Only C3; C2 disjointWith C3.La fig. 2.5 rappresenta tramite sintassi GrOWL la soluzione.

2.4.3 Sinonimo o equivalenzaSi tratta dell’ antipattern che si crea quando si esprime l’equivalenza tra 2 classiidentiche. La soluzione prevede l’aggiunta di tutti i commenti e le etichette allaclasse meno usata nell’ontologia. Graficamente la soluzione ha lo stesso grafico delproblema in quanto in GrOWL non vengono evidenziati i commenti e le etichettealle classi.



In SROIQ(DL) il problema si presenta come: ( C1 ≡ C2 . La fig. 2.6 rappresentatramite sintassi GrOWL la soluzione.

Figura 2.6: Soluzione in GrOWL del pattern Sinonimo o equivalenza

2.4.4 Definizione di classi ibride per risolvere il problemadi disgiunzione dovuto a sussunzione

Questo pattern serve per risolvere il problema dell’inconsistenza della disgiun-zione che si crea quando si definisce una classe come sottoclasse di due classidisgiunte.La soluzione proposta è la definizione di una classe ibrida basata sulla definizionedi classi disgiunte implicate nella inconsistenza. La hybrid class è l’unione delledefinizioni delle classi disgiunte.

La fig. 2.7 rappresenta tramite sintassi GrOWL la rappresentazione del proble-ma, la fig. 2.8 presenta la soluzione e la fig. 2.9 presenta la soluzione attraversoun esempio riguardante la classe delle piante carnivore che essendo piante ap-partengono alla classe delle piante ed essendo carnivore appartengono alla classedegli animali sebbene l’appartenere al mondo degli animali implichi il non essereparte del mondo delle piante e viceversa.

Di questo pattern si osserva che :

• viene definita una classe ibrida come unione della definizione delle classidisgiunte implicate nell’inconsistenza da risolvere.

• viene definita una sussunzione tra la più specifica superclasse comune delleclassi disgiunte implicate nell’inconsistenza e la classe ibrida creata.


Figura 2.7: Problema in GrOWL del pattern “Definizione di classi ibride perrisolvere il problema di disgiunzione dovuto a sussunzione”

Figura 2.8: Soluzione in GrOWL del pattern “Definizione di classi ibride perrisolvere il problema di disgiunzione dovuto a sussunzione”

Figura 2.9: Esempio pianta carnivora con le classi ibride

• viene definita una sussunzione tra la classe ibrida e la sottoclasse coinvoltanell’inconsistenza.

2.4.5 Definizione di classe allargata per risolvere il pro-blema di disgiunzione dovuto a sussunzione

Come il pattern 2.4.4 serve per risolvere il problema della sussunzione da due clas-si disgiunte. La soluzione prevista da questo pattern implica la creazione di unanuova classe (enlarged class) come unione delle definizioni delle classi disgiuntecoinvolte nell’inconsistenza.Per la rappresentazione del problema tramite sintassi GrOWL si fa ancora riferi-mento alla fig. 2.7.


La soluzione è riportata in fig. 2.10 mentre l’esempio sulle piante carnivore ( giàtrattato per il pattern precedente ) è riportato graficamente nella figura 2.11.

Figura 2.10: Soluzione GrOWL del pattern “Definizione di classe allargata perrisolvere il problema di disgiunzione dovuto a sussunzione”

Figura 2.11: Esempio pianta carnivora con la classe allargata

2.4.6 Pattern per la relazione di arità nQuesto pattern serve per permettere l’inferenza di relazioni di proprietà tra dif-ferenti relazioni dell’originale relazione n-ary basata sulla sua reificazione.

Soluzione: la relazione n-ary è reificata creando una classe per la relazione(NR) ecreando proprietà e classi per il dominio (D) e i codomini (R1-Rn) della relazione.


La classe NR è specificata usando una restrizione di riflessività locale della forma: NR equi vis_NR some Self. Si specifica il ruolo delle catene per ogni relazionebinaria tra dominio e codominio.In questo caso viene riportata soluzione del problema riportata sul sito [8] ( fig2.12 ) mentre la soluzione ( fig 2.13 ) è creata attraverso la sintassi GrOWL.

Figura 2.12: Problema GrOWL del Pattern per la relazione di arità n

Figura 2.13: Soluzione GrOWL del Pattern per la relazione di arità n

2.4.7 Sommarizzazione di una relazione inversa di arità nHa come obiettivo quello di richiedere relazioni n-ary e le loro relazioni diversetra 2 partecipanti distinti senza utilizzare queries complesse. Come soluzionesi crea una classe NAryRelationClass che supporta la relazione di arità n e lesue relazioni ed attributi. La relazione mainRelationship e la relazione inversasono state create per cortocircuitare la relazione tra i diversi partecipanti nellarelazione di arità n.In questo caso non viene rappresentata una visualizzazione grafica del problema.Per la soluzione, oltre al grafico GrOWL di fig. 2.15, si riporta la soluzione


grafica di fig. 2.14 riportata sul sito [8] che tramite un diagramma UML mostrachiaramente la soluzione.

Figura 2.14: Grafico UML della soluzione della Sommarizzazione di una relazioneinversa di arità n

Figura 2.15: Soluzione GrOWL della Sommarizzazione di una relazione inversadi arità n

2.4.8 Relazione simmetrica di arità nQuesto pattern serve per rappresentare relazioni simmetriche n-ary come ad esem-pio la distanza tra due punti. Per questo scopo come soluzione si crea una classeNAryRelationship con il valore degli argomenti necessari ed una relazione traquesta classe e l’entità. Come nel pattern precedente, anche in questo si rappre-senta solo la soluzione grafica del problema in quanto non è possibile farne unarappresentazione del problema.Oltre al grafico GrOWL di fig. 2.17, si riporta la soluzione grafica ( fig, 2.16


riportata sul sito [8] che tramite un diagramma UML mostra chiaramente lasoluzione.

Figura 2.16: Grafico UML della soluzione del pattern Relazione simmetrica diarità n

Figura 2.17: Soluzione GrOWL del pattern Relazione simmetrica di arità n

2.4.9 NormalizzazioneSi occupa della riformulazione in modo più leggibile di uno schema con molte ge-rarchie codificando le relazioni di sussunzione e utilizzando restrizioni piuttostoche relazioni di classe-sottoclasse. Questo pattern non è ovviamente rappresen-tabile in GrOWL in quanto risulta specifico per un determinato dominio e vienequindi rappresentato un esempio tratto da [8] in cui si nota il suo utilizzo.In fig. 2.18 si presenta l’esempio prima della normalizzazione mentre in fig. 2.19lo si ripropone in seguito all’applicazione del pattern.

Di questo pattern si osserva che :

• Per applicare la normalizzazione occorre identificare i moduli e raggrupparele classi mantenendo un solo parent per ogni classe primitiva dei dati.

• L’ontologia viene districata e diventa una collezione di moduli ordinati. Ilresto della semantica è dato da restrizioni che puntano a moduli e il reasonermantiene la struttura.

2.4.10 PartizioneQuesto pattern descrive come modellare una partizione dividendo un concettoin più classi disgiunte. La soluzione prevede l’introduzione di assiomi del tipo :(define-concept P (or C0 C1 ... Cn) ) (disjoint Ci Cj) ( ( 0 ≤ i, j ≤ n, i¬j ) doveP rappresenta la il concetto partizione e Ci, Cj sono i concetti della partizione.Oltre al grafico GrOWL di fig. 2.20, si riporta la soluzione grafica ( fig, 2.21


Figura 2.18: Prima della normalizzazione

Figura 2.19: Dopo la normalizzazione

riportata sul sito [8] che tramite un diagramma UML mostra chiaramente lasoluzione.


Figura 2.20: Soluzione GrOWL del pattern Partizione

Figura 2.21: Soluzione UML del pattern Partizione

2.4.11 Asserzioni per la negazione delle proprietà

Questo pattern ha come obiettivo quello di rappresentare le asserzioni per la ne-gazione delle proprietà nelle ontologie prima di OWL 2 ( poiché in OWL 2 questoè già esprimibile).La soluzione, usando la sintassi astratta di OWL 2 è : NegativeObjectProper-tyAssertion(prop i1 i2) equivalente a :

SubClassOf(ObjectOneOf(i1), ObjectComplementOf(ObjectSomeValuesFrom(prop,ObjectOneOf(i2))))La fig. 2.22, rappresenta il grafico GrOWL della soluzione mentre la fig 2.23riporta il diagramma UML della soluzione riposrtata su [8] .


Figura 2.22: Soluzione GrOWL del pattern Asserzioni per la negazione delleproprietà

Figura 2.23: Soluzione UML del pattern Asserzioni per la negazione delleproprietà

2.4.12 Adrian Walker 2Questo pattern è completamente differente da tutti i precedenti in quanto nonanalizza una particolare struttura logica di qualche ontologia. Si tratta di unastruttura scritta in codice java che serve per permettere interrogazioni complessenella lingua inglese. Questo viene attuato utilizzando delle strutture di frasi giàcompilate composte da parole segnaposto al posto delle quali è possibile inserirele parole desiderate nel raggiungimento delle queries volute. In questo caso nonè possibile fare una rappresentazione grafica.

2.4.13 Context SlicesQuesto pattern ha come scopo quello di rappresentare l’informazione contestua-lizzata. In RDF e in altri linguaggi relazionali, per rappresentare una relazionebinaria che esiste in qualche concetto, si reifica la relation-holding nel contesto


come un nodo con una relazione binaria con un soggetto,un oggetto, una pro-prietà e una quarta relazione binaria che rappresenta il contesto stesso, perdendocosì, però, l’abilità espressiva del linguaggio. Il Context Slices pattern permetteuna soluzione che lascia una certa espressività al linguaggio.

Anzichè reificare le frasi stesse, questo pattern, permette la creazione della pro-iezione degli argomenti correlati in ogni contesto per i quali esista una relazionebinaria che li colleghi. In questo modo risulta più naturale rappresentare unarelazione binaria per rappresentare delle relazioni. Inoltre in questo modo sipossono esprimere cardinalità e si può affermare se una relazione è transitiva osimmetrica cosa che con un reificazione con RDF non è possibile. La figura 2.24mostra la soluzione proposta.

In fig. 2.25 si considera invece l’esempio Chris believes Sam is the CEO of IBM .

Figura 2.24: Context Slices


Figura 2.25: Esempio Context Slices

Capitolo 3

Pianificazione di blocchi conContext Slices

Tra tutti i patterns analizzati nel capitolo precedente il pattern denominato ‘Con-text Slices’ trova applicazione nel dominio della pianificazione ( campo dell’in-telligenza artificiale che si occupa di trovare sequenze di azioni per raggiungereun obiettivo). In particolare, in quanto obiettivo di questa tesi, si analizza l’u-tilizzo del pattern nel mondo dei blocchi, uno dei domini di pianificazione piùfamosi [13], situazione in cui è necessario trovare una soluzione per rappresenta-re la posizione di più blocchi in diversi istanti di tempo e quindi in diversi contesti.

Viene ora presentato il dominio della pianificazione di blocchi e, attraverso la de-scrizione di un modello realizzato appositamente per questo scopo, si presentanoi risultati ottenuti dall’inserimento del pattern nel dominio.

3.1 Dominio di interesse

Dominio di interesse di questo lavoro di tesi è la pianificazione di blocchi, unparticolare campo della pianificazione.

Il mondo dei blocchi si compone di un ambiente interamente osservabile, de-terministico, finito, statico ( i cambiamenti accadono quando agisce l’agente) ediscreto. Il dominio consiste in un insieme di blocchi che risiedono sopra un pianoe che possono essere spostati da un braccio meccanico. I blocchi possono essereimpilati ma, solo un blocco può stare sopra ad un altro. Un braccio robotico puòprelevare un blocco e muoverlo in un’altra posizione, o sul piano o in cima ad unaltro blocco. Si può spostare un solo blocco alla volta e non si può muovere unblocco che ne abbia un altro sopra di esso. L’obiettivo è quello di costruire unoo più insiemi di blocchi specificando quali blocchi sono sopra a quali altri. Per

32 Pianificazione di blocchi con Context Slices

esempio un obiettivo potrebbe essere quello di posizionare un blocco A su B e unblocco C su D.

3.1.1 Dominio consideratoPer effettuare uno studio sull’adattabilità del pattern Context Slices nel dominiodella pianificazione di blocchi, si è analizzato un caso semplificato della pianifi-cazione di blocchi. Non si considera la presenza del braccio robotico e i blocchipossono essere Clear (quando non hanno niente al di sopra di essi), Up (quandosi trovano sopra altri blocchi) o Down (quando si trovano al di sotto di un altroblocco).

3.2 ModelloLa trattazione avviene considerando inizialmente un caso di studio di base com-posto da un numero limitato di blocchi e cambiamenti che in seguito viene estesoa più blocchi e spostamenti.

3.2.1 Caso base di studioIl caso base di studio analizzato prevede la presenza di 3 blocchi e la loro osser-vazione nel tempo. Il modello realizzato analizza il comportamento in 2 stati ditempo. E’ stata effettuata questa scelta di 3 blocchi e 2 istanti di tempo perchési ritiene questa configurazione la base più giusta e semplice per un’osservazionecompleta del fenomeno oltre che un ottimo punto di partenza per l’analisi di casicon più blocchi e/o più stati.Una rappresentazione con un solo blocco non avrebbe alcun senso pratico e lapresenza di due soli blocchi limiterebbe notevolmente le analisi possibili in quantoriguarderebbero solo 3 semplici casistiche:

• blocco 1 sopra blocco 2


• entrambi i blocchi liberi

a differenza dei 6 casi analizzabili con 3 blocchi :





3.3 Modello con Context Slices 33



Per quanto riguarda il numero degli stati si ritiene indispensabile fare un’anali-si su almeno 2 stati in modo da poter osservare almeno un cambiamento dellacomposizione. In seguito verranno comunque fatte altre riflessioni sul numero distati e blocchi.

Seguendo le indicazioni proposte nel Logical ODP Context Slices il contesto tem-porale in cui considerare lo stato dei blocchi deve essere rappresentato da unoggetto capace di indicare il tempo. Si è pensato quindi ad una rappresentazionead istanti di tempo.

Con gli istanti di tempo è possibile osservare l’andamento preciso dei vari blocchiin un preciso istante di tempo che si vuole considerare. Nella figura 3.1 si nota larappresentazione considerata del modello. Si osserva la situazione dei 3 blocchichiamati A, B e C in due istanti di tempo chiamati s1 e s2. Lo stato s1 ( cherappresenta la situazione iniziale ) mostra il blocco A sopra il blocco B e il bloccoC sul piano, mentre nello stato s2, successivo a s1, si osserva il blocco A sopra ilblocco C e il blocco B sul piano.

Figura 3.1: Stati del modello Context Slices

Il modello viene presentato attraverso una dettagliata descrizione delle classi e re-lazioni, una rappresentazione grafica tramite il linguaggio GrOWL ( paragrafo A.3nell’appendice 1 ), una rappresentazione grafica effettuata dal tool di visualizza-zione OntoGraf dell’editor Protégé ( paragrafo A.2 nell’appendice 1), la presenzadi alcune queries applicabili al modello. Si pone inoltre particolare attenzioneal numero di individui e asserzioni utilizzate che saranno utili per i confronticon i successivi modelli ( presentati nel capitolo 4). L’implementazione in OWLfunctional syntax del modello ( e dei successivi ) è riportatata nell’appendice 2.

3.3 Modello con Context SlicesI 3 blocchi vengono identificati come individui delle classi dei blocchi A, B e Ctutti derivanti dalla classe Object rappresentante gli oggetti in generale. L’azio-


ne clear dei blocchi è rappresentata come individuo del fatto Clear attraverso larelazione isClear che lega un individuo di un blocco ad un individuo di clear. Leposizioni di sopra o sotto dei blocchi sono rappresentate dalle relazioni oggetto-oggetto isUp, che lega il blocco che sta sopra al blocco che sta sotto, e dallarelazione isDown, che lega il blocco che sta sotto a quello che sta sopra. Gliistanti di tempo sono individui della classe State ( nell’esempio i 2 istanti di tem-po sono s1 e s2 ); si collegano con i blocchi attraverso la relazione holdsIn chelega i blocchi presenti in un determinato istante solamente ed unicamente con lostato con cui è relazionato.

Poichè i blocchi sono contestualizzati negli istanti temporali serve solamente unindividuo per il fatto Clear (clear). I diversi individui, rappresentanti i blocchiin relazione agli istanti di tempo a cui appartengono, si creano con la notazione“individuo_blocco@individuo_istante_temporale”.Per ogni stato temporale devono esistere dunque diversi individui.Per lo stato s1 ci sono gli individui a@s1, b@s1 e c@s1 che corrispondono ai 3blocchi nell’istante s1 mentre per lo stato s2 ci sono gli individui a@s2, b@s2 ec@s2 che corrispondono ai blocchi A, B e C nell’istante di tempo s2.

3.3.1 Classi del modello• Object : rappresenta i blocchi

• Clear : rappresenta l’azione Clear. Un blocco è clear quando non ha nessunaltro blocco sopra di sé.

• Fact : è la classe da cui deriva Clear

• State : rappresenta la classe degli stati

• Space : è la superclasse della classe State

• A : è la classe dei blocchi A

• B : è la classe dei blocchi B

• C : è la classe dei blocchi C

3.3.2 Relazioni del modello• holdsIn : Object → State. Lega il blocco allo stato

• isUp : Object → Object. Lega il blocco che sta sopra al blocco che stasotto

3.3 Modello con Context Slices 35

• isDown : Object → Object. Lega il blocco che sta sotto al blocco che stasopra

• isClear : Object→ Clear. Lega il blocco all’oggetto Clear del relativo stato

3.3.3 Rappresentazioni graficheLa fig. 3.2 è la rappresentazione GrOWL del modello descritto. La fig. 3.3 èinvece la rappresentazione OntoGraf dello stesso modello. Con una rappresenta-zione di questo tipo si possono osservare tutti gli individui del modello e le varierelazioni che intercorrono tra gli elementi.

Figura 3.2: Rappresentazione del modello Context Slices in GrOWL

Figura 3.3: Rappresentazione OntoGraf del modello Context Slices


3.3.4 QueriesUtilizzando la sintassi OWL Manchester ( paragrafo A.4 dell’appendice 1, sipresentano ora alcune queries con i relativi risultati per giustificare la validitàdel modello.

• holdsIn some State restituisce a@s1,a@s2,b@s1,b@s2,c@s1,c@s2

• holdsIn value s1 restituisce a@s1,b@s1,c@s1

• isClear some Clear restituisce a@s1,a@s2,b@s2,c@s1

3.3.5 Numero individui e asserzioniPer la realizzazione del modello sono stati inseriti 9 diversi individui di cui 6corrispondenti ai blocchi, 1 al fatto Clear e 2 agli stati.Le asserzioni inserite sono 12, tutte inerenti i blocchi.

3.3.6 Rappresentazione con più stati e oggettiVolendo rappresentare un modello composto da più istanti temporali e quindi dapiù stati si tempo e mantenendo costante il numero di 3 blocchi presente in ogniistante di tempo, si prevede un aumento di un fattore 4 per ogni stato temporaleaggiunto; per ogni nuovo stato sono infatti necessari 4 nuovi individui, 3 per iblocchi e uno per lo stato. Se ad esempio si aggiungesse uno stato s3 si avrebberogli individui a@s3, b@s3, c@s3 oltre che lo stato s3.Contemporaneamente servirebbero 3 nuove asserzioni per collegare a@s3, b@s3e c@s3 allo stato s3 e altre 3 asserzioni nel caso in cui i blocchi siano tutti e treliberi o 4 asserzioni nel caso due blocchi siano impilati ( così infatti servirebberouna relazione isUp per il blocco sopra, una relazione isDown per il blocco sottoe due relazioni isClear per i due blocchi necessariamente clear), per un totale di6/7 nuove asserzioni per ogni nuovo stato.

Per quanto riguarda una rappresentazione con più oggetti se, ad esempio, sivolesse considerare un modello composto da 4 blocchi, rispetto al modello pre-sentato, si dovrebbero aggiungere, per ogni istante di tempo, 2 nuovi individuilegati al nuovo blocco e 2 o 3 nuove asserzioni a seconda se il blocco verrà impilatoo meno.

Capitolo 4

Modelli alternativi

L’obiettivo di questa tesi è trovare la miglior soluzione ontologica per rappresen-tare modelli nel dominio della pianificazione di blocchi. Si è dunque pensato ditrovare metodi di rappresentazione alternativi a quello proposto nel capitolo 3.Inizialmente, considerando sempre il caso base mostrato nel paragrafo 3.2.1 delcapitolo precedente, si è pensato alla costruzione dello stesso modello attraversoun pattern differente consistente in una reificazione delle relazioni piuttosto checonsiderare i blocchi in relazione a dei contesti.Successivamente si è ragionato sulla possibilità di avere una rappresentazione al-ternativa del tempo analizzando il modello secondo intervalli di tempo piuttostoche istanti di tempo, osservando come una soluzione Context Slices risulti impos-sibile con una tale rappresentazione temporale in quanto implica l’opposto di ciòche il pattern si propone e cioè la contestualizzazione degli oggetti in un certomomento. Per i modelli ad intervalli si fa riferimento sia ad un modello con pochiintervalli ( per questo scopo si “trasforma” il caso base in un modello ad intervalli) che ad uno con diversi intervalli.

In questo capitolo vengono presentati sia il modello basato sulla reificazione dellerelazioni sia i 2 modelli ad intervalli. Inoltre viene presentato un quarto modelloa stati realizzato come confronto con il modello ad intervalli.

4.1 Modello con reificazione delle relazioniIn alternativa alla soluzione Context Slices si è realizzato un modello utilizzandola reificazione delle relazioni Clear e la relazione di posizione dei blocchi. Perrappresentare il fatto della posizione dei blocchi ( un blocco sopra l’altro ) siinserisce una nuova classe On ( sottoclasse della classe Fact ) già presente nelmodello precedente.In questa rappresentazione con reificazione delle relazioni, i blocchi non sono piùcontestualizzati in un istante di tempo ma esistono come unica entità nel tempo.

38 Modelli alternativi

A variare sono gli individui delle reificazioni delle classi Clear e On che dovrannoessere presenti distintamente per ogni differente istante di tempo.

Considerando sempre una soluzione con tre blocchi e due istanti di tempo, sa-ranno necessari 3 individui indicanti ciascuno un blocco (A,B,C) e due individuiper ciascun fatto (On e Clear) per ogni istante di tempo considerato. Per quantoriguarda l’istante s1 sono presenti gli individui cl001 e on001 mentre per l’istantes2 ci sono gli individui cl002 e on002 ( cl001 e cl002 sono individui della classeClear, on001 e on002 sono individui della classe On ).Gli individui dei fatti si legano al corrispondente istante di tempo ( sempre rap-presentato come individuo di una classe State, sottoclasse della classe Space)attraverso la relazione holdsIn. I blocchi a, b e c ( individui della classe Object)si legano agli individui di On ( corrispondenti allo stato di tempo cui sono legatidalla relazione holdsIn ) attraverso la relazione onUp quando si trovano sopra unaltro blocco e attraverso la relazione onDown quando si trovano sotto un altroblocco mentre si legano agli individui di Clear attraverso la relazione objClearquando sono in una situazione clear.

4.1.1 Classi del modello• Object : rappresenta i blocchi

• On : rappresenta la reificazione dell’azione On quando un oggetto si trovasopra o sotto un altro oggetto

• Clear : rappresenta la reificazione dell’azione Clear. Un blocco è clearquando non ha nessun altro blocco sopra di sé.




• ImpossibleState : serve per verificare che un oggetto Clear sia anche sottoun altro oggetto.

4.1.2 Relazioni del modello• holdsIn : Fact → State. Lega il fatto allo stato

• onUp : Object → On. Lega il blocco che sta sopra all’oggetto On delrelativo stato

• onDown : Object → On. Lega il blocco che sta sotto all’oggetto On delrelativo stato

4.1 Modello con reificazione delle relazioni 39

• objClear : Object → Clear. Lega il blocco all’oggetto Clear del relativostato

4.1.3 Rappresentazioni graficheLa fig. 4.1 è la rappresentazione GrOWL del modello descritto. La fig. 4.2 èinvece la rappresentazione OntoGraf dello stesso modello. Con una rappresenta-zione di questo tipo si possono osservare tutti gli individui del modello e le varierelazioni che intercorrono tra gli elementi.

Figura 4.1: Rappresentazione del modello con reificazione dei fatti in GrOWL

4.1.4 QueriesUtilizzando sempre la sintassi OWL Manchester e la funzionalità DL Query forni-ta dal software Protégé ( Glossario), si presentano ora alcune queries con i relativirisultati per valutare la bontà del modello.

• holdsIn some State restituisce on001, on002

• holdsIn value s1 restituisce on001, cl001

• onUp some (inverse(onDown) some Object) restituisce a

• objClear some (holdsIn value s2) restituisce a,b


Figura 4.2: Rappresentazione OntoGraf del modello con reificazione dei fatti

Per verificare che un oggetto Clear non si trovi al di sotto di un altro oggetto eviceversa, si utilizza la classe ImpossibleState e la regola SWRL ( A.1 nell’appen-dice 1) :holdsIn(?clear, ?s), holdsIn(?on, ?s), objClear(?o, ?clear), onDown(?o, ?on) ->ImpossibleState(?s)che, quando viene eseguita, restituisce lo stato in cui c’è la violazione se nel si-stema è presente un caso in cui un oggetto non rispetti la condizione di esseresolamente clear o solamente sotto un altro blocco e viceversa.

4.1.5 Numero individui e asserzioniCome si nota dalla rappresentazione OntoGraf sono presenti 9 individui diversi( 3 per i blocchi, 4 per gli individui di clear e on e 2 individui per gli stati), e leasserzioni sono 13.

4.1.6 Rappresentazione con più stati e oggettiPer quanto riguarda una rappresentazione con più stati, mantenendo costante ilnumero di 3 blocchi presente in ogni istante di tempo, è possibile prevedere unaumento di individui di un fattore 3 per ogni stato temporale aggiunto.Per ogni nuovo stato aggiunto sarebbero infatti necessari 3 nuovi individui , 1

4.1 Modello con reificazione delle relazioni 41

della classe Clear, 1 della classe On e un nuovo stato temporale . Se ad esempiosi considerasse un nuovo stato s3 ci si dovrebbero aggiungere gli individui cl003,on003 e lo stato s3.

Contemporaneamente servirebbero 2 nuove asserzioni per collegare cl003 e on003allo stato s3 e altre 3 asserzioni nel caso in cui i blocchi siano tutti e tre liberio 4 asserzioni nel caso due blocchi siano impilati ( così infatti servirebbero duerelazioni objClear per i due blocchi necessariamente clear, una relazione onUpper il blocco sopra e una relazione onDown per il blocco), per un totale di 5/6nuove asserzioni per ogni nuovo stato.

Per quanto riguarda una rappresentazione con più oggetti se, ad esempio, sivolesse aggiungere un quarto blocco D sarebbe necessario aggiungere, per ognistato, solamente un individuo rappresentante il quarto blocco e una o due nuo-ve asserzioni per permettere l’inserimento del blocco stesso nel modello ( 1 se ilblocco dovesse essere clear e 2 se dovesse trovarsi impilato con un altro blocco,situazione nella quale un blocco sarebbe down e l’altro up).

4.1.7 Confronto con modello con Context SlicesNella tabella di fig. 4.3 vengono riportati il numero di individui e di asserzioninecessari per i due casi appena descritti con 3 blocchi e 2 stati e il numero diindividui previsto per ogni stato aggiunto come riportato in precedenza.

Figura 4.3: Tabella del confronto tra modello Context Slices e con reificazionedei fatti

Osservando i dati in tabella è facile da notare come, in base al minor numerodi oggetti e asserzioni necessarie per la rappresentazione, per quanto riguardauna rappresentazione con soli 2 stati e 3 blocchi è preferibile una rappresentazio-ne Context Slices.Quando però si valutano soluzioni con più di due stati o più blocchi risulta pre-feribile il modello con la reificazione dei fatti.


L’aggiunta congiunta di più stati e blocchi è intuitivamente la combinazione del-l’aumento degli stati e dell’aumento dei blocchi, risulta qundi sempre più conve-niente una soluzione con reificazione dei fatti rispetto ad una soluzione ContextSlices.

4.2 Modelli ad intervalliIl modello ad intervalli prevede un’osservazione del modello in un certo intervallodi tempo il quale a sua volta si suddivide in sotto intervalli in base alla posizionedi un certo blocco in un certo istante. L’obiettivo di una rappresentazione diquesto tipo non è più quello di osservare il comportamento completo di tuttol’ambiente ma di osservare l’andamento nel tempo dei vari blocchi per quantoriguarda una singola azione. Per le altre azioni si cerca ugualmente un inseri-mento laddove le condizioni lo permettono. Per quanto riguarda la pianificazionedi blocchi il fatto che un blocco sia clear per un certo istante e per un altro nonlo sia, implicitamente sta a significare che questo si trova impilato sotto un altroblocco, il quale può essere riconoscibile nel caso in cui un solo altro blocco è clearnello stesso intervallo in cui questo non lo è.

Con gli intervalli di tempo si deve visualizzare separatamente il comportamentodi ciascun blocco in relazione ad una certa azione che si vuole considerare. Soloin seguito è possibile effettuare delle considerazioni su tutti i blocchi .A titolo dimostrativo nei modelli seguenti si è scelto di rappresentare l’andamen-to dei blocchi per l’azione di Clear ( si poteva scegliere anche l’azione di On).Nei grafici successivi si osserva che per ciascuna riga del grafico corrisponde undeterminato blocco. Quando la funzione è uguale a 0 significa che il blocco nonè clear, quando invece è alzata significa che il blocco è libero.Per una rappresentazione di questo tipo sembra risultare ovvio che i possibili van-taggi si possano ottenere utilizzando un certo numero di intervalli di tempo. Ciònonostante, per osservarne gli effetti, si è analizzato inizialmente il caso base con2 intervalli di tempo e in seguito un caso con un numero maggiore di intervallitemporali.

4.2.1 Scelte di analisiCome nel caso con istanti di tempo le possibili scelte rappresentative sono di 2tipi : utilizzare l’ODP Context Slices o la reificazione dei fatti.

Per quanto riguarda la possibilità di inserire il pattern Context Slices in unarappresentazione ad intervalli è però subito risultata evidente l’insensatezza nelcompiere tale scelta. Questo perché una rappresentazione ad intervalli ha co-me obiettivo quello di visualizzare il comportamento di un singolo oggetto in

4.2 Modelli ad intervalli 43

un periodo di tempo composto da diversi intervalli di tempo cosa che è l’esattocontrario di una rappresentazione Context Slices che prevede la presenza di piùistanze dello stesso oggetto . Le analisi si sono dunque incentrate sulla costruzionedi modelli che prevedono una reificazione dei fatti.

4.2.2 Modello ad intervalli basePer rappresentare la situazione base di 3 blocchi in 2 stati con gli intervalli è statonecessario fare delle modifiche ed aggiungere alcuni dati non presenti nel caso astati. Mentre i blocchi e gli stati vengono rappresentati, come nei casi preceden-ti, attraverso le classi Object e State e le azioni di clear e on sono rappresentateugualmente al caso con reificazione dei fatti precedente, occorre trovare una so-luzione per la rappresentazione degli intervalli.

Gli intervalli di tempo vengono identificati da un punto di inizio ed uno di fi-ne che per motivi di semplicità e leggibilità vengono considerati come numeriinteri. Sono individui della classe Interval sottoclasse della classe TemporalEnti-ty che rappresenta il tempo. Le relazioni di dati starts e ends legano un intervalload un intero che indica rispettivamente l’inizio e la fine dell’intervallo stesso.

Per quanto riguarda l’inserimento degli intervalli nel caso base si è pensato diconvertire i 2 stati s1 e s2 in 2 intervalli temporali di lunghezza arbitraria. Infigura si è scelto di trasformare lo stato s1 nell’intervallo IC di tempo che parteall’istante 0 e termina all’istante 15 mentre lo stato s2 nell’intervallo IB che parteall’istante 16 e termina all’istante 30. I valori sono stati scelti a caso con l’unicacondizione di non essere sovrapposti e di partire dall’istante 0 ( si considera iltempo convenzionalmente positivo).

La figura 4.5 rappresenta l’andamento dei blocchi secondo la proprietà di clear,seguendo le considerazioni del capitolo precedente. Un blocco risulta clear ne-gli intervalli temporali in cui la linea del grafico è sollevata mentre non è clearquando è a zero. Nella figura si osserva che il blocco A rimane clear per entrambigli intervalli di tempo mentre il blocco B è clear solo nell’intervallo IB ( corri-spondente allo stato s2 della figura4.4) e il blocco C è clear solo nell’intervalloIC ( corrispondente allo stato s1 della figura). Implicitamente, grazie al limitatonumero di elementi presenti nell’ambiente, si può comprendere come il blocco Bnell’intervallo IB si trovi sotto al blocco A mentre in IC il blocco C stia sottoil blocco A. Tra le classi utilizzate per la costruzione del modello è presente laclasse Instant rappresentante un istante di tempo che viene utilizzato congiun-tamente alla relazione at ( collega un istante con un intero ) per esaminare ilcomportamento dei blocchi in un certo istante attraverso una query presentatanel prossimo paragrafo. Poichè deve esistere un solo individuo Instant per istantetemporale, la classe Instant ha come sottoclasse “At exactly 1 Literal”.


Figura 4.4: Stati del modello ad intervalli

Figura 4.5: Intervalli del modello

Classi del modello

• Object : rappresenta i blocchi

• On : rappresenta la reificazione dell’azione On

• Clear : rappresenta la reificazione dell’azione Clear. Un blocco è clearquando non ha nessun altro blocco sopra di sé




• TemporalEntity: è la superclasse delle classi che rappresentano il tempo.

• Instant : rappresenta un istante di tempo. Sottoclasse di TemporalEntity.

• Interval: rappresenta gli intervalli di tempo. Sottoclasse di TemporalEntity.


Relazioni del modello

Questo modello necessita della presenza di due tipologie di relazioni, gli objectproperties che legano 2 individui delle classi e i data properties che legano unindividuo di una classe ad un valore definito.Object properties

• holdsIn : Fact → State. Lega il fattoo allo stato




Data properties

• at : Instant → int. Serve per la regola SWRL ( presentata in seguito)

• starts : Interval→ int. Indica l’inizio dell’intervallo

• ends : Interval→ int. Indica la fine dell’intervallo

• now : Instant→ int. Indica l’istante

• holdsAtInstant :Fact→ int. Serve per la regola SWRL (presentata inseguito)

Rappresentazioni grafiche

La fig. 4.6 è la rappresentazione GrOWL del modello descritto. La fig. 4.7 èinvece la rappresentazione OntoGraf dello stesso modello. Con una rappresenta-zione di questo tipo si possono osservare tutti gli individui del modello e le varierelazioni che intercorrono tra gli elementi.

Queries

Utilizzando sempre la sintassi OWL Manchester e la funzionalità DL Query forni-ta dal software Protégé ( Glossario), si presentano ora alcune queries con i relativirisultati per valutare la bontà del modello.

• starts value 0 restituisce IA, IC

• start some int [>=10] restituisce IB


Figura 4.6: Rappresentazione del modello ad intervalli in GrOWL

Figura 4.7: Rappresentazione OntoGraf del modello ad intervalli

Impostando un individuo now della classe Instant ad un certo valore intero si puòutilizzare la regola SWRL ( glossario ) holdsAtInstant che permette di verificarequale fatto è attivo nell’istante impostato.

holdsIn(?fact, ?int), At(now, ?z), ends(?int, ?y), starts(?int, ?x), greaterTha-nOrEqual(?z, ?x), lessThanOrEqual(?z, ?y) -> holdsAtInstant(?fact, ?z)

Eseguendo la query holdsAtInstant some int si ottengono gli individui di Cleare di On attivi in quell’istante. Attraverso l’utilizzo di questa query risulta evi-dente la contestualizzazione del blocco ad un certo istante. Questo è più comodoche dover contestualizzare l’azione. Nell’esempio la query, utilizzando l’intero 20restituisce clC, onA001 e clA indicanti il blocco A e C clear e che il blocco A si


trova sopra un altro blocco.

Numero individui e asserzioni

Il numero di individui necessari per la rappresentazione di un modello del genereè 11 ( 3 per i blocchi, 3 per le reificazioni di Clear, 2 per le reificazioni di On e 3per gli intervalli ) mentre il numero delle asserzioni è 18 ( 12 data assertions e 6property assertions per gli intervalli ).

Confronto con il modello a stati

Rispetto alla rappresentazione a stati con reificazione dei fatti si nota un aumentosia del numero degli individui ( da 9 a 11 ) che del numero delle asserzioni ( da 13a 18 ). Per un modello composto da 2 soli intervalli corrispondenti a 2 istanti ditempo si è dimostrato come risulti preferibile l’utilizzo degli stati anziché l’utilizzodegli intervalli.

4.2.3 Modello ad intervalli estesoLe considerazioni del paragrafo 4.2.2 confermano le previsioni della poca utilitàdegli intervalli con casi limitate. Le analisi sono proseguite su una ambiente com-posto da più intervalli di tempo in cui i blocchi cambiano stato più volte.Si è realizzato un modello composto da 3 blocchi e 6 diversi intervalli temporali.Per ogni blocco vengono considerati 2 distinti intervalli di tempo. La figura 4.8rappresenta l’andamento dei blocchi secondo la proprietà di clear e seguendo idati in tabella 4.9

Come nel caso precedente si analizza il comportamento dei blocchi in relazio-ne all’azione di clear.

In tabella 4.9 sono riportati tutti gli intervalli del modello con i rispettivi istantidi inizio e di fine indicanti quando il blocco corrispondente all’intervallo conside-rato risulti clear. L’oggetto A è clear negli intervalli IA01 e IA02, l’oggetto B èclear negli intervalli IB01 e IB02 e l’oggetto C è clear negli intervalli IC01 e IC02.Dall’analisi del grafico 4.8 si può intuire solo relativamente quando un blocco sitrovi sopra o sotto un altro.Con certezza si può solo affermare che nell’intervallo IA02 il blocco C è sopra ilblocco B e che nell’intervallo IB01 il blocco A è sopra il blocco C. Degli altri casicome ad esempio nell’intervallo IC01 non si può sapere con certezza quale bloccosia sopra un altro. Si può infatti presumere che il blocco B sia sotto il blocco Ao il blocco C ma poiché l’intervallo IB02 parte dall’istante 25 e quindi prima chefiniscano gli intervalli IA01 e IC01, non si può affermare che il blocco B si trovisotto un altro blocco.


Un’altra considerazione riguarda l’effettiva posizione del blocco tra gli istantidi tempo 15 e 25 che, analizzando il grafico e la tabella non può essere dedotta.Nel modello, inoltre, poiché si vuole confrontare la rappresentazione ad intervallirispetto con quella con stati di tempo, viene implementata solamente la proprietàdi clear inserendo unicamente le considerazioni intuibili descritte poco fa.

Figura 4.8: Intervalli del modello con più intervalli

Figura 4.9: Tabella degli intervalli di clear

Classi del modello

• Object : rappresenta i blocchi

• On : rappresenta la reificazione dell’azione On

• Clear : rappresenta la reificazione dell’azione Clear. Un blocco è clearquando non ha nessun altro blocco sopra di sé





• TemporalEntity: è la superclasse delle classi che rappresentano il tempo.

• Instant : rappresenta un istante di tempo. Sottoclasse di TemporalEntity.

• Interval: rappresenta gli intervalli di tempo. Sottoclasse di TemporalEntity.

Relazioni del modello

Questo modello, come il precedentem, necessita della presenza di due tipologie direlazioni, gli object properties che legano 2 individui delle classi e i data propertiesche legano un individuo di una classe ad un valore definito.Object properties

• holdsIn : Fact → State. Lega il fattoo allo stato




Data properties

• at : Instant → int. Serve per la regola SWRL ( presentata in seguito)

• starts : Interval → int. Indica l’inizio dell’intervallo

• ends : Interval → int. Indica la fine dell’intervallo

• now : Instant → int. Indica l’istante

• holdsAtInstant : Fact → int. Serve per la regola SWRL (presentata inseguito)

Rappresentazioni grafiche

La fig. 4.10 è la rappresentazione GrOWL del modello descritto. La fig. 4.11 èinvece la rappresentazione OntoGraf dello stesso modello. Con una rappresenta-zione di questo tipo si possono osservare tutti gli individui del modello e le varierelazioni che intercorrono tra gli elementi.


Figura 4.10: Rappresentazione del modello con più intervalli in GrOWL

Figura 4.11: Rappresentazione OntoGraf del modello con più intervalli

Queries

Utilizzando sempre la sintassi OWL Manchester e la funzionalità DL Query forni-ta dal software Protégé ( Glossario), si presentano ora alcune queries con i relativirisultati per valutare la bontà del modello.

• starts value 0 restituisce IA01, IC01

• start some int [>=10] restituisce IA02, Ib02, IC01, IC02


Come nel modello precedente, impostando un individuo now della classe Instantal valore intero 15 ed eseduendo la regola SWRL holdsAtInstantholdsIn(?fact, ?int), At(now, ?z), ends(?int, ?y), starts(?int, ?x), greaterThanO-rEqual(?z, ?x), lessThanOrEqual(?z, ?y) -> holdsAtInstant(?fact, ?z)si ottiene come risultato .


Con questa configurazione il numero degli individui necessario per la rappresen-tazione del modello descritto è 17 ( 6 intervalli, 6 clear, 2 on e 3 oggetti) e leasserzioni necessarie sono 33 ( 21 object properties e 12 data properties ).


Per fare un confronto con il modello a stati risulta necessario realizzare un modelloa stati analogo a questo.

4.2.4 Modello a stati analogo al modello ad intervalli este-so

Per effettuare il confronto con il modello ad intervalli esteso si è realizzato unmodello modificando i 6 intervalli di tempo in 9 stati (s1,s2.s9) rappresentanticiascuno un intervallo di tempo. La fig. 4.12 mostra questo processo di trasfor-mazione.Per rispettare le limitazioni del modello ad intervalli, per quanto riguarda l’analisicompleta dei blocchi solo in riferimento all’azione clear, si tengono in considera-zione tutte le asserzioni sugli oggetti clear e solo le 2 asserzioni sugli oggetti Onpresentate in precedenza ( per mantenere un confronto equivalente ).

Le classi e le relazioni presenti sono le stesse del modello a stati con reificazionedei fatti. La fig. 4.13 rappresenta il modello in GrOWL.


Per quanto riguarda il numero di individui e asserzioni, sono presenti 23 individui(9 per gli stati, 9 per i clear, 2 per gli on e 3 per gli oggetti) e 31 asserzioni ( 9sui clear, 20 sui blocchi e 2 sugli on).


Dal confronto con i dati precedenti si osserva che, per quanto riguarda il numerodegli individui, in questo caso ne servono di più ( 23 contro 17 ) ma per quantoriguarda il numero delle asserzioni ne sono necessarie circa lo stesso numero delcaso con intervalli ( 33 contro 31 ).


Figura 4.12: Intervalli in stati

Figura 4.13: Rappresentazione OntoGraf del modello con gli stati

Il fatto di dover rappresentare 9 stati anziché 6 intervalli per mostrare la stessasituazione fa comprendere come sia molto più complessa una rappresentazione astati rispetto ad una ad intervalli.

La rappresentazione ad intervalli risulta quindi più conveniente quando la finestradi osservazione è ampia ed è sufficiente osservare l’andamento dei blocchi per unasola azione. Con la rappresentazione ad intervalli inoltre si riesce a visualizzarela situazione dei blocchi in un qualsiasi istante di tempo cosa che con gli statinon è possibile perché non hanno un punto di inizio né un punto di fine.

Capitolo 5

Conclusioni e sviluppi futuri

Partendo dall’analisi degli Ontology Design Patterns, piccole ontologie sviluppa-te negli ultimi anni, ci si è soffermati su una particolare ontologia denominataContext Slices per osservarne l’utilità nel dominio della pianificazione dei blocchi.

Si è considerata una situazione semplice di pianificazione composta solo da 3blocchi e 2 diverse configurazioni, rappresentate come 2 istanti di tempo suc-cessivi e sono stati creati un modello utilizzando il pattern Context Slices ed unpattern basato sulla reificazione delle relazioni di On e Clear osservando come perquesto dominio di applicazione risulti preferibile in termini di numero di indivi-dui e asserzioni necessarie per la creazione dei modelli la soluzione basata sullareificazione delle relazioni.

In seguito si è ragionato sulla possibilità di costruire un modello con una confi-gurazione temporale ad intervalli. Immediatamente si è notata l’impossibilità diuna realizzazione di questo modello tramite il pattern Context Slices in quantol’utilizzo degli intervalli implica l’opposto di ciò che ci si propone di fare con ilpattern Context Slices. Da principio si è modellata la soluzione con 3 blocchi e 2intervalli per osservarne l’andamento con gli intervalli e si è notato che con po-che configurazioni risulta conveniente una soluzione basata su istanti temporali.Successivamente si è ragionato su un modello con più configurazioni diverse neltempo; lo si è rappresentato prima attraverso gli intervalli di tempo e in seguitoattraverso gli stati temporali, concludendo che, se non interessa la totalità delleazioni ma ci si focalizza su una singola azione per volta,con una finestra di osser-vazione ampia, risulta preferibile una situazione ad intervalli.

Per il dominio di pianificazione dei blocchi si è giunti a queste conclusioni:

1. per quanto riguarda il metodo di contestualizzazione risulta preferibile unasituazione con reificazione dei fatti rispetto ad una con la presenza dicontext-slices.

54 Conclusioni e sviluppi futuri

2. per quanto riguarda invece la scelta temporale con cui analizzare la piani-ficazione di blocchi è necessario fare una distinzione in base al numero diindividui e spostamenti degli stessi che si considerano: se si devono osser-vare pochi spostamenti è preferibile una rappresentazione a stati mentre sesi osserva l’andamento dei blocchi in un intervallo temporale più lungo condiversi spostamenti dei blocchi è preferibile una rappresentazione ad inter-valli, anche se, comunque, risulta essere meno dettagliata di una a stati inquanto non riesce a fornire tutte le proprietà dei blocchi stessi.

In futuro, partendo dal lavoro di questa tesi, è possibile ampliare l’analisi deldominio di applicazione inserendo il comportamento del braccio meccanico edosservando se le conclusioni raggiunte si adattano a tale dominio.

Bibliografia

[1] http://home.dei.polimi.it/colombet/ic/materiale/growl.pdf.

[2] http://ontologydesignpatterns.org/wiki/main_page.

[3] http://ontologydesignpatterns.org/wiki/odp:evaluationprinciples.

[4] http://protege.stanford.edu.

[5] http://www.co-ode.org/resources/reference/manchester_syntax/.

[6] http://www.daml.org/2003/11/swrl/.

[7] http://www.w3.org/.

[8] http://www.w3.org/2007/owl/wiki/owl_working_group.

[9] Valentina Presutti Aldo Gangemi. Ontology design patterns. Handbook onOntologies, 2nd edition, pagg 242-264, Dicember 2009.

[10] Dan Brickley Alistar Miles. Skos core vocabulary specification. Technicalreport, World Wide Web Consortium (W3C), November 2005.

[11] Libby Miller Dan Brickley. Foaf vocabulary specification 0.98.http://xmlns.com/foaf/spec/, August 2010.

[12] Mike Uschold e Martin King. Towards a methodology for building ontologies.In In Workshop on Basic Ontological Issues in Knowledge Sharing, held inconjunction with IJCAI-95, 1995.

[13] S.Russel e P.Norvig. Artificial intelligence, a modern approach pagg. 375.Sams, 2003.

[14] Robert Tolksdorf Elena Paslaru Bontas, Malgorzata Mochol. Case studieson ontology reuse. Freie Universitat Berlin, Germany, 2005.

[15] Dan Rubel Eric Clayberg. Ontology Design Patterns. Addison Wesley, thirdedition, 2008.

56 BIBLIOGRAFIA

[16] Thomas R. Gruber. A translation approach to portable ontologyspecifications. Knowledge Systems Laboratory, 1993.

[17] Peter Haase. D1.1.5 updated version of the networked ontology model.NEON/2009/D1.1.5/1.0, February 2009.

Appendice A

A.1 SWRLSWRL [6], Semantic Web Rule Language, é un linguaggio basato sulla combi-nazione dei sottolinguaggi del linguaggio OWL, OWL DL e OWL Lite, con isottolinguaggi del Rule Markup Language, Unary/Binary Datalog RuleML. Leregole SWRL vengono create per estendere gli assiomi OWL ad includere regolecome quelle di Horn. Unâestensione della semantica OWL é necessaria anche perprovvedere un significato formale alle ontologie OWL includendo regole scrittein sintassi astratta. Le regole SWRL si compongono di una parte anteceden-te(body) e una conseguente (head). Quando le condizioni specificate nel campoantecedente valgono allora devono valere le condizioni del campo conseguente.

Sia la parte antecedente che quella conseguente consistono di zero o piú ato-mi. Un antecedente vuoto é banalmente vero cosicché il conseguente deve esseresoddisfatto da ogni interpretazione; un conseguente vuoto é banalmente falso(per esempio non soddisfatto da alcuna interpretazione) cosicché anche il prece-dente non deve essere soddisfatto da alcuna interpretazione. Atomi multipli sonotrattati come una congiunzione. Si puó notare che regole con conseguenti incongiunzione possono essere trasformati in piú regole ciascuna delle quali con unconseguente atomico attraverso delle trasformazioni Lloyd-Topor.

Gli atomi in queste regole possono essere della forma C(x), P(x,y), sameAs(x,y)or differentFrom(x,y), dove C é una descrizione OWL, P una proprietá OWL, ex,y sono variabili o individui OWL o data values OWL .

A.2 ProtégéProtégé [4] é un editor di ontologie gratuito open source il cui frame work sibasa sulla conoscenza sviluppato dal Stanford Center for Biomedical InformaticsResearch alla facoltá di Medicina dell’Universitá di Stanford.

58

La piattaforma Protégé possiede lâeditor Protégé-OWL che ne é una sua estensio-ne per supportare il Web Ontology Language (OWL). Attraverso Protégé lâuten-te puó caricare e salvare ontologie OWL e RDF, modificare e visualizzare classi,proprietá e regole SWRL, definire caratteristiche classi logiche come espressioniOWL, utilizzare reasoners come classificatori della logica descrittiva e modificareindividui OWL per il markup del web semantico.

In Protégé é presente inoltre un plugin chiamato OntoGraf che permette unavisualizzazione grafica dellâontologia selezionando le relazioni, gli individui e leclassi che si desidera osservare.

A.3 GrOWLLa sintassi GrOWL [1] é una sintassi grafica per OWL sviluppata dal professorColombetti del Politecnico di Milano che permette una rappresentazione graficadei modelli OWL.Simili ai diagrammi UML, i diagrammi GrOWL sono specifici per la rappresen-tazione di modelli OWL.

A.4 Sintassi OWL ManchesterDalla versione 4 di Protégé - OWL é presente la sintassi OWL di Manchesterche viene utilizzata per scrivere le espressioni delle classi OWL. E’ influenzatasia dalla sintassi astratta OWL che dalla sintassi DL, che usa simboli logici didescrizione come il quantificatore universale ∀ e quello esistenziale ∃ .

Rispetto alla sintassi astratta OWL é meno ridondante e quindi piú veloce dascrivere e piú facile da comprendere. Rispetto alla sintassi DL i simboli matema-tici ∀ , ∃ , ¬ sono stati rimpiazzati dalle parole chiave “some”, “only”, e “not”.La sintassi OWL Manchester parte dalla sintassi DL usando una notazione infissapiuttosto che una notazione prefissa per le parole chiave in quanto, secondo glisviluppatori della sintassi, una notazione infissa rende la sintassi piú semplice daleggere e comprendere per i non esperti alla logica. Per alcuni esempi sullâuti-lizzo delle varie parole chiave della sintassi come “some”, “only”, “value”, “min”,“max”, “exactly” ecc. si rimanda al sito di riferimento del progetto [5].

Appendice B

In questa appendice vengono riportati le implementazioni in OWL functionalsyntax dei modelli presenti in questo documento.

B.1 Modello a stati Context SlicesPrefix(:=<http://www.semanticweb.org/massi/ontologies/2012/6/contextSlices>)Prefix(owl:=<http://www.w3.org/2002/07/owl>)Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns>)Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)Prefix(xsd:=<http://www.w3.org/2001/XMLSchema>)Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema>)Prefix(contextSlices:=<http://www.semanticweb.org/massi/ontologies/2012/6/contextSlices>)

Ontology(<http://www.semanticweb.org/massi/ontologies/2012/6/contextSlices>Declaration(Class(contextSlices:A))SubClassOf(contextSlices:A contextSlices:Object)Declaration(Class(contextSlices:B))SubClassOf(contextSlices:B contextSlices:Object)Declaration(Class(contextSlices:C))SubClassOf(contextSlices:C contextSlices:Object)Declaration(Class(contextSlices:Clear))Declaration(Class(contextSlices:Object))Declaration(Class(contextSlices:Space))Declaration(Class(contextSlices:State))SubClassOf(contextSlices:State contextSlices:Space)Declaration(ObjectProperty(contextSlices:holdsIn))SubObjectPropertyOf(contextSlices:holdsIn owl:topObjectProperty)ObjectPropertyDomain(contextSlices:holdsIn contextSlices:Object)ObjectPropertyRange(contextSlices:holdsIn contextSlices:State)Declaration(ObjectProperty(contextSlices:isClear))ObjectPropertyDomain(contextSlices:isClear contextSlices:Object)

60

ObjectPropertyRange(contextSlices:isClear contextSlices:Clear)Declaration(ObjectProperty(contextSlices:isDown))InverseObjectProperties(contextSlices:isDown contextSlices:isOn)ObjectPropertyDomain(contextSlices:isDown contextSlices:Object)ObjectPropertyRange(contextSlices:isDown contextSlices:Object)Declaration(ObjectProperty(contextSlices:isOn))InverseObjectProperties(contextSlices:isDown contextSlices:isOn)ObjectPropertyDomain(contextSlices:isOn contextSlices:Object)ObjectPropertyRange(contextSlices:isOn contextSlices:Object)Declaration(NamedIndividual(contextSlices:a@s1))ClassAssertion(contextSlices:A contextSlices:a@s1)ObjectPropertyAssertion(contextSlices:holdsIn contextSlices:a@s1 contextSli-

ces:s1)ObjectPropertyAssertion(contextSlices:isClear contextSlices:a@s1 contextSli-

ces:clear)ObjectPropertyAssertion(contextSlices:isOn contextSlices:a@s1 contextSlices:b@s1)Declaration(NamedIndividual(contextSlices:a@s2))ClassAssertion(contextSlices:A contextSlices:a@s2)ObjectPropertyAssertion(contextSlices:holdsIn contextSlices:a@s2 contextSli-

ces:s2)ObjectPropertyAssertion(contextSlices:isClear contextSlices:a@s2 contextSli-

ces:clear)ObjectPropertyAssertion(contextSlices:isOn contextSlices:a@s2 contextSlices:c@s2)Declaration(NamedIndividual(contextSlices:b@s1))ClassAssertion(contextSlices:B contextSlices:b@s1)ObjectPropertyAssertion(contextSlices:holdsIn contextSlices:b@s1 contextSli-

ces:s1)Declaration(NamedIndividual(contextSlices:b@s2))ClassAssertion(contextSlices:B contextSlices:b@s2)ObjectPropertyAssertion(contextSlices:holdsIn contextSlices:b@s2 contextSli-

ces:s2)ObjectPropertyAssertion(contextSlices:isClear contextSlices:b@s2 contextSli-

ces:clear)Declaration(NamedIndividual(contextSlices:c@s1))ClassAssertion(contextSlices:C contextSlices:c@s1)ObjectPropertyAssertion(contextSlices:holdsIn contextSlices:c@s1 contextSli-

ces:s1)ObjectPropertyAssertion(contextSlices:isClear contextSlices:c@s1 contextSli-

ces:clear)Declaration(NamedIndividual(contextSlices:c@s2))ClassAssertion(contextSlices:C contextSlices:c@s2)ObjectPropertyAssertion(contextSlices:holdsIn contextSlices:c@s2 contextSli-

ces:s2)

B.2 Modello a stati con reificazione delle relazioni 61

Declaration(NamedIndividual(contextSlices:clear))ClassAssertion(contextSlices:Clear contextSlices:clear)Declaration(NamedIndividual(contextSlices:s1))ClassAssertion(contextSlices:State contextSlices:s1)Declaration(NamedIndividual(contextSlices:s2))ClassAssertion(contextSlices:State contextSlices:s2) )

B.2 Modello a stati con reificazione delle rela-zioni

Prefix(:=<http://www.semanticweb.org/massi/ontologies/2012/4/reiModel>)Prefix(owl:=<http://www.w3.org/2002/07/owl>)Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns>)Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)Prefix(xsd:=<http://www.w3.org/2001/XMLSchema>)Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema>)Prefix(swrl:=<http://www.w3.org/2003/11/swrl>)Prefix(prova:=<http://www.semanticweb.org/massi/ontologies/2012/4/reiModel>)

Ontology(<http://www.semanticweb.org/massi/ontologies/2012/4/reiModel>Declaration(Class(<http://www.semanticweb.org/massi/ontologies/2012/4/reiModelImpossibleState>))SubClassOf(<http://www.semanticweb.org/massi/ontologies/2012/4/reiModelImpossibleState> prova:State)Declaration(Class(prova:Clear))SubClassOf(prova:Clear prova:Fact)DisjointClasses(prova:Clear prova:Object)DisjointClasses(prova:Clear prova:On)DisjointClasses(prova:Clear prova:State)DisjointClasses(prova:Clear owl:Nothing)Declaration(Class(prova:Fact))SubClassOf(prova:Fact owl:Thing)DisjointClasses(prova:Fact owl:Nothing)Declaration(Class(prova:Object))SubClassOf(prova:Object owl:Thing)DisjointClasses(prova:Object prova:Clear)DisjointClasses(prova:Object prova:On)DisjointClasses(prova:Object prova:State)DisjointClasses(prova:Object owl:Nothing)Declaration(Class(prova:On))SubClassOf(prova:On prova:Fact)

62

DisjointClasses(prova:On prova:Clear)DisjointClasses(prova:On prova:Object)DisjointClasses(prova:On prova:State)DisjointClasses(prova:On owl:Nothing)Declaration(Class(prova:Space))SubClassOf(prova:Space owl:Thing)DisjointClasses(prova:Space owl:Nothing)Declaration(Class(prova:State))SubClassOf(prova:State prova:Space)DisjointClasses(prova:State prova:Clear)DisjointClasses(prova:State prova:Object)DisjointClasses(prova:State prova:On)DisjointClasses(prova:State owl:Nothing)DisjointClasses(owl:Nothing prova:Clear)DisjointClasses(owl:Nothing prova:Fact)DisjointClasses(owl:Nothing prova:Object)DisjointClasses(owl:Nothing prova:On)DisjointClasses(owl:Nothing prova:Space)DisjointClasses(owl:Nothing prova:State)Declaration(ObjectProperty(prova:holdsIn))SubObjectPropertyOf(prova:holdsIn owl:topObjectProperty)AsymmetricObjectProperty(prova:holdsIn)IrreflexiveObjectProperty(prova:holdsIn)ObjectPropertyDomain(prova:holdsIn prova:Fact)ObjectPropertyRange(prova:holdsIn prova:State)Declaration(ObjectProperty(prova:objClear))SubObjectPropertyOf(prova:objClear owl:topObjectProperty)InverseObjectProperties(ObjectInverseOf(prova:objClear) prova:objClear)AsymmetricObjectProperty(prova:objClear)IrreflexiveObjectProperty(prova:objClear)ObjectPropertyDomain(prova:objClear prova:Object)ObjectPropertyRange(prova:objClear prova:Clear)Declaration(ObjectProperty(prova:onDown))SubObjectPropertyOf(prova:onDown owl:topObjectProperty)InverseObjectProperties(ObjectInverseOf(prova:onDown) prova:onDown)InverseFunctionalObjectProperty(prova:onDown)AsymmetricObjectProperty(prova:onDown)IrreflexiveObjectProperty(prova:onDown)ObjectPropertyDomain(prova:onDown prova:Object)ObjectPropertyRange(prova:onDown prova:On)DisjointObjectProperties(prova:onDown prova:onUp)Declaration(ObjectProperty(prova:onUp))SubObjectPropertyOf(prova:onUp owl:topObjectProperty)

B.2 Modello a stati con reificazione delle relazioni 63

InverseObjectProperties(ObjectInverseOf(prova:onUp) prova:onUp)AsymmetricObjectProperty(prova:onUp)IrreflexiveObjectProperty(prova:onUp)ObjectPropertyDomain(prova:onUp prova:Object)ObjectPropertyRange(prova:onUp prova:On)DisjointObjectProperties(prova:onUp prova:onDown)Declaration(NamedIndividual(<http://www.semanticweb.org/massi/ontologies/2012/4/reiModels1>))ClassAssertion(prova:Space <http://www.semanticweb.org/massi/ontologies/2012/4/reiModels1>)ClassAssertion(prova:State <http://www.semanticweb.org/massi/ontologies/2012/4/reiModels1>)ClassAssertion(owl:Thing <http://www.semanticweb.org/massi/ontologies/2012/4/reiModels1>)Declaration(NamedIndividual(prova:a))ClassAssertion(prova:Object prova:a)ClassAssertion(owl:Thing prova:a)ObjectPropertyAssertion(prova:objClear prova:a prova:cl001)ObjectPropertyAssertion(prova:objClear prova:a prova:cl002)ObjectPropertyAssertion(prova:onUp prova:a prova:on001)ObjectPropertyAssertion(prova:onUp prova:a prova:on002)Declaration(NamedIndividual(prova:b))ClassAssertion(prova:Object prova:b)ClassAssertion(owl:Thing prova:b)ObjectPropertyAssertion(prova:objClear prova:b prova:cl002)ObjectPropertyAssertion(prova:onDown prova:b prova:on001)Declaration(NamedIndividual(prova:c))ClassAssertion(prova:Object prova:c)ClassAssertion(owl:Thing prova:c)ObjectPropertyAssertion(prova:objClear prova:c prova:cl002)ObjectPropertyAssertion(prova:objClear prova:c prova:cl001)ObjectPropertyAssertion(prova:onDown prova:c prova:on002)Declaration(NamedIndividual(prova:cl001))AnnotationAssertion(rdfs:comment prova:cl001 clear allo stato s1)ClassAssertion(prova:Clear prova:cl001)ClassAssertion(prova:Fact prova:cl001)ClassAssertion(owl:Thing prova:cl001)ObjectPropertyAssertion(prova:holdsIn prova:cl001 <http://www.semanticweb.org/massi/ontologies/2012/4/reiModels1>)Declaration(NamedIndividual(prova:cl002))AnnotationAssertion(rdfs:comment prova:cl002 clear allo stato s2)ClassAssertion(prova:Clear prova:cl002)ClassAssertion(prova:Fact prova:cl002)

64

ClassAssertion(owl:Thing prova:cl002)ObjectPropertyAssertion(prova:holdsIn prova:cl002 prova:s2)Declaration(NamedIndividual(prova:on001))ClassAssertion(prova:Fact prova:on001)ClassAssertion(prova:On prova:on001)ClassAssertion(owl:Thing prova:on001)ObjectPropertyAssertion(prova:holdsIn prova:on001 <http://www.semanticweb.org/massi/ontologies/2012/4/reiModels1>)Declaration(NamedIndividual(prova:on002))ClassAssertion(prova:Fact prova:on002)ClassAssertion(prova:On prova:on002)ClassAssertion(owl:Thing prova:on002)ObjectPropertyAssertion(prova:holdsIn prova:on002 prova:s2)Declaration(NamedIndividual(prova:s2))ClassAssertion(prova:Space prova:s2)ClassAssertion(prova:State prova:s2)ClassAssertion(owl:Thing prova:s2)DifferentIndividuals(prova:s2 <http://www.semanticweb.org/massi/ontologies/2012/4/reiModels1>)

DLSafeRule(Body(ObjectPropertyAtom(prova:holdsIn Variable(<urn:swrl clear>)Variable(<urn:swrls>)) ObjectPropertyAtom(prova:holdsIn Variable(<urn:swrlon>)Variable(< urn:swrls>)) ObjectPropertyAtom(prova:objClear Variable(<urn:swrlo>)Variable(< urn:swrlclear>)) ObjectPropertyAtom(prova:onDown Variable(<urn:swrlo>)Variable(< urn:swrlon>)))

Head(ClassAtom(<http://www.semanticweb.org/massi/ontologies/2012/4/reiModelImpossibleState> Variable(<urn:swrls>)))) )

B.3 Modello ad intervalli basePrefix(:=<http://www.semanticweb.org/massi/ontologies/2012/7/intervalBase>)Prefix(owl:=<http://www.w3.org/2002/07/owl>)Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns>)Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)Prefix(xsd:=<http://www.w3.org/2001/XMLSchema>)Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema>)Prefix(swrl:=<http://www.w3.org/2003/11/swrl>)Prefix(swrlb:=<http://www.w3.org/2003/11/swrlb>)Prefix(intervalBase:=<http://www.semanticweb.org/massi/ontologies/ 2012/7/in-tervalBase>)

B.3 Modello ad intervalli base 65

Ontology(<http://www.semanticweb.org/massi/ontologies/2012/7/intervalBase>Declaration(Class(:Clear))SubClassOf(:Clear :Fact)Declaration(Class(:Fact))Declaration(Class(:Instant))SubClassOf(:Instant :TemporalEntity)Declaration(Class(:Interval))SubClassOf(:Interval :TemporalEntity)Declaration(Class(:Object))Declaration(Class(:On))SubClassOf(:On :Fact)Declaration(Class(:TemporalEntity))Declaration(ObjectProperty(:holdsIn))ObjectPropertyDomain(:holdsIn :Fact)ObjectPropertyRange(:holdsIn :Interval)Declaration(ObjectProperty(:objClear))ObjectPropertyDomain(:objClear :Object)ObjectPropertyRange(:objClear :Clear)Declaration(ObjectProperty(:onDown))ObjectPropertyDomain(:onDown :Object)ObjectPropertyRange(:onDown :On)Declaration(ObjectProperty(:onUp))ObjectPropertyDomain(:onUp :Object)ObjectPropertyRange(:onUp :On)Declaration(DataProperty(:At))DataPropertyDomain(:At :Instant)DataPropertyRange(:At xsd:int)Declaration(DataProperty(:ends))DataPropertyDomain(:ends :Interval)DataPropertyRange(:ends xsd:int)Declaration(DataProperty(:holdsAtInstant))SubDataPropertyOf(:holdsAtInstant owl:topDataProperty)DataPropertyDomain(:holdsAtInstant :Fact)DataPropertyRange(:holdsAtInstant xsd:int)Declaration(DataProperty(:now))DataPropertyDomain(:now :Instant)DataPropertyRange(:now xsd:int)Declaration(DataProperty(:starts))DataPropertyDomain(:starts :Interval)DataPropertyRange(:starts xsd:int)Declaration(NamedIndividual(:IA))ClassAssertion(:Interval :IA)

66

DataPropertyAssertion(:ends :IA 508sd:int)DataPropertyAssertion(:starts :IA 08sd:int)Declaration(NamedIndividual(:IB))ClassAssertion(:Interval :IB)DataPropertyAssertion(:ends :IB 508sd:int)DataPropertyAssertion(:starts :IB 218sd:int)Declaration(NamedIndividual(:IC))ClassAssertion(:Interval :IC)DataPropertyAssertion(:ends :IC 208sd:int)DataPropertyAssertion(:starts :IC 08sd:int)Declaration(NamedIndividual(:a))ClassAssertion(:Object :a)ObjectPropertyAssertion(:objClear :a :clA)ObjectPropertyAssertion(:onUp :a :onA01)ObjectPropertyAssertion(:onUp :a :onA02)Declaration(NamedIndividual(:b))ClassAssertion(:Object :b)ObjectPropertyAssertion(:objClear :b :IB)ObjectPropertyAssertion(:onDown :b :onA02)Declaration(NamedIndividual(:c))ClassAssertion(:Object :c)ObjectPropertyAssertion(:objClear :c :IC)ObjectPropertyAssertion(:onDown :c :onA01)Declaration(NamedIndividual(:clA))ClassAssertion(:Clear :clA)ObjectPropertyAssertion(:holdsIn :clA :IA)Declaration(NamedIndividual(:clB))ClassAssertion(:Clear :clB)ObjectPropertyAssertion(:holdsIn :clB :IB)Declaration(NamedIndividual(:clC))ClassAssertion(:Clear :clC)ObjectPropertyAssertion(:holdsIn :clC :IC)Declaration(NamedIndividual(:now))ClassAssertion(:Instant :now)DataPropertyAssertion(:At :now 208sd:int)Declaration(NamedIndividual(:onA01))ClassAssertion(:On :onA01)ObjectPropertyAssertion(:holdsIn :onA01 :IC)Declaration(NamedIndividual(:onA02))ClassAssertion(:On :onA02)ObjectPropertyAssertion(:holdsIn :onA02 :IB)DLSafeRule(Body(ObjectPropertyAtom(:holdsIn Variable(<urn:swrlfact>)Variable(<urn:swrlint>)) DataPropertyAtom(:At :now Variable(<urn:swrlz>))


DataPropertyAtom(:ends Variable(<urn:swrlint>) Variable(<urn:swrly>))DataPropertyAtom(:starts Variable(<urn:swrlint>) Variable(<urn:swrlx>))BuiltInAtom(swrlb:greaterThanOrEqual Variable(<urn:swrlz>) Variable(<urn:swrlx>))BuiltInAtom(swrlb:lessThanOrEqual Variable(<urn:swrlz>) Variable(<urn:swrly>)))Head(DataPropertyAtom(:holdsAtInstant Variable(<urn:swrlfact>)Variable(<urn:swrlz>)))) )

B.4 Modello ad intervalli basePrefix(:=<http://www.semanticweb.org/massi/ontologies/2012/6/moreIntervals>)Prefix(owl:=<http://www.w3.org/2002/07/owl>)Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns>)Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)Prefix(xsd:=<http://www.w3.org/2001/XMLSchema>)Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema>)Prefix(swrl:=<http://www.w3.org/2003/11/swrl>)Prefix(swrlb:=<http://www.w3.org/2003/11/swrlb>)Prefix(moreIntervals:=<http://www.semanticweb.org/massi/ontologies/ 2012/6/mo-reIntervals>)

Ontology(<http://www.semanticweb.org/massi/ontologies/2012/6/moreIntervals>Declaration(Class(moreIntervals:Clear))SubClassOf(moreIntervals:Clear moreIntervals:Fact)Declaration(Class(moreIntervals:Fact))Declaration(Class(moreIntervals:Instant))SubClassOf(moreIntervals:Instant moreIntervals:TemporalEntity)SubClassOf(moreIntervals:Instant DataExactCardinality(1 moreIntervals:At))Declaration(Class(moreIntervals:Interval))SubClassOf(moreIntervals:Interval moreIntervals:TemporalEntity)Declaration(Class(moreIntervals:Object))Declaration(Class(moreIntervals:On))SubClassOf(moreIntervals:On moreIntervals:Fact)Declaration(Class(moreIntervals:State))SubClassOf(moreIntervals:State moreIntervals:TemporalEntity)Declaration(Class(moreIntervals:TemporalEntity))Declaration(ObjectProperty(moreIntervals:holdsIn))ObjectPropertyDomain(moreIntervals:holdsIn moreIntervals:Fact)ObjectPropertyRange(moreIntervals:holdsIn moreIntervals:Interval)Declaration(ObjectProperty(moreIntervals:objClear))ObjectPropertyDomain(moreIntervals:objClear moreIntervals:Object)ObjectPropertyRange(moreIntervals:objClear moreIntervals:Clear)Declaration(ObjectProperty(moreIntervals:onDown))

68

ObjectPropertyDomain(moreIntervals:onDown moreIntervals:Object)ObjectPropertyRange(moreIntervals:onDown moreIntervals:On)Declaration(ObjectProperty(moreIntervals:onUp))ObjectPropertyDomain(moreIntervals:onUp moreIntervals:Object)ObjectPropertyRange(moreIntervals:onUp moreIntervals:On)Declaration(DataProperty(moreIntervals:At))SubDataPropertyOf(moreIntervals:At owl:topDataProperty)DataPropertyDomain(moreIntervals:At moreIntervals:Instant)DataPropertyRange(moreIntervals:At xsd:int)Declaration(DataProperty(moreIntervals:ends))DataPropertyDomain(moreIntervals:ends moreIntervals:Interval)DataPropertyRange(moreIntervals:ends xsd:int)Declaration(DataProperty(moreIntervals:holdsAtInstant))DataPropertyDomain(moreIntervals:holdsAtInstant moreIntervals:Fact)DataPropertyRange(moreIntervals:holdsAtInstant xsd:int)Declaration(DataProperty(moreIntervals:now))SubDataPropertyOf(moreIntervals:now owl:topDataProperty)DataPropertyDomain(moreIntervals:now moreIntervals:Instant)DataPropertyRange(moreIntervals:now xsd:int)Declaration(DataProperty(moreIntervals:starts))DataPropertyDomain(moreIntervals:starts moreIntervals:Interval)DataPropertyRange(moreIntervals:starts xsd:int)Declaration(NamedIndividual(moreIntervals:IA01))ClassAssertion(moreIntervals:Interval moreIntervals:IA01)DataPropertyAssertion(moreIntervals:ends moreIntervals:IA01 308sd:int)DataPropertyAssertion(moreIntervals:starts moreIntervals:IA01 08sd:int)Declaration(NamedIndividual(moreIntervals:IA02))ClassAssertion(moreIntervals:Interval moreIntervals:IA02)DataPropertyAssertion(moreIntervals:ends moreIntervals:IA02 608sd:int)DataPropertyAssertion(moreIntervals:starts moreIntervals:IA02 408sd:int)Declaration(NamedIndividual(moreIntervals:IB01))ClassAssertion(moreIntervals:Interval moreIntervals:IB01)DataPropertyAssertion(moreIntervals:ends moreIntervals:IB01 158sd:int)DataPropertyAssertion(moreIntervals:starts moreIntervals:IB01 08sd:int)Declaration(NamedIndividual(moreIntervals:IB02))ClassAssertion(moreIntervals:Interval moreIntervals:IB02)DataPropertyAssertion(moreIntervals:ends moreIntervals:IB02 388sd:int)DataPropertyAssertion(moreIntervals:starts moreIntervals:IB02 258sd:int)Declaration(NamedIndividual(moreIntervals:IC01))ClassAssertion(moreIntervals:Interval moreIntervals:IC01)DataPropertyAssertion(moreIntervals:ends moreIntervals:IC01 278sd:int)DataPropertyAssertion(moreIntervals:starts moreIntervals:IC01 158sd:int)Declaration(NamedIndividual(moreIntervals:IC02))


ClassAssertion(moreIntervals:Interval moreIntervals:IC02)DataPropertyAssertion(moreIntervals:ends moreIntervals:IC02 658sd:int)DataPropertyAssertion(moreIntervals:starts moreIntervals:IC02 358sd:int)Declaration(NamedIndividual(moreIntervals:a))ClassAssertion(moreIntervals:Object moreIntervals:a)ObjectPropertyAssertion(moreIntervals:objClear moreIntervals:a moreInter-

vals:clc01)ObjectPropertyAssertion(moreIntervals:objClear moreIntervals:a moreInter-

vals:clb01)ObjectPropertyAssertion(moreIntervals:objClear moreIntervals:a moreInter-

vals:cla02)ObjectPropertyAssertion(moreIntervals:objClear moreIntervals:a moreInter-

vals:cla01)ObjectPropertyAssertion(moreIntervals:onUp moreIntervals:a moreIntervals:onb01)Declaration(NamedIndividual(moreIntervals:b))ClassAssertion(moreIntervals:Object moreIntervals:b)ObjectPropertyAssertion(moreIntervals:objClear moreIntervals:b moreInter-

vals:clb02)ObjectPropertyAssertion(moreIntervals:objClear moreIntervals:b moreInter-

vals:clb01)ObjectPropertyAssertion(moreIntervals:onDown moreIntervals:b moreIntervals:ona02)Declaration(NamedIndividual(moreIntervals:c))ClassAssertion(moreIntervals:Object moreIntervals:c)ObjectPropertyAssertion(moreIntervals:objClear moreIntervals:c moreInter-

vals:clc01)ObjectPropertyAssertion(moreIntervals:objClear moreIntervals:c moreInter-

vals:clc02)ObjectPropertyAssertion(moreIntervals:objClear moreIntervals:c moreInter-

vals:cla02)ObjectPropertyAssertion(moreIntervals:onDown moreIntervals:c moreIntervals:onb01)ObjectPropertyAssertion(moreIntervals:onUp moreIntervals:c moreIntervals:ona02)Declaration(NamedIndividual(moreIntervals:cla01))ClassAssertion(moreIntervals:Clear moreIntervals:cla01)ObjectPropertyAssertion(moreIntervals:holdsIn moreIntervals:cla01 moreIn-

tervals:IA01)Declaration(NamedIndividual(moreIntervals:cla02))ClassAssertion(moreIntervals:Clear moreIntervals:cla02)ObjectPropertyAssertion(moreIntervals:holdsIn moreIntervals:cla02 moreIn-

tervals:IA02)Declaration(NamedIndividual(moreIntervals:clb01))ClassAssertion(moreIntervals:Clear moreIntervals:clb01)ObjectPropertyAssertion(moreIntervals:holdsIn moreIntervals:clb01 moreIn-

tervals:IB01)

70

Declaration(NamedIndividual(moreIntervals:clb02))ClassAssertion(moreIntervals:Clear moreIntervals:clb02)ObjectPropertyAssertion(moreIntervals:holdsIn moreIntervals:clb02 moreIn-

tervals:IB02)Declaration(NamedIndividual(moreIntervals:clc01))ClassAssertion(moreIntervals:Clear moreIntervals:clc01)ObjectPropertyAssertion(moreIntervals:holdsIn moreIntervals:clc01 moreIn-

tervals:IC01)Declaration(NamedIndividual(moreIntervals:clc02))ClassAssertion(moreIntervals:Clear moreIntervals:clc02)ObjectPropertyAssertion(moreIntervals:holdsIn moreIntervals:clc02 moreIn-

tervals:IC02)Declaration(NamedIndividual(moreIntervals:now))ClassAssertion(moreIntervals:Instant moreIntervals:now)DataPropertyAssertion(moreIntervals:At moreIntervals:now 608sd:int)Declaration(NamedIndividual(moreIntervals:ona02))ClassAssertion(moreIntervals:On moreIntervals:ona02)ObjectPropertyAssertion(moreIntervals:holdsIn moreIntervals:ona02 moreIn-

tervals:IA02)Declaration(NamedIndividual(moreIntervals:onb01))ClassAssertion(moreIntervals:On moreIntervals:onb01)ObjectPropertyAssertion(moreIntervals:holdsIn moreIntervals:onb01 moreIn-

tervals:IB01)DLSafeRule(Body(ObjectPropertyAtom(moreIntervals:holdsIn Variable(<urn:swrlfact>)

Variable(<urn:swrlint>))DataPropertyAtom(moreIntervals:At moreIntervals:now Variable(<urn:swrlz>))DataPropertyAtom(moreIntervals:ends Variable(<urn:swrlint>) Variable(<urn:swrly>))DataPropertyAtom(moreIntervals:starts Variable(<urn:swrlint>) Variable(<urn:swrlx>))BuiltInAtom(swrlb:greaterThanOrEqual Variable(<urn:swrlz>) Variable(<urn:swrlx>))BuiltInAtom(swrlb:lessThanOrEqual Variable(<urn:swrlz>) Variable(<urn:swrly>)))Head(DataPropertyAtom(moreIntervals:holdsAtInstant Variable(<urn:swrlfact>)

Variable(<urn:swrlz>))))DLSafeRule(Body(ObjectPropertyAtom(moreIntervals:holdsIn Variable(<urn:swrlfact>)

Variable(<urn:swrlint>))DataPropertyAtom(moreIntervals:ends Variable(<urn:swrlint>) Variable(<urn:swrly>))DataPropertyAtom(moreIntervals:starts Variable(<urn:swrlint>) Variable(<urn:swrlx>))BuiltInAtom(swrlb:greaterThanOrEqual 108sd:integer Variable(<urn:swrlx>))BuiltInAtom(swrlb:lessThanOrEqual 108sd:integer Variable(<urn:swrly>)))

Head(ClassAtom(moreIntervals:State Variable(<urn:swrlfact>))))

B.5 Modello a stati esteso 71

B.5 Modello a stati estesoPrefix(:=<http://www.semanticweb.org/massi/ontologies/2012/6/senzaIntervals>)Prefix(owl:=<http://www.w3.org/2002/07/owl>)Prefix(rdf:=<http://www.w3.org/1999/02/22-rdf-syntax-ns>)Prefix(xml:=<http://www.w3.org/XML/1998/namespace>)Prefix(xsd:=<http://www.w3.org/2001/XMLSchema>)Prefix(rdfs:=<http://www.w3.org/2000/01/rdf-schema>)Prefix(swrl:=<http://www.w3.org/2003/11/swrl>)Prefix(swrlb:=<http://www.w3.org/2003/11/swrlb>)Prefix(senzaIntervals:=<http://www.semanticweb.org/massi/ontologies /2012/6/sen-zaIntervals>)

Ontology(<http://www.semanticweb.org/massi/ontologies/2012/6/senzaIntervals>Declaration(Class(senzaIntervals:Clear))SubClassOf(senzaIntervals:Clear senzaIntervals:Fact)Declaration(Class(senzaIntervals:Fact))Declaration(Class(senzaIntervals:Instant))SubClassOf(senzaIntervals:Instant senzaIntervals:TemporalEntity)SubClassOf(senzaIntervals:Instant DataExactCardinality(1 senzaIntervals:At))Declaration(Class(senzaIntervals:Object))Declaration(Class(senzaIntervals:On))SubClassOf(senzaIntervals:On senzaIntervals:Fact)Declaration(Class(senzaIntervals:State))SubClassOf(senzaIntervals:State senzaIntervals:TemporalEntity)Declaration(Class(senzaIntervals:TemporalEntity))Declaration(ObjectProperty(senzaIntervals:holdsIn))ObjectPropertyDomain(senzaIntervals:holdsIn senzaIntervals:Fact)Declaration(ObjectProperty(senzaIntervals:objClear))ObjectPropertyDomain(senzaIntervals:objClear senzaIntervals:Object)ObjectPropertyRange(senzaIntervals:objClear senzaIntervals:Clear)Declaration(ObjectProperty(senzaIntervals:onDown))ObjectPropertyDomain(senzaIntervals:onDown senzaIntervals:Object)ObjectPropertyRange(senzaIntervals:onDown senzaIntervals:On)Declaration(ObjectProperty(senzaIntervals:onUp))SubObjectPropertyOf(senzaIntervals:onUp owl:topObjectProperty)ObjectPropertyDomain(senzaIntervals:onUp senzaIntervals:Object)ObjectPropertyRange(senzaIntervals:onUp senzaIntervals:On)Declaration(DataProperty(senzaIntervals:At))SubDataPropertyOf(senzaIntervals:At owl:topDataProperty)DataPropertyDomain(senzaIntervals:At senzaIntervals:Instant)DataPropertyRange(senzaIntervals:At xsd:int)Declaration(DataProperty(senzaIntervals:ends))

72

DataPropertyRange(senzaIntervals:ends xsd:int)Declaration(DataProperty(senzaIntervals:holdsAtInstant))DataPropertyDomain(senzaIntervals:holdsAtInstant senzaIntervals:Fact)DataPropertyRange(senzaIntervals:holdsAtInstant xsd:int)Declaration(DataProperty(senzaIntervals:now))SubDataPropertyOf(senzaIntervals:now owl:topDataProperty)DataPropertyDomain(senzaIntervals:now senzaIntervals:Instant)DataPropertyRange(senzaIntervals:now xsd:int)Declaration(DataProperty(senzaIntervals:starts))DataPropertyRange(senzaIntervals:starts xsd:int)Declaration(NamedIndividual(senzaIntervals:a))ClassAssertion(senzaIntervals:Object senzaIntervals:a)ObjectPropertyAssertion(senzaIntervals:objClear senzaIntervals:a senzaInter-

vals:cl002)ObjectPropertyAssertion(senzaIntervals:objClear senzaIntervals:a senzaInter-




vals:cl003)ObjectPropertyAssertion(senzaIntervals:onUp senzaIntervals:a senzaIntervals:on001)Declaration(NamedIndividual(senzaIntervals:b))ClassAssertion(senzaIntervals:Object senzaIntervals:b)ObjectPropertyAssertion(senzaIntervals:objClear senzaIntervals:b senzaInter-

vals:cl004)ObjectPropertyAssertion(senzaIntervals:objClear senzaIntervals:b senzaInter-




vals:cl006)ObjectPropertyAssertion(senzaIntervals:onDown senzaIntervals:b senzaInter-

vals:on008)Declaration(NamedIndividual(senzaIntervals:c))ClassAssertion(senzaIntervals:Object senzaIntervals:c)ObjectPropertyAssertion(senzaIntervals:objClear senzaIntervals:c senzaInter-

vals:cl003)ObjectPropertyAssertion(senzaIntervals:objClear senzaIntervals:c senzaInter-

vals:cl002)


ObjectPropertyAssertion(senzaIntervals:objClear senzaIntervals:c senzaInter-vals:cl007)




ObjectPropertyAssertion(senzaIntervals:onDown senzaIntervals:c senzaInter-vals:on001)

ObjectPropertyAssertion(senzaIntervals:onUp senzaIntervals:c senzaIntervals:on008)Declaration(NamedIndividual(senzaIntervals:cl001))ClassAssertion(senzaIntervals:Clear senzaIntervals:cl001)ObjectPropertyAssertion(senzaIntervals:holdsIn senzaIntervals:cl001 senzaIn-

tervals:s1)Declaration(NamedIndividual(senzaIntervals:cl002))ClassAssertion(senzaIntervals:Clear senzaIntervals:cl002)ObjectPropertyAssertion(senzaIntervals:holdsIn senzaIntervals:cl002 senzaIn-

tervals:s2)ClassAssertion(senzaIntervals:Clear senzaIntervals:cl003)ObjectPropertyAssertion(senzaIntervals:holdsIn senzaIntervals:cl003 senzaIn-






tervals:s8)Declaration(NamedIndividual(senzaIntervals:cl009))

74

ClassAssertion(senzaIntervals:Clear senzaIntervals:cl009)ObjectPropertyAssertion(senzaIntervals:holdsIn senzaIntervals:cl009 senzaIn-

tervals:s9)Declaration(NamedIndividual(senzaIntervals:now))ClassAssertion(senzaIntervals:Instant senzaIntervals:now)DataPropertyAssertion(senzaIntervals:At senzaIntervals:now 158sd:int)Declaration(NamedIndividual(senzaIntervals:on001))ClassAssertion(senzaIntervals:On senzaIntervals:on001)ObjectPropertyAssertion(senzaIntervals:holdsIn senzaIntervals:on001 senzaIn-

tervals:s1)Declaration(NamedIndividual(senzaIntervals:on008))ClassAssertion(senzaIntervals:On senzaIntervals:on008)ObjectPropertyAssertion(senzaIntervals:holdsIn senzaIntervals:on008 senzaIn-

tervals:s8)Declaration(NamedIndividual(senzaIntervals:s1))ClassAssertion(senzaIntervals:State senzaIntervals:s1)Declaration(NamedIndividual(senzaIntervals:s2))ClassAssertion(senzaIntervals:State senzaIntervals:s2)Declaration(NamedIndividual(senzaIntervals:s3))ClassAssertion(senzaIntervals:State senzaIntervals:s3)Declaration(NamedIndividual(senzaIntervals:s4))ClassAssertion(senzaIntervals:State senzaIntervals:s4)Declaration(NamedIndividual(senzaIntervals:s5))ClassAssertion(senzaIntervals:State senzaIntervals:s5)Declaration(NamedIndividual(senzaIntervals:s6))ClassAssertion(senzaIntervals:State senzaIntervals:s6)Declaration(NamedIndividual(senzaIntervals:s7))ClassAssertion(senzaIntervals:State senzaIntervals:s7)Declaration(NamedIndividual(senzaIntervals:s8)) ClassAssertion(senzaIntervals:State

senzaIntervals:s8) Declaration(NamedIndividual(senzaIntervals:s9)) ClassAsser-tion(senzaIntervals:State senzaIntervals:s9)

DLSafeRule(Body(ObjectPropertyAtom(senzaIntervals:holdsIn Variable(<urn:swrlfact>)Variable(<urn:swrlint>)) DataPropertyAtom(senzaIntervals:At senzaIntervals:nowVariable(<urn:swrlz>)) DataPropertyAtom(senzaIntervals:ends Variable(<urn:swrlint>)Variable(<urn:swrly>)) DataPropertyAtom(senzaIntervals:starts Variable(<urn:swrlint>)Variable(<urn:swrlx>)) BuiltInAtom(swrlb:greaterThan Variable(<urn:swrlz>)Variable(<urn:swrlx>)) BuiltInAtom(swrlb:lessThanOrEqual Variable(<urn:swrlz>)Variable(<urn:swrly>)))Head(DataPropertyAtom(senzaIntervals:holdsAtInstantVariable(<urn:swrlfact>) Variable(<urn:swrlz>))))

DLSafeRule(Body(ObjectPropertyAtom(senzaIntervals:holdsIn Variable(<urn:swrlfact>)Variable(<urn:swrlint>)) DataPropertyAtom(senzaIntervals:ends Variable(<urn:swrlint>)


Variable(<urn:swrly>)) DataPropertyAtom(senzaIntervals:starts Variable(<urn:swrlint>)Variable(<urn:swrlx>)) BuiltInAtom(swrlb:greaterThanOrEqual 108sd:integer Va-riable(<urn:swrlx>)) BuiltInAtom(swrlb:lessThanOrEqual 108sd:integer Varia-ble(<urn:swrly>))) Head(ClassAtom(senzaIntervals:State Variable(<urn:swrlfact>)))))

Politecnico di Milano Scuola di ingegneria industriale e Corso ......Politecnico di Milano Scuola di...

Documents

Transcript of Politecnico di Milano Scuola di ingegneria industriale e Corso ......Politecnico di Milano Scuola di...