. Formalisme Alternative Pentru Semantic Web
Introducere
Scopul acestei lucrari este de a compara si evalua doua formalisme de adnotare pentru Semantic Web: Resource Description Framework (RDF) si Topic Map. In acest scop a fost ales un scenariu particular: am adnotat informatia turistica gasita pe site-ul www.turism.ro folosind instrumente de proiectare specifice pentru Semantic Web.
Semantic Web poate aduce imbunatatiri substantiale in rezultatele motoarelor de cautare. Un prim pas in aceasta directie este organizarea si structurarea informatiei utilizand RDF si Topic Maps.
Acesta lucrare este impartita in 6 capitole dupa cum urmeaza:
Capitolul 1 intitulat “Notiuni generale despre Semantic Web” ofera o scurta prezentare a web-ului si a principalelor elemente care fac din Semantic Web noua generatie a www . Acest capitol este si o introducere pentru cele doua formalisme de adnotare: RDF si Topic Maps, care vor fi discutate pe larg in Capitolul 2: “Doua formalisme de adnotare: RDF si Topic Maps ”
Capitolul 3 intitulat “Studiu de caz” contine modalitatea de adnotare a corpusului preluat de la adresa www.turism.ro si prezentarea celor doua instrumente de proiectare folosite: Protégé-3.0 si Omnigator Eight.
In Capitolul 4 intitulat “Modelarea cu RDF” sunt ilustrate: extragerea informatiei de pe web, structurarea corpusului astfel obtinut, crearea ierarhiilor de clase si subclase, implementarea acestora in Protégé 3.0, vizualizarea si navigarea cu Omnigator Eight.
Capitolul 5 intitulat “Modelarea cu Topic Maps” reia acelasi demers, pe acelasi corpus, dar pentru Topic Maps.
In Capitolul 6 intitulat “Studiu comparative al celor doua formalisme prezentate” sunt ilustrate asemanarile si deosebirile dintre cele doua formalisme, comparatia fiind realizata atat la nivel formal cat si la nivel de aplicatie.
Capitolul 1- Notiuni generale despre Semantic Web
Semantic Web este un concept depre modul in care calculatoarele, oamenii si web-ul pot lucra impreuna mai eficient decat este acum posibil
O scurta istorie a “Web”-ului. De la HTML la XML
World Wide Web (deasemenea cunoscut ca www, w3 sau web) a fost creat de Tim Berners-Lee. Programul "World Wide Web" a fost lansat pe Internet in vara anului 1991. Avea scopul de a facilita accesul la informatiile gasite pe diferite computere.
World Wide Web a schimbat modul de comunicare intre oameni si modul in care informatia este raspandita si obtinuta. De asemenea, a schimbat rolul de baza al computerelor: initial erau folosite pentru calcule numerice, acum sunt folosite in principal pentru procesarea informatiei.
HTML
Unul dintre principalele mecanisme care a facut posibila expansiunea rapida a web-ului este HTML (HyperText Markup Language).
HTML nu este un limbaj de programare, ci un limbaj de marcare bazat pe SGML (Standard Generalized Markup Language).
SGML a fost ales ca baza pentru ca nu depinde de computerul pe care este folosit, si pentru ca sunt disponibile multe documentati si specificatii pentru acest limbaj.
Definitia HTML-ului este: Limbaj de Marcare a Hiper-Textelor (HyperText Markup Language).
HiperText este o metoda folosita pentru navigarea unui document sau a unei pagini web prin simplul click pe un text special numit hiperlink care te trimite la urmatoarea pagina.
Hiper inseamna ca nu este liniar — i.e. oricine poate ajunge oriunde pe internet prin intermediul link-urilor.
Marcarea reprezinta ceea ce face un tag HTML textului din interiorul acestuia: il marcheaza ca fiind un anumit tip de text.
HTML este alcatuit dintr-o serie de taguri ce contin texte. Un astfel de document este salvat ca fisier html si vizualizat cu ajutorul unui browser ca Internet Explorer sau Netscape Navigator.
Browserul citeste fisierul si afiseaza textul.
Principalul avantaj al HTML-ului este simplicitatea acestuia, dar are si dezavantaje. Acest limbaj de marcare a fost creat in scopul prezentarii informatiei pe Web. Numai oamenii pot intelege continutul unui astfel de document. Din acest motiv computerele au jucat un rol pasiv in acest proces.
Ca rezultat al folosirii HTML-ului, o mare parte din informatia care se gaseste pe Web este adecvata doar pentru intelegerea umana. Web-ul este utilizat pentru cautarea de informatie, contactarea altor persoane, cumparaturi on-line, etc. Toate acestea sunt activitati care consuma mult timp.
Problemele si limitarile HTML-ului sunt:
exista o colectie fixa de taguri cu o semantica fixa
nu se deosebeste sintaxa de semantica
nu descrie continutul unui document web
nu marcheaza continutul documentelor intr-un mod in care acestea sa poata fi intelese atat de oameni cat si de computere
trebuie sa fie suficient de flexibil incat sa poata descrie anumite arii de interes atat pentru companiile si organizatiile din prezent cat si pentru cele din viitor
Trebuie sa mentionam ca nu toata informatia de pe Web este hipertext.
Un limbaj care ar putea depasi aceste limitari si faptul ca nu toata informatia este hipertext exista de multi ani. Acesta este meta-limbajul SGML pe baza caruia a fost creat HTML-ul
Dar SGML e un limbaj prea complicat si nu este adaptat pentru Internet. Prin urmare la inceputul lui 1998 a fost creat un nou meta-limbaj bazat pe SGML: XML (eXtensible Markup Language). A fost creat pentru a servi ca fundatie pentru noua generatie Web (pentru Semantic Web).
XML
In XML nu exista o colectie fixa de taguri ca in HTML; tagurile pot fi definite in functie de informatia pe care o contin.
XML a fost creat in scopul de a:
separa sintaxa de semantica
ofera o baza comuna pentru structurarea informatiilor
suporta internationalizarea(Unicode) si independenta de platforma
XML nu este un substituent pentru HTML. Au fost create in scopuri diferite:
XML este folosit pentru a descrie informatia
HTML este folosit pentru a afisa informatia
1.1.3 XHTML. Relatiile dintre SGML, HTML, XML si XHTML
XHTML este o reformulare a ultimei versiuni de HTML, anume HTML 4.0, scrisa in XML.
Deci HTML va fi inlocuit de XHTML, nu de XML. XML va fi folosit pentru a structura si a descrie informatia, iar XHTML va fi folosit pentru a o afisa.
“XHTML este o familie de tipuri de documente si module curente si viitoare care reproduc si extind HTML 4. Familia de documente de tipul XHTML se bazeaza si colaboreaza cu agentii XML” (W3C 2002a)
Figura urmatoare ilustreaza legaturile dintre: SGML, XML, HTML si XHTML.
Figura 1.1 Relatiile dintre SGML, XML, HTML si XHTML.
Semantic Web: Noua generatie Web
Conceptul de Semantic Web se bazeaza pe ideea lui Tim Berners-Lee, inventatorul WWW si Directorul W3C. Creatorul Web-ului a dorit ca oricine sa poata pune informatie pe un computer si sa o faca accesibila oricui, oriunde. A sperat ca si calculatoarele sa poata intelege si folosi informatia de pe Web, ceea ce ar insemna o mai buna colaborare om-computer-om.
Ideea de baza a Semantic Web este aceea de a lasa pe seama computerului cat mai multe activitati curente specifice omului.
Semantic Web, in contrast cu actualul Web bazat pe HTML Web, se leaga in totalitate de intelesul informatiilor.
Sa luam urmatorul exemplu:
Daca, 23 ar insemna 23 de ani, putem descrie acest lucru in XML asfel:
<age>23</age>
Dar daca 23 reprezinta numarul unei pagini dintr-o carte atunci acest lucru va fi scris astfel:
<book PageNo=”23”/>
Evident, in aceste cazuri aceeasi sintaxa (“23”) are semantica diferita. Pentru Semantic Web, semantica inseamna intelesul informatiei de pe internet, ce poate fi descoperit nu doar de catre oameni ci si de catre computere. Oamenii nu au nevoie de taguri speciale pentru a intelege informatia de pe internet, dar pentru calculatoare aceasta informatie nu are sens daca nu este marcata cu taguri semantice.
1.2.1 Definitii.
Exista multe idei diferite si multe puncte de vedere legate de Semantic Web; vom prezenta numai cateva dintre acestea:
Din punctul de vedere al calculatoarelor care citesc si prelucreaza datele– “Semantic Web este o viziune: ideea de a avea informatii pe Web definite si conectate in asa fel incat sa poata fi folosite de calculatoare nu doar pentru a afisa informatia, dar si pentru a integra si a refolosi informatia de catre alte aplicatii” (W3C 2003).
Din punctul de vedere al agentilor Web– “Scopul Semantic Web este de a face actualul Web mai accesibil calculatoarelor pentru a permite agentilor sa extraga si sa manipuleze informatia” (Cost et al 2001).
Din punctul de vedere al infrastructurii automatizate– “ Berners-Lee argumenteaza ca Semantic Web este o infrastructura si nu o aplicatie. Si suntem de acord. ” (Tuttle et al 2001 ) “De aceea adevarata problema este lipsa unei structuri automatizate in actualul Web… ” (Garcia and Delgado 2001)
Din punctul de vedere al adnotarilor – “Ideea de 'Semantic Web' furnizeaza actualului Web adnotari exprimate intr-o forma procesabila de catre computer.” (Euzenat 2001)
Din punctul de vedere al cautarilor imbunatatite– “Curand va fi posibil sa accesam resurse Web prin continut, nu doar prin cuvinte cheie.” (Anutariya et al 2001).
Din punctul de vedere al serviciilor Web – “Semantic Web va fi folosit pentru a furniza acces nu doar la documente statice care colecteaza date ci si la servicii care furnizeaza un comportament folositor.” (Klein and Bernstein 2001)
“Semantic Web nu este un Web separat ci o extensie a celui curent, in care informatia primeste intelesuri bine definite, determinand o mai buna colaborare om-computer.” (Berners-Lee, Hendler, and Lassila 2001)
“Semantic Web este un spatiu conceptual al informatiei in care resursele identificate prin URI (Universal Resource Identifiers) pot fi procesate de calculatoare. (Un URI este un identificator pentru Web: un sir de caractere ce incepe cu "http:" or "ftp:". Orice are un URI este considerat a “fi pe Web”.
“Semantic Web opereaza pe principiu ‘intelegerii partiale’ si a ‘inferentei’, in consecinta pe principiul evolutiei si al transformarii” (Palmer 2001)
“Semantic Web este o colectie de date ce evolueaza continuu, creata pentru a lasa pe oricine sa adauge informatiile pe care le cunoaste pe internet, si sa gaseasca raspunsuri la intrebarile sale. Informatia care se gaseste pe Semantic Web, este mentinuta intr-o forma structurata, ceea ce face ca atat oamenii cat si computerele sa lucreze mai usor cu informatia.“ (W3C 2002b)
Tehnologii
Cateva dintre tehnologiile pe care se bazeaza Semantic Web sunt: meta-data, ontologiile, logica si agentii inteligenti (agentii web).
A. Meta-data
Meta-data reprezinta date despre date (detine intelesul informatiei). Un exemplu de meta-data este numarul ISBN si numele autorului dintr-o carte. Meta-datele pot fi privite simplu ca date, diferenta constand in faptul ca meta-datele sunt folosite pentru cautarea si descoperirea de noi informatii. Si adnotarile pot fi privite ca meta-date.
B. Ontologiile
Initial Ontologia era ramura metafizicii preocupata cu identificarea lucrurilor din natura si cu descrierea acestora. In informatica, “o ontologie reprezinta o specificare explicita si formala a unei conceptualizari” (R. Studer).
In general, o ontologie descrie formal un domeniu de discurs, ce este alcatuit dintr-o lista de termeni si relatiile dintre acestia. Termenii definesc concepte importante ale domeniului. Relatiile dintre termeni includ ierarhii de clase. O ierarhie specifica faptul ca o clasa A este de tipul clasei B, daca fiecare obiect din A este de asemenea un obiect din B.
Ontologiile pot include informatii precum:
proprietati
valori restrictionate ale proprietatilor
specificari ale relatiilor logice dintre obiecte
In contextul www, ontologiile impartasesc o intelegere comuna a domeniului, lucru care este necesar pentru trece peste problema diferentelor de terminologie (doua aplicatii pot folosi acelasi termen, dar cu intelesuri diferite)
Aceste diferente pot fi depasite prin realizarea unei harti intre ontologii.
Ontologiile sprijina interoperabilitatea semantica, si sunt folositoare: in organizatii, in navigarea site-urilor web, penizatii, in navigarea site-urilor web, pentru imbunatatirea acuratetii motoarelor de cautare.
In prezent, cele mai importante limbaje de ontologii pentru web sunt:
XML- furnizeaza o sintaxa de suprafata pentru documentele structurate, dar nu impune nici o constrangere asupra semanticii.
XML Schema este un limbaj ce restrictioneaza structura documentelor XML
RDF este un model de date pentru obiecte (resurse) si relatiile dintre acestea; acest model de date are o semantica simpla, si poate fi reprezentat in XML
RDF Schema este un limbaj de descriere al vocabularului folosit pentru descrierea proprietatilor si claselor din RDF si are o semantica proprie pentru generalizarea acestor ierarhii.
OWL este un limbaj mai bogat de descriere al vocabularului folosit pentru descrierea proprietatilor si claselor precum si a relatiilor dintre acestea
Logica
Pentru Semantic Web colectia de cunostinte poate fi foarte mare dar si inconsistenta.
Exista o diferenta importanta intre un sistem inchis si unul deschis. Intr-un sistem inchis toate lucrurile relevante sunt cunoscute, asa ca , atunci cand ceva lipseste, o concluzie negativa este justificata. Un sistem deschis nu contine toata informatia relevanta; informatiile pot aparea in timp.
Semantic Web va fi un sistem deschis foarte mare. Intr-un mediu greu de controlat, exista riscul ca sistemul sa preia informatie contradictorie sau falsa, ceea ce ar duce la probleme serioase din moment ce in logica pura o contradictie poate permite demonstrarea oricarui lucru.
Logica este disciplina care studiaza principiile gandirii. Ea ofera:
limbaje formale pentru a exprima cunostintele
o semantica mai clara
extragerea concluziilor dintr-o informatie data
Un important avantaj al logicii este ca aceasta poate furniza explicatii pentru modul cum se ajunge la anumite concluzii.
Pentru Semantic Web, computerele vor trebui sa aplice logica pentru toate tipurile de afirmatii (date in diferite forme) si aceste afirmatii vor fi distribuite pe Web.
Logica va avea mai multe roluri in Semantic Web. Iata cateva dintre ele:
aplica si evalueaza regulile
deduce fapte care nu au fost afirmate explicit
explica de ce s-a ajuns la o anumita concluzie
gaseste afirmatii contradictorii
este un mod de reprezentare a cunostintelor
joaca un rol cheie in formularea si executarea intrebarilor
combina informatii din mai multe surse intr-un mod coerent
D. Agenti inteligenti si servicii bazate pe Web
Un agent este un proces care actioneaza in numele utilizatorului. Un agent software actioneaza in mod autonom, comunicand cu alti agenti pentru a descoperi servicii, produse si informatii pentru utilizator.
Agentii Semantic Web vor folosi toate tehnologiile despre care am discutat:
meta-data va fi folosita pentru a identifica si a extrage informatia din surse web
ontologiile vor fi folosite pentru a asista in cautarile pe Web, pentru a interpreta si extrage informatiile si pentru a comunica cu alti agenti
logica va fi folosita pentru a procesa informatia extrasa si pentru a formula concluzii
1.2.3 Viziunea Semantic Web
Pentru a vedea mai bine cum ar trebui sa lucreze Semantic Web, am ales un exemplu din cartea “A Semantic Web Primer” scrisa de Grigoris Antoniou si Frank von Harmelen:
“Michael tocmai a avut un accident de masina, minor, si simtea dureri la nivelul gatului. Doctorul sau i-a sugerat sedinte de terapie fizica. Michael a cerut agentului Semantic Web sa gaseasca solutii la aceasta problema.
Agentul a extras detalii privind recomandarile terapeutilor din agenda doctorului tinand cont si de stipularile politei de asigurare a lui Michael. Agentul a cautat doar terapeutii localizati pe o raza de 10 km distanta de biroul sau casa lui Michael, apoi a cauta informatii legate de reputatia acestora bazandu-se pe serviciile de “rating”. A cautat dintre acestia terapeutii care erau disponibili in functie de programul lui Michael.
In cateva minute agentul a dat doua propuneri. Din pacate Michael nu a fost multumit de aceste rezultate: un terapist avea timp pentru consultatii peste abia doua saptamani, iar pentru celalalt, Michael trebuia sa conduca in timpul orelor de varf. Prin urmare Michael a pus alte constrangeri asupra timpului, si a cerut agentului sa caute din nou. Dupa cateva minute agentul a rezolvat problema. [..]” Aceasta sectiune este completa in varianta in limba engleza a lucrarii de licenta .
Fundatia Semantic Web
World Wide Web are anumite trasaturi de design care il diferentiaza de primele experimente hiperlink. Aceste trasaturi vor avea un rol important si in designul pentru Semantic Web
Web nu inseamna intreg Internetul si este posibil sa dezvoltam alte capabilitati ale Semantic Web utilizand alte mijloace. Deoarece ca web-ul este foarte raspandit si pentru ca operatiile sale de baza sunt foarte simple, multe dintre tehnologiile create pentru Semantic Web se bazeaza pe actualul Web.
Web-ul a fost creat in jurul: resurselor, adreselor standardizate (Uniform Resource Locators si Uniform Resource Indicators), si a unui set de comenzi.
A. Resurse
O resursa reprezinta o idee despre care se poate vorbi. De obicei resursele sunt considerate pachete de date tangibile (documente sau pagini), dar notiunea de resursa poate fi privita intr-unul dintre cele doua moduri:
1) In primul rand o resursa se poate modifica in timp, ea ramanand aceeasi resursa daca poate fi accesata prin acelasi URI. Alternativ, un URI poate reprezenta o varianta neschimbata a unui document. Notiunea de resursa este suficient de flexibila pentru a defini atat resursele variabile cat si cele fixe.
Trebuie mentionat ca nu accesam resursa, ci numai o reprezentare a acesteia (o copie, sau o reprezentare in alt format);
2) In al doilea rand o resursa poate fi ceva ce inca nu exista sau poate nu va exista niciodata. Poate fi un concept sau o referinta la un personaj fictiv- ceva ce nu poate fi adresat sau obtinut de pe Web.
In Semantic Web, orice resursa este identificata printr-un URI.
B. Adrese standardizate
Toate resursele de pe web sunt identificate printr-un URI. Cele mai cunoscute URI sunt cele care pot fi accesate, numite URL (Uniform Resource Locators).
C. Retele
Web-ul opereaza peste o retea foarte mare, in expansiune si cu foarte multe site-uri web. Si reuseste acest lucru datorita unor modele de proiectare:
Web-ul este descentralizat
Fiecare tranzactie pe web contine toate informatiile necesare pentru a efectuarea acesteia.
Date care pastreaza informatii despre tranzactii se numesc “stari” (“starea computerului”)
Tranzactiile Web nu au stari.
D. Web si Semantic Web
Web-ul este un sistem deschis, ceea ce inseamna ca site-urile web pot fi adaugate, fara acordul unei autoritati. Pentru atribuirea numelor de domeniu unui server, trebuie cerut acordul unei autoritati centrale pentru a se evita duplicatele.
Web-ul este incomplet ceea ce inseamna ca nu exista garantii ca orice link va functiona, sau ca toata informatia posibila este disponibila.
Este inconsistent: oricine poate spune orice pe o pagina web, in consecinta pagini diferit de web pot intra in contradictie.
Informatia pe web nu va fi niciodata pe deplin consistenta; in plus, se afla in continua schimbare.
Pentru ca Semantic Web sa urmeze modelul actualului web, acesta ar trebui sa foloseasc aspecte cheie ale actualului World Wide Web:
Sa foloseasca adrese de tip URI
Sa cunoasca notiunile de resurse adresabile si neadresabile
Sa utilizeze protocoale ce folosesc seturi universale de comenzi
Sa fie descentralizat
Sa functioneze pe scara larga
Sa se poata descurca cu linkuri inexistente si informatie incompleta si inexistenta
1.4 Structura Semantic Web
Crearea Semantic Web-ului se face pe pasi , fiecare pas creand un strat peste altul.
In crearea acestor straturi, trebuiesc urmarite doua principii:
Compatibilitatea cu straturile inferioare
Intelegerea partiala a straturilor superioare
Figura de mai jos prezinta principalele straturi ale designului si a viziunii Semantic Web.
Figura 1.2 Structura Semantic Web
XML se afla la un nivel inferior; este un limbaj cu ajutorul caruia se structureaza documentele web folosind un vocabular definit de user. Este folosit in principal pentru trimiterea documentelor pe Web.
RDF este un model de date folosit pentru scrierea unor afirmatii despre resursele Web. Modelul RDF nu se bazeaza pe XML, dar are o sintaxa bazata pe XML, de aceea se afla la un nivel superior.
RDF schema poate creea o ierarhie a resurselor; se bazeaza pe modelul RDF.
RDF Schema poate fi privit ca un limbaj primitiv de scriere a ontologiilor, dar este nevoie de un limbaj mai puternic care sa-l extinda pentru Semantic Web. Aici intervine nivelul Logicii care permite extinderea acestui limbaj
Stratul Verificarii implica procese deductive, reprezentari ale verificarii in limbaje Web din straturile inferioare si validarea verificarii
Stratul Increderii se va baza pe semnaturi digitale si alte date obtinute pe baza recomandarile agentilor Web.
Fiind localizata in varful piramizii, increderea este un concept crucial : Semantic Web va atinge potentialul maxim in momentul in care utilizatorii au incredere in operatiile efectuate de acesta (securitate) si in calitatea informatiei furnizate.
a) Baza
Exista o cantitate impresionanta de informatie pe Web, iar majoritatea este in format HTML, datorita faptului ca acest limbaj este suportat de browsere si usor de inteles de catre creatorii paginilor web.
HTML descrie documentele: paragrafuri, header-uri, imagini, tabele, etc., si ordinea acestora, dar este de datoria browserului sa decida cum afiseaza informatia. Aceasta metoda furnizeaza rezultate bune atunci cand informatia se adreseaza strict oamenilor.
Cu XML este posibil sa descriem informatia in alte moduri. De aceea el este considerat ca fiind fundatia pentru Semantic Web.
Stratul XML Schema furnizeaza capabilitati de structurare a datelor, folositoare intr-un document XML.
b)Proprietati si relatii
RDF indica intelesul diferitelor elemente dintr-o pagina. In plus atribuie proprietati lucrurilor, si creeaza legaturi intre acestea.
Stratul RDF Schema descrie aceste proprietati;
Stratul Ontologiilor nu numai ca descrie proprietatile, dar defineste si relatiile dintre acestea.
Aceste straturi sunt folosite pentru a descrie si a reprezenta informatia.
Analiza, verificarea si increderea
Odata ce relatiile dintre proprietati resurse si termeni au fost stabilite, afirmatiile RDF pot fi analizate pentru consistenta, si se pot deduce concluzii.
Asta inseamna ca pot fi descoperite afirmatii care nu au fost formulate explicit.
Aceste capabilitati sunt oferite de stratul Logicii si al Verificarii
Cand programele lucreaza cu date de pe Web, stratul Increderii apeleaza stratul Logicii si al Verificarii pentru a analiza afirmatii si pentru a deduce concluzii. Stratul Logicii si al verificarii trebuie sa cunoasca legaturile dintre termeni si proprietati si daca sunt corect folosite.
Stratul Ontologie trebuie sa foloseasca documentul structurat, creat de straturile RDF si XML Schema Aceste dependente pot fi vazute si din alt punct de vedere: Stratul RDF foloseste RDF Schema si Ontologiile pentru a atribui proprietatile, iar stratul XML furnizeaza structura datelor.
RDFn (Resource Description Framework). Introducere.
RDF-Resource Description Framework (Cadru de Descriere a Resurselor) asa cum implica numele, RDF este un cadru de descriere al resurselor (meta-data).
RDF nu poate fi privit ca un limbaj de programare, ci ca un model de date.
Pentru a-si indeplini rolul de a descrie resursele, trebuie sa poata descrie:
tipuri de date ce exista sau care pot exista
designul structural al seturilor de date
relatiile dintre biti de date
RDF este construit dupa urmatoarele reguli:
O resursa este orice, adresabil printr-un URI; asta include toate paginile Web dar si elementele individuale dintr-un document XML.
O proprietate este o resursa care are nume si care poate fi folosita ca o proprietate. O proprietate trebuie sa fie resursa, ca sa poata avea si ea la randul ei proprietati.
O declaratie este alcatuita din: o resursa, o proprietate, si o valoare. Aceste elemente sunt cunoscute ca: 'subiect', 'predicat' si 'obiect' al unei declaratii (afirmatii). Un exemplu de declaratie este: "Autorul cartii Don Quijote este Miguel Cervantes “. Valoarea poate fi un simplu string, "Miguel Cervantes " in exemplul precedent, sau poate fi reprezentat de o alta resursa: "Pagina principala pentru link-ul http://www.google.com/advanced search?hl=en este http://www.google.com ."
Urmatoarea descriere a modelului RDF a fost preluata din (Passin 2004).
RDF foloseste un model simplu de date. Exista lucruri care se numesc resurse si declaratii care se pot face despre aceste resurse. O declaratie simpla leaga doua resurse. Aceste declaratii sunt ca niste propozitii simple care au o structura de tipul subiect-verb-obiect. Complicatiile apar cand modelul este aplicat la un exemplu practic, dar fundamental, RDF reprezinta declaratii care descriu informatii despre anumite subiecte.
XML nu furnizeaza mijloace pentru a vorbi despre semantica, de aceea acest limbaj nu este acesibil computerelor (pentru computere, un tag nu are asociat un inteles; ramane la latitudinea aplicatiilor de a interpreta tagurile )
RDF este format din triplete. Fiecare declaratie atesta un singur lucru despre despre subiectul sau, prin atribuirea unor proprietati si a unor valori.
Componenta proprietate a unui triplet se numeste predicat, iar valoarea se numeste obiect. Subiectul unei declaratii este o resursa identificata printr-un URI. Obiectul poate fi o resursa sau un literar.
Putem intalni resurse care nu sunt identificate prin URI, ci prin legaturile cu alte resurse. Asemenea resurse se numesc resurse anonime, sau noduri albe (sau noduri goale).
Obiectul unei declaratii poate fi subiectul altei declaratii. O colectie de date RDF formeaza o retea de declaratii interconectate ce alcatuieste modelul informational de reprezentare a datelor in RDF. Acest model este simplu din moment ce este format din diviziuni simple (tripletele), dar este si complex deoarece un numar mare de noduri sunt interconectate intr-un graf.
RDF este folositor ca un mod flexibil de a stoca structuri de date iregulare. RDF este independent de domeniu. Useri isi definesc singuri propriul lor vocabular intr-un limbaj numit RDF Schema.
Vom descrie RDF in detaliu in Capitolul 2
Topic Maps. Introducere
Urmatoarea descriere a modelului Topic Maps a fost extrasa din (Passin 2004).
Topic Maps este o alta tehnologie folosita pentru organizarea informatiei, inclusiv a meta-datei.Topic Maps a evoluat din eforturile de a crea indecsi electronici. De aceea modelul TM este potrivit pentru aplicatiile care implica descoperirea si navigarea bazelor de date. Topic maps are un stil diferit de RDF de a modela informatia.
Modelul de baza al Topic Maps este de a lega concepte cu informatia despre aceste concepte, promovand colocatia si navigarea informatiilor (adica gasirea corecta a informatiilor si de asemenea informatiile inrudite).
Topic Maps se bazeaza pe ideea de concepte-orice despre care se poate vorbi. Un topic este reprezentarea pe computer a unui concept.
Conceptele sunt importante datorita legaturilor lor cu alte concepte.
Doua topice sunt legate intre ele prin asocieri. Topicele pot contine, sau pot indica informatia relevanta folosind ocurente (“occurrence”)
Identitatea Subiectului (Subject identity) este un aspect cheie pentru Topic Maps. Subiectul unui topic map este reprezentat de conceptul la care se refera.
Identitatea acestuia poate fi stabilita intr-unul din urmatoarele moduri :
specificand un identificator public (un PIS), care contine o descriere a subiectului.
afirmand ca o anumita resursa (pagina web) indica subiectul.
afirmand ca o anumita resursa este subiectul.
In toate cele trei cazuri este nevoie de ratiunea umana pentru a determina care este subiectul unui topic.
Cu toate ca scopul initial pentru TM era de a se comporta precum un index intr-o masa de informatie, acesta poate stoca si organiza date de toate tipurile.
Topic Maps este potrivit pentru a face parte din Semantic Web deoarece poate referi orice subiect oriunde pe net, poate combina informatii. Exista un standar de nivel international pentru descrierea acestui model.
1.7 Rezumat
Semantic Web este o initiativa care tinteste spre imbunatateste actualului WWW.
Nu are o singura definitie, doarece poate fi privit din mai multe puncte de vedere.
Ideea de baza este de a folosi pe Web informatie procesabila de catre computere.
Tehnologiile cheie includ: meta-data, ontologiile, logica si inferenta, agentii inteligenti.
Semantic Web trebuie sa fie o extindere a actualului Web
Dezvoltarea proiectului Semantic Web se face in straturi.
RDF- este un cadru de descriere a resurse. Este un model de date.
RDF se bazeaza pe modelul tripletelor.
Topic Maps a evoluat din eforturile de a crea indecsi electronici
Capitolul 2- Doua formalisme de adnotare: RDF si Topic Maps
2.1 Introducere. Adnotari
Sectiunea despre RDF se bazeaza in special pe specificarile de pe site-ul www.w3c.com, iar cea despre Topic Maps pe specificarile extrase de pe www.topicmaps.org .
In acest capitol vom examina modelarea si reprezentare cunostintelor care servesc drept fundatie pentru Semantic Web.
Vom analiza doua formalisme de adnotare: RDF si Topic Maps .
Vom vedea cum lucreaza RDF si Topic Maps, cum pot modela informatia si care este legatura lor cu Semantic Web.
2.1 .1 Sisteme de adnotare pentru Web
In anumite dictionare cuvantul adnotare este definit astfel:
O nota critica sau explicativa; un comentariu (American Heritage)
Procesul de a furniza comentarii critice sau note explicative (American Heritage)
Un comentariu (de obicei adaugat unui text)
Procesul de a adauga note (Word Net)
Un nod nou de comentarii legat de un nod deja existent (din punctul de vedere al hipertext-ului). “ Daca cititorii, ca si autorul poate adnota noduri, acestia pot furniza imediat feedback daca informatia este gresita”. (FOLDOC)
Ultima definitie este orientata catre Web, din moment ce se refera la hiperlinkuri si noduri.
Adnotarea reprezinta adaugarea de informatii (precum note, comentarii, linkuri catre resurse, etc) la documentele web existente, fara a modifica originalul.
Semantic Web poate sustine functionalitatea care ar duce la imbunatatirea adnotarilor:
Descoperirea adnotarilor: Un computer poate localiza adnotarile, si le poate afisa.
Adnotari procesabile de computere: Adnotarile trebuiesc intelese atat de oameni cat si de computere
Filtrari inteligente: Fara filtrare, o pagina poate colecta multe note astfel incat sa devina ilizibila
Imbunatatirea cautarilor: Adnotarile adecvate pot ajuta motoarele de cautare in localizarea informatiilor
Cea mai simpla modalitate de a adnota o pagina web, este de a o descarca pe computer si apoi de a insera comentarii.
Aceasta modalitate functioneaza doar pentru paginile care pot fi editate, precum pagini HTML.
Browserul Amaya (creat de W3C) subliniaza pasajele adnotate. Adnotarile pot fi salvate pe un computer sau pe un server la distanta.
Wiki collaborative
Un Wiki (pe scurt WikiWiki) este un site care isi lasa membrii (sau cititorii) sa editeze articolele sau sa adauge comentarii.
De asemenea exista conventii pentru formatarea textului.
Exista si alte site-uri care furnizeaza capabilitati asemanatoare, cu toate ca putine sunt dispuse sa lase cititorii sa aduca modificari in textul original.
Annotea
W3C lucreaza la un sistem experimental de adnotari care foloseste RDF pentru a descrie adnotarile. Continutul fiecarei note este reprezentat intr-un document XHTML.
Amaya poate scrie si citi adnotarile realizate cu Annotea. Cand Amaya incarca o pagina de pe Web, verifica inregistrarile adnotarilor (de pe server sau computer) pentru a vedea daca exista adnotari pentru acea pagina. Daca exista, adnotarile sunt incarcate si afisate prin intermediul anumitor icoane, in anumite zone ale documentului.
Multivalent browser
Poate adnotat mai multe tipuri de documente, nu doar HTML si XML. Se poate adnota orice tip de documente afisabile de un browser, chiar si grafice, imagini, adnotari (adnotarea adnotarilor). Adnotarile se pastreaza intr-un strat separat si sunt salvate in fisiere XML nu RDF, separate.
Daca documentul se schimba, adnotarile din document pot sfarsi prin a fi legate de alte zone (paragrafe), sau pot disparea.
Multivalent Browser propune o cale de rezolvare a acestei probleme:foloseste un fragment din text impreuna cu textul locatiei tinta (locatia adnotata) pentru a identifica cu siguranta zona adnotata.
2.1.2 Imbunatatirea adnotarii.
Viitoarele sisteme de adnotare vor trebui sa se confrunte cu urmatoarele probleme:
Stocarea, extragerea si descoperirea adnotarilor trebuie facuta intr-un mod mai convenabil.
Trebuie sa fie posibil sa aplicam adnotarea pentru mai multe tipuri de documente
Trebuie sa putem crea adnotari cu o semanatica usor inteleasa de computerelor
Trebuiesc create interfete mai bune
Browser-ele trebuie sa permita accesul pragmatic la adnotatii
Sistemele de adnotare trebuie sa poata folosi orice ontologie relevanta pentru subiectul adnotat
Cu asa capabilitati, adnotarile vor juca un rol important in viitorul Web
2.2 Modelul RDF
2.2.1 Introducere
Semantic Web are nevoie de un limbaj simplu care poate lucra cu date de structuri variabile. RDF este candidatul RDF pentru acest rol.
RDF este folosit pentru a reprezenta resurse Web si metadata.
Un exemplu de metadata: este titlul, autorul si data modificarii unei pagini web. RDF poate de asemenea sa reprezinte informatii despre lucrurile care pot fi identificate pe web, dar nu pot fi obtinute direct, cum ar fi preturi, persoane, etc.
RDF serveste ca baza pentru limbajele de nivel inalt care descriu ontologii.
RDF se bazeaza pe idea de a identifica lucrurile, utilizand identificatori Web, numiti URI (Uniform Resource Identifiers) si de a descrie resursele folosind proprietati simple si valori ale acestora.
Din acest motiv RDF poate reprezenta afirmatii simple despre resurse sub forma de graf, avand ca noduri resursele si ca arcuri proprietatile acestora.
Pentru a putea juca acest rol de a descrie data si metadata, RDF trebuie sa detina urmatoarele capabilitati:
Sa poata descrie tipuri de date care pot exista
Sa descrie designul structural al seturilor de date
Sa descrie relatii dintre biti de date
RDF foloseste un model simplu de date: exista lucruri care se numesc resurse si afirmatii care pot fi facute despre aceste resurse. O singura afirmatie leaga doua resurse. Afirmatiile sunt ca niste proprozitii simple de tipul: subiect-verb-obiect. De exemplu: “Ivona scrie lucrarea”
Ivona este subiectul, scrie este verbul iar lucrarea este obiectul. Acesta este modelul RDF.
A) Concepte de baza
In RDF, o afirmatie este uneori numita triplet deoarece are trei parti. Subiectul unei declaratii se numeste subiect, echivalentul verbului se numeste predicat sau proprietate, iar restul se numeste obiect sau valoare (deoarece afirmatiile RDF atribuie o valoare subiectului)
Figura urmatoare descrie structura unui triplet RDF:
subiect predicat obiect
Ivona, scrie, lucrarea
triplet
Figura 2.1 Structura unui triplet RDF
Valoarea unei proprietati poate fi simpla; asemenea valori se numesc literali.
Valoarea unei proprietati poate fi un literal sau o alta resursa.
Un literal nu poate fi subiectul unei afirmatii.
O colectie de date RDF nu are un nume standard; uneori se numeste magazie RDF, set de date RDF, baza de cunostinte sau baza de date.
Termenii RDF ce descriu partile unei afirmatii sunt:
subiecutul reprezentat de “Ivona”
predicatul este cuvantul “scrie”
obiectul este “lucrarea”
Referinte URI
Resursele sunt lucrurile despre care RDF face afirmatii.
Pentru a identifica resursele, RDF foloseste URI. Un URI este folosit pentru a identifica un concept, un lucru tangibiul care nu poate fi descarcat de pe computer, sau obtinuta de pe retea. O referinta URI este un URI plus un character optional “identificator de fragment” (partea care urmeaza dupa semnul # dintr-un URI).
Pentru a identifica o resursa, un URI este asociat doar cu resursa pe care o reprezinta.
O rersursa poate fi identificata prin proprietatile si relatiile pe care le are cu alte resurse.
Recomandarea RDF de pe site-ul w3c contine un concept numit afirmatie (statement). Resursele de tipul afirmatie RDF sunt identificate folosind urmatorul URI: http://www.w3c.org/1999/02/22-rdf-syntax-ns#Statement
La aceasta adresa intamplator se gaseste un document RDF, care contine, printre altele, urmatorul fragment:
<!- – This is the RDF Schema for the RDF data model as described in the Resource Description Framework (RDF) Model and Syntax Specification http://www.w3.org/TR/REC-rdf-syntax – >
<s:Class rdf:ID= “Satement”
s:comment=”A triple consisting of a predicate, a subject and an object.” />
<s:Class rdf:ID= “Property”
s:comment=”A name of a property, defining specific meaning for the propery.”/ >
Identificatorul despre care vorbim nu trebuie sa indice un document. Faptul ca indica un document este folositor (in acest caz identificatorul de fragment “#Statement” ar face ca informatia sa fie afisata cu bold intr-un browser care intelege XML)
“RDF foloseste URIs pentru a identifica:
Indivizi: Eric Miller, identificat prin : http://www.w3.org/People/EM/contact#me
Tipuri de lucruri: Persoane, identificat prin http://www.w3.org/2000/10/swap/pim/contact#Person
Proprietati ale acestor lucruri: mailbox(adresa de email), identificat prin http://www.w3.org/2000/10/swap/pim/contact#mailbox
Valorile acestor proprietati: mailto:[anonimizat] este valoare pentru proprietatea mailbox (adresa de email)” (W3C RDF Primer)
Ca HTML, RDF/XML este un model de date procesabil de computere; folosind URI leaga anumite informatii pe Web. Spre deosebire de hipertextul conventional URI folosit de RDF poate referi orice lucru care poate fi identificat pe Web, inclusive lucrurile care nu pot fi descarcate de pe retea (precum persoana Eric Miller).
In afara de a descrie pagini web, RDF poate descrie masini, afaceri, persoane, stiri, etc.
C) Resurse anonime
RDF nu impune ca orice resursa dintr-o afirmatie sa fie identificata printr-o referinta URI. O resursa fara un identificator URI este ca si cum am ne-am referi la o persoana ca “omul acela”. Cele mai multe programe creaza proprii lor identificatori pentru aceste resurse, care nu trebuiesc cunoscute in afara programului. Resursele anonime se numesc noduri albe sau a-noduri (blank nodes or b-nodes); acestea sunt resursele care nu au un URI.
D) RDF si bazele de date
Modelul RDF difera de ceea ce gasim in bazele de date conventionale, dar diferenta nu este asa mare cum pare la inceput.
Tabelul 2.1 Fragment dintr-o baza de date
Fiecare rand are aceeasi structura ca si urmatorul, iar randul reprezinta o relatie particulara intre celulele lui.
Fiecare coloana reprezinta un fapt despre o anumita persoana, aceasta fiind reprezentata de un rand.
Randurile din table pot fi reprezentate astfel:
(“Ivona Profire ” , “0040723856333” , “23” , “Bucharest”, “Independentei”, “[anonimizat] ”) atata vreme cat stim ce reprezinta fiecare coloana.
Intr-o baza de date bine conceputa, toate faptele dintr-un rand depind de o cheie primara, care trebuie sa fie unica intr-un table.
Tabelul 2.2 Tabel ce contine ID
Diferenta dintre cele doua versiuni consta in identitatea persoanei. Daca in versiunea 1, numele persoanei se schimba, nu vom mai sti la ce se refera datele ramase.
Ambele variante pot fi reprezentate folosind RDF
Deoarece RDF are numai resurse si tripleti, trebuie sa reducem tabelul in tabele cat mai mici posibile.
Un table cu un rand si doua coloane poate fi vazut ca un triplet.
Coloanele trebuie sa fie independente intre ele.
Tabelul 2.3.1 Reducerea tabelului principal-1
Proprietate
Valoare
Tabelul 2.3.2 Reducerea tabelului principal-2
Observam urmatorul model: (persoana)- (proprietate)- (valoare) care este de fapt un triplet RDF. O colectie de asemenea tabele alcatuiesc o baza de date.
Orice tabel poate fi reprezentat sub forma de triplete RDF.
Daca tripletele au proprietati diferite, acestea nu se pot incadra intr-un table existent. Aceasta este o problema pentru bazele de date conventionale dar nu si pentru RDF
Un set de date RDF are avantajul felxibilitatii. In plus se pot face afirmatii despre predicate dar si despre valorile acestora.
2.2.2 Proprietati RDF
Din moment ce proprietatile RDF sunt un fel de resurse, acestea pot fi definite de o referinta URI.
Urmatoarea este o proprietate RDF standard definita in recomandarea w3c pentru RDF:
http://www.w3.org/1999/02/22-rdf-syntax-ns#type
Aceasta proprietate desemneaza tipul unei resurse.
Din motive didactice vom folosi nume comune precum “persoana” in loc de
http://description.org/schema/Person.
Cand dorim sa distribuim date RDF catre alte sisteme, este necesar sa folosim URI pentru a identifica in mod unic resursele.
Crearea vocabularelor si a identificatorilor folositi pe Web este problema ontologiilor.
De obicei identificatorii URI nu sunt usor de citit, de aceea e indicat a se folosi etichete pentru resurse.
O afirmatie nu este o resursa si de aceea nu poate fi subiectul unei afirmatii. RDF ocoleste aceasta limitare astfel: la urmatoarea adresa http://www.w3.org/1999/02/22-rdf-syntax-ns#Statement se gaseste un tip particular de resurse care se numesc rdf:Statement (afirmatii rdf).
Aceste resurse au urmatoarele proprietati:
rdf :subject
rdf :predicate
rdf :object
rdf :type ( a carei vaolare este rdf: statement).
Un rdf: Statement declara ca exista o afirmatie care are un anumit subiect, predicat si obiect. Un lucru deosebit este ca un rdf: Statement nu poate fi identificat printr-un triplet, chiar daca exista unul care are acelasi subiect, predicat, si obiect ca rdf:Statement.
Nu se poate face o afirmatie referitoare la un triplet , dar se pot face afirmatii despre ceva de tipul rdf: Statement.
2.2.3 Grafuri RDF
Grafurile sunt portivite pentru reprezentarea afirmatiilor RDF.
Un graf este o colectie de noduri legate prin arcuri. Un arc leaga doua noduri si are o eticheta.
Pentru RDF , un nod reprezinta o resursa sau un literal, iar arcul reprezinta predicatul.
Figura 2.2 reprezinta o afirmatie RDF in forma unui graf.
Graful declara ca “o masina are o culoare a carei valori este albastru”. Cu toate ca graful este simplu, eticheta “masina” este ambigua.
masina culoare albastru
Figura 2.2 Graf RDF
In RDF nu putem vorbim despre toate masinile, ci doar despre anumite resurse.
In reprezentarea afirmatiilor RDF sub forma de grafuri, vom folosi un cerc sau un oval pentru a reprezenta o resursa si un dreptunghi pentru a reprezenta un literal.
Resurse cu mai multe afirmatii.
Putem vedea un rand dintr-o baza de date ca reprezentand mai multe afirmatii ale aceleiasi resurse. Sa consideram primul rand din Tabelul 2.1 si sa-l reprezentam in RDF sub forma de graf:
Tabelul 2.4 Primul rand din Tabelul 2.1
Acesta este un exemplu de reprezentare a unui grup de afirmatii RDF ca un graf RDF:
Ivona Profire
name
phone 0723856333
person-1 street Independentei
city
email Bucharest
age
23 mailto:[anonimizat]
Figura 2.3 O resursa cu mai multe proprietati
Fiecare arc/proprietate reprezinta o afirmatie separata. Subiectul acestor declaratii este person-1.
O problema in baza de date este faptul ca City si Street nu sunt corelate. Putem rezolva aceasta problema in RDF, folosind noduri goale (albe).
Ivona Profire
name
phone 0723856333
person-1
address city Bucuresti
street Independentei
age email
23 mailto:[anonimizat]
Figura 2.4 Gruparea afirmatiilor
Acum person-1 are o adresa care este asociata cu un oras si o strada. Nu stim ca nodul este o resursa de tipul adresa dar putem explicita acest lucru creand un nou nod, ca in figura 2.5 .
In figura 2.4, “23” ar trebui interpretat ca un numar intreg, nu ca un string constituit din caracterele “2”si “3”, sau ca un numar octal (din moment ce literalul reprezinta valoarea proprietatii varsta). Totusi in figura 2.4 nimic nu indica faptul ca “23” ar trebui interpretat ca un numar intreg.
In limbajele de programare sau in sistemele de baze de date este mentionat cum trebuie intrepretat un literal, asociindu-i un tip de date, in acest caz tipul “integer”.
O aplicatie care intelege tipurile de date stie daca literalul “10” este o reprezentare a numarului zece, a numarului doi sau a unui string alcatuit din caracterele “1” si “0”., in functie de tipul de date specificat: integer, binary, sau string.
In figura 2.5 am reprezentat varsta persoanei-1 ca fiind numarul intreg “23”, si am creat un nod anonim pentru adresa.
Ivona Profire
name
phone 0723856333
person-1
address city Bucuresti
street Independentei
age email type
mailto:[anonimizat] address
Figura 2.5 Nod anonim pentru adresa
Iata cateva lucruri care se pot face cu datele sub forma RDF si care nu se pot face daca datele se afla intr-o baza de date conventionala:
combinarea datelor cu date din seturi care nu folosesc acelasi model.
adaugarea datelor care nu se potrivesc in tabelele structurate
schimb de informatii cu aplicatii care pot procesa date RDF
folosirea unui procesor RDF care poate descoperi relatii noi in baza de date
adaugarea unor afirmatii despre publicatii care au fost definite pe Web. (Nu suntem limitati la a vorbi doar despre datele stocate in propria baza de date).
2.2.4 Capabilitati RDF.
RDF furnizeza capabilitati aditionale precum tipuri si proprietati pentru reprezentarea grupurilor de resurse si afirmatii RDF.
a) Containere RDF
Sunt necesare pentru a descrie un grup. De exemplu pentru a sublinia faptul ca o carte a fost scrisa de mai multi autori, sau lista studentilor dintr-o grupa.
RDF furnizeza un vocabular de stocare alcatuit din trei tipuri predefinite. Un container reprezinta o resursa ce contine lucruri, iar lucrurile continute se numesc membri.
Membrii unui container se numesc resurse (inclusiv resurse anonime, adica noduri goale) sau literali. RDF defineste trei tipuri de containere:
rdf:Bag
rdf:Seq
rdf:Alt
O resursa de tipul rdf:Bag reprezinta un grup de resurse sau literali, inclusiv dubluri; nu conteaza ordinea in care apar membrii.
O resursa de tipul rdf:Seq (o secventa) reprezinta un grup de resurse sau literali, inclusiv dubluri; ordinea in care apar membrii este importanta.
O resursa de tipul rdf:Alt (o alternativa) reprezinta un grup de resurse sau literali care reprezinta o modalitate alternativa de a defini o resursa. De exemplu o alternativa pentru cuvantul “mar” este cuvantul “apple” care in limba engelza identifica aceeasi resursa.
Pentru a descrie o resursa ca fiind de tipul unuia dintre aceste containere, resursei i se atribuie proprietatea rdf:type a carei valoare este una dintre resursele predefinite rdf:Bag, rdf:Seq, or rdf:Alt.
Membrii unui container pot pot fi descrisi definind proprietatea de membru a unui container. Aceste proprietati de membru au numele de forma rdf:_n, unde n reprezinta un numar intreg
Exemplu de container.
Vrem sa reprezentam propozitia:”Cursul 6.001 este frecventat de studentii Amy, Mohamed, Johann, Maria, and Phuong” , i.e., in engleza: "Course 6.001 has the students Amy, Mohamed, Johann, Maria, and Phuong"
Cursul poate fi descris, atribuindu-i o proprietate s:students a carei valoare este un container de tipul rdf:Bag (care reprezinta grupul de studenti).
Apoi folosind proprietatea de membru al unui container, studentii, in mod individual, pot fi identificati ca fiind membri al acelui grup, ca in graful RDF din Figura 2.6.1:
Figura 2.6.1: Descrierea unui container Bag
b)Colectii RDF
“O limitare a folosirii containerelor este faptul ca un pot fi inchise, adica nu exista un mod de a afirma ca”acestia sunt toti membrii unui container”.
Un container spune doar ca anumite resurse sunt membrii lui; nu spune daca mai exista alti membrii. RDF furnizeaza suport pentru descrierea grupurilor ce contin numai membrii care sunt specificati, sub forma de colectii RDF.
O colectie RDF este un grup de lucruri reprezentat ca o lista in graful RDF. Aceasta structura este construita folosind un vocabular de colectie predefinit alcatuit din tipul rdf:List si proprietatile :
rdf:first
rdf:rest
rdf:nil
Pentu a ilustra o colectie, propozitia "The students in course 6.001 are Amy, Mohamed, and Johann" poate fi reprezentata folosind graful din Figura 2.6.2:
Figura 2.6.2: O colectie RDF
In acest graf, fiecare membru al colectiei , ca s:Amy este obiectul unei proprietati rdf:first al carei subiect este o resursa (un nod gol in acest exemplu) care reprezinta o lista. Aceasta resursa-lista este legata de restul listei printr-o proprietate rdf:rest.
Sfarsitul listei este indicat de catre proprietatea rdf:rest avand ca obiect resursa rdf:nil (rdf:nil reprezinta lista vida).
c) Reificare RDF
Unele aplicatiile trebuie sa descrie afirmatii RDF, folosind modelul RDF, de exemplu pentru a inregistra informatie despre afirmatiile facute: cine le-a facut si alte informatii similare (informatie de “provenienta”) .
RDF furnizeaza un vocabular predefinit care este folosit in situatiile in care trebuie sa descriem afirmatii RDF. O descriere a unei afirmatii utilizand acest vocabular se numeste reificarea (reification) unei afirmatii.
Vocabularul pentru reificarea RDF consta in:
tipul: rdf:Statement
proprietatile:
rdf:subject
rdf:predicate
rdf:object
Un exemplu de reificare este modelat in figura 2.6.3.
In cuvinte, graful afirma ca: “Exista ceva al carui tip este rdf:Statement. Are ca subiect ‘person-1’, ca predicat ‘name’, iar ca obiect ‘Ivona Profire’”.
“A reifica inseamna a face un lucru din ceva, in acest caz: o resursa dintr-o afirmatie”
(Passin 2004)
Figura 2.6.3 Reificarea unei afirmatii
Graful spune ca “Exista o afirmatie al carui subiect este ‘person-1’, iar afirmatia spune ca numele asociat cu ‘person-1’ este ‘Ivona Profire’.”
Resursa rdf:Statement nu exprima acelasi lucru, spus de catre afirmatia originala.
E ca si cum as spune: “Ma gandesc sa spun ca vreau sa merg la cinema”.
Afirmatia reificata nu poate inlocui afirmatia propriu-zisa dar furnizeaza un mod prin care se poate vorbi despre acea afirmatie.
2.2.5 Serializarea RDF in sintaxa XML
Pentru a inregistra informatie si a face schimb de date intre grafuri, exista pentru RDF o sintaxa bazata pe XML, numita RDF/XML.
Vom incepe cu o scurta prezentare a sintaxei XML.
2.2.5.1 XML
XML (Extensible Mark-up Language ) reprezinta un cadru pentru definirea limbajelor de marcare.
In XML nu exista o colectie fixa de taguri ca in HTML; tagurile pot fi definite in functie de informatia pe care o contin.
XML a fost creat in scopul de a:
separa sintaxa de semantica
ofera o baza comuna pentru structurarea informatiilor
suporta internationalizarea(Unicode) si independenta de platforma
XML nu este un substituent al HTML. Au fost create in scopuri diferite:
XML este folosit pentru a descrie informatia
HTML este folosit pentru a afisa informatia
2.2.5.2 Sintaxa XML
Un document XML este alcatuit dintr-un prolog, niste elemente si optional un epilog.
Prologul este format dintr-o declaratie si optional o referinta catre structura externa a documentului.
Examplu de declaratie:
<? xml version=”1.0” encoding=”UTF-16”>
Elementele XML reprezinta lucrurile despre care se vorbeste in document; ele compun conceptul principal al documentelor XML. Ca si HTML , XML se bazeaza pe taguri.
Un element este format dintr-un tag de deschidere, continut, si un tag de inchidere. Aceste taguri pot fi imbricate (taguri in interiorul altor taguri). Toate tagurile din XML trebuiesc inchise, spre deosebire de cele din HTML pentru care exista exceptii, de exemplu tagul <br> poate fi lasat deschis.
Examplu de element:
<student>Ivona Profire</student>
Continutul poate fi text sau un alt element, sau nimic:
<student>
<name>Ivona Profire</name>
<phone>0040723856333</phone>
</student>
Daca elemental nu contine nimic, este numit element gol(empty).
Un element gol:
<student></student>
poate fi abreviat astfel:
<student/>
Un element gol poate avea attribute. Un atribut este o pereche nume-valoare din interiorul tagului de deschidere al unui element. De exemplu:
<student name=”Ivona Profire” phone=”0040723856333” />
Un exemplu de atribut pentru un element care nu este gol:
< order order_No=”212749” customer=”John Smith” date=”October 5, 2004”>
<item itemNo=”s327” quantity=”3”/>
<item itemNo=”b418” quantity=”1”/>
</order>
Atributele pot fi inlocuite cu elemente imbricate, dar atributele nu pot fi imbricate:
<order>
<order No>212749</order No>
<customer>John Smith</customer>
<date>October 5, 2004</date>
<item>
<itemNo>s327</itemNo>
<quantity>3</quantity>
</item>
<item>
<itemNo>b418</itemNo>
<quantity>1</quantity>
</item>
</order>
Un comentariu este o portiune de text ignorata de catre procesorul XML. Acesta are forma:
<! – This is a comment – >
Un document XML este bine-realizat daca este corect din punct de vedere sintactic.
Iata cateva reguli pentru a stabili daca un document este bine-realizat:
Exista o singura radacina
Fiecare element contine un tag de deschidere si unul de inchidere
Tagurile nu se pot intercala ca in:
<student><name>Ivona Profire</student></name>
Atributele din interiorul unui element au nume unice
Elementele si tagurile trebuie sa fie valide:primul character trebuie sa fie o litera sau unul din semnele: ‘_’, ‘:’.Nici un nume nu poate incepe cu stringul ‘xml’
XML este case sensitive
Aceste reguli nu spun nimic despre structura documentelor.
Putem defini structura unui document XML folosind:
un document DTD (Document Type Definition)
o schema XML (XML Schema)
Vom prezenta doar XML Schema deoarece vom folosi doar aceasta metoda de a defini structura in acest proiect.
XML Schema se bazeaza pe XML.
Aceasta metoda permite:
Refolosirea tehnologiilor folosite
Refolosirea si redefinirea schemelor
Definirea unor tipuri noi de date prin extinderea sau restrictia celor existente
Un element XML Schema este un element ce are un tag de deschidere precum:
<xsd:schema xmlns:xsd=”http://www.w3.org/2000/10/XMLSchema ” version=”1.0” >
Elementul foloseste schema XML gasita pe site-ul W3C. Aceasta schema reprezinta fundatia pe care sunt construite celelalte scheme.
Sintaxa unui element:
<element name=”…”/>
<element name=”head” minOccurs=”1” maxOccurs=”1”/>
Sintaxa unui atribut:
<attribute name=”…”/>
Exemplu de atribut:
<attribute name=”id” type=”ID” use=”required”/>
< attribute name=”speaks” type=”Language” use=”default” value=”en”/>
XML Schema permite definirea unor noi tipuri de date, dar exista si tipuri predefinite precum:
Date de tip numeric: integer, short, byte, long, float, decimal
Date de tip string: string, ID, IDREFF, CDATA, Language
Date de tipul data calendaristica: time, Date, Month, Year
Tipurile de date definite de user pot fi: tipuri simple de date (care nu folosesc elemente sau atribute), si tipuri complexe de date(care folosesc elemente si atribute).
Tipurile complexe de date sunt definite folosind tipuri existente de date, definind in plus attribute si folosind:
Sequence – o secventa de elemente in care ordinea de aparitie este importanta
All – o colectie de elmente care trebuie sa apara, dar nu conteaza ordinea in care acestea apar
Choice – o colectie de elemente din care numai unul va fi ales
Un exemplu de tip complex de date:
<complexType name=”studentType”>
<sequence>
<element name=”firstname” type=”string”
minOccurs=”0” maxOccurs=”unbounded”/ >
<element name=”lastname” type=”string” />
</sequence>
<attribute name=”year” type=”CDATA” use =
”required”/>
</complexType>
Ceea ce am scris inseamna ca daca un element este de tipul studentType atunci trebuie sa aibe un atribut year(an) , poate avea mai multe prenume(firstname) si trebuie sa aibe exact un nume de familie (lastname).
Putem extinde acest tip de date student:
<complexType name=”extendedStudentType”>
<extension base=”studentType”>
<sequence >
<element name=”email” type=”string”
minOccurs=”0”maxOccurs=”1”/ >
</sequence >
<attribute name=”group” type=”CDATA” use
=”required” />
</extension>
</complexType>
In acest exemplu, studentType a fost extins prin adaugarea unui element email si a unui atribut group :
<complexType name=”extendedStudentType”>
<sequence >
<element name=”firstname” type=”string”
minOccurs=”0” maxOccurs=”unbounded”/ >
<element name=”lastname” type=”string” />
<element name=”email” type=”string”
minOccurs=”0”maxOccurs=”1”/ >
</sequence >
<attribute name=”year” type=”CDATA” use
=”required”/>
<attribute name=”group” type=”CDATA” use
=”required” />
</complexType>
Exista o ierarhie a relatiilor dintre tipul de date creat la inceput si cel extins: instantele tipului extins sunt instante si pentru tipul creat initial.
Restrictia tipului de date student:
<complexType name=”restrictedStudentType”>
<restriction base=”studentType”>
<sequence >
<element name=”firstname” type=”string”
minOccurs=”1” maxOccurs=”2”/ >
<element name=”lastname” type=”string” />
</sequence >
<attribute name=”year” type=”CDATA” use
=”optional”/>
</restriction>
</complexType>
Am restrictionat numarul de prenume care pot aparea.
Un document poate folosi una sau mai multe scheme XML; pentru a fi siguri ca nu avem doua elemente cu acelasi nume in cele doua scheme, trebuie sa folosim prefixe:
prefix:name
Numele se spatii (namespaces) sunt declarate in interiorul unui element.
O declaratie namespace are forma:
xmlns:prefix=”location”, unde “location” reprezinta adresa Schemei.
In afara de faptul ca tehnologiile XML reprezinta baza noii generatii WWW (Semantic Web), are numeroase avantaje si beneficii:
Iata cateva dintre ele:
XML este o industrie standard, deschisa, definita de catre consortiul W3C
XML separa continutul unui document XML de prezentarea acestuia
XML contine meta-data (sau “date despre date”)
In designul Semantic Web, XML furnizeaza stratul de baza in manipularea sintactica.
2.2.5.3 Sintaxa RDF/XML
Am vazut cum putem reprezenta sub forma de graf o afirmatie RDF. Acum vom vedeam cum vom scrie afirmatiile in sintaxa RDF/XML plecand de la reprezentarea cu grafuri.
“Un graf este o colectie de drumuri intre noduri unite de predicate (arce). In RDF/XML aceasta reprezentare se transforma intr-o secventa de elemente.
Nodul de inceput se transforma in radacina, urmatorul in copilul acesteia, s.a.m.d.” (W3C RDF syntax).
Daca consideram graful din figura 2.7, partea stanga corespunde urmatoarelor noduri si predicate:
Nod avand urmatorul URI http://www.w3.org/TR/rdf-syntax-grammar
Predicat etichetat cu urmatoarea referinta RDF http://example.org/terms/editor
Nod fara referinta RDF
Predicat etichetat cu urmatoarea referinta http://example.org/terms/homePage
Nod avand urmatorul URI http://purl.org/net/dajobe/
“In RDF/XML, secventa de 5 noduri si predicate din partea stanga, corespunde folosirii a 5 elemente XML de doua tipuri. In mod conventional aceste tipuri se numesc: elemente nod si elemente proprietate.
Figura 2.7 Elemente nod si elemente proprietati
Exemplul 1: RDF/XML (noduri si predicate)
<rdf:Description>
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description>
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description
In figura 2.7, graful contine noduri care sunt referinte URI, si altele care nu sunt. Acest lucru poate fi mentionat in sintaxa XML folosind atributul rdf:about ca in exemplul 2:
Exemplul 2: Elemente Nod ce contin referinte URI
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description
rdf:about="http://purl.org/net/dajobe/">
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description>
Daca scriem in RDF/XML si celelalte doua cai din figura 2.7 obtinem rezultatul din exemplul 3:
Exemplul 3: Descrierea completa a cailor grafului din figura 2.7
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:homePage>
<rdf:Description
rdf:about="http://purl.org/net/dajobe/">
</rdf:Description>
</ex:homePage>
</rdf:Description>
</ex:editor>
</rdf:Description>
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<ex:editor>
<rdf:Description>
<ex:fullName>Dave Beckett</ex:fullName>
</rdf:Description>
</ex:editor>
</rdf:Description>
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-syntax-grammar">
<dc:title>RDF/XML Syntax Specification
(Revised)</dc:title>
</rdf:Description>
Pentru a crea un document RDF/XML, serializarea grafului in sintaxa XML este continuta intr-un element rdf:RDF, care devine elementul de nivel cel mai inalt (radacina).
Este permisa o declaratie XML la inceputul documentului ce contine versiunea XML si codificarea folosita.
Reprezentarea completa a grafului din figura 2.7:
Exemplul 4: Descrierea completa in RDF/XML a grafului din Figura 2.7
<?xml version="1.0"?>
<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:ex="http://example.org/stuff/1.0/">
<rdf:Description rdf:about="http://www.w3.org/TR/rdf-
syntax-grammar" dc:title="RDF/XML Syntax Specification
(Revised)">
<ex:editor>
<rdf:Description ex:fullName="Dave Beckett">
<ex:homePage
rdf:resource="http://purl.org/net/dajobe/" />
</rdf:Description>
</ex:editor>
</rdf:Description>
</rdf:RDF>
2.2.6 RDF Schema- Vocabularul RDF
“RDF furnizeaza un mod de a exprima afirmatii simple despre resurse utilizand proprietati si valori. In RDF trebuie sa putem defini termeni pentru a descrie mai bine clasele de obiecte (trebuie sa avem un vocabular).
RDF nu furnizeaza metode pentru a defini clase si proprietati specifice unei aplicatii. In schimb aceste clase si proprietati pot fi definite folosind vocabularul de descriere al limbajului RDF numit RDF Schema.
RDF Schema permite a defini resurse ca fiind instante a uneia sau mai multor clase. De asemenea permite organizarea claselor in ierarhii.
“Resursele din RDF Schema au referinte URI ce incep cu prefixul http://www.w3.org/2000/01/rdf-schema#.[..]
Pentru ca un calculator sa inteleaga informatiile pe care le citeste, software-urile RDF trebuiesc scrise in asa fel incat sa poata procesa limbaje extinse ce contin atat vocabularul rdf cat si rdfs.” (W3C-RDF-primer)
A) Clase
O clasa in RDF Schema corespunde conceptului de Tip sau Categorie; se aseamana cu conceptul de clasa din programarea orientata pe obiecte (java).
Clasele RDF pot fi folosite pentru a reprezenta aproape orice categorie de lucruri: pagini Web, documente, oameni, baze de date sau concepte abstracte.
Clasele sunt descrise cu ajutorul resurselor RDF Schema: rdfs:Class si rdfs:Resource, si folosind proprietatile: rdf:type si rdfs:subClassOf.
In RDF Schema o clasa este orice resursa ce are o proprietate rdf:type, a carei valoare este rdfs:Class.
Exemplu:
Figure 2.8: Ierarhia Clasei Vehiculelor
Descriem aceasta ierarhie in RDF/XML:
Exemplul 5: Ierarhia Clasei Vehiculelor in RDF/XML
<?xml version="1.0"?>
<!DOCTYPE rdf:RDF [<!ENTITY xsd "http://www.w3.org/2001/XMLSchema#">]>
<rdf:RDF
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:rdfs="http://www.w3.org/2000/01/rdf-schema#"
xml:base="http://example.org/schemas/vehicles">
<rdf:Description rdf:ID="MotorVehicle">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
</rdf:Description>
<rdf:Description rdf:ID="PassengerVehicle">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>
<rdf:Description rdf:ID="Truck">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>
<rdf:Description rdf:ID="Van">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#MotorVehicle"/>
</rdf:Description>
<rdf:Description rdf:ID="MiniVan">
<rdf:type rdf:resource="http://www.w3.org/2000/01/rdf-schema#Class"/>
<rdfs:subClassOf rdf:resource="#Van"/>
<rdfs:subClassOf rdf:resource="#PassengerVehicle"/>
</rdf:Description>
</rdf:RDF>
B) Proprietati
Pe langa a descrie clase specifice pentru obiecte, putem sa descriem si proprietati care caracterizeaza aceste clase. In RDF Schema, proprietatile sunt descrise cu ajutorul clasei rdf:Property, si cu proprietatile: rdfs:domain, rdfs:range, si rdfs:subPropertyOf.
Toate proprietatile sunt descrise ca instante ale clasei rdf:Property.
Proprietatea rdf:range este folosita pentru a indica faptul ca valoarile unei anumite proprietati sunt instante ale unei clase.
Interpretarea declaratiilor RDF Schema
“RDF difera de cele mai multe limbaje de programare din mai multe puncte de vedere:
O diferenta importanta este aceea ca RDF nu descrie clase care au anumite proprietati, ci descrie proprietati care se aplica anumitor clase.
In RDF descrierea proprietatilor se face independent de definirea claselor, putand fi aplicate oricaror clase.
Afirmatiile RDF Schema sunt descriptive. Pot fi si normative (introduc restrictii), doar daca aplicatia care interpreteaza aceste afirmatii vrea sa le foloseasca in acest mod.
2.2.7 Dublin Core Metadata Initiative
Dublin Core este un set de "elemente" (proprietati) folosite in scopul descrierii documentelor (si deci pentru a inregistra metadata). Setul de elemente a fost creat in Martie 1995 in Dublin, Ohio si urmareste furnizarea unui set minimal de elemente descriptive care pot facilita descrierea si indexarea automata a documentelor de pe Web.
Setul Dublin Core a fost realizat pentru a fi folosit de "Webcrawlers".Un “webcrawler” este un program care traverseaza automat structura hypertextuala a Web-ului prin gasirea unui document, iar apoi gasirea recursiva a tuturor documentelor referite de pe acest document.
Elementele DC sunt definite in Setul de Elemente Dublin Core Metadata, Versiunea 1.1, si contin definitii pentru urmatoarele proprietati:
Title: Nume dat unei resurse
Creator: Entitatea responsabila pentru crearea continutului unei resurse
Subject: Topicul continutului unei resurse
Description: Explicatia continutului resursei.
Publisher: Entitatea responsabila cu publicarea resursei
Contributor: Entitate care a contribuit la crearea continutului resursei
Date: O data asociata cu un eveniment din viata resursei
Type: Natura continutului unei resurse
Format: Manifestarea fizica sau digitala a unei resurse
Identifier: O referinta unica intr-un context, pentru o resursa
Source: O referinta catre o resursa de la care deriva resursa despre care se vorbeste
Language: Limba in care este prezentat continutul resursei
Relation: O referinta catre o resursa inrudita
Coverage: Scopul continutului resursei
Rights: Informatii privind drepturile asupra resursei
RDF este indicat pentru a reprezenta elementele Dublin Core.
2.2.8 Rezumat RDF:
RDF foloseste un model simplu de date: exista lucruri care se numesc resurse si afirmatii care pot fi facute despre aceste resurse. O singura afirmatie leaga doua resurse. Afirmatiile sunt ca niste proprozitii simple de tipul: subiect-verb-obiect.
O colectie de date RDF nu are un nume standard; uneori se numeste magazie RDF, set de date RDF, baza de cunostinte sau baza de date. Pentru a identifica resursele, RDF foloseste URI.
Ca HTML, RDF/XML este un limbaj (model de date) procesabil de computere; folosind URI leaga anumite informatii pe Web. Spre deosebire de hipertextul conventional URI folosit de RDF poate referi orice lucru care poate fi identificat pe Web, inclusive lucrurile care nu pot fi descarcate de pe retea (precum persoana Eric Miller).
RDF nu impune ca orice resursa dintr-o afirmatie sa fie identificata printr-o referinta URI.
Resursele anonime se numesc noduri albe sau a-noduri (blank nodes sau b-nodes); acestea sunt resursele care nu au un URI.
RDF defineste trei tipuri de containere:
rdf:Bag
rdf:Seq
rdf:Alt
Pentru a inregistra informatia si a face schimb de date intre grafuri RDF, exista o sintaxa bazata pe XML, numita RDF/XML.
RDF nu furnizeaza metode pentru a defini clase si proprietati specifice unei aplicatii. In schimb aceste clase si proprietati pot fi definite folosind vocabularul de descriere al limbajului RDF numit RDF Schema.
RDF Schema permite definirea resurselor ca fiind instante a uneia sau mai multor clase. De asemenea permite organizarea claselor in ierarhii.
2.3 Topic Maps
Topic Maps este o tehnologie folosita pentru organizarea informatiei, inclusiv a meta-datei.
Topic Maps a evoluat din eforturile de a crea indecsi electronici. De aceea modelul TM este potrivit pentru aplicatiile care implica descoperirea si navigarea bazelor de date. Topic maps are un stil diferit de RDF de a modela informatia.
Modelul de baza al Topic Maps este de a lega concepte cu informatia despre aceste concepte, promovand colocatia si navigarea informatiilor (adica gasirea corecta a informatiilor si de asemenea informatiile inrudite).
Topic Maps se bazeaza pe ideea de concepte-orice despre care se poate vorbi .
2.3.1 Modelul Topic Maps
Topic Maps captureaza subiectele resurselor si relatiile dintre aceste subiecte in asa fel incat nu depinde de implementare.
Conceptele cheie folosite in Topic Maps sunt
topicele (topics)
asocierile (associations)
ocurentele (occurrences)
Topicele au trei tipuri de caracteristici:
nume
ocurente (occurrences)
roluri jucate ca membri ai unei asocieri.
Mai multe Topic Maps-uri pot fi combinate (merged) dupa cum doreste autorul sau utilizatorul acestora.
XTM furnizeaza o sintaxa si un model pentru a reprezenta structura informatiei continuta de resurse si a relatilor dintre acestea.
XTM este pentru Topic Maps ceea ce este RDF/XML pentru modelul RDF.
2.3.2 Obiective
Obiectivele XTM :
creat pentru a fi utilizat pe Internet
sa poata fi folosit de o varietate larga de aplicatii.
sa fie compatibil cu XML
sa fie usor de realizat programe care proceseaza documente XTM
sa aibe cat mai putine caracteristici optionale
documentele XTM trebuie sa fie usor intelese de oameni
sa aiba un design formal si concis.
Sa se realizeze usor un document XTM
2.3.3 Sintaxa XTM
Figura 2.8 Topic Maps
Cu topic maps putem crea un index pentru informatii, care rezida in afara informatiei, ca in figura 2.8.
Topic Map (norul de sus) descrie informatia din documente (dreptunghiurile) si din bazele de date (reprezentate prin cilindri), conectandu-se la ele prin intermediul URI-lor (liniile).
Cel mai des, Topic Maps este folosit pentru a crea site-uri.
Pot fi folosite si in scopul organizarii continutului in sistemele de management.
La baza oricarui Topic Maps se afla topicele (cercurile din figura 2.8), ce reprezinta obiectele despre care se vorbeste.
Asocierile reprezinta relatiile dintre topice. Acestea au o caracteristica noua: despre fiecare topic implicat intr-o asociere se spune ca joaca un rol definit de tipul sau.
Asocierile nu trebuiesc restrictionate la doua topicuri.
Un alt concept cheie important este reprezentat de ocurente (occurences), ce reprezinta informatia relevanta pentru un topic. Pentru o persoana, ocurentele pot fi: pagina web, adresa, CV-ul, etc.
Vom prezenta cateva topice repezentand piese ale lui William Shakespeare, in XTM:
<topic id="hamlet">
<instanceOf><topicRef xlink:href="#play"/></instanceOf>
<baseName>
<baseNameString>Hamlet, Prince of
Denmark</baseNameString>
</baseName>
<occurrence>
<instanceOf><topicRef xlink:href="#plain-text-
format"/></instanceOf>
<resourceRef
xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws2610.txt"/>
</occurrence>
</topic>
<topic id="tempest">
<instanceOf><topicRef xlink:href="#play"/></instanceOf>
<baseName>
<baseNameString>The Tempest</baseNameString>
</baseName>
<occurrence>
<instanceOf><topicRef xlink:href="#plain-text-
format"/></instanceOf>
<resourceRef
xlink:href="ftp://www.gutenberg.org/pub/gutenberg/etext97/1ws4110.txt"/>
</occurrence>
</topic>
Asocierea care reprezinta relatia dintre Shakespeare si piesa Hamlet este prezentata mai jos:
<association>
<instanceOf><topicRef xlink:href="#written-
by"/></instanceOf>
<member>
<roleSpec><topicRef xlink:href="#author"/></roleSpec>
<topicRef xlink:href="#shakespeare"/>
</member>
<member>
<roleSpec><topicRef xlink:href="#work"/></roleSpec>
<topicRef xlink:href="#hamlet"/>
</member>
</association>
Deoarece asocierile exprima relatii, acestea sunt mostenite bidirectional: Daca piesa “Hamlet” a fost scrisa de Shakespeare, automat se intelege ca Shakespeare a scris piesa “Hamlet”.
2.3.4 Concepte
Aceasta sectiune contine conceptele necesare pentru a intelege constructia Topic Maps in sintaxa XML ( XTM).
Un topic map retine subiectele despre care vorbeste resursa, si relatiile dintre acestea.
2.3.4.1 Topice
a)Topic
Un topic este o resursa ce actioneaza ca un proxy pentru un subiect. Intre un topic si subiectul sau apare relatia de reificare.
Fiecare topic este o instanta a uneia sau mai multor clase de topice (cunoscute ca tipuri de topice) care pot fi, sau nu, indicate explicit.
Tipul topicului este determinat de “subiectul publicat” (Published Subject).
b) Tipuri de Topice
Topicele pot fi categorizate in functie de tipul acestora.
De exemplu, daca am considera topic maps-ul Opera (vezi [Omnigator]), atunci Puccini este un topic de tipul “compositor”, Tosca si Madame Butterfly sunt topice de tipul “opera”, Roma si Lucca sunt topice de tipul “oras” , Itala e un topic de tipul ‘tara”, etc.
Cu alte cuvinte, relatia dintre un topic si tipul acestuia este o relatie de tipul clasa-instanta.
Tipurile de topice trebuiesc definite si ele ca topice. Trebuie declarat in mod explicit faptul ca “opera”, “compositor“, “oras”, etc. sunt topice, daca vrem sa le folosim ca tipuri.
Figure 2.9.1 Tipuri de Topice in Topic Map-ul Opera
c) Subiectul
Subiectul reprezinta lucrul despre care se vorbeste. Subiectele reprezinta principiul de organizare a topicelor. Intr-un topic map fiecare subiect este reprezentat de un singur topic. Unele subiecte nu pot fi adresate, cum ar fi: William Shakespeare, piesa Hamlet, personajul Hamlet, conceptul de razbunare, etc.
Identitatea subiectelor neadresabile se poate stabili indirect prin intermediul resurselor care functioneaza ca indicatoare de subiect. Resursele considerate subiecte se numesc subiecte adresabile. Un exemplu de subiect adresabil ar putea fi specificarea XTM in format HTML.
d) Reificarea
Actul de creare a unui topic se numeste reificare. Cand un lucru este reificat, acesta devine subiectul topicului astfel creat.
Din moment ce orice lucru poate fi un subiect, reificarea poate fi aplicata asupra obiectelor ce fac parte din topic map, cum ar fi: asocierile, numele, ocurentele.
e) Identitatea Subiectului (Subject Identity)
Identitatea Subiectului reprezinta modul prin care putem stabili care subiect este reificat de catre un anumit topic. Cand doua topice au aceeasi identitate a subiectului, sunt considerate ca topice care trateaza acelasi subiect si trebuiesc combinate (merged).
Identitatea subiectului poate fi stabilita intr-unul din urmatoarele moduri :
specificand un identificator public (un PIS), care contine o descriere a subiectului.
afirmand ca o anumita resursa (pagina web) indica subiectul.
afirmand ca o anumita resursa este subiectul.
In toate cele trei cazuri este nevoie de ratiunea umana pentru a determina care este subiectul unui topic.
f) Identificator de Subiect
Un indicator de subiect este o resursa care poate furniza intr-un mod clar identitatea unui subiect. Deoarece este o resursa, un indicator de subiect are o adresa (de obicei un URI) care poate fi folosit ca identificator de subiect.
Un identificator de subiect publicat (published subject indicator PSI) este un identificator de subiect care este publicat si mentinut in scopul de a facilita interschimbul si combinarea topicelor.
g) Caracteristicile unui topic
Orice lucru care poate fi spus despre un topic dintr-un topic map, este cunoscut sub numele de caracteristica a acelui topic.
Caracteristicile unui topic sunt:
numele
ocurentele
rolurile jucate de un topic ca membru al unei asocieri
Atribuirea caracteristicilor este valida intr-un anumit context (scope).
h)Contextul (Scope)
Contextul stabileste circumstantele in care un nume sau o ocurenta este atribuita unui topic, si situatiile in care topicele sunt corelate prin intermediul asocierilor.
Contextul este definit in functie de teme, si o tema este definita ca membru a unui set de topice utilizate pentru a specifica un context. Astfel numele “tosca” poate fi atribuit unor topice diferite in contexte definite de temele: “opera” si “personaj”.
Figura 2.9.1 Contextul
i) Numele
Un topic poate avea zero sau mai multe nume, fiecare fiind considerat valid intr-un anumit context.
Fiecare nume poate exista sub mai multe forme. Un nume are o singura forma de baza, cunoscuta sub numele de “base name”.
Numele pot exista sub mai multe forme, cum ar fi: nume formale, nume simbolice, porecle, nume pentru logare (user).
Unui topic i se pot asocia mai multe “base name” pentru a fi folosite in contexte diferite.
Figura 2.9.2 Nume
j) Parametri
Parametri reprezinta informatia sub forma unui set de topice care exprima contextul adecvat pentru procesarea unui nume
Selectand un topic anume, aplicatia poate alege sa examineze parametrii pentru a selecta forma cea mai potrivita pentru un nume
2.3.4.2 Ocurente
O ocurenta este informatia relevanta petru un subiect. Ocurentele constituie una dintre cele trei tipuri de caracteristici atribuite unui topic si astfel guvernate de un context.
Fiecare ocurenta individuala este o instanta a unei clase de ocurente (tip de ocurenta).
Pentru a putea fi exprimate in sintaxa XTM, ocurentele trebuie sa fie resurse care pot fi adresabile printr-un URI sau sa fie de tipul “resource data”
2.3.4.3 Asocieri
O asociere este o relatie dintre topice, fiecare jucand rolul de membru al asocierii. Asocierile descriu relatii: Daca A se afla in legatura cu B, atunci si B se afla in legatura cu A
O asociere subliniaza legatura dintre doua sau mai multe topice.
Exemple:
“Tosca a fost scrisa de Puccini”
“Actiunea operei Tosca are loc in Roma”
“Puccini s-a nascut in Lucca”
“Lucca se afla in Italia”
“Puccini a fost influentat de Verdi”
Figura 2.9.3 Asocieri
2.3.5 Concluzii
Topic Maps este o tehnologie folosita pentru organizarea informatiei, inclusiv a meta-datei.
Topic Maps a evoluat din eforturile de a crea indecsi electronici. De aceea modelul TM este potrivit pentru aplicatiile care implica descoperirea si navigarea bazelor de date. Topic maps are un stil diferit de RDF pentru a modela informatia.
Topic Maps se bazeaza pe ideea de concepte-orice despre care se poate vorbi .
Modelul de baza este de a lega concepte cu informatia cunoscuta despre aceste concepte, promovand colocatia si navigarea informatiilor.
Topic Maps captureaza subiectele resurselor si relatiile dintre aceste subiecte in asa fel incat nu depinde de implementare.
Conceptele cheie folosite in Topic Maps sunt
topicele (topics)
asocierile (associations)
ocurentele (occurrences)
Topicele au trei tipuri de caracteristici:
nume
ocurente (occurrences)
roluri jucate ca membri ai unei asocieri.
Doua topice sunt legate intre ele prin asocieri. Topicele pot contine, sau pot indica informatia relevanta folosind ocurente.
Identitatea Subiectului (Subject identity) este un aspect cheie pentru Topic Maps. Subiectul unui topic map este reprezentat de conceptul la care se refera.
Identitatea acestuia poate fi stabilita intr-unul din urmatoarele moduri :
specificand un identificator public (un PIS), care contine o descriere a subiectului.
afirmand ca o anumita resursa (pagina web) indica subiectul.
afirmand ca o anumita resursa este subiectul.
In toate cele trei cazuri este nevoie de ratiunea umana pentru a determina care este subiectul unui topic.
Cu toate ca scopul initial pentru TM era de a se comporta precum un index intr-o masa de informatie, acesta poate stoca si organiza date de toate tipurile.
Topic Maps este potrivit pentru a face parte din Semantic Web, deoarece poate referi orice subiect, oriunde pe net, poate combina informatii si exista un standar de nivel international pentru descrierea acestui model. (Adaptare dupa (TAO, Pepper))
Capitolul 3: Studiu de caz
3.1 Corpus-ul
Scopul acestei lucrari este de a compara si evalua RDF si Topic Maps, care au fost prezentate in Capitolul 2.
In acest scop a fost ales un scenariu particular (informatie turistica), si au fost folosite unelte specifice pentru Semantic Web.
Comparatia a fost facuta pe un anumit corpus, dupa adnotarea acestuia cu RDF si Topic Maps.
Este pentru prima oara cand modelele sunt comparate la nivel de aplicatie, nu doar formal.
Corpusul folosit are 7000 cuvinte, este un document nestructurat preluat de pe pagina www.turism.ro . Am adnotat numai informatia geografica (tipul de informatie de care un turist ar fi interesat).
Adnotarea documentelor folosind RDF sau Topic Maps ar duce la imbunatatirea rezultatelor motoarelor de cautare.
Protégé -3.0
Am ales sa modelam corpusul utilizand Protégé deoarece are o interfata prietenoasa si pentru ca putem modela cu ajutorul acestuia documente RDF si TM.
Protégé-3.0 poate fi descarcat de la adresa http://protege.stanford.edu/ ;este un editor de ontologii gratis, si open source.
Cele mai importante caracteristici ale acestuia sunt:
Este bazat pe Java
Este extensibil
Furnizeaza o fundatie pentru aplicatiile bazate pe cunostinte
Se poate lucra simultan cu clasele si instantele acestora
Elementele principale ale modelului Protégé sunt:
Clasele, care corespund conceptelor din domeniu;
Instantele claselor;
Sloturile care reprezinta proprietatile claselor si ale instantelor
Figura 3.1. Modelul Protégé
Clasele sunt organizate in ierarhii. Clasele pot fi instante ale altor clase.
Sloturile pot fi atasate claselor sau instantelor intr-unul din cele doua moduri:
ca template slots
sau ca own slots
Pentru a modela corpusul cu Topic Maps am folosit de asemenea Protégé -3.0, dar a trebuit sa includem un alt plugin: “TMTab” pentru a realiza acest lucru.
TMTab poate fi descarcat de la adresa: http://www.techquila.com/tmtab-status.html
De fiecare data cand se realizeaza un proiect folosind Protégé putem alege formatul in care sa scriem proiectul:
Default Files (pont and pins) – sub acest format am realizat adnotarea corpusului cu Topic Maps
RDF Files – sub acest format am realizat adnotarea corpusului cu RDF
Figura 3.2 Format Protégé
Indiferent de format, informatia specifica interfetei Protégé-3.0 este salvata cu extensia pprj (Protégé project).
Urmatoarea figura arata instanta “Bucharest” a clasei “City” din proiectul RDF :
Figura 3.3 Clasele si Instantele in Protégé
Protégé a fost realizat in scopul crearii ontologiilor (documentelor RDF, Topic Maps, etc), dar cu ajutorul lui putem realiza grafuri care sa indice relatiile dintre nodurile ontologiei, asa cum este indicat in figura urmatoare:
Figura 3.4 Graf RDF
3.3 Omnigator Eight
Celalalt instrument pe care l-am utilizat este Omnigator Eight, si este un instrument folosit pentru navigare. Poate fi descarcat de la adresa: http://www.ontopia.net/download/freedownload.html
Am ales sa folosesc Omnigator Eight pentru a naviga prin documentele .xtm si .rdf deoarece:
permite navigarea documentelor RDF cat si a celor Topic Maps
putem folosi un web browser standard pentru navigarea acestor documente
a fost realizat ca un instrument pentru invatarea conceptelor de baza ale Topic Maps
are o interfata grafica prietenoasa
exista o versiune free pentru acest instrument
In urmatoarele randuri vom prezenta descrierea arhitecturii instrumentului Omnigator Eight, gasita la adresa: http://www.ontopia.net/omnigator/docs/navigator/userguide.html
Omnigator foloseste o arhitectura simpla client-server bazata pe un protocol standard http.
Figura 3.5 Arhitectura Omnigator-ului
De partea serverului se afla o aplicatie J2EE construita folosind Ontopia Topic Map Engine si Navigator Framework, care ruleaza pe serverul Tomcat. Aceasta aplicatie citeste si scrie Topic Maps-uri si genereaza pagini HTML.
Pe partea client, un browser standard primeste aceste pagini HTML, si afiseaza portiuni din topic map.
Dupa descarcarea si instalarea instrumentului Omnigator Eight, pentru a naviga printr-un document XTM sau RDF, trebuie sa copiem documentul respectiv in directorul unde am instalat Omnigator Eight, in cazul de fata, in directorul:
file:/home/ivy/Desktop/licenta/TM1/jakarta-tomcat/webapps/omnigator/WEB-INF/topicmaps
Daca serverul Tomcat functioneaza, ne putem conecta la adresa
http://localhost:8080/omnigator/ pentru a naviga documentele.
La aceasta adresa se afla urmatoarea pagina:
Documentele RDF si TM incarcate in Omnigator
Figura 3.6 Prima pagina a Omnigator-ului
Daca ati adaugat documentele la adresa corecta, dupa incarcarea acestora, pot fi vizualizate pe prima pagina ca in figura de mai sus, unde sunt afisate documentele: Romania2.rdf si Romania3TM_lucru.xtm
Pentru a naviga intr-un document (dupa incarcarea in prealabil pe prima pagina a Omnigatorului), trebuie sa dam click pe numele acestuia, sa selectam un topic, de exemplu “Bucuresti”, si sa dam click pe butonul vizigate.
Acestea sunt conexiunile pe care le are topicul “Bucharest” in documentul RDF, navigat cu Omnigator Eight:
Figura 3.7 Navigarea topicului Bucharest -1
Fiecare nod are legaturi cu alte noduri, in functie de cum a fost realizat documentul RDF sau Topic Map
Avem posibilitatea de a afisa documentele in moduri diferite. De exemplu acelasi nod “Bucharest” poate fi afisat ca in Figura 3.7, dar si ca in Figura 3.8, expandand, minimizand sau modificand proprietatea “sticky” a unui nod:
Figura 3.8 Navigarea topicului Bucharest -2
Capitolul 4: Modelarea cu RDF
4.1 Adnotarea corpusului cu RDF
Pentru adnotarea corpusului cu RDF am urmat pasii:
extragerea informatiei pe care am considerat-o imporanta;
transformarea corpusului intr-un document structurat (corpusul a fost impartit in clase si proprietati);
crearea ierarhiilor.
Mentionam ca primul pas este identic atat pentru modelarea cu RDF cat si pentru cea cu Topic Maps.
In cele ce urmeaza vom prezenta procesul de adnotare pe una din paginile corpusului: http://www.turism.ro/english/moldavia.php .
4.1.1 Extragerea informatiei:
„Bucovina – the north-eastern province of Romania[..]Moldavia has an extensive countryside of forests and hills, with many lesser known delights to discover, especially in the region of Targu Neamt.[..]
Iasi and Suceava
Iasi is the home of Romania’s oldest University and a centre of intellectual life. Many well-known Romanian writers’ houses are preserved as memorials. The best known monument of the city is the Trei Ierarhi Church, dating from 1639. In Suceava,[..] it is worth going up to the ruins of Stephen's princely citadel on the heights near the city. Remember to ask for specialities of Moldavian cuisine in the restaurants. Moldavian cooking and local wines are widely appreciated.
Targu Neamt
This town is the access point for a remarkable group of monasteries and fortresses that are definitely worth a detour.
The 18th century convent of Agapia gleams as white as if it stood on a Greek Island. The Monastery in Targu Neamt is the oldest in Moldavia, while the Neamt fortress used to be a key to the region's defence. [..]
Humor
Humor, founded in 1530, is quite small. Its paintings include illustration of a poem on the "The Siege of Constantinople", which shows the feelings of the Romanians towards the Turks. The aim was to maintain the Christian faith among Romanians. On other walls are the "Return of the Prodigal Son" and the Devil amusingly pictured as a greedy woman.[..]
Voronet
This "Sixtine Chapel of the East" was built by Stephen the Great in 1488 and the vivid colours of its frescoes added later. [..]
Sucevita [..]
Thousands of pictures decorate the walls of the church. In fact they outnumber the pictures at any of the other monasteries, yet the western wall is blank. Legend says it that the artist fell off the wall scaffolding and was killed, so it remained undecorated. When you go there, look for the complex "Jesse's Tree" on the southern wall.
Moldovita
Striking shades of red, blue, yellow and brown characterize the monumental scene of the "Siege of Constantinopole" on the walls of the Moldovita church. Inside, 16th century furniture survives, including Prince Petru Rares' chair, as large as a throne. The Prince built Moldovita and his statue stands outside.
Arbore
Quite small, and without the high cupola that distinguishes most monastery churches, Arbore is predominantly decorated in shades of green. Look for the scene from "Genesis" along the western wall, since it is particularly lively and graceful. “
Transformarea corpusului intr-un document structurat.
Bucovina is a region of Romania.
Moldavia is a region of Romania.
Targu Neamt is a city from Moldavia
Iasi is a city from Moldavia
Suceava is a city from Bucovina
Iasi_description:” Iasi is the home of Romania’s oldest University and a centre of intellectual life.”
Iasi_attraction: Trei Ierarhi monastery
Trei Ierarhi is monastery from Iasi, dating from 1639.
Agapia is a monastery in Targu Neamt.
Agapia_description: “It is the oldest monastery in Moldavia”
Humor is a monastery in Suceava, founded in 1530.
Humor_description: ” Its paintings include illustration of a poem on the "Siege of Constantinople".On other walls are the "Return of the prodigal son" and the devil amusingly pictured as a greedy woman”
Voronet is a monastery from Suceava.
Voronet_description: ”This "Sixtine Chapel of the East" was built by Stephen the Great. It is known for its unique blue colour.”
Sucevita is a monastery from Suceava.
Sucevita_description: ” Thousands of pictures decorate the walls of the church. In fact they outnumber the pictures at any of the other monasteries, yet the western wall is blank. Legend says it that the artist fell off the wall scaffolding and was killed, so it remained undecorated. When you go there, look for the complex "Jesse's Tree" on the southern wall.”
Moldovita is a monastery from Suceava
Moldovita_description: “Was built by Prince Pertu Rares. It is known for its striking shades of red, blue,yellow and brown.”
Arbore is a monastery from Suceava.
Arbore_description: ” Is quite small, is predominantly decorated with shades of green. It is known for the lively and graceful scene from "Genesis"”
Impartirea corpusului in clase si proprietati.
Am creat urmatoarele clase si proprietatile acestora, pentru aceasta pagina a corpusului:
Regions
Name: value type= string, cardinality= single
City: value type= instance, allowed classes=Cities, cardinality= multiple
County: value type= instance, allowed classes=Counties, cardinality= multiple
Monastery: value type= instance, allowed classes=Monasteries, cardinality= multiple
Counties
Name: value type= string, cardinality= single
Region: value type= instance, allowed classes=Regions, cardinality= single
City: value type= instance, allowed classes=Cities, cardinality= multiple
Cities
Name: value type= string, cardinality= single
Region: value type= instance, allowed classes=Regions, cardinality= single
County: value type= instance, allowed classes=Counties, cardinality= single
Monastery: value type= instance, allowed classes=Monasteries, cardinality= multiple
Description: value type= string, cardinality= single
Attractions: instance, allowed classes=Touristic_Attractions, cardinality= multiple
Monasteries
Name: value type= string, cardinality= single
City: value type= instance, allowed classes=Cities, cardinality= single
County: value type= instance, allowed classes=Counties, cardinality= single
Region: value type= instance, allowed classes=Regions, cardinality= single
Description: value type= string, cardinality= single
Foundation_year: value type= integer, cardinality= required single
Is_Colored: value type= boolean, cardinality= required single
Touristic_attractions
Name: value type= string, cardinality= single
City: value type= instance, allowed classes=Cities, cardinality= multiple
Crearea ierarhiilor
Clasa “Cities” este subclasa a clasei “Counties”.
Clasa “Counties” este subclasa a clasei “Regions”.
Clasa “Monasteries” este subclasa a clasei “THING”.
Clasa “Regions” este subclasa a clasei “THING”.
Clasa “Touristic_Attractions” este subclasa a clasei “THING”.
Pentru o modelare mai buna am adaugat informatie cand am considerat ca este insuficienta. De exemplu am gasit urmatoarea informatie: “The Agapia monastery is situated in Targu Neamt and is the oldest in Moldavia.” Aceasta informatie nu este suficienta daca vrem sa organizam o ierarhie a claselor. De aceea am adaugat judetul (county) “Neamt”.
Acum avem clasa “City” este o subclasa a clasei “County” care este o subclasa a clasei “Region”, unde:
“Targu Neamt” este o instanta a clasei “City”
“ Neamt” este o instanta a clasei “County” si
“Moldavia” este o instanta a clasei “Region”.
Modelarea RDF utilizand Protégé-3.0 :
Figura 4.1 Modelarea claselor cu RDF
4.3 Codul RDF si RDFS.
In cele ce urmeaza vom prezenta codul pentru pagina din corpus ce poate fi consultata la adresa: http://www.turism.ro/english/moldavia.php.
Mentionam ca nu toate paginile au aceeasi structura, asa ca am creat noi clase si proprietati pentru fiecare pagina a corpusului.
Codul RDF:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY kb 'http://protege.stanford.edu/kb#'>
<!ENTITY rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
]>
<rdf:RDFxmlns:rdf="&rdf;"xmlns:kb="&kb;" xmlns:rdfs="&rdfs;">
<!–This is the code for instance “Iasi” of class city–>
<kb:Cities rdf:about="&kb;Romania2_Instance_11"
kb:name="iasi"
rdfs:label="iasi">
<kb:description>Is the home of Romania's oldest University and a center of intellectula life.Many well-known writers' houses are preserved as memorials.</kb:description>
<kb:regions rdf:resource="&kb;Romania2_Instance_3"/>
<kb:county rdf:resource="&kb;Romania2_Instance_31"/>
<kb:attractions rdf:resource="&kb;Romania2_Instance_40001"/>
<kb:attractions rdf:resource="&kb;Romania2_Instance_50003"/>
<kb:attractions rdf:resource="&kb;Romania2_Instance_50004"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_58"/>
</kb:Cities>
<!–this is the code for instance “Targu Neamt” of class city–>
<kb:Cities rdf:about="&kb;Romania2_Instance_12"
kb:name="targu_neamt"
rdfs:label="targu_neamt">
<kb:county rdf:resource="&kb;Romania2_Instance_24"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_3"/>
<kb:attractions rdf:resource="&kb;Romania2_Instance_50003"/>
<kb:attractions rdf:resource="&kb;Romania2_Instance_50004"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_52"/>
</kb:Cities>
<!–This is the code for instance “Suceava” of class city–>
<kb:Cities rdf:about="&kb;Romania2_Instance_14"
kb:name="suceava"
rdfs:label="suceava">
<kb:description>It has direct airlines and rail links with Bucharest, it is worth going up to the ruins of Stephen's princely citadel on the heights near the city.</kb:description>
<kb:county rdf:resource="&kb;Romania2_Instance_38"/>
<kb:attractions rdf:resource="&kb;Romania2_Instance_40002"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_5"/>
<kb:attractions rdf:resource="&kb;Romania2_Instance_50004"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_53"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_55"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_56"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_57"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_59"/>
</kb:Cities>
<!–This is the code for instance “Neamt” of class county–>
<kb:Counties rdf:about="&kb;Romania2_Instance_24"
kb:name="neamt"
rdfs:label="neamt">
<kb:city rdf:resource="&kb;Romania2_Instance_12"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_3"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_52"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_54"/>
<kb:city rdf:resource="&kb;Romania2_Instance_62"/>
</kb:Counties>
<!–This is the code for instance “Moldova” of class regions–>
<kb:Regions rdf:about="&kb;Romania2_Instance_3"
kb:name="moldova"
rdfs:label="moldova">
<kb:city rdf:resource="&kb;Romania2_Instance_11"/>
<kb:city rdf:resource="&kb;Romania2_Instance_12"/>
<kb:county rdf:resource="&kb;Romania2_Instance_24"/>
<kb:county rdf:resource="&kb;Romania2_Instance_31"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_54"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_58"/>
<kb:city rdf:resource="&kb;Romania2_Instance_62"/>
</kb:Regions>
<kb:Counties rdf:about="&kb;Romania2_Instance_31"
kb:name="iasi"
rdfs:label="iasi">
<kb:city rdf:resource="&kb;Romania2_Instance_11"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_3"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_58"/>
</kb:Counties>
<!–This is the code for instance “Suceava” of class county–>
<kb:Counties rdf:about="&kb;Romania2_Instance_38"
kb:name="suceava"
rdfs:label="suceava">
<kb:city rdf:resource="&kb;Romania2_Instance_14"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_5"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_53"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_55"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_56"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_57"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_59"/>
</kb:Counties>
<!–This is the code for instance “Trei Ierarhi” of class Touristic_Attractions–>
<kb:Touristic_Attractions rdf:about="&kb;Romania2_Instance_40001"
kb:name="Trei Ierarhi"
rdfs:label="Trei Ierarhi">
<kb:city rdf:resource="&kb;Romania2_Instance_11"/>
</kb:Touristic_Attractions>
<kb:Touristic_Attractions rdf:about="&kb;Romania2_Instance_40002"
kb:name="The ruins of king Stephen's citadel"
rdfs:label="The ruins of king Stephen's citadel">
<kb:city rdf:resource="&kb;Romania2_Instance_14"/>
</kb:Touristic_Attractions>
<!–This is the code for instance “Bucovina” of class regions–>
<kb:Regions rdf:about="&kb;Romania2_Instance_5"
kb:name="bucovina"
rdfs:label="bucovina">
<kb:city rdf:resource="&kb;Romania2_Instance_14"/>
<kb:county rdf:resource="&kb;Romania2_Instance_38"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_53"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_55"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_56"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_57"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_59"/>
</kb:Regions>
<!–End of code for instance “Bucovina” of class regions–>
<!–The following is the code for the rest of the instances of the project we used as an example –>
<kb:Touristic_Attractions rdf:about="&kb;Romania2_Instance_50003"
kb:name="Local cooking and wines"
rdfs:label="Local cooking and wines">
<kb:city rdf:resource="&kb;Romania2_Instance_11"/>
<kb:city rdf:resource="&kb;Romania2_Instance_12"/>
<kb:city rdf:resource="&kb;Romania2_Instance_62"/>
</kb:Touristic_Attractions>
<kb:Touristic_Attractions rdf:about="&kb;Romania2_Instance_50004"
kb:name="The monasteries"
rdfs:label="The monasteries">
<kb:city rdf:resource="&kb;Romania2_Instance_11"/>
<kb:city rdf:resource="&kb;Romania2_Instance_12"/>
<kb:city rdf:resource="&kb;Romania2_Instance_14"/>
<kb:city rdf:resource="&kb;Romania2_Instance_62"/>
</kb:Touristic_Attractions>
<kb:Monasteries rdf:about="&kb;Romania2_Instance_52"
kb:description="Is the oldest monastery in Moldavia"
kb:foundation_year="1644"
kb:name="agapia"
rdfs:label="agapia">
<kb:city rdf:resource="&kb;Romania2_Instance_12"/>
<kb:county rdf:resource="&kb;Romania2_Instance_24"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_3"/>
</kb:Monasteries>
<kb:Monasteries rdf:about="&kb;Romania2_Instance_53"
kb:foundation_year="1503"
kb:is_colored="true"
kb:name="arbore"
rdfs:label="arbore">
<kb:description>Is quite small, is predominantly decorated withshades of green.It is known for the lively and graceful scene from "Genesis"</kb:description>
<kb:city rdf:resource="&kb;Romania2_Instance_14"/>
<kb:county rdf:resource="&kb;Romania2_Instance_38"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_5"/>
</kb:Monasteries>
<kb:Monasteries rdf:about="&kb;Romania2_Instance_54"
kb:description="It is also a mountain and a ski resort"
kb:foundation_year="1835"
kb:name="durau"
rdfs:label="durau">
<kb:county rdf:resource="&kb;Romania2_Instance_24"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_3"/>
<kb:city rdf:resource="&kb;Romania2_Instance_62"/>
</kb:Monasteries>
<kb:Monasteries rdf:about="&kb;Romania2_Instance_55"
kb:foundation_year="1530"
kb:is_colored="true"
kb:name="humor"
rdfs:label="humor">
<kb:description>Its paintings inculde illustration of a poem on the "Siege of Constantinople".On other walls are the "Return of the prodigal son" and the devil amusingly pictured as a greedy woman</kb:description>
<kb:city rdf:resource="&kb;Romania2_Instance_14"/>
<kb:county rdf:resource="&kb;Romania2_Instance_38"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_5"/>
</kb:Monasteries>
<kb:Monasteries rdf:about="&kb;Romania2_Instance_56"
kb:foundation_year="1532"
kb:is_colored="true"
kb:name="moldovita"
rdfs:label="moldovita">
<kb:description>Was built by Prince Pertu Rares.It is known for its sriking shades of red, blue,yellow and brown.</kb:description>
<kb:city rdf:resource="&kb;Romania2_Instance_14"/>
<kb:county rdf:resource="&kb;Romania2_Instance_38"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_5"/>
</kb:Monasteries>
<kb:Monasteries rdf:about="&kb;Romania2_Instance_57"
kb:foundation_year="1600"
kb:is_colored="true"
kb:name="sucevita"
rdfs:label="sucevita">
<kb:description xml:space='preserve'><![CDATA[Thousands of pictures decorate the walls of the church. In fact they outnumber the pictures at any of the other monasteries, yet the western wall is blank. Legend says it that the artist fell off the wall scaffolding and was killed, so it remained undecorated. When you go there, look for the complex "Jesse's Tree" on the southern wall.]]></kb:description>
<kb:city rdf:resource="&kb;Romania2_Instance_14"/>
<kb:county rdf:resource="&kb;Romania2_Instance_38"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_5"/>
</kb:Monasteries>
<kb:Monasteries rdf:about="&kb;Romania2_Instance_58"
kb:foundation_year="1639"
kb:name="trei_ierarhi"
rdfs:label="trei_ierarhi">
<kb:description>Many well-known Romanian writers' houses are preserved as memorials. The best known monument of the city is the Trei Ierarhi Church.</kb:description>
<kb:city rdf:resource="&kb;Romania2_Instance_11"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_3"/>
<kb:county rdf:resource="&kb;Romania2_Instance_31"/>
</kb:Monasteries>
<kb:Monasteries rdf:about="&kb;Romania2_Instance_59"
kb:foundation_year="1488"
kb:is_colored="true"
kb:name="voronet"
rdfs:label="voronet">
<kb:description>This "Sixtine Chapel of the East" was built by Stephen the Great.It is known for its unique blue color.</kb:description>
<kb:city rdf:resource="&kb;Romania2_Instance_14"/>
<kb:county rdf:resource="&kb;Romania2_Instance_38"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_5"/>
</kb:Monasteries>
<kb:Cities rdf:about="&kb;Romania2_Instance_62"
kb:name="piatra_neamt"
rdfs:label="piatra_neamt">
<kb:description>It lies in the valley of the Bistrita River and is surrounded by mountains. It is first documented in the 15th century as Piatra lui Craciun, or Camena.</kb:description>
<kb:county rdf:resource="&kb;Romania2_Instance_24"/>
<kb:regions rdf:resource="&kb;Romania2_Instance_3"/>
<kb:attractions rdf:resource="&kb;Romania2_Instance_50003"/>
<kb:attractions rdf:resource="&kb;Romania2_Instance_50004"/>
<kb:monastery rdf:resource="&kb;Romania2_Instance_54"/>
</kb:Cities>
</rdf:RDF>
RDFS code:
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rdf:RDF [
<!ENTITY rdf 'http://www.w3.org/1999/02/22-rdf-syntax-ns#'>
<!ENTITY kb 'http://protege.stanford.edu/kb#'>
<!ENTITY rdfs 'http://www.w3.org/2000/01/rdf-schema#'>
]>
<rdf:RDF xmlns:rdf="&rdf;"
xmlns:kb="&kb;"
xmlns:rdfs="&rdfs;">
<!–The next three lines represents the subclass-of hierarchy: class city is subclass-of class county–>
<rdfs:Class rdf:about="&kb;Cities"
rdfs:label="Cities">
<rdfs:subClassOf rdf:resource="&kb;Counties"/>
</rdfs:Class>
<rdfs:Class rdf:about="&kb;Counties"
rdfs:label="Counties">
<rdfs:subClassOf rdf:resource="&kb;Regions"/>
</rdfs:Class>
<rdfs:Class rdf:about="&kb;Monasteries"
rdfs:label="Monasteries">
<rdfs:subClassOf rdf:resource="&kb;Regions"/>
</rdfs:Class>
<rdfs:Class rdf:about="&kb;Regions"
rdfs:label="Regions">
<rdfs:subClassOf rdf:resource="&rdfs;Resource"/>
</rdfs:Class>
<rdfs:Class rdf:about="&kb;Touristic_Attractions"
rdfs:label="Touristic_Attractions">
<rdfs:subClassOf rdf:resource="&rdfs;Resource"/>
</rdfs:Class>
<rdf:Property rdf:about="&kb;attractions"
rdfs:label="attractions">
<rdfs:domain rdf:resource="&kb;Cities"/>
<rdfs:range rdf:resource="&kb;Touristic_Attractions"/>
</rdf:Property>
<!–The following represents a property “city” which is a instance of class “cities” and can be found in class counties, regions, and touristic_attractions–>
<rdf:Property rdf:about="&kb;city"
rdfs:label="city">
<rdfs:range rdf:resource="&kb;Cities"/>
<rdfs:domain rdf:resource="&kb;Counties"/>
<rdfs:domain rdf:resource="&kb;Regions"/>
<rdfs:domain rdf:resource="&kb;Touristic_Attractions"/>
</rdf:Property>
<rdf:Property rdf:about="&kb;county"
rdfs:label="county">
<rdfs:range rdf:resource="&kb;Counties"/>
<rdfs:domain rdf:resource="&kb;Regions"/>
</rdf:Property>
<rdf:Property rdf:about="&kb;description"
rdfs:label="description">
<rdfs:domain rdf:resource="&kb;Cities"/>
<rdfs:domain rdf:resource="&kb;Monasteries"/>
<rdfs:range rdf:resource="&rdfs;Literal"/>
</rdf:Property>
<rdf:Property rdf:about="&kb;foundation_year"
rdfs:label="foundation_year">
<rdfs:domain rdf:resource="&kb;Monasteries"/>
<rdfs:range rdf:resource="&rdfs;Literal"/>
</rdf:Property>
<rdf:Property rdf:about="&kb;is_colored"
rdfs:label="is_colored">
<rdfs:domain rdf:resource="&kb;Monasteries"/>
<rdfs:range rdf:resource="&rdfs;Literal"/>
</rdf:Property>
<rdf:Property rdf:about="&kb;monastery"
rdfs:label="monastery">
<rdfs:domain rdf:resource="&kb;Cities"/>
<rdfs:range rdf:resource="&kb;Monasteries"/>
<rdfs:domain rdf:resource="&kb;Regions"/>
</rdf:Property>
<rdf:Property rdf:about="&kb;name"
rdfs:label="name">
<rdfs:domain rdf:resource="&kb;Counties"/>
<rdfs:domain rdf:resource="&kb;Monasteries"/>
<rdfs:domain rdf:resource="&kb;Regions"/>
<rdfs:domain rdf:resource="&kb;Touristic_Attractions"/>
<rdfs:range rdf:resource="&rdfs;Literal"/>
</rdf:Property>
<rdf:Property rdf:about="&kb;regions"
rdfs:label="regions">
<rdfs:domain rdf:resource="&kb;Counties"/>
<rdfs:domain rdf:resource="&kb;Monasteries"/>
<rdfs:range rdf:resource="&kb;Regions"/>
</rdf:Property>
</rdf:RDF>
Pentru a crea ID-uri unice pentru resursele sale, Protégé genereaza URIs in modul urmator:
Cand am creat instanta “Agapia” a clasei “Monastery”, Protégé a creat automat “Romania2_Instance_12” ca fiind un URI, unde “Romania2” este numele pentru aceasta sectiune a proiectului, iar “Instance_12” reprezinta “a 12a instanta creata din proiect”.
Precizam ca Protégé nu poate simula concepte precum: seguences, bags, alternatives, types, acestea fiind concepte caractristice pentru RDF prezentate in Capitolul 2.
Navigand instanta “Iasi” din aceast sectiune a proiectului cu Omnigator Eight am obtinut urmatoarea figura:
Figura 4.3 Navigare Iasi (RDF)
Codul RDF pentru intreg proiectul are 79 de pagini, mai exact 1876 linii de cod.
Capitolul 5- Modelarea cu Topic Maps
5.1 Adnotarea corpusului cu Topic Maps.
Pentru adnotarea corpusului cu Topic Maps am urmat pasii:
extragerea informatiei pe care am considerat-o imporanta;
transformarea corpusului intr-un document structurat (corpusul a fost impartit in topice, asociatii si ocurente);
crearea ierarhiilor.
In cele ce urmeaza vom prezenta procesul de adnotare pe una din paginile corpusului: http://www.turism.ro/english/moldavia.php. Este aceeasi pagina pe care am explicat mecanismul de adnotare cu RDF.
Extragerea informatiei:
Asa cum am mentionat in Capitolul 4, primul pas este identic atat pentru modelarea cu RDF cat si pentru modelarea cu Topic Maps. Din acest motiv nu vom afisa din nou informatia de la punctul 4.1.1.
Transformarea corpusului intr-un document structurat.
Am creat urmatoarele topice si proprietatile(sloturile) acestora pentru aceasta sectiune din proiect:
Regions
Association Slots:
HasCities: value type= instance, allowed classes=Cities, cardinality= multiple
HasCities_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Has Cities
HasCities_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Regions
HasCities_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Cities
HasCounties: value type= instance, allowed classes=Counties, cardinality= single
HasCounties_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Has Counties
HasCounties_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Regions
HasCounties_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Counties
HasMonasteries: value type= instance, allowed classes=Monasteries, cardinality= multiple
HasMonasteries_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Has Monasteries
HasMonasteries_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Regions
HasMonasteries_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Monasteries
Counties
Associations slots:
FoundInRegion: value type= instance, allowed classes=Regions, cardinality= single
FoundInRegion_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Found In Regions
FoundInRegions_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Counties
FoundInRegions_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Regions
HasCities: value type= instance, allowed classes=Cities, cardinality= multiple
HasCities_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Has Cities
HasCities_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Counties
HasCities_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Cities
Cities
Occurrence slots:
Touristic Attractions_occ: value type= instance, allowed classes=Touristic Attractions, cardinality= multiple
Description_occ: value type= instance, allowed classes=Description, cardinality= single
Associations:
FoundInRegion: value type= instance, allowed classes=Regions, cardinality= single
FoundInRegion_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Found In Regions
FoundInRegions_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Cities
FoundInRegions_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Regions
FoundInCounty: value type= instance, allowed classes=Counties, cardinality= single
FoundInCounty_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Found In County
FoundInCounty_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Cities
FoundInCounty_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Counties
HasMonastery: value type= instance, allowed classes=Monasteries, cardinality= multiple
HasMonasteries_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Has Monasteries
HasMonasteries_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Cities
HasMonasteries_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Monasteries
Monasteries
Associations:
FoundInCity: value type= instance, allowed classes=Cities, cardinality= single
FoundInCity_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Found In City
FoundInCity_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Monasteries
FoundInCity_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Cities
FoundInCounty: value type= instance, allowed classes=Counties, cardinality= single
FoundInCounty_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Found In County
FoundInCounty_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Monasteries
FoundInCounty_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Counties
FoundInRegion: value type= instance, allowed classes=Regions, cardinality= single
FoundInRegion_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Found In Regions
FoundInRegions_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Monasteries
FoundInRegions_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Regions
Occurrences:
Description: value type= string, cardinality= multiple
Foundation_year: value type= integer, cardinality= required single
Is_Colored: value type= boolean, cardinality= required single
Touristic_Attractions
Associations:
FoundInCity: value type= instance, allowed classes=Cities, cardinality= multiple
FoundInCity_assoc: value type=instance, allowed classes=TOPIC, cardinality= single, template value=Found In City
FoundInCity_thisrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Touristic Attractions
FoundInCity_otherrole: value type= instance, allowed classes=TOPIC, cardinality= single, template value=Cities
Crearea ierarhiilor.
Clasa “Cities” este subclasa a clasei “Counties”.
Clasa “Counties” este subclasa a clasei “Regions”.
Clasa “Monasteries” este subclasa a clasei “THING”.
Clasa “Regions este subclasa a clasei “THING”.
Clasa “Touristic Attractions” este subclasa a clasei “THING”.
Observam ca este aceeasi ierarhie din Capitolul 4.
Modelarea Topic Maps cu Protégé-3.0 :
Clasele:
Ierarhia claselor Sloturi
Figura 5.1 Modelarea topicelor cu Topic Maps
Instantele:
Figure 5.2 Modelarea instantelor cu Topic Maps
Protégé genereaza automat id-uri pentru topicele Topic Maps in acelasi mod ca pentru resursele RDF.
5.3 Codul Topic Maps.
In cele ce urmeaza vom prezenta codul XTM pentru aceeasi pagina pentru care am prezentat si codul RDF (http://www.turism.ro/english/moldavia.php).
Codul Topic Map:
<?xml version="1.0" encoding="UTF-8"?>
<topicMap xml:base="http://www.techquila.com/topicmaps/tmworld.xtm"
xmlns="http://www.topicmaps.org/xtm/1.0/" xmlns:xlink="http://www.w3.org/1999/xlink">
<topic id="P1L10216.topic">
<instanceOf>
<topicRef xlink:href="#P1L10132"/>
</instanceOf>
<subjectIdentity>
<subjectIndicatorRef xlink:href="http://www.techquila.com/topicmaps/tmworld.xtm#P1L10216"/>
</subjectIdentity>
<description>
It lies in the valley of the Bistrita River and is surrounded by mountains. It is first documented in the 15th century as Piatra lui Craciun, or Camena.</baseNameString>
</description>
</topic>
<topic id="P1L10134">
<baseName>
<baseNameString>Attractions</baseNameString>
</baseName>
</topic>
<topic id="P1L10056">
<baseName>
<baseNameString>Cities</baseNameString>
</baseName>
</topic>
<topic id="P1L10160">
<instanceOf>
<topicRef xlink:href="#P1L10056"/>
</instanceOf>
<baseName>
<baseNameString>Targu Neamt</baseNameString>
</baseName>
</topic>
In the example above, topic “Cities” has ID=P1L10056, and topic “Targu Neamt” is an instance of topic “Cities”
<topic id="P1L10182">
<instanceOf>
<topicRef xlink:href="#P1L10077"/>
</instanceOf>
<baseName>
<baseNameString>Moldova</baseNameString>
</baseName>
</topic>
<topic id="P1L10223.topic">
<instanceOf>
<topicRef xlink:href="#P1L10132"/>
</instanceOf>
<subjectIdentity>
<subjectIndicatorRef xlink:href="http://www.techquila.com/topicmaps/tmworld.xtm#P1L10223"/>
</subjectIdentity>
<description>It has direct airlines and rail links with Bucharest, it is worth going up to the ruins of Stephen's princely citadel on the heights near the city.</baseNameString>
</description>
</topic>
<topic id="P1L10179">
<instanceOf>
<topicRef xlink:href="#P1L10092"/>
</instanceOf>
<baseName>
<baseNameString>Sucevita</baseNameString>
</baseName>
<occurrence>
<resourceData>Thousands of pictures decorate the walls of the church. In fact they outnumber the pictures at any of the other monasteries, yet the western wall is blank. Legend says it that the artist fell off the wall scaffolding and was killed, so it remained undecorated. When you go there, look for the complex "Jesse's Tree" on the southern wall.</resourceData>
</occurrence>
<occurrence>
<resourceData>1600</resourceData>
</occurrence>
</topic>
<topic id="P1L10177">
<instanceOf>
<topicRef xlink:href="#P1L10092"/>
</instanceOf>
<baseName>
<baseNameString>Humor</baseNameString>
</baseName>
<occurrence>
<resourceData>Its paintings inculde illustration of a poem on the "Siege of Constantinople".On other walls are the "Return of the prodigal son" and the devil amusingly pictured as a greedy woman</resourceData>
</occurrence>
<occurrence>
<resourceData>1530</resourceData>
</occurrence>
</topic>
<topic id="P1L10198">
<instanceOf>
<topicRef xlink:href="#P1L10092"/>
</instanceOf>
<baseName>
<baseNameString>Agapia</baseNameString>
</baseName>
<occurrence>
<resourceData>Is the oldest monastery in Moldavia</resourceData>
</occurrence>
<occurrence>
<resourceData>1644</resourceData>
</occurrence>
</topic>
<topic id="P1L10157">
<instanceOf>
<topicRef xlink:href="#P1L10056"/>
</instanceOf>
<instanceOf>
<topicRef xlink:href="#P1L10043"/>
</instanceOf>
<baseName>
<baseNameString>Iasi</baseNameString>
</baseName>
<baseName>
<baseNameString>Iasi</baseNameString>
</baseName>
<occurrence id="P1L10210">
<instanceOf>
<topicRef xlink:href="#P1L10132"/>
</instanceOf>
<resourceData>Iasi</resourceData>
</occurrence>
</topic>
<topic id="P1L10098">
<baseName>
<baseNameString>Found in city</baseNameString>
</baseName>
</topic>
<topic id="P1L10161">
<instanceOf>
<topicRef xlink:href="#P1L10118"/>
</instanceOf>
<baseName>
<baseNameString>Local cooking and wines</baseNameString>
</baseName>
</topic>
<topic id="x1l0ckgi2e-2">
<subjectIdentity>
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/index.html#psi-at-class-instance"/>
</subjectIdentity>
</topic>
<topic id="P1L10075">
<baseName>
<baseNameString>Found in region</baseNameString>
</baseName>
</topic>
<topic id="P1L10176">
<instanceOf>
<topicRef xlink:href="#P1L10092"/>
</instanceOf>
<baseName>
<baseNameString>Arbore</baseNameString>
</baseName>
<occurrence>
<resourceData>Is quite small, is predominantly decorated withshades of green.It is known for the lively and graceful scene from "Genesis"</resourceData>
</occurrence>
<occurrence>
<resourceData>1503</resourceData>
</occurrence>
</topic>
<topic id="P1L10043">
<baseName>
<baseNameString>Counties</baseNameString>
</baseName>
</topic>
<topic id="P1L10118">
<baseName>
<baseNameString>Touristic Attractions</baseNameString>
</baseName>
</topic>
<topic id="x1l0ckgi2e-1">
<subjectIdentity>
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/index.html#psi-role-instance"/>
</subjectIdentity>
</topic>
<topic id="P1L10111">
<baseName>
<baseNameString>Has Regions</baseNameString>
</baseName>
</topic>
<topic id="P1L10174">
<instanceOf>
<topicRef xlink:href="#P1L10077"/>
</instanceOf>
<baseName>
<baseNameString>Bucovina</baseNameString>
</baseName>
</topic>
<topic id="P1L10092">
<baseName>
<baseNameString>Monasteries</baseNameString>
</baseName>
</topic>
<topic id="P1L10185">
<instanceOf>
<topicRef xlink:href="#P1L10092"/>
</instanceOf>
<baseName>
<baseNameString>Durau</baseNameString>
</baseName>
<occurrence>
<resourceData>It is also a mountain and a ski resort</resourceData>
</occurrence>
<occurrence>
<resourceData>1853</resourceData>
</occurrence>
</topic>
<topic id="P1L10159">
<instanceOf>
<topicRef xlink:href="#P1L10056"/>
</instanceOf>
<instanceOf>
<topicRef xlink:href="#P1L10043"/>
</instanceOf>
<baseName>
<baseNameString>Suceava</baseNameString>
</baseName>
<baseName>
<baseNameString>Suceava</baseNameString>
</baseName>
<occurrence id="P1L10223">
<instanceOf>
<topicRef xlink:href="#P1L10132"/>
</instanceOf>
<resourceData>Suceava</resourceData>
</occurrence>
</topic>
<topic id="x1l0ckgi2e-0">
<subjectIdentity>
<subjectIndicatorRef xlink:href="http://www.topicmaps.org/xtm/1.0/index.html#psi-role-class"/>
</subjectIdentity>
</topic>
<topic id="P1L10158">
<instanceOf>
<topicRef xlink:href="#P1L10056"/>
</instanceOf>
<baseName>
<baseNameString>Piatra Neamt</baseNameString>
</baseName>
<occurrence id="P1L10216">
<instanceOf>
<topicRef xlink:href="#P1L10132"/>
</instanceOf>
<resourceData>Piatra Neamt</resourceData>
</occurrence>
</topic>
<topic id="P1L10186">
<instanceOf>
<topicRef xlink:href="#P1L10092"/>
</instanceOf>
<baseName>
<baseNameString>Trei Ierarhi</baseNameString>
</baseName>
<occurrence>
<resourceData>Many well-known Romanian writers' houses are preserved as memorials. The best known monument of the city is the Trei Ierarhi Church.</resourceData>
</occurrence>
<occurrence>
<resourceData>1639</resourceData>
</occurrence>
</topic>
<topic id="P1L10103">
<baseName>
<baseNameString>Has Counties</baseNameString>
</baseName>
</topic>
<topic id="P1L10180">
<instanceOf>
<topicRef xlink:href="#P1L10092"/>
</instanceOf>
<baseName>
<baseNameString>Voronet</baseNameString>
</baseName>
<occurrence>
<resourceData>This "Sixtine Chapel of the East" was built by Stephen the Great.It is known for its unique blue color.</resourceData>
</occurrence>
<occurrence>
<resourceData>1488</resourceData>
</occurrence>
</topic>
<topic id="P1L10167">
<instanceOf>
<topicRef xlink:href="#P1L10118"/>
</instanceOf>
<baseName>
<baseNameString>The ruins of king Stephen's citadel</baseNameString>
</baseName>
</topic>
<topic id="P1L10061">
<baseName>
<baseNameString>Found in county</baseNameString>
</baseName>
</topic>
<topic id="P1L10178">
<instanceOf>
<topicRef xlink:href="#P1L10092"/>
</instanceOf>
<baseName>
<baseNameString>Moldovita</baseNameString>
</baseName>
<occurrence>
<resourceData>Was built by Prince Pertu Rares.It is known for its sriking shades of red, blue,yellow and brown.</resourceData>
</occurrence>
<occurrence>
<resourceData>1532</resourceData>
</occurrence>
</topic>
<topic id="P1L10184">
<instanceOf>
<topicRef xlink:href="#P1L10043"/>
</instanceOf>
<baseName>
<baseNameString>Neamt</baseNameString>
</baseName>
</topic>
<topic id="P1L10132">
<baseName>
<baseNameString>Description</baseNameString>
</baseName>
</topic>
<topic id="P1L10124">
<baseName>
<baseNameString>Has Monasteries</baseNameString>
</baseName>
</topic>
<topic id="P1L10077">
<baseName>
<baseNameString>Regions</baseNameString>
</baseName>
</topic>
<topic id="P1L10210.topic">
<instanceOf>
<topicRef xlink:href="#P1L10132"/>
</instanceOf>
<subjectIdentity>
<subjectIndicatorRef xlink:href="http://www.techquila.com/topicmaps/tmworld.xtm#P1L10210"/>
</subjectIdentity>
<baseName>
<baseNameString>Is the home of Romania's oldest University and a center of intellectula life.Many well-known writers' houses are preserved as memorials.</baseNameString>
</baseName>
</topic>
<topic id="P1L10156">
<instanceOf>
<topicRef xlink:href="#P1L10118"/>
</instanceOf>
<baseName>
<baseNameString>The monasteries </baseNameString>
</baseName>
</topic>
<topic id="P1L10081">
<baseName>
<baseNameString>Has Cities</baseNameString>
</baseName>
</topic>
<association id="P1L10157_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
</association>
<association id="P1L10157_P1L10072">
<instanceOf>
<topicRef xlink:href="#P1L10075"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10182"/>
</member>
</association>
<association id="P1L10157_P1L10122">
<instanceOf>
<topicRef xlink:href="#P1L10124"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10186"/>
</member>
</association>
<association id="P1L10157_P1L10127">
<member>
<topicRef xlink:href="#P1L10157"/>
</member>
<member>
<topicRef xlink:href="#P1L10156"/>
</member>
</association>
<association id="P1L10158_P1L10122">
<instanceOf>
<topicRef xlink:href="#P1L10124"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10158"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10185"/>
</member>
</association>
<association id="P1L10158_P1L10127">
<member>
<topicRef xlink:href="#P1L10158"/>
</member>
<member>
<topicRef xlink:href="#P1L10161"/>
<topicRef xlink:href="#P1L10156"/>
</member>
</association>
<association id="P1L10159_P1L10072">
<instanceOf>
<topicRef xlink:href="#P1L10075"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10174"/>
</member>
</association>
<association id="P1L10159_P1L10122">
<instanceOf>
<topicRef xlink:href="#P1L10124"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10176"/>
<topicRef xlink:href="#P1L10177"/>
<topicRef xlink:href="#P1L10178"/>
<topicRef xlink:href="#P1L10179"/>
<topicRef xlink:href="#P1L10180"/>
</member>
</association>
<association id="P1L10159_P1L10127">
<member>
<topicRef xlink:href="#P1L10159"/>
</member>
<member>
<topicRef xlink:href="#P1L10156"/>
<topicRef xlink:href="#P1L10167"/>
</member>
</association>
<association id="P1L10160_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10160"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10184"/>
</member>
</association>
<association id="P1L10160_P1L10072">
<instanceOf>
<topicRef xlink:href="#P1L10075"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10160"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10182"/>
</member>
</association>
<association id="P1L10160_P1L10122">
<instanceOf>
<topicRef xlink:href="#P1L10124"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10160"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10198"/>
</member>
</association>
<association id="P1L10160_P1L10127">
<member>
<topicRef xlink:href="#P1L10160"/>
</member>
<member>
<topicRef xlink:href="#P1L10161"/>
<topicRef xlink:href="#P1L10156"/>
</member>
</association>
<association id="P1L10174_P1L10079">
<instanceOf>
<topicRef xlink:href="#P1L10081"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10174"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10174_P1L10101">
<instanceOf>
<topicRef xlink:href="#P1L10103"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10174"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10174_P1L10122">
<instanceOf>
<topicRef xlink:href="#P1L10124"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10174"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10176"/>
<topicRef xlink:href="#P1L10177"/>
<topicRef xlink:href="#P1L10178"/>
<topicRef xlink:href="#P1L10179"/>
<topicRef xlink:href="#P1L10180"/>
</member>
</association>
<association id="P1L10182_P1L10079">
<instanceOf>
<topicRef xlink:href="#P1L10081"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10182"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
<topicRef xlink:href="#P1L10158"/>
<topicRef xlink:href="#P1L10160"/>
</member>
</association>
<association id="P1L10182_P1L10101">
<instanceOf>
<topicRef xlink:href="#P1L10103"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10182"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
<topicRef xlink:href="#P1L10184"/>
</member>
</association>
<association id="P1L10182_P1L10122">
<instanceOf>
<topicRef xlink:href="#P1L10124"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10182"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10185"/>
<topicRef xlink:href="#P1L10186"/>
</member>
</association>
<association id="P1L10183_P1L10072">
<instanceOf>
<topicRef xlink:href="#P1L10075"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10182"/>
</member>
</association>
<association id="P1L10183_P1L10122">
<instanceOf>
<topicRef xlink:href="#P1L10124"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10186"/>
</member>
</association>
<association id="P1L10183_P1L10079">
<instanceOf>
<topicRef xlink:href="#P1L10081"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
</association>
<association id="P1L10184_P1L10072">
<instanceOf>
<topicRef xlink:href="#P1L10075"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10184"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10182"/>
</member>
</association>
<association id="P1L10184_P1L10122">
<instanceOf>
<topicRef xlink:href="#P1L10124"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10184"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10198"/>
<topicRef xlink:href="#P1L10185"/>
</member>
</association>
<association id="P1L10184_P1L10079">
<instanceOf>
<topicRef xlink:href="#P1L10081"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10184"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10158"/>
<topicRef xlink:href="#P1L10160"/>
</member>
</association>
<association id="P1L10175_P1L10072">
<instanceOf>
<topicRef xlink:href="#P1L10075"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10174"/>
</member>
</association>
<association id="P1L10175_P1L10122">
<instanceOf>
<topicRef xlink:href="#P1L10124"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10077"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10176"/>
<topicRef xlink:href="#P1L10177"/>
<topicRef xlink:href="#P1L10178"/>
<topicRef xlink:href="#P1L10179"/>
<topicRef xlink:href="#P1L10180"/>
</member>
</association>
<association id="P1L10175_P1L10079">
<instanceOf>
<topicRef xlink:href="#P1L10081"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10198_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10198"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10184"/>
</member>
</association>
<association id="P1L10198_P1L10119">
<member>
<topicRef xlink:href="#P1L10198"/>
</member>
<member>
<topicRef xlink:href="#P1L10160"/>
</member>
</association>
<association id="P1L10198_P1L10131">
<member>
<topicRef xlink:href="#P1L10198"/>
</member>
<member>
<topicRef xlink:href="#P1L10182"/>
</member>
</association>
<association id="P1L10198_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10198"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10160"/>
</member>
</association>
<association id="P1L10176_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10176"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10176_P1L10119">
<member>
<topicRef xlink:href="#P1L10176"/>
</member>
<member>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10176_P1L10131">
<member>
<topicRef xlink:href="#P1L10176"/>
</member>
<member>
<topicRef xlink:href="#P1L10174"/>
</member>
</association>
<association id="P1L10176_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10176"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10185_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10185"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10184"/>
</member>
</association>
<association id="P1L10185_P1L10119">
<member>
<topicRef xlink:href="#P1L10185"/>
</member>
<member>
<topicRef xlink:href="#P1L10158"/>
</member>
</association>
<association id="P1L10185_P1L10131">
<member>
<topicRef xlink:href="#P1L10185"/>
</member>
<member>
<topicRef xlink:href="#P1L10182"/>
</member>
</association>
<association id="P1L10185_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10185"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10158"/>
</member>
</association>
<association id="P1L10177_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10177"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10177_P1L10119">
<member>
<topicRef xlink:href="#P1L10177"/>
</member>
<member>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10177_P1L10131">
<member>
<topicRef xlink:href="#P1L10177"/>
</member>
<member>
<topicRef xlink:href="#P1L10174"/>
</member>
</association>
<association id="P1L10177_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10177"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10178_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10178"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10178_P1L10119">
<member>
<topicRef xlink:href="#P1L10178"/>
</member>
<member>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10178_P1L10131">
<member>
<topicRef xlink:href="#P1L10178"/>
</member>
<member>
<topicRef xlink:href="#P1L10174"/>
</member>
</association>
<association id="P1L10178_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10178"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10179_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10179"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10179_P1L10119">
<member>
<topicRef xlink:href="#P1L10179"/>
</member>
<member>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10179_P1L10131">
<member>
<topicRef xlink:href="#P1L10179"/>
</member>
<member>
<topicRef xlink:href="#P1L10174"/>
</member>
</association>
<association id="P1L10179_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10179"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10186_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10186"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
</association>
<association id="P1L10186_P1L10119">
<member>
<topicRef xlink:href="#P1L10186"/>
</member>
<member>
<topicRef xlink:href="#P1L10157"/>
</member>
</association>
<association id="P1L10186_P1L10131">
<member>
<topicRef xlink:href="#P1L10186"/>
</member>
<member>
<topicRef xlink:href="#P1L10182"/>
</member>
</association>
<association id="P1L10186_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10186"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
</member>
</association>
<association id="P1L10180_P1L10059">
<instanceOf>
<topicRef xlink:href="#P1L10061"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10180"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10043"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10180_P1L10119">
<member>
<topicRef xlink:href="#P1L10180"/>
</member>
<member>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10180_P1L10131">
<member>
<topicRef xlink:href="#P1L10180"/>
</member>
<member>
<topicRef xlink:href="#P1L10174"/>
</member>
</association>
<association id="P1L10180_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10092"/>
</roleSpec>
<topicRef xlink:href="#P1L10180"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10159"/>
</member>
</association>
<association id="P1L10156_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10118"/>
</roleSpec>
<topicRef xlink:href="#P1L10156"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
<topicRef xlink:href="#P1L10158"/>
<topicRef xlink:href="#P1L10159"/>
<topicRef xlink:href="#P1L10160"/>
</member>
</association>
<association id="P1L10161_P1L10096">
<instanceOf>
<topicRef xlink:href="#P1L10098"/>
</instanceOf>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10118"/>
</roleSpec>
<topicRef xlink:href="#P1L10161"/>
</member>
<member>
<roleSpec>
<topicRef xlink:href="#P1L10056"/>
</roleSpec>
<topicRef xlink:href="#P1L10157"/>
<topicRef xlink:href="#P1L10158"/>
<topicRef xlink:href="#P1L10160"/>
</member>
</association>
</topicMap>
Navigand instanta “Iasi” din aceast sectiune a proiectului (modelarea cu Topic Maps) cu Omnigator Eight am obtinut urmatoarea figura:
Figura 5.3 Navigare Iasi (TM)
Intregul document Topic Maps pentru acest proiect are 153 de pagini, mai exact 6989 linii.
Capitolul 6- Studiu comparativ al celor doua formalisme prezentate
6.1 RDF si Topic Maps
Termenii RDF si Topic Maps sunt mentionati de fiecare data cand sunt mentionate tehnologiile pentru Semantic Web.
In acest capitol vom incerca sa subliniem asemanarile si diferentele dintre cele doua formalisme de adnotare.
Ambele tehnologii furnizeaza un set de mecanisme pentru a face afirmatii despre “lucruri” in general.
Este pentru prima oara cand modelele sunt comparate la nivel de aplicatie (pe acelasi corpus), nu doar formal.
6.2 Compararea modelelor
Vom incepe prin a descrie conceptele precum “lucruri”, “relatii intre lucruri”, “proprietati ale lucrurilor”, “tipuri de lucruri”, “numele lucrurilor”, “categorii de lucruri”, etc reprezentate in fiecare din cele doua formalisme.
6.2.1. Lucruri
Lucrurile despre care vorbim reprezinta notiunea centrala atat in RDF cat si in Topic Maps. Exemple de astfel de lucruri pot fi : persoana ‘Ion Creanga’, judetul 'Neamt' si aceasta lucrare. In topic maps asemenea lucruri sunt reprezentate prin constructii numite topice, iar in RDF prin constructii numite resurse. La baza, aceste constructii sunt la fel: stringuri ce reprezinta un lucru bine definit.
In RDF fiecare resursa este reprezentata de un singur URI. In cazul in care modelul RDF vorbeste despre lucruri abstracte, URI este doar un identificator simbolic pentru acea resursa.
In topic maps, lucrurile reprezentate de topice se numesc subiecte. Topicele pot identifica
subiectele in mai multe moduri: specificand resursa subiect printr-un URI (la fel precum o resursa RDF defineste un concept concret), sau printr-un identificator de subiect (la fel precum o resursa RDF defineste un concept abstract).
Mai jos este prezentata o diagrama care arata cum sunt identificate cele trei lucruri (Ion Creanga, Neamt si lucrarea) in RDF si in TM.
In RDF nu exist un mod, independent de aplicatie, pentru a preciza ca o resursa este concreta sau abstracta.
In topic maps, acest lucru este clar diferentiat prin adresa subiectului (pentru topice concrete) si identificatorul subiectului (pentru topice abstracte).
Figura 6.1 Trei lucruri
6.2.2. Relatii
RDF si Topic Maps au mecanisme diferite pentru a reprezenta relatiile dintre resurse, respectiv topice. In RDF avem tripletele, formate dintr-o resursa ce are o proprietate si o valoare. In topic maps relatiile sunt reprezentate prin asocieri si ocurente.
Pentru a spune ca :” Ion Creanga was born in Neamt” putem folosi aceasta afirmatie simpla in RDF: (www.icreanga, born_in, http://www.neamt.ro).
In topic maps relatia dintre ‘Ion Creanga’ si ‘Neamt’ este cel mai bine reprezentata printr-o asociere de tipul ‘born_in’, unde ‘Ion Creanga’ joaca rolul ‘personality’, iar ‘Neamt’ rolul ‘county’.
In diagrama de mai jos este reprezentata relatia in topic maps:
Figura 6.2 O relatie in Topic Maps
Mai jos aceeasi relatie in RDF:
Figura 6.3 Aceeasi relatie in RDF
Sunt trei mari diferente intre modul cum se reprezinta relatiile in RDF si Topic Maps:
in structura reprezentarii
in mostenirea bidirectionala
in reprezentarea resurselor concrete si abstracte
6.2.3. Atribute
Exemple de atribute pentru topicul 'Ion Creanga' sunt: ‘name’, ‘field of activity’, si ‘birth date’. In RDF, acestea ar fi simple proprietati ale resursei 'Ion Creanga':
(www.icreanga.ro, name, "Ion Creanga"), (www.icreanga.ro, field of activity, http://www.literature.3x.ro), and (www.icreanga.ro, birthdate, "1837-03-01").
Exista trei clase diferite de atribute:
Names (Nume) pot fi reprezentate atat in Topic Maps cat si in RDF.
Proprietati Simple sunt similare in cele doua formalisme.
Resurse relevante pentru un ‘lucru’ (ocurente): sunt reprezentate precum relatiile in RDF. In Topic Maps, ocurenta indica faptul ca resursa contine mai multa informatie.
6.2.4. Categorii de lucruri
Lucrurile sunt impartite in categorii. De exemplu, ‘Agapia’ este manastire, iar ‘Neamt’ este un judet. Atat RDF cat si Topic Maps impart lucrurile in categorii.
Aceasta este aria in care Topic Maps si RDF au cel mai mult in comun. rdf:type se gaseste in ambele formalisme de adnotare.
6.2.5. Context
RDF nu are notiunea de context. In Topic Maps, contextele se numesc “scopes”.
Contextele sunt alcatuite dintr-un set de topice care definesc validitatea contextului, si pot fi atasate numelor, ocurentelor si asocierilor.
6.2.6. Reificarea
RDF furnizeaza un proces numit "reificare" (transformarea intr-un lucru).
In Topic Maps totul este deja reificat.
Aceste doua modele de adnotare au nevoie unul de celalalt:
RDF are nevoie de Topic Maps pentru a face informatia practica. Topic Maps este o aplicatie RDF;
Topic Maps are nevoie de RDF pentru a avea o fundatie populara, si acceptata pe scara larga, pentru a putea descrie ce inseamna un topic map.
Tabelul 6.1 Compararea modelelor la nivel formal
Tabelul 6.2 Compararea modelelor la nivel de aplicatie
* Timpul efectiv de lucru dupa insusirea cunostintelor legate de RDF si Topic Maps
** Trebuie sa mentionam ca nu am folosit in proiectul RDF: seguences, bags sau alternatives deoarece Protégé nu poate simula aceste concepte.
6.3 Concluzii
Asemanari:
Au aplicatii in problema gasirii de informatie pe Web.
Sunt modele simple dar puternice
Pot fi folosite pentru a construi retele semantice de informatii
Topicele sunt precum RDF Schema: amandoua concepte stabilesc legaturile dintre lucruri
Deosebiri:
Modelul Topic Maps este considerat ca fiind mai abstract si mai greu de inteles decat modelul RDF
RDFS are o modalitate standard de a reprezenta ontologiile si constrangerile asupra acestora
Topic maps nu are concepte similare cu: sequences, bags, si alternatives, precum RDF
Notiunea de context: topic maps are facilitatea de a defini topice si asocieri valide intr-un anumit context; acest lucru ofera modelului Topic Maps o abilitate mai buna de a modela cunostintele
7. Bibliografie
(Antoniou, Harmelen 2004) Grigoris Antoniou, Frank von Harmelen: A Semantic Web Primer. 2004
(Anutariya et al 2001) Chutiporn Anutariya, Vilas Wuwongse, Kiyoshi Akama, Vichit Wattanapailin: Semantic Web Modeling and Programming with XDD.The firs Semantic
Web Working Symposium .2001 retrieved at http://www.semanticweb.org/SWWS/program/full/paper17.pdf. , last checked 01.10.2004.
(Berners-Lee, Hendler, and Lassila 2001) Tim Berners-Lee, James Hendler, and Ora Lassila: The Semantic Web. Scientific American May 2001.
(Cost et al 2001) R. Scott Cost, Tim Finin, Anupam Joshi, Yun Peng, Charles Nicholas, Harry Chen, Lalana Kagal, Filip Perich, Youyong Zou, Sovrin Tolia. ITTALKS: A Case Study in the Semantic Web and DAML .The first Semantic Web Working Symposium .2001 retrieved at http://www.semanticweb.org/SWWS/program/full/paper41.pdf. , last checked 01.10.2004.
(Cranefield 2001) Stephen Cranefield : UML and the semantic web .The firs Semantic Web Working Symposium .2001 .retrieved at http://www.semanticweb.org/SWWS/program/full/paper1.pdf. ,last checked 01.10.2004.
(Denny, 2002) Michael Denny: Ontology Building. A Survey of Editing Tools, November 06,
2002, retrieved at http://www.xml.com/pub/a/2002/11/06/ontologies.html , last checked 15.05.2005
(Euzenat 2001) Jérôme Euzenat : An infrastructure for formally ensuring interoperability in a heterogeneous semantic web .The firs Semantic Web Working Symposium .2001
retrieved at http://www.semanticweb.org/SWWS/program/full/paper16.pdf.
last checked 01.10.2004.
(Garcia and Delgado 2001) Roberto Garcia, Jaime Delgado: Semantic brokerage of intellectual property right .The firs Semantic Web Working Symposium .2001 . retrieved
at http://www.semanticweb.org/SWWS/program/full/paper5.pdf. ,last checked 01.10.2004.
(Klein and Bernstein 2001) Mark Klein, Abraham Bernstein: Searching for services on the semantic web using process ontologies .The firs Semantic Web Working Symposium .2001. retrieved at : http://www.semanticweb.org/SWWS/program/full/paper2.pdf. ,last checked 01.10.2004.
(Lambrix et al 2003) Patrick Lambrix, Manal Habbouche and Marta Pérez: Evaluation of
ontology development tools for bioinformatics, by, February 26, 2003 , retrieved at : http://bioinformatics.oupjournals.org/cgi/content/abstract/19/12/1564
last checked 22.04.2005.
(Protégé) Protégé home page, retrieved at: http://protege.stanford.edu/ , last checked
22.04.2005
(Palmer 2001) Sean B. Palmer. The Semantic Web, taking form.2001. retrieved at
http://infomesh.net/2001/06/swform/ , last checked 28.09.2004.
(Passin 2004) Thomas B. Passin:Explorer's guide to the semantic web. 2004.
(Omnigator) Omnigator home page, retrieved at http://www.ontopia.net/omnigator/ , last
checked 22.04.2005
(Tuttle et al 2001 ) Mark S. Tuttle, Steven H. Brown, Keith E. Campbell, John S. Carter, Kevin D. Keck, Michael Lincoln, Michael Stonebraker. The Semantic Web As "Perfection Seeking": A View from Drug Terminology .The firs Semantic Web Working Symposium . 2001.retrieved at http://www.semanticweb.org/SWWS/program/full/paper49.pdf. ,last checked 01.10.2004.
(SWAD-E) ––W3C:Semantic Web Advanced Development for Europe. retrieved at http://www.w3.org/2001/sw/Europe , last checked 28.09.2004.
(Tallis, Goldman and Balzer 2001)Marcelo Tallis, Neil Goldman, Robert Balzer. The Briefing Associate: A Role for COTS applications in the Semantic Web .The first
Semantic Web Working Symposium 2001. Retrieved at http://www.semanticweb.org/SWWS/program/full/paper54.pdf. , last checked 01.10.2004.
(W3C 2002a)––W3C:XHTML 1.0 The Extensible Hyper Text Markup Language (Second Edition).2002 retrieved at http://www.w3.org/TR/xhtml1/ , last checked
28.09.2004.
(W3C 2002b)––W3C:.How the Semantic Web Works . 2002 . retrieved at
http://www.w3.org/2002/03/semweb/ ,last checked 28.09.2004.
(W3C 2003)––-W3C:Semantic Web Activity Statement.2003. retrieved at www.w3.org/2001/sw/activity ,last checked 28.09.2004.
(W3C 2000)––-W3C:Semantic Web Development. Technical Proposal.2000. retrieved at http://www.w3.org/2000/01/sw/Development Proposal ,last checked 28.09.2004.
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: . Formalisme Alternative Pentru Semantic Web (ID: 148967)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.
