Universitatea „Alexandru Ioan Cuza”
                   Facultatea de Informatică




 Interconectarea semantică a datelor ...
"Revolution doesn’t happen when
society adopts new technologies – it
happens when society adopts new
behaviors."
         ...
CUPRINS
1. INTRODUCERE ......................................................................................................
4.4.2.3 Translatarea semantică a informaŃiilor...............................................................................
1. Introducere

     Web-ul este o platformă dinamică şi interactivă, care oferă utilizatorilor posibilitatea de a colabor...
2. Date Interconectate în cadrul Web-ului

    2.1 Conceptul de Date Interconectate
    Web-ul este înŃeles ca un spaŃiu g...
conexiuni între surse de date asemănătoare. Având legături între seturile de date importante este uşor de
a explora conexi...
Începând cu anul 2007, numeroase seturi de date au fost publicate conform principiilor Web-ul
Semantic, descriind date din...
modelului de date RDF şi a felului în care acest model trebuie folosit pentru a fi utilizat în contextul
Datelor Intercone...
informaŃii despre resursa referenŃiată. Articolul „Dereferencing HTTP URIs”23 introduce o distincŃie
asupra felului în car...
non-informaŃională. În cazul reprezentărilor RDF va trimite locaŃia conŃinutului fişierului RDF
     care descrie resursa,...
dereferenŃierea URI-ului http://dbpedia.org/resource/Bucharest cu menŃiunea ca la returnare să obŃinem
un răspuns de tipul...
Figura 3 Modul de afişare a datelor conŃinute de un profil FOAF de către navigatorul Disco

     Persoana descrisă de prof...
RDF spre o resursă care reprezintă lista celorlalte municipii din România.




            Figura 5 Interconectarea cu inf...
2.2.2.1 Beneficii ale folosirii modelului de date RDF în contextul Datelor
Interconectate

     Principalele beneficii38 a...
două URI fac referinŃă la acelaşi lucru. Astfel, owl:sameAs este folosit pentru a mapa alias-uri URI. Un
exemplu care folo...
pentru seturi de date specifice, pentru generarea legăturilor RDF între sursele respective de date. În
continuare prezenta...
application/rdf+xml, atunci o sursă de date trebuie să returneze o descriere RDF/XML a resursei
identificate;
     −    UR...
2.5 Descoperirea Datelor Interconectate
    Modul standard de descoperire a Datelor Interconectate este acela de a urmări ...
3. Logicile Descrierii ca fundament pentru Datele
Interconectate

     3.1 Logicile Descrierii şi separarea TBox - ABox
  ...
A reprezintă elementele ascensionale sau ABox. A este un set finit de propoziŃii – axiome
individuale – de forma a:C, nota...
3.2 Caracteristici specifice DL cu aplicabilitate în Web-ul Semantic

     3.2.1 PrezumŃia de asignare unică de nume
     ...
arhitectura Datelor Interconectate şi vom arăta modul în care tehnicile de interconectare a datelor pot
beneficia de conce...
Orice astfel de set din cadrul diagramei norului LOD (a se vedea Figura 1) este considerat a încorpora
date deschise.

   ...
şi ontologii externe acesteia. Acest lucru permite proprietăŃilor, domenilor şi intervalelor asociate să fie
moştenite de ...
4. Strategii pentru reprezentarea, interconectarea şi
interoperabilitatea datelor în cadrul Web-ului

   4.1 MotivaŃie, tr...
Modelul de software bazat pe servicii este unul în care serviciile sunt configurate pentru a îndeplini
un set de cerinŃe s...
Serviciile sunt accesibile oriunde, având Web-ul ca un unic punct de acces pentru toate nevoile
computaŃionale ale utiliza...
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 c...
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale
Upcoming SlideShare
Loading in...5
×

Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale

3,323

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
3,323
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
110
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale

  1. 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. 2. "Revolution doesn’t happen when society adopts new technologies – it happens when society adopts new behaviors." Clay Shirky 2
  3. 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.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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×