SPARQLExplorer e D2RServer

SPARQLExplorer e D2RServer
Andrea Paglialonga, Alessio Pierantozzi
Abstract
Nel seguente elaborato sono analizzati gli strumenti D2R-Server e SPARQLExplorer. Il lavoro si colloca all'interno del progetto Context-ADDICT, in quanto
tale analisi é volta ad ottenere un confronto dei due strumenti, che valuti le
dierenze nell'estrazione delle informazioni da una base di dati relazionale e la
loro rappresentazione semantica.
Keywords: XML, Relational, OWL, Ontology, XML Schema, Wrapping
Released: June 19, 2007
Num. Pages: 28
Internal No.: 2007.04
Context-ADDICT is a project on Context-Aware Data Design, Integration, Customization and Tailoring
developed at Politecnico di Milano, Dipartimento di Elettronica e Informazione.
An electronic copy of this document is available for download at:
http://poseidon.elet.polimi.it/ca/docs/
Contents
1 Introduzione
2 Obiettivi e Requisiti
3 Lavori correlati
3.1
D2R-Server
3.1.1
3.2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Congurazione ed esecuzione D2R-Server
2
2
3
3
. . . . . . . . . . . . . . . . . . . . . . .
4
Rosex e SPARQLExplorer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
3.2.1
Rosex
6
3.2.2
SPARQLExplorer
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 Risultati sperimentali
4.1
Database di riferimeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2
Ontologie generate
4.3
Analisi delle query in SPARQL
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5 Conclusioni e sviluppi futuri
A File RDF generato da D2R-Server
7
9
9
9
10
22
24
1
1
Introduzione
Il seguente progetto si colloca nell'ambito di Context-ADDICT (mostrato in Figura 1). Nello scenario
in cui lavora Context-Addict ( [4] acronimo di Context-Aware Data Design, Integration, Customization
and Tailoring), le informazioni generate da sorgenti informative indipendenti, eterogenee, distribuite e
mobili vengono integrate e ltrate sulla base degli interessi dell'utente e del contesto in cui si trova.
E' un progetto suddiviso in vari moduli, i quali focalizzano l'attenzione ognuno su di una particolare
macro-funzionalità da sviluppare.
In particolare il modulo di estrazione semantica si occupa di concettualizzare la sorgente relazionale
in modo da permettere l'integrazione all'interno del sistema Context-ADDICT, e più in generale per
consentire alle applicazioni operanti nel Web Semantico di accedere ai dati contenuti con un approccio
basato sulla semantica.
Un ulteriore modulo poi si occupa di realizzare tutte le funzionalità che, operando su di una rappresentazione semantica, consentono ad una applicazione utente di estrarre i dati e di contestualizzarli
nell'ambiente di riferimento. Questo è permesso creando delle query semantiche SPARQL.
Tale lavoro non si occupa di fornire ulteriori funzionalità a quelle già implementate nell'ambito del
sistema Context-ADDICT, ma è un lavoro prettamente analitico di confronto tra lo strumento SPARQLExplorer e D2R-Server, che permettono di operare nel contesto appena descritto in modo sommario.
Figure 1: Context-ADDICT scenario
Prima di entrare nel vivo dell'analisi ci soermiamo ad inquadrare il problema focalizzando l'ambito
su cui ci si muove (sezione 2), in particolare verranno descritti nel dettaglio come sono stati sviluppati i due
strumenti D2R-Server (sezione 3.1) e SPARQLExplorer (sezione 3.2); successivamente verrà arontato il
discorso del confronto tra i due strumenti nella sezione 4. Inne nell'ultima sezione, la 5, verrano espresse
le conclusioni a cui si é giunti dopo i vari risultati sperimentali ottenuti.
2
Obiettivi e Requisiti
L'obiettivo che ci si è posti è quello di analizzare e commentare in modo critico come due strumenti
D2R-Server e SPARQLExplorer eettuano delle interrogazioni SPARQL su un modello ontologico dei
dati. Pur eettuando entrambi lo stesso compito, i due tool operano secondo procedure diverse e quindi
è utile comprendere quali sono le principali dierenze e analogie.
SPARQL (SPARQL Protocol And Query Language) è un linguaggio di interrogazione usato per
ottenere informazioni da un grafo RDF; in denitiva è un RDF query language. Sorge l'interrogativo:
2
A cosa serve un linguaggio di interrogazione di dati RDF se esiste il linguaggio di interrogazione di dati
espressi in forma relazionale come sql? O meglio: A cosa serve rappresentare i dati in formato RDF?
RDF è un linguaggio (non è l'unico) che permette di rappresentare i dati sotto forma di ontologie.
La rappresentazione ontologica dei dati va a focalizzare l'attenzione sull'informazione contenuta nel dato
da un punto di vista semantico che viene poi utilizzata da numerose applicazioni del Web Semantico.
La semantica del dato determina il signicato che possiede un valore (stringa, intero, ...) attribuito
ad una proprietà del soggetto. La semantica è anche l'insieme delle proprietà logiche che sono deducibili
dai valori forniti ai vari dati.
Un modo per descrivere l'ontologia è mediante il linguaggio RDF, che si basa sul modello a triple :
una tripla è un'asserzione che consiste di un soggetto, predicato e oggetto. Analogo al linguaggio a triple
RDF è il linguaggio OWL, che permette la costruzione di una ontologia a partire dai concetti primitivi e
dai ruoli che legano tali concetti.
I due strumenti, oggetto della nostra analisi, dieriscono principalmente sulla modalità di creazione
dell'ontologia dei dati e quindi sulle procedure di interrogazione che si basano su tali modelli. In particolare D2R-Server denisce un'ontologia con un modello a triple (N3), mentre SPARQLExplorer denisce
l'ontologia con un procedimento basato sulla logica OWL.
E' però importante sottolineare che tale rappresentazione ontologica non va a sostituire il database:
l'ontologià è importante nel momento in cui vengono eettuate delle query SPARQL che si basano sulla semantica; poi le varie istanze dei dati che costituiscono la soluzione dell'interrogazione vengono recuperate
tramite il mapping generato tra la semantica del database e il relativo modello relazionale.
3
Lavori correlati
Come già detto, materia prima della nostra analisi sono gli strumenti SPARQLExplorer e D2R-Server.
Analizziamo nel dettaglio in questa sezione questi due software cui facciamo riferimento. [3, 4].
3.1
D2R-Server
Lo strumento D2R-Server viene utilizzato per la pubblicazione del contenuto dei database relazionali nel
Web semantico.
D2R-Server dà la possibilità a browser HTML (Firefox) e browser RDF (Tabulator, Disco) di navigare i contenuti di database relazionali (intrinsecamente non-RDF) pubblicati nel web, e permette alle
applicazioni di interrogare tali database usando query SPARQL (interrogazioni semantiche) attraverso lo
stesso protocollo SPARQL.
Poiché le applicazioni del Web Semantico operano su ontologie, per permettere che database relazionali, non-RDF, possano essere acceduti da applicazioni del Semantic Web occorre che venga eettuato un
mapping tra la sorgente relazionale e la rappresentazione ontologica del database.
D2RQ, utilizzato da D2R-Server, è un linguaggio di mapping adatto a questo scopo che permette
di trattare database relazionali non-RDF come dei gra RDF virtuali. Questi a loro volta sono espressi
con un linguaggio N3 che caratterizza le asserzioni con il paradigma soggetto - predicato - oggetto. Tali
asserzioni specicano come le risorse sono identicate e come i valori delle proprietà delle risorse sono
associati al contenuto di tali database.
L'elemento principale di D2RQ è il d2rq:ClassMap , il quale rappresenta il mapping da un insieme
di entità descritte all'interno del database ad una classe o un gruppo di classi simili di risorse. Ad una
classe di istanze è associato poi un particolare insieme di proprietà.
Il documento RDF generato attraverso il linguaggio D2RQ (vedi le .n3 in appendice A) , che in
denitiva descrive l'ontologia del database, viene creato utilizzando uno strumento integrato all'interno
di D2R-Server che genera un mapping a partire dalla struttura delle tabelle del database.
In questo modo, le applicazioni client del Web Semantico possono recuperare le rappresentazioni RDF
e HTML delle risorse e inoltre possono interrogare il database non-RDF attraverso query semantiche
SPARQL.
Un quadro di funzionamento generale del software è espresso in Figura 2.
Le rappresentazioni dai dati generate da D2R-Server sono fortemente interconnesse ai vari livelli RDF
e HTML in modo tale da rendere semplice e intercambiabile la navigazione del contenuto del database.
3
Figure 2: architettura D2R-Server
Infatti lo strumento fornisce una vera e propria funzione di esplorazione dei dati; in questo modo
l'utente non è più costretto a scrivere le query per ricercare le informazioni desiderate in quanto, man
mano che si esplora il database utilizzando la funzione di browsing, viene costruita automaticamente le
query SPARQL che genera l'uscita ricercata.
E' chiaro che oltre alla funzionalità di browsing per la ricerca dei dati è possibile procedere scrivendo
nel modo tradizionale query SPARQL in un apposito riquadro riservato per tale scopo.
Il risultato di tali interrogazioni, ricavato dal contenuto del database relazionale, inoltre può essere
rappresentato attraverso diversi formati tra cui quello graco/tabulare oltre che in formato XML e RDF.
3.1.1 Congurazione ed esecuzione D2R-Server
Prima di iniziare ad utilizzare l'applicazione web D2R-Server bisogna creare il le di mapping del database,
ad esempio mapping.n3 .
Per crearlo bisogna avviare il Command Line Tool compreso nel pacchetto D2R-Server semplicemente
digitando la linea di comando:
generate-mapping [-o mapping.n3] [-d driver.class.name] [-u db-user] [-p db-password]
jdbc:mysql://servername/database
Una volta creato il le, si avvia il D2R-Server in localhost attraverso la seguente linea di comando:
d2r-server mapping.n3
Per utilizzare il server bisogna connettersi alla pagina http://localhost:2020/.
In gura 3 è rappresentata la schermata di avvio del server.
Per accedere alla pagina dove è possibile interrogare il database bisogna cliccare sul link alla ne della
pagina this AJAX-based SPARQL Explorer, nel terzo riquadro.
Da qui in poi è possibile eettuare le interrogazioni utilizzando il riquadro apposito nel quale si deve
inserire la query SPARQL oppure, attraverso la funzionalità di browsing, esplorare i dati contenuti nel
database di cui si è fatto il mapping.
4
Figure 3: Home Page D2R-Server
3.2
Rosex e SPARQLExplorer
Gli strumenti Rosex e SPARQLExplorer insieme permettono di eseguire le stesse funzionalità di D2RServer.
Uno schema di funzionamento è rappresentato in Figura 4
Figure 4: architettura SPARQLExplorer
In particolare Rosex genera tre le che costituiscono la rappresentazione di un'ontologia a partire da
un database relazionale, RelationalONTO.owl, MappingONTO.owl e SemanticONTO.owl che in un certo
5
senso sostituiscono il le mapping.n3 generato da D2R-Server.
In seguito attraverso SPARQLExplorer è possibile eseguire le interrogazioni SPARQL sull'ontologia
utilizzando i le .owl creati da Rosex.
3.2.1 Rosex
Rosex é un'applicazione java che permette di rappresentare lo schema di un database in una rappresentazione ontologica.
Il sistema (Relational.OWL) che utilizza Rosex per generare l'ontologia del database è un sistema
basato sul linguaggio per ontologie OWL (Web Ontology Language).
Questo sistema estrae in modo
completamente automatico lo schema del database e genera una rappresentazione in formato ontologico
secondo lo schema riportato in gura 5
Figure 5: Relational.OWL Ontology
L'ontologia rappresenta l'informazione contenuta nelle tabelle come oggetti di tipo table, e non come
oggetti dotati di semantica, fornendogli aspetti strutturali.
Per ovviare a questo problema e rendere
l'ontologia utilizzabile dal Web Semantico viene proposto un mapping tra l'ontologia generata e una di
riferimento (target), che ne rappresenta la semantica. L'operazione di mapping è in genere una operazione
automatica, in questo caso condotta da Rosex.
In denitiva quindi, Rosex opera generando tre distinti le .owl:
•
RelationalONTO.owl
: la Relational Ontology è la rappresentazione della base di dati creata
dallo strumento Relational.OWL; il database viene rappresentato creando un'istanza della classe
table per ogni relazione presente nello schema, allo stesso modo le colonne vengono rappresentate
da istanze della classe column. Così come viene creata, questa ontologia rappresenta lo schema
della base di dati, e può virtualmente sostituirsi ad esso.
•
SemanticONTO.owl
: la Semantic Ontology contiene tutti e soli i concetti e ruoli estraibili dallo
schema relazionale della base di dati. Questo le denisce cosa contiene la base di dati (concetti e
ruoli) e non come questi sono rappresentati (tabelle e colonne). La Semantic Ontology permette
di eettuare interrogazioni basate sulla semantica (SPARQL query).
•
MappingONTO.owl
: la Mapping Ontology mantiene il riferimento tra la semantica e il formato
dei dati; viene costruita importando la Relational Ontology e la Semantic Ontology e mettendo in
relazione gli elementi di queste due categorie. Vengono mappati tutti gli elementi costruiti durante
la prima fase: concetti, ruoli e attributi, in modo da risalire alla tabella e colonna dello schema
relazionale.
6
Figure 6: DataSource Ontology
Questi tre le ontologici insieme costituiscono la Datasource Ontology (Figura 6), che viene utilizzata
dal strumento SPARQLExplorer per interrogare la base di dati a partire dalla rappresentazione semantica.
Congurazione ed esecuzione Rosex
Rosex si presenta come un le .jar (Rosex.jar), e puó
essere eseguito sia attraverso linea di comando che attraverso una IDE Java quale Eclipse.
In ogni modo per avviare lo strumento occorre impostare un le di congurazione (cong.xml) che
viene fornito come parametro d'ingresso e in cui vengono espresse delle informazioni utili all'esecuzione,
quali driver del database, DBUrl, username e password per l'accesso al DBMS.
Il le di congurazione si presenta come mostrato in gura 7
Figure 7: congRosex.xml
La linea di comando utilizzata per l'avvio di tale strumento è la seguente:
java -jar ROSEX.jar -c config/config.xml
3.2.2 SPARQLExplorer
Mentre Rosex si occupa di portare a termine la fase di estrazione semantica di un database nella relativa
ontologia semantica, SPARQLExplorer è uno strumento che sviluppa la parte di interrogazione.
Esso costituisce la componente software che si occupa di:
1. tradurre le interrogazioni SPARQL nel linguaggio del mondo relazionale.
2. wrappare i risultati per riportarli in un formato semantico.
7
Quindi volendo riassumere in grandi linee il 'core' di SPARQLExplorer è utile servirsi di una sua rappresentazione visuale (Figura 8):
Figure 8: SPARQLExplorer
Innanzitutto SPARQLExplorer è un software sviluppato in java che utilizza delle librerie particolari
quali arq.jar e jena.jar, che permettono di elaborare le funzionalità di traduzione delle query SPARQL.
Passo1.
Per tradurre le query semantiche in ingresso in linguaggio sql, è necessario che SPARQLExplorer tenga in considerazione il DataSource Ontology fornitogli da Rosex. Ciò vuol dire che
direttamente conosce il le SemanticONTO.owl su cui si basa la query SPARQL, attraverso
il MappingONTO.owl ritrova quale deve essere la rispettiva sorgente (tabella e colonna) da
cui estrarre le istanze dei dati descritti nel RelationalONTO.owl, e quindi trasforma la query
iniziale in un frammento sql che secondo le interrogazioni standard relazionali va a reperire
direttamente i dati sul database. Essendo una interrogazione sql eseguita in ambiente java
viene utilizzato lo strumento jdbc per l'interfacciamento con la base di dati.
Passo2.
Il wrapping del 'JDBCResultSet' fornito da jdbc in formato semantico ('JENAResultSet') è
eettuato grazie al metodo JenaResultSetAdapter implementato nella libreria jena.jar.
Quest'ultimo passo è essenziale per mantenere una conformità tra un'interrogazione semantica che esige
una risposta sempre basata sull'aspetto semantico.
Congurazione ed esecuzione SPARQLExplorer
L'esecuzione di SPARQLExplorer è
analoga all'esecuzione di Rosex, in quanto anche questo strumento è un'applicazione java per cui basta
mandare in esecuzione il le SPARQLExplore.jar da linea di comando oppure da Eclipse.
Anche in
questo caso è necessario compilare un le di congurazione che imposta i paramentri necessari da inviare
in ingresso allo scopo di poter eseguire correttamente le query SPARQL.
Il le di congurazione xml si presenta come mostrato in Figura 9:
La linea di comando adatta all'esecuzione dello strumento è la seguente:
java -jar SPARQLExplorer.jar -c config/config.xml "/queryPATH/queryName.txt"
8
Figure 9: congSPARQLExplorer.xml
4
Risultati sperimentali
La valutazione dei due strumenti si basa su un procedimento di confronto diretto dei risultati prodotti
dall'esecuzione di alcune query in SPARQL.
L'intento è di vericare se a fronte di una stessa interrogazione, D2R-Server e SPARQLExplorer
producono gli stessi e corretti dati in uscita.
Un giudizio complessivo deve anche tener conto della
semplicità di utlizzo e chiarezza dei risultati ad un utente esterno e quindi la capacità espressiva del
linguaggio di estrarre in modo semplice i dati di interesse.
4.1
Database di riferimeto
Il confronto delle prestazioni dei due strumenti è stato eettuato utilizzando un database ragurante il
mondo immobiliare, che abbiamo nominato unidb .
Lo schema logico di tale database è il seguente :
OWNER(IdOwner, Name, Surname, Type, Address, City, PhoneNumber)
ESTATE(IdEstate, IdOwner, Category, Area, City, Province, RoomsNumber, Bedrooms, Garage, SquareMeters, Sheet, CadastralMap)
CUSTOMER(IdCustomer, Name, Surname, Type, Budget, Address, City, PhoneNum)
AGENT(IdAgent, Name, Surname, Oce, Address, City, Phone)
AGENDA(IdAgent, Data, Hour, IdEstate, ClientName)
VISIT(IdEstate, IdAgent, IdCustomer, Date, ViewDuration)
SALE(IdEstate, IdAgent, IdCustomer, Date, AgreePrice, Status)
RENT(IdEstate, IdAgent, IdCustomer, Date, RatePrice, Status, Duration)
PICTURE(IdPicture, IdEstate, Date, Description, FileName)
4.2
Ontologie generate
I due strumenti hanno eettuato dei mapping del database dierenti.
D2R-server, come abbiamo visto in precedenza, attraverso un 'command line tool' interno al pacchetto
D2R-Server ha creato il le mapping-unidb.n3 (stralcio in appendice A).
SPARQLExplorer utilizza invece i le .owl creati preventivamente dallo strumento java ROSEX.
Da un punto di vista funzionale il le mapping-unidb.n3, e la terna di le unidbSemanticONTO.owl,
unidbRelationalONTO.owl e unidbMappingONTO.owl costituiscono la stessa informazione semantica.
9
Essi hanno lo scopo di esprimere il database
unidb
di riferimento in un formato rispettivamente RDF
e OWL, che permette di astrarre dai dettagli di implementazione e vedere lo stesso database da un punto
di vista semantico di concetti e relazioni e non da una visione di tabelle e colonne e vincoli referenziali.
È chiaro che dalla rappresentazione semantica c'è un mapping verso la rappresentazione relazionale e
viceversa, come già precedentemente è stato discusso.
L'unica dierenza che rende tali le (.n3 e .owl) così diversi sintatticamente l'uno dall'altro consiste nella diversa sintassi utilizzata per esprimere l'ontologia. D2R-Server attraverso il linguaggio D2RQ
genera una rappresentazione a grafo RDF che viene formalizzata in un linguaggio N3 (triple soggettopredicato-oggetto), mentre ROSEX (Semantic Extractor) genera la sua ontologia a partire da un linguaggio OWL-Full.
Nel paragrafo successivo verrano riportate tutte le query utilizzate per confrontare le potenzialità dei
due strumenti con i relativi risultati.
4.3
Analisi delle query in SPARQL
Per valutare come gli strumenti descritti nella sezione precedente eseguono delle interrogazioni sull'ontologia
ricavata dal database preso come riferimento, proviamo a dare in ingresso varie query espresse in SPARQL
e vericare cosa viene fornito in uscita dai due software, mettendo in evidenza le dierenze e le analogie.
Le query che abbiamo costruito hanno l'obiettivo di testare la capacità degli strumenti di riconoscere
costrutti base del linguaggio e di valutare la potenza espressiva dello strumento, intendendo con ciò la
capacità di esprimere delle interrogazioni in modo semplice e facilmente comprensibili dall'utente.
È
inoltre interessante notare se ciò che viene prodotto dalla query è eettivamente quello che l'utente si
aspetta.
Piccola premessa
: la sintassi delle query che vengono sviluppate per D2R_Server dierisce legger-
mente rispetto a quella utilizzata per SPARQLExplorer.
Ad esempio, ciò che con D2R-Server è espresso attraverso il presso vocab: si rappresenta in SPARQLExplorer con il presso uni:
semplicemente perché abbiamo dato queste convenzioni per rappre-
sentare la risorsa semantica dell'ontologia a cui accedere per reperire i dati (una sorta di vocabolario).
In secondo luogo D2R-Server accetta una notazione del tipo nomeTabella_nomeAttributo per reperire
informazioni dal mapping dell'ontologia, a dierenza di SPARQExplorer che accetta solo notazione puntata del tipo nomeTabella.nomeAttributo.
Passiamo in rassegna alcune query:
1.
Estraggo identicativo del cliente che acquista un edicio, con mappa catastale dell'immobile,
e identicativo dell'agente immobiliare:
Lo scopo della query è di valutare il comportamento del join esplicito e della proiezione su
attributi, similmente a quanto avviene nel caso di una interrogazione sql.
SELECT ?sale_date ?est_cadMap ?ag_surname ?client_name ?client_surname
WHERE {
?s rdf:type vocab:sale.
?s vocab:sale_Date ?sale_date.
?s vocab:sale_IdEstate ?s_estate.
?s_estate vocab:estate_CadastralMap ?est_cadMap.
?s vocab:sale_IdAgent ?s_agent.
?s_agent vocab:agent_Surname ?ag_surname.
?s vocab:sale_IdCustomer ?s_customer.
?s_customer vocab:customer_Name ?client_name.
?s_customer vocab:customer_Surname ?client_surname.
}
10
Figure 10: d2r-server output
Figure 11: SPARQLExplorer output
Sia D2R-Server che SPARQLExplorer producono in output lo stesso risultato alla query proposta
11
in ingresso.
Possiamo asserire che i due strumenti riescono ad estrarre in maniera corretta le
informazioni richieste quindi le funzionalità base del join esplicito tra più tabelle della base di dati
è eseguita in modo corretto. I join sono resi in maniera esplicita attraverso i vincoli di chiave esterna
che ad esempio legano sale.IdEstate con la chiave primaria di estate(estate.IdEstate).
La proiezione sugli attributi di select è corretta.
Il risultato è ciò che l'utente si aspetta anche se c'è qualche dierenza sulla formattazione e soprattutto sull'ordine dei risultati, dovuto al fatto che i due strumenti operano delle sequenze di
elaborazione diverse.
2.
Estraggo i locali venduti e attati:
Lo scopo della query è quello di valutare il comportamento dell'operatore di UNION; operatore
che permette di concatenare soluzioni e risultati da più insiemi.
La query che segue vuole mettere in evidenza la potenzialità della UNION di mettere insieme più
elementi da relazioni dierenti, ma riuscendo a mantenere e distinguere l'appartenenza di ogni
istanza alla propria relazione.
Ad esempio si estraggono tutti i locali venduti e attati, lasciando l'informazione di sale o rent per
ogni estate. Questo è possibile in D2R-Server, associando tramite UNION due query che operano
su variabili dierenti. (s-estate e r-estate )
SELECT ?sale_est_cat ?sale_est_city ?rent_est_cat ?rent_est_city
WHERE {
{
?s rdf:type vocab:sale.
?s vocab:sale_IdEstate ?s_estate.
?s_estate vocab:estate_Category ?sale_est_cat.
?s_estate vocab:estate_City ?sale_est_city.
}
UNION
{
?r rdf:type vocab:rent.
?r vocab:rent_IdEstate ?r_estate.
?r_estate vocab:estate_Category ?rent_est_cat.
?r_estate vocab:estate_City ?rent_est_city.
}
}
12
Figure 12: d2r-server output
SPARQLExplorer, per come è stato implementato non permette di usare questo costrutto in questo
modo.
La semantica su cui è stato costruito si basa sull'utilizzo tradizionale di UNION come
operatore insiemistico che non distingue l'appartenenza delle istanze ad una particolare relazione
e quindi, di base, elimina anche i duplicati.
Nel contesto di questa query è una perdita di informazioni in quanto non c'è modo di sapere
quando uno stesso locale prima è stato attato e poi venduto.
La query modicata risulta:
SELECT ?est_cat ?est_city
WHERE {
{
?s rdf:type uni:sale.
?s uni:sale.IdEstate ?estate.
?estate uni:estate.Category ?est_cat.
?estate uni:estate.City ?est_city.
}
UNION
{
?r rdf:type uni:rent.
?r uni:rent.IdEstate ?estate.
?estate uni:estate.Category ?est_cat.
?estate uni:estate.City ?est_city.
}
13
}
Le variabili ?est_cat e ?est_city sono comuni per entrambe le parti della UNION.
Figure 13: SPARQLExplorer output
Come si può notare dal confronto dei due output vengono eliminati i duplicati (trilocale Spoleto )
e non c'è più distinzione tra i locali venduti e attati.
Il problema si potrebbe risolvere estraendo delle istanze che presentano almeno una proprietà su
cui dieriscono.
Una query SQL del genere:
SELECT IdEstate, 'sale' as PType
FROM sale
UNION
SELECT IdEstate, 'rent' as PType
FROM rent
permette di inserire nel campo PType il valore stringa 'sale' o 'rent'.
Una query così non è esprimibile con SPARQL poichè non si possono inserire a run-time dei valori
stringa. Infatti SPARQL si limita ad interrogare un'ontologia estraendo un valore associato ad una
proprietà di una risorsa (un nodo dell'albero di un'ontologia). Ciò vuol dire che dovrebbe esistere
un attributo ulteriore che presenti il valore stringa sell oppure rent nella tabella rispettivamente
sell
e
rent,cosa
assolutamente assurda.
Attraverso la proprietà rdf:type (proprietà di rdf:property espressa dallo standard W3C [7] ) è
possibile per un utente conoscere la classe a cui fa riferimento una particolare istanza. Nel nostro
caso ciò vuol dire che ogni istanza di sell deve presentare un attributo
con valore sell. Analogo discorso vale per rent.
La query che eettua questa operazione:
SELECT ?est_cat ?est_city ?ptype
WHERE {
{
?s rdf:type vocab:sale.
?s vocab:sale_IdEstate ?estate.
?estate vocab:estate_Category ?est_cat.
?estate vocab:estate_City ?est_city.
?s rdf:type ?ptype
}
UNION
{
?r rdf:type vocab:rent.
?r vocab:rent_IdEstate ?estate.
?estate vocab:estate_Category ?est_cat.
?estate vocab:estate_City ?est_city.
?r rdf:type ?ptype.
}
14
?ptype
estratto da rdf:type
}
Mostriamo i risultati ottenuti con D2R-Server:
Figure 14: D2R-Server output
Con SPARQLExplorer non si ottiene un risultato migliore del precedente riportato sopra.
3.
Estraggo i locali venduti e attati da un particolare agente immobiliare:
Oltre all'operatore di UNION mettiamo in evidenza la relazione che lega un'istanza ad una
proprietà nota (la rdf:type che lega l'edicio ad un agente noto).
SELECT ?ag ?ag_surname ?estate ?est_type
WHERE {
{
?ag vocab:agent_Surname "Caio".
?estate vocab:sale_IdAgent ?ag.
?estate rdf:type ?est_type.
?ag vocab:agent_Surname ?ag_surname.
}
UNION
{
?ag vocab:agent_Surname "Caio".
?estate vocab:rent_IdAgent ?ag.
?estate rdf:type ?est_type.
?ag vocab:agent_Surname ?ag_surname.
15
}
}
Figure 15: d2r-server output
Il problema che sorge in SPARQLExplorer in questo caso è legato al fatto che per poter selezionare
il particolare operatore immobiliare Caio non posso utilizzare il costrutto abbreviato:
?ag vocab:agent_Surname "Caio".
ma occorre utilizzare l'operatore FILTER che permette la selezione di istanze per un particolare
valore letterale che si attribuisce ad una proprietà.
La query sopra diventa:
SELECT ?ag ?ag_surname ?estate ?est_type
WHERE {
{
?ag rdf:type uni:agent.
?estate uni:sale.IdAgent ?ag.
?estate rdf:type ?est_type.
?ag uni:agent.Surname ?ag_surname.
FILTER (?ag_surname = "Caio").
}
UNION
{
?ag rdf:type uni:agent.
?estate uni:rent.IdAgent ?ag.
?estate rdf:type ?est_type.
16
?ag uni:agent.Surname ?ag_surname.
FILTER (?ag_surname = "Caio").
}
}
Con il seguente output espresso da linea di comando:
Figure 16: SPARQLExplorer output
In realtà dierisce dal precedente in quanto non viene fornito il valore della variabile est_type che
denisce il tipo di appartamento (venduto/attato).
Tale informazione comunque è deducibile
dalla chiave dell'estate.
4.
Estraggo la descrizione e i le contenenti l'immagine dei loft milanesi:
Lo scopo della query è quello di valutare il comportamento dell'operatore FILTER, che consente
di eettuare una selezione delle istanze di una certa classe di risorse, basandosi sul valore di
particolari proprietà delle istanze.
SELECT ?e ?est_cat ?est_city ?descr ?fig
WHERE {
?e rdf:type vocab:estate.
?e vocab:estate_Category ?est_cat.
?e vocab:estate_City ?est_city.
FILTER (?est_cat="loft" && ?est_city="Milano").
?p vocab:picture_IdEstate ?e.
?p vocab:picture_Description ?descr.
?p vocab:picture_FileName ?fig.
}
17
Figure 17: d2r-server output
Figure 18: SPARQLExplorer output
Come si può notare, l'operatore FILTER non genera particolari problemi in quanto è un costrutto
che permette delle interrogazioni SQL Like anche se può risultare leggermente diversa la sintassi
dell'espressione regolare che c'è alla base della query SPARQL rispetto ad una generica query sql.
5.
Per tutti i locali estraggo (se sono disponibili), le descrizioni e i le immagine:
18
Lo scopo è quello di valutare il comportamento dell'operatore OPTIONAL, che permette alla
query di riportare anche una parte opzionale di informazioni se sono disponibili; in ogni modo
vengono riportate le informazioni non opzionali.
SELECT ?e ?est_cat ?est_city ?descr ?fig
WHERE {
?e rdf:type vocab:estate.
?e vocab:estate_Category ?est_cat.
?e vocab:estate_City ?est_city.
OPTIONAL {?p vocab:picture_IdEstate ?e.
?p vocab:picture_Description ?descr.
?p vocab:picture_FileName ?fig.
}
}
Figure 19: d2r-servrer output
SPARQLExplorer non fornisce un output signicativo a questa query ma lancia una exception. Ciò
è dovuto al fatto che la funzione dell'operatore OPTIONAL non è ancora stata implementata.
19
Figure 20: SPARQLExplorer output exception
6.
Estraggo l'identicativo e il cognome dell'agente, la data e l'ora in cui l'agente ha
mostrato il locale al cliente, inoltre viene estratto l'identicativoe la zona del locale,
ed il nome, cognome e il budget del cliente:
È una query costruita dopo aver popolato consistentemente il database con lo scopo di eettuare
parecchie proiezioni che coinvolgono più tabelle coinvolgendo vari tipi di join.
SELECT ?id_agent ?ag_surname ?date ?hour ?estate ?zona ?client ?client_name ?client_bud
WHERE{
?s rdf:type vocab:agenda.
?s vocab:agenda_IdAgent ?id_agent.
?id_agent vocab:agent_Surname ?ag_surname.
?s vocab:agenda_Data ?date.
?s vocab:agenda_Hour ?hour.
?s vocab:agenda_IdEstate ?estate.
?estate vocab:estate_Area ?zona.
?s vocab:agenda_ClientName ?client.
?c vocab:customer_Surname ?client.
?c vocab:customer_Budget ?client_bud.
?c vocab:customer_Name ?client_name.
}
Figure 21: d2r-server output
Attraverso il seguente costrutto
?s vocab:agenda_ClientName ?client.
?c vocab:customer_Surname ?client.
?c vocab:customer_Budget ?client_bud.
20
si è cercato di estrarre il budget del cliente presente nell'agenda utilizzando il suo cognome come
campo su cui fare il join. In questo caso agenda_ClientName non è chiave esterna.
Questa costruzione ha fatto emergere alcuni aspetti signicativi.
Con D2R-Server la query è stata eseguita ecientemente, ovvero ad ogni cliente è stato associato il
relativo budget, invece per quanto riguarda SPARQLExplorer tale operazione è stata interpretata
come l'operazione di prodotto cartesiano, che è totalmente errato, quindi è stato generato un
risultato con un numero di tuple spropositato tale per cui è impossibile visualizzare il risultato
nale.
Volendo giusticare quanto appena detto si può mostrare l'uscita di una query analoga che proietta
su un numero più limitato di attributi:
*** SPARQL query:
PREFIX rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX uni: <file:///ROSEX/result/unidbSemanticONTO.owl#>
PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>
PREFIX xsd: <http://www.w3.org/2001/XMLSchema#>
SELECT ?owner_sur ?client_bud
WHERE{
?o rdf:type uni:owner.
?o uni:owner.Surname ?owner_sur.
?c uni:customer.Surname ?owner_sur.
?c uni:customer.Budget ?client_bud.
}
La query sopra eettua un join implicito sull'attributoche non è chiave esterna.Dalla traduzione in
codice sql si comprende che non viene eettuato comunque un'operazione di join implicito, ma
al contrario un prodotto cartesiano tra 'ownwer' e 'customer'.
*** SQL query:
SELECT
owner.Surname as owner_sur,
customer.Budget as client_bud
FROM
owner,
customer
Il risultato è palesemente il prodotto cartesiano.
*** SQL results:
Figure 22: SPARQLExplorer output
21
Tale confronto porta a concludere che il costrutto di cui sopra, rappresentante l'operazione di join
su una proprietà per cui non è denita una chiave esterna, viene interpretato in maniera erronea
da SPARQLExplorer.
Per ovviare a questo problema una soluzione possibile che permette di ottenere con SPARQLExplorer lo stesso risultato ottenuto con D2R-server è la seguente query:
SELECT ?id_agent ?ag_surname ?date ?hour ?estate ?zona ?client ?client_name ?client_bud
WHERE{
?s rdf:type uni:agenda.
?s uni:agenda.IdAgent ?id_agent.
?id_agent uni:agent.Surname ?ag_surname.
?s uni:agenda.Data ?date.
?s uni:agenda.Hour ?hour.
?s uni:agenda.IdEstate ?estate.
?estate uni:estate.Area ?zona.
?s uni:agenda.ClientName ?client.
?c uni:customer.Surname ?clientSurname.
?c uni:customer.Budget ?client_bud.
?c uni:customer.Name ?client_name.
FILTER ( ?clientSurname = ?client).
}
In denitiva SPARQLExplorer eettua il join, se esplicitamente si ltrano le istanze di interesse
dal prodotto cartesiano.
Abbiamo schematizzato le dierenze per questo costrutto con l'aiuto di questa tabella:
D2R-Server
SPARQLExplorer
?s vocab:agenda_ClientName ?client.
?s vocab:agenda.ClientName ?client.
?c vocab:customer_Surname ?client.
?c vocab:customer.Surname ?clientSurname.
?c vocab:customer_Budget ?client_bud.
?c vocab:customer.Budget ?client_bud.
?c vocab:customer_Name ?client_name.
?c vocab:customer.Name ?client_name.
FILTER ( ?clientSurname = ?client).
Table 1: dierenza signicativa
5
Conclusioni e sviluppi futuri
Giunti a questo punto, siamo in grado di trarre alcune conclusioni basandosi su quanto è emerso dall'analisi
dei due strumenti.
Innanzi tutto è chiaro il quesito che era sorto inizialmente, che il linguaggio SPARQL meglio si
adatta ad eettuare delle interrogazioni su ontologie, rispetto ad un SQL che opera su dati relazionali. Si
comprende comunque, che le interrogazioni SPARQL possono essere tradotte in SQL in quanto, in ogni
modo, deve essere sempre acceduta una base di dati per recuperare i dati stessi.
Infatti, entrambi gli strumenti, operano una traduzione delle query SPARQL in SQL per recuperare
i dati, per poi fornire come output una rappresentazione semantica del risultato.
Facciamo notare inoltre che le query che abbiamo fornito in ingresso sono query principalmente relazionali e quindi non mettono molto in risalto tutte le potenzialità semantiche degli strumenti, nonostante
ciò, sono risultate sucienti per comprendere il meccanismo di traduzione in sql e wrapping del contenuto
semantico che, sta alla base del funzionamento di questi software.
Le dierenze emerse, confrontando i risultati forniti dai software, ci portano a concludere che possono
esserci delle dierenze sull'implementazione della traduzione da SPARQL in sintassi SQL. In particolare
il fatto che alcune query non forniscono il risultato atteso con SPARQLExplorer è un segnale di non
corretta traduzione di alcuni costrutti.
22
Il fatto più signicativo che ci fa dedurre ciò è il comportamento di fronte ai join impliciti. SPARQL,
infatti, virtualmente tratta tutti i join in maniera implicita, attraverso una notazione compatta; un'equivalente
costruzione in SQL deve essere trattata in maniera esplicita utilizzando cioè parametri per il join che
siano anche chiavi esterne.
Operare queste trasformazioni è in genere una possibile fonte di errore
nell'implementazione.
Si sottolinea inoltre che i due strumenti generano delle rappresentazioni ontologiche della base di dati
in formati dierenti.
Pensiamo che entrambe le rappresentazioni siano corrette ed esplicative, ma ai ni dell'esecuzione
delle query semantiche, un formalismo basato su triple si adatta di più alla sintassi SPARQL.
Dato che le interrogazioni SPARQL estraggono dei valori associati a qualche proprietà di un oggetto
?s uni:agenda.IdAgent ?id_agent), tale linguaggio è molto più adatto ad operare su le come
(
N3, costituiti da insiemi di asserzioni soggetto - predicato - oggetto, che non su le OWL basati
su formalismi logici.
Ciò non vuol dire che non si possono generare delle interrogazioni su semantiche logiche come OWL,
però sicuramente la traduzione delle query SPARQL in SQL è meno diretta.
Per concludere poniamo un interrogativo che si potrebbe considerare come un possibile sviluppo
futuro.
Ammesso che una rappresentazione ontologica in formato RDF-N3 di una base di dati meglio si
adatta ad essere interrogata con un linguaggio SPARQL, e dato che SPARQLExplorer è uno strumento
che eettua delle interrogazioni su un formato OWL dell'ontologia, ci si può chiedere se trasformare un
documento N3 (prodotto da D2R-Server) in formato OWL (utilizzabile da SPARQLExplorer) porti dei
beneci all'esecuzione delle query da parte di SPARQLExplorer.
Quindi il quesito da porsi é il seguente: è possibile riuscire a trarre dei beneci dai due strumenti e
utilizzare la rappresentazione ontologica N3 di D2R-Server come ingresso per un esecutore di query come
SPARQLExplorer?
In base a ciò che abbiamo potuto constatare, la trasformazione di un le N3 in OWL non dovrebbe
essere un impedimento, in quanto entrambi sono linguaggi per ontologie. Nonostante ciò creano l'ontologia
partendo da presupposti diversi. Il vantaggio che si potrebbe cogliere è che non si generano, in questo
caso, dei le .owl partendo da un database, ma da un le che rappresenta già un'ontologia (N3) del
database, altrimenti un' ulteriore ipotesi sarebbe quella di riadattare SPARQLExplorer in modo tale da
essere in grado di estrarre le informazioni attraverso un le N3. Però, prima di tutto, resta da esaminare
più accuratamente in SPARQLExplorer il passaggio di traduzione di una query dal formato SPARQL in
formato SQL.
23
A
File RDF generato da D2R-Server
Riportiamo uno stralcio del documento RDF in formato 'N3' generato da D2R-Server che descrive il
mapping del database in rappresentazione ontologica.
In particolare è rappresentato il mapping della tablla più rappresentativa, estate, e una tabella
importante come sale che evidenzia la presenza di join sugli attributi che costituiscono chiave
esterna.
mapping-unidb.n3
@prefix map: <file:/C:/Program Files/d2r-server-0.3.2/mapping-unidb.n3#> .
@prefix db: <> .
@prefix vocab: <http://xmlns.com/foaf/0.1/> .
@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix d2rq: <http://www.wiwiss.fu-berlin.de/suhl/bizer/D2RQ/0.1#> .
map:database a d2rq:Database;
d2rq:jdbcDriver "com.mysql.jdbc.Driver";
d2rq:jdbcDSN "jdbc:mysql://localhost/unidb";
d2rq:username "root";
d2rq:password "polimero";
.
# Table estate
map:estate a d2rq:ClassMap;
d2rq:dataStorage map:database;
d2rq:uriPattern "estate/@@estate.IdEstate@@";
d2rq:class vocab:estate;
.
map:estate__label a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property rdfs:label;
d2rq:pattern "estate #@@estate.IdEstate@@";
.
map:estate_IdEstate a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_IdEstate;
d2rq:column "estate.IdEstate";
d2rq:datatype xsd:int;
.
map:estate_IdOwner a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_IdOwner;
d2rq:column "estate.IdOwner";
d2rq:datatype xsd:int;
.
map:estate_Category a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_Category;
d2rq:column "estate.Category";
.
24
map:estate_Area a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_Area;
d2rq:column "estate.Area";
.
map:estate_City a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_City;
d2rq:column "estate.City";
.
map:estate_Province a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_Province;
d2rq:column "estate.Province";
.
map:estate_RoomsNumber a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_RoomsNumber;
d2rq:column "estate.RoomsNumber";
d2rq:datatype xsd:int;
.
map:estate_Bedrooms a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_Bedrooms;
d2rq:column "estate.Bedrooms";
d2rq:datatype xsd:int;
.
map:estate_Garage a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_Garage;
d2rq:column "estate.Garage";
d2rq:datatype xsd:int;
.
map:estate_SquareMeters a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_SquareMeters;
d2rq:column "estate.SquareMeters";
d2rq:datatype xsd:int;
.
map:estate_Sheet a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_Sheet;
d2rq:column "estate.Sheet";
d2rq:datatype xsd:int;
.
map:estate_CadastralMap a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:estate;
d2rq:property vocab:estate_CadastralMap;
25
d2rq:column "estate.CadastralMap";
.
# Table sale
map:sale a d2rq:ClassMap;
d2rq:dataStorage map:database;
d2rq:uriPattern "sale/@@sale.Date@@/@@sale.IdAgent@@/@@sale.IdCustomer@@/@@sale.IdEstate@@";
d2rq:class vocab:sale;
.
map:sale__label a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:sale;
d2rq:property rdfs:label;
d2rq:pattern "sale #@@sale.Date@@/@@sale.IdAgent@@/@@sale.IdCustomer@@/@@sale.IdEstate@@";
.
map:sale_IdEstate a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:sale;
d2rq:property vocab:sale_IdEstate;
d2rq:refersToClassMap map:estate;
d2rq:join "sale.IdEstate = estate.IdEstate";
.
map:sale_IdAgent a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:sale;
d2rq:property vocab:sale_IdAgent;
d2rq:refersToClassMap map:agent;
d2rq:join "sale.IdAgent = agent.IdAgent";
.
map:sale_IdCustomer a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:sale;
d2rq:property vocab:sale_IdCustomer;
d2rq:refersToClassMap map:customer;
d2rq:join "sale.IdCustomer = customer.IdCustomer";
.
map:sale_Date a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:sale;
d2rq:property vocab:sale_Date;
d2rq:column "sale.Date";
.
map:sale_AgreePrice a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:sale;
d2rq:property vocab:sale_AgreePrice;
d2rq:column "sale.AgreePrice";
.
map:sale_Status a d2rq:PropertyBridge;
d2rq:belongsToClassMap map:sale;
d2rq:property vocab:sale_Status;
d2rq:column "sale.Status";
.
26
References
[1] A.Magni. Relazione progetto tecnologie per i sistemi informativi., 2006.
[2] Freie Universitaet Berlin. D2r server. http://sites.wiwiss.fu-berlin.de/suhl/bizer/d2r-server/.
[3] C. Bolchini, C. Curino, E. Quintarelli, F. A. Schreiber, and L. Tanca.
Context-addict.
Technical
Report 2006.044, Dip. Elettronica e Informazione, Politecnico di Milano, 2006.
[4] C. Bolchini, C. Curino, F. A. Schreiber, and L. Tanca. Context integration for mobile data tailoring.
In Proc. 7th IEEE/ACM Int. Conf. on Mobile Data Management, pages 5.15.8, 2006.
[5] C.Bizer
and
R.Cyganiak.
D2r
server
publishing
relational
databases
on
the
semantic
web.
http://sites.wiwiss.fu-berlin.de/suhl/bizer/pub/Bizer-Cyganiak-D2R-Server-ISWC2006.pdf.
[6] L.Macagnino.
Estrazione di ontologie da basi di dati relazionali basata sulla semantica.
Master's
thesis, Politecnico di Milano - Dipartimento di Elettronica e Informazione, 2006.
[7] W3C. Rdf vocabulary description language 1.0: Rdf schema. http://www.w3.org/TR/rdf-schema/.
[8] W3C. Sparql query language for rdf. http://www.w3.org/TR/rdf-sparql-query/.
27
A
Elaborato scritto in L TEX 2ε