In questa sezione verranno delineati i requisiti che dovrà avere il sistema di tipi per SPARQL 1.1, attraverso lo studio di alcuni esempi significativi di query. L’analisi che effettueremo è volta a individuare per ciascuna query quale potrebbe essere il tipo che un sistema di tipi infe- rirebbe.
Nel nostro approccio il programmatore definisce la struttura dei dati nei grafi di input attra- verso alcuni assiomi specificati in un sotto-linguaggio di OWL2 che chiameremo ELOELOELOELO (Ex-
traLightOWL). In prima battuta diciamo che ELO include gli operatori di RDFS type, do-
main, range, SubClassOf, ma tale linguaggio verrà specificato nel dettaglio in seguito.
Gli assiomi ELO specificati dal programmatore vanno a formare uno schema chiamato ELELELO-ELO-O-O- Schema
SchemaSchema Schema.
Le query che andremo ad analizzare faranno riferimento al grafo rappresentato in Figura 6. Osserviamo che il sottografo formato dalle frecce in neretto è anche un grafo ELO che po- trebbe essere fornito al compilatore per essere usato durante l’analisi statica.
Persona viveIn Paese
Marta Andrea madreDi Italia rdfs:domain rdfs:range rdfs:subclassOf rdfs:domain rdfs:range rdfs:subclassOf rdfs:domain rdfs:range rdf:type madreDi sorellaDi viveIn Madre Lisa sorellaDi Figura 6. Grafo RDF. Donna
74
Gli assiomi ELO che corrispondono al sottografo denotato dagli archi in neretto in Figura 6 sono i seguenti:
OBJECTPROPERTYDOMAIN(viveIn,Persona)
OBJECTPROPERTYRANGE(viveIn,Paese)
OBJECTPROPERTYDOMAIN(madreDi,Madre)
OBJECTPROPERTYRANGE(madreDi,Persona)
OBJECTPROPERTYDOMAIN(sorellaDi,Donna)
OBJECTPROPERTYRANGE(sorellaDi,Persona)
CLASSASSERTION(Madre,Lisa)
SUBCLASSOF(Madre,Donna)
SUBCLASSOF(Donna,Persona)
Si ritiene molto utile, al fine di una migliore tipizzazione, che il programmatore introduca sempre tra gli assiomi tutti quelli derivanti dalla struttura rdfs. Ad esempio:
OBJECTPROPERTYDOMAIN(rdfs:subPropertyOf, rdf:Property)
OBJECTPROPERTYRANGE(rdfs:subPropertyOf, rdf:Property)
OBJECTPROPERTYDOMAIN(rdfs:subClassOf, rdfs:Class) OBJECTPROPERTYRANGE(rdfs:subClassOf, rdfs:Class)
Proseguiamo adesso analizzando diverse query per delineare i requisiti che dovrà avere il no- stro sistema di tipi.
Query generica
La query:
eseguita sul grafo di Figura 6, restituisce tutte le triple RDF che compongono il grafo. Il tipo del risultato è dato dalle variabili ?s ?p ?o con i rispettivi tipi. Dal momento che non ab-
biamo informazioni sulle variabili, in assenza di ulteriori informazioni nel grafo ci aspettiamo che:
• ?s sia di tipo e f ∪ g f • ?p sia di tipo e f
• ?o sia di tipoe f ∪ g f ∪ h]i f ovvero jk f
Query con informazioni dal dominio
La query:
eseguita sul grafo di Figura 6, restituisce il termine che rappresenta la madre di Marta. Il tipo del risultato dell’esecuzione della query è dato dal tipo della variabile ?s. In questo caso è pos-
sibile utilizzare le informazioni presenti nell’ELOSchema, in particolare se fosse presente l’asserzione OBJECTPROPERTYDOMAIN(madreDi, Madre) potremmo dedurre che la variabile ?s è di tipo Madre.
SELECT ?s ?p ?o WHERE { ?s ?p ?o }
SELECT ?s
75 Query con informazioni dal range
La query:
eseguita sul grafo di Figura 6, restituisce la lista dei termini che rappresentano i figli di Lisa. Il tipo del risultato dell’esecuzione della query è dato dal tipo della variabile ?o. In questo caso,
analogamente all’esempio precedente, è possibile utilizzare le informazioni presenti nell’ELOSchema. In particolare se fosse presente l’asserzione OBJECTPROPERTYRAN- GE(madreDi, Persona) potremmo dedurre che la variabile ?o è di tipo Persona.
Query con informazioni dal filtro
La query:
eseguita sul grafo di Figura 6, restituisce tutte le coppie di termini (madre, figlio). Il tipo del risultato dell’esecuzione della query è dato dal tipo delle variabili ?s e ?o. Un sistema di tipi
potrebbe ricavare informazioni sul tipo di ?p dal Constraint all’interno della FILTER e da
queste dedurre informazioni di tipo per ?s e ?o. In particolare il Constraint impone che ?p
sia la Iri madreDi e di conseguenza le asserzioni OBJECTPROPERTYDOMAIN(madreDi, Ma-
dre) e OBJECTPROPERTYRANGE(madreDi, Persona) ci permettono di dedurre che ?s è di ti-
po Madre e ?o è di tipo Persona.
Il sistema di tipi potrebbe anche adottare tutt’altro approccio, che è quello di non usare le uguaglianze presenti nella clausola FILTER per effettuare deduzioni. Entrambi gli approcci sono validi. Probabilmente i casi in cui da un’analisi statica di una FILTER potremmo riuscire a dedurre informazioni interessanti sui tipi sono pochi, e quindi nel nostro sistema di tipi adotteremo il secondo approccio. In particolare il sistema di tipi che svilupperemo in presenza di una FILTER verificherà solamente che l’espressione Constraint sia valida, e cioè che ritorni un valore booleano.
Query con informazioni inconsistenti
Consideriamo la seguente query eseguita sul grafo di Figura 6:
Da un punto di vista di buon senso questa query è chiaramente sbagliata, tuttavia le informa- zioni che abbiamo a disposizione dal grafo non ci permettono di dedurlo perché da quel grafo possiamo dedurre solo che ?x è una Persona e contemporaneamente una Città, ma nulla in
quel grafo ci dice che queste due informazioni siano incompatibili. Più in generale nulla in RDFS permette di dedurre una contraddizione. D’altra parte un errore di questo genere ci sembra abbastanza importante da segnalare. Quindi abbiamo deciso di introdurre in ELO, ac- canto agli operatori base di RDFS, anche l’operatore di disgiunzione tra le classi.
SELECT ?o
WHERE { Lisa madreDi ?o }
SELECT ?s ?o WHERE { ?s ?p ?o .
FILTER (?p = madreDi) }
SELECT ?x
WHERE { Lisa sorellaDi ?x . Lisa viveIn ?x }
76
Assumiamo quindi poter esprimere il fatto che Persona e Paese sono due classi disgiunte attra- verso l’asserzione DISJOINTCLASSES(Persona,Paese). Questa asserzione ci permette di rilevare
l’errore presente nella precedente query. Un altro esempio è dato dalla seguente query:
che viene eseguita sul grafo di Figura 6. Anche questa query presenta un errore analogo al pre- cedente, che possiamo rilevare utilizzando le asserzioni DISJOINTCLASSES(Persona,Paese) e SUBCLASSOF(Donna,Persona).
Tipizzazione di costanti
Prendiamo adesso in considerazione la seguente query:
che come le precedenti viene eseguita sul grafo di Figura 6. Anche in questo caso il program- matore si aspetterebbe probabilmente un errore che non viene rilevato se assumiamo un ap- proccio standard nel quale la costante Lisa non essendo stata tipizzata esplicitamente abbia
semplicemente il tipo generico. Per risolvere questo problema assumiamo di trattare le costanti come delle variabili dal punto di vista dei tipi, ovvero assumere ulteriore informazione rispetto alle costanti durante la tipizzazione.
Errori sintattici 1
La seguente query viene eseguita sul grafo di Figura 6.
Osserviamo che all’interno della query c’è un errore nella stringa Italiia. Questa query è
analoga alla query SQL:
SELECT * FROM Persone
WHERE Persone.ViveIn='Italiia'
Non sembra possibile o ragionevole cercare di rilevare questo genere di errore sintattico, per- ché non è in pratica distinguibile da una situazione in cui una query perfettamente ragionevo- le come
non ottenga nessun risultato semplicemente perché nel grafo non è presente in nessuna tripla con predicato viveIn e oggetto Italia.
Inoltre questo tipo di errore non va a influenzare il tipo di ?s, che è dato dal dominio del pre-
dicato viveIn. SELECT ?x
WHERE { ?x sorellaDi Andrea . Lisa viveIn ?x }
SELECT ?x
WHERE { Lisa madreDi ?x . ?y viveIn Lisa }
SELECT ?s
WHERE { ?s viveIn Italiia }
SELECT ?s
77 Errori sintattici 2
Consideriamo adesso la seguente query eseguita sul grafo di Figura 6:
Questa query è analoga alla query SQL:
SELECT * FROM Persone
WHERE Persone.ViveeIn='Italia'
Questo è un errore che qualunque compilatore SQL andrebbe a rilevare avendo la conoscenza completa di tutti gli attributi che esistono in una base di dati. Potremmo fare una cosa analoga nel nostro sistema se avessimo una conoscenza a priori di tutte le Iri di tutti gli archi che pos- sono apparire in un grafo. Questa conoscenza è del tutto ragionevole in molti casi, è ragione- vole aspettarsela in alcuni casi come conoscenza imposta a priori, in altri casi come conoscenza ricavata applicando uno strumento che analizza il grafo, mentre per altre applicazioni ancora, si tratta di un vincolo troppo restrittivo. Per questo motivo nel nostro sistema di tipi noi as- sumeremo che un grafo possa essere descritto o da un tipo del tutto generico oppure da un ti- po che elenca un upperbound dell’insieme di tutti i nomi di proprietà presenti nel grafo. La query dell’esempio se applicata a un grafo tipizzato in maniera generica non ritornerà alcun er- rore né alcuna informazione utile, se invece viene applicata a un grafo tipizzato attraverso un elenco del quale noi conosciamo l’upperbound, non trovando il predicato viveeIn nel grafo
ritornerà un errore.
Errori sintattici 3
Consideriamo adesso la seguente query eseguita sul grafo di Figura 6:
Questa query rappresenta un caso intermedio tra le due precedenti perché Madre è un’informazione che nasce a livello di tipi, dove potrebbe essere ragionevole immaginare la possibilità di averne un elenco esaustivo. D’altra parte le triple ?x rdf:type ?y sono viste in
RDF come triple allo stesso livello dei dati. Nel nostro approccio abbiamo deciso di adottare, nei riguardi dei tipi, un approccio in cui non viene messo a disposizione alcun meccanismo per limitare staticamente l’insieme dei tipi che possono essere nominati in una query, per cui questa query non darà un errore e il tipo Maddre verrà riflesso nel risultato come tipo inferito per la variabile ?s.
Tipo del predicato
La seguente query:
eseguita sul grafo di Figura 6 restituisce la lista di predicati che hanno come soggetto Lisa e
come oggetto Italia. Se questa query viene eseguita su un grafo sul quale non abbiamo nes-
suna informazione in quanto tipizzato in maniera generica, allora non possiamo dedurre nien-
SELECT ?s
WHERE { ?s viveeIn Italia }
SELECT ?s
WHERE { ?s rdf:type Maddre }
SELECT ?p
78
te. Se invece questa query viene eseguita su un grafo di cui conosciamo tutti i predicati
{m<}<0=..@, allora in questo caso possiamo calcolare l’intersezione tra il dominio di m< e il tipo di
Lisa, e l’intersezione tra il range di m< e il tipo di Italia. Se una di queste intersezioni è vuo-
ta, il predicato m< viene eliminato dal tipo di ?p. Come risultato finale avremo un sottoinsieme
di predicati che appaiono nel dataset, tali per cui i domini e i range sono compatibili con i tipi
Lisa e Italia, questo sarà il tipo di ?p.