SPARQLExplorer e D2RServer

Transcript

1 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:

2 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:

3 Contents 1 Introduzione 2 2 Obiettivi e Requisiti 2 3 Lavori correlati 3 31 D2R-Server Congurazione ed esecuzione D2R-Server 4 32 Rosex e SPARQLExplorer Rosex SPARQLExplorer 7 4 Risultati sperimentali 9 41 Database di riferimeto 9 42 Ontologie generate 9 43 Analisi delle query in SPARQL 10 5 Conclusioni e sviluppi futuri 22 A File RDF generato da D2R-Server 24 1

4 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 SPAR- QLExplorer 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 31) e SPARQLExplorer (sezione 32); 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

5 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] 31 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

6 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 311 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 mappingn3 Per crearlo bisogna avviare il Command Line Tool compreso nel pacchetto D2R-Server semplicemente digitando la linea di comando: generate-mapping [-o mappingn3] [-d driverclassname] [-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 mappingn3 Per utilizzare il server bisogna connettersi alla pagina 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

7 32 Rosex e SPARQLExplorer Figure 3: Home Page D2R-Server Gli strumenti Rosex e SPARQLExplorer insieme permettono di eseguire le stesse funzionalità di D2R- Server 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, RelationalONTOowl, MappingONTOowl e SemanticONTOowl che in un certo 5

8 senso sostituiscono il le mappingn3 generato da D2R-Server In seguito attraverso SPARQLExplorer è possibile eseguire le interrogazioni SPARQL sull'ontologia utilizzando i le owl creati da Rosex 321 Rosex Rosex é un'applicazione java che permette di rappresentare lo schema di un database in una rappresentazione ontologica Il sistema (RelationalOWL) 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: RelationalOWL 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: RelationalONTOowl: la Relational Ontology è la rappresentazione della base di dati creata dallo strumento RelationalOWL; 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 SemanticONTOowl: 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) MappingONTOowl: 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

9 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 (Rosexjar), 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 (congxml) 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: congrosexxml La linea di comando utilizzata per l'avvio di tale strumento è la seguente: java -jar ROSEXjar -c config/configxml 322 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

10 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 arqjar e jenajar, che permettono di elaborare le funzionalità di traduzione delle query SPARQL Passo1 Passo2 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 SemanticONTOowl su cui si basa la query SPARQL, attraverso il MappingONTOowl ritrova quale deve essere la rispettiva sorgente (tabella e colonna) da cui estrarre le istanze dei dati descritti nel RelationalONTOowl, 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 Il wrapping del 'JDBCResultSet' fornito da jdbc in formato semantico ('JENAResultSet') è eettuato grazie al metodo JenaResultSetAdapter implementato nella libreria jenajar 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 SPARQLExplorejar 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 SPARQLExplorerjar -c config/configxml "/querypath/querynametxt" 8

11 4 Risultati sperimentali Figure 9: congsparqlexplorerxml 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 41 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) 42 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-unidbn3 (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-unidbn3, e la terna di le unidbsemanticontoowl, unidbrelationalontoowl e unidbmappingontoowl costituiscono la stessa informazione semantica 9

12 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 43 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 leggermente rispetto a quella utilizzata per SPARQLExplorer Ad esempio, ciò che con D2R-Server è espresso attraverso il presso vocab: si rappresenta in SPAR- QLExplorer con il presso uni: semplicemente perché abbiamo dato queste convenzioni per rappresentare 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 nometabellanomeattributo 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

13 Figure 10: d2r-server output Figure 11: SPARQLExplorer output Sia D2R-Server che SPARQLExplorer producono in output lo stesso risultato alla query proposta 11

14 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 saleidestate con la chiave primaria di estate(estateidestate) 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

15 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:saleidestate?estate?estate uni:estatecategory?est_cat?estate uni:estatecity?est_city UNION {?r rdf:type uni:rent?r uni:rentidestate?estate?estate uni:estatecategory?est_cat?estate uni:estatecity?est_city 13

16 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?ptype estratto da rdf:type 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

17 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

18 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:saleidagent?ag?estate rdf:type?est_type?ag uni:agentsurname?ag_surname FILTER (?ag_surname = "Caio") UNION {?ag rdf:type uni:agent?estate uni:rentidagent?ag?estate rdf:type?est_type 16

19 ?ag uni:agentsurname?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

20 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

21 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

22 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 Attraverso il seguente costrutto?s vocab:agenda_clientname?client?c vocab:customer_surname?client?c vocab:customer_budget?client_bud Figure 21: d2r-server output 20

23 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: PREFIX uni: PREFIX rdfs: PREFIX xsd: < <file:///rosex/result/unidbsemanticontoowl#> < < SELECT?owner_sur?client_bud WHERE{?o rdf:type uni:owner?o uni:ownersurname?owner_sur?c uni:customersurname?owner_sur?c uni:customerbudget?client_bud La query sopra eettua un join implicito sull'attributoche non è chiave esternadalla 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 ownersurname as owner_sur, customerbudget as client_bud FROM owner, customer Il risultato è palesemente il prodotto cartesiano *** SQL results: Figure 22: SPARQLExplorer output 21