1. Universitatea „Alexandru Ioan Cuza”
Facultatea de Informatică
Interconectarea semantică a datelor în
contextul managementului informaŃiilor
personale
Iaşi, 2009
Candidat: Ecaterina Valică
Coordonator: Conf. Dr. Sabin Corneliu Buraga

2. "Revolution doesn’t happen when
society adopts new technologies – it
happens when society adopts new
behaviors."
Clay Shirky
2

3. CUPRINS
1. INTRODUCERE ................................................................................................................................5
2. DATE INTERCONECTATE ÎN CADRUL WEB-ULUI................................................................6
2.1 CONCEPTUL DE DATE INTERCONECTATE .........................................................................................6
2.2 PRINCIPII DE BAZĂ PENTRU INTERCONECTAREA DATELOR ...............................................................8
2.2.1 Arhitectura Web.......................................................................................................................9
2.2.1.1 Resurse.............................................................................................................................................. 9
2.2.1.2 Identificatori de resursă..................................................................................................................... 9
2.2.1.3 Reprezentări...................................................................................................................................... 9
2.2.1.4 DereferenŃierea URI-lor HTTP.......................................................................................................... 9
2.2.1.5 Negocierea de conŃinut ................................................................................................................... 10
2.2.1.6 Alias-uri URI .................................................................................................................................. 11
2.2.1.7 Descrieri asociate............................................................................................................................ 11
2.2.2 Modelul de date RDF ............................................................................................................12
2.2.2.1 Beneficii ale folosirii modelului de date RDF în contextul Datelor Interconectate........................ 15
2.2.2.2 Caracteristici RDF de evitat în contextul Datelor Interconectate .................................................... 15
2.3 STABILIREA LEGĂTURILOR RDF CĂTRE ALTE SURSE DE DATE.......................................................15
2.3.1 Setarea manuală a legăturilor RDF .................................................................................................... 16
2.3.2 Setarea automată a legăturilor RDF ................................................................................................... 16
2.3.3 Algoritmi bazaŃi pe tipare .................................................................................................................. 17
2.3.4 Algoritmi bazaŃi pe proprietăŃi........................................................................................................... 17
2.3.5 CerinŃe minime pentru publicarea Datelor Interconectate.................................................................. 17
2.4 TESTAREA DATELOR INTERCONECTATE ........................................................................................18
2.5 DESCOPERIREA DATELOR INTERCONECTATE ................................................................................19
3. LOGICILE DESCRIERII CA FUNDAMENT PENTRU DATELE INTERCONECTATE ....20
3.1 LOGICILE DESCRIERII ŞI SEPARAREA TBOX - ABOX ......................................................................20
3.1.1 Reprezentarea cunoştinŃelor pentru Logicile Descrierii .......................................................20
3.1.2 Maparea conceptelor DL peste formatele semantice ............................................................21
3.2 CARACTERISTICI SPECIFICE DL CU APLICABILITATE ÎN WEB-UL SEMANTIC ..................................22
3.2.1 PrezumŃia de asignare unică de nume...................................................................................22
3.2.2 Ipoteza lumilor deschise versus lumilor închise ....................................................................22
3.3 ANALOGII TBOX ŞI ABOX ÎN CADRUL DATELOR INTERCONECTATE..............................................22
3.3.1 Separarea TBox - ABox pentru Date Interconectate .............................................................23
3.3.1.1 Fenomenul de „explozie a domeniului” .......................................................................................... 24
4. STRATEGII PENTRU REPREZENTAREA, INTERCONECTAREA ŞI
INTEROPERABILITATEA DATELOR ÎN CADRUL WEB-ULUI ..............................................26
4.1 MOTIVAłIE, TRANZIłII ŞI DIRECłII PARCURSE ÎN DEZVOLTAREA INTERACłIUNILOR CU
UTILIZATORUL .....................................................................................................................................26
4.1.1 Portabilitatea datelor ............................................................................................................26
4.1.2 TranziŃii spre Cloud Computing şi sisteme de operare Web .................................................26
4.1.2.1 Software as a Service ...................................................................................................................... 26
4.1.2.2 Cloud Computing............................................................................................................................ 27
4.1.2.3 TranziŃii Web-către-desktop, desktop-către-Web ........................................................................... 29
4.1.2.4 Spre conceptul de sistem de operare Web....................................................................................... 31
4.2 ALEGEREA VOCABULARELOR POTRIVITE PENTRU REPREZENTAREA INFORMAłIEI .........................32
4.3 INTERCONECTAREA COMUNITĂłILOR ONLINE ...............................................................................33
4.3.1 FOAF – Friend of a Friend ...................................................................................................33
4.3.2 SIOC – Semantically-Interlinked Online Communities .........................................................34
4.3.2.1 Ontologia SIOC............................................................................................................................... 35
4.3.2.2 RelaŃia dintre SIOC şi alte vocabulare semantice............................................................................ 35
4.3.3 SKOS - Simple Knowledge Organisation Systems.................................................................38
4.4 INTERCONECTAREA INFORMAłIILOR PERSONALE ..........................................................................38
4.4.1 MotivaŃie................................................................................................................................38
4.4.1.1 Scenarii de utilizare ........................................................................................................................ 39
4.4.2 Managementul InformaŃiilor Personale ................................................................................40
4.4.2.1 Modelare pentru gestiunea informaŃiilor personale......................................................................... 40
4.4.2.2 Suite de aplicaŃii SaaS..................................................................................................................... 42
3

4. 4.4.2.3 Translatarea semantică a informaŃiilor............................................................................................ 42
4.4.3 Ontologii utilizate pentru Interconectarea InformaŃiei .........................................................43
4.4.3.1 Persoane şi RelaŃii........................................................................................................................... 43
4.4.3.2 PublicaŃii, Articole şi Categorii....................................................................................................... 44
4.4.3.3 Evenimente, Calendare şi LocaŃii Geografice ................................................................................. 45
4.4.3.4 Documente şi Fişiere....................................................................................................................... 46
4.4.3.5 Email-uri şi Ataşamente.................................................................................................................. 47
4.4.3.6 ConŃinut Media ............................................................................................................................... 48
5. CONCLUZII .....................................................................................................................................50
ANEXE ..................................................................................................................................................52
Anexa A: Redirectare 303 - exemplu de sesiune HTTP în cazul dereferenŃierii URI-ului unei
resurse non-informaŃionale .............................................................................................................52
Anexa B: Interconectarea şi crearea minimală a profilului FOAF .................................................53
Anexa C: Expresivitatea limbajelor DL .........................................................................................56
LISTĂ DE FIGURI ..............................................................................................................................57
ACRONIME .........................................................................................................................................58
BIBLIOGRAFIE ..................................................................................................................................60
4

5. 1. Introducere
Web-ul este o platformă dinamică şi interactivă, care oferă utilizatorilor posibilitatea de a colabora
şi de a interschimba informaŃii online. Crearea aplicaŃiilor este facilitată de colaborarea masivă între
dezvoltatorii din cadrul comunităŃilor şi de reutilizarea componentelor software, toate aceste lucruri
realizând din Web un mediu aflat într-un ritm accelerat de dezvoltare şi îmbunătăŃire, care are ca
element central utilizatorul.
Web-ul Semantic furnizează un cadru comun, care permite datelor să fie înŃelese, reutilizate şi
partajate de aplicaŃii, permiŃând calculatoarelor şi persoanelor să lucreze în cooperare. Ideea din spate
este aceea de a avea datele din cadrul Web-ului definite şi interconectate într-o manieră în care să
eficientizeze expunerea, descoperirea, automatizarea, partajarea, integrarea şi reutilizarea datelor între
aplicaŃii diverse.
Lucrarea prezintă în detaliu principiile de bază ale Datelor Interconectate, descriind mecanisme şi
strategii de crearea, furnizare, consumare, testare şi identificare a acestui tip de date.
Datorită tranziŃiei înspre sisteme de operare bazate Web, întâlnim din ce în ce mai multe suite de
aplicaŃii care acoperă majoritatea nevoilor întâlnite în cadrul desktop-ului şi care integrează toate
cerinŃele managementului informaŃiilor personale.
Tehnologiile Web-ului Semantic pot fi folosite pentru a integra informaŃiile rezultate din
activităŃile zilnice ale utilizatorilor, ca utilizarea de email-uri, calendare, managere de contacte sau de
fişiere, etc. La un nivel global, utilizatorii interacŃionează prin împărtăşirea de resurse comune, prin
comunicare şi colaborare. Toate informaŃiile generate de aceste procese sunt eterogene: datele fiind
reprezentate în diferite formate, gestionate de instrumente diverse şi aparŃinând unor domenii şi
activităŃi variate.
Scopul lucrării noastre este acela de a documenta practicile recomandate pentru integrarea
standardelor şi protocoalelor existente, pentru a permite reutilizarea şi reprezentarea informaŃiei,
portabilitatea între servici, furnizori şi instrumentele online.
Strategiile prezentate implică tranziŃia de la conceptele abstracte deŃinute de aplicaŃii către
informaŃii semantice, care pot fi înŃelese de către calculatoare. Reprezentarea modelului este primul pas
către o descriere completă. Reprezentarea se bazează în mod special pe componentele structurale ale
modelului, descriind clasele corespondente şi atributele acestora. Astfel datele conŃinute vor putea fi
ulterior integrate, chiar dacă sunt stocate în reprezentări diferite şi descrise conform a ontologii diverse.
Dorim să realizăm o ontologie de bază, care înglobează mai multe ontologii de suport, care vor
modela principalele concepte implicate în activitatea zilnică a unei persoane: locuri, organizaŃii,
persoane, documente, etc. Ontologia va facilita crearea datelor necesare pentru reprezentarea
activităŃilor întâlnite în mediul de lucru şi susŃinerea funcŃionalităŃilor aferente. Ontologia trebuie să fie
potrivită atât pentru scenarii individuale de muncă, cât şi pentru scenarii colaborative în cadrul unei
echipe sau a unei organizaŃii, iar conceptele definite trebuie să poată fi reutilizate în toate aplicaŃiile
care le necesită.
Scopul ontologiei este acela de a integra toate aceste date eterogene într-o bază de cunoştinŃe
formală, uşor de gestionat şi de distribuit altor utilizatori. Pentru a putea fi utilă pentru un anumit
individ, acest model generic trebuie să fie personalizat şi populat, prin adăugarea de noi clase şi
instanŃe concrete ale claselor existente. DorinŃa este aceea de a încorpora şi reutiliza, pe cât de mult
posibil, vocabulare deja existente, cu scopul de a evita redundanŃa şi pentru a utiliza descentralizat
descrieri de metadate specifice mai multor domenii.
Lucrarea prezintă o suită de ontologii standard pentru identificarea, reprezentarea,
interoperabilitatea, performanŃa şi managementul datelor din cadrul sistemelor informaŃionale utilizate.
Vom arăta modul în care ontologiile relaŃionează şi identifică conceptele de bază necesare
managementului informaŃiilor personale, subliniind beneficiile aduse.
5

6. 2. Date Interconectate în cadrul Web-ului
2.1 Conceptul de Date Interconectate
Web-ul este înŃeles ca un spaŃiu global al informaŃiei care conectează documente şi date. Există o
problemă totuşi cu felul în care informaŃia este interconectată în cadrul Web-ului. Se folosesc
mecanismele de bază de conectare a paginilor, dar aceste mecanisme nu specifică şi semantica sau
contextul legăturilor.
Majoritatea sit-urilor Web sunt scrise având în minte doar cititorii umani şi acest lucru tinde să
creeze informaŃie contextuală, care nu poate fi procesată în mod eficient de calculatoare. Pentru
accesarea respectivei informaŃii şi de către calculatoare s-au realizat diferiŃi algoritmi de procesare a
limbajului natural sau algoritmi care încearcă să extragă înŃeles din cadrul textelor, dar toŃi aceşti
algoritmi lucrează în jurul ideii de „recuperare” de informaŃie, nu de „citire” sau „înŃelegere” a
informaŃiei.
Cea mai bună metodă de a îmbunătăŃii acurateŃea şi relevanŃa informaŃiilor procesate este ca
furnizorii de conŃinut să reprezinte cunoştinŃele deŃinute într-o formă global înŃeleasă. Este necesară o
descriere a resurselor şi un context, care să arate în ce fel resursele sunt în relaŃie cu alte resurse.
Web-ul Semantic crează un Web al datelor prin integrarea datelor care provin din surse diferite ca:
pagini HTML1, documente XML2, foi de calcul, baze de date relaŃionale, etc. Pentru ca aplicaŃiile Web
să poată utiliza surse diferite de date trebuie ca acestea să fie componente ale unei baze de date virtuale
unificate. Acest lucru este posibil utilizând RDF3, care este un format standardizat pentru reprezentarea
datelor într-un format subiect-predicat-obiect. Acest lucru facilitează schimbul şi combinarea datelor
găsite în cadrul Web-ului, alcătuind spaŃiul Datelor Interconectate (Linked Data).
Termenul de Date Interconectate (Linked Data) a fost introdus de Tim Berners-Lee4, în 2006, în
propunerea5 sa legată de arhitectura interconectată a Web-ului. Termenul se referă la un stil de
publicare şi de interconectare a datelor structurate în cadrul Web-ului. Principala presupunere aflată în
spatele termenului este aceea că valoarea şi utilitatea datelor creşte o dată cu interconectarea acestora
cu alte date.
Principalele reguli aflate la baza Datelor Interconectate sunt:
− folosirea modelului de date RDF pentru publicarea datelor structurate pe Web;
− folosirea legăturilor RDF pentru interconectarea datelor provenite din surse diferite.
Aplicând cele două principii creăm un spaŃiu de date în cadrul Web-ului în care oamenii şi
organizaŃiile pot publica şi consuma date referitoare la orice. Acest spaŃiu este numit deseori ca Web-ul
de Date (Web of Data) sau Web-ul Semantic (Semantic Web)6.
Modul în care Web-ul Semantic funcŃionează este legat de disponibilitatea unor cantităŃi mari de
date în format RDF, care nu sunt izolate ca nişte insule, ci lucrează ca seturi de date interconectate.
Scopul Datelor Interconectate este acela de a permite oamenilor să distribuie date structurate în cadrul
Web-ului la fel de uşor ca distribuŃia de documente în lumea reală.
Termenul de Date Interconectate descrie o metodă de conectare a datelor din cadrul Web-ului
Semantic: şi anume date care sunt exprimate în format RDF. Astfel Datele Interconectate oferă un stil
de publicare a datelor în cadrul Web-ului, care pune accent pe reutilizarea acestora şi crearea de
1
http://www.w3.org/TR/html401/
2
http://www.w3.org/TR/REC-xml/
3
http://www.w3.org/RDF/
4
http://www.w3.org/People/Berners-Lee/
5
http://www.w3.org/DesignIssues/LinkedData.html
6
http://www.w3.org/2001/sw/
6

7. conexiuni între surse de date asemănătoare. Având legături între seturile de date importante este uşor de
a explora conexiunile între date.
Scopul şi viziunea Web-ul Semantic este aceea de a crea o lume de date reutilizabile. În loc de a
crea anumite informaŃii de fiecare dată, cu grade diferite de calitate a informaŃiei, Web-ul Semantic
permite crearea unică şi reutilizarea ulterioară.
RDF realizează o interoperabilitate şi o colaborare mai eficientă decât alte standarde, ca XML,
deoarece permite furnizorilor de date să încapsuleze alături de date şi înŃelesul acestora. AdiŃional, dacă
aceste date sunt interconectate, atunci datele devin uşor de descoperit. O legătură RDF doar afirmă ca o
bucată de date are o anumită relaŃie cu o alta bucată de date. Aceste relaŃii pot avea tipuri diferite. De
exemplu, o legătură RDF care conectează date despre persoane, poate afirma că doua persoane se
cunosc; o legătură RDF care conectează informaŃii despre o persoană şi publicaŃiile acesteia într-o bază
de date bibliografică, poate să afirme că acea persoană este autorul respectivei lucrări.
Proiectul Linked Open Data7 (LOD) care este o iniŃiativă a grupului W3C SWEO8 (Semantic Web
Education and Outreach) reprezintă un efort colaborativ în spiritul Web-ului Semantic, care publică
seturi de date aflate sub licenŃe deschise pe Web, în format RDF şi creează un număr mare de legături
între aceste seturi.
Figura 1 Interconectarea seturilor de date în cadrul proiectului Linked Open Data – martie 20099
7
http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData
8
http://www.w3.org/2001/sw/sweo/
9
http://www4.wiwiss.fu-berlin.de/bizer/pub/lod-datasets_2009-03-27.html
7

8. Începând cu anul 2007, numeroase seturi de date au fost publicate conform principiilor Web-ul
Semantic, descriind date din domenii diferite, ca muzică, cărŃi, informaŃii geografice, filme, persoane,
evenimente, fotografii, etc. Combinând aceste date obŃinem peste 4.5 miliarde10 de triple RDF, care
sunt interconectate cu mai mult de 180 milioane11 de legături RDF.
O dată cu acestă creştere a datelor conectate, şi numărul de aplicaŃii care doresc să le exploateze s-
a intensificat. Totuşi în ciuda faptului că în ultimii ani s-au evidenŃiat progrese în domeniul Web-ul
Semantic, având ca efect cantităŃi mari de date reprezentate în format semantic, nu există încă aplicaŃii
care să profite la maxim de avantajele acestor resurse.
Web-ul de Date poate fi accesat utilizând navigatoare speciale care ştiu să citească Date
Interconectate, în aceeaşi manieră în care tradiŃionalele documente Web sunt accesate utilizând
navigatoare HTML (HyperText Markup Language). DiferenŃa constă în faptul că în loc să urmăm
legături între pagini HTML, navigatoarele de Date Interconectate permit utilizatorilor să navigheze între
surse de date diferite folosind legături RDF (Resource Description Framework). Acest lucru permite
unui utilizator să înceapă cu o sursă de date şi apoi să se deplaseze în cadrul unui potenŃial infinit Web
de surse de date conectate prin legături RDF. De exemplu, în timp ce caută date despre o persoană în
cadrul unei surse, un utilizator ar putea fi interesat de informaŃii legate de oraşul natal al persoanei
căutate. Prin accesarea unei legături RDF, utilizatorul poate naviga către informaŃie despre acel oraş,
care se găseşte într-un alt set de date.
La fel cum tradiŃionalele documente Web pot fi parcurse cu ajutorul hiperlegăturilor, Web-ul de
Date poate fi parcurs cu ajutorul legăturilor RDF. Parcurgând aceste date, motoarele de căutare pot
furniza capabilităŃi de interogare mult mai avansate decât cele actuale, similare cu cele oferite de
convenŃionalele baze de date relaŃionale. Deoarece rezultatele interogăriilor returnează date structurate,
nu doar legături către pagini HTML, aceste date pot fi imediat procesate de către aplicaŃii specifice
Web-ul de Date.
Elementul de legătură al Web-ului tradiŃional sunt hiperlegăturile între pagini HTML. Elementul de
legătura al Web-ului de Date sunt legăturile RDF. O legătura RDF atribuie unui set de date un anumit
fel de relaŃie cu un alt set de date. Aceste relaŃii pot fi de tipuri diferite. De exemplu, o legătură RDF,
care conectează date despre persoane, poate specifica dacă două persoane se cunosc; o legătură RDF,
care conectează informaŃii despre o persoană cu informaŃii despre publicaŃii aflată într-o bază de date
bibliografică, poate preciza dacă persoana respectivă este autorul unei lucrări specifice.
Există deja o multitudine de date structurate care sunt accesibile prin utilizarea API-urilor
(Application Programming Interface) ca cele furnizate12 de eBay, Amazon, Yahoo sau Google Base.
Pentru mai multe detalii asupra modului în care se folosesc interfeŃele publice de programare a altor
aplicaŃii, se recomandă consultarea capitolului „AplicaŃii hibride: mashup-uri”13 din cartea
„Programarea în Web 2.0”.
Comparativ cu aceste API-uri, Datele Interconectate au avantajul de a furniza un mecanism
standardizat de acces în loc să deŃină diferite interfeŃe şi formate de rezultate, specifice fiecărui furnizor
de API. Acest lucru permite surselor de date să fie:
− mai uşor de indexat de motoarele de căutare,
− accesibile folosind navigatoare generice de date, şi
− permite legătura între date provenind din diferite surse de date.
2.2 Principii de bază pentru interconectarea datelor
Principiile Datelor Interconectate sunt aliniate cu arhitectura generală a Web-ului. Astfel, vom
prezenta principiile de bază ale acestei arhitecturi şi apoi vom avea o trecere în revistă asupra
10
http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets/Statistics
11
http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets/LinkStatistics
12
http://www.programmableweb.com/apis/directory
13
Ecaterina Valică, „Aplicatii hibride: mashup-uri”, pag 183-242, Sabin Buraga (ed.), „Programarea
în Web 2.0”, Polirom, Iaşi, 2007
8

9. modelului de date RDF şi a felului în care acest model trebuie folosit pentru a fi utilizat în contextul
Datelor Interconectate.
2.2.1 Arhitectura Web
Prezentăm principiile de bază ale arhitecturii Web şi introducem noŃiunile de resursă şi
reprezentare. Pentru informaŃii mai detaliate se poate parcurge recomandarea14 ConsorŃiului W3C15
(World Wide Web Consortium) asupra arhitecturii Web-ului şi activitatea grupului de cercetare W3C
Technical Architecture Group (TAG)16.
2.2.1.1 Resurse
Pentru a putea publica date în cadrul Web-ului, avem nevoie mai întâi să identificăm elementele de
interes din cadrul domeniului. Astfel, lucrurile pentru care dorim să descriem proprietăŃi şi relaŃii sunt
numite resurse, în terminologia arhitecturii Web-ului.
În articolul „Dereferencing HTTP URIs”17, publicat în cadrul grupului TAG, există o diferenŃiere
între cele două tipuri posibile de resurse: resurse informaŃionale şi resurse non-informaŃionale
(denumite şi “alte resurse”). Această diferenŃiere este importantă în contextul Datelor Interconectate.
Toate resursele pe care le găsim în cadrul Web-ului tradiŃional, cum ar fi documente, imagini sau alte
tipuri de fişiere media, sunt resurse informaŃionale. Dar multe dintre lucrurile despre care vrem să
publicăm date nu sunt: de exemplu persoane, produse fizice, locuri, concepte ştiinŃifice, etc. Ca o
regulă, toate obiectele din lumea reală, care există înafara Web-ului sunt văzute ca resurse non-
informaŃionale.
2.2.1.2 Identificatori de resursă
Resursele sunt identificate de identificatori globali numiŃi URI18 (Uniform Resource Identifier). În
contextul Datelor Interconectate, avem restricŃie de a folosi numai URI-uri HTTP19 (Hypertext Transfer
Protocol) şi de a evita alte scheme URI de genul URN20 (Uniform Resource Name) and DOI21 (Digital
Object Identifier). URI-le HTTP sunt utilizate din două motive: oferă o metodă simplă de a crea
denumiri globale unice fără a avea nevoie de un management centralizat; şi URI-le nu reprezintă numai
o modalitate de identificare, ci oferă şi posibilitatea de a accesa informaŃia despre o resursă în cadrul
Web-ului. Justificarea preferenŃei pentru URI-le HTTP în detrimentul celorlalte scheme este prezentată
pe larg în articolul “URNs, Namespaces and Registries”22.
2.2.1.3 Reprezentări
Resursele informaŃionale pot avea diferite reprezentări. O reprezentare este un flux de octeŃi într-
un anumit format, ca HTML, RDF /XML (Extensible Markup Language) sau JPEG (Joint Photographic
Experts Group). De exemplu, o factură este o resursa informaŃională. Aceasta poate fi reprezentată ca o
pagină HTML, ca un document printabil PDF (Portable Document Format) sau ca un document RDF.
O singură resursă informaŃională poate avea diferite reprezentări, în diferite formate, rezoluŃii sau
limbaje.
2.2.1.4 DereferenŃierea URI-lor HTTP
DereferenŃierea unui URI este procesul de căutare a URI-ului în cadrul Web-ului, pentru a găsi
14
http://www.w3.org/TR/webarch/
15
http://www.w3.org/
16
http://www.w3.org/2001/tag/
17
http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
18
http://tools.ietf.org/html/rfc3986
19
http://www.ietf.org/rfc/rfc2616.txt
20
http://tools.ietf.org/html/rfc2141
21
http://www.doi.org/index.html
22
http://www.w3.org/2001/tag/doc/URNsAndRegistries-50.html
9

10. informaŃii despre resursa referenŃiată. Articolul „Dereferencing HTTP URIs”23 introduce o distincŃie
asupra felului în care URI-le resurselor informaŃionale şi ale resurselor non-informaŃionale sunt
dereferenŃiate:
− Resursele informaŃionale: când un URI care identifică o resursă informaŃională este
dereferenŃiat, serverul proprietarului URI-ului generează o nouă reprezentare, un instantaneu
al stării curente a resursei informaŃionale şi trimite această reprezentare înapoi clientului
folosind codul HTTP de răspuns 200 OK .
− Resursele non-informaŃionale nu pot fi dereferenŃiate în mod direct. Astfel, arhitectura Web
foloseşte un artificiu pentru a activa identificarea URI-lor resurselor non-informaŃionale ca
fiind dereferenŃiabile: în loc să transmită o reprezentare a unei resurse, serverul trimite
clientului, URI-ul resursei informaŃionale care descrie resursa non-informaŃională, folosind
codul HTTP de răspuns 303 See Other. Acest proces se numeşte o redirectare 303. În al doilea
pas, clientul dereferenŃiază noul URI şi primeşte reprezentarea care descrie resursa non-
informaŃională originală.
Notă: există două abordări pe care furnizorii de date le pot folosi pentru a furniza clienŃilor URI-uri
ale resurselor informaŃionale care descriu resurse non-informaŃionale: Hash URI şi redirectări 303. În
această lucrare prezentăm doar abordarea cu redirectări 303. Pentru comparaŃii între cele două variante
a se vedea SecŃiunea 4.3 din lucrarea “Cool URIs for the Semantic Web”24.
2.2.1.5 Negocierea de conŃinut
Navigatoarele HTML afişează de obicei reprezentările RDF în mod simplu, neprelucrat, sau doar
salvează respectivele fişierele RDF fără a le afişa. Acest lucru nu este foarte folositor pentru utilizatori.
Astfel, oferirea unui reprezentări RDF împreună cu o reprezentare adiŃională HTML a resursei cerute,
ajută utilizatori să identifice / folosească mai uşor referinŃa URI.
Acest lucru poate fi obŃinut folosind un mecanism HTTP numit negociere de conŃinut.ClienŃii
HTTP trimit antete HTTP pentru fiecare cerere pentru a indica ce tip de reprezentare preferă. Serverele
vor inspecta aceste antete şi vor selecta un răspuns potrivit, conform cererii. Dacă antetul indică faptul
că respectivul client preferă HTML, atunci serverul va genera o reprezentare HTML. Dacă clientul
preferă RDF, atunci serverul va genera RDF.
Negocierea conŃinutului pentru resurse non-informaŃionale este implementată în maniera
următoare: Când un URI care identifică o resursă non-informaŃională este dereferenŃiat, serverul trimite
o redirectare 303 către o resursă informaŃională corespunzătoare. Astfel, o sursă de date de obicei
serveşte trei URI-uri corespunzătoare unei resurse non-informaŃionale, de exemplu:
− http://dbpedia.org/resource/Romania (URI care identifică resursa non-informaŃională
România)
− http://dbpedia.org/data/Romania (resursa informaŃională care descrie România în format RDF)
− http://dbpedia.org/page/Romania (resursa informaŃională care descrie România în format
HTML)
Următoarea figură arată felul în care dereferenŃierea unui URI HTTP, care identifică o resursă non-
informaŃională, este legată de negocierea conŃinutului:
1. Utilizatorul realizează o cerere HTTP GET pentru un URI care identifică o resursă non-
informaŃională, în cazul nostru „resource/Romania”. Dacă utilizatorul deŃine un navigator de Date
Interconectate şi preferă o reprezentare RDF/XML pentru resursă, acesta trimite un antet Accept:
application/rdf+xml împreună cu cererea. Navigatoarele HTML vor trimite un antet de tipul
Accept: text/html;
2. Serverul recunoaşte URI-ul ca identificând o resursă non-informaŃională. Din cauză că
serverul nu poate returna o reprezentare a acestei resurse, el va răspunde folosind codul de răspuns
HTTP 303 See Other şi va trimite navigatorului URI-ul resursei informaŃionale care descrie resursa
23
http://www.w3.org/2001/tag/doc/httpRange-14/2007-05-31/HttpRange-14
24
http://www.w3.org/TR/2007/WD-cooluris-20071217/
10

11. non-informaŃională. În cazul reprezentărilor RDF va trimite locaŃia conŃinutului fişierului RDF
care descrie resursa, respectiv http://dbpedia.org/data/Romania;
3. Navigatorul va cere serverului să primească (în stil GET) reprezentarea respectivei resurse
informaŃionale, cerând iar application/rdf+xml;
4. Serverul trimite navigatorului un document RDF/XML care conŃine o descriere a resursei
originale cerute.
Figura 2 Redirectare 303 în cazul derefenŃierii URI-ului unei resurse non-informaŃionale25
Un exemplu complet de sesiune HTTP pentru dereferenŃierea unui URI identificând o resursă non-
informaŃională poate fi consultat în Anexa A.
2.2.1.6 Alias-uri URI
Într-un mediu deschis ca Web-ul se întâmplă adesea ca diferiŃi furnizori de informaŃii să ofere
informaŃii despre aceeaşi resursă non-informaŃională, de exemplu o locaŃie geografică sau o persoană
cunoscută. Cum furnizorii nu ştiu unii de alŃii, ei vor introduce URI-uri diferite pentru a identifica
acelaşi obiect real. De exemplu: DBpedia26, care furnizează surse de date extrase din cadrul
Wikipedia27, foloseşte URI-ul http://dbpedia.org/page/Iaşi pentru a identifica oraşul Iaşi. Există, tot în
cadrul DBpedia, un alt alias şi anume http://dbpedia.org/page/Iassy, care redirectează către celalalt URI
DBpedia, mai cuprinzător. Geonames28, o sursă de date care furnizează informaŃii despre milioane de
locaŃii geografice, utilizează URI-ul http://www.geonames.org/675810 pentru a identifica Iaşi-ul.
Deoarece cele trei URI-uri prezentate fac referinŃă la aceeaşi resursă non-informaŃională, ele sunt
numite alias-uri URI. Alias-urile URI sunt des întâlnite în Web-ul de Date, deoarece este puŃin probabil
ca toŃi furnizorii de date să cadă de acord asupra aceluiaşi URI, care să identifice o resursă non-
informaŃională. Alias-urile URI furnizează o funcŃie socială importantă în cadrul Web-ul de Date
deoarece permite dereferenŃierea către diferite descrieri ale aceleiaşi resurse non-informaŃionale şi
astfel, permit exprimarea a diverse opinii şi perspective legate de o resursă.
Pentru a putea stabili dacă furnizorii de informaŃie vorbesc despre aceeaşi resursă non-
informaŃională, se obişnuieşte ca furnizorii să stabilească o legătură owl:sameAs29 către toate alias-urile
URI pe care aceştia le cunosc. Pentru căutarea URI-urilor echivalente existente în cadrul Web-ului se
poate folosi motorul de căutare SameAs30.
2.2.1.7 Descrieri asociate
Termenul „descrieri asociate”31 se referă la descrierea unei resurse non-informaŃionale pe care un
utilizator o obŃine prin dereferenŃierea unui URI al respectivei resurse non-informaŃionale. De exemplu:
25
http://www.w3.org/TR/swbp-vocab-pub/img/deref-ont-uri-rdf.png
26
http://dbpedia.org/
27
http://www.wikipedia.org/
28
http://www.geonames.org/
29
http://www.w3.org/TR/owl-ref/#sameAs-def
30
http://sameas.org
31
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/
11

12. dereferenŃierea URI-ului http://dbpedia.org/resource/Bucharest cu menŃiunea ca la returnare să obŃinem
un răspuns de tipul application/rdf+xml, după o redirectare, oferă o descriere asociată, care este aceeaşi
cu descrierea RDF a URI-ului http://dbpedia.org/resource/Bucharest din cadrul resursei informaŃionale
http://dbpedia.org/data/Bucharest. Folosirea termenului „descrieri asociate” are sens în contextul
Datelor Interconectate deoarece este o practică întâlnită utilizarea mai multor alias-uri URI pentru a
face referinŃă către aceeaşi resursă non-informaŃională şi deoarece diferite alias-uri URI dereferenŃiază
către descrieri diferite ale respectivei resursei.
2.2.2 Modelul de date RDF
Atunci când publicăm Date Interconectate în cadrul Web-ului, de fapt reprezentăm informaŃie
despre resurse folosind Resource Description Framework32 (RDF). RDF furnizează un model de date
care este simplu şi uşor de integrat în arhitectura Web-ului actual.
În RDF, o descriere a unei resurse este reprezentată de un număr de triple. Cele trei componente
ale unei triple sunt numite subiect, predicat şi obiect. Un triplu reflectă structura de bază a unei
propoziŃii simple, cum ar fi aceasta:
Ecaterina are adresa de e-mail evalica@infoiasi.ro .
(subiect) (predicat) (obiect)
Subiectul unui triplu este URI-ul care identifică resursa descrisă. Obiectul poate fi ori o simplă
valoare de literal, cum ar fi un număr, o dată, un şir de caractere; sau URI-ul unei alte resurse care este
relaŃionată într-un fel cu subiectul. Predicatul indică ce fel de relaŃie este între subiect şi obiect, de
exemplu dacă relaŃia reprezină un nume, o dată de naştere (în cazul unui literal); un angajator sau o
persoana cunoscută (în cazul unei alte resurse). Predicatul este de asemenea un URI. Aceste URI-uri de
predicate provin din vocabulare, colecŃii de URI-uri, care sunt utilizate pentru a reprezenta informaŃia
referitoare la un anumite domeniu.
Anumitor persoane le este mai uşor să-şi imagineze un set de triple RDF ca un graf RDF. URI-
urile referitoare la subiect şi la obiect sunt noduri în cadrul grafului, iar fiecare triplă este un arc direct
care conectează subiectul cu obiectul.
Exista două tipuri de triple RDF care pot fi identificate, Triple de Literali (Literal Triples) şi
Legături RDF (RDF Links):
− Triplele de literali au ca obiect un literal RDF de tipul şir de caractere, un număr, o dată.
Triplele de literali sunt folosite pentru a descrie proprietăŃi ale resurselor, de exemplu pentru a
descrie numele sau ziua de naştere a unei persoane.
− Legăturile RDF reprezintă legături între două resurse. Legăturile RDF consistă din trei
referinŃe URI. URI-urile din cadrul subiectului şi al obiectului identifică resursele interconectate.
URI-ul predicatului defineşte tipul legăturii. De exemplu, o legătură RDF poate specifica că o
persoană este angajată a unei organizaŃii, în timp ce altă legătură RDF poate afirma că acea
persoana cunoaşte o altă persoană.
Legăturile RDF sunt fundaŃia Web-ului de Date. Prin dereferenŃierea URI-ului, care apare ca
destinaŃie a unei legături, rezultă descrierea resursei conectate. Această descriere conŃine de obicei
legături adiŃionale RDF, care indică către alte URI-uri, care la rândul lor pot fi dereferenŃiate, etc.
Acesta este felul în care descrierile resurselor individuale sunt publicate în Web-ul de Date. De
asemenea, acesta este modul în care Web-ul de Date poate fi explorat cu un navigator sau parcurs
motoarele de căutare semantice.
Tabulator33, Marbles34 sau Disco35 sunt exemple de navigatoare RDF. În exemplul următor,
navigatorul va afişa informaŃii despre resursele extrase din profilul FOAF36 (Friend of a Friend), creat
şi explicat în Anexa B.
32
http://www.w3.org/TR/rdf-concepts/
33
http://www.w3.org/2005/ajar/tab
34
http://dbpedia.org/Marbles
12

13. Figura 3 Modul de afişare a datelor conŃinute de un profil FOAF de către navigatorul Disco
Persoana descrisă de profil este Ecaterina Valică, identificată cu URI-ul
http://students.info.uaic.ro/~evalica/foaf.rdf#evalica. Prin introducerea respectivei adresei în navigator
se va dereferenŃia URI-ul, cerând conŃinut de tip application/rdf+xml şi se vor afişa informaŃiile
primite. În profilul respectiv, Ecaterina a afirmat că locuieşte undeva în apropierea oraşului Iaşi,
folosind URI-ul DBpedia http://dbpedia.org/resource/Iaşi ca alias URI pentru resursa non-
informaŃională Iaşi. În cazul în care se doresc mai multe informaŃii despre oraşul Iaşi, se poate
dereferenŃia URI-ul corespunzător resursei Iaşi. Navigatorul va realiza acest lucru cerând conŃinut de
tip application/rdf+xml.
Figura 4 InformaŃii despre resursa http://students.info.uaic.ro/~evalica/foaf.rdf#evalica
După ce a fost redirectat un cod de răspuns HTTP 303, navigatorul primeşte un graf RDF care
descrie oraşul Iaşi în detaliu. O parte din acest graf este prezentat mai jos. Graful conŃine un triplu
literal care afirmă că Iaşi-ul are peste 300.000 de locuitori şi, de asemenea, este oferită şi o legătură
35
http://sites.wiwiss.fu-berlin.de/suhl/bizer/ng4j/disco/
36
http://www.foaf-project.org/
13

14. RDF spre o resursă care reprezintă lista celorlalte municipii din România.
Figura 5 Interconectarea cu informaŃiile resursei http://dbpedia.org/resource/Iaşi
Prin dereferenŃierea URI-ului care identifică lista municipiilor, se va opŃine un nou graf RDF, care
conŃine legături RDF către diferite oraşe româneşti, de exemplu Bucureşti şi Suceava. Toate
informaŃiile converg în cadrul unui graf virtual unitar.
Figura 6 Interconectarea resursei http://dbpedia.org/resource/Category:Municipalities_of_Romania
Dacă observăm aceste lucruri dintr-o perspectivă a Datelor Interconectate, cele mai valoroase
legături RDF sunt acelea care conectează o resursă către date externe, publicate de alte surse de date.
Tehnic, o astfel de legătură externă RDF este de fapt un triplu RDF care are un subiect URI dintr-o
sursă de date şi un obiect URI din altă sursă de date. Mai jos sunt date câteva exemple de legături RDF
externe, prezentate în formatul Turtle37 RDF:
<http://students.info.uaic.ro/~evalica/foaf.rdf#evalica>
foaf:knows <http://profs.info.uaic.ro/~busaco/busaco.foaf.xml#me> ;
foaf:interest <http://dbpedia.org/resource/Semantic_Web> .
<http://dbpedia.org/resource/Iaşi>
owl:sameAs <http://sws.geonames.org/675810/> .
37
http://www.w3.org/TeamSubmission/turtle/
14

15. 2.2.2.1 Beneficii ale folosirii modelului de date RDF în contextul Datelor
Interconectate
Principalele beneficii38 aduse de utilizarea modelului de date RDF în contextul Date Interconectate
sunt:
− utilizatorii, pentru a opŃine informaŃii adiŃionale, pot căuta orice URI într-un graf RDF în
cadrul Web-ului;
− informaŃiile din surse diferite se îmbină în mod natural;
− modelul de date permite crearea de legături RDF între date care provin din surse diferite;
− modelul de date permite reprezentarea informaŃiei provenită din scheme diferite în cadrul unui
singur model;
− combinând cu limbaje de reprezentare de cunoştiinŃe ca RDF-S39 (RDF Schema) sau OWL40
(Web Ontology Language), modelul de date permite utilizarea unei structuri minimale pentru
reprezentarea datelor structurate sau semi-structurate.
2.2.2.2 Caracteristici RDF de evitat în contextul Datelor Interconectate
Pentru a fi uşor de interogat şi interconectat date, se recomandă41 neutilizarea expresivităŃii totale
care poate fi oferită de modelul de date RDF, ci doar utilizarea unui subset de caracteristici RDF,
precum:
− este descurajata folosirea nodurilor blank42. Nu este posibil atribuirea de legături RDF externe
către noduri blank, astfel îmbinarea datelor din surse diferite devenind mult mai dificilă atunci
când acest tip de noduri sunt folosite. Se recomandă ca toate resursele care au o anumită
importanŃă în cadrul setului de date să fie numite folosind referinŃe URI;
− este descurajată folosirea reificaŃiei RDF43 deoarece semantica de reificare este neclară şi
declaraŃiile reificate sunt dificil de interogat folosind limbajul SPARQL44 (SPARQL Protocol and
RDF Query Language). Ca alternativă, se pot ataşa metadate informaŃiei;
− trebuiesc folosite cu atenŃie colecŃiile RDF45 sau containerele RDF46 deoarece nu funcŃionează
eficient împreună cu SPARQL. În cazul în care se doreşte înlocuirea unei colecŃii sau un container
este suficient ca informaŃia să fie exprimată folosind triple multiple care au acelaşi predicat. În
această manieră, interogăriile SPARQL devin directe.
2.3 Stabilirea legăturilor RDF către alte surse de date
Legăturile RDF permit navigatoarelor concepute pentru Datele Interconectate să acceseze surse de
date şi să descopere date adiŃionale.
Domeniul aplicaŃiei va determina ce tip de proprietăŃi RDF sunt folosite ca predicate. De exemplu,
pentru a descrie proprietăŃi de legătură între persoane se pot utiliza foaf:knows, foaf:based_near şi
foaf:interest.
Este des întâlnit ca proprietatea owl:sameAs să fie folosită pentru a afirma că şi altă sursă de date
furnizează informaŃii despre o anume resursă non-informaŃională. O legătură owl:sameAs indică că
38
http://www.mkbergman.com/?p=483
39
http://www.w3.org/TR/rdf-schema/
40
http://www.w3.org/TR/owl-ref/
41
http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/#datamodel
42
http://www.w3.org/TR/rdf-concepts/#section-blank-nodes
43
http://www.w3.org/TR/rdf-mt/#Reif
44
http://www.w3.org/TR/rdf-sparql-query/
45
http://www.w3.org/TR/rdf-mt/#collections
46
http://www.w3.org/TR/rdf-mt/#Containers
15

16. două URI fac referinŃă la acelaşi lucru. Astfel, owl:sameAs este folosit pentru a mapa alias-uri URI. Un
exemplu care foloseşte owl:sameAs pentru a indica două URI-uri care vorbesc despre acelaşi lucru este
profilul FOAF a lui Tim Berners-Lee47, care afirmă că http://www.w3.org/People/Berners-Lee/card#i
identifică aceeaşi resursă ca http://www4.wiwiss.fu-berlin.de/bookmashup/persons/Tim+Berners-Lee şi
http://www4.wiwiss.fu-berlin.de/dblp/resource/person/100007. Legăturile owl:sameAs vor oferi
ulterior „indicii” sistemelor de inferenŃă (reasoners48), asupra modului în care datele trebuiesc să fie
unificate.
Legăturile RDF pot fi setate manual, cazul profilurilor FOAF, sau pot fi generate automat folosind
diferiŃi algoritmi. Ultima abordare este folosită pentru a interconecta seturi de date foarte mari.
2.3.1 Setarea manuală a legăturilor RDF
Înainte de a seta manual legături RDF trebuie să avem cunoştinŃe despre seturile de date către care
dorim să realizam respectivele legături. Pentru a avea o viziune generală a diferitelor seturi de date care
pot fi folosite pentru a conecta obiecte de interes se poate consulta lista49 seturilor de Date
Interconectate. O dată identificate seturi de date particulare ca fiind Ńinte potrivite pentru conectare, se
pot cauta manual, în aceste seturi de date, referinŃele URI către care dorim legături. Dacă sursa de date
nu oferă o interfaŃă de căutare, de exemplu o consolă SPARQL sau un formular HTML, se pot utiliza
navigatoare ca Tabulator50 sau Disco 51pentru a explora seturile de date şi pentru a găsi URI-urile
necesare.
Se pot folosi servicii ca Uriqr52 sau Sindice53 pentru a căuta URI-uri existente şi alege cel mai
popular URI din cadrul a mai mulŃi candidaŃi. Uriqr permite găsirea URI-urilor pentru persoane
cunoscute, doar utilizând numele acestora. Rezultatele sunt clasificate în funcŃie de gradul de
dereferenŃiere al URI-urilor în cadrul documentelor RDF, dar totuşi alegerea celui mai potrivit URI nu
depinde numai de acest lucru. Sindice indexează Web-ul Semantic şi ştie ce surse menŃionează anumite
URI-uri. Astfel, acest serviciu poate ajuta la alegerea celor mai populare URI-uri pentru un anumit
concept.
De reŃinut este faptul că sursele de date pot folosi redirectări HTTP-303 pentru a direcŃiona clienŃi
de la URI-uri, care identifică resurse non-informaŃionale, către URI-uri, care identifică resurse
informaŃionale, care descriu resurse non-informaŃionale În acest caz, trebuie avut grijă de a face
legătura cu URI-ul care referenŃiază resursa non-informaŃională şi nu cu documentul care o descrie.
2.3.2 Setarea automată a legăturilor RDF
Abordarea descrisa mai sus nu este potrivită pentru seturi mari de date, cum ar fi interconectarea a
cele peste 70.000 de locaŃii din DBpedia pentru a corespunde intrărilor din Geonames. În acest caz este
necesar un algoritm automat de conectare a înregistrărilor pentru generarea legăturilor RDF între
sursele de date.
Conectarea înregistrărilor (Record Linkage54) este o problemă cunoscută în comunitatea
persoanelor care se ocupă de baze de date. Mai multe materiale referitoare la folosirea algoritmilor de
conectare a înregistrărilor în contextul Datelor Interconectate se găsesc pe pagina Equivalence
Mining55.
Se simte o lipsă a instrumentelor bune şi uşor de folosit pentru generarea automată a legăturilor
RDF. Astfel este des întâlnită practica de implementare a algoritmilor de conectare a înregistrărilor
47
http://www.w3.org/People/Berners-Lee/card
48
http://www.cs.man.ac.uk/~sattler/reasoners.html
49
http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets
50
http://www.w3.org/2005/ajar/tab
51
http://sites.wiwiss.fu-berlin.de/suhl/bizer/ng4j/disco/
52
http://uriqr.com/
53
http://www.sindice.com/
54
http://en.wikipedia.org/wiki/Record_linkage
55
http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/EquivalenceMining
16

17. pentru seturi de date specifice, pentru generarea legăturilor RDF între sursele respective de date. În
continuare prezentam două clase de astfel de algoritmi:
2.3.3 Algoritmi bazaŃi pe tipare
În diverse domenii există scheme general acceptate de denumire. De exemplu, în domeniul
publicaŃiilor sunt numerele ISBN, în domeniul financiar exista identificatorii ISIN. Dacă aceşti
identificatori sunt folosiŃi ca componente ale URI-lor HTTP, pentru identificarea resurselor particulare,
atunci este posibil să folosim algoritmi simpli bazaŃi pe tipare pentru a genera legături RDF între aceste
resurse.
Un exemplu de sursă de date, care foloseşte numere ISBN ca componenta a URI-ului, este RDF
Book Mashup56, care de exemplu foloseşte URI-ul http://www4.wiwiss.fu-berlin.de/bookmashup/
books/0525270450 pentru a identifica cartea “A Book of Spooks and Spectres”, de Ruth Manning-
Sanders. PrezenŃa numărul ISBN în aceste URI-uri a facilitat generarea de legături owl:sameAs între
cărŃile prezente în cadrul DBpedia şi cele din cadrul Book Mashup. DBpedia foloseşte următorul
algoritm bazat pe tipare:
− Iterează peste toate cărŃile din DBpedia care au asociat un număr ISBN;
− Crează o legătura owl:sameAs între URI-ul unei cărŃi din cadrul DBpedia şi URI-ul
corespondent în cadrul Book Mashup folosind următorul tipar pentru URI-urile Book Mashup:
http://www4.wiwiss.fu-berlin.de/bookmashup/books/{ISBN}.
Rulând acest algoritm peste toate cărŃile din cadrul DBpedia rezulta legături, care sunt adăugate
setului de date DBpedia. De exemplu, legătura rezultată pentru cartea “A Book of Spooks and
Spectres”este:
<http://dbpedia.org/resource/A_Book_of_Spooks_and_Spectres>
owl:sameAs <http://www4.wiwiss.fu-berlin.de/bookmashup/books/0525270450>
owl:sameAs <http://www.freebase.com/view/en/a_book_of_spooks_and_spectres>
foaf:page <http://en.wikipedia.org/wiki/A_Book_of_Spooks_and_Spectres>
2.3.4 Algoritmi bazaŃi pe proprietăŃi
În cazurile în care nu avem identificatori comuni între seturile de date existente, este necesară
existenŃa unor algoritmi de legătură bazaŃi pe proprietăŃi. Precizăm doi algoritmi:
Interconectarea DBpedia cu Geonames57. InformaŃii despre locaŃii geografice apar atât în baza de
date Geonames, cât şi în DBpedia. Pentru a identifica locaŃiile care apar în ambele baze de date,
echipa Geonames foloseşte o euristică bazată pe proprietăŃi, care este bazată pe găsirea în titlul
articolului a informaŃie semantică, ca latitudine şi longitudine, dar şi Ńară, divizie administrativă,
populaŃie sau categorii. Rulând această euristică pe cele două surse de date rezultă corespondenŃe,
care sunt apoi adăugate ca legături owl:sameAs în setul de date DBpedia şi Geonames.
Interconectarea Jamendo cu MusicBrainz58. În acest caz este nevoie de interconectarea URI-lor de
gen http://musicbrainz.org/show/artist/?mbid=0781a3f3-645c-45d1-a84f-76b4e4decf6d cu cele de
gen http://dbtune.org/jamendo/artist/5, realizându-se corespondenŃe între melodii, artişti şi albume.
2.3.5 CerinŃe minime pentru publicarea Datelor Interconectate
Pentru a putea furniza informaŃii ca Date Interconectate avem nevoie să îndeplinim nişte cerinŃe
minimale:
− Resursele trebuiesc identificate prin URI-uri HTTP care pot fi derefenŃiate;
− Dacă un astfel de URI este derefenŃiat prin cererea unui tip MIME, de genul
56
http://sites.wiwiss.fu-berlin.de/suhl/bizer/bookmashup/index.html
57
http://lists.w3.org/Archives/Public/semantic-web/2006Dec/0027.html
58
http://blog.dbtune.org/post/2007/06/11/Linking-open-data:-interlinking-the-Jamendo-and-the-
Musicbrainz-datasets
17

18. application/rdf+xml, atunci o sursă de date trebuie să returneze o descriere RDF/XML a resursei
identificate;
− URI-urile care identifică resurse non-informaŃionale trebuiesc setate într-unul din următoarele
feluri:
− fie sursa de date trebuie să returneze un răspuns HTTP, care conŃine o redirectare HTTP
303 către o resursă informaŃională, care descrie o resursă non-informaŃională;
− fie URI-ul resursei non-informaŃionale trebuie format prin alăturarea URI-ului resursei
informaŃionale asociate şi un fragment hash identificator (e.g. #evalica);
− Pe lângă legăturile RDF către resurse care au aceeaşi sursă de date, descrierile RDF pot
conŃine legături RDF către surse oferite de alte surse de date, astfel încât utilizatorii să poată naviga
prin urmarea respectivelor legături;
2.4 Testarea Datelor Interconectate
După ce informaŃiile au fost publicate ca Date Interconectate, trebuie să ne asigurăm că există
legături RDF externe, care fac legătura cu URI-urile din cadrul setului nostru de date, astfel încât
navigatoarele RDF să poată găsi aceste date şi trebuie testat dacă informaŃia este accesată în mod
corect.
O metodă facilă de testare este aceea de a introduce folosi serviciul de validare Vapour59, care
generează un raport detaliat asupra felului în care URI-urile introduse reacŃionează la diferite tipuri de
cereri HTTP.
În afară de validare, trebuie testat modul în care informaŃia este afişată în diverse navigatoare de
Date Interconectate şi dacă aceste navigatoare pot accesa legăturile RDF din cadrul datelor. Se pot testa
următoarele navigatoare:
− Tabulator60: dacă navigatorul Tabulator durează prea mult la încărcarea datelor, atunci acesta
este un semn ca grafurile RDF sunt prea complexe şi trebuie divizate în mai multe fişiere. Tabulator
realizează şi inferenŃe de bază peste datele găsite, fără a verifica consistenŃa. Astfel, dacă Tabulator se
comportă ciudat, acest lucru poate să indice existenŃa problemelor în cadrul declaraŃilor
rdfs:subClassOf şi rdfs:subPropertyOf din schemele RDFS şi OWL folosite;
− Marbles61;
− OpenLink RDF Browser62;
− OpenLink Data Explorer63;
− Zitgist64;
− Disco65: navigatorul Disco foloseşte un timp de aşteptare de 2 secunde atunci când primeşte
date din cadrul Web. Astfel, dacă Disco nu afişează datele în mod corect, acest lucru poate fi un
indicator ca serverul este prea încet.
În cazul în care apar probleme, următoarele lucruri pot fi efectuate:
− Se va testa cu cURL66 dacă derefenŃierea URI-urilor implică răspunsuri HTTP corecte. Richard
Cyganiak67 a publicat un tutorial despre felul în care se poate face depanarea datelor folosind cURL;
− Se va folosi serviciul de validare RDF68 oferit de W3C pentru a verifica dacă avem
RDF/XML valid.
59
http://validator.linkeddata.org/vapour
60
http://www.w3.org/2005/ajar/tab
61
http://dbpedia.org/Marbles
62
http://demo.openlinksw.com/DAV/JS/rdfbrowser/index.html
63
http://linkeddata.uriburner.com/ode/
64
http://dataviewer.zitgist.com/
65
http://sites.wiwiss.fu-berlin.de/suhl/bizer/ng4j/disco/
66
http://dowhatimean.net/2007/02/debugging-semantic-web-sites-with-curl
67
http://richard.cyganiak.de/
68
http://www.w3.org/RDF/Validator/
18

19. 2.5 Descoperirea Datelor Interconectate
Modul standard de descoperire a Datelor Interconectate este acela de a urmări legăturile RDF în
cadrul datelor. Pentru a se uşura procesul de descoperire, furnizorii de informaŃie pot decide dacă vor să
suporte mecanisme adiŃionale de descoperire:
2.5.1 Mecanisme de Ping pentru Web-ul Semantic
Ping the Semantic Web69 este un serviciu pentru documentele RDF din cadrul Web-ului, care este
folosit de câteva alte servicii şi aplicaŃii client. Astfel, se poate îmbunătăŃi tehnica de descoperire a
propriilor date prin înregistrarea URI-urilor în cadrul seriviciului Ping The Semantic Web;
2.5.2 Auto-descoperirea legăturilor HTML
De multe ori se pot crea legături din cadrul paginilor Web standard către date RDF, de exemplu din
cadrul paginii personale către un profil FOAF. Astfel de legături pot fi marcate prin folosirea
elementului HTML <link> în antetul paginii HTML:
<link rel=“alternate” type=“application/rdf+xml” href=“legătura_către_RDF”/>
Elementele <link> sunt folosite de extensii ale navigatoarelor, ca de exemplu Piggybank70 sau
Semantic Radar71, pentru a descoperi date RDF în cadrul Web.
2.5.3 Indexare Semantic Web: extensii de structura a site-ului Web
Extensiile de structură72 a site-urilor Web permit furnizorilor de date să definească locul în care
RDF-urile sunt localizate şi să specifice ce metode alternative sunt oferite pentru a le accesa (Date
Interconectate, consolă SPARQL, RDF dump). ClienŃii Web-ului Semantic şi motoarele de căutare pot
folosi aceasta informaŃie pentru a accesa datele RDF pentru operaŃiunea de care au nevoie.
2.5.4 Liste de seturi de date în cadrul ESW Wiki
Pentru a facilita modul de descoperire a Datelor Interconectate şi pentru utilizatorii umani este
indicat adăugarea setului personal de date listei gestionate de ESW Wiki73. Este recomandată adăugarea
şi a câtorva resurse URI provenite din setul propriu de date, care vor deveni puncte de start în navigare.
2.5.5 Motoare de căutare semantice
Se pot utiliza următoarele motoare de căutare semantice pentru găsirea informaŃiei necesare:
− Sindice74;
− Uriqr75;
− Falcon 76;
− SWSE 77;
− Swoogle 78;
− Watson 79;
− SameAs80.
69
http://pingthesemanticweb.com/
70
http://simile.mit.edu/wiki/Piggy_Bank
71
http://sioc-project.org/firefox
72
http://sw.deri.org/2007/07/sitemapextension/
73
http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets
74
http://www.sindice.com/
75
http://uriqr.com/
76
http://iws.seu.edu.cn/services/falcons/objectsearch/index.jsp
77
http://swse.deri.org/
78
http://swoogle.umbc.edu/
79
http://watson.kmi.open.ac.uk/WatsonWUI/
80
http://sameas.org/
19

20. 3. Logicile Descrierii ca fundament pentru Datele
Interconectate
3.1 Logicile Descrierii şi separarea TBox - ABox
Description Logic81 (DL - Logicile Descrierii) este o denumire pentru familia de formaliste care
reprezintă cunoştinŃele unui domeniu, definind în primul rând concepte (clase) relevante domeniului
(terminologia acestuia, numită TBox – Terminology Box); şi utilizând aceste concepte pentru a specifica
proprietăŃi (relaŃii, roluri) ale obiectelor şi indivizii care apar în domeniu, în descrierea lumii (datele,
numită ABox – Assertions Box ). Astfel, TBox este mai structural şi reflectă relaŃiile logice şi
conceptuale din cadrul domeniului, în timp ce ABox furnizează instanŃele de date şi caracteristicile
conŃinute de schemă. În cazul în care am face o analogie cu o bază de date relaŃională, schema logică ar
corespunde lui TBox, iar înregistrările conŃinute ar corespunde lui ABox.
Ideile lui Brachman82 au influenŃat dezvoltarea ulterioară a DL, fiind astfel stabilite fundamentele
termenului:
− componentele sintactice de bază sunt concepte atomice (predicate unare), roluri atomice
(predicate binare) sau indivizi (constante);
− puterea expresivă a limbajului este restricŃionată prin folosirea unui set de constructori pentru
construcŃia conceptelor complexe şi a rolurilor;
− cunoştinŃe implicite despre concepte şi indivizi pot fi inferate (deduse) automat cu ajutorul
procedurilor de inferenŃă (deducŃie).
În timp ce TBox descrie vocabularul domeniului (structură, schemă conceptuală), ABox conŃine
aserŃiuni despre indivizi (instanŃe, date, situaŃii concrete) folosind termenii vocabularului. Vocabularul
constă din concepte, care denotă seturi de indivizi, şi roluri, care denotă relaŃii binare între indivizi.
Descrierile elementare conŃin concepte atomice şi roluri atomice. Descrierile complexe pot fi construite
inductiv din descrierile de bază folosind constructori de concepte. Limbajele DL se disting în funcŃie de
constructorii pe care ii oferă, aceştia reprezentând nivelul de expresivitate al unui limbaj.
Componentele de bază83 pentru Logicile Descrierii sunt concepte, roluri şi indivizi. Conceptele
descriu proprietăŃi comune ale unei colecŃii de indivizi şi pot fi considerate ca predicate unare, care sunt
interpretate ca seturi de obiecte. Rolurile sunt interpretate ca relaŃii binare între obiecte. Fiecare DL
defineşte un număr de constructori (recursivi) de limbaj (constructori logici pentru logica cu predicate
de ordinul I84 ca intersecŃie, reuniune, negaŃie, etc) care pot fi folosiŃi pentru a definii noi concepte şi
roluri.
Principalele operaŃii de raŃionament în DL sunt clasificarea şi satisfiabilitatea, incluziune -
apartenenŃă şi verificare de instanŃe. Incluziunea (apartenenŃa) reprezintă relaŃia is-a85. Clasificarea este
realizarea unei ierarhii de concepte bazate pe incluziune.
3.1.1 Reprezentarea cunoştinŃelor pentru Logicile Descrierii
O bază de cunoştinŃe Σ este un tuplu <T, A>. T denotă elementele de terminologie TBox. T este
un set finit de propoziŃii care se numesc axiome terminologice:
− C ⊆ D (axioma de incluziune generală) sau C ≡ D (axioma de echivalenŃă generală), care
integrează C ⊆ D şi D ⊆ C, unde C,D sunt concepte, şi
− R ⊆ S (axioma de incluziune pentru roluri) sau R ≡ S (axioma de echivalenŃă pentru roluri),
care integrează R ⊆ S şi S ⊆ R, unde R, S sunt roluri.
81
http://dl.kr.org/
82
http://brachman.org/
83
http://www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-01.pdf
84
Smullyan, R. M. , "First-order logic", Courier Dover Publications, 1995
85
http://en.wikipedia.org/wiki/Is-a
20

21. A reprezintă elementele ascensionale sau ABox. A este un set finit de propoziŃii – axiome
individuale – de forma a:C, notat şi C(a), numite aserŃiuni conceptuale şi <a,b>:R, notate şi R(a,b),
numite aserŃiuni de rol.
O interpretare86 I satisface Σ, notată I |= Σ, dacă şi numai dacă satisface T şi A. I consistă dintr-
un set nevid ∆I – domeniul interpretării – şi o funcŃie de interpretare, care atribuie fiecărui concept
atomic A un set A I ⊆ ∆I şi fiecărui rol R o relaŃie binară R ⊆ ∆I x ∆I. O interpretare I = 〈 ∆I , ⋅ I 〉 este
model pentru Σ dacă fiecare axiomă din Σ este satisfăcută de I. Σ este satisfiabilă dacă modelul este
acceptat.
O ontologie se poate asocia unei baze de cunoştinŃe DL, Σ şi este echivalentă cu TBox + ABox.
Astfel, o bază de cunoştinŃe este o schemă logică de roluri, concepte şi relaŃiile dintre acestea (TBox),
care este populată cu instanŃe de date şi atributele corespunzătoare (ABox). . Limbajul AL (Attribute
Language) reprezintă limbajul minimal; celelalte limbaje DL sunt extensii ale AL. Web-ul Semantic
este bazat pe OWL, care corespunde unei variante de SHOIN(D). Pentru mai multe detalii despre
expresivitatea limbajelor DL a se vedea Anexa C.
Familii întregi de sisteme de reprezentare a cunoştinŃelor au fost construite folosind aceste limbaje
şi pentru majoritatea dintre acestea complexitatea pentru efectuarea sarcinilor principale de
raŃionamente sunt cunoscute. Astăzi, principala funcŃionalitate DL este aceea de a modela ontologii în
Web-ul Semantic. Sublimbajele OWL-DL şi OWL-Lite ale W3C Web Ontology Language87 (OWL) sunt
bazate pe DL.
3.1.2 Maparea conceptelor DL peste formatele semantice
Modelul de date RDF88 furnizează un cadru abstract şi conceptual pentru definirea şi utilizarea de
metadate şi de vocabulare de metadate. În forma sa de bază, nu există definite constrângeri de domeniu
sau de intervale folosite; nu există constrângeri de cardinalitate şi îi lipsesc proprietăŃi de tranzitivitate,
inversă sau simetrie. La acest nivel RDF are suport limitat pentru realizarea de raŃionamente.
În această formă, baza RDF este adecvată89 pentru descrierea de instanŃe şi înregistrări de date,
lucru denumit ABox în Logicile Descrierii.
RDFS90 (RDF Schema) este următorul strat modelat pentru a depăşi limitările modelului RDF.
RDFS introduce noi predicate şi clase, ca declaraŃiile class, subClass şi adaugă domeniu şi intervale
proprietăŃilor asociate, oferind astfel mecanismele necesare construirii de vocabulare. Există numeroase
vocabulare create folosind RDFS şi se poate aplica peste aceste vocabulare suport limitat pentru
inferenŃe şi raŃionamente.
Un alt strat care poate realiza acest lucru este OWL91. OWL furnizează o modalitate de a adăuga
expresivitate şi posibilitatea de a descrie relaŃiile şi structura conceptelor deŃinute. RDFS şi OWL
descriu TBox-ul în Logicile Descrierii.
RDF oferă fundamentul care poate fi mapat peste conceptele Logicii Descrierii. Utilizând RDF şi
RDFS, avem un model de date şi o bază pentru vocabulare, care este potrivită descrierii instanŃelor
(ABox). Folosind RDFS şi OWL, avem o schemă extinsă de structură şi ontologii potrivite pentru
descrierea şi modelarea relaŃiilor în cadrul contextului (TBox). Astfel, RDF oferă un cadru pentru
modelarea tuturor formelor de date, pentru descrierea datelor prin intermediul vocabularelor şi pentru a
asigura interoperabilitatea prin scheme şi ontologii.
86
http://www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-02.pdf
87
http://www.w3.org/TR/owl-features/
88
http://www.w3.org/RDF/
89
http://www.mkbergman.com/?p=483
90
http://www.w3.org/TR/rdf-primer/#rdfschema
91
http://www.w3.org/TR/owl-ref
21

22. 3.2 Caracteristici specifice DL cu aplicabilitate în Web-ul Semantic
3.2.1 PrezumŃia de asignare unică de nume
PrezumŃia de asignare unică de nume (Unique Naming Assumption92 - UNA) este una dintre aceste
caracteristici. În DL presupunem că nume distincte denotă obiecte distincte. Astfel, dacă avem numele
distincte a,b ∈ I , aceasta implică aI ≠ bI. Contrastual, limbajul DL ALC (Attribute Language with
Complements) nu necesită ca simboluri diferite să fie interpretate ca obiecte diferite. Nici recomandarea
consorŃiului W3C pentru OWL93 nu utilizează UNA. În contextul Web-ului Semantic acest lucru este
direct şi natural. Pot exista mai multe etichete (URI) pentru acelaşi „obiect” sau pentru scopuri diferite,
care să refere sau să reprezinte aceeaşi entitate. Un alt aspect este acela că o anumită propoziŃie poate
să fie validă numai pentru o anumită perioadă de timp.
3.2.2 Ipoteza lumilor deschise versus lumilor închise
Bazele de cunoştinŃe DL au semantici de lumi deschise94. Dacă nu putem deduce din baza de
cunoştinŃe DL că un individ i este o instanŃă a conceptului C, atunci nu presupunem că i aparŃine ¬C. În
contextul Web-ului Semantic, OWL aparŃine tot ipotezei lumilor deschise. Dacă o clasă C1 nu este
definită în ontologia O1, se poate ca ea să fie extinsă în alte ontologii. InformaŃie nouă nu poate retracta
informaŃie deja existentă. InformaŃie nouă poate fi contradictorie, dar faptele pot fi doar adăugate, nu şi
şterse.
Perspectiva lumilor deschise presupune că informaŃia este înŃeleasă ca fiind incompletă şi
insuficientă. Valorile lipsă nu influenŃează conŃinutul actual. Există asumpŃia că există mereu
informaŃie care poate fi adăugată şi modelul datelor trebuie să reflecte acest lucru.
Utilizând formatul RDF înseamnă că avem la dispoziŃie noi structuri, noi date şi noi vocabulare
externe cu care datele proprii să poată fi conectate. În timp ce datele interne sunt expuse într-o manieră
deschisă, datele externe pot fi uşor incorporate contextului local.
Scopul Datelor Interconectate este acela de a depăşi limitele organizaŃiilor şi de a îmbrăŃişa toată
informaŃia ca fiind publică. La o scală extinsă se doreşte promovarea vocabularelor partajate, a
cunoştinŃelor partajate, a creării, adnotării şi gestiunii colective a datelor.
3.3 Analogii TBox şi ABox în cadrul Datelor Interconectate
Logicile Descrierii (DL) şi semantica asociată acestora separă conceptele şi relaŃiile dintre acestea,
de indivizii, descrişi împreună cu atributele şi rolurile lor. Separarea conceptelor este cunoscută sub
denumirea de TBox (cunoştinŃe terminologice) şi reprezintă schema domeniului descris. Separarea
indivizilor este cunoscută sub denumirea de ABox (aserŃiuni) şi descrie atributele indivizilor şi rolurilor
dintre aceştia.
OperaŃiile logice specifice TBox şi ABox sunt distincte şi au roluri diferite. OperaŃiile TBox sunt
folosite în special pentru a realiza inferenŃe şi pentru a determina şi verifica ierarhiile dintre clase.
OperaŃiile ABox sunt mai mult bazate pe reguli şi ajută la verificarea faptelor, instanŃelor şi a
consistenŃei acestora. DeducŃiile pentru ABox sunt mult mai complexe şi costisitoare decât cele
realizate pentru TBox.
Până în momentul de faŃă conceptele Logicii Descrierii au fost folosite exclusiv pentru a realiza
inferenŃe în cadrul Web-ului Semantic. Totuşi, Logicile Descrierii oferă fundamente95 pentru a descrie
92
http://www.w3.org/TR/2004/REC-owl-guide-20040210/#term_uniqueName
93
http://www.w3.org/TR/owl-features/
94
http://www.mindswap.org/2005/OWLWorkshop/sub12.pdf
95
http://www.mkbergman.com/?p=466
22

23. arhitectura Datelor Interconectate şi vom arăta modul în care tehnicile de interconectare a datelor pot
beneficia de conceptele regăsite în DL.
Datelor Interconectate le lipseşte o structură de referinŃă coerentă pentru conceptele şi subiectele
care descriu conŃinutul. Deşi Datele Interconectate permit furnizorilor de date să-şi descrie şi
interconecteze propriile date, acestora le lipseşte un cadru care să relaŃioneze toate instanŃele asociate
între ele. De exemplu, datorită Datelor Interconectate se pot găsi informaŃii suplimentare despre o
anumită persoană, ca informaŃii despre locul naşterii şi funcŃia pe care acesta a deŃinut-o în timpul
vieŃii, dar nu se pot afla toate persoanele care au avut funcŃia respectivă sau care este ierarhia funcŃiilor
în cadrul organizaŃiei.
Logicile Descrierii au fost utilizate pentru a crea şi înŃelege sistemele de reprezentare a
cunoştiinŃelor. Putem observa astfel că primele eforturi ale iniŃiativei Datelor Interconectate i-au lipsit
contextul, un TBox standardizat. Este necesar atât un ABox, cât şi un TBox pentru a completa cadrul
logic şi pentru a crea un sistem de reprezentare de cunoştiinŃe.
Componenta TBox este reprezentată de ontologiile utilizate, împreună cu clasele, ierarhiile şi
relaŃiile dintre acestea. Această componentă deŃine terminologia care permite conectarea cu ontologii
externe. TBox utilizează un vocabular controlat pentru a defini conceptele şi rolurile unui domeniu de
interes şi relaŃiile sau proprietăŃii dintre acestea. Vocabularul utilizat poate fi oricânt extins cu noi
concepte.
Componenta ABox este reprezentată de instanŃele conŃinute, extrase sau oferite de către furnizori,
care populează structura definită de TBox.
În funcŃie de gradul de formalism pe care o ontologie îl oferă, aceasta ajută la definirea scopului,
limbajului şi a înŃelesurilor semantice pe care un anumit domeniu le conŃine. Ontologiile oferă directive
asupra modului în care informaŃia se relaŃionează în cadrul domeniului. Putem astfel realiza inferenŃe
asupra domeniului şi să extragem informaŃii suplimentare.
Există numeroare avantaje96 pentru a separa TBox de ABox, care Ńin de beneficiile aduse
perspectivelor modelării, performanŃei, arhitecturii şi flexibilităŃii. Se oferă o mai bună performanŃă
prin păstrarea separată a modului de realizare a inferenŃelor şi a raŃionamentelor. Scalabilitatea este
crescută, atunci când avem o separare a funcŃiilor şi creşte modularitatea, atunci când informaŃiile
atributelor sunt Ńinute separat de relaŃiile conceptuale şi de structură. În acest mod putem avea o
partiŃionare a ABox-urilor şi a ontologiilor conŃinute de TBox. Clasele şi structurile relaŃionale TBox
trebuie să rămână separate de instanŃele datelor şi pot fi utilizate pentru a opera separat de seturile de
date. Este recomandat ca structura TBox să conŃină ontologii deja cunoscute, ca FOAF97, DC98, SIOC99,
UMBEL100, etc.
Totuşi de multe ori, această separaŃie a TBox de ABox este mai mult la nivel conceptual şi este
întâlnită mai rar în practică. Însă recomandarea de a păstra faptele şi aserŃiunile separat de modul în
care acestea ar trebui interpretate, rămâne.
Cei mai mulŃi furnizori de date, care publică datele în format OWL, consideră imperativă
decidabilitatea şi raŃionamentele care pot fi realizate cu ajutorul respectivelor date. Furnizorii din cadrul
comunităŃii Datelor Interconectate se concentrează asupra cantităŃii de date care poate fi publicată şi
expusă spre reutilizare.
3.3.1 Separarea TBox - ABox pentru Date Interconectate
Obiectivul comunităŃii Linked Open Data (LOD) este acela de a publica cât mai multe seturi de
date, în format RDF, în cadrul Web-ului şi de a interconecta elementele conŃinute de aceste seturi.
96
http://www.mkbergman.com/?p=470
97
http://xmlns.com/foaf/spec/
98
http://dublincore.org/documents/dcmes-xml/
99
http://rdfs.org/sioc/spec/
100
http://www.umbel.org/technical_documentation.html
23

24. Orice astfel de set din cadrul diagramei norului LOD (a se vedea Figura 1) este considerat a încorpora
date deschise.
În momentul în care discutăm despre norul Datelor Interconectate trebuie precizat că acesta este o
reprezentare ABox a lumiilor descrise şi instanŃelor sale. Vizualizarea norului descrie la nivel de
instanŃă componentele Datelor Interconectate.
Diagrama constelaŃiei101 LOD completează diagrama norului102 LOD. IniŃial103, cele mai multe
conexiuni se concentrau în jurul setului Dbpedia104, care conŃine datele structurate extrase din cadrul
Wikipedia. Conexiunile prezente în diagrama norului LOD sunt în general relaŃii owl:sameAs, ceea ce
înseamnă că aceleaşi lucruri-obiecte-concepte-resurse sunt referenŃiate în cadrul a mai multe seturi de
date şi apoi interconectate. În prezent datele conŃinute de LOD sunt interconectate cu mai mult de 180
milioane105 de legături RDF.
Figura 7 Diagrama constelaŃiei106 Linked Open Data – octombrie 2008
Diagrama constelaŃiei LOD interconectează clasele a 21 de seturi de date LOD şi a fost concentrată
pe legăturile la nivel de clasă centrate în jurul setului UMBEL107. Legăturile la nivel de clasă sunt foarte
importante şi descriu un fenomen numit „exploding the domain”108 (explozia domeniului). Legăturile la
nivel de clasă întâlnite în cadrul constelaŃiei LOD se bazează pe unul din predicatele: rdfs:subClassOf,
owl:equivalentClass, umbel:superClassOf sau umbel:isAligned.
3.3.1.1 Fenomenul de „explozie a domeniului”
Explozia domeniulu109i presupune realizarea de mapări clasă-la-clasă între o ontologie de referinŃă
101
http://umbel.org/lod_constellation.html
102
http://www4.wiwiss.fu-berlin.de/bizer/pub/lod-datasets_2009-03-27.html, martie 2009
103
http://www4.wiwiss.fu-berlin.de/bizer/pub/lod-datasets_2008-09-18.html, septembrie 2008
104
http://dbpedia.org/
105
http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets/LinkStatistics
106
http://umbel.org/images/lod_constellation.html, octombrie 2008
107
http://www.umbel.org
108
http://fgiasson.com/blog/index.php/2008/09/04/exploding-dbpedias-domain-using-umbel/
109
http://www.mkbergman.com/?p=454
24

25. şi ontologii externe acesteia. Acest lucru permite proprietăŃilor, domenilor şi intervalelor asociate să fie
moştenite de la o ontologie la alta. Explozia domeniului dezvoltă puterea inferenŃelor spre aceste noi
informaŃii asociate. În urma exploziei domeniului se moştenesc şi relaŃiile structurale la nivel de schemă
de la sursele către care s-a realizat asocierea.
Setul de date: Organisme Setul de date: Rase
Clase (structură) Animalia Homo sapiens
Vertebrata Caucasoid
Mammalia Negriod
Hominini Mongoloid
Homo sapiens
InstanŃe (indivizi) Individ A (Homo sapiens) Individ A (Negroid)
Individ B (Caucasoid)
Dacă cele două seturi de date din tabel sunt conectate doar la nivelul instanŃelor, utilizând pentru
„Individ A” o relaŃie de tip sameAs, se poate afirma atât faptul că „Individ A” este un animal vertebrat,
cât şi că aparŃine rasei Negroide. Nu există o mapare la nivel de clase, astfel încât nu putem afirma că
“Individ B” este la rândul lui un animal vertebrat, deoarece nu există nici o instanŃă a acestui individ în
setul de date Organisme.
Pentru a putea realiza inferenŃe utilizând sameAs, în absenŃa unei mapări între clase, avem nevoie
ca respectiva instanŃă să existe în setul de date extern. Proprietatea owl:sameAs este una din cele mai
puternice predicate existente, având proprietăŃi de reflexivitate şi tranzitivitate. InstanŃele pot moşteni
proprietăŃi şi structura setului de date din care provin. În acest caz avem un model de intersecŃie astfel
încât, având o potrivire în cadrul instanŃelor, putem face inferenŃe asupra structurilor seturilor de date
de provenienŃă.
Totuşi atunci când există mapări la nivel de clasă, se pot realiza inferenŃe pentru toŃi membrii
seturilor respective. Având o relaŃie de tip equivalentClass pentru “Homo sapiens” între cele două
seturi A şi B, putem deduce că “Individ B” este un animal vertebrat. În acest caz avem un model de
reuniune, unde mapările au devenit generalizate şi inferenŃele extinse pentru toate instanŃele.
Indiferent de formatul de publicare al datelor, aserŃiunile care se vor realiza la nivelul ABox al
datelor conectate trebuie să poată să fie testate asupra consistenŃei, deoarece ABox-ul poate să conŃină
inconsistenŃe. De asemeni schemele şi structurile de date TBox sunt inutile dacă acestea nu sunt
populate cu date.
Datele Interconectate şi ABox nu oferă prin definiŃie posibilitatea a face inferenŃe şi raŃionamente,
acestea fiind strâns legate de existenŃa TBox, care descrie perpectiva organizaŃională. RaŃionamentele
pot fi deduse utilizând sisteme de inferenŃă (reasoners110).
Translatând munca de validare şi testare a datelor unor servicii externe, se oferă o modalitate mult
mai uşoară de a publica şi expune date. Este timpul pentru dezvoltarea de intermediari ai Datelor
Interconectate şi de servicii care să evolueze în cadrul ecosistemului.
În capitolul următor vor descrie ontologiile care ar trebui regăsite şi utilizate pentru a realiza TBox-
ul în contextul Datelor Interconectate, pentru a descrie componentele reŃelelor sociale şi al
managementului informaŃiilor personale.
110
http://www.cs.man.ac.uk/~sattler/reasoners.html
25

26. 4. Strategii pentru reprezentarea, interconectarea şi
interoperabilitatea datelor în cadrul Web-ului
4.1 MotivaŃie, tranziŃii şi direcŃii parcurse în dezvoltarea
interacŃiunilor cu utilizatorul
4.1.1 Portabilitatea datelor
Viziunea conceptului de portabilitate a datelor (DataPortability111) descrie o experienŃă fără limite,
în care persoanele au libertate de a se deplasa în cadrul serviciilor din reŃea, în care pot reutiliza
propriile date în timp ce menŃin controlul asupra securităŃii lor.
IniŃiativa DataPortability a fost lansată în anul 2007, în cadrul acesteia participând membri ai
diferite organizaŃii, printre care Facebook, Google sau Microsoft. DataPortability are ca scop
promovarea capabilităŃii de control asupra datelor personale, de partajare şi de portabilitate în cadrul
sistemelor şi serviciilor. Prin portarea datelor se pot transfera conversaŃii, fişiere, contacte, identităŃi şi
profilul personal, fără a fi necesară reintroducerea datelor de fiecare dată atunci când este nevoie de
înregistrarea în cadrul unui nou serviciu. Pentru fiecare serviciu se pot extrage doar informaŃiile
relevante şi necesare. Actualizarea datelor se realizează automat şi simultan de către toate serviciile
care împart datele utilizatorului. Acest lucru avantajează accesul datelor între sisteme, interoperabilite
şi portabilitate.
Mişcarea DataPortability se concentrează mai mult spre deschiderea grafului social, permiŃând
informaŃiei sociale să devină mult mai accesibilă. Scopul lucrării noastre este acela de a documenta
practicile recomandate pentru integrarea standardelor şi protocoalelor existente, pentru a permite
portabilitatea între serviciile, furnizorii şi instrumentele online.
O altă mişcare de acest gen este şi OpenSocial112, care îşi propune interoperabilitatea în cadrul
reŃelelor sociale.
4.1.2 TranziŃii spre Cloud Computing şi sisteme de operare Web
4.1.2.1 Software as a Service
Utilizatorii au la dispoziŃie trei platforme pe care pot să-şi desfăşoare activitatea: desktop-ul,
dispozitivele mobile şi “the Cloud” (metafora care descrie conceptul de Web). Sarcinile zilnice se
realizează folosind aplicaŃii din cadrul sistemelor desktop tradiŃionale, care au fost translatate în
aplicaŃii web şi aplicaŃii mobile. Linia de separaŃie între cele trei platforme este din ce în ce mai puŃin
vizibilă şi furnizorii încearcă să ofere o experienŃă cât mai unitară şi transparentă, indiferent de
platforma aleasă de utilizator.
“Software as a Service” (SaaS) este un model de dezvoltare în care o aplicaŃie este găzduită ca un
serviciu oferit către utilizatori, prin intermediul Web-ului. Eliminând nevoia de a instala şi rula aplicaŃia
pe calculatorul personal, SaaS elimină problemele instalării, mentenanŃei, suportului sau administrării
software-ului.
Modelul de dezvoltare a aplicaŃiilor în genul “Software as a Service” (SaaS) a apărut din nevoia
utilizatorilor de a atinge un nivel cât mai ridicat de funcŃionalitate, flexibilitatea şi timp de răspuns.
Astfel, aplicaŃiile au fost livrate ca servicii, într-o arhitectură în care componentele sunt oferite
instantaneu, atunci când ele sunt necesare, realizând un software mult mai flexibil şi viabil, care poate
satisface cerinŃele în continuă schimbare ale utilizatorilor.
111
http://www.dataportability.org/
112
http://www.opensocial.org/
26

27. Modelul de software bazat pe servicii este unul în care serviciile sunt configurate pentru a îndeplini
un set de cerinŃe specificate la un moment dat. Serviciile sunt compuse din componente mai mici (în
mod recursiv). Această strategie permite dezvoltatorilor să creeze, compună şi să asambleze un
serviciu, selectând cea mai potrivită combinaŃie de servicii necesare pentru a îndeplini o anumită
sarcină.
Acest tip de software este caracterizat ca fiind software la cerere (on-demand) şi se diferenŃiază de
varianta clasică de software (on-premise), care rula în cadrul restrâns al unei organizaŃii, organizaŃia
fiind responsabilă pentru licenŃierea, instalarea, operarea şi mentenanŃa aplicaŃiei.
SoluŃiile SaaS sunt văzute ca “applications in the clouds”, aplicaŃii în cadrul Web-ului. Utilizatorul
final nu este interesat de modul în care aplicaŃiile sunt create sau de modul în care funcŃionează. Pentru
el, aplicaŃia este reprezentată de interfaŃa utilizator pe care aceasta o afişează - “UI (User Interface) is
the application”(Jason Miller).
O aplicaŃie de tip cloud (cloud application) utilizează Web-ul ca şi componentă unică în cadrul
arhitecturii ei, eliminând necesitatea de a instala aplicaŃia pe calculatorul utilizatorului. O caracteristică
vitală pe care aplicaŃiile trebuie să o satisfacă este scalabilitatea. Unul din cele mai cunoscute exemple
de astfel de aplicaŃii, este suita de aplicaŃii Google (Gmail, GDocs, Picasa, etc.). Suita Google
furnizează funcŃionalităŃi online de productivitate şi colaborare, care sunt accesate prin intermediul
unui navigator, în timp ce software-ul şi datele sunt stocate pe serverele Google (cu posibilitatea de
export local).
4.1.2.2 Cloud Computing
SaaS a permis înlocuirea modelului tradiŃional de aplicaŃii one-to-one (unu-la-unu), către un model
one-to-many (unu-la-mulŃi). Platform as a Service (PaaS) este o extindere a modelului SaaS şi
reprezintă un model many-to-many (mulŃi-la-mulŃi). Acest model facilitează suportul pentru tot ciclu de
viaŃă necesar realizării sau livrării aplicaŃiilor şi serviciilor disponibile, exclusiv în cadrul Web-ului.
PaaS este o platformă completă, care permite dezvoltarea, stocarea, testarea şi furnizarea de aplicaŃii
către clienŃi. PaaS se întâlneşte şi sub denumirea de cloudware, platform-on-demand sau cloud
platform. Cloud platform este tipul de platformă care permite dezvoltatorilor să scrie aplicaŃii, care
rulează în cadrul Cloud-ului sau folosesc servicii furnizate de către acesta.
Figura 8 Conceptul de “Cloud computing”
Cloud computing presupune dezvoltarea şi utilizarea de tehnologii bazate exclusiv pe platforma
Web. Cloud computing este necesar atunci când avem nevoie de o metodă care să ajute la creşterea
capacităŃii de stocare sau adăugarea de capabilităŃi instante, fără a investi în infrastructură, în instruirea
de personal sau licenŃierea software-ului. Este un stil computaŃional în care resursele sunt oferite ca
servicii către utilizatori care nu au cunoştinŃe cu privire la modul în care infrastructura tehnologică
funcŃionează. Utilizatorii se bucură de funcŃionalitatea aplicaŃiilor şi se concentrează asupra datelor pe
care le deŃin, arhitectura fiind transparentă pentru ei.
27

28. Serviciile sunt accesibile oriunde, având Web-ul ca un unic punct de acces pentru toate nevoile
computaŃionale ale utilizatorilor. Standardele deschise şi software-ul open-source au avut un impact
critic asupra dezvoltării recente a noŃiunii de cloud computing. Furnizori ca Amazon, Google sau
Microsoft s-au implicat în dezvoltarea şi utilizarea componentelor din cadrul Cloud-ului.
Serviciile din cadrul Cloud-ului pot fi grupate în trei categorii:
− AplicaŃii de tip “Software as a Service” (SaaS), care rulează în întregime în cadrul Cloud-ului.
Clientul este de obicei un navigator Web. AplicaŃiile SaaS expun servicii care pot fi folosite de aplicaŃii
on-premise sau de alte aplicaŃii din cadrul Cloud-ului. Un exemplu de aplicaŃie SaaS este
Salesforce.com.
− Servicii ataşate: o aplicaŃie poate să acceseze servicii specifice furnizate de către Cloud.
Deoarece aceste servicii sunt utilizabile doar în cadrul acestei aplicaŃii, ele sunt ataşate acesteia. Un
exemplu este Apple iTunes: o aplicaŃie desktop care permite ascultarea de melodii, având asociat un
serviciu care permite cumpărarea de conŃinut audio şi video;
− Platforme cloud: o astfel de platformă pune la dispoziŃie servicii bazate pe Cloud pentru
crearea de aplicaŃii. De exemplu, în loc ca dezvoltatorii să aibe nevoie de propria infrastructură, ei pot
să construiască aplicaŃii SaaS direct în cadrul Cloud-ului. Utilizatorii direcŃi ai acestui tip de cloud sunt
dezvoltatorii şi nu utilizatorii finali. Componentele unui platforme de tip cloud sunt: maşini virtuale
(exemplu furnizor: Amazon Elastic Compute Cloud - EC2113), servicii de infrastructură (exemplu
furnizor stocare: Amazon Simple Storage Service - S3114, exemplu furnizor integrare: Amazon Simple
Queue Service - SQS115) şi serviciile de aplicaŃie (disponibile prin servicii web, API-uri). AlŃi furnizori
de platforme cloud sunt Google AppEngine116 sau Microsoft Azure117.
Figura 9 Categorii de servicii oferite de Cloud118
Pentru accesarea informaŃiilor din cadrul Cloud-ului este nevoie de o identitate virtuală a
utilizatorilor, de exemplu un cont Google, Amazon sau un Windows Live ID..
O problemă care este evidenŃiată în cadrul conceptului de cloud computing este aceea de securitate
a datelor, companiile nefiind încă pregătite să-şi încredinŃeze datele confidenŃiale terŃelor părŃi, care ar
avea grijă de infrastructura Cloud-ului. O altă problemă spre o tranziŃie de tip Cloud este aceea ca Web-
ul nu este încă disponibil permanent pentru toŃi utilizatorii săi.
113
http://aws.amazon.com/ec2/
114
http://aws.amazon.com/s3/
115
http://aws.amazon.com/sqs/
116
http://code.google.com/appengine/
117
http://www.microsoft.com/azure
118
http://www.davidchappell.com/CloudPlatforms--Chappell.pdf
28

29. 4.1.2.3 TranziŃii Web-către-desktop, desktop-către-Web
SaaS este de obicei utilizat fie ca parte a unui mashup sau ca un plugin pentru PaaS. SaaS poate să
beneficieze şi de avantajele unei arhitecturi SOA (Service Oriented Architecure), permiŃând aplicaŃiilor
să comunice între ele.
Mashup-urile sunt aplicaŃii Web hibride, care combină în mod inteligent diverse date provenite din
surse externe într-o formă unitară şi mai complexă. Realizarea mashup-urilor a fost în strânsă legătură
cu expunerea serviciilor de către furnizorii mari şi dezvoltarea API-urilor. Datele disponibile sunt puse
la dispoziŃie prin interfeŃele publice de programare ale altor aplicaŃii (API – Application Programming
Interface), prin servicii Web sau fluxuri – feed-uri (date agregate în formate precum RSS ori Atom). Un
API defineşte o modalitate standard de invocare de către alte aplicaŃii a unor funcŃionalităŃi şi date
deŃinute de către un serviciu. Astfel mashup-urile combină eficient arhitectura orientată spre servicii
(SOA) şi componentele Web reutilizabile.
Aceştia grupează serviciile în instanŃe comune, de exemplu Google Data API119 care conŃine
servicii de acces al informaŃiilor pentru Google Contacts, Picasa, etc. Microsoft grupează Bing, Bing
Maps, etc. în cadrul platformei Microsoft Live. Toate aceste date oferite de API-uri, care acoperă
majoritatea aplicaŃiilor existente în cadrul desktop-ului, pot fi grupate în cadrul unui manager de
aplicaŃii care să le gestioneze.
Utilizatorii visează la ziua când sistemele de operare tradiŃionale vor dispărea şi toate lucrurile de
care aceştia au nevoie (date, aplicaŃii, contacte) vor fi disponibile în cadrul Cloud-ului, într-un sistem
de operare Web. O altă abordare ar fi unificarea Web-ului şi a desktop-ului, pentru a reda desktop-ului
uşurinŃa, ubicuitatea, independenŃa de platformă şi simplicitatea pe care o deŃin aplicaŃiile Web. Deşi
există anumite similarităŃi între Web şi desktop, dezvoltarea aplicaŃiilor specifice presupune utilizarea
de limbaje de programare diferite şi a altor metafore de interfaŃă pentru fiecare caz în parte.
Toate aceste lucruri duc către o tranziŃie cât mai evidentă de la sistemele de operare desktop, către
cele orientate Web, tranziŃie care a început cu o dezvoltare a comunicării desktop-către-Web şi Web-
către-desktop. Alinierea Web-ul mai aproape de desktop este importantă, dar totuşi, s-ar putea ca în cele
din urmă, cele două să nu fuzioneze, ci doar să se perfecŃioneze independent.
Adoptarea rapidă a aplicaŃiilor Web s-a datorat utilizării AJAX (Asynchronous JavaScript and
XML), RIA (Rich Web Applications), Flash, etc. În ultimii ani unele dintre aplicaŃiile Web cele mai
populare au fost Flickr, YouTube sau Facebook. Totuşi influenŃa aplicaŃiilor desktop s-a păstrat,
deoarece aplicaŃiile Web nu au ajuns să reproducă fidel gradul de performanŃă, răspuns, grafică şi acces
la datele locale, la fel ca aplicaŃiile desktop.
Un pas în apropierea lumii Web de desktop, a fost acela de a desfiinŃa ideea singularităŃii unei
aplicaŃii Web. O primă încercare de a combina mai multe informaŃii on-line în cadrul unui tot unitar au
fost portal-urile Web. Portal-urile Web prezintă informaŃie din diferite surse într-o metodă unitară.
Paginile personale bazate AJAX (Asynchronous JavaScript and XML), ca Pageflakes, My Yahoo!,
iGoogle, Netvibes, etc. se pot organiza în instanŃe, în funcŃie de nevoile utilizatorilor şi pot încorpora
informaŃie referitoare la ştiri, calendare, note, clienŃi de email, de chat, etc. DiferenŃa între un portal
AJAX şi un sistem de operare Web este aceea că ultimul pune la dispoziŃie o platformă de dezvoltare
completă, oferind printre altele şi posibilităŃi de stocare a datelor. Portal-urile doar oferă o interfaŃă mai
complexă pentru conŃinutul Web, gestionat de “mini aplicaŃii”.
Portal-urile AJAX sunt versiunea Web a gadget-urilor oferite de Google Desktop. Google Desktop
a reprezentat o încercare de aducere a diversităŃii şi actualităŃii informaŃiei Web în cadrul desktop-ului.
În primul rând a furnizat o metodă de a utiliza o interfaŃă de căutare asemănătoare cu cea oferită de
Google pentru documentele stocate local. Un alt avantaj a presupus existenŃa sidebar-ului (bară
laterală), care a permis integrarea în desktop a anumitor servicii întâlnite pe Web (email, ştiri, starea
vremii, etc) şi nu numai.
Principala tendinŃă a fost aceea de a permite aplicaŃiilor Web să împrumute cât mai multe
caracteristici ale aplicaŃiilor desktop, fără a-şi pierde din atributele specifice, precum suportul indiferent
de platformă sau dispozitiv (cross platform/device). Acest lucru este posibil în două feluri: prin
119
http://code.google.com/apis/gdata/
29