Analisi di una integrazione con il sistema MOMIS
Partendo da alcuni database inerenti lo stesso argomento (possono essere
forniti 6 database del settore tessile) eseguire, come prima cosa, una
integrazione 'a mano'. Rappresentare con uno schema E/R la vista globale
voluta ed i relativi mapping con i concetti locali. Eseguire successivamente
l'integrazione delle sorgenti con il sistema MOMIS evidenziando, se
presenti, le differenze con l'integrazione fatta a mano. Provare ad ottenere
lo schema desiderato variando i parametri del modulo di Cluster o
l'annotazione delle sorgenti locali.
Porre alcune semplici query al modulo Query Manager del sistema MOMIS ed
analizzare la correttezza dei risultati proposti indicando le query locali,
eseguendole sui database di partenza e mostrando la riconciliazione dei dati
cosi' ottenuti.
Indicare eventuali problematiche riscontrate durante la fase di integrazione
e di interrogazione.
Inserimento di relazioni Estensionali nel sistema MOMIS
Il sistema MOMIS, al momento, permette al progettista di definire o
ritrovare solamente relazioni di tipo intensionale. Si devono implementare
le classi java rappresentanti i concetti di relazioni estensionali fra
diverse interfacce ODLi3 e permettere al progettista (via interfaccia
grafica) di aggiungere a mano relazioni estensionali al Thesaurus di
relazioni intensionali di MOMIS durante una integrazione. Fornire inoltre un
tool che verifichi la correttezza degli assiomi estensionali proposti
analizzando i dati delle sorgenti locali di partenza.
Confronto fra le funzionalita' di editing e di visualizzazione di ontologie fornite dai principali tool sviluppati (con particolare riferimento a Protege) e quelle fornite da MOMIS-Ontology Builder con l'obiettivo di fornire un'analisi di massima di nuove funzionalita' da implementare.
(altri Tool: Apollo, Linkfactory, Oiled, OntoEdit, Ontolingua, Ontosaurus, ...)
Test del componente di MOMIS-Ontology Builder per l'esportazione in OWL:
provare a importare in MOMIS alcune delle ontologie esportate da protege all'URL: http://protege.stanford.edu/ontologies/ontologies.html: quali sono gli elementi persi nella visualizzazione (se ce ne sono)?
Esportare l'ontologia OWL creata con Protege e precedentemente importata in MOMIS nuovamente in OWL e verificare con OWL se ci sono degli elementi persi/ delle differenze
Confrontare i due file OWL prodotti
Test del Wrapper per sorgenti OWL di MOMIS:
Importazione di ontologie OWL in MOMIS e verifica di eventuali
elementi/concetti perduti durante l'operazione (Per trovare altre
ontologie OWL si puo' utilizzare Google:
http://www.google.com/search?q=filetype:owl+owl o consultare la pagina http://protege.stanford.edu/ontologies/ontologies.html)
Provare a effettuare alcuni testi di allineamento di ontologie: in particolare si consideri l'EON Contest all'URL: http://co4.inrialpes.fr/align/Contest
Le sorgenti per eseguire i test sono state riportate alla pagina: http://dbgroup.unimo.it/EON/contestResult.html
Elenco dei test possibili (ogni tesina dovra' provare 4/5 test tra quelli in elenco)
Effettuare il test 101:
101) Concept test: Id
This test compares the ontology to itself.
102) Concept test: ?
This test compares the ontology to a totally irrelevant one. We ussed the food ontology given in the OWL guide (verbatim).
103) Concept test: Language generalisation
This test compares the ontology with its generalisation in OWL Lite (i.e., unavailable constraints are replaced by the more general available). The generalization basically removes owl:unionOf and owl:oneOf and the Property types (owl:TransitiveProperty).
104) Concept test: Language restriction
This test compares the ontology with its restriction in OWL Lite (where unavailable constraints have been discarded).
201) Systematic: No names
Each label or identifier is replaced by a random one.
202) Systematic: No names, no comment
Each label or identifier is replaced by a random one. Comments (rdfs:comment and dc:description) have been suppressed as well.
204) Systematic: Naming conventions
Different naming conventions (Uppercasing, underscore, dash, etc.) are used for labels. Comments have been suppressed.
205) Systematic: Synonyms
Labels are replaced by synonyms. Comments have been suppressed.
206) Systematic: Foreign names
The complete ontology is translated to another language than english (French in the current case, but other languages would be fine).
221) Systematic: No hierarchy
All subclass assertions to named classes are suppressed.
222) Systematic: Flattened hierarchy
A hierarchy still exists but has been strictly reduced.
223) Systematic: Expanded hierarchy
Numerous intermediate classes are introduced within the hierarchy.
224) Systematic: No instances
All individuals have been suppressed from the ontology.
225) Systematic: No restrictions
All local restrictions on properties have been suppressed from the ontology.
226) Systematic: No datatypes
In this test all datatypes are converted to xsd:string.
228) Systematic: No properties
Properties and relations between objects have been completely suppressed.
230) Systematic: Flattening entities
Some components of classes are expanded in the class structure (e.g., year, month, day attributes instead of date).
Analizzare le API per l'allineamento di ontologie in http://sourceforge.net/projects/owlapi e ipotizzare l'uso di un tale tool per la valutazione delle ontologie prodotte con MOMIS-Ontology Builder
Analisi del progetto KPONTOLOGY e confronto con MOMIS-Ontology Builder
KPONTOLOGY is a Java framework allowing ontology management a high-level
interface to several implementations for ontology handling, including JENA
(versions 1.6 and 2.1: http://www.hpl.hp.com/semweb/jena.htm), Sesame
(http://sourceforge.net/projects/sesame) and ODE
(http://delicias.dia.fi.upm.es/webODE/).
KPONTOLOGY has been developed with support of European IST projects such as
Esperonto, SEKT and HOPS.
KPONTOLOGY is the result of several research and commercial projects using
Semantic Web technology developed at iSOCO. You are welcome to use, improve
and/or comment any of the aspects of this software.
Studio di alcuni tra i linguaggi esistenti per l'interrogazione di ontologie
RDF/OWL:
RDQL
RQL
SquishQL
OWL-QL
SPARQL
Analisi delle caratteristiche dei diversi linguaggi e delle loro differenze.
Analisi di eventuali tool che li implementano
Reingegnerizzazione e sperimentazione di Hunter Agent Hunter Agent
e' un agente per la ricerca semantica di informazioni in Internet.
Lo scopo primario dell'agente e' quello di migliorare i risultati della
ricerca che normalmente si ottengono usando un motore di ricerca basato su
parole chiave (come Google). La tesina dovra' validare l'approccio esistente
in due direzioni. La prima riguarda la re-ingegnerizzazione del codice
esistente in modo da organizzare i comportamenti dell'agente sfruttando i
comportamenti di JADE. Durante questa fase si procedera' ad una attivita'
di progettazione usando Agent UML e di conseguente implementazione del
codice. La seconda direzione prevede l'utilizzo sperimentale dell'agente in
modo da tracciare i tempi richiesti per soddisfare una interrogazione al
variare di alcuni parametri quali il numero di link considerati e la
profondita' della ricerca. Questa attivita' servira' anche per verificare
gli algoritmi utilizzati.
Riferimenti: tesi di Daniele Gozzi, materiale su
Agent UML, codice Java esistente del progetto Hackord Creazione ed
integrazione di ontologie da sorgenti di dati eterogenee
Studio di un brokering agent in termini di FSM
Un Brokering Agent e' responsabile di raccogliere informazioni ontologiche
proveniente da altri agenti e di costruire ontologie che integrano queste
ontologie in una unica vista globale. Durante il progetto Sewasie (attualmente
in corso) si e' compiuta una analisi delle attivita' proprie di un Brokering
Agent. Sulla base di questa analisi, la tesina ha come obiettivo la costruzione
del Brokering Agent come macchina a stati finiti (FSM). I comportamenti
dell'agente dovranno essere organizzati individuando gli stati, le attivita'
pertinenti a ciascuno di essi e le condizioni di transizione da uno stato
all'altro. Si prevede pertanto una parte progettuale in Agent UML e una parte
implementativa in JADE.
Riferimenti: Deliverable Sewasie, documento di analisi interna, materiale su
Agent UML
Studio di un SINode Agent in termini di FSM
Un SINode Agent gestisce ed espone in un ambiente ad agenti una ontologia
risultato di un processo di integrazione di MOMIS. Durante il progetto Sewasie
(attualmente in corso) si e' compiuta una analisi delle attivita' proprie di un
SINode Agent e come questo debba interagire con un Brokering Agent. Sulla base
di questa analisi, la tesina ha come obiettivo la costruzione del SINode Agent
come macchina a stati finiti (FSM). I comportamenti dell'agente dovranno essere
organizzati individuando gli stati, le attivita' pertinenti a ciscuno di essi e
le condizioni di transizione da uno stato all'altro. Si prevede pertanto una
parte progettuale in Agent UML e una parte implementativa in JADE.
Riferimenti: Deliverable Sewasie, documento di analisi interna, materiale su
Agent UML
