Sunteți pe pagina 1din 15

Interogri de scriere (SPARQL Update) n Sesame

Am vzut deja o interogare de scriere INSERT. n aceast seciune intrm n mai multe detalii legate de
operaiile de scriere.

Creai o baz de cunotine nou, fr a face upload de cunotine cu ecranul Add. De data aceasta vom
realiza adugri i modificri de cunotine prin interogri de scriere (numite i interogri "SPARQL
Update"). Acestea se realizeaz n ecranul SPARQL Update, cu urmtoarele consecine n privina
modului de lucru:

cnd trebuie s executai un SELECT pentru a vedea efectul unor modificri, trebuie s revenii
n ecranul Query;
ca alternativ, adesea vei putea vedea mai rapid modificrile n ecranele Export (pentru a
vedea toat baza de cunotine) sau Contexts (pentru a avea acces selectiv la grafurile pe care le
creai);

Adugarea de cunotine cu interogri SPARQL (ca alternativ la ecranul Add)

Metoda 1: Adugarea de afirmaii din fiiere on-line (direct accesibile prin HTTP)

Pentru urmtoarele exemple creai un fiier nou numit social.ttl cu urmtorul coninut:

@prefix : <http://expl.at#>.
:Anna :hasFriend :Andrew, :Peter, :Mary.
:Andrew :hasFriend :George.
:George :hasFriend :Roxanne.
De aceast dat fiierul nu este n sintax TriG, deci nu precizeaz graful n care trebuie ncrcate
afirmaiile. Vom specifica graful n interogare!

Facei acest fiier disponibil prin HTTP, prin plasarea sa n folderul rdcin pentru pagini Web gzduite
n Tomcat (Tomcat/webapps/Root). Putem verifica disponibilitatea acestuia n browser, la adresa:
http://localhost:8080/social.ttl .

n Sesame, pentru interogri de scriere (insert/update/delete) vom folosi ecranul SPARQL Update (sub
Modify) n loc de Query!
Tastai urmtoarea interogare, incluznd i prefixul (baza de cunotine fiind goal, trebuie s includem
manual prefixul, sau s l definim n prealabil n ecranul Namespaces pentru a evita tastarea sa la fiecare
interogare):
prefix : <http://expl.at#>
load <http://localhost:8080/social.ttl> into graph :FacebookRelations
Verificai acum la Contexts graful nou adugat.

Metoda 2: Adugarea de afirmaii specificate direct n interogare


S se tasteze n ecranul SPARQL Update urmtoarea comand, care creeaz 2 grafuri noi indicate explicit
n cadrul interogrii, mpreun cu coninutul lor (de aici ncolo prefixul ar putea s apar automat,
deoarece a fost detectat n fiierul uploadat cu LOAD n exerciiul anterior; dac nu apare automat n
ecranul de interogare, prefixul trebuie inclus manual ca i pn acum! 1):
insert data
{
graph :FamilyRelations
{
:MarySmith :isRelativeOf :JohnSmith.
:JohnSmith :isRelativeOf :AnnaSmith,:GeorgeParker.
}
graph :OtherData
{
:EllenSmith :hasHairColor :Red; :hasAge 20; :daughterOf :JackSmith.
:MarySmith :daughterOf :JackSmith.
}
}

S se creeze relaia isRelative n cadrul grafului FamilyRelations pentru fiecare relaie daughter gsit n
graful OtherData:
insert
{
graph :FamilyRelations {?x :isRelativeOf ?y}
}
where
{
graph :OtherData {?x :daughterOf ?y}
}

Verificai coninutul grafului FamilyRelations pentru a vedea c au aprit relaii isRelative ntre
EllenSmith i JackSmith, respectiv ntre MarySmith i JackSmith. Putei face aceast verificare:
Printr-o interogare SELECT (atenie, pentru interogri select trebuie s trecei n ecranul Query,
apoi pentru interogri de scriere revenii n ecranul SPARQL Update):
select *
from :FamilyRelations
where {?x ?y ?z}
Cu un click pe opiunea Contexts, apoi alegei graful FamilyRelations pentru a-i vedea tot
coninutul
De aici ncolo pentru oricare din operaiile de scriere verificai pe una din aceste ci succesul operaiei.

S se creeze n graful OtherData o relaie fatherOf pentru fiecare relaie daughterOf, dar cu direcia
inversat (tatl s apar ca subiect):
with :OtherData
insert
{?y :fatherOf ?x}
where
{?x :daughterOf ?y}

Verificai coninutul grafului OtherData pentru a vedea rezultatele.

Important: Acesta este un exemplu de REGUL ncorporat n interogri ("dac x e fiica lui y, y e tatl
lui x", respectiv ceva mai nainte am avut "dac x e fiica lui y, x e rud cu y").

1
Ca i pn acum, prefixul nu va fi inclus n fiecare exemplu, dar asta nu nseamn c el nu trebuie s apar!
Reamintim c regulile au rolul de a executa deducii logice, genernd afirmaii noi ("concluzii") din cele
existente. Regulile pot fi prezente fie n interogri (cazul de fa), fie sub form de axiome (vor fi
discutate ulterior).
Dac regulile sunt prezente n interogri, generarea concluziilor are loc prin executarea
interogrii (cazul de fa). Pentru aceast tehnic se folosesc:
o interogrile CONSTRUCT (caz n care afirmaiile generate sunt oferite clientului; acesta
trebuie s le salveze n baza de cunotine)
o interogrile INSERT (care se ocup de salvarea afirmaiilor generate, dar nu le ofer
clientului; acesta trebuie s le obin ulterior cu SELECT);
Dac regulile sunt prezente ca axiome, generarea concluziilor are loc fr intervenie uman
(dup cum se va vedea ulterior). Pentru aceast tehnic se folosesc terminologiile standardizate
i motoarele infereniale.

Unirea, copierea i redenumirea grafurilor

S se adauge coninutul grafului FamilyRelations n graful OtherData:


add graph :FamilyRelations to graph :OtherData
Verificai coninutul grafului OtherData pentru a observa rezultatele combinate. ADD a avut ca efect o
uniune a coninutului vechi cu cel nou n graful destinaie.

nlocuii coninutul grafului OtherData cu coninutul grafului FacebookRelations:


copy graph :FacebookRelations to graph :OtherData
Verificai coninutul grafului OtherData pentru a observa nlocuirea. Spre deosebire de ADD, COPY va
distruge coninutul existent n graful destinaie!

Mutai coninutul grafului OtherData n graful implicit (default):


move graph :OtherData to default

Observai n ecranul Contexts c nu mai exist graful OtherData! Totui afirmaiile din acesta nu s-au
pierdut. Putei verifica prin opiunea Export c ele au rmas n baza de cunotine dar nu mai au context
(nu mai aparin unui graf identificat)! Mai exact, ele aparin acum "grafului implicit". Graful implicit
(default) este un graf fr identificator, care exist n Sesame n mod implicit atunci cnd nu suntem
interesai s lucrm cu grafuri (de exemplu cnd facem upload de fiiere Turtle n loc de TriG).
Se poate considera i c MOVE funcioneaz ca o "redenumire" n acest caz, graful i-a schimbat
identificatorul din OtherData n nimic. n loc de cuvntul cheie DEFAULT se putea folosi un URI, caz n
care devine mai clar faptul c MOVE e o operaie de redenumire de grafuri (chiar dac numele su ar
putea sugera altceva).
Spre deosebire de COPY, cu MOVE se elimin att graful surs (n sensul c e "redenumit", pstrndu-i-
se ns coninutul) ct i coninutul graful destinaie (dac exista deja un graf cu noul identificator,
coninutul su va fi nlocuit, ca la COPY).

Pentru a vedea doar afirmaiile care i-au pierdut contextul (graful) se poate accesa coninutul grafului
implicit prin interogri cu clauza FROM DEFAULT:
select *
from default
where {?x ?y ?z}
Atunci cnd nu se folosete clauza FROM sau GRAPH, interogrile se execut pe toat baza de
cunotine (pe uniunea tuturor grafurilor, inclusiv cel implicit):
select *
where {?x ?y ?z}

S se mute coninutul grafului FamilyRelations n graful implicit:


move graph :FamilyRelations to default
Operaia e similar cu cea de dinainte, dar acum s-a distrus graful FamilyRelations, mutndu-i-se
coninutul n graful implicit. Cum MOVE distruge coninutul grafului destinaie, ceea ce s-a mutat mai
nainte din OtherData s-a pierdut (verificai prin opiunea Export c acum afirmaiile fr context sunt
cele care au relaia isRelative).
Acum am rmas doar cu graful FacebookRelations i cu graful implicit (cu coninutul preluat din fostul
graf FamilyRelations).

tergerea afirmaiilor cu interogri SPARQL

S se tearg o afirmaie indicat direct prin interogare:


delete data
{
graph :FacebookRelations {:George :hasFriend :Roxanne}
}
Verificai graful FacebookRelations pentru a observa faptul c o anumit afirmaie a fost tears.

Atenie la tergerile care nu specific un anumit graf! Urmtorul exemplu adaug aceeai afirmaie n
trei grafuri: dou identificate plus cel implicit:
insert data
{
graph :g1 {:Vienna :capitalOf :Austria}
graph :g2 {:Vienna :capitalOf :Austria}
:Vienna :capitalOf :Austria
}

Ai putea fi tentai s credei c urmtoarea comand va terge doar afirmaia din graful implicit:
delete data
{:Vienna :capitalOf :Austria}

n schimb, va terge afirmaiile din toate grafurile (nu va mai exista nici o afirmaie despre Viena)!
Important: dac la INSERT nu se indic graful, inserarea are loc n graful implicit (fr identificator). Dac
la DELETE nu se indic graful, tergerea este fcut n toate grafurile.

n graful FacebookRelations, s se tearg toate afirmaiile ce i au pe prietenii lui Anna drept subiect (ar
trebui s dispar o singur afirmaie avndu-l pe Andrew ca subiect):
with :FacebookRelations
delete {?x ?y ?z}
where
{:Anna :hasFriend ?x.?x ?y ?z}
Clauza WITH ofer o prescurtare pentru a indica acelai graf att n clauza de tergere ct i n clauza
WHERE. Cu alte cuvinte, aceeai interogare s-ar putea scrie i astfel:
delete
{graph :FacebookRelations {?x ?y ?z}}
where
{graph :FacebookRelations {:Anna :hasFriend ?x.?x ?y ?z}}

Este important de observat c ablonul de tergere se aplic pe rezultatele ablonului WHERE: mai nti
se selecteaz setul de cunotine {:Anna :hasFriend ?x.?x ?y ?z} i doar pe acest set are loc tergerea!

Din acest motiv urmtoarea tergere nu are niciun efect:


with :FacebookRelations
delete {?x ?y ?z}
where {:Anna :hasFriend ?x}
Motivul este c setul de cunotine obinute cu {:Anna :hasFriend ?x} nu va conine nicio afirmaie care
s aib pe ACELAI ?x ca subiect, deci {?x ?y ?z} nu va gsi nimic de ters n rezultatele ablonului
WHERE.

Modificarea afirmaiilor cu interogri SPARQL

S se nlocuiasc proprietatea hasFriend cu proprietatea knows n graful FacebookRelations:


with :FacebookRelations
delete
{?x :hasFriend ?y}
insert
{?x :knows ?y}
where
{?x :hasFriend ?y}

Observaii:
Nu este disponibil o comand UPDATE! Va trebui s folosii astfel de combinaii ntre comenzile
DELETE i INSERT!
Aceste combinaii formeaz o singur operaie i nu dou interogri succesive! De aceea nu
trebuie s v lsai indui n eroare de faptul c DELETE apare nainte de INSERT (execuia
propriu-zis are loc n ordinea invers apariiei abloanelor: mai nti selecia cu WHERE, apoi
inserarea relaiei noi, apoi tergerea relaiei vechi).

Distrugerea grafurilor cu SPARQL

S se elimine graful FacebookRelations:


drop graph :FacebookRelations
S se elimine graful implicit:
drop default
Prin eliminarea ultimelor grafuri, baza de cunotine ar trebui s rmn goal.
Alte opiuni disponibile sunt: DROP ALL (va distruge toate datele, nu o executai dect pentru a goli baze
de cunotine!)

Interogri la distan

Interogrile la distan sunt cele prin care se interogheaz prin HTTP un alt server dect cel instalat
local. De regul e vorba de un serviciu public de interogare (serviciu de tip "SPARQL endpoint"). Avem i
posibilitatea de a interoga mai multe servere simultan, caz n care vorbim de interogri federative, deci
despre baze de cunotine federative.

Un exemplu de serviciu public de interogare SPARQL este cel oferit de baza de cunotine DBPedia
(versiunea RDF a lui Wikipedia):
http://dbpedia.org/sparql

Vei folosi formularul HTML disponibil la aceast adres pentru a extrage o list cu 50 de companii:
select * where
{
?x a <http://dbpedia.org/ontology/Company>
}
limit 50
Aplicm limita de 50 pentru a evita blocarea sau ateptarea ndelungat (unele baze de cunotine
publice sunt disponibile doar pentru testare, iar interogrile cu multe rezultate pot fi respinse sau pot
avea timpi foarte mari de execuie; pentru a evita astfel de riscuri vom limita n unele cazuri numrul de
rezultate ateptat). Un click pe oricare din rezultate de afieaz fragmentul de graf ce conine afirmaiile
n care acel rezultat este subiect. Analiznd aceste rezultate putem intui forma pe care o au termenii din
DBPedia:
Exemplu de clas: http://dbpedia.org/ontology/Company;
Exemple de proprieti: http://dbpedia.org/property/sponsor, http://dbpedia.org/ontology/closeTo; cele prefixate cu
ontology sunt considerate mai generale (aplicabile la mai multe clase), cele prefixate cu property
sunt specifice unui anumit domeniu sau unei singure clase;
Exemplu de instan: http://dbpedia.org/resource/Hasbro

Pentru un studiu mai detaliat, setul de date complet poate fi downloadat de la urmtoarea adres:
http://wiki.dbpedia.org/Downloads2015-10
(este posibil ca adresa URL s se schimbe de fiecare dat cnd apare o nou versiune, de obicei de 1-2
ori pe an pentru cea mai recent versiune consultai meniul Services and Resources Datasets de pe
site-ul Dbpedia.org)

Explicaii cu privire la structura setului de date sunt oferite la:


http://wiki.dbpedia.org/services-resources/datasets/dbpedia-datasets

Explicaii cu privire la terminologie (vocabularul de clase i proprieti folosite n DBPedia) sunt oferite la
(sunt incluse acolo i linkuri pentru a descrca doar terminologia separat de restul afirmaiilor):
http://wiki.dbpedia.org/services-resources/ontology

Se ofer i posibilitatea de a naviga prin terminologie, pentru o mai bun nelegere a proprietilor ce
pot fi interogate pentru fiecare tip de resurs:
http://mappings.dbpedia.org/server/ontology/classes/

Nu vom downloada setul de date, ci vom folosi serviciul public SPARQL. Cei care fac lucrarea de licen pe
aceast tem ar putea considera integrarea unor informaii din DBPedia n propria baz de cunotine fie
prin download, fie prin interogri la distan dup cum vom exemplifica n aceast seciune.

Pentru interogarea de mai sus, am presupus cunoscut faptul c identificatorul pentru conceptul (clasa)
Company este <http://dbpedia.org/ontology/Company>. Dac nu l tim, putem solicita o list cu toate clasele
disponibile:
select ?c where
{
?x a ?c
}

Undeva n lista de rezultate putem gsi identificatorul pentru conceptul Company. Efectuai clic pe
acesta pentru a vedea proprietile afiate ntr-o pagin formatat cu HTML.

Aceast pagin permite utilizatorului s se deplaseze n cadrul grafului DBPedia prin clickuri pe
identificatorii URI (posibilitatea de a da click pe un URI pentru a obine o pagin HTML e asigurat de
mecanismul de derefereniere URI). Prin aceast navigare putem observa i ali identificatori pentru
diverse proprieti i lucruri conectate la conceptul Company.

Realizai aceeai interogare n interfaa Sesame, dar n aa fel nct Sesame s forwardeze interogarea
spre DBPedia. Sintaxa este similar cu cea n care foloseam clauza GRAPH, cu deosebirea c n loc de a
indica graful local ca i surs de date se va indica serviciul de interogare DBPedia:
select * where
{
service <http://dbpedia.org/sparql>
{?x a <http://dbpedia.org/ontology/Company>}
}
limit 50
A se observa c n aceast interogare nu folosim prefixe, deoarece am folosit URI complei.

S se obin toate afirmaiile DBPedia care au conceptul Company ca subiect sau obiect:
select * where
{
service <http://dbpedia.org/sparql>
{
{<http://dbpedia.org/ontology/Company> ?p ?o}
union
{?s ?p <http://dbpedia.org/ontology/Company>}
}
}

S se extrag toate filmele regizate de James Cameron conform DBPedia (de aici ncolo vom include
prefixe manual; ele nu pot fi detectate automat de Sesame, deoarece nu am fcut un upload de
cunotine ci folosim interfaa Sesame doar pentru a forwarda interogri spre DBPedia):
prefix db: <http://dbpedia.org/property/>
select ?t where
{
service <http://dbpedia.org/sparql>
{?dir db:name "James Cameron"@en.
?mov db:director ?dir.
?mov db:name ?t}
}

Am presupus c tim urmtoarele:


Numele de persoane i titlurile lucrurilor sunt ataate cu proprietatea <http://dbpedia.org/property/name>
Regizorii de filme sunt ataai cu proprietatea <http://dbpedia.org/property/director>
Dac nu le tim, am putea afla aceste lucruri interognd n formularul DBPedia (dbpedia.org/sparql)
informaiile legate de stringul James Cameron:
select * where
{
?x ?y "James Cameron"@en
}
n rezultatele gsite putem gsi identificatorii pentru James Cameron i proprietile acestuia.

Interogrile federative

Pentru a avea interogri federative trebuie s extragem informaii din cel puin dou servere diferite.
Pentru aceasta, pe lng DBPedia vom mai utiliza i o baz de cunotine proprie creat n Sesame, cu
informaii parial conectate la DBPedia.

ncrcai urmtorul exemplu (din fiierul awards.trig) n baza de cunotine denumit MyRepo:
@prefix : <http://expl.at#>.
:awards
{
:JamesCameron a :OscarWinner, :Director; :hasName "James Cameron"@en.
:TimBurton a :OscarNominee, :Director; :hasName "Tim Burton"@en.
:CristiPuiu a :CannesWinner, :Director; :hasName "Cristi Puiu"@en.
:StevenSpielberg a :OscarWinner, :Director; :hasName "Spielberg"@en
}
S se extrag din DBPedia titlurile filmelor regizorilor despre care n graful nostru local (awards) se tie
c au ctigat premii Oscar:

prefix : <http://expl.at#>
prefix db:<http://dbpedia.org/property/>
select ?dir ?t where
{
service <http://localhost:8080/openrdf-sesame/repositories/MyRepo>
{graph :awards {?x a :OscarWinner; :hasName ?n}}
service <http://dbpedia.org/sparql>
{?dir db:name ?n.
?mov db:director ?dir.
?mov db:name ?t}
}

A se observa c:
am atribuit prefixul db pentru proprieti DBPedia. Prefixul poate fi definit manual n Sesame
pentru a evita tastarea sa complet pe viitor (Namespaces);
serverul nostru local are o adres predefinit (<http://localhost:8080/openrdf-
sesame/repositories/MyRepo>); aceasta nseamn c Sesame nu e doar un server local de
cunotine, ci ofer i acea funcionalitate de "serviciu public de interogare" pe care o ofer i
DBPedia i care se poate accesa cu clauza SERVICE (cu meniunea c adresa serviciului conine
openrdf-sesame n loc de openrdf-workbench);
variabila comun conecteaz afirmaii din graful local cu informaiile de pe DBPedia.
Rezultatele ar trebui s ofere d titlurile lui James Cameron chiar dac l avem i pe Spielberg declarat ca
i ctigtor Oscar. Asta deoarece doar n cazul lui James Cameron numele din graful nostru este identic
cu numele stocat n DBPedia. n cazul lui Spielberg graful nostru are doar numele de familie, deci
variabila comun ?n nu va realiza potrivirea de stringuri.

Dac tim c numele folosite de noi pot fi incomplete putem aplica un filtru pentru a verifica dac
numele gsit pe DBPedia conine numele folosit n graful nostru.

prefix : <http://expl.at#>
prefix db:<http://dbpedia.org/property/>
select ?dir ?t where
{
service <http://localhost:8080/openrdf-sesame/repositories/MyRepo>
{graph :awards {?x a :OscarWinner; :hasName ?n1}}
service <http://dbpedia.org/sparql>
{?dir db:name ?n2.
?mov db:director ?dir.
?mov db:name ?t.
filter (contains(str(?n2),str(?n1)))}
}

Observai c acum folosim dou variabile diferite (?n1, ?n2) pentru a extrage numele regizorilor, apoi
aplicm un filtru cu testul contains() pentru a le compara. Acum vor fi afiate i filmele lui Spielberg. Mai
exist i alte funcii pentru procesarea stringurilor care pot fi utilizate pentru a cuta diverse similariti
ce pot apare ntre stringuri. Exist i instrumente automate de detectare a similaritii 2

2
Un instrument pentru definirea regulilor de similaritate (similarity rules) este Silk disponibil la adresa
http://wifo5-03.informatik.uni-mannheim.de/bizer/silk/
Totui, similaritatea ntre stringuri nu va garanta c avem informaii despre acelai lucru (poate sunt i
alte persoane cu numele de familieSpielberg, poate unele stringuri sunt scrise n limbi diferite i nu se
poate detecta automat similaritatea lor).

n continuare presupunem c stringurile cu nume nu sunt disponibile, sau nu ne putem baza pe ele
pentru a asigura potrivirea de nume. n general, numele nu sunt adecvate pentru a asigura identitatea,
de aceea e preferabil s folosim identificatori URI n acest scop.

Din acest motiv, n urmtorul exemplu nu ne bazm pe potrivirea de nume, ci pe reutilizarea de


identificatori oferii de DBPedia. Problema este c n graful nostru am creat deja o serie de URI pentru
regizori i nu dorim s i nlocuim (de exemplu, ar putea exista aplicaii software care depind deja de acei
URI). n acest caz, legtura trebuie s fie realizat prin crearea unei ontologii de aliniere ("alignment
ontology") care de obicei ia forma unui dicionar de echivalene ntre URI de provenien diferit (pe
lng echivalene poate include i alte relaii semantice care s asigure "traversarea" interogrilor dintr-
o baz de cunotine spre cealalt).

Urmtorul exemplu este un graf (mappings) ce conine o astfel de ontologie de aliniere, asigurnd
echivalarea ntre URI din graful nostru i cei din DBPedia. E nevoie s ncrcm acest fiier TriG
(alignment.trig) n Sesame, n aceeai baz de cunotine:

@prefix : <http://expl.at#>.
@prefix dbr: <http://dbpedia.org/resource/>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
:mappings
{
:JamesCameron owl:sameAs dbr:James_Cameron.
:TimBurton owl:sameAs dbr:Tim_Burton.
:CristiPuiu owl:sameAs dbr:Cristi_Puiu.
:StevenSpielberg owl:sameAs dbr:Steven_Spielberg
}

S se extrag lista cu regizorii din graful nostru, alturi de identificatorii lor din DBPedia precum i lista
cu titlurile acestora preluat tot din DBPedia:
prefix : <http://expl.at#>
prefix db:<http://dbpedia.org/property/>
prefix owl: <http://www.w3.org/2002/07/owl#>
select ?localdir ?dbpdir ?t where
{
service <http://localhost:8080/openrdf-sesame/repositories/MyRepo>
{
graph :awards {?localdir a :Director}
graph :mappings {?localdir owl:sameAs ?dbpdir}
}
service <http://dbpedia.org/sparql>
{?mov db:director ?dbpdir.
?mov db:name ?t}
}

Observai cum graful mappings asigur "puntea" ntre graful local awards i cunotinele accesate la
distan din DBPedia.
Remarcai c fiecare server poate s gzduiasc mai multe grafuri, iar interogrile pot s urmreasc
afirmaii ce conecteaz grafuri repartizate pe mai multe servere! Grafurile RDF distribuite pe mai multe
servere i conectate ntr-o astfel de manier, care s permit "traversarea" interogrilor de la un server
la altul, poart numele Linked Data (date conectate), fcnd astfel o distincie important fa de datele
izolate! Dac aceste grafuri sunt publice (ofer acces nerestricionat la serviciul de interogare), avem de
a face cu Linked Open Data. Dac ele sunt accesibile doar n interiorul unei organizaii i partenerii
direci ai acesteia, vorbim de Linked Enterprise Data.

Exist situaii cnd dorim s verificm dac exist informaii contradictorii n surse diferite (sau
organizaii). Pentru exemplificare, ncrcai urmtoarele afirmaii (disponibile n fiierul birth.trig) n
Sesame:
@prefix : <http://expl.at#>.
@prefix dbr: <http://dbpedia.org/resource/>.
@prefix dbo: <http://dbpedia.org/ontology/>.
:birthdata
{
dbr:Jim_Jarmusch dbo:birthPlace :Austria.
dbr:James_Cameron dbo:birthPlace dbr:Canada.
dbr:Ohio :isBirthPlaceOf dbr:Steven_Spielberg
}

Remarcai c folosim URI cunoscui din DBPedia (prefixai cu dbr sau dbo), cu dou excepii:
pentru Austria (declarat ca loc de natere pentru Jim Jarmusch)
pentru proprietatea cu care declarm locul de natere a lui Spielberg (isBirthPlaceOf).

Extragei lista cu regizorii care au locul de natere declarat att n graful nostru local ct i n DBPedia.
Pentru aceia la care se gsete dou locuri de natere diferite s se genereze un mesaj:

prefix : <http://expl.at#>
prefix dbo:<http://dbpedia.org/ontology/>
select ?dir ?bp1 ?bp2 (if(?bp1=?bp2,"valid","contradiction") as ?check)
where
{
service <http://localhost:8080/openrdf-sesame/repositories/MyRepo>
{graph :birthdata {?dir dbo:birthPlace ?bp1}}
service <http://dbpedia.org/sparql>
{?dir dbo:birthPlace ?bp2}
}

Se va afia contradicie pentru Jarmusch. James Cameron va avea mai multe rezultate deoarece DBPedia
folosete aceeai proprietate pentru a atribui ara de natere, statul sau regiunea de natere. Printre
acestea, se poate vedea rezultatul valid (dbr:Canada). Spielberg nu se regsete printre rezultate
deoarece am folosit o alt proprietate pentru a declara locul su de natere.

Pentru a include i verificarea valorilor pentru Spielberg trebuie s adugm n ontologia de aliniere o
echivalare ntre relaia dbo:birthPlace i :isBirthPlaceOf. Atenie ns, nu e vorba de o echivalare total,
cci la :isBirthPlaceOf persoana apare ca subiect i locul ca obiect, n timp ce la dbo:birthPlace poziiile
sunt inversate. Din acest motiv echivalarea nu se face cu owl:sameAs, ci cu o alt relaie standardizat,
tot din vocabularul OWL. ncrcai n Sesame fiierul cu coninutul urmtor (din fiierul inverse.trig):

@prefix : <http://expl.at#>.
@prefix dbo: <http://dbpedia.org/ontology/>.
@prefix owl: <http://www.w3.org/2002/07/owl#>.
:mappings
{:isBirthPlaceOf owl:inverseOf dbo:birthPlace}

Reamintim c ontologiile de aliniere pot conine i alte "puni" dect simpla echivalare de indivizi. n
acest exemplu avem o mapare ntre o proprietate i inversul acesteia, folosind relaia standard
owl:inverseOf. Acum putem s includem i verificarea pentru locul de natere a lui Spielberg, incluznd
noua mapare n interogare:
prefix : <http://expl.at#>
prefix dbo:<http://dbpedia.org/ontology/>
prefix owl: <http://www.w3.org/2002/07/owl#>
select ?dir ?localpl ?dbppl where
{
service <http://localhost:8080/openrdf-sesame/repositories/MyRepo>
{
graph :mappings {?invprop owl:inverseOf dbo:birthPlace}
graph :birthdata {
{?dir dbo:birthPlace ?localpl}
union
{?localpl ?invprop ?dir}
}
}
service <http://dbpedia.org/sparql>
{?dir dbo:birthPlace ?dbppl}
}

(acum comparaia ntre locul de natere gsit n DBPedia (?dbppl) i cel local (?localpl) este doar vizual;
nu am mai generat un mesaj de comparaie pentru a pstra exemplul simplu)

Exemplele oferite aici sunt nu singurele modaliti prin care putem realiza interogri federatie. n loc s
avem mai multe opiuni SERVICE/GRAPH n aceeai interogare, putem executa mai multe interogri
separat i s transmitem ntre ele valorile relevante n mod manual sau prin programare (variabile
intermediare n limbajul de programare din care executm interogrile). n continuare vom descompune
interogarea bazat pe echivalri owl:sameAs.

ntr-o prim interogare, prelum din ontologia de aliniere identificatorii DBPedia pentru regizorii din
graful nostru local:

prefix : <http://expl.at#>
prefix owl: <http://www.w3.org/2002/07/owl#>
select?dbpdir where
{
service <http://localhost:8080/openrdf-sesame/repositories/MyRepo>
{
graph :awards {?localdir a :Director}
graph :mappings {?localdir owl:sameAs ?dbpdir}
}
}

n a doua faz construim interogarea trimis ctre DBPedia (pentru obinerea filmelor) dar de data
aceasta lista de regizori o includem manual:

prefix db: <http://dbpedia.org/property/>


prefix dbr: <http://dbpedia.org/resource/>
select ?dbdir ?t where
{
service <http://dbpedia.org/sparql>
{?mov db:director ?dbdir.
?mov db:name ?t}
}
bindings ?dbdir
{
(dbr:James_Cameron)
(dbr:Tim_Burton)
(dbr:Cristi_Puiu)
(dbr:Steven_Spielberg)
}

Pentru fiecare identificator din lista BINDINGS, se va reexecuta interogarea spre DBPedia. Practic avem
un ciclu FOR inclus manual n interogare. Astfel ni se permite s descompune o interogare federativ,
ntr-o succesiune de interogri mai simple. n cazuri realiste, lista BINDINGS poate fi destul de lung i va
fi creat prin programare (concatenri ntr-un ciclu FOR), n limbajul n care se creeaz aplicaia client ce
iniiaz astfel de interogri.

Liste de servicii de interogare publice pot fi obinute pe diverse site-uri, n special pe cele care ofer
cataloage cu surse de date publice:
https://www.w3.org/wiki/SparqlEndpoints
http://labs.mondeca.com/sparqlEndpointsStatus.html
https://datahub.io/dataset?res_format=api%2Fsparql
(Datahub ncearc s centralizeze cataloage cu seturi mari de date publice, nu doar de tip RDF, dar
include i puncte de acces la servicii de interogare SPARQL)

Avertisment: Nu toate aceste servicii publice pot fi accesate din Sesame. Unele nu funcioneaz
permanent, altele funcioneaz dar nu returneaz rezultatele ntr-un format pe care Sesame s l poat
afia n propria interfa fr procesri suplimentare.
De exemplu putei testa interogri SPARQL pentru informaii geografice la http://www.geosparql.org/
ns nu putei forwarda o astfel de interogare direct din Sesame, aa cum am putut face cu DBPedia.
Aceste servicii sunt n general concepute pentru a fi accesate din programe client, aa cum vom discuta
n a doua jumtate a semestrului. DBPedia e unul din puinele servicii care ofer toate tipurile de acces
(tastare de interogare n browser, forwardare de interogare din Sesame, acces prin HTTP dinspre
programe client).

Site-ul Mondeca monitorizeaz disponibilitatea / durata de funcionare pentru serviciile de interogare


SPARQL centralizate n propriul catalog. De asemenea, ofer i descrieri RDF pentru sursele de date
catalogate, iar acestea pot fi interogate tot printr-un serviciu public (semantic.ckan.net) ce ofer
descrieri de surse de date publice folosindu-se de proprieti preluate din terminologiile standard voID i
DCTerms.

La adresele indicate mai jos putem consulta aceste terminologii, pentru a afla ce proprieti putem
include n interogarea catalogului Mondeca:

Terminologia voID poate fi consultat aici:


http://vocab.deri.ie/void
(n general se folosete pentru a descrie baze de cunotine ntr-o manier sintetic cte proprieti
ofer, cte clase, cte afirmaii, la ce adres e disponibil un serviciu public de interogare etc.)
Terminologia DCTerms poate fi consultat aici:
http://dublincore.org/documents/2012/06/14/dcmi-terms
(n general se folosete pentru a descrie orice fel de resurse informaionale prin proprieti precum:
autor, titlu, versiune, condiii de liceniere etc.)

Modul de folosire voID/DCTerms pentru a descrie surse de date n catalogul Mondeca este explicat aici:
http://labs.mondeca.com/vocab/endpointStatus/index.html

De exemplu, proprietatea void:sparqlEndpoint indic serverul pe care e disponibil o surs de date, n


timp ce proprietatea dcterms:title ofer o descriere textual a sursei de date (pentru cititori umani). Le
vom folosi pentru a extrage o list cu sursele de date din catalogul Mondeca, mpreun cu "titlurile" lor:
select distinct ?datasource ?t
where
{
service <http://semantic.ckan.net/sparql>
{
?datasource <http://rdfs.org/ns/void#sparqlEndpoint> ?server.
?datasource <http://purl.org/dc/terms/title> ?t
}
}

Putei testa interogri spre diverse surse din lista rezultat ns, dup cum am avertizat, nu toate
returneaz rezultate ntr-un format pe care Sesame s-l poat afia n mod direct, iar unele e posibil s
fie indisponibile.

Remarcai n cadrul listei c anumite surse de date folosesc stringul "sparql" n adresa URL, sugernd c
ofer un serviciu public de interogare SPARQL. Putem realiza o filtrare a acestora dup prezena
stringului "sparql" n adres:

select distinct ?datasource ?t


where
{
service <http://semantic.ckan.net/sparql>
{
?datasource <http://rdfs.org/ns/void#sparqlEndpoint> ?server.
?datasource <http://purl.org/dc/terms/title> ?t
filter contains(str(?datasource),"sparql")
}
}

Observai c e nevoie s aplicm asupra identificatorului conversie n string (STR) naintea realizrii unei
comparaii de stringuri (CONTAINS).

Putem folosi adresa serviciului ca variabil, n aceeai modalitate prin care am folosit grafurile
identificate ca variabile. n exemplul urmtor, vom lua fiecare surs de date ce conine string-ul "sparql"
n adres i vom ncerca s obinem clasele disponibile pe acele servere:
select distinct ?dataset ?c
where
{
service <http://semantic.ckan.net/sparql>
{
?dataset <http://rdfs.org/ns/void#sparqlEndpoint> ?endp.
?dataset <http://purl.org/dc/terms/title> ?t
filter contains(str(?dataset),"sparql")
}
service ?dataset
{?x a ?c}
}

Este posibil ca aceast interogare s dea eroare, dac cel puin unul dintre serverele interogate este
indisponibil. Pentru a evita aceast eroare prin ocolirea serverelor indisponibile vom aduga opiunea
SILENT:

select distinct ?dataset ?c


where
{
service <http://semantic.ckan.net/sparql>
{
?dataset <http://rdfs.org/ns/void#sparqlEndpoint> ?endp.
?dataset <http://purl.org/dc/terms/title> ?t
filter contains(str(?dataset),"sparql")
}
service silent ?dataset
{?x a ?c}
}

Opiunea SILENT este foarte important n interogrile la distan i federative pentru a evita blocaje
cauzate de servere indisponibile temporar sau permanent.