Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale

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

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

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.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

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

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

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

Î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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ş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

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

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

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

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

extinderea capabilităŃilor navigatoarelor sau prin crearea de noi containere de aplicaŃii pentru generaŃia “Web-Desktop Applications” (AplicaŃii mixte Web-Desktop). În direcŃia de extindere a navigatoarelor, rolul cel mai important este adus de extensiile create pentru navigatorul Mozilla Firefox şi de noile îmbunătăŃiri aduse de navigatorul Google Chrome (precum Crash Control, etc). Platforme precum Adobe AIR120 sau Mozilla Prism121 combină beneficiile aduse de Web cu flexibilitatea şi puterea aplicaŃiilor desktop. Aceste platforme sunt jumătate navigatoare, jumătate aplicaŃii desktop şi se dovedesc a fi extrem de eficiente pentru anumite tipuri de aplicaŃii care le pot utiliza. Ele îşi doresc să permită utilizatorilor să treacă de barierele impuse de navigatoarele Web. Single-site browsers (SSB) doresc să aducă tot ce e mai caracteristic desktop-ului înspre aplicaŃi Web. În loc de a rula programe în cadrul navigatoarelor, fiecărei aplicaŃii care rulează în cadrul SSB, i se va asocia o sesiune de navigator dedicată. Avantajele sunt evidente. AplicaŃiilor ca Gmail sau Facebook li se poate asocia o pictogramă pentru acces rapid în cadrul desktop-ului. Elemente nenecesare ca bara de navigaŃie sau controalele navigatorului sunt ascunse, eliminând din zgomotul vizual al interfeŃei. Fiecare aplicaŃie de acest gen rulând în propriul proces elimină posibilitatea de a bloca navigatorul în cazul unei erori. Mozilla Prism este unul dintre primele exemple de SSB. IniŃial a fost cunoscut sub numele de WebRunner şi apoi a fost transformat într-o extensie Firefox. În loc să creeze o nouă platformă pentru aplicaŃii Web de sine stătătoare, Prism doreşte să integreze transparent aplicaŃiile Web existente în cadrul experienŃei desktop. Încercând o tranziŃie cât mai apropiată de ideea de Cloud, observăm mai multe încercări de a fuziona lumile online şi offline. O abordate Web-către-desktop este urmată şi de Google Gears122 care oferă posibilitatea de a extinde aplicaŃiile Web cu capabilităŃi offline. Există un număr limitat de aplicaŃii care pot beneficia de Google Gears, precum YouTube, Zoho, MySpace, Picasa, etc şi pentru care se vor încărca local informaŃiile necesare. De asemenea, noua specificaŃie HTML5 include detalii despre comportamentul aplicaŃiilor web offline123. Adobe AIR (Adobe Integrated Runtime) este similar cu Mozilla Prism în mai multe feluri. Ca instanŃă de navigator foloseşte Safari în loc de Firefox. O altă diferenŃă majoră este aceea că adiŃional de suportul pentru HTML, CSS şi JavaScript, Adobe AIR poate utiliza Flash şi un alt limbaj proprietar, Adobe Flex. Scopul Adobe este acela de a construi şi dezvolta aplicaŃii de tip RIA pentru desktop („desktop connected”). RIA (Rich Web Applications), atât cele bazate navigator, cât şi cele bazate desktop, au jucat un rol important, încapsulând părŃile bune ale fiecărei platforme (Web, desktop). RIA bazate navigator oferă o experienŃă utilizator mai calitativă, în timp ce RIA bazate desktop permit accesul offline asupra resurselor, acces asupra sistemului de fişiere (acest acces fiind de dorit cât mai independent de sistemul de operare). Aceste aplicaŃii au fost posibile datorită existentei Adobe AIR (pe partea de RIA desktop), Flash sau Microsoft Silverlight (pe partea de RIA Web). Combinând tehnologiile Web cu interacŃiunea bogată pe care aplicaŃiile desktop o pun la dispoziŃie, aplicaŃiile rulează indiferent de sistemul de operare şi înafara navigatoarelor, oferind o interacŃiune utilizator consistentă cu experienŃa anterioară a utilizatorilor (modelele drag&drop, o aplicaŃie – o fereastră, etc.). Fiind capabili să interacŃioneze offline cu aplicaŃiile Web, utilizatorii nu mai sunt constrânşi de existenŃa unei conexiuni. În momentul în care conexiunea devine disponibilă, sincronizările se realizează transparent. Astfel, utilizatorii pot lucra local, dar pot să beneficieze în acelaşi timp şi de caracteristicile Cloud-ului. Yahoo BrowserPlus a fost descris de Yahoo ca o tehnologie pentru navigatoare, care să permită dezvoltatorilor să creeze aplicaŃii Web cu capabilităŃi desktop, ca de exemplu drag&drop pentru fişiere 120 http://www.adobe.com/products/air/ 121 http://labs.mozilla.com/2007/10/prism/ 122 http://gears.google.com/ 123 http://dev.w3.org/html5/spec/Overview.html#offline 30

direct în cadrul navigatorului, editare de imagini sau interpretor de Ruby. Live Mesh este un sistem de sincronizare de date de la Microsoft, care permite fişierelor să fie sincronizate şi distribuite în cadrul mai multor tipuri de dispozitive. 4.1.2.4 Spre conceptul de sistem de operare Web WebOS (Web Operating System) este definit ca o platformă software care interacŃionează cu utilizatorii săi prin intermediul unui navigator Web şi care nu depinde în nici un fel de un sistem de operare local. Web Desktop sau Webtop (derivat din „desktop”) este un sistem de aplicaŃii care integrează aplicaŃii Web, servicii Web, aplicaŃii client-server într-un spaŃiu de lucru care oferă o experienŃă similară tradiŃionalului desktop. Este un desktop virtual, bazat Web, fiind o aplicaŃie Web care rulează în cadrul unui navigator şi care se comportă ca un sistem de operare obişnuit. InterfaŃa este similară cu a sistemelor de operare clasice (Windows, Linux, Mac) şi unul din principalele beneficii pe care le aduce, este posibilitatea de a salva propriile fişiere, nu local, ci pe servere aflate la distanŃă, unde sunt disponibile online. Webtop-urile caracterizează migraŃia aplicaŃiilor desktop către navigatoare. Majoritatea aplicaŃiilor uzuale desktop au fost translatate în aplicaŃii de tip RIA. Astfel, Webtop-urile au putut încorpora cât mai multe categorii de aplicaŃii, de genul procesoarelor de texte, managerelor de fişiere, managerelor de procese, etc., care nu sunt altceva decât copii AJAX ale versiunilor originale. AplicaŃiile, datele, fişierele, configurările sau drepturile de acces sunt distribuite la distanŃă, navigatorul reprezentând legătura utilizatorului cu mediul virtual. Webtop-uri permit utilizatorilor să folosească aplicaŃii tradiŃionale pe o platformă comună, care este navigatorul, şi să aibe acces la aplicaŃii şi documente indiferent de sistemul de pe care aceştia provin. Exemple de webtop-uri: EyeOS, DesktopTwo, Cloudo, etc. Următorul pas logic este acela de a înlocui sistemele de operare tradiŃionale (desktop). Problemele pe care acestea le au sunt necesitatea de a instala/dezinstala programe, probleme la nivel de compatibilitate şi versiune, sau bug-uri în cadrul aplicaŃiilor. Este nevoie de un efort pentru a-Ńi proteja sistemul de viruşi, spyware, etc. Există limitări şi legate de hardware, cum ar fi puterea de procesare, memoria, spaŃiul de stocare, acestea având nevoie de o actualizare periodică. Având aceste probleme în minte, calculatoarele ar trebuie să fie mai asemănătoare cu televizoarele. Nu trebuie să ai grijă să instalezi programe, conŃinutul şi funcŃionalitatea oferite provenind dintr-o sursă externă. Singurele griji sunt legate de rezoluŃia, dimensiunea şi calitatea imaginii. Viziunea pentru WebOS este simplă. Este nevoie de existenŃa unui sistem de operare minimal care să booteze, care să încarce driverele necesare pentru a avea suport IO, video, placă de reŃea, etc. şi puterea de a rula o aplicaŃie primară – adică un navigator Web. În acest scenariu majoritatea acŃiunilor şi procesărilor la nivel de aplicaŃie vor avea loc pe Web şi foarte puŃine date vor fi stocate local. Constrângerea principală Ńine de conexiunea Web. În fiecare zi viteza conexiunii la Web se îmbunătăŃeşte şi numărul de persoane care au acces este într-o continuă creştere. Webtop-ul ar fi doar o comoditate şi nu ar reprezenta nimic mai mult decât o interfaŃă. Valoarea stă în aplicaŃiile care sunt puse la dispoziŃie. În acest caz nu ar mai fi probleme de compatibilitate la nivelul sistemului de operare. Aceasta ar reduce dependenŃa de un anumit calculator şi ar da libertate utilizatorilor de a se conecta în spaŃiul lor personalizat de oriunde, având doar nevoie de o conexiune. Astfel nu ar mai fi nevoie nici de sincronizări între diversele calculatoarele pe care utilizatorii le deŃin. Astăzi, din ce în ce mai multe aplicaŃii Web încearcă să înlocuiască tradiŃionalele aplicaŃii desktop, astfel conceptul de sistem de operare bazat pe Web a câştigat tot mai mulŃi adepŃi, devenind noua frontieră. gOS este o distribuŃie minimală Linux cu un focus orientat Web, care a fost lansată ca un sistem de operare. Aceasta promovează suita de aplicaŃii Google (Gmail, GNews, GCalendar, GMaps, GDocs, YouTube (online video), Blogger (blogging)) şi alte aplicaŃii Web de tipul Facebook (social 31

networking), Wikipedia (reference), Meebo (chat). Din cadrul aplicaŃiilor desktop standard care au fost păstrate în cadrul distribuŃiei sunt Firefox, suita OpenOffice, GIMP (image editing), Skype (VoIP), Rhythmbox (music) şi Xine (video). Creatorii gOS au lansat gOS Cloud, un sistem de operare al cărui focus este doar mediul online. Spre deosebire de gOS, gOS Cloud nu mai trece prin stadiul intermediar desktop, ci înlocuieşte toată interfaŃa sistemului de operare cu un navigator Web (bazat pe navigatorul Google Chrome), care afişează ca pagina de start un motor de căutare (Live Search, Google sau Yahoo). gOS Cloud permite din cadrul navigatorului schimbare volumului, schimbarea sistemului de operare sau selecŃia reŃelei wireless. Metafora păstrata din cadrul desktop este doar bara de aplicaŃii (dock, launcher), care permite accesul rapid la acestea. Noul tip de interfaŃă de bază pe care gOS Cloud îl promovează este “Search as Interface”. Dezavantajul acestui tip de “sistem de operare” este acela de a fi incapabil să ruleze aplicaŃii mai complexe, de genul Microsoft Office, Adobe Photoshop, etc. Din cauză că suportul este momentan doar pentru aplicaŃii Web, audio & video, gOS Cloud este recomandat să fie distribuit la pachet cu un alt sistem de operare matur (Windows XP, gOS, Linux, etc). Utilizatorii din ziua de azi nu mai folosesc la fel de multe aplicaŃii desktop ca altă dată, dar totuşi există anumite aplicaŃii pentru care nu există o translaŃie completă către versiunea pentru Cloud. Un exemplu este Adobe Photoshop, care deşi există mai multe aplicaŃii Web de editare de imagini, nici una dintre acestea nu se ridică la complexitatea iniŃială. AplicaŃii de tip Microsoft Office sunt un exemplu de suită care au avut o tranziŃie totală spre Web. Astfel, încă mai este de aşteptat momentul în care vom putea realiza în cadrul Web-ului animaŃii, editare video, dezvoltare de software sau să beneficiem de complexitatea jocurilor actuale. Totuşi, desktop sau Web, acestea sunt doar platforme care ne ajută la crearea, colaborarea, distribuŃia, managementul şi prezentarea informaŃiei existente. Indiferent de varianta pe care le alegem, accentul este pus pe productivitatea, scalabilitatea şi viteza pe care aceasta ne-o oferă fiecăruia în parte. 4.2 Alegerea vocabularelor potrivite pentru reprezentarea informaŃiei Pentru a fi cât mai uşor pentru aplicaŃiile client să proceseze datele furnizate, este necesară reutilizarea termenilor din vocabulare existente şi utilizate la scară largă. Definirea termenilor noi se face doar când nu se găsesc termenii necesari în cadrul vocabularelor existente. În ultimii ani mai multe vocabulare au evoluat în comunitatea Web-ului Semantic, de exemplu: − Friend-of-a-Friend124 (FOAF), vocabular pentru descrierea persoanelor; − Dublin Core125 (DC) defineşte metadate general folosite pentru descrierea resurselor informaŃionale online, ca text, imagini, video sau pagini Web; − Semantically-Interlinked Online Communities126 (SIOC), vocabular pentru reprezentarea comunităŃilor online; − Description of a Project127 (DOAP), vocabular pentru descrierea proiectelor; − Simple Knowledge Organization System128 (SKOS), vocabular pentru reprezentarea taxonomiilor şi a cunostiintelor slab structurate; − Music Ontology129 furnizează termeni pentru descrierea artiştilor, albumelor şi a melodiilor; − Review Vocabulary130, vocabular pentru reprezentarea recenziilor; − Publ131, termeni care descriu publicaŃiile printate; 124 http://xmlns.com/foaf/spec/ 125 http://dublincore.org/documents/dcmes-xml/ 126 http://sioc-project.org/ 127 http://trac.usefulinc.com/doap 128 http://www.w3.org/2004/02/skos/ 129 http://musicontology.com/ 130 http://vocab.org/review/terms.html 32

− NMO132, utilizat pentru reprezentarea structurilor de tip email şi mesaje instante; − NFO133, pentru descrierea fişierelor de orice tip; − iCal134, pentru descrierea datelor calendaristice; − owlTime135, pentru descrierea noŃiunilor temporale; − geo136, pentru reprezentarea locaŃiilor geografice; − SCOT137, pentru asocierea de etichete descriptive conŃinutului; − Creative Commons138 (CC), vocabular pentru descrierea licenŃelor. O listă extinsă de alte vocabulare139 este întreŃinută de comunitatea W3C SWEO140 (Semantic Web Education and Outreach) în cadrul proiectului “Linking Open Data”141. O listă de seturi de date 142 dereferenŃiabile prin URI este menŃinută de aceeaşi comunitate. 4.3 Interconectarea comunităŃilor online 4.3.1 FOAF – Friend of a Friend Cel mai cunoscut şi utilizat vocabulat în cadrul Web-ului Semantic este FOAF143. FOAF descrie persoane împreună cu activităŃile acestora şi relaŃiile lor cu alte persoane sau obiecte. FOAF permite descrierea de reŃele sociale fără a fi necesară existenŃa unei baze de date centralizate. FOAF defineşte clase precum foaf:Person, foaf:Document, foaf:Image, împreună cu proprietăŃi specifice claselor, precum foaf:name, foaf:mbox, foaf:homepage, etc. Un tip de relaŃie notabil este foaf:depiction, care relaŃionează o clasă foaf:Person cu o clasă foaf:Image, pentru a identifica o persoană surprinsă în fotografie. O ontologie conŃine clase şi proprietăŃi care capturează cunoştiinŃele existente despre un anumit subiect. Pentru a putea încapsula cunoştinŃe despre o anumită persoană a fost realizată specificaŃia FOAF. Pentru a descrie o persoană pe Web este nevoie de încadrarea ei în clasa foaf:Person şi conectarea cu atribute specifice, ca nume, gen, sau alte resurse. Se pot menŃiona interesele persoanei prin folosirea proprietăŃii foaf:interest sau adresa de email prin folosirea proprietăŃii foaf:mbox. Un mod de identificare unică este dat prin folosirea proprietăŃii foaf:openid, conform perspectivei OpenID144, care asociază un URI unic pentru stabilirea identităŃii. Fiecare persoană cunoscută de utilizator va fi de asemenea mapată cu clasa foaf:Person. FOAF este cea mai folosită specificaŃie pentru exprimarea datelor personale şi a relaŃiilor cu alte persoane. Una din proprietăŃile de interes deŃinute de specificaŃie este foaf:holdsAccount, care asociază unui utilizator conturi ale aplicaŃiilor Web pe care acesta le foloseşte. Contul este descris folosind clasa foaf:OnlineAccount, care aparŃine serviciului identificat prin foaf:accountServiceHomepage. FOAF este folosită ca o extensie pentru alte ontologii, ca de exemplu SIOC145. 131 http://ebiquity.umbc.edu/ontology/publication.owl 132 http://www.semanticdesktop.org/ontologies/2007/03/22/nmo/ 133 http://www.semanticdesktop.org/ontologies/2007/03/22/nfo/ 134 http://www.w3.org/2002/12/cal/ 135 http://www.w3.org/TR/owl-time/ 136 http://www.w3.org/2003/01/geo/ 137 http://scot-project.org/scot/ 138 http://creativecommons.org/ns 139 http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies 140 http://esw.w3.org/topic/SweoIG 141 http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData 142 http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets 143 http://xmlns.com/foaf/spec/ 144 http://openid.net/ 145 http://rdfs.org/sioc/spec/ 33

4.3.2 SIOC – Semantically-Interlinked Online Communities Dezvoltarea comunităŃilor online a oferit utilizatorilor Web un spaŃiu virtual unde aceştia îşi pot exprima gândurile, pot primi critici şi răspunsuri, şi pot interacŃiona cu indivizi cu care împart aceleaşi principii şi interese. Fiecare comunitate poate fi văzută ca o insulă de cunoştiinŃe unice. Proiectul SIOC se concentrează pe modalităŃi de a conecta şi integra aceste insule de cunoaştere, oferind punŃi de legătură între cunoştiinŃele deŃinute. Din considerente de portabilitate a datelor, SIOC furnizează specificaŃii care se vor folosi în cazul în care se vor exporta date din cadrul sit-urilor care deŃin grupuri, forum-uri sau alte servicii sociale. SIOC permite capturarea interacŃiunii între indivizi şi este capabil să exprime rolurile pe care indivizii le pot juca în cadrul spaŃiilor respective. SIOC va facilita localizarea informaŃiei relevante şi înrudite, depăşind limitaŃiile curente şi favorizând informaŃia să fie accesibiliă utilizatorilor săi într-un mod eficient. Principalul beneficiul adus de SIOC este posibilitatea de interconectare a diferite tipuri de entităŃi din cadrul a multiple varietăŃi de sit-uri. Dacă un email menŃionează un URI către un articol, atunci se creează o legătură între containerul de informaŃie şi respectivul sit. InformaŃiile adiŃionale pot fi înglobate şi pot permite utilizatorului să navigheze direct către acea informaŃie. La ora actuală, comunităŃiile online sunt ca nişte insule care nu sunt interconectate. Utilizarea ontologiilor şi a tehnologiilor Web-ului Semantic oferă o cale de îmbunătăŃire a comunităŃiilor online spre oferirea de servicii mai complexe. Ontologia SIOC146 combină termeni din vocabulare deja existente cu noi termeni necesari descrierii relaŃiilor existente în cadrul comunităŃiilor online. Proiectul SIOC147 s-a orientat spre modelarea datelor sociale din cadrul Web-ul folosind tehnologiile Web-ului Semantic. În timp ce serviciile sociale media au introdus noi tendinŃe şi practici legate de felul în care oamenii ar trebui să-şi publice şi transmită datele în cadrul Web-ului, popularitatea acestora a ridicat anumite probleme, ca interoperabilitatea reŃelelor sociale şi schimbul de informaŃii sociale în cadrul aplicaŃiilor. Datorita naturii eterogene a modelelor folosite de furnizorii de aplicaŃii sociale, căutarea, interconectarea şi interogarea datelor a reprezentat o problemă. Viziunea de a combina tehnologii ale Web-ului Semantic cu paradigme sociale va tinde către crearea de “spaŃii informaŃionale sociale semantice” (Social Semantic Information Spaces148), unde informaŃia este creată şi menŃinută în mod social în acelaşi timp în care este interconectată şi înŃeleasă de către maşini. Scopul SIOC este de a realiza un cadru pentru modelarea activităŃilor şi contribuŃiilor media sociale prin folosirea de standarde şi tehnologii semantice. Pentru a avea utilizate aceleaşi semantici în cadrul a multiple servicii media şi aplicaŃii, SIOC se bazează pe următorii paşi: − producerea datelor – acest pas are nevoie atât de un vocabular care sa poată modela datele, cât şi de o aplicaŃie care sa le producă şi care să includă posibilitatea de a exporta datele către alte aplicaŃii deja existente, RDBMS, sisteme de mapare RDF sau aplicaŃii native SIOC; − căutarea şi găsirea datelor – datorită naturii distributive a Web-ului, datele SIOC trebuie să fie căutate şi găsite într-un mod eficient. Eforturile în această direcŃie sunt reprezentate de extensia Firefox pentru descoperirea datelor RDF, Semantic Radar149, cât şi de motoare de căutare semantice, ca Sindice150; − utilizarea datelor – descrisă prin crearea de aplicaŃii care ştiu să producă datele SIOC, dar şi a celor care ştiu să reutilizeze şi consume aceste date. 146 http://rdfs.org/sioc/spec/ 147 http://sioc-project.org/ 148 http://www.w3.org/2008/09/msnws/papers/sioc.html 149 http://sioc-project.org/firefox 150 http://www.sindice.com/ 34

4.3.2.1 Ontologia SIOC Unul din scopurile principale ale ontologiei SIOC a fost acela de a găsi un echilibru între simplitate şi putere pentru a putea fi cât mai uşor integrată în cadrul aplicaŃiilor existente. Ontologia SIOC utilizează specificaŃii existente oferite de FOAF şi RSS151, pentru a-şi defini clasele şi proprietăŃile proprii. Ontologia SIOC conŃine clase abstracte, care descriu cunoştinŃe asociate cu comunităŃile online: Community, Container, Forum, Item, Post, Role, Site, Space, Thread, User, Usergroup. Scopul SIOC este acela de a interconecta comunităŃile online. Sit-urile comunităŃilor pot include liste de email-uri, blog-uri, buletine de anunŃuri, toate acestea fiind grupate în cadrul conceptului de forum. În timp ce nucleul SIOC oferă un model suficient pentru a descrie activităŃile comunităŃilor online, acesta nu este destul de minuŃios pentru a face diferenŃa între un articol de blog şi o actualizare a unui serviciu de microblogging, deoarece deŃine o singură clasa sioc:Post. SIOC este modelat astfel încât să fie uşor de extins prin adăugarea de noi module. Pentru a avea nivele adiŃionale semantice, s-a introdus un modul152 de tipuri de SIOC, care modelează mai bine de 20 de tipuri de conŃinut: − Container: AddressBook, AnnotationSet, AudioChannel, BookmarkFolder, Briefcase, EventCalendar, ImageGallery, ProjectDirectory, ResumeBank, ReviewArea, SubscriptionList, SurveyCollection, VideoChannel, Wiki; − Item: Poll; − Forum: ArgumentativeDiscussion, ChatChannel, MailingList, MessageBoard, Weblog; − Post: BlogPost, BoardPost, Comment, InstantMessage, MailMessage, WikiArticle. Figura 10 Nucleul ontologiei SIOC 4.3.2.2 RelaŃia dintre SIOC şi alte vocabulare semantice SIOC reutilizează153 modelul Dublin Core154 pentru definirea a diverse atribute conŃinutului care poate fi creat, cum ar fi data creării prin folosirea termenului dcterms:created. De asemenea reutilizează vocabularul FOAF pentru a modela identităŃi personale şi atribute specifice. Interconectarea FOAF cu SIOC furnizează un model pentru reprezentarea unitară a aplicaŃiilor din cadrul Web-ului. O singură persoană poate deŃine mai multe conturi pe site-uri diferite (fiind reprezentat ca instanŃe de sioc:User) în timp ce identifică aceeaşi persoană fizică (foaf:Person). Pentru a consolida URI-urile şi a fuziona informaŃie înrudită, se pot folosi următoarele proprietăŃi pentru a reprezenta identitatea obiectelor existente: − owl:sameAs folosit pentru a afirma că două resurse sunt identice, chiar dacă deŃin URI-uri 151 http://purl.org/rss/1.0/ 152 http://rdfs.org/sioc/types 153 http://www.w3.org/Submission/sioc-related/ 154 http://dublincore.org 35

diferite; − rdfs:seeAlso folosit de motoarele de căutare şi navigatoarele semantice, precum Tabulator155, pentru a extrage informaŃie adiŃională legată de o resursă. Folosind aceste proprietăŃi în cadrul unui context distribuit şi multi-serviciu, putem interconecta şi conecta URI-uri care reprezintă aceleaşi concepte. infoiasi:evalica owl:sameAs blogger:risherry owl:sameAs delicious:evalica owl:sameAs twitter:evalica MulŃumită acestor tipuri de relaŃii, se poate realiza o reprezentare a tuturor contribuŃiilor aduse de o persoana fizică (prin intermediul conturilor sale virtuale) într-un singur graf de date RDF, devenind un model pentru interoperabilitate şi portabilitate a datelor sociale între serviciile folosite de respectiva persoană. <sioc:Post rdf:about=“http://risherry.blogspot.com/2009/05/xwiki-design-proposals-i-always- wanted.html”> <dcterms:title>XWiki Design Proposals</dcterms:title> <dcterms:created>2009-05-19T15:10:30Z</dcterms:created> <sioc:has_container rdf:resource=“http://risherry.blogspot.com?sioc_type= risherry.blogspot.com#weblog”/> <sioc:has_creator> <sioc:User rdf:about=“http://www.blogger.com/profile/04274242221944682444” rdfs:label=“risherry”/> </sioc:has_creator> <sioc:content> XWiki is an open source project with an amazing active community of people that use the software and want to make it better...</sioc:content> <sioc:topic rdfs:label=“XWiki” rdf:resource=“http://risherry.blogspot.com/search/label/XWiki”/> <sioc:topic rdfs:label=“Mockups” rdf:resource=“http://risherry.blogspot.com/search/label/Mockups”/> <sioc:has_reply> <sioc:Post rdf:about=“https://www.blogger.com/comment.g?blogID=30407244& postID=6261819087963651469?sioc_type=comment”/> </sioc:has_reply> </sioc:Post> Conceptele menŃionate afirmă existenŃa un obiect de tip sioc:Post identificat prin http://risherry.blogspot.com/2009/05/xwiki-design-proposals-i-always-wanted.html, care are următoarele proprietăŃi: − dcterms:title, proprietate cu valoarea “XWiki Design Proposals”; − dcterms:created, proprietatea în format ISO-8601156 cu valoarea datei 2009-05-19T15:10:30Z; − sioc:has_container, relaŃie cu un obiect identificat prin http://risherry.blogspot.com?sioc_type= risherry.blogspot.com#weblog, care identifică un obiect de tip sioc:Forum (în acest caz un weblog) care conŃine postul respectiv; − sioc:has_creator, relaŃie cu un obiect sioc:User numit “risherry” şi identificat prin adresa http://www.blogger.com/profile/04274242221944682444?sioc_type=user; − sioc:content, proprietatea cu o reprezentare în mod text a conŃinutului postului; − sioc:topic, proprietate care indică topicele “XWiki” identificat prin http://risherry.blogspot.com/search/label/XWiki şi subiectele “Mockups” identificat prin http://risherry.blogspot.com/search/label/Mockups; − sioc:has_reply, relaŃie (care directează spre comentariile postului) cu un obiect de tip sioc:Post identificat prin https://www.blogger.com/comment.g?blogID=30407244& 155 http://www.w3.org/2005/ajar/tab 156 http://tools.ietf.org/html/rfc3339 36

postID=6261819087963651469 ?sioc_type=comment; În alte cuvinte: • Există un post numit “XWiki Design Proposals” creat la ora 15:10:30 pe data de 2009-05-19 scris de un utilizator pe nume “risherry” în categoriile “XWiki” şi “Mockups” cu conŃinutul descries în sioc:content; • Mai multe informaŃii despre autor se pot găsi la adresa http://www.blogger.com/profile/04274242221944682444; • Postarea are un comentariu şi informaŃii despre comentariu se pot găsi la https://www.blogger.com/comment.g?blogID=30407244&postID=6261819087963651469?si oc_type=comment; Acest exemplu ilustrează folosirea a două clase de obiecte sioc:Post şi sioc:User. Exemplul următor utilizează alte clase SIOC pentru a descrie mai multe informaŃii despre utilizatori, sit-uri şi alte obiecte. SIOC poate fi folosit în mod adiŃional pentru asocierea multiplor identităŃi pe care o persoană poate să le deŃină în mediul online. Folosind foaf:holdsAccount şi sioc:account_of, toate postările sau comentariile adresate sau create de o anumită persoană vor fi identificate, chiar dacă provin din cadrul a conturi diferite. Figura 11 Modelarea datelor folosind SIOC, FOAF şi SKOS În Figura 10, Ecaterina deŃine conturi pe mai multe sit-uri sociale (în acest exemplu delicious157 şi Blogger158) şi prin intermediul acestor conturi crează conŃinut, care de obicei este păstrat în containere specifice tipului de aplicaŃie, ca un director de bookmark-uri, blog-ul personal sau galerie de imagini. Având la dispoziŃie un astfel de graf, se va putea reutiliza şi exporta atât graful social (conexiunile cu Sabin şi Raluca), cât şi containerele personale de conŃinut şi comentariile asociate acestora. Conceptul de sioc:User este văzut ca punct central al acestei ontologii, unde sioc:User este subclasă de foaf:OnlineAccount. Ontologia SIOC are definite proprietăŃi care relaŃionează utilizatorul cu fiecare din clasele componente. Proprietatea sioc:has_moderator descrie relaŃia pe care un forum o are cu persoana care îl monitorizează, în timp ce proprietatea sioc:has_administrator descrie relaŃia unui sit Web cu persoana care îl gestionează, etc. 157 http://delicious.com/ 158 https://www.blogger.com/ 37

4.3.3 SKOS - Simple Knowledge Organisation Systems SKOS159 este un model pentru exprimarea structurilor de bază şi conŃinutului schemelor conceptuale, cum ar fi tezaure, scheme de clasificare, liste de subiecte, taxonomii, “folksonomii” sau alte tipuri de vocabulare controlate. Nucleul vocabularului SKOS160 este format din resurse RDF. Utilizarea RDF permite datelor să fie conectate şi/sau îmbinate cu alte surse de date, care sunt distribuite în cadrul aplicaŃiilor Web-ului Semantic. În practică, acest lucru înseamnă ca sursele de date pot fi distribuite într-o manieră descentralizată, dar în acelaşi timp pot fi integrate şi compuse într-un mod relevant şi inovator de către aplicaŃii. Nucleul vocabularului SKOS reprezintă o mulŃime de proprietăŃi RDF şi clase RDF-S, care pot fi folosite pentru a exprima conŃinut şi structura unei scheme de concept cu ajutorul unui graf RDF. Fiind o schemă RDF , SKOS adaugă limbaj adiacent şi defineşte relaŃii suplimentare bazei clasice RDF. Cu SKOS se pot defini orice tip de concept, având integrate relaŃii de tip broader şi narrower, care permit modelarea relaŃiilor ierarhice, cât şi relaŃii de tip related sau member. <skos:Concept rdf:about=“http://domeniu.ro/#weblog”> <skos:prefLabel>Weblog</skos:prefLabel> <skos:altLabel>Blog</skos:altLabel> <owl:sameAs rdf:resource=“http://xmlns.com/wordnet/1.6/Blog”/> </skos:Concept> <skos:Concept rdf:about=“http://domeniu.ro/weblog#post”> <skos:prefLabel>Post</skos:prefLabel> <skos:altLabel>Weblog Entry</skos:altLabel> <skos:altLabel>Blog Entry</skos:altLabel> <skos:broader rdf:resource=“http://domeniu.ro/#weblog”/> <skos:narrower rdf:resource=“http://domeniu.ro/weblog#comment”/> </skos:Concept> <skos:Concept rdf:about=“http://domeniu.ro/weblog#comment”> <skos:prefLabel>Comment</skos:prefLabel> <skos:broader rdf:resource=“http://domeniu.ro/weblog#post”/> </skos:Concept> Putem utiliza un concept sioc:Post, care utilizează un skos:Concept pentru proprietatea skos:subject, pentru a indica tipul mesajului. În acest fel conceptul sioc:Post este definit în cadrul domeniilor folosite. O intrare în cadrul blog-ului va fi de tipul sioc:Post şi va avea ca skos:subject http://domeniu.ro/weblog#entry. Un răspuns la acest post va fi de tipul sioc:Post şi va avea ca skos:subject http://domeniu.ro/weblog#comment. 4.4 Interconectarea informaŃiilor personale 4.4.1 MotivaŃie Un aspect foarte important, care nu este realizat încă la ora actuală, este acela de a avea aplicaŃii cât mai apropiate de modelul mental al utilizatorilor. Pentru a persoană nu este deloc important mediul în care documentele sale se găsesc, sau formatul documentelor, ci lucrurile-persoanele-evenimentele pe care documentele le descriu. Biologii sunt interesaŃi de proteine, gene şi medicamente. Oamenii de afaceri sunt interesaŃi de clienŃi, produse şi vânzări. Majoritatea persoanelor sunt interesate de prieteni, familie, colegi sau cunoştinŃe. Web-ul furnizează doar documente dispersate care identifică persoane separate, în cadru a sit-uri şi conturi diferite, care de cele mai multe ori descriu acelaşi lucru. Scopul Web-ului este acela de a realiza legături între lucruri. Dorim ca relaŃiile dintre persoanele 159 http://www.w3.org/TR/skos-reference/ 160 http://www.w3.org/TR/2009/CR-skos-reference-20090317/skos.html 38

pe care le cunoaştem să fie centralizate şi să dispunem oricând de graful social. Acelaşi lucru îl dorim aplicat şi documentelor, evenimentelor şi intereselor pe care le avem. Scopul nu este acela de a naviga într-un Web de documente sau de date, ci în propriul Web. Productivitatea, reutilizarea, personalizarea şi managementul semantic a datelor se află printre beneficiile aduse de un astfel de model de navigare. Fiecare tip de serviciu folosit are cerinŃele sale proprii. Serviciile sociale pot avea nevoie doar de schimbul de mesaje între utilizatori, în timp ce alte servicii se pot concentra mai mult pe schimbul de documente, coordonarea de calendare, contacte, etc. Există numeroare modalităŃi de a realiza schimb de informaŃie, atât sincrone, cât şi asincrone, între doi sau mai mulŃi participanŃi, ca de exemplu email-urile, chat-urile, blog-urile, wiki-urile, etc. Cele mai multe dintre aceste instrumente stochează informaŃia într-o formă semi-structurată sau în cadrul bazelor de date. Sit-urile sunt găzduite pe sisteme independente care nu pot fi interconectate datorită diferenŃelor de interfaŃă şi aplicaŃie. Pot exista în cadrul a diferite sit-uri discuŃii paralele despre subiecte asemănătoare, fără ca utilizatorii să fie conştienŃi de acest lucru. Există o cantitate foarte mare de informaŃie înrudită care ar putea fi exploatată. 4.4.1.1 Scenarii de utilizare Se observă o explozie a datelor regăsite în cadrul Web-ului. Un număr din ce în ce mai mare de persoane produc conŃinut (articole, imagini, video-uri, etc) şi le distribuie în cadru a sit-uri ca Flickr, YouTube sau Blogger. Totuşi lucrul care lipseşte din acest peisaj sunt legăturile între aceste resurse, legături care ar permite recomandări, conectare multi-sit, identificarea în mod eficient a părŃi de conŃinut care interesează pe utilizator, etc. O căutare care să returneze rezultate din cadrul a sit-uri multiple este imposibilă. Cel mai evident motiv pentru acest lucru este lipsa metadatelor asociate conŃinutului. Dacă conŃinutul ar avea asociat metadate atunci ar putea exista mashup-uri care să combine nu numai API-uri, ci şi să combine informaŃiile şi la un nivel semantic. Un exemplu de acest gen este Joost161. DeŃinând metadate despre conŃinutul video, articole, feed-uri de ştiri şi despre utilizatorii sistemului, Joost permite urmărirea selectivă, în funcŃie de preferinŃe, a pieselor muzicale, emisiunilor sau filmelor, în genul programelor TV tradiŃionale, însă prin intermediul Internet-ului. În cadrul organizaŃiilor, utilizatorii se comportă ca nişte colaboratori, care au de îndeplinit sarcini şi au obiective comune. Aceşti utilizatori au un stil dinamic de lucru şi sarcinile pe care trebuie să le realizeze sunt contrânse de limite de timp şi de distribuŃia geografică a ulitizatorilor. Colaboratori sunt utilizatorii care au interacŃiuni zilnice, legate de proiecte comune, şi care de cele mai multe ori se cunosc personal ca indivizi. De obicei colaboratorii sunt grupaŃi în cadrul echipelor, departamentelor sau grupurilor, având cerinŃe similare de informaŃie necesară. Cheia reuşitei pentru sarcinile colaborative este împărtăşirea de seturi comune de informaŃie, care ajută la îndeplinirea obiectivelor. Seturile de informaŃie pot conŃine de la descrierea sarcinii, a participanŃilor şi a obiectivelor, până la documente ataşate, email-uri şi evenimente calendaristice. Fiecare participant trebuie să poată adăuga, edita sau şterge informaŃii, ataşa noi documente, noi participanŃi sau să poată schimba statusul progresului sarcinii. Toate proprietăŃile de mai sus sunt satisfăcute prin utilizarea de wiki-uri, un exemplu de platformă wiki este XWiki162. 161 http://www.joost.com/ 162 http://www.xwiki.org/ 39

4.4.2 Managementul InformaŃiilor Personale Utilizatorii de calculatoare deŃin foarte multe informaŃii salvate pe calculatoarele personale, pe calculatoarele de servici sau informaŃii disparate în cadrul a diverse aplicaŃii Web. Scopul dorit este acela de a conecta toate aceste informaŃii în cadrul unui Web Semantic. Persoanele au tendinŃa de a grupa informaŃia după conŃinut, context şi să reŃină relaŃiile între cele mai importante elemente, cum ar fi asocierea unei persoane cu compania pentru care lucrează. AplicaŃiile sunt capabile de a aduna informaŃii în mod automat şi permit utilizatorilor să asocieze conŃinut semantic respetivelor date. InformaŃie adiŃională semantică se autogenerează prin inspectarea şi realizarea de raŃionamente din conexiunile între elementele cunoscute. Oferind sens documentelor, datelor de contact, imaginilor, video-urilor sau oricărui tip de date deŃinut de utilizator, aplicaŃiile care folosesc aceste date pot să identifice conexiuni între componente diverse şi să faciliteze modul de operare şi regăsire a datelor necesare utilizatorilor. Toate fişierele unui utilizator alcătuiesc perspectiva personală asupra lumii a utilizatorului. Aceste date pot fi utilizate pentru realizarea de vizualizări ale modului de lucru sau modului de socializare a unui utilizator. CunoştiinŃele umane consistă din receptarea, interpretarea şi structurarea informaŃiei în reprezentări potrivite (ca text sau imagini), care pot fi apoi împărtăşite, distribuite şi modificate de alŃi participanŃi. Utilizarea acestor metode vor transforma serviciile folosite într-un instrument de gestiune eficientă a spaŃiului personal de cunoştiinŃe. Managementul Informatiilor Personale (PIM163 – Personal Information Management) se referă de obicei la managementul informaŃiilor de contact, întâlnirilor, notelor sau obiectivelor zilnice care trebuiesc îndeplinite. Rolul şi natura PIM s-a schimbat în ultima perioadă. Managementul calendarului, listelor de contacte şi de obiective nu se referă numai la informaŃiile pe care utilizatorul le produce, ci înglobează şi alte tipuri de date, ca feed-uri RSS, pagini Web, fişiere media şi metadatele asociate. Există din ce în ce mai multe date care trebuie gestionate şi manipulate, şi acestea provin din multiple surse, sisteme de operare şi dispozitive mobile. Înafară de gestiunea eficientă a datelor personale s-ar putea dori şi managementul personal al sarcinilor de lucru. Posibilitatea de a avea o perspectivă asupra lucrurilor care trebuie realizate, structurarea activităŃilor zilnice sau a termenelor limită pentru proiectele asociate, gestiunea cooperării între membrii echipei sau raportarea realizărilor. Acestea sunt câteva din provocările cu care se confruntă colaboratorii atunci când lucrează în cadrul a multiple proiecte paralele. 4.4.2.1 Modelare pentru gestiunea informaŃiilor personale Dorim să realizăm o ontologie care modelează principalele concepte implicate în activitatea zilnică a unei persoane: locuri, organizaŃii, persoane, 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ă. Utilizatorii virtuali au un set bine stabilit de activităŃi zilnice cum ar fi trimiterea de email-uri, navigarea paginilor Web, descărcarea de fişiere, etc. 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 este acela de a integra toate aceste date eterogene într-o bază de cunoştinŃe formală, uşor de 163 Jones, W. P., Teevan, J., „Personal information management”, University of Washington Press, 2007 40

gestionat şi de distribuit cu alŃi 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. Figura 12 RelaŃii între clase necesare interconectării comunităŃilor online În momentul în care se încearcă asocierea de informaŃii în cadrul unei noi ontologii, există discuŃia dacă termenii conŃinuŃi să fie interconectaŃi şi reutilizaŃi din cadrul ontologiilor deja existente şi cunoscute, sau dacă este necesară construirea unei ontologii complet noi. În cel de al doilea caz există mai multă flexibilitate, dar vor fi ulterior necesari algoritmi de citire, mapare şi de transformare a datelor conŃinute dintr-o formă cunoscută în altă formă. Mapările actuale între ontologiile existente se realizează folosind owl:equivalentProperty şi owl:equivalentClass, problema rămasă fiind efectuarea mapărilor într-un mod cât mai eficient. Unde este posibil, se vor folosi termeni din ontologii existente, pentru a elimina costurile de mapare de termeni noi şi deoarece, utilizarea unor termeni deja consacraŃi, interconectează Web-ul şi mai strâns. O sarcină importantă, care ar putea fi rezolvată prin integrarea acestor ontologii în cadrul descrierii informaŃiilor furnizate, este sugerarea de informaŃie relevantă şi înrudită cu obiectele active folosite de utilizatori. O primă abordare ar fi căutarea, prin utilizarea motoarelor de căutare, a anumitor elemente, ca autor, titlu, cuvinte cheie, în cadrul tuturor resurselor existente. Totuşi această abordare nu beneficiază de înŃelegerea resurselor în care caută şi din acest motiv, se returnează foarte multe rezultate irelevante. Folosind elemente, care reuşesc să descrie informaŃia într-o manieră înŃeleasă de calculatoare, se îmbunătăŃeşte procesul de căutare şi sugerare. Datele care trebuie gestionate folosind ontologia: − Calendar şi evenimente: date, participanŃi, invitaŃii, evenimente anuale, notificări, managementul timpului liber; − Listă de contacte: persoane, adrese, numere de telefon, avatare, relaŃii între grupuri de indivizi; − LocaŃii: corelate de evenimente şi de persoanele de contact; − Gestiunea fluxului de lucru: managementul proiectelor, liste de obiective, liste de sarcini; − Email-uri şi mesaje instante: primirea şi transmiterea de email-uri integrate cu toate datele de mai sus, gestiunea mesajelor instante; − Gestiunea fişierelor: pagini Web, documente text, foi de calcul, fişiere multimedia (foto, video, audio); − Categorii şi interese: care se pot asigna oricărui element menŃionat; − Analiza datelor: raŃionamente, extragerea de cuvinte cheie, sortare şi grupare; Principala provocare, în cazul ontologiilor generale de acest gen, este adopŃia de către sit-uri. Este nevoie de adopŃia de către furnizorii de date a acestui mod de expunere a informaŃiei. O altă provocare este integrarea celor mai bune componente, provenite din cadrul altor ontologii. Acest lucru se rezolvă parŃial prin tehnici de mapare şi oferire de interfeŃe către ontologii comune. 41

4.4.2.2 Suite de aplicaŃii SaaS Tehnologiile Web-ului Semantic pot fi folosite pentru a integra infomaŃii oferite de diverse aplicaŃii, ca 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. Datorită tranziŃiei înspre sistemele de operare 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 acoperă toate cerinŃele managementului informaŃiilor personale. Pentru un sistem de operare care poate rula în cadrul Web-ului (Web OS) avem nevoie de exploatarea fişierelor, mesajelor, documentelor, imaginilor, evenimentelor şi contactelor. Aceste surse trebuie să poată fi navigate, căutate, adnotate şi conectate unele cu altele. Un astfel de exemplu este suita Google164. Google nu înseamnă numai un motor de căutare, ci oferă peste 50165 de API-uri, acoperind o gamă diversă de servicii, precum: cartografiere, distribuŃie de imagini, prelucrare de documente, calendar, email, etc. Suita de aplicaŃii Google permite crearea, stocarea, distribuŃia, căutarea, arhivarea, analiza şi managementul a diverse tipuri de informaŃie ca documente, contacte, imagini, pagini Web, locaŃii, etc. AplicaŃiile care fac parte din această suită sunt: − Google Search, permite căutarea informaŃiei în cadrul Web-ului; − Google Calendar (GCalendar), este o aplicaŃie care afişează multiple calendare în mod concurent; − Google Documents (GDocs), permite crearea şi gestiunea de documente text, foi de calcul tabelar, etc; − Google Mail (GMail), este o aplicaŃie Web, care permite utilizatorilor transmiterea şi organizarea de email-uri, contacte şi conversaŃii; − Google Contacts, pentru gestiunea contactelor − Google Talk (GTalk), este un serviciu de IM (Instant Messaging) care permite utilizatorilor trimiterea de mesaje text instant şi apeluri voce către alŃi utilizatori. − Google Maps (GMaps), pentru corelarea datelor cu locaŃia lor geografică − Google Tasks, pentru gestiunea sarcinilor; − YouTube (online video), pentru distribuirea de video; − Picasa, pentru vizualizarea şi editarea de imagini; − Blogger, pentru crearea şi gestiunea blog-urilor personale; − Google Bookmarks, pentru gestiunea şi stocarea paginilor Web preferate; − Google Reader (GReader), pentru gestiunea ştirilor provenite din cadrul sit-urilor preferate. Toate aplicaŃiile mai sus menŃionate se încadrează în categoria de aplicaŃii de tip SaaS şi fiecare dintre ele pun la dispoziŃie API-uri, care permit mixarea şi integrarea datelor conŃinute în cadrul altor aplicaŃii. Alte exemple de suite de acest gen sunt suita166 Yahoo (Search, Mail, Contacts, Calendar, Notepad, Messenger, Flickr, Maps, Zimbra, delicious), suita Zoho167 (Mail, People, Docs, Planner, Notebook, Chat), etc. 4.4.2.3 Translatarea semantică a informaŃiilor Scopul principal atunci când utilizăm astfel de suite este interconectarea şi interoperabilitatea aplicaŃiilor. De exemplu, am putea dori ca din cadrul Gmail să putem căuta, naviga sau partaja fişiere, imagini şi video, prin combinarea beneficilor reŃelelor sociale şi managementul media cu medile de gestiune a email-urilor. Având un astfel de instrument, am putea să găsim imaginile sau fişierele trimise cu o anumită ocazie, să le postăm în cadrul blog-ului personal şi să permitem prietenilor să comenteze asupra lor. Pentru a realiza acest lucru avem nevoie de ontologii care să descrie în mod semantic informaŃiile 164 http://www.google.com/ 165 http://www.programmableweb.com/apilist/bycompany/Google 166 http://everything.yahoo.com/ 167 http://www.zoho.com/ 42

conŃinute şi legăturile dintre acestea. Avem nevoie de o integrare strânsă între ontologiile folosite. Anumite formate de date conŃin referinŃe spre entităŃi care depăşesc scopul lor iniŃial, de exemplu, referinŃe către persoane putem găsi în cadrul email-urilor ( în cadrul câmpurilor to, from, cc, bcc), în cadrul evenimentelor din calendarul personal (organizator, participant) sau în contextul documentelor (autor, redactor). Figura 13 TranziŃia de la concepte abstracte către informaŃie semantică Strategia 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 maşini. 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, şi definind aspectele dinamice. Vor fi reprezentate fişiere, mesaje, sit-uri Web, date multimedia, contacte, locaŃii, evenimente etc. Toate metadatele vor fi stocate în format RDF, conform schemei vocabularului utilizat. Astfel toate datele conŃinute vor putea fi integrate, chiar dacă sunt stocate în reprezentări diferite şi descrise conform a ontologii diverse. Scopul este acela 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. Vom prezenta modul de combinare şi relaŃiile dintre vocabularele RDF utilizate. Există câteva provocări pentru utilizarea acestui mix de ontologii. Prima provocare şi cea mai importantă este adopŃia de către furnizori, ca manieră de publicare de metadate pentru conŃinutul gestionat de aceştia. Prin utilizarea de concepte uşor de integrat în cadrul platformelor deja existente şi prin furnizarea de proprietăŃi care pot fi automat create de utilizatorii finali, ontologiile pot fi adoptate mult mai uşor. Cea de a doua provocare este alegerea celor mai bune ontologii existente care să fie combinate în mod armonios. O altă provocare este scalabilitatea pe care ontologiile selecŃionate o deŃin. 4.4.3 Ontologii utilizate pentru Interconectarea InformaŃiei În continuare vom descrie vocabularele semantice care pot fi aplicate conŃinutului gestionat de suita Google, pentru asigurarea unui management optimal al informaŃiilor personale. Toate datele conŃinute de aplicaŃii vor fi interconectate. De exemplu, pot exista relaŃii între o persoană, participarea acesteia la un eveniment şi articolul publicat în cadrul evenimentului. 4.4.3.1 Persoane şi RelaŃii InformaŃiile despre persoane vor fi stocate în format FOAF168. Profilele standard FOAF conŃin date despre adresa de email, locul de muncă, locaŃie, persoane cunoscute, etc. Fiecare persoană va avea un spaŃiu de nume personal, identificat prin URI-uri unice, descris printr-o clasă de tip foaf:Person. 168 http://xmlns.com/foaf/spec/ 43

Contactele asociate unei persoane pot fi vizualizate şi gestionate accesând serviciul Google Contacts169. Google Contacts ajută menŃinerea listei de contacte, prin păstrarea numelor, adreselor de contact şi a altor informaŃii legate de profilul FOAF designat. Contactele pot fi grupate în diferite categorii definite de deŃinător-ul contului. Figura 14 Interconectarea informaŃiilor referitoare la o persoană Rolurile între persoane pot fi extinse faŃă de proprietate foaf:knows prin utilizarea vocabularelor rel170 sau xfn171, detalind astfel reŃeaua socială a persoanei. 4.4.3.2 PublicaŃii, Articole şi Categorii Alte vocabulare care pot fi utile în cadrul managementului informaŃiilor personale este Publ172 pentru descrierea informaŃiilor legate de publicaŃii printate. PublicaŃiile vor reŃine date referitoare la autori, editori, compendiul în care au fost publicate, data publicării, numărul de pagini, etc. <publ:Article> <publ:title>Comunicare vizuală prin intermediul infograficelor</publ:title> <publ:publisher>Matrix Rom Bucureşti</publ:publisher> <publ:pages>4</publ:pages> <publ:firstAuthor> <foaf:Person> <foaf:name>Ecaterina Valică</foaf:name> </foaf:Person> </publ:firstAuthor> </publ:Article> Pe lângă articolele printate, autorul poate să interconecteze articolele, ştirile, contribuŃiile virtuale create de acesta. AplicaŃiile din cadrul suitei Google, care conectează, crează şi stochează aceste date sunt Blogger173, Reader174 şi Bookmarks175. Blog-urile sunt o formă de exprimare personală şi o unealtă care accesarea ştirilor, opinilor şi comentariilor aferente. Pentru toate blog-urile, postările aferente, pagini Web, articole realizate de autor, se va folosi vocabularul SIOC176. În cazul în care se doreşte asocierea de tag-uri, etichete, categorii se pot folosi ontologiile SCOT 177 169 http://www.google.com/contacts 170 http://vocab.org/relationship/.html 171 http://vocab.sindice.com/xfn.html 172 http://ebiquity.umbc.edu/ontology/publication.owl 173 http://www.blogger.com 174 http://www.google.com/reader 175 http://www.google.com/bookmarks/ 176 http://rdfs.org/sioc/spec/ 177 http://scot-project.org/scot/ 44

(Semantic Cloud Of Tags) sau MOAT178 (Meaning Of A Tag), ambele ontologii fiind bazate pe SIOC şi FOAF. Datele se etichetează folosind cuvinte cheie sau limbaj natural, care asociază datelor etichetate o anumită categorie. Categoriile sunt practice în cadrul grupurilor restrânse de indivizi, care folosesc acelaşi limbaj pentru a denota concepte, dar sunt greu de utilizat la nivel global. Taxonomii sau baze de date lexicale deja existente ca WordNet179 pot fi folosite pentru a denota categoriile. 4.4.3.3 Evenimente, Calendare şi LocaŃii Geografice Evenimentele au nevoie de termeni structuraŃi care să identifice elemente ca durată, locaŃie, etc. Evenimentele pot fi gestionate folosind Google Calendar180 sau pot fi adăugate prin Gmail181. Mesajele care conŃin menŃiuni către evenimente sau date, sunt recunoscute şi se oferă posibilitatea de a fi adăugate în calendarul personal. Google Calendar este o aplicaŃie Web care permite utilizatorilor săi să fie ŃinuŃi la curent cu toate evenimentele importante, întâlnirile sau ocaziile speciale, relevante pentru aceştia. Toate datele conŃinute de aplicaŃie pot fi partajate între mai mulŃi utilizatori, care pot colabora şi îmbunătăŃii detaliile aferente conŃinutului. Folosind Google Calendar pot fi vizualizate agendele prietenilor, familiei sau a contactelor. Se pot crea şi calendare adiŃionale care să surprindă date ale conferinŃelor de interes sau a altor lucruri cu care utilizatorul doreşte să fie Ńinut la curent. Datele calendaristice vor fi declarate folosind ontologia Cal182. NoŃiunile temporale pot fi definite cu owlTime183 sau declarate folosind xsd:date şi xsd:time. Figura 15 Interconectarea informaŃiilor despre evenimente şi locaŃii Google Maps184 permite utilizatorilor să interogheze şi să găsească informaŃii referitoare la instituŃii publice şi obiective de atracŃie turistică, direcŃii către acestea, hărŃi şi imagini disponibile prin satelit de pe întreaga planetă. Orice informaŃii despre o locaŃie pot fi îmbunătăŃite prin adăugarea de date suplimentare personalizate. Totuşi, prelucrarea şi selectarea surselor externe de informaŃii, care se doresc adăugate, este limitată. Google Maps este ideal pentru a corela alte date cu locaŃia lor geografică şi dispune de instrumente pentru interogare, analiză şi vizualizare de relaŃii cu alte componente de acelaşi tip. Pentru a descrie locaŃii se pot utiliza vocabularele Geo185 şi WAIL186. În cadrul vocabularului fiecare locaŃie are asociat un nume şi valorile de latitudine/longitudine. 178 http://moat-project.org/ontology 179 http://wordnet.princeton.edu/ 180 http://www.google.com/calendar 181 http://mail.google.com 182 http://www.w3.org/2002/12/cal/ 183 http://www.w3.org/TR/owl-time/ 184 http://maps.google.com/ 185 http://www.w3.org/2003/01/geo/ 186 http://www.eyrie.org/~zednenem/2002/wail/ 45

LocaŃia este un element important în cadrul comunităŃilor online deoarece majoritatea comunităŃilor se construiesc în jurul unei zone geografice. Următorul pas este găsirea unei reprezentări codate geografic care să definească locaŃia utilizatorului. Obiectele returnate de Google Maps conŃin coordonatele de latitudine şi longitudine ale locaŃiei dorite. Folosind proprietatea foaf:based_near pentru a exprima referinŃa către locaŃie, vom include o clasă geo:Point din cadrul ontologiei Geo, care va fi populată cu atributele geo:lat şi geo:long corespunzătoare coordonatelor de latitudine şi longitudine. O altă variantă de specificare a locaŃiei este utilizarea conceptelor geografice oferite de serviciul Geonames187. <ical:vcalendar> <ical:vevent-prop> <ical:vevent rdf:about=“http://www.xwiki.org/”> <dc:title>XWiki Meeting</dc:title> <ical:summary>XWiki Presentation</ical:summary> <ical:organizer rdf:resource=“http://students.info.uaic.ro/ ~evalica/foaf.rdf#evalica”/> <ical:dtstart rdf:datatype=“xsd:date”>2009-06-18</ical:dtstart> <ical:dtend rdf:datatype=“xsd:date”>2009-06-18 </ical:dtend> <ical:location> <geo:Point> <geo:lat>47.1700 </geo:lat> <geo:long>25.5830</geo:long> </geo:Point> </ical:location> </ical:vevent> </ical:vevent-prop> </ical:vcalendar> 4.4.3.4 Documente şi Fişiere Documentele sunt resurse vitale pentru atingerea obiectivelor şi îndeplinirea unei sarcini. Persoanele ataşează documente email-urilor, discuŃiilor, oferă legături externe, toate aceste date fiind conectate din punct de vedere semantic. Figura 16 Descrierea subclaselor de documente Google Docs188 este o aplicaŃie care facilitează crearea şi gestiunea fişierelor de tip: − Documente: .html, .txt, .doc .docx (Microsoft Word), .rtf, .odt (OpenOffice), .sxw (StarOffice), .pdf − Foi de calcul tabelar: .xls .xlsx, .ods, .csv, .tsv, .txt, .tsb − Prezentări: .ppt, .pps − Fişiere customizate, ca formulare. 187 http://www.geonames.org/ 188 http://docs.google.com 46

Aceste tipuri de fişiere acoperă întreaga gamă de fişiere utilizate preponderent în cadrul organizaŃiilor. DiferenŃa dintre această aplicaŃie şi alte procesoare de documente standard este abilitatea de a edita documentele în mod concurent şi colaborativ. Se pot ataşa documentelor colaboratori sau spectatori, prin acordarea de permisii asupra fişierelor. Ontologia utilizată pentru descrierea documentelor sau a altor fişiere primite ca ataşamente în cadrul email-urilor sau distribuite pe Web este NFO 189 (Nepomuk File Ontology). 4.4.3.5 Email-uri şi Ataşamente Gmail190 este o aplicaŃie Web, care permite utilizatorilor transmiterea şi organizarea de email-uri, contacte şi conversaŃii. AplicaŃia ajută organizarea, accesarea şi identificarea datelor transmise prin email. Se pot interoga email-urile trimise către sau primite de la o anume persoană, se pot vizualiza ataşamente sau conversaŃii adiacente. Orice mesaj transmis din cadrul aplicaŃiei este legat automat de datele găsite în lista de contacte Google Contacts191. Figura 17 Interconectarea informaŃiilor legate de email-uri şi ataşamente Ontologia utilizată este NMO192 (Nepomuk Message Ontology), care descrie structura email-urilor sau a mesajelor instante (IM Instant Messagging). Transmiterea de mesaje instante este posibilă prin utilizarea aplicaŃiei Gtalk193, care este integrat atât cu Gmail, cât şi disponibilă ca aplicaŃie separată. <nmo:Email> <nmo:messageId>imap://evalica@infoiasi.ro/inbox/1</nmo:messageId> <nmo:messageSubject>Prezentare</nmo:messageSubject> <nmo:receivedDate>2009-06-26T10:22:55.0000000+02:00</nmo:receivedDate> <nmo:sentDate>2009-06-26T10:22:25.0000000+02:00</nmo:sentDate> <nmo:to> <foaf:Person rdf:about=“http://profs.info.uaic.ro/~busaco/busaco.foaf.xml#me”/> </nmo:to> <nmo:from> <foaf:Person rdf:about=“http://students.info.uaic.ro/~evalica/foaf.rdf#evalica”> <foaf:name>Ecaterina Valica</foaf:name> 189 http://www.semanticdesktop.org/ontologies/2007/03/22/nfo/ 190 http://mail.google.com 191 http://www.google.com/contacts 192 http://www.semanticdesktop.org/ontologies/2007/03/22/nmo/ 193 http://www.google.com/talk/ 47

<foaf:mbox>evalica@infoiasi.ro</foaf:mbox> </foaf:Person> </nmo:from> <nmo:hasAttachment> <nfo:Attachment> <nfo:fileName>Prezentare.pdf</nfo:fileName> <nfo:fileExtension>pdf</nfo:fileExtension> <nfo:fileSize>56370 </nfo:fileSize> </nfo:Attachment> </nmo:hasAttachment> </nmo:Email> 4.4.3.6 ConŃinut Media Ontologia folosită pentru a descrie datele media conŃinute este Media Resource 1.0194, un vocabular de bază şi general, care descrie resursele media găsite în cadrul Web-ului. Ontologia este definită conform unui set de proprietăŃi specifice resurselor media şi este concepută astfel încât să asigure interoperabilitatea cu formatele cele mai întâlnite şi utilizate frecvent pentru descrierea resurselor media. Figura 18 Descrierea proprietăŃilor media <ma:Media rdf:about=“http://www.flickr.com/photos/evalica/3304781204/”> <ma:title>Prezentare</ma:title> <ma:creator rdf:resource=“http://students.info.uaic.ro/~evalica/foaf.rdf#evalica”/> <foaf:depicts rdf:resource=“http://students.info.uaic.ro/~evalica/foaf.rdf#evalica”/> <ma:location rdf:resource=“http://dbpedia.org/resource/Iaşi”/> <ma:createDate rdf:datatype=“xsd:date”>2009-06-26</ma:createDate> <ma:compression>H264</ma:compression> <ma:format>image/png</ma:format> <ma:frameSize>w:720, h:480</ma:frameSize> <cc:license>Creative Commons Attribution Non-Commercial 3.0 License</cc:license> <cc:permits rdf:resource=“http://web.resource.org/cc/Distribution”/> <cc:permits rdf:resource=“http://web.resource.org/cc/DerivativeWorks”/> <cc:prohibits rdf:resource=“http://web.resource.org/cc/CommercialUse”/> </ma:Media> La toate fişierele media adăugate se pot adăuga informaŃii referitoare la licenŃa în care au fost publicate, pentru a evita utilizarea necorespunzătoare ulterioară, folosind schema CC195. Un alt standard de metadata pentru conŃinutul media este specificaŃia Adobe XMP196 (Extensible Metadata Platform), care standardizează definirea, crearea şi procesarea pentru format media. 194 http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont-1.0.html 195 http://creativecommons.org/ns 48

4.4.3.6.1 Adnotarea şi Distribuirea de Imagini Distribuirea de imagini este o caracteristică foarte populară în cadrul aplicaŃiilor Web. Există un număr ridicat de aplicaŃii (Picasaweb, Flickr, Pbase, Kodak, Shutterfly) care oferă acest serviciu şi care ataşează respectivelor imagini metadate. Se poate să dorim să strângem toate pozele făcute cu ocazia unui anumit eveniment (imagini care se încadrează într-un anumit interval de timp şi poziŃionate la o anumită locaŃie geografică), poze distribuite în cadrul a mai multor aplicaŃii Web, sau să dorim pe langă respectivele poze, să strângem şi filmuleŃele referitoare la eveniment, ştirile, articolele. Încapsulând metadate fişierelor, acestea vor putea fi interogate de aplicaŃii semantice. Alte ontologii mai specifice sau metadate care se pot asociat pentru astfel de conŃinut sunt: − VRA197; − Exif198; − NISO Z39.87199; − DIG35200; − NEXIF201 - Nepomuk EXIF. Formatul Exif încapsulează metadata pentru imagini, ca de exemplu data, ora sau coordonatele GPS202 ale locaŃiei în care a fost făcută poza respectivă. Alte informaŃii suplimentare pot fi legate de persoanele participante sau ocazia cu care au fost făcute pozele. 4.4.3.6.2 Cumpărarea de albume muzicale şi gestiunea acestora Magazine precum iTunes furnizează metadate de bază legate de melodiile comercializate. Utilizând un format comun de metadate se permite legarea datelor cu alte resurse semantice. AplicaŃiile semantice vor putea oferi informaŃii despre artist, recenzii, informaŃii aflate pe site-uri ale fanilor, etc. Alte ontologii mai specifice sau metadate care se pot asociat pentru astfel de conŃinut sunt: − ID 3203; − MusicBrainz204; − MusicXML205; − NID3206. 4.4.3.6.3 Distribuirea de conŃinut video ConŃinutul video poate fi gestionat utilizând aplicaŃii de tip YouTube, Spike, ComCast. Alte ontologii mai specifice sau metadate care se pot asociat pentru astfel de conŃinut sunt: − MXF207; − P_Meta208; − MPEG – 7209; − MPEG – 21210. 196 http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf 197 http://www.vraweb.org/vracore3.htm 198 http://www.digicamsoft.com/exif22/exif22/html/exif22_1.htm 199 http://www.niso.org/standards/resources/Z39-87-2006.pdf 200 http://xml.coverpages.org/FU-Berlin-DIG35-v10-Sept00.pdf 201 http://www.semanticdesktop.org/ontologies/2007/05/10/nexif 202 http://www.gps.gov/ 203 http://www.id3.org/Developer_Information 204 http://musicbrainz.org/MM/ 205 http://www.recordare.com/xml.html 206 http://www.semanticdesktop.org/ontologies/2007/05/10/nid3/ 207 http://www.pro-mpeg.org/publicdocs/mxf.html 208 http://www.ebu.ch/trev_290-hopper.pdf 209 http://www.itscj.ipsj.or.jp/sc29/29w42911.htm#MPEG-7 210 http://www.itscj.ipsj.or.jp/sc29/29w42911.htm#MPEG-21 49

5. Concluzii Web-ul este înŃeles ca un spaŃiu global al informaŃiei care conectează documente şi date. Totuşi, deşi conceptul de Web-ul a fost modelat în anul 1973, a devenit operaŃional în anul 1993 şi apoi a fost comercial disponibil în anul 1999, încă îi lipsesc anumite funcŃionalităŃi importante. Una din acestea este felul în care informaŃia şi aplicaŃiile sunt interconectate în cadrul Web-ului. Se folosesc mecanismele de bază de conectare a documentelor, dar aceste mecanisme nu specifică semantica sau contextul legăturilor şi datelor. 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. Acest lucru facilitează schimbul şi combinarea datelor găsite în cadrul Web-ului, alcătuind spaŃiul Datelor Interconectate. Cel mai mare beneficiu adus de Datele Interconectate este acela că oferă o metodă de a realiza din Web o bază de date globală şi interoperabilă. Fundamentul care a stat la baza succesului Datelor Interconectate este flexibilitatea şi simplitatea modelului de date RDF. Beneficiul adus de folosirea RDF ca model de date este capacitatea lui de a stoca virtual orice relaŃie sau dată structurată. Un alt mecanism vital a fost utilizarea URI-urilor ca identificatori globali de conectare. Totuşi principalul avantaj oferit de RDF este interoperabilitatea pe care o asigură. Din momentul în care datele sunt reprezentate în format RDF, este uşor de incorporat noi seturi de date sau noi atribute. De asemenea uşurează agregarea surselor de date disparate şi oferirea acestora ca o singură sursă. Acest lucru facilitează compoziŃia datelor din cadru a aplicaŃii diferite indiferent de modul de reprezentare sau serializare a acestora. O dată cu expansiunea datelor care sunt interconectate, 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, nu există încă aplicaŃii care să profite la maxim de avantajele acestor resurse, unul din motive fiind lipsa unui model standard de reprezentare a datelor. Conceptele Logicii Descrierii se mapează perfect pe felul în care sunt luate decizile arhitecturale şi de modelare ale Datelor Interconectate, realizând astfel separarea în TBox – ABox a ontologiilor şi a viziunii organizaŃionale faŃă de instanŃele datelor. Datelor Interconectate le lipseşte o structură de referinŃă coerentă pentru conceptele şi subiectele care descriu conŃinutul, 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.. TBox utilizează un vocabular controlat pentru a defini conceptele şi rolurile unui domeniu de interes şi relaŃiile sau proprietăŃii dintre acestea. În cadrul lucrării am descris 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. AplicaŃiile de tip SaaS reprezintă 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 personale a software-ului. În ultima perioadă s-a observat o tranziŃie mult 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. Acest lucru are ca efect stocarea şi managementul, în cadrul Web-ului, a din ce în ce mai multe documente, informaŃii şi date care sunt gestionate de diverşi utilizatori. 50

Î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 descrise în cadrul lucrării modelează principalele concepte implicate în activitatea zilnică a unei persoane: locuri, organizaŃii, persoane, documente, etc. Oferind sens acestor tipuri de date deŃinute de utilizator, aplicaŃiile care folosesc aceste date pot să identifice conexiuni între componente diverse şi să faciliteze modul de operare şi regăsire a datelor necesare utilizatorilor. Interoperabilitatea, productivitatea, reutilizarea, personalizarea şi managementul semantic a datelor sunt câteva dintre beneficiile aduse de adoptarea unui astfel de mod de reprezentare. În momentul în care se încearcă maparea de informaŃii în cadrul unei noi ontologii, există discuŃia dacă termenii conŃinuŃi să fie interconectaŃi şi reutilizaŃi din cadrul ontologiilor deja existente şi cunoscute, sau dacă este necesară construirea unei ontologii complet noi. Abordarea prezentată în cadrul lucrării este de reutilizare de ontologii deja existente, cu scopul de a evita redundanŃa, de a oferi modularitate şi pentru a utiliza descentralizat descrieri de metadate specifice mai multor domenii. Există câteva provocări în cazul utilizării unui mix de ontologii. Prima provocare şi cea mai importantă este adopŃia de către furnizori, ca manieră de publicare de metadate pentru conŃinutul gestionat de aceştia. Prin utilizarea de concepte uşor de integrat în cadrul platformelor deja existente şi prin furnizarea de proprietăŃi care pot fi automat create de utilizatorii finali, ontologiile pot fi adoptate mult mai uşor. Cea de a doua provocare este alegerea celor mai bune ontologii existente care să fie combinate în mod armonios. O altă provocare este scalabilitatea pe care ontologiile selecŃionate o deŃin. Momentan comunitatea Datelor Interconectate a pus accentul mai mult pe conectarea şi înglobarea a cât mai mult conŃinut. DirecŃii viitoare pentru Datele Interconectate includ dezvoltarea de interfeŃe utilizator care să pună în valoare noile moduri de navigare a datelor. Vor trebui deasemenea îmbunătăŃite motoarele de căutare în cadrul acestor date. 51

ANEXE Anexa A: Redirectare 303 - exemplu de sesiune HTTP în cazul dereferenŃierii URI-ului unei resurse non-informaŃionale Prezentăm un exemplu de sesiune HTTP în care un navigator de Date Interconectate încearcă să dereferenŃieze URI-ul http://dbpedia.org/resource/Romania, publicat de proiectul DBpedia211. Pentru a obŃine o reprezentare, navigatorul utilizatorului se va conecta la serverul dbpedia.org şi va emite o cerere HTTP GET: GET /resource/Romania HTTP/1.1 Host: dbpedia.org Accept: text/HTML;q=0.5, application/rdf+xml Navigatorul trimite un antet Accept: care indică dacă acesta doreşte să primească răspuns în format HTML sau RDF. Valoarea HTML q=0.5 arată că acesta preferă formatul RDF. Serverul va răspunde: HTTP/1.1 303 See Other Location: http://dbpedia.org/data/Romania Vary: Accept Aceasta este o redirectare 303, care spune navigatorului că resursa cerută este o resursă non- informaŃională şi că descrierea asociată poate fi găsită la URI-ul transmis în parametrul Location: al antetului de răspuns. Dacă antetul Accept: ar fi indicat că se preferă formatul HTML, atunci s-ar fi returnat un alt URI. În continuare navigatorul încearcă să dereferenŃieze URI-ul primit: GET /data/Romania HTTP/1.1 Host: dbpedia.org Accept: text/HTML;q=0.5, application/rdf+xml Serverul va răspunde: HTTP/1.1 200 OK Content-Type: application/rdf+xml;charset=utf-8 <?xml version=“1.0”?> <rdf:RDF xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax-ns#” xmlns:rdfs=“http://www.w3.org/2000/01/rdf-schema#”> ... Codul 200 OK confirmă navigatorului că resursa transmisă conŃine reprezentarea resursei informaŃionale cerute. Antetul Content-Type: specifică că reprezentarea este în format RDF/XML. Restul mesajului conŃine reprezentarea. 211 http://dbpedia.org/ 52

Anexa B: Interconectarea şi crearea minimală a profilului FOAF Cea mai potrivită metodă de a începe publicarea Datelor Interconectate este aceea de a servi un fişier static RDF; mai ales în cazul în care se doreşte a fi publicat un conŃinut redus de date. Cel mai popular exemplu pentru aceasta metodă este furnizarea unui profil Friend-of-a-Friend212 (FOAF) conectat cu pagina personală în format clasic HTML. În această anexă sunt prezentaŃi paşii pentru crearea, publicarea şi interconectarea în cadrul Web-ului de Date a unui profil FOAF. FOAF-a-Matic213 este un formular Web care generează o descriere minimală FOAF în format RDF/XML. Folosind acest serviciu avem o bază de pornire, pe care se pot adaugă alte date. După generarea profilului FOAF folosind FOAF-a-Matic, codul RDF/XML generat va fi salvat ca un fişier static (denumirea foaf.rdf este cea mai întâlnită convenŃie) şi găzduit pe un anumit server. Din punct de vedere tehnic acest profil poate fi găzduit oriunde în cadrul Web-ului, deşi este des întâlnit să fie găzduit pe serverul personal, în acelaşi director cu pagina personală. De exemplu, profilul FOAF pentru Ecaterina Valică se găseşte la locaŃia http://students.info.uaic.ro/~evalica/foaf.rdf. Respectivul document descrie persoana Ecaterina Valică, resursă non-informaŃională, identificată de URI-ul http://students.info.uaic.ro/~evalica/foaf.rdf#evalica. În mod standard FOAF-a-Matic foloseşte un fragment identificator (#me) pentru a face referire la autor în cadrul profilul FOAF. Acest fragment este alăturat URI-ului profilului FOAF pentru a forma URI-ul personal, de forma http://domeniu.ro/foaf.rdf#me. În acest fel avem un URI care identifică autorul în alte declaraŃii RDF din cadrul Web-ului de date. Acest URI este un exemplu de „hash URI” (URI care foloseşte în construcŃie caracterul #). În exemplu, s-a înlocuit valoarea standard #me, cu valoarea #evalica. În acest stadiu, următorul pas este acela de a lega profilul FOAF în cadrul Web-ului. Un prim pas este legarea profilului FOAF de pagina personală, prin folosirea elementului <link>. Schimbarea nodurilor blank cu referinŃe URI FOAF-a-Matic foloseşte noduri blank pentru a identifica persoanele cunoscute, în loc de a utiliza direct referiŃe URI. Acest lucru se datorează dificultăŃii de a asocia automat URI-ul potrivit care să corespundă unei anumite persoane. Un exemplu de rezultat care foloseşte noduri blank este: ... <foaf:knows> <foaf:Person> <foaf:name>Sabin-Corneliu Buraga </foaf:name> <foaf:mbox_sha1sum> 939923a71879cefd6efb6500e20541422f98c119 </foaf:mbox_sha1sum> <rdfs:seeAlso rdf:resource=“http://profs.info.uaic.ro/~busaco/busaco.foaf.xml”/> </foaf:Person> </foaf:knows> ... Acest cod este RDF valid, dar nu este potrivit pentru Date Interconectate, deoarece folosirea nodurilor blank face ca îmbinarea datelor din surse diferite să devină mult mai dificilă. Astfel, toate resursele care au o anumită importanŃă şi folosesc noduri blank trebuiesc înlocuite cu referinŃe URI. Aflarea legăturilor către anumite resurse Setarea legăturilor RDF se poate realiza manual şi se pot folosi servicii (Uriqr214, Sindice215) care pot fi folosite pentru a căuta URI-uri existente ale persoanelor cunoscute. Urmărind această abordare se află că URI-ul http://profs.info.uaic.ro/~busaco/busaco.foaf.xml#me identifică persoana Sabin-Corneliu 212 http://xmlns.com/foaf/spec/ 213 http://www.ldodds.com/foaf/foaf-a-matic 214 http://uriqr.com/ 215 http://www.sindice.com/ 53

Buraga. Această informaŃie va înlocui nodul blank generat de FOAF-a-Matic cu referinŃa URI găsită. Rezultatul va fi de forma: ... <foaf:knows> <foaf:Person rdf:about=“http://profs.info.uaic.ro/~busaco/busaco.foaf.xml#me”> <foaf:name>Sabin-Corneliu Buraga </foaf:name> <foaf:mbox_sha1sum>939923a71879cefd6efb6500e20541422f98c119</foaf:mbox_sha1sum> <rdfs:seeAlso rdf:resource=“http://profs.info.uaic.ro/~busaco/busaco.foaf.xml”/> </foaf:Person> </foaf:knows> ... După setarea legăturilor către persoane pe care le cunoaştem, putem aplica şi alte metode de a lega profilul FOAF în Web-ul de date. Adăugarea informaŃiilor referitoare la locaŃia curentă În profilurile FOAF se adaugă de obicei şi locaŃia curentă a autorului, folosind proprietatea foaf:based_near. Această proprietate nu este suportată de FOAF-a-Matic şi trebuie adăugată manual. Se vor adăuga următoarele linii în interiorul elementului <foaf:Person RDF:ID=“me”></foaf:Person>, înlocuind obiectul triplului cu referinŃa URI a celei mai apropiate locaŃii: … <foaf:based_near RDF:resource=“http://dbpedia.org/resource/Iaşi”/> … Folosind URI-uri furnizate de Dbpedia216 sau Geonames217 ne asigurăm că profilul FOAF va fi conectat cu URI-uri deja cunoscute şi utilizate de alte persoane, interconectând astfel profilul cu Web-ul de Date. Adăugarea informaŃiilor referitoare la publicaŃii În cazul în care se doreşte adăugarea de referinŃe către articole sau cărŃi publicate, există o şansă ca respectivele URI-uri să existe deja în cadrul bazei de date DBLP218 (Digital Bibliography & Library Project) sau în RDF Book Mashup219. Este nevoie de a crea o legătură care să precizeze că profilul FOAF identifică acelaşi lucru ca şi URI-ul furnizat de DBLP. Acest lucru poate fi realizat folosind proprietatea owl:sameAs. Exemplu de profil FOAF <rdf:RDF xmlns:rdf=“http://www.w3.org/1999/02/22-rdf-syntax- ns#”xmlns:rdfs=“http://www.w3.org/2000/01/rdf-schema#”xmlns:foaf=http://xmlns.com/foaf/0.1/ xmlns:geo=“http://www.w3.org/2003/01/geo/wgs84_pos#”> <foaf:PersonalProfileDocument rdf:about=“http://students.info.uaic.ro/~evalica/foaf.rdf”> <foaf:maker rdf:resource=“#evalica”/> <foaf:primaryTopic rdf:resource=“#evalica”/> </foaf:PersonalProfileDocument> <foaf:Person rdf:ID=“evalica”> <foaf:name>Ecaterina Valica</foaf:name> <foaf:title>Mrs</foaf:title> <foaf:givenname>Ecaterina</foaf:givenname> <foaf:family_name>Valica</foaf:family_name> <foaf:nick>risherry</foaf:nick> <foaf:nick>evalica</foaf:nick> <foaf:nick>valicac</foaf:nick> 216 http://dbpedia.org/ 217 http://www.geonames.org/ 218 http://dblp.uni-trier.de/ 219 http://www4.wiwiss.fu-berlin.de/bizer/bookmashup/ 54

<foaf:mbox_sha1sum>6b3f46cf155abfb810316d1d5be8fb6286ed86d6</foaf:mbox_sha1sum> <foaf:homepage rdf:resource=“http://students.info.uaic.ro/~evalica/”/> <foaf:based_near rdf:resource=“http://dbpedia.org/resource/Iaşi”/> <foaf:interest rdf:resource=“http://dbpedia.org/resource/Semantic_Web”/> <foaf:knows> <foaf:Person rdf:about=“http://profs.info.uaic.ro/~busaco/busaco.foaf.xml#me”> <foaf:name>Sabin-Corneliu Buraga </foaf:name> <foaf:mbox_sha1sum> 939923a71879cefd6efb6500e20541422f9c119 </foaf:mbox_sha1sum> <rdfs:seeAlso rdf:resource=“http://profs.info.uaic.ro/~busaco/busaco.foaf.xml”/> </foaf:Person> </foaf:knows> <foaf:knows> <foaf:Person> <foaf:name>Raluca Morosan</foaf:name> <foaf:mbox_sha1sum> 7145288a1f24b1b2a6604136ff7d74e3a153e17 </foaf:mbox_sha1sum> <rdfs:seeAlso rdf:resource=“http://students.info.uaic.ro/~rmorosan/”/> </foaf:Person> </foaf:knows> </foaf:Person> </rdf:RDF> 55

Anexa C: Expresivitatea limbajelor DL Există numeroase varietăŃi (limbaje) de DL, în funcŃie de operatorii (constructorii) permişi. Expresivitatea este dată de folosirea următoarelor convenŃii în denumirea limbajului: F RestricŃii de cardinalitate funcŃională, e.g. ≤1 hasMother; (0 sau 1) S ProprietăŃi tranzitive H Ierarhia proprietăŃilor (subproprietăŃi - rdfs:subPropertyOf), e.g. hasDaughter ⊆ hasChild R Tranzitivitate; Axiome de incluziune de rol limitate; reflexivitate şi ireflexivitate; roluri disjuncte O Nominali (restricŃii ale obiectelor pe valoare - owl:oneOf, owl:hasValue), e.g. {Tim} I ProprietăŃi inverse, e.g. isChildOf ≡ hasChild- N RestricŃii de cardinalitate necalificata (owl:Cardinality, owl:MaxCardinality), e.g. ≥2 hasChild, ≤3 hasChild Q RestricŃii de cardinalitate calificate ≤, ≥, = (restricŃii care au domeniu altceva decât owl:thing), e.g. ≥2 hasChild.Male ε Cuantificare existenŃială full ∃ (restricŃii existenŃiale care au domeniu altceva decât owl:thing) U Reuniunea conceptelor – union ∪ C NegaŃia conceptelor full – complement ¬ (D) Folosirea proprietăŃilor tipurilor de date, valorilor datelor sau tipurilor de date Există şi anumite DL-uri canonice care nu se încadrează exact în convenŃie, ca: AL Attributive Language. Limbajul minimal care permite: − NegaŃie atomică (negarea conceptelor care nu apar pe partea stânga a axiomelor) − IntersecŃie de concepte ∩ , Reuniune de concepte ∪ − RestricŃii universale: pe valoare ∀ − Cuantificare existenŃială limitată ∃ FLo Un sublimbaj a lui FL-, (AL fără negaŃie atomică) care este obŃinut prin eliminarea cuatificatorului de existenŃă limitată εL IntersecŃie şi cuantificare existenŃială full ALC este limbajul DL central de la care alte varietăŃi pot fi făcute. ALC este o AL cu posibilitate de a avea complement pentru orice concept, nu doar conceptele atomice. SHIQ este logica ALC cu extinderi ale restricŃiilor de cardinalitate şi cu rolurile de inversă şi tranzitivitate (echivalentă cu SHOIN(D) ). SHOIN(D) este baza pentru limbajul OWL-DL. (D) SHIF este baza pentru OWL-Lite. Prezentăm expresivitatea câtorva ontologii utilizate în cadrul lucrării: FOAF – ALCHIF (D) NFO, NMO, DC, geo – ALH (D) ( ) SIOC – SHI D Publ– ALIN (D) ( ) SKOS – SHIF D iCal – ALUHN (D) Expresivitatea a fost determinată folosind editorul Protégé220. Mai multe detalii asupra complexităŃii pot fi determinate utilizând pagina221 lui Evgeny Zolin. 220 http://protege.stanford.edu/ 221 http://www.cs.man.ac.uk/~ezolin/dl/ 56

LISTĂ DE FIGURI Figura 1 Interconectarea seturilor de date în cadrul proiectului Linked Open Data – martie 2009.........7 Figura 2 Redirectare 303 în cazul derefenŃierii URI-ului unei resurse non-informaŃionale ..................11 Figura 3 Modul de afişare a datelor conŃinute de un profil FOAF de către navigatorul Disco..............13 Figura 4 InformaŃii despre resursa http://students.info.uaic.ro/~evalica/foaf.rdf#evalica .....................13 Figura 5 Interconectarea cu informaŃiile resursei http://dbpedia.org/resource/Iaşi ...............................14 Figura 6 Interconectarea resursei http://dbpedia.org/resource/Category:Municipalities_of_Romania .14 Figura 7 Diagrama constelaŃiei Linked Open Data – octombrie 2008 ..................................................24 Figura 8 Conceptul de “Cloud computing” ...........................................................................................27 Figura 9 Categorii de servicii oferite de Cloud .....................................................................................28 Figura 10 Nucleul ontologiei SIOC......................................................................................................35 Figura 11 Modelarea datelor folosind SIOC, FOAF şi SKOS ..............................................................37 Figura 12 RelaŃii între clase necesare interconectării comunităŃilor online...........................................41 Figura 13 TranziŃia de la concepte abstracte către informaŃie semantică ..............................................43 Figura 14 Interconectarea informaŃiilor referitoare la o persoană .........................................................44 Figura 15 Interconectarea informaŃiilor despre evenimente şi locaŃii ...................................................45 Figura 16 Descrierea subclaselor de documente ...................................................................................46 Figura 17 Interconectarea informaŃiilor legate de email-uri şi ataşamente............................................47 Figura 18 Descrierea proprietăŃilor media.............................................................................................48 57

ACRONIME ABox – Assertions Box AIR – Adobe Integrated Runtime AJAX – Asynchronous JavaScript and XML AL – Attribute Language API – Application Programming Interface CC – Creative Commons CSV – Comma-Separated Values DBLP – Digital Bibliography & Library Project DC – Dublin Core DIG – Digital Imaging Group DL – Description Logics DOAP – Description of a Project DOI – Digital Object Identifier EXIF – Exchangeable Image File Format FOAF – Friend of a Friend FOL – First Order Logic GPS – Global Positioning System HTML – HyperText Markup Language HTTP – Hypertext Transfer Protocol IM – Instant Messaging IMAP – Internet Message Access Protocol ISBN – International Standard Book Number ISIN – International Securities Identification Number JPEG – Joint Photographic Experts Group LOD – Linked Open Data MIME – Multipurpose Internet Mail Extensions MOAT – Meaning Of A Tag MPEG – Moving Picture Experts Group MXF – Material eXchange Format NEXIF – Nepomuk Exchangeable Image File Format Ontology NID3 – Nepomuk ID3 Ontology NISO – National Information Standards Organization NMO – Nepomuk Message Ontology NFO – Nepomuk File Ontology ODS – OpenDocument Spreadsheet Format ODT – OpenDocument Format OS – Operating System OWL – Web Ontology Language PaaS – Platform as a Service PDF – Portable Document Format PIM – Personal Information Management PPS – Microsoft PowerPoint Show Format PPT – Microsoft PowerPoint Presentation Format RDBMS – Relational database management system RDF – Resource Description Framework RDF-S – RDF Schema RIA – Rich Web Applications RSS – Really Simple Syndication RTF – Rich Text Format SaaS – Software as a Service SCOT – Semantic Cloud Of Tags SIOC – Semantically–Interlinked Online Communities SKOS – Simple Knowledge Organization Systems SOA – Service Oriented Architecture SPARQL – SPARQL Protocol and RDF Query Language SSB – Single-Site Browsers 58

SWEO – Semantic Web Education and Outreach SXW – StarOffice XML Writer Format TAG – Technical Architecture Group TBox – Terminology Box TSV – Tab-separated values UI – User Interface UNA – Unique Naming Assumption UMBEL – Upper Mapping and Binding Exchange Layer URI – Uniform Resource Identifiers URN – Uniform Resource Name VRA – Visual Resources Association W3C – World Wide Web Consortium WAIL – Where Am I Language XFN – XHTML Friends Network XLS – Microsoft Office Excel Format XML – Extensible Markup Language XMP – Extensible Metadata Platform XSD – XML Schema Definition 59

BIBLIOGRAFIE Allen, R., "The Web Desktop – Replacing Windows, Linux, and OS X on the desktop", 2005, http://rallenhome.com/essays/essay1.html Arrington., M., "Bridging Desktop And Web Applications - A Look At Mozilla Prism", March, 2008, http://www.techcrunch.com/2008/03/22/bridging-desktop-and-web-applications-a-look-at-mozilla- prism/comment-page-2/ Ayers, D., Bizer, C., Heath, T., Raimond, Y., "Interlinking Open Data on the Web", 2008, http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkingOpenData.pdf Ayers, D., Cyganiak, R., Sauermann, L., Völkel, M. "Cool URIs for the Semantic Web", 2007, http://www.w3.org/TR/cooluris/ Baader, F., Nutt, W., "Basic Description Logics", pag. 47-100 în Baader, F., Calvanese, D., McGuinness, D.L., Nardi, D., Patel-Schneider, P.F. (ed.), "Description Logic Handbook", Cambridge University Press, 2002, http://www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-02.pdf Bergman, M. K., „A New Constellation in the Linking Open Data (LOD) Sky”, 2008, http://www.mkbergman.com/?p=457 Bergman, M. K., „Advantages and Myths of RDF”, 2009, http://www.mkbergman.com/?p=483 Bergman, M. K., „Back to the Future with Description Logics”, 2009, http://www.mkbergman.com/?p=470 Bergman, M. K., „‘Exploding the Domain‘ in Context”, 2008, http://www.mkbergman.com/?p=454 Bergman, M. K., „Making Linked Data Reasonable using Description Logics, Part 1”, 2009, http://www.mkbergman.com/?p=474 Bergman, M. K., „Making Linked Data Reasonable using Description Logics, Part 2”, 2009, http://www.mkbergman.com/?p=476 Bergman, M. K., „Making Linked Data Reasonable using Description Logics, Part 3”, 2009, http://www.mkbergman.com/?p=477 Bergman, M. K., „Making Linked Data Reasonable using Description Logics, Part 4”, 2009, http://www.mkbergman.com/?p=478 Bergman, M. K., „Ontology Best Practices for Data-driven Applications: Part 3”, 2009, http://www.mkbergman.com/?cat=173 Bergman, M. K., „‘Structs’: Naïve Data Formats and the ABox”, 2009, http://www.mkbergman.com/?p=471 Bergman, M. K., „Thinking ‘Inside the Box’ with Description Logics”, 2008, http://www.mkbergman.com/?p=466 Berners-Lee, T., „Giant Global Graph”, 2007, http://dig.csail.mit.edu/breadcrumbs/node/215 Berners-Lee, T., „Linked Data”, 2007, http://www.w3.org/DesignIssues/LinkedData.html Berners-Lee, T., „Tim Berners-Lee Card”, http://www.w3.org/People/Berners-Lee/card/ Berners-Lee, T., Bizer, C., Heath, T., Idehen, K., "Linked Data on the Web", 2008, http://www2008.org/papers/pdf/p1265-bizer.pdf Bizer, C., Cyganiak, R., Hausenblas, M., Heath, T., "How to Publish Linked Data on the Web", 2008, http://events.linkeddata.org/iswc2008tutorial/proposal.pdf Bizer, C., Cyganiak, R., Heath, T., „How to Publish Linked Data on the Web”, 2007, http://www4.wiwiss.fu-berlin.de/bizer/pub/LinkedDataTutorial/ Bojars, U., Breslin, J.G., Cyganiak, R., Passant, A., "Weaving SIOC into the Web of Linked Data", 2008, http://events.linkeddata.org/ldow2008/papers/01-bojars-passant-weaving-sioc.pdf Bojars, U., Breslin, J.G., Decker, S., Fernández, S., Passant, A., "SIOC: Content Exchange and Semantic Interoperability Between Social Networks", 2009, http://www.w3.org/2008/09/msnws/papers/sioc.html Bojars, U., Breslin, J.G., Decker, S., Harth, A., "Towards Semantically-Interlinked Online Communities", 2005, http://sw.deri.org/2004/12/sioc/index.pdf Bojars, U., Breslin, J.G., Passant, A., "Data Portability with SIOC and FOAF", 2008, http://assets.expectnation.com/15/event/3/Data%20Portability%20with%20SIOC%20and%20FOA F%20Paper.pdf Brachman, R. J., Nardi, D., "An Introduction to Description Logics", pag. 5 - 44 în Baader, F., Calvanese, D., McGuinness, D.L., Nardi, D., Patel-Schneider, P.F. (ed.), "Description Logic Handbook", Cambridge University Press, 2002, http://www.inf.unibz.it/~franconi/dl/course/dlhb/dlhb-01.pdf Breslin, J.G., Decker, S., Harth, A., O'Murchu, I., "Linking Semantically-Enabled Online Community Sites", 2004, http://www.deri.ie/fileadmin/documents/DERI-TR-2004-08-09.pdf Buraga, S., „Semantic Web. Fundamente şi aplicaŃii”, Matrix Rom, Bucureşti, 2004 60

Buraga, S., „Tehnologii XML”, Polirom, Iaşi, 2006 Chappell, D., "A short introduction to cloud platform - an enterprise-oriented view", 2008, http://www.davidchappell.com/CloudPlatforms--Chappell.pdf Ciravegna, F., Rowe, M., "Getting to Me – Exporting Semantic Social Network Information from Facebook", 2008, http://sdow2008.semanticweb.org/pub/slides/SDoW2008-slides-Getting-to-Me- Exporting-Semantic-Social-Network-from-Facebook.pdf Cyganiak, R., "Expressing the XFN microformat in RDF", 2008, http://vocab.sindice.com/xfn.html Cyganiak, R., "Debugging Semantic Web sites with cURL", 2007, http://dowhatimean.net/2007/02/debugging-semantic-web-sites-with-curl Cyganiak, R., Sauermann, L., Völkel, M., „Cool URIs for the Semantic Web”, 2007, http://www.w3.org/TR/2007/WD-cooluris-20071217/ Davis, I., "Generation Zero", Oct 2008, Nodalities magazine Dengel, A., Sauermann, L., van Elst, L., "Pimo - a framework for representing personal information models", 2007, http://www.dfki.uni-kl.de/~sauermann/papers/sauermann+2007b.pdf Giasson, F., „Exploding DBpedia’s Domain using UMBEL”, 2008, http://fgiasson.com/blog/index.php/2008/09/04/exploding-dbpedias-domain-using-umbel/ Hausenblas, M., "Discovery and Usage of Linked Datasets on the Web of Data", Oct 2008, Nodalities magazine Heath, T., "Linked Data? Web of Data? Semantic Web?", 2009, http://tomheath.com/blog/2009/03/linked-data-web-of-data-semantic-web-wtf/ Heath, T., "Looking ahead to Linked Data on the Web", april 2008, Nodalities magazine Iacolare, L.,"Web Operating Systems And Web Desktops: A Mini-Guide", 2007, http://www.masternewmedia.org/operating_systems/web-operating-systems-virtual-desktops/best- web-os-and-virtual-desktops-guide.htm Jones, W. P., Teevan, J., „Personal information management”, University of Washington Press, 2007, http://books.google.ro/books?id=byN4SPUt6RgC O’Steen, B., "Cherry-picking the Semantic Web", July 2008, Nodalities magazine Sequeda, J. F., "Databases and the Semantic Web", July 2008, Nodalities magazine Smullyan, R. M. , "First-order logic", Courier Dover Publications, 1995, http://books.google.com/books?id=AYcr1yKq1BcC Raimond, Y., "Linking open data: interlinking the Jamendo and the Musicbrainz datasets", 2007, http://blog.dbtune.org/post/2007/06/11/Linking-open-data:-interlinking-the-Jamendo-and-the- Musicbrainz-datasets Valică, E., „Aplicatii hibride: mashup-uri”, pag. 183-242 în Buraga, S. (ed.), „Programarea în Web 2.0”, Polirom, Iaşi, 2007 Valică, E., “Tehnici de tip mashup pentru interacŃiuni Web în sisteme informaŃionale geografice”, Iaşi, 2007 ***, „Architecture of the World Wide Web”, Volume One, 2004, http://www.w3.org/TR/webarch/ ***, „Best Practice Recipes for Publishing RDF Vocabularies”, 2008, http://www.w3.org/TR/swbp- vocab-pub/ ***, "Creating Connections Between Discussion Clouds with SIOC", 2006, http://sioc- project.org/node/139 ***, Creative Commons Ontology, http://creativecommons.org/ns ***, CSS 2.1 Cascading Style Sheets Specification, 2009, http://www.w3.org/TR/CSS2/ ***, Complexity of reasoning in Description Logics, http://www.cs.man.ac.uk/~ezolin/dl/ ***, Data Portability Initiative, http://www.dataportability.org/ ***, DBLP Computer Science Bibliography, http://dblp.uni-trier.de/ ***, DBLP Bibliography Database published as RDF, http://www4.wiwiss.fu-berlin.de/dblp/ ***, DBpedia, http://dbpedia.org/ ***, „Dereferencing HTTP URIs”, 2007, http://www.w3.org/2001/tag/doc/httpRange-14/2007-05- 31/HttpRange-14 ***, DIG35 Digital Imaging Group Image Format, http://xml.coverpages.org/FU-Berlin-DIG35-v10- Sept00.pdf ***, Digital Object Identifier System, 2008, http://www.doi.org/index.html ***, Disco Browser, http://www4.wiwiss.fu-berlin.de/bizer/ng4j/disco/ ***, Description of a Project DOAP Ontology, http://trac.usefulinc.com/doap ***, Description Logic, http://dl.kr.org/ ***, Description Logic Reasoners, http://www.cs.man.ac.uk/~sattler/reasoners.html ***, Dublin Core Metadata Initiative, http://dublincore.org/ ***, Dublin Core Ontology, http://purl.org/dc/elements/1.1/ 61

***, EXIF Exchangeable Image File Format, http://www.digicamsoft.com/exif22/exif22/html/exif22_1.htm ***, Falcon Browser, http://iws.seu.edu.cn/services/falcons/objectsearch/index.jsp ***, Friend of a Friend Project, http://www.foaf-project.org/ ***, FOAF-a-Matic, http://www.ldodds.com/foaf/foaf-a-matic ***, FOAF Vocabulary Specification, 2007, http://xmlns.com/foaf/spec/, http://xmlns.com/foaf/0.1/ ***, Geonames, http://www.geonames.org/ ***, Geo Ontology, http://www.w3.org/2003/01/geo/ ***, HTML 4.01 Specification, 1999, http://www.w3.org/TR/html401/ ***, HTML 5 Draft, 2009, http://dev.w3.org/html5/spec/ ***, Hypertext Transfer Protocol - HTTP/1.1, 1999, http://www.ietf.org/rfc/rfc2616.txt ***, iCalendar Ontology, http://www.w3.org/2002/12/cal/ ***, ID3 Audio Format, http://www.id3.org/Developer_Information ***, JavaScript Mozilla Reference, 2009, https://developer.mozilla.org/en/JavaScript ***, Linked Data Sets, 2009, http://esw.w3.org/topic/DataSetRDFDumps ***, Linking Open Data Community Project, http://esw.w3.org/topic/SweoIG/TaskForces/CommunityProjects/LinkingOpenData ***, Linked Data Cloud, http://www4.wiwiss.fu-berlin.de/bizer/pub/lod-datasets_2009-03-27.html ***, Linked Data Constelation, 2008, http://umbel.org/images/lod_constellation.html ***, Linking Open Data Statistics on Data sets, 2009, http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets/Statistics ***, Linking Open Data Statistics on links between Data sets, 2009, http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets/LinkStatistics ***, Linked Data Validator, http://validator.linkeddata.org/vapour ***, Marbles Browser, http://marbles.sourceforge.net/ ***, Media Resource Ontology, http://dev.w3.org/2008/video/mediaann/mediaont-1.0/mediaont- 1.0.html ***, MOAT Meaning of a Tag Ontology, http://moat-project.org/ontology ***, MPEG-7 Moving Picture Experts Group, http://www.itscj.ipsj.or.jp/sc29/29w42911.htm#MPEG-7 ***, MPEG-21 Moving Picture Experts Group, http://www.itscj.ipsj.or.jp/sc29/29w42911.htm#MPEG- 21 ***, Music Ontology, http://musicontology.com/ ***, MusicBrainz Audio Format, http://musicbrainz.org/MM/ ***, MusicXML Audio Format, http://www.recordare.com/xml.html ***, MXF Material eXchange Format, http://www.pro-mpeg.org/publicdocs/mxf.html ***, Nepomuk Calendar Ontology, http://www.semanticdesktop.org/ontologies/ncal/ ***, Nepomuk Contact Ontology, http://www.semanticdesktop.org/ontologies/nco/ ***, Nepomuk EXIF Ontology, http://www.semanticdesktop.org/ontologies/nexif/ ***, Nepomuk File Ontology, http://www.semanticdesktop.org/ontologies/2007/03/22/nfo/ ***, Nepomuk ID3 Ontology, http://www.semanticdesktop.org/ontologies/nid3/ ***, Nepomuk Message Ontology, http://www.semanticdesktop.org/ontologies/nmo/ ***, Nepomuk Project Deliverable D3.1, "Task Management model", 2006, http://nepomuk.semanticdesktop.org/xwiki/bin/view/Main1/D3-1 ***, NISO National Information Standards Organization Image Format, http://www.niso.org/standards/resources/Z39-87-2006.pdf ***, Nodalities magazine, http://www.talis.com/nodalities/ ***, OpenID, http://openid.net/ ***, OpenLink RDF Browser, http://demo.openlinksw.com/DAV/JS/rdfbrowser/index.html ***, OpenLink Data Explorer, http://linkeddata.uriburner.com/ode/ ***, OpenSocial, http://www.opensocial.org/ ***, OWL Web Ontology Language Reference, 2004, http://www.w3.org/TR/owl-ref ***, OWL Web Ontology Language Overview, 2004, http://www.w3.org/TR/owl-features/ ***, Piggy Bank Extension, http://simile.mit.edu/wiki/Piggy_Bank ***, PIM Personal information management, http://en.wikipedia.org/wiki/Personal_information_management ***, PIMO Personal Information Model, http://www.semanticdesktop.org/ontologies/2007/11/01/pimo/ ***, PIMO Personal Information Model, NEPOMUK Recommendation, 2006, http://dev.nepomuk.semanticdesktop.org/repos/trunk/ontologies/pimo/latex/pimo.pdf ***, P-Meta Media Format, http://www.ebu.ch/trev_290-hopper.pdf ***, Pinging The Semantic Web, http://pingthesemanticweb.com/ 62

***, ProgrammableWeb, http://www.programmableweb.com/ ***, Programmable Web Google APIs, http://www.programmableweb.com/apilist/bycompany/Google ***, Protégé, http://protege.stanford.edu/ ***, Publication Ontology, http://ebiquity.umbc.edu/ontology/publication.owl ***, RDF Book Mashup, http://www4.wiwiss.fu-berlin.de/bizer/bookmashup/ ***, Relationship vocabulary for describing relationships between people, http://vocab.org/relationship/.html ***, Resource Description Framework, 2001, http://www.w3.org/RDF/ ***, Resource Description Framework: Concepts and Abstract Syntax, 2004, http://www.w3.org/TR/rdf-concepts/ ***, RDF Schema: Defining RDF Vocabularies, 2004, http://www.w3.org/TR/rdf-primer/#rdfschema ***, RDF Semantics, 2004, http://www.w3.org/TR/rdf-mt/ ***, RDF Validator, http://www.w3.org/RDF/Validator/ ***, RDF Vocabulary Description Language: RDF Schema, 2004, http://www.w3.org/TR/rdf-schema/ ***, RSS RDF Site Summary Specification, 2000, http://web.resource.org/rss/1.0/ ***, Record linkage, http://en.wikipedia.org/wiki/Record_linkage ***, Review Vocabulary, http://vocab.org/review/terms.html ***, SameAs Browser, http://sameas.org/ ***, SCOT Social Semantic Cloud of Tags Project, http://scot-project.org/ ***, SCOT Ontology Specification, 2008, http://scot-project.org/scot ***, Semantic Radar Extension, http://sioc-project.org/firefox ***, Semantically-Interlinked Online Communities (SIOC) Project, http://sioc-project.org/ ***, Sindice Browser, http://www.sindice.com/ ***, SIOC Core Ontology Specification, http://sioc-project.org/ontology, http://rdfs.org/sioc/spec/ ***, SIOC Ontology: Related Ontologies and RDF Vocabularies, 2007, http://www.w3.org/Submission/sioc-related/ ***, SIOC Types Module, http://rdfs.org/sioc/types ***, SKOS - Simple Knowledge Organisation Systems, http://www.w3.org/2004/02/skos/ ***, SKOS Simple Knowledge Organization System Reference, http://www.w3.org/TR/skos-reference/ ***, SKOS Simple Knowledge Organization System RDF Schema, 2009, http://www.w3.org/TR/2009/CR-skos-reference-20090317/skos.html ***, SPARQL Query Language for RDF, 2008, http://www.w3.org/TR/rdf-sparql-query/ ***, Semantic Web Education and Outreach SWEO, http://esw.w3.org/topic/SweoIG ***, SWEO Semantic Web Education and Outreach Interest Group, http://www.w3.org/2001/sw/sweo/ ***, SWEO Community Project, Common Vocabularies / Ontologies / Micromodels, http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/CommonVocabularies ***, SWEO Community Project, Data sets, http://esw.w3.org/topic/TaskForces/CommunityProjects/LinkingOpenData/DataSets ***, SWSE Browser, http://swse.deri.org/ ***, Swoogle Browser, http://swoogle.umbc.edu/ ***, Tabulator Browser, http://www.w3.org/2005/ajar/tab ***, Technical Architecture Group, http://www.w3.org/2001/tag/ ***, Time Ontology, http://www.w3.org/TR/owl-time/ ***, Turtle Format, http://www.w3.org/TeamSubmission/turtle/ ***, UMBEL - Upper Mapping and Binding Exchange Layer, http://umbel.org/intro.html ***, Uniform Resource Identifier (URI): Generic Syntax, 2005, http://tools.ietf.org/html/rfc3986 ***, Uriqr Browser, http://uriqr.com/ ***, URN Syntax, 1997, http://tools.ietf.org/html/rfc2141 ***, URNs, Namespaces and Registries, 2001, http://www.w3.org/2001/tag/doc/URNsAndRegistries- 50.html ***, VRA Visual Resources Association Image Format, http://www.vraweb.org/vracore3.htm ***, W3C Semantic Web Activity, http://www.w3.org/2001/sw/ ***, WAIL Where Am I Language Ontology, http://www.eyrie.org/~zednenem/2002/wail/ ***, Watson Browser, http://watson.kmi.open.ac.uk/WatsonWUI/ ***, Wikipedia, http://www.wikipedia.org/ ***, Wordnet, http://wordnet.princeton.edu/ ***, XFN Xhtml Friends Network, http://gmpg.org/xfn/ ***, XMP Extensible Metadata Platform, http://partners.adobe.com/public/developer/en/xmp/sdk/XMPspecification.pdf ***, Zitgist, http://dataviewer.zitgist.com/ 63

Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale

by Ecaterina Valica

Accessibility

Categories

Upload Details

Usage Rights

1 Embed 1

Statistics

Interconectarea Semantica A Datelor In Contextul Managementului Informatiilor Personale Document Transcript