Proiectarea Unei Ontologii Utilizate In Domeniul Servicilor Web

=== Proiectarea Unei Ontologii Utilizate in Domeniul Servicilor Web ===

Cuprins

CAPITOLUL 1

Introducere

1.1. Scopul lucrării

În lucrarea de licență de față, cu titlul “Proiectarea unei ontologii utilizate în domeniul serviciilor Web” este tratată adăugarea semantică, pornind de la un model de date semistructurat. Adăugarea semantică se regăsește sub numele de adnotare. Această atașare semantică poate fi procesată de calculator, și astfel facilitează accesul și integrarea conținutului extins de date de pe Web.

World Wide Web-ul asigură acces la sursele de date eterogene care există pe Internet. Succesul său a dus la o creștere foarte mare a numărului de nivele, astfel încât găsirea informațiilor corecte devine o adevărată problemă. Pentru a rezolva aceste limitări, în ultima perioadă Web-ul a fost supus la două modificări majore, care încearcă să îl transforme dintr-o colecție de documente statice într-um mediu inteligent și dinamic de integrare a datelor.

Prima tehnologie inovatoare, tehnologia serviciilor Web, permite accesul la componentele software care se află pe platforme diferite și sunt scrise în limbaje de programare diferite, prin intermediul standardelor Web. Din perspectiva de afaceri, serviciile Web corespund cu serviciile de afaceri, și astfel, prin intermediul paradigmei de compoziție care stă la baza tehnologiilor Web, se poate realiză combinarea serviciilor de afaceri deja existente, pentru a rezulta servicii noi și complexe.

O limită a tehnologiei serviciilor Web o reprezintă faptul că găsirea și compunerea serviciilor încă necesită eforturi manuale. Pentru a rezolva această problemă, se propune adăugarea la serviciile Web existente a unor descrieri semantice ale funcțiilor lor pentru a facilita descoperirea și integrarea acestora. Această tehnologie, care combină serviciile Web și tehnicile Web-ului semantic, poartă numele de servicii Web semantice.

A doua tehnologie, Web-ul Semantic, dezvoltă tehnici pentru îmbunătățirea datelor existente pe Web cu descrieri, bazate pe logica formală, ale semnificațiilor lor. O ontologie se definește ca fiind o reprezentare formală a cunoștințelor existente în lume și oferă elemente pentru realizarea descrierilor semantice.

În contextul Web-ului semantic, descrierile serviciilor Web semantice se bazează pe două tipuri de ontologii: o ontologie generală a serviciilor Web, care specifică principalale aspecte utilizate pentru a descrie serviciile Web indiferent de domeniul în care operează; a doua ontologie, cea din domeniu, conține concepte din domeniul serviciilor Web pentru a popula tiparul de descrieri generale construit cu conceptele ontologiei generale. Aceste concepte denotă atât entități din domeniul serviciilor Web, cât și funcționalități ale serviciilor din domeniul respectiv.

Lucrarea de față își propune să analizeze și să prezinte o metodologie pentru proiectarea ontologiilor pentru serviciile Web, prin adaptarea unor tehnici existente, având la bază ca principale lucrări: [1, 2, 3].

Pe tot parcursul lucrării de față, conceptul de ontologie este deosebit de important. Această noțiune are diferite interpretări, conform schemei din figura 1.1.

Figura 1.1. Ierarhizarea ontologiilor

Ontologiile fundamentale sunt conceptualizări care conțin specificații ale conceptelor independente de domeniu și relații bazate pe principii formale derivate din lingvistică, filosofie și matematică. Ontologiile fundamentale utilizează un model de cunoștințe abstracte, cu un grad de generalitate crescut, care are la bază entități generice și relațiile dintre acestea.

Ontologia generică poate descrie servicii din mai multe domenii. Modelul de cunoștințe este mai specializat decât în cazul ontologiilor fundamentale, în schimb, conceptele similare din mai multe domenii sunt organizate sub forma unei singure entități.

Ontologiile din domeniu sunt cele mai specifice ontologii, modelele de cunoștințe din două domenii diferite diferă complet unul de altul, mulțimile alcătuite din concepte specifice fiecărui domeniu fiind disjuncte.

În cadrul ontologiilor, modelele de date sunt prelucrate și procesate semantic, rezultând astfel modele de cunoștințe și raționamente. Prelucrarea semantică se încadrează în unda semantică, bazată pe inteligența distribuită, ce implică modificări majore pentru tehnologie și economie, din punct de vedere al tehnicilor de transfer și comunicare a informațiilor. Tehnologiile semantice au un impact foarte mare asupra dezvoltării, infrastructurii, informațiilor și cunoștințelor utilizate în cadrul afacerilor, asupra aplicațiilor bazate pe informații și a celor bazate pe cunoștințe. Unda semantică este un proces de durată, care se prefigureaza din 2005 și se așteaptă că va dura peste 60 de ani.

1.2. Elemente distinctive ale lucrării

Lucrarea are ca elemente distinctive în dezvoltarea ontologiilor serviciilor Web, următoarele:

1. Prezentarea identificarea cerințelor pentru ontologiile din domeniul serviciilor Web

2. Analizarea unor metode pentru îmbogățirea ontologiilor serviciilor Web,având la bază restructurări ale unui limbaj clasic pentru serviciile Web, și anume DAML-S (DARPA Agent Markup Language, limbaj dezvoltat de Agenția de Apărare militară).

Un prim scop în dezvoltarea serviciilor Web semantice l-a constituit proiectarea unei ontologii generale pentru serviciile Web. Am identificat o serie de metode pentru evaluarea corectitudinii unei ontologii și pentru îmbunătățirea calității ei. Pe baza acestor calcule, se recomandă utilizarea unei ontologii generale pentru a descrie serviciile din viața reală, în scopul creșterii expresivității de modelare. Apoi, se adaptează ontologia pentru utilizarea sa în cadrul altor domenii, pentru a testa generalitatea cunoștințelor conceptualizate. În final, am ales tranziția către o ontologie fundamentală, de bază, în scopul eliminării ambiguităților existente în cadrul înțelesului conceptelor propuse și pentru a spori gradul de axiomizare a ontologiei. Aceste metode sunt utilizate în cadrul lucrării pentru a analiza OWL-S, Ontology Web Language – Service, pentru a îi identifica limitările și pentru a furniza soluții care să rezolve problema acestor limitări.

În acest sens, definesc unele dintre abrevierile folosite foarte des pe parcursul acestei lucrări:

OWL-S reprezintă un limbaj ontologic pentru serviciile Web.

DAML-S este o ontologie pentru serviciile Web care a fost promovată de Ministerul American al Apărării, iar abrevierea provine de la Darpa Agent Modelling Language.

DOLCE reprezintă o ontologie descriptivă pentru lingvistică și ingineria cognitivă.

WSDL este un limbaj de definire pentru serviciile Web.

1.3. Structura lucrării

Această lucrare este structurată în capitole, după cum urmează:

În capitolul 2 este prezentată tehnologia pentru dezvoltarea serviciilor Web semantice și sunt identificate unele cerințe ce trebuie îndeplinite de ontologiile din domeniul serviciilor Web.

În capitolul 3 sunt descrise o serie de concepte cheie pentru realizarea unei îmbunătățiri în cadrul Web-ului semantic, care se pot obține cu ajutorul semanticilor software, ce stau la baza principiilor ontologice generale.

În capitolul 4, ținând cont de faptul că o ontologie din domeniul serviciilor Web este calificată în funcție de gradul de expresivitate și utilizabilitate, este analizat DAML-S, limbajul de specificare al serviciilor Web, din aceste două perspective.

În capitolul 5, este tratată adaptabilitatea OWL-S prin extinderea sa în scopul descrierii modulelor software administrate de middleware-ul serverului de aplicație. Analiza realizată demonstrează că OWL-S se bazează pe mai multe principii de proiectare importante, care îl fac astfel ușor de reutilizat.

Capitolul 6 prezintă faptul că OWL-S se dovedește a fi ambiguu și slab axiomizat, propunând îmbunătățirea acestor aspecte prin tranziția lui OWL-S către ontologia fundamentală DOLCE.

În capitolul 7 sunt descriși unii dintre factorii care împiedică proiectarea ontologiilor de calitate dintr-un anumit domeniu, sunt expuse cerințele pentru o soluție automată a acestei probleme și este prezentat un mediu pentru învățarea ontologiilor, care satisface aceste cerințe.

CAPITOLUL 2

Serviciile Web-ului Semantic

În acest capitol este realizată o scurtă introducere referitoare la tehnologiile și serviciile aferente Web-ului Semantic. Scenariul prezentat oferă un exemplu de aplicare a acestor tehnologii, arătând modul în care ele îmbunătățesc accesul la informație, precum și modul de integrare a lor. În finalul capitolului, este dată o listă a cerințelor ce trebuie îndeplinite de ontologiile din domeniul serviciilor Web.

2.1. Evoluția continuă a World Wide Web – ului

World Wide Web–ul și noile tehnologii care îl extind (Web-ul Semantic, Serviciile Web și Serviciile Web Semantice) se adresează accesului la date și problemelor de integrare a conținutului.

World Wide Web –ul a apărut ca o soluție la problema managementului informației, pe care institutul de cercetare CERN din Elveția o întâmpina la sfârșitul anilor ’90. Activitatea de cercetare bazată pe date dezvoltată de CERN producea o cantitate mare de date digitale despre proiecte, software, cercetători, care erau distribuite în cadrul unei rețele de calculatoare pe care rulau sisteme de operare diferite și care foloseau formate de date proprii adesea incompatibile. Găsirea și integrarea acestor date distribuite și eterogene era foarte dificilă. Web-ul reprezenta un sistem hipertext distribuit care permitea accesul la surse de date eterogene prin utilizarea unui set de standarde pentru descrierea datelor (HTML), localizarea documentelor în cadrul unei rețele (URI – Uniform Resource Identifier) și accesarea datelor (HTTP). Datorită simplității HMTL-ului care permitea crearea unor pagini Web cu un efort minim, Web-ul a avut un succes grozav într-un timp relativ scurt. De atunci, numărul site-urilor a crescut într-un ritm alert, ajungând la 110 milioane în martie 2007.

Datorită evoluției accelerate a Web-ului, găsirea unei informații corecte devine din ce în ce mai dificilă, chiar dacă utilizăm motoare de căutare, cum ar fi Google. Tehnologiile de căutare actuale se bazează pe căutarea cuvintelor cheie. Aceste tehnici furnizează un număr relativ mare de răspunsuri, deoarece sunt listate toate site-urile care menționează cuvintele cheie, dar referirea semantică este scăzută, iar paginile despre subiectul dorit sunt ignorate dacă nu conțin cuvântul cheie. Precizia unei astfel de căutări este mică, pentru că doar câteva dintre paginile găsite conțin informațiile necesare utilizatorului. O căutare generală a unei sintagme poate duce la afișarea unui număr enorm de site-uri, în cadrul cărora cuvintele sintagmei se găsesc separate, în diverse propoziții. Prin rafinarea cererii, punând condiția ca respectivele cuvinte să se afle în ordinea dată, se găsesc puține răspunsuri, care în general sunt inutilizabile. Acest lucru apare din cauză că fiecare cuvânt este perceput ca un șir de litere, fără a se ține cont de semnificația lui. Aceste tehnici nu pot ține pasul cu limbajul uman, atât de complex, care conține sinonime, cuvinte polisemantice. Pentru a rezolva problema acestor limitări, Web-ul a suferit două schimbări majore.

În primul rând, a fost generat Web-ul semantic, care oferă, după cum îi spune și numele, o extensie semantică a Web-ului sintactic existent, prin adăugarea la întelesurile informației a unor descrieri formale bazate pe logică. Această caracteristică semantică va putea fi procesată de calculatoare și de aceea va putea permite un acces și o integrare mai ușoare a cantității mari de informație disponibilă decât cele ce vor putea fi obținute printr-o căutare bazată pe cuvinte cheie.

Din alt punct de vedere, Web-ul se modifică dintr-o colecție de pagini statice într-un mediu dinamic prin includerea tehnologiei serviciilor Web care permit accesul la componentele software prin intermediul protocoalelor Web. Tehnologia serviciilor Web semantice este o îmbinare a două tehnologii, prin aplicarea tehnicilor Web-ului Semantic asupra serviciilor Web.

2.2. Web-ul Semantic

Scopul Web-ului Semantic este de a rezolva limitele specifice Web-ului tradițional prin adăugarea la informația Web a unei reprezentări formale a înțelesului acesteia. Un beneficiu direct al semanticilor ce pot fi procesate de calculator îl reprezintă intensificarea ritmului și automatizarea sarcinilor de management informațional, cum ar fi căutarea sau integrarea datelor.

Figura 2.1. Evoluția Web-ului

Web-ul semantic poate fi definit ca o extensie a Web-ului actual, în cadrul căruia informației i se adaugă un înțeles bine definit, permițând calculatoarelor și oamenilor să coopereze mult mai bine. Acest înțeles este asigurat de descrierile semantice, numite metadate, ale căror caracteristici sunt:

descriu informațiile prin intermediul vocabularului din domeniu, ale cărui semnificații sunt specificate printr-un model formal din domeniu (ontologie)

se exprimă printr-un limbaj de reprezentare care poate fi analizat și interpretat de calculatoare.

Au existat mai multe propuneri pentru realizarea Web-ului Semantic, printre care includerea înțelesului surselor de date textuale în cadrul descrierilor semantice, al cărei minus a fost imposibilitatea unei codificări ulterioare, deși asigură o serie de adnotații utilizate cu succes în procesarea limbajului natural, pentru a capta diferite aspecte ale documentelor analizate. O alternativă pentru o mai bună înțelegere a conținutului documentului, o reprezintă scăderea complexității explicațiilor semantice adăugate documentelor text, lucru ce poate fi obținut prin utilizarea unor limbaje Web cu expresivitate semantică redusă (XML), având succes în procesarea limbajului natural. Scopul actual al Web-ului Sematic este susținerea schimbului inteligent de date. Informația explicată este semistructurată și se găsește în cadrul bazelor de date sau este transferată între diverse servicii Web. Rolul explicațiilor semantice este de a susține integrarea și schimbul de informații între aplicații sau organizații.

2.2.1. Ontologiile

Ontologiile reprezintă modele formale dintr-un domeniu. Conform lui Gruber ontologia poate fi definită ca o specificare explicită a unei conceptualizări. Cu alte cuvinte, o ontologie este un model de domeniu care este descris explicit. Borst consideră ontologia ca fiind o specificație formală a unei aceleiași conceptualizări, privită mai mult ca un consens, și nu ca un punct de vedere individual. De asemenea, această conceptualizare trebuie exprimată într-un format ce poate fi citit de calculator. Ca model formal, ontologiile reprezintă cunoștințele într-un format ce poate fi procesat de calculator, îmbunătățind astfel comunicarea dintre om și un program de calculator sau între două programe.

Descrierile semantice îmbunătățesc integrarea și accesul la informație. Mai multe forme sintactice diferite vor fi codate prin aceeași informație semantică, depășindu-se astfel limitările date de căutarea bazată pe cuvinte cheie. Bazându-se pe ontologia care explică relațiile dintre concepte într-un mod formal, ce poate fi înțeles de calculator, computerul va putea executa un raționament.

Ontologiile pot fi clasificate în funcție de gradul de generalitate, astfel:

1.Ontologiile de bază sunt conceptualizări ce conțin specificații ale unor relații și concepte independente de domeniu sau de problemă, bazate pe principii formale derivate din lingvistică, filosofie și matematică (de exemplu DOLCE).

2.Ontologiile generice conțin cunoștințe generale despre un anumit domeniu. În lucrarea de față se va folosi OWL-S, o ontologie care specifică un set de concepte ce permit descrierea serviciilor Web.

3.Ontologiile de domeniu sunt foarte puțin reutilizabile și sunt specifice unui anumit domeniu.

Un alt criteriu de clasificare îl reprezintă gradul de detaliere al specificațiilor:

1.Ontologiile nedetaliate de domeniu, care sunt învățate automat.

2.Ontologiile generice, detaliate, OWL-s, care conțin câteva restricții, dar care nu oferă mult din perspectiva ontologică.

3.Ontologiile detaliate de bază, cum este DOLCE.

Figura 2.2. Clasificarea ontologiilor conform celor două criterii

Pentru a descrie beneficiile utilizării descrierilor ontologice pentru problemă găsirii unei farmacii MediCare pe o distanță de o milă de zona ce are codul poștal 19901, s-a avut în vedere construirea unei ontologii care specifică un set de concepte referitoare la furnizorii medicali. Entitățile principale din domeniul ce trebuie conceptualizat îl reprezintă termeni ca Furnizor Medical, Program Medical, Farmacie. Între acest concepte există o serie de relații, cum ar fi cea de tipul isA. Ontologia exemplificată specifică trei feluri de concepte HealthCareProvider, Furnizor Medical, și anume trei subclase. Pot fi impuse o serie de restricții asupra definițiilor, restricția proprietăților fiind un mecanism des utilizat pentru definirea subclaselor. Spre exemplu, o Farmacie este un Furnizor Medical, ce vinde Medicamente, iar un Spital poate diferi de o Farmacie din punct de vedere al produselor sau serviciilor oferite. Multe pagini Web referitoare la farmacii pot fi descrise semantic utilizând concepte din această ontologie. Spre exemplu, instanțele de date din figura 2.2 descriu că SafeWayInc este un Furnizor Medical HealthCare aprobat de Medicare, ce vinde aspirină, care este un Medicament.

În figura următoare, sunt prezentate o serie de relații existente între conceptele din domeniul pe care l-am ales pentru exemplificare.

Figura 2.3. Exemplu de ontologie și de instanțe ale acesteia

Descrierile semantice îmbunătățesc accesul la informație și integrarea acesteia. Formele sintactice diferite vor fi codificate utilizând aceeași informație semantică, depășindu-se astfel contrângerile căutării axate pe cuvinte cheie. Pe baza ontologiei care explică relațiile dintre concepte într-un mod formal, ce poate fi înțeles de calculator, computerul poate executa raționamente. Spre exemplu, poate deduce aitomat că SafeWazInc poate fi clasificat atât ca și Farmacie (deoarece vinde medicamente), cât și ca Furnizor Medicare, deoarece este autorizată de acest program. Astfel, datele semantice ajută la îmbunătățirea și automatizarea sarcinii de îndeplinit.

2.2.2. Limbaje ontologice pentru Web-ul Semantic

Ontologiile se pot specifica într-un limbaj formal. RDF reprezintă primul pas pentru constituirea unui limbaj ontologic bazat pe Web. RDF reprezintă un model de date care permite descrierea resurselor de pe Web. RDF Schema se bazează pe RDF și asigură definirea elementelor de bază ale unei ontologii, cum sunt clasele și ierarhia acestora, proprietățile și domeniile acestora, intervalul de definiție. RDF este utilizat pentru exprimarea ontologiilor nedetaliate.

OWL (Ontology Web Language) este un limbaj ontologic care permite o expresivitate mai mare decât RDF. Se bazează pe DAML-ONT și OIL, și oferă metode de definire a relațiilor dintre clase (uniune, intersecție), cardinalitatea și restricțiile valorice ale proprietăților (cardinalitate, cuantificatori). OWL asigură codarea cunoștințelor ontologice, folosind o sintaxă bazată pe XML.

<owl:Class rdf:ID="Furnizor Medicare">

<rdfs:subClassOf>

<owl:Restriction>

<owl:onProperty>

<owl:ObjectProperty rdf:ID="autorizatDe"/>

</owl:onProperty>

<owl:hasValue>

<HealthProgram rdf:ID="Medicare"/>

</owl:hasValue>

</owl:Restriction>

</rdfs:subClassOf>

<rdfs:subClassOf>

<owl:Class rdf:ID="Furnizor medical"/>

</rdfs:subClassOf>

</owl:Class>

<owl:Class rdf:ID="Program medical"/>

2.3. Servicii Web

În paralel cu evoluția spectaculoasă a sa, Web-ul devine din ce în ce mai dinamic datorită tehnologiilor serviciilor Web. Un serviciu Web reprezintă o aplicație software identificată printr-un URI (Uniform Resource Identifier), ale cărei interfețe și legături pot fi definite, descrise și descoperite ca obiecte XML. Un serviciu Web asigură interacțiuni directe cu alți agenți software prin utilizarea mesajelor bazate pe XML transmise prin intermediul protocoalelor Internet.

Figura 2.4. Funcționarea unui serviciu Web

Interfața unui serviciu Web este descrisă utilizând WSDL (Web Service Description Language) (Limbaj de descriere a unui serviciu Web). Serviciile Web fac schimb de mesaje codate în mediul de lucru SOAP (Simple Object Access Protocol = Protocol de acces al Obiectelor) și transportate prin intermediul HTTP sau al altor protocoale Internet. Serviciile Web pot îndeplini sarcini multiple.

Ciclul de viață al unui serviciu Web este următorul: Un furnizor de servicii publică descrierea WSDL a serviciului său în protocolul UDDI (protocol XML pentru descrierea, descoperirea și integrarea generală – Universal description, discovery and integration), un registru care permite descoperirea și integrarea unei descriei universale a unui serviciu Web. Cei care solicită serviciul pot să inspecteze UDDI și să localizeze sau să descopere serviciile Web care îi interesează. Utilizând informația furnizată de descrierea WSDL, clienții pot utiliza serviciul Web cerut. Pentru o mai bună funcționalitate, se pot folosi simultan mai multe servicii Web. Specificarea unei astfel de compuneri este dată de BPEL4AWS (Limbajul de execuție a unui proces de afaceri pentru un serviciu Web – Business Proces Execution language for Web Services). Pe baza acestor standarde, serviciile Web ascund detaliile de implementare, sporind interoperabilitatea între platforme și limbaje.

Majoritatea serviciilor Web permit acesul la baze de date de dimensiuni mari, asigurând astfel accesul controlat la informașiile care nu sunt prezentate explicit pe paginile Web. Spre exemplu, procesul de găsire al farmaciei poate fi repetat pentru orice cod poștal, sau pentru orice furnizor de servicii medicale, pe baza rezultatelor unuia sau mai multor servicii Web, și nu pe baza datelor din cadrul paginilor Web. Un serviciu Web de calitate care poate generaliza această sarcină este serviciul Web Furnizor Medical, care poate găsi detalii despre furnizorii Medicare, pe baza unui cod poștal, a numelui unui oraș sau a tipurilor de furnizori solicitații.

Serviciul(

TipulPortului:FurnizorMedicareSoap (

Op:AflăFurnizorDupăCodulPoștal(

Imsg(cod), OMsg(ListaDatelorFurnizorului))

Op:AflăFurnizorDupăOraș(

Imsg(Oraș), Omag(ListaDatelorFurnizorului))

Op:AflăFurnizorDupăTip(

Imsg(descriere), Omag(ListaDatelorFurnizorului))

)

)

Exemplul de mai sus arată reprezentarea schematică a unui fișiei WSDL asociat serviciului FurnizorMedicare. WSDL conține multe informații utile în industrie și documentații aprofundate referitoare la instrumente, ca generatoarele și editoarele WSDL. Fiind un limbaj bazat pe XML, poate fi procesat de calculator, fiind un mod structurat și standardizat penzru descrierea interfețelor web ale serviciilor. În WSDL, un serviciu este interpretat sub forma unei colecții de puncte finale din cadrul unei rețele, care operează asupra mesajelor. Serviciul exemplificat asigură un singur port, FurnizorMedicareSoap. Acest port grupează trei operații, care returnează lista furnizorilor Medicare și detaliile acestora, în cazul în care a fost precizat fie codul poștal, fie numele unui oraș, sau descrierea materailului furnizat (AflăFurnizorDupă…). Fiecare operație are un mesaj de intrare IMSg și unul de ieșire Omsg. Fiecare mesaj are un nume și un set de părți de un anumit tip. Părțile acestea eeprezintă parametrii de intrare, respectiv de ieșire. Exemplul nu prezintă numele mesajului, ci numai al părților sale. Un document WSDL are două părți importante, interfața abstractă a serviciului, ce specifică tipurile datelor, mesajelor, porturilor, împreună cu operațiile corespunzătoare, și partea de implementare, care leagă interfața cu protocoalele rețelei și formatele mesajelor.

Totuși, aceste tehnologii nu pot asigura automatizarea și interoperabilitatea. Pentru acest lucru este nevoie de programatori. Pentru realizarea automată a acestui lucru sunt necesare semantici ce pot fi procesate de calculator, care includ proprietățile, capacitățile și interfețele serviciului.

2.4. Servicii Web semantice

Comunitatea științifică ce se ocupă de Web-ul Semantic consideră că limitele tehnologiei actuale din domeniul serviciilor Web pot fi depășite prin îmbogățitrea descrierilor serviciilor cu un strat semantic, care să permită descoperirea, compoziția, monitorizarea și execuția automată a serviciilor. Deoarece automatizarea acestor sarcini este foarte necesară, tehnologia serviciilor Web-ului semantic a fost adoptată în cadrul multor proiecte de cercetare din diverse domenii.

Figura 2.5. Ciclul de acțiuni pentru găsirea celui mai apropiat furnizor medical

Sarcina exemplificată reprezintă o specializare a acțiunii mai generale de găsire a celui mai apropiat furnizor medical, sau de găsire a unui furnizor din orice domeniu. Una dintre strategiile pentru tealizarea acestei acțiuni generice este de a afla detaliile tuturor furnizorilor medicali și apoi de a îl selecta pe cel mai apropiat prin calcularea distanțelor dintre locația furnizorului și locația de referință. Acest ciclu este reprezentat schematic în figura 2.5. Pentru acțiunea exemplificată, este suficient ca în cadrul acestui ciclu să se regăsească serviciul FurnizorMedicare și serviciul Web penztru calcularea distanțelor dintre codurile poștale.

Tehnologia serviciilor web-ului semantic încearcă să automatizeze realizarea acestui tip de acțiuni pe baza descrierilor semantice ale serviciilor Web. Prin utilizarea acestor descrieri, pot fi selectate și combinate serviciile necesare într-un mod care să permită rezolvarea sarcinii propuse. În primul rând, fiind date specificațiile stării inițiale și finale, este executat un raționament pre sau postcondiționat pentru selectarea și combinarea serviciilor corespunzătoare. În al doilea rând, utilizând paradigma de proiectare bazată pe parametri, este specificat formal ciclul de acțiuni și apoi acesta este populat cu serviciile Web corespunzătoare, în funcție de sarcina ce trebuie îndeplinită.

O caracteristică a tuturor mediilor de lucru pentru descrierile serviciilor Web semantice este faptul că acestea combină două tipuri de ontologii. Prima dintre ele este o ontologie generică, cum ar fi OWL-S, care specifică principalele concepte generice ale unui serviciu Web , spre exemplu intrările și ieșirile, și care constituie elementul de bază al descrierii. Cea de-a doua este o ontologie de domeniu, care definește cunoștințele din domeniul serviciului Web, cum ar fi tipurile parametrilor (de exemplu Oraș) și funcționarea acestora (de exemplu Găsește Furnizorul Medical).

2.4.1. Ontologiile generice

Lucrarea ia în considerare una dintre cele două ontologii care se află momentan în procesul de dezvoltare, și anume OWL-S. Aceasta este împărțită în patru subontologii pentru specificarea a ceea ce serviciul realizează (Profilul), a modului în care funcționează serviciul (Procesul), și a felului în care acesta este implementat (Motivarea). A patra ontologie, Serviciul, conține conceptul de serviciu care leagă Profilul, Modelul și Motivul Serviciului. Serviciul prezintă un Profil, este descris de un Model și susține un Motiv. Aceste trei concepte sunt specializate în ontologiile de Profil, Proces și Implementare. În continuarea acestei secțiuni, sunt explicate toate cele trei părți ale OWL-sS prin ecemplificarea utilizării lor pentru a descrie serviciul prezentat.

Figura 2.6. Ontologia OWL-S

A1. Ontologia de Profil

Specifică funcționalitatea unui serviciu (Află Furnizor Medical), tipul semantic al intrărilor și al rezultatelor (Oraș, Furnizor Medicare), detaliile furnizorului serviciului și alți parametri, cum ar fi aria geografică și rata calității. Această descrie este utilizată pentru descoperirea serviciului. Conceptul central al acestei ontologii, Profilul, este o sublasă a Profilului Serviciului.

În reprezentarea schematică a descrierilor serviciilor Web-ului semantic, pentru fiecare Profil este prezentat atât procesul pe care îl descrie, indicat prin relația hasProc – Are Procesul, cât și caracteristicile funcționale ale profilului (Intrări, Ieșiri, Precondiții, Efecte) și tipul acestora. Pentru exemplul considerat, serviciul FurnizorMedical descrie trei profile. Fiecare profil are un tip semantic descris de unul dintre conceptele de funcționare (Găsește Furnizor Medical După Cod Poștal), (Găsește Furnizor Medical După Oraș) sau (Găsește Furnizor Medical După Stoc). Fiecare profil descrie un proces, iar în final returnează un rezultat care este descris prin conceptul de (Detalii Furnizor). Tipul intrării variază pentru fiecare profil: CodPoștal, Oraș, TipStoc.

Serviciu FurnizorMedicare:

*Profil:AflăFurnizorMedicareDupăCodPoștal (hasProc P1)

(I(Cod), O(DetaliiFurnizor))

*Profil: AflăFurnizorMedicareDupăOraș (hasProc P2)

(I(Oraș), O(DetaliiFurnizor))

*Profil: AflăFurnizorMedicareDupăStoc (hasProc P3)

(I(TipFurnizare), O(DetaliiFurnizor))

*ModelProces: …

*WSDLGrounding: …

A2. Ontologia de Proces

Multe servicii complexe sunt alcătuite din servicii mai simple executate într-o anumită ordine. Cumpărarea unei cărți de pe un site implică utilizarea unui serviciu de căutare, care selectează cartea, și a unui serviciu de plăți. OWL-S permite descrierea modelelor interne ale proceselor de acest tip. Acest lucru are multe utilizări. Se poate verifica dacă procesul de afaceri al unui serviciu este corespunzător (selectarea produsului trebuie să fie întotdeauna anterioară plății). Se poate monitoriza execuția fiecărei etape din cadrul serviciului. Aceste modele de procese pot fi utilizate pentru compunerea automată a serviciilor Web. Conceptul de Model al Serviciului descrie modul de funcționare internă a serviciului și este detaliat sub forma conceptului de Model de Proces, care conține un singur proces ce poate fi atomic, simplu sau compus din mai multe procese înlănțuite prin diverse concepte de control. Pentru fiecare proces se specifică tipul acestuia, conceptele de control, intrările, rezultatele și tipurile acestora. Serviciul FurnizorMedical permite alegerea din cele trei procese atomice ale sale, corespunzătoare celor trei profile. De aceea, Modelul Procesului conține un Proces Compus, cu o alternativă de control a Alegerii.

Serviciu FurnizorMedicare:

*Profil:…

*ModelulProcesului:

Proces Compus: Proces Medicare:Alegere

{

ProcesAtomic:P1 (I(CodPoștal),O(DetaliiFurnizor))

ProcesAtomic:P2 (I(Oraș),O(DetaliiFurnizor))

ProcesAtomic:P3 (I(TipStoc),O(DetaliiFurnizor))

}

*Bază implementare WSDL

Legătura dintre Profil și Proces

Un Profil conține multiple legături cu Procesul. Figura 2.7 prezintă aceste legături. În primul rând, un profil declară procesul pe care îl descrie prin proprietatea unică Are Procesul. În al doilea rând, Intrările, Ieșirile, Precondițiile și Efectele, sau pe scurt IIPE, profilului corespund în anumită măsură cu cele ale procesului. Înțelegerea acestei corespondențe nu este facilă, deoarece IIPE-urile joacă roluri diferite în cadrul profilului și în cadrul procesului. În ontologia de profil, IIPE-urile sunt tratate ca parametri ai profilului, fiind subproprietăți ale profilului, incluse în cadrul proprietății Parametru. În ontologia de proces, doar Intrările și Ieșirile sunt considerate subproprietăți ale procesului, de tip Parametru. Precondițiile și Efectele sunt simple proprietăți ale procesului. În timp ce IIPE-urile reprezintă proprietăți atât în cadrul profilului, cât și în cadrul procesului, faptul că ele sunt tratate diferit la nivel conceptual ridică anumite probleme. Legătura dintre IIPE-urile din părțile de Proces și cele de Profil din cadrul descrierilor DAML-S este realizată prin proprietatea seReferăLa, care are ca domeniu DescriereParametru și ca plajă de valori proces:parametru.

Figura 2.7. Legătura dintre Profil și Proces

A3. Ontologia de implementare

Permite vocabularului conectarea descrierilor conceptuale ale serviciului, specificate de profil și de proces, la detaliile de implementare reale, cum ar fi formatele de transmitere a mesajelor și protocoalele rețelei. Implementarea se realizează pe baza a trei reguli:

R1. Fiecărui proces atomic îi corespunde o operație din limbajul de descriere al serviciului Web.

R2.Fiecare intrare a procesului atomic formează o parte a mesajului de intrare.Fiecare ieșire a procesului atomic este transformată într-o parte corespondentă din mesajul de ieșire al operașiilor WSDL.

R3.Tipul fiecărei părți a mesajului WSDL poate fi specificat în termenii unui parametru OWL-S.

Ontologia de implementare specializează Implementarea Serviciului, ca fiind o Implementare WSDL, ce conține un set de elemente de tip ImplementareAProcesuluiAtomicWSDL, fiecare fiind implementarea procesului atomic specificat în Modelul Procesului. Fiecare implementare a procesului atomic este deescrisă prin prezentarea legăturii dintre procesul atomic și elementul WSDL corespondent. Serviciul FurnizorMedicare are trei implementări ale proceselor atomice, câte una pentru fiecare proces din Modelul Procesului.

Serviciu FurnizorMedicare:

*Profil:…

*ModelulProcesului:

*Implementare WSDL

{

ImplementareAProcesuluiAtomicWSDL: Gr1 (P1->op: AflăFurnizorDupăCodPoștal)

ImplementareAProcesuluiAtomicWSDL: Gr2 (P2->op: AflăFurnizorDupăOraș)

ImplementareAProcesuluiAtomicWSDL: Gr3 (P3->op: AflăFurnizorDupăTipStoc)

}

Unele dintre principiile de proiectare de la baza OWL-S identificate sunt:

Descrieri semantice sau sintactice. OWL-S face diferență între aspectele semantice și cele sintactice ale entității descrise. Ontologiile de Profil și de Proces permit realizarea descrierilor semantice ale serviciului Web, în timp ce descrierile WSDL codifică aspectele sintactice, cum ar fi numele operațiilor și parametri acestora. Ontologia de implementare asigură o transformare între părțile semantice și cele sintactice ale descrierii, facilitând asocierea lor. Spre exemplu, o anumită descriere semantică poate fi transformată în mai multe descrieri sintactice facă aceeași funcționalitate semantică poate fi accesată în mai multe moduri. O anumită descriere sintactică ăpate fi transformară în diferite interpretri conceptuale, oferind diverse puncte de vedere asupra serviciului.

Cunoștințe generice sau din domeniu. OWL-S oferă un set de bază de primitive ce specifică orice tip de serviciu Web. Aceste descrieri pot fi îmbogățite prin cunoștințe din domeniu, specificate în cadrul unei ontologii separate din domeniu. Această alternativă de modelare permite utilizarea setulșui de primitive de bază în cadrul mai multor domenii.

Modularitatea. Altă caracteristică a OWL-S o constituie partiționarea descrierilor asupra mai multor concepte. Diferite aspecte ae descrierii sunt împărțite în trei concepte. Ca rezultat, o instanță serviciu se află în relație cu alte trei instanțe, fiecare dintre ele conținând un aspect particular al serviciului. Există anumite avantaje ale modelării modulare. Deoarece descrierea este împărțită în mai multe instanțe, părțile pot fi reutilizate. De exemplu, se poate refolosi descrierea Profilului unui anumit serviciu. Specificarea serviciului devine flexibilă, putând fi specificată doar partea relevantă pentru acel serviciu (dacă nu existăă implementarem nu sunt necesare nici modelul serviciului, nici implementarea serviciului). Orice descriere OWL-S poate fi extinsă cu ușurință prin specializarea conceptelor OWL-S.

2.4.2. Ontologiile din domeniu

Sunt utilizate pentru a defini tipul funcționalității serviciului, precum și tipul parametrilor săi. Se specifică o ierarhie a structurii de date și o ierarhie a funcționalității, care conține o clasificare a posibilităților de funcționare a serviciului. De exemplu, cunoștințele din domeniu sunt utilizate pentru a defini tipul de funcționalitate oferită de serviciu și tipul parametrilor serviciului.

Figura 2.8. Ontologia din domeniul serviciilor Web

Figura 2.8. arată structura ierarhică a ontologiei din domeniu utilizate pentru a descrie serviciul Web exemplificat. Figura descrie o ierarhie a strucuturilor de date și o ierarhie a funcționalităților. Ierarhia funcționalităților conține o clasificare a capacităților serviciului. Sunt prezentate două clase generice de capacități ale serviciului, una pentru găsirea furnizorului medical și alta pentru calcularea distanțelor dintre două locații. Fiecare dintre aceste categorii generice are mai multe capacități specializate, obținute prin resticționarea tipului parametrilor de ieșire (de exemplu Găsește furnizori Medicare) sau a tipului parametrilor de intrare (de exemplu CodPoștal, Oraș, TipStoc).

Complexitatea activităților de execuție a raționamentelor ce pot fi realizate cum ajutorul descrierilor serviciilor Web-ului semantic este condiționată de mai mulți factori. În primul rand, toate serviciile Web dintr-un domeniul trebuie să utilizeze concepte din cadrul aceleiași ontologii din domeniu pentru descrierea lor. Altfel, problema transformării ontologiei este dificil de rezolvat.

Acest lucru necesită ca ontologia dein domeniu să fie îndeajuns de cuprinzătoare, încât să includă conceptele necesare pentru orice serviciu Web dintr-un anumit domeniu. În al doilea rând, cantitatea sporită de cunoștințe disponibile este crucială pentru realizarea unor raționamente complexe.

Prin utlizarea descrierilor serviciilor Web-ului semantic prezentate, sarcina exemplificată poate fi generalizată și automatizată. Serviciile corespunzătoare necesare pentru executarea sarcinii pot fi selectate automat din cadrul unei colecții de servicii. Metadatele semantice permit realizarea unei selecții flexibile, care poate allege servicii ce îndeplinesc parțial o anumită cerință, dar pot fi interesante. De exemplu, u serviciu care găsește detaliile furnizorilor medicali poate fi considerat corespunzător pentru sarcina de găsire a detaliilor furnizorilor Medicare, dacă ontologia din domeniul serviciilor Web utilizată specifică faptul că un furnizor Medicare este un tip de furnizor medical. Această potrivire este mai avansată decât tehnica oferită de UDDI, bazată pe căutarea cuvintelor cheie. Compunerea mai multor servicii pentru a forma un serviciu complex este realizată automat. După descoperirea și compunerea pe baza descrierilor semantice, serviciile pot fi apelate pentru a rezolva o anumită sarcină precizată.

2.5. Caracteristici necesare ontologiilor

Rolul ontologiilor generice din domeniul serviciilor Web este de a capta aspectele independente de domeniu ale serviciilor Web. Aceste ontologii trebuie să fie puternic axiomatizate, astfel încât să permită realizarea automată de descrieri formale. Următoarele cerințe trebuie îndeplinite de ontologiile generice din domeniul serviciilor Web:

Expresivitatea de modelare

Ontologiile generice din domeniul serviciilor Web sunt utilizate entru a modela un număr mare de servicii din domenii diferite. De aceea, aceste ontologii trebuie să descrie multe servicii eterogene, prin permiterea modelării diverselor tipuri de servicii.

Semanticile clare și formalizarea bogată

Descrierile serviciilor Web semantice implică acțiuni complexe, bazate pe raționamente, din partea mai multor agenți software. De aceea, este important ca semnificația descrierilor să poată fi interpretată fără ambiguități de către toți agenții. Este necesar ca semanticile ontologiilor generice din domeniul serviciilor Web să fie clar și specificat formal. O formalizare amănunțită este cruciaă pentru experimarea clară a semanticilor descrierilor și pentru a facilita realizarea raționamentelor complexe.

Adaptabilitatea

O altă cerință importantă este ca modelele create utilizând ontologiile generice să fie ușor reutilizate, și anume să poată fi adaptete pentru orice alte servicii Web. Cunoștințele generice conținute în cadrul unei ontologii a serviciilor Web trebuie să poată descrie și alte tipuri de entități software. Acest lucru facilitează trecerea de la software-ul tradițional la serviciile Web.

Standardele comune

Deși ontologiile generice din domeniul serviciilor Web au același obiectiv, utilizează diferite medii ontologice pentru specificarea serviciilor. Nu există o coincidență între standardele propuse, ceea ce semnifică faptul că serviciile descrise cu ajutorul unor anumite medii nu pot fi utilizate împreună. Lipsa acestei coincidențe împiedică realizarea unei comparări formale între aceste ontologii. Dacă nivelul de dezvoltare al unei ontologii nu permite alinierea acestora la un singur standard, standardul trebuie transformat astfel încât să fie cel puțin interoperabil. Deoarece tehnologie serviciilor Web-ului semantic completează și îmbunătățește tehnologia actuală, este importantă realizarea unei corespondențe între ontologiile generice din domeniul serviciilor Wev și alte standarde industriale din acest domeniu.

Utilizabilitatea

Reușita unei ontologii generice nu este condiționată doar de calitatea sa, ci și de acceptarea sa de către comunitate. Această acceptare poate fi determinată de mai mulți factori. Spre exemplu, atât documentația suport, cum ar fi exemplele de utilizare și ghidurile de modelare, cât și instrumentele suport, asigură ușurința utilizării ontologiei. Un alt punct cheie al utilizabilitățiiîl reprezintă mentenanța modelelor semantice realizate. Pentru a putea i adaptată de o comunitate mare, orice standard trebuie să fie minimal. Pentru a putea fi utilizailă, conceptele și relațiile din cadrul ontologiei nu trebuie să fie complexe.

2.6. Rezumat

În acest capitol am descris trei noi tehnologii Web și am arătat modul în care acestea îmbunătățesc integrarea și accesul la informație. Web-ul asigură o cantitate vastă de date digitale, care pot fi consultate de utilizatori. Totuși, tehnicile ce utilizează criteriile de căutare bazate pe cuvinte cheie nu oferă rezultatul corect pentru o interogare și sunt limitate la informațiile prezente pe paginile web, fără a putea asigura o procesare a datelor. Aceste limite pot fi depășite prin descrierea formală a înțelesului paginilor web, ce pot fi procesate și interpretate de calculator, îmbunătățind astfel sarcinile de căutare și integrare a datelor. De asemenea, serviciile Web oferă posibilitatea accesării dinamice a serviciilor de procesare prin intermediul interfețelor Web, ducând astfel la o viziune generică a sarcinii ce trebuie îndeplinite. Totuși, descoperirea și integrarea acestor servicii Web trebuie realizată manual. Serviciile Web Semantice depășesc această limitare prin descrierea semantică a capacităților serviciilor Web. Pot fi create modele generice ale sarcinii de îndeplinit, care pot fi completate la momentul rulării prin utilizarea serviciilor Web potrivite.

CAPITOLUL 3

Semantici Software

În acest capitol sunt descrise o serie de concepte cheie pentru realizarea unei îmbunătățiri în cadrul Web-ului semantic, care se pot obține cu ajutorul semanticilor software, care stau la baza principiilor ontologice generale.

Achiziția unor anexe, adăugări textuale semantice este considerată problema cheie în realizarea Web-ului semantic. Aceasta se axează pe utilizarea conceptelor oferite de ontologii, fiind astfel necesară, în primul rând, o cunoaștere a acestora. Cu toate că ontologiile se dezvoltă de zeci de ani, Web-ul semantic impune modificări ale acestora, datorită câmpului larg de aplicabilitate și creșterii ritmului de schimbare. În cadrul acestei lucrări, se tratează problema achiziției de ontologii în cadrul unui context specific, cel al serviciilor Web. Există mai multe metode pentru achiziția ontologică, cum ar fi metodologiile care descriu etapele principale ce trebuie parcurse pentru proiectarea ontologiilor, precum și metodologii care se bazează pe cercetarea intensivă a principiilor filosofice, lingvistice și matematice fundamentale utilizate pentru îmbunătățirea calității ontologiilor. Aceste metode pot detecta, explica și corecta erorile frecvente din cadrul ontologiilor prin faptul că se bazează pe principii ontologice riguros studiate. În final, învățarea ontologiilor are ca scop derivarea automată a ontologiilor din bazele de date deja existente.

3.1. Semantici pentru serviciile Web

Tehnologiile semantice reprezintă o paradigmă nouă, o abordare ce tratează provocările unei infrastructuri axate pe rețele, pe automatizarea lucrului cu informațiile și cunoștințele și pe construirea sistemelor ce știu ceea ce fac.

Tehnologiile semantice sunt capacități funcționale care permit oamenilor și calculatoarelor să creeze, să descopere, să reprezintă, să organizeze, să proceseze, să gestioneze, să prezinte, să partajeze, să utilizeze și să raționeze cu interpratările și cunoștințele, pentru a putea îndeplini obiective de afaceri, personale și sociale.

Tehnologiile semantice sunt instrumente carereprezintă semnificații, asociații, teorii și cunoștințe referitoare la utilizarea seaparată a lucrurilor, pornind de la date, până la cod program. Această reprezentare a cunoștințelor se numește ontologie, un model semantic de informații disponibil la momentul execuției, și definit utilizând anumite construcții pentru:

Concepte – clase

Relații – proprietăți (obiecte și date)

Reguli – axiome și constrângeri

Instanțe ale conceptelor – date, fapte.

Modelele semantice prezintă unele asemănări și deosebiri față de alte modele IT:

La fel ca bazele de date, ontologiile sunt utilizate de aplicații la momentul execuției. Prin utilizare se înțelege interogarea și realizarea raționamentului. Spre deosebire de bazele de date convenționale, relațiile sunt construcții logice de ordinul întâi.

Ca și modelele obiectuale, ontologiile descriu clase și atribute, proprietăți. În schimb, ontologiile sunt dinamice și bazate pe o serie de reguli.

Asemenea regulilor de afaceri, modelele semantice codifică comportamentele bazete pe evenimente. Spre deosebire de acestea, ontologiile organizează regulile folosind axiome.

La fel ca shemele XML, ontologiile sunt elemente native pentru Web. Spre deosebire de schemele XML, ontologiile sunt grafuri, nu arbori și sunt utilizate pentru executarea raționamentelor.

Descrierile semantice îmbunătățesc realizarea, căutarea, descoperirea, accesul, partajarea, agregarea, înțelegerea și comunicarea informațiilor.

Figura 3.1. Capacități de interoperabilitate și raționament

Figura 3.1 descrie un spectru de capacități de interoperabilitate și de raționament, de la cercetare la cunoaștere:

De jos în sus, cantitatea, tipul și complexitatea metadatelor, modelării, contextului și a reprezentării cunoștințelor crește.

De la stânga la dreapta, capacitățile de raționament avansează de la (a) găsirea informațiilor pe baza metodelor statistice și lingvistice, la (b) descoperirea informațiilor neașteptate relevante și a asociațiilor prin tehnica de mining, la (c) inteligență bazată pe corelarea surselor de date, conectarea nodurilor și prezentarea informațiilor în context, la (d) răspunsul la întrebări, de la fapte simple, la suportul deciziei, și în final la (e) comportamente inteligente incluzând acțiuni autonome și adaptive.

Pornind din colțul inferior dreapta, spre cel superior stânga, diagrama prezintă un spectru de evoluție al categoriilor de reprezentare a cunoștințelor, cât și standardele și formalismele utilizate pentru a exprima metadatele, asociațiile, modelele, contextele și modurile de raționament.

Metadatele mai expresive și modelele semantice înlocuiesc formele mai simple și le extind capacitățile. Standardul Web OWL are o abilitate mare pentru reprezentarea glosarelor, a taxonomiilor, a vocabularelor și a semanticilor schemelor XML specifice, a schemelor bazelor de date, a relației entitate și a modelelor UML. În schimb, standardul OWL nu poate reprezenta întregul spectru al teoriei logicii, și nici alte tipuri de raționament mai evoluat. Dar există alte formalisme ce pot prezenta aceste capacități.

Pe măsura creșterii cantității descrierilor semantice și a expresivității lor, evoluează și capacitatea raționamentului implicat.

Utilizarea descrierilor semantice ale componentelor software a fost subiect de cercetare în cadrul ingineriei software pentru a asigura înțelegerea unui program sau proiectarea librăriilor software reutilizabile. Cu toate acestea, achiziția descrierilor semantice a constituit întotdeauna un stadiu critic ce încetinea dezvoltarea tehnicilor bazate pe semantică.

Printre metodele de achiziție automată a semanticilor, se enumeră și instrumentul GURU, care analizează documentația unui software bazată pe limbajul natural, care conține mai multe informații funcționale decât codul sursă sau comentariile explicative din cadrul acestuia. Această abordare utilizează o combinație de metode de găsire și de organizare a informațiilor. În prima etapă, se construiește un profil pentru fiecare document analizat, ce conține toți termenii relevanți ce definesc documentul. În a doua etapă, aceste profile sunt organizate utilizând metoda ierarhică nesupervizată, ierarhia rezultată fiind un arbore binar. Nodurile arborelui nu sunt denumite pentru că este imposibilă o predicție automată a numelui potrivit pentru fiecare. Librăria proiectată automat s-a dovedit a fi mai eficientă cu aproximativ 15% decât instrumentele care se bazează pe cunoștințele codate manual, referitoare la aceeași colecție software. Tehnica automată a fost combinată cu metode de analiză a codului, ca apoi să avanseze prin utilizarea tehnicilor de regăsire și recunoaștere a informației, dar care se limitau doar la substantivele din cadrul documentului, și se bazau pe prezența în aceeași frază a termenilor, în scopul reducerii relațiilor semantice existente între ele. În schimb, niciuna din aceste abordări nu construiește structuri taxonomice.

O subtemă a achiziției semanticilor pentru software o reprezintă achiziția semanticilor pentru serviciile Web. Crearea descrierilor semantice pentru serviciile Web este o sarcină ce consumă timp și care se dorește să fie realizată automat. Această sarcină poate fi împărțită în două. În primul rând, pentru crearea unei descrieri semantice a unui serviciu Web este necesară existența unei ontologii din domeniul serviciilor Web, în scopul realizării unei terminologii comune pentru descrierile semantice. În al doilea rând, trebuie asigurată îmbogățirea, adnotarea serviciilor Web cu diverse concepte oferite de ontologia domeniului. Acest lucru se poate realiza prin aplicarea tehnicilor de clasificare Naive Bayes în cadrul fișierelor WSDL (Web Service Description Language) sau în cadrul formularelor Web. De asemenea, se pot utiliza tehnicile de reprezentare sub formă de grafuri pentru a selecta ontologia din domeniu relevantă din cadrul unei colecții de ontologii.

3.2. Metode formale bazate pe ontologii

Pentru a putea fi folosite cu succes în cadrul sistemelor informatice, ontologiile trebuie să asigure semantici clare pentru conceptele din cadrul lor și o bună formalizare a acestor semantici. Aceste cerințe sunt importante în special pentru serviciile Web semantice, ale căror descrieri ontologice trebuie să fie utilizate pentru realizarea raționamentelor.

OntoClean este o metodologie pentru validarea relațiilotr taxonomice și se bazează pe noțiunile ontologice generice referitoare la identitate și unitate. Prin utilizarea OntoClean este posibilă detectarea și corectarea erorilor frecvente de modelare, cum ar fi confuziile dintre includere și instanțiere sau de tipul partOf.

DOLCE folosește noțiuni ontologice general valabile din filosofie, lingvistică și matematică. Ontologia DOLCE și metodologia OntoClean sunt folosite pentru evaluarea calității categoriilor de substantive din WordNet, o bază de date lexicală ce modelează relațiile dintre cuvinte. Se execută o transformare directă a conceptelor WordNet în concepte din ontologia DOLCE și se aplică rigurozitatea impusă de OntoClean. Prin utilizarea acestor metode s-au descoperit o serie de probleme ale WordNet. S-a observat confuzia dintre elemente ontologice diferite, dintre concepte și entități, precum și o slabă precizare a nivelelor de generalitate din cadrul unei familii de cuvinte.

Lucrarea de față tratează alinierea OWL-S la DOLCE, pentru validarea și îmbunătățirea calității OWL-S.

3.3. Învățarea ontologiilor

Scopul metodelor de învățare a ontologiilor este de a deriva automat structuri conceptuale din diverse tipuri de date nestructurate, semistructurate sau complet structurate. Cercetarea învățării ontologiilor a cuprins multe discipline, cum ar fi lingvistica computațională, machine learning, bazele de date, ingineria software. Totuși, în ultimul timp termenul de ontologie este cel mai des utilizat în contextul cercetăriilor privind Web-ului Semantic.

O caracteristică importantă a abordărilor învățării ontologiilor o reprezintă tipul datelor de intrare pe care se bazează, care au o influență fundamentală asupra metodei de învățare utilizate. Majoritatea abordărilor existente învață o ontologie utilizând surse textuale. O subcategorie a abordărilor bazate pe text sunt cele care procesează dicționarele ce pot fi citite de calculator (machine readable dictionaries MRD) pentru a deriva unele structuri conceptuale. În ultimul timp, se observă că învățarea ontologiilor se bazează pe datele, uneori redundante, care se găsesc pe Web. Alte metode pentru învățarea ontologiilor folosesc baze de cunoștințe, scheme semistructurate și relaționale.

Se pot avea în vedere mai multe posibilități pentru a decide care surse de date sunt potrivite pentru învățarea ontologiilor din domeniul serviciilor Web. În primul rând, resursele conectate la implementarea serviciului ar putea asigura cunoștințe utile despre funcționalitatea serviciului Web, ținând cont de faptul că serviciile Web sunt produse software simple ce pot fi accesate prin intermediul Web-ului. La fel sunt și codul sursă, documentațiile sale textuale și diagramele UML existente. În al doilea rând, se pot utiliza sursele de date specifice serviciilor Web, cum ar fi fișierele WSDL sau logurile de activitate. Un criteriu important pentru alegerea unei surse de date pentru metoda de învățare a unei ontologii îl reprezintă disponibilitatea acesteia. S-a observat că serviciile Web sunt aproape întotdeauna însoțite de o scurtă descriere textuală a funcționalității lor, lucru care îl ajută pe utilizator să înțeleagă ce realizează, ce face serviciul respectiv. Există descrieri de acest tip în “depozitele” online ale serviciilor Web, spre exemplu Xmethods. În mod asemănător, descrierile javadoc ale metodelor oferă detalieri succinte ale funcționalității, documentațiile API (Application Programming Interface) fiind disponibile mai frecvent decât codul sursă.

3.3.1. Metode pentru învățarea ontologiilor bazate pe text

Au fost dezvoltate o serie de metode pentru învățarea ontologiilor utilizând surse textuale. Aceste metode se bazează pe tehnici care utilizează tipare și reguli de asociere sau metode de organizare. Abordarea adoptată în lucrarea de față pentru învățarea ontologiilor din domeniul serviciilor Web este motivată de faptul că sursele textuale atașate serviciilor Web conțin informații importante pentru proiectarea ontologiilor și că ele utilizează limbajul natural într-un mod specific. De fapt, aceste texte aparțin unui sublimbaj, o formă specializată a limbajului natural. Date fiind aceste caracteristici ale textelor, în lucrarea prezentă s-a ales utilizarea tehnicilor bazate pe tipare, structuri și modele pentru învățarea unei ontologii. Tehnicile bazate pe modele sunt utilizate în aplicațiile de procesare a limbajului natural. Au fost folosite pentru a deriva relațiile semantice din cadrul unei colecții de texte.

A fost introdusă ideea învățării relațiilor de derivare a unei familii de cuvinte prin utilizarea tiparelor lexico-sintactice, definite prin informații lexicale și sintactice de bază. Astfel, se permite extragerea relațiilor după o procesare superficială a textului. Astfel de tipare sunt relevante pentru învățarea ontologiilor. Totuși, deși astfel de tipare generale sunt potrivite pentru o colecție de documente cu informații generale, pentru un anumit domeniu sau câmp de activitate nu se dovedesc a fi cea mai bună alternativă. De aceea, se preferă alegerea tehnicilor bazate pe modele, care permit și o extrapolare a domeniului de acțiune.

3.3.2. Instrumente pentru învățarea ontologiilor

În anul 2006, înaintea demarării propriu-zise a lucrării, s-au identificat 18 instrumente pentru învățarea ontologiilor urilizând surse textuale. Aceste unelte implementează o serie de metode diferite, cum ar fi tehnicile dee organizare, în cazul ASIUM, sau tehnicile bazate pe tipare și modele, pentru CAMELEON. Scopul lucrării este de a reutiliza metodele existente de învățare a ontologiilor în contextul serviciilor Web. În momentul elaborării lucrării, doar trei dintre instrumente puteau fi downloadate, dintre care cel mai util îl reprezenta TextToOnto.

TextToOnto reprezintă un mediu de lucru pentru învățarea ontologiilor, ce oferă un set de algoritmi ce pot fi combinați în scopul proiectării unei ontologii. În particular, acest mediu de lucru oferă module pentru identificarea conceptelor, învățarea relațiilor taxonomice și extragerea relațiilor binare generice prin utilizarea regulilor de asociere. Ontologia învățată este prezentată vizual, folosind tehnica de vizulaizare TouchGraph. Prin utilizarea TextToOnto, au putut fi experimentați o serie de algoritmi de bază. Totuși, particularitățile colecției de documete au dus la o performanță suboptimală a metodelor implementate. Una dintre problemele majore a fost aceea că setul de documente conținea un sublimbaj specific documentațiilor software, care este diferit de cel folosit în textele cu caracter general. TextToOnto a constituit, în ciuda acestei probleme, baza efortului din lucrarea de față, care încearcă să rezolve aceast inconvenient.

OntoLT este un plugin care permite extragerea rapidă de ontologii de domeniu cu ajutorul unui set de reguli de transformare definite în termeni de interogări XPATH aplicate asupra adăugărilor lingvistice bazate pe XML. În prezent, acest instrument conține două transformări definite, ce pot fi citite. Prima permite învățarea relațiilor taxonomice pe baza informațiilor din cadrul sintagmelor substantivale. A doua mapare extrage poziții din cadrul unui fișier care conțin înregistrări singulare de cuvinte. Potrivit acestei transformări, un predicat devine o astfel de înregistrare, și are ca domeniu subiectul său și ca obiect, raza sa de acțiune. În funcție de cerințele utilizatorului, pot fi construite și alte transformări. Ontologia astfel aflată este prezentată în mediul Protege. Fiecare structură învațată, respectiv slot, conține informații detaliate despre proveniența sa, spre exemplu, părțile din documentul în care a fost identificat și regula care a dus la identificarea sa.

Figura 3.2.OntoLT

Text2Onto este succesorul lui TextToOnto, și oferă un set extins de algoritmi de învățare a ontologiilor. Text2Onto aduce predecesorului său numeroase îmbunătățiri. În primul rând, se bazează pe Modelul Probabilistic al Ontologiei, care permite combinarea rezultatelor diverșilor algoritmi de procesare și reprezentarea probabilităților pentru structurile învățate. În al doilea rând, interfața este îmbunătățită. Construcțiile învățate sunt listate ordonat în funcție de probabilitățile de corectitudine sau sunt reprezentate utilizând o componentă vizuală bazată pe grafuri. Alt avantaj al Modelului Probabilistic îl constituie posibilitatea de urmărire a extracției: fiecare structură învățată este stocată împreună cu un set de pointeri către părțile documentului de unde a fost extrasă. În final, Text2Onto implementează un mecanism de descoperire a schimbărilor datorate datelor, care permite înnoirea modelului ontologiei pe baza schimbărilor din datele care sunt fundamental acestei ontologii, fără să fie necesară execuția întregii extrageri, pornind de la zero. Acest lucru asigură eficiența și permite utilizatorului să urmărească evoluția ontologiei pe baza schimbărilor datelor de intrare.

Figura 3.3. Arhitectura Text2Onto

3.3.3. Probleme în învățarea ontologiilor

Odată cu dezvoltarea Web-ului semantic, s-a observat necesitatea existenței ontologiilor în multiple domenii. Acest lucru a mărit cererea soluțiilor de învățare a ontologiilor, care să poată fi utilizate în domenii noi, diferite. Spre exemplu, contextul serviciilor Web reprezintă un nou domeniu de aplicare pentru învățarea ontologiilor. Aceste domenii specializate au unele caracteristici, cum ar fi:

Texte cu caracteristici speciale. Textele care descriu cunoștințele dintr-un anumit domeniu au uneori o serie de caracteristici deosebite. Cel mai des, acestea utilizează limbajul natural într-un mod specific, un sublimbaj. Acest lucru este valabil și în domeniul serviciilor Web.

Cerințe clare pentru rezultatele unei metode de învățare. Într-un domeniu anume, este adeseori clar tipul de cunoștințe necesare, ce trebuie extras din cadrul documentului. Aceste cunoștințe sunt uneori mai specializate decât structura semantică extrasă de un algoritm general. Spre exemplu, în cazul serviciilor Web, este știut faptul că trebuie învățate atât conceptele din domeniu, cât și ierarhiile funcționalităților.

Dezvoltatorii și utilizatorii instrumentelor de învățare a ontologiilor sunt rareori experți în ingineria ontologiilor.

Aceste caracteristici extind câmpul de cercetare al învățării ontologiilor cu unele elemente cum ar fi:

Adaptabilitatea. Caracteristicile speciale ale setului de documente analizate din domeniile date, cât și cerințele clare referitoare la cunoștințele ce trebuie extrase, solicită adaptarea metodelor existente de învățare a ontologiilor. Această nevoie de adaptare este rezolvată de OntoLT, care oferă un mediu de lucru general pentru definirea regulilor de extragere bazate pe modele dintr-un anumit domeniu. Pentru a întâmpina cerințele dezvoltatorilor care nu sunt experți în soluții de învățare a ontologiilor, este nevoie de metode ce pot fi ușor adaptate și combinate, cât și de un ghid asupra modului de implementare a unei soluții de învățare a unei ontologii dintr-un domeniu.

Evaluarea. Evaluarea rămâne o problemă importantă pentru învățarea ontologiilor în general. Dat fiind faptul că se dezvoltă metodologii diferite, este greu să se definească metrici de evaluare unitare. Acest lucru este și mai dificil în cazul domeniilor specializate, când nu sunt colectate seturi de documente, nu este clar ce standard ar trebui utilizat și nu există nici un element de comparație.

Utilizabilitatea. Învățarea ontologiilor este în principiu un proces de transfer al cunoștințelor, din cunoștințele din domeniu, așa cum sunt ele percepute de oameni, în modele formale care pot fi raționate și înțelese de calculator. Metodele de învățare a ontologiilor implică mai multe stadii. În principiu, acestea extrag termenii din setul de documente, apoi îi combină și îi transformă în elemente sau concepte ontologice. Astfel, este esențial, atât în timpul dezvoltării cât și al utilizării instrumentelor de învățare, ca structurile de cunoștințe implicate în aceste procese și relațiile existente între acestea, să fie facil înțelese de utilizatorii umani. Este important să se îmbunătățească utilizabilitatea instrumentelor de învățare a ontologiilor.

3.4. Rezumat

În acest capitol, am realizat o scurtă prezentare a câmpurilor de cercetare care sunt importante pentru lucrarea de față. În domeniul ingineriei software, am descris eforturile depuse pentru dobândirea unor descrieri semantice automate ale componentelor software.

Pentru ingineria ontologică, am avut în vedere atât metodele bazate pe principii ontologice, care au ca scop îmbunătățirea calității ontologiilor existente, cât și metodele de învățare a ontologiilor menite să dezvolte învățarea unei ontologii prin învățarea automată a unor ontologii simple. Utilizarea metodelor ontologice are aplicații în îmbunătățirea calității ontologiilor din domeniul serviciilor Web generale. Învățarea unei ontologii poate fi folosită pentru a susține proiectarea ontologiilor de domeniu. În acest scop, metodele de învățare a ontologiilor trebuie adaptate la contextul serviciilor Web.

CAPITOLUL 4

DAML-S

În acest capitol, ținând cont de faptul că o ontologie din domeniul serviciilor Web este calificată în funcție de gradul de expresivitate și utilizabilitate, este analizat DAML-S, limbajul de specificare al serviciilor Web, din aceste două perspective. În urma testărilor pentru modelarea unor servicii din ce în ce mai complexe, DAML-S s-a dovedit a fi puțin expresiv și utilizabil. Lucrarea încearcă să îmbunătățească ambele aspecte privind DAML-S. În primul rând, sunt identificate o serie de limitări și sunt date soluții pentru eliminarea acestora, extinzând astfel expresivitatea ontologiei. Pentru a ajuta la îmbunătățirea ontologiei de către dezvoltatori, sunt date unele exemple de modelare.

Orice servicii Web trebuie descrise prin utilizarea unei ontologii generice din domeniul serviciilor Web, independent de domeniul acestora. Există doi factori cheie pentru adoptarea unei astfel de ontologii. Acesta trebuie să fie îndeajuns de expresivă încât sa permită modelarea unui câmp vast de servicii. Este de asemenea necesară și existența unor ghiduri de modelare pentru a asigura învățarea cât mai facilă a unei ontologii.

DAML-S este utilizat pentru a descrie servicii din mai multe domenii. Spre exemplu, a fost utilizat pentru a descrie servicii din viața reală, cum ar fi tehnologiile agent, sau domeniul bioinformaticii, dar și servicii matematice sau de e-commerce, cum ar fi cel de conversie monetară sau o descriere a serviciului Amazon. În momentul demarării acestei lucrări, DAML-S avea o documentație redusă, asigurând astfel o slabă utilizabilitate. Cu toate că se constituia întru-un standard pentru adăugările textuale la serviciile Web, am putut observa doar câteva descrieri complete ale serviciilor, și foarte puține lucrări care discutau problemele tehnice referitoare la procesul de adăugare a documentațiilor. Am încercat rezolvarea acestor probleme prin prezentarea unei serii de descrieri reale pentru serviciile Web.

Acest capitol descrie la început aplicația care prezintă exemple de servicii, ca apoi să detalieze modalitatea de modelare în cazul a trei servicii complexe, de tipul Sesame, care reprezintă o bază de date RDF, cât și un motor de interogări. Astfel, poate constitui un punct de pornire, un fundament pentru aplicațiile bazate pe ontologii. Sesame poate fi utilizat ca și parte a unei aplicații sau poate fi accesat prin intermediul unei interfețe web.

4.1. Funcționarea unor servicii Web

Am ales pentru descriere proiectul care utilizează tehnologia Web-ului Semantic pentru a construi un portal al publicațiilor științifice pornind de la fișiere BibTex. Figura prezintă modul de înlănțuire tipică a serviciilor.

Figura 4.1. Serviciile Web utilizate pentru realizarea unor portale bibliografice

Etapele funcționării serviciilor:

Translația datelor. Prima oară, fiecare document BibTex disponibil este transformat în fișier RDF, utilizând serviciul Bib2Rdf, apoi este salvat într-un modul ce conține o bază de date RDF, care poate fi accesată prin intermediul Web-ului, cât și un motor de interogare, modul numit Sesame.

Detectarea duplicatelor. În urma procesului de contopire a datelor deseori rezultă redundanțe, datorită faptului că proprietarii bibliografiilor folosesc resurse sintactice diferite pentru a preciza același autor. Am utilizat conceptul AcelașiCaȘi din DAML pentru a codifica aceste redundanțe și am extins capacitățile de a raționa ale Sesame astfel încât să poată interpreta această sintagmă. Serviciul SIA (SameIndividualAs) asigură o bază automată pentru a găsi resursele care se referă la aceeași persoană. Utilizând tehnicile de machine learning pe sursele RDF, SIA poate extrage resursele care se pot referi la aceeași persoană și furnizează tupluri de resurse similare. De aceea, al doilea pas constă în obținerea tuturor datelor din Sesame cu ajutorul serviciului Esesame, transmiterea acestora către SIA, onținerea fișierului care conține termenii redundanți și salvarea dinj nou în Sesame prin utilizarea serviciului I-sesame.

Realizarea afișajului. În final, un software, ce realizează portaluri, crează portalurile de publicații prin interogarea serviciului Sesame.

Aceste servicii Web pot fi combinate în mai multe moduri, în funcție de datele de intrare și de cerințele utilizatorului. Spre exemplu, dacă fișierele de date sunt deja în format RDF, transformarea Bib2Rdf nu mai este necesară. Dacă datele provin dintr-o singură sursă de date, nu mai este executată etapa de detectare a duplicatelor. Or dacă datele se află deja în baza de date Sesame, acestea nu mai sunt stocate. Tehnologia serviciilor Web Semantice încearcă să automatizeze o astfel de compunere a unor servicii adaptive, prin utilizarea raționamentului în cadrul descrierilor serviciilor și ale cerințelor.

4.2. Modelarea unui serviciu simplu Bib2Rdf

Primul serviciu prezentat care utilizează DAML-S este Bib2Rdf. Bib2Rdf reprezintă un serviciu simplu, care transformă un fișier BibTex într-o reprezentare RDF. Serviciul preia ca date de intrare URL-ul unui document BibTex și redă codarea RDF a acestor date. Cu toate că este un serviciu simplu, prin modelarea acestuia utilizând DAML-S am putut observa o divergență între părțile descrierii referitoare la Profilul_Serviciului și cele referitoare la Modelul_Serviciului. Deși ne-am putea aștepta ca parametrii de un anumit tip ai profilului să se refere la parametrii de același tip ai procesului, acest lucru nu este întotdeauna valabil. Cu specificațiile curente, se poate realiza o legătură între parametrii de tipuri diferite. Deoarece ontologia de proces nu modelează precondițiile și efectele ca fiind subproprietăți ale parametrilor procesului, utilizarea unor astfel de entități pentru valori ale profilului care se referă la ele nu are nici un rezultat. Astfel, precondițiile și efectele definite în cadrul profilului nu se pot referi la precondițiile și efectele corespondente din cadrul procesului, deoarece nu sunt incluse printre acestea cu ajutorul legăturii refersTo. Ontologia de proces poate referi aceste definiții prin folosirea unui set de proprietăți. Raționamentul care stă la baza acestei modelări este acela că atât partea de profil, cât și cea de proces din cadrul unei descrieri se referă la aceleași instanțe ale datelor de Intrare, IeșireCondiționată, Precondiție și Efect Condiționat și că instanțele declarate în profil constituie o submulțime a celor declarate în proces. Prin această soluție, nu vor mai apărea duplicate ale instanțelor în ambele modele. De asemenea, deoarece ambele modele utilizează aceleași instanțe, se rezolvă problema transformării dintr-o ontologie de profil în una de proces.

Figura 4.2. Noua modalitate de a modela legătura dintre Profil și Proces

Diferența conceptuală dintre Intrări și Ieșiri, pe de o parte, și Precondiții și Efecte, pe de cealaltă parte a fost păstrată și în noul model. Această diferență rezultă din cele două puncte de vedere referitoare la funcționalitatea serviciului. Funcționalitatea unui serviciu poate fi privită ca un proces de transformare a informațiilor care este definit prin parametrii Intrare și Ieșire. În altă ordine de idei, pentru a descrie modificările la scară largă cauzate de execuția unui serviciu este mai util să definim Precondițiile și Efectele, și anume stările care trebuie îndeplinite înainte de executarea serviciului și, respectiv, stările de după execuția acestuia. Urmând acest raționament, Intrările și Ieșirile sau Rezultatele sunt grupate sub conceptual de Parametru.

4.3. Modelarea unui serviciu cu interfețe multiple SIA

Serviciul SIA (Same Individual As – Același Ca Și) este în principiu la fel de simplu ca serviciul Bib2Rdf. Acționează asupra unui fișier RDF, determinând care sunt resursele ce pot să refere aceeași persoană și returnează un fișier RDF cu tupluri care conțin resurse echivalente. Singurul element complex este acela că serviciul poate ajunge la un fișier RDF prin mai multe moduri: prin citirea sa dintr-un URL, prin acceptarea datelor propriu-zise transmise în formatul unui șir de caractere sau prin citirea datelor dintr-o bază de date Sesame, dând numele acesteia și informațiile de logare. Această situație este similară aceleia de polimorfism, aceleia de supraîncărcare: o anumită metodă permite existența mai multor semnături, dar în principiu are aceeași funcționare. Serviciul SIA își execută funcția, cea de recunoaștere a a duplicatelor, independent de setul de parametri transmiși.

Documentația disponibilă pentru DAML-S oferă foarte puține informații despre modul de modelare a acestei situații. Se pot utiliza mai multe interfețe, în cazul în care numărul de argumente este același și acestea sunt precizate în aceeași ordine, numai că au tipuri diferite. Soluția propusă este de a defini un concept care să aibă un grad mai mare de acoperire a tipurilor de date posibile. Totuși, această abordare nu rezolvă problema în cazul unui număr mai mare de argumente.

O soluție simplă ar putea fi aceea de a trata fiecare interfață alternativă ca fiind un serviciu diferit, separat. Din motive care țin de latura conceptuală, practică, această soluția a fost refuzată. La nivel conceptual, este descris același serviciu de mai multe ori. Dacă le separăm, în servicii diferite, DAML-S nu poate identifica faptul că de fapt este vorba despre același serviciu. Cunoașterea faptului că un serviciu sau descrierea acestuia se află în relație cu un alt serviciu sau descriere, sau că acestea sunt identice, reprezintă un factor important în alegerea serviciilor. Din punct de vedere practice, adnotarea unui serviciu este o sarcină care consumă foarte mult timp, chiar și fără efectuarea acesteia pentru fiecare interfață posibilă. Am încercat mai multe alternative pentru a putea găsi semantica ce ar permite o potrivire mai inteligentă și ar putea să aibă mai multe interfețe cu tipuri de date diferite și cu un număr distinct de parametric. Prima variantă, SIA1, se bazează pe un design de tipul top-down, pornind de la modelul serviciului până la baza acestuia. Datorită problemelor întâmpinate, SIA2 are o abordare bottom-up, ce pleacă de la definiția WSDL. SIA2 a clarificat modul în care DAML-S consideră un serviciu ca fiind mai bine definit de Intrările și Ieșirile sale, decât de efecte. SIA3 a fost dezvoltat în perspectiva serviciului ca un proces compus, și nu atomic, care implică cititoare și translatoare de date. Totuși , aceste descrieri nu s-au dovedit a fi soluții valide ale problemei, fie pentru că erau greșite din punct de vedere conceptual, fie pentru că nu puteau fi specificate prin utilizarea DAML-S și WSDL. În final, SIA4 a fost compromisul care constituie o soluție valabilă, dar care nu reprezintă complet modelul conceptual al unui serviciu. De asemenea, a fost necesară repetarea unor descrieri.

4.3.1. Modelul final SIA4

Acest model a fost dezvoltat în urma experiențelor anterioare și a limitărilor DAML-S, acest model a fost considerat ca fiind optim în cazul problemei interfețelor multiple, cu un număr variabil de parametri. Această problemă a fost rezolvată prin modelarea unui singur serviciu cu trei profile diferite, Pr1, Pr2, Pr3, fiecare descriind una dintre cele trei funcționalități diferite ale serviciului. Acest lucru indică faptul că serviciul poate executa unul dintre aceste trei procese atomice P1, P2, P3. Aceste procese sunt transformate în operații WSDL.

Serviciul SIA4:

*Profil:Pr1 (areProcesul=P1)(I(url),O(RdfFile))

*Profil:Pr2 (areProcesul=P2)(I(RdfStream),O(RdfFile))

*Profil:Pr3 (areProcesul=P3)(I(server),I(url),I(psw),I(ln),O(RdfFile))

*Modelul Procesului:

CompositeProcess: CP:Choice

{

ProcesAtomic:P1(I(RdfStream),O(RdfFile))}

ProcesAtomic:P2(I(RdfFile),O(RdfFile))}

ProcesAtomic:P3(I(server),I(url),I(psw),I(ln),O(RdfFile))}

}

*IncheiereWSDL:

ImplementareaProcesuluiAtomicWSDL: Gr1 (P1->op1)

ImplementareaProcesuluiAtomicWSDL: Gr2 (P2->op2)

ImplementareaProcesuluiAtomicWSDL: Gr3 (P3->op3)

Modelul final nu este unul satisfăcător, deoarece procesele P1, P2, P3 nu pot fi modelate ca procese compuse, lucru care ar reflecta mai bine structura serviciului. De asemenea, necesarul de efort pentru asigurarea și mentenanța acestui set dens de constrângeri se dovedește a fi destul de mare. În timp ce la nivelul superclasei Serviciu există o singură definiție, care este corectă din punct de vedere conceptual, documentul este cel mai restâns dintre toate. Repetițiile existente în cadrul documentelor referitoare la Profil și Implementare sunt supărătoare. Bineînțeles că prin operația de cut-paste se reduce considerabil munca, iar mentenanța este ușor asigurată prin definirea conceptelor într-un singur document și asignarea unor pointeri către acestea din cadrul celorlaltor două documente. Totuși, acest model se dovedește a fi unui viabil, deoarece prin adăugarea semanticilor într-un mod care poate fi înțeles și ușor de utilizat, se poate asigura o mai bună precizie a ontologiei și modelul poate fi compatibil cu alte modele care sunt dezvoltate pentru reprezentarea aceluiași serviciu.

4.4. Modelarea unui serviciu complex – Sesame

DAML-S este utilizat pentru a descrie servicii din mai multe domenii. Spre exemplu, a fost utilizat pentru a descrie servicii din viața reală, cum ar fi tehnologiile agent, sau domeniul bioinformaticii, dar și servicii matematice sau de e-commerce, cum ar fi cel de conversie monetară sau o descriere a serviciului Amazon. Totuși, nu s-a realizat o descriere a instrumentelor de Web Semantic, cu toate că numărul acestora este în continuă creștere. Pentru a acoperi acest gol, am utilizat ontologia DAML-S și WSDL pentru a descrie un instrument tipic pentru Web-ul Semantic, și anume Sesame. Sesame are anumite caracteristici care nu mai apar în cadrul altor servicii anterioare, din acest motiv modelarea sa nu s-a dovedit a fi deloc ușoară. Sesame are o arhitectură modulară, alcătuită din componente independente, ce pot fi utilizate în combinații arbitrare pentru îndeplinirea anumitor sarcini. În contrst cu acest lucru, serviciile Web, chiar dacă sunt modulare, au o structură bine definită a ciclului de funcționare și componentele lor nu pot fi utilizate separat. Sesame utilizează tipuri complexe de date, fiind necesară o modificare a modului de a percepe intrările și ieșirile ca și valori atomice. De asemenea, în cadrul Sesame există o serie de constrângeri între parametrii de Intrare și de Ieșire. Această parte a capitolului încearcă să demonstreze faptul că DAML-S poate fi considerat destul de expresiv pentru a modela particularitățile serviciului Sesame, dar prezintă și o serie de limitări care pot apare.

4.4.1. Descrierea serviciului Sesame

Sesame reprezintă o bază de date RDF, Rich Definition Format, cât și un motor de interogări. Astfel, poate constitui o bază importantă pentru aplicațiile bazate pe ontologii. Poate fi utilizat ca și parte a unei aplicații sau poate fi accesat prin intermediul unei interfețe web. Sunt disponibile protocoalele de comunicații HTTP și SOAP. Interfața HTTP a Sesame permite șase funcționalități distincte la șase URL-uri diferite. Aceste funcționalități sunt prezentate pe scurt, incluzând între paranteze extensiile URL unde acestea sunt publicate.

Un server Sesame conține o serie de depozite de date care sunt protejate prin parole. Aceste magazii de date, deși sunt considerate publice, pot fi accesate doar după introducerea informațiilor de logare. Pin intermediul interfeței serverului HTTP, se poate solicita o listă a tuturor magaziilor care sunt disponibile pentru anumite informații de intrare, inclusiv magaziile publice (listRepositories). Ca o facilitate de stocare, Sesame oferă funcția de transfer al datelor și de interacțiune cu acestea. Funcția de transfer al datelor adaugă date care au un URL specificat sau transmis sub forma unui șir de caractere (addData). Conținutul unei magazii de date poate fi șters în întregime (clearRepository). De asemenea, este permisă ștergerea la nivel de propoziție (removeStatement). Utilizatorul poate extrage întregul conținut al unei magazii de date (extractRDF) sau numai informațiile schematice, pe cele referitoare la instanța sau ambele. O metodă de extragere a datelor rafinate, metoda de interogare (performRQLQuery și performRDQLQuery), transformă serviciul Sesame într-un motor de interogări. Nu există un mod predefinit de utilizare a acestor funcționalități. De fapt, ele pot fi utilizate independent, mai degrabă decât în combinație cu alte funcționalități.

4.4.2. Cerințe de modelare

La nivel conceptual, trebuie specificată semantica funcționalității asociate unui serviciu. Există mai multe moduri pentru realizarea acestei cerințe. Se poate specifica serviciul prin descrierea parametrilor săi. De asemenea, interpretarea unui serviciu depinde de relația sa cu alte servicii. Este de dorit să existe o descriere a modului în care aceste componente interacționează unele cu altele, astfel încât serviciile inteligente să poată determina tipare de folosire pentru îndeplinirea anumitor sarcini. Una dintre dependențele ce pot exista între servicii este aceea de compunere, caz în care un serviciu este compus din maui multe alte servicii. Acesta este și cazul Sesame.

Altă problemă o constituie legătura ce trebuie să existe între descrierile sintactice și cele semantice ale unui serviciu. Este de dorit ca o singură descriere conceptuală să fi transformată în descrieri a mai multor implementări tehnice ale aceluiași serviciu. În cazul Sesame, ar trebui să fie posibilă o descriere semantică, pe baza descrierilor sintactice ale diverselor interfețe (HTTP, SOAP, RMI). De asemenea, descrierile tehnice utilizate împreună cu cele semantice necesită o serie de schimbări minore pentru a putea fi utilizate de instrumente care nu necesită date semantice.

4.4.3. Specificarea Semanticii Serviciului

Pentru a satisface diversele cerințe ale furnizorilor de servicii, DAML-S nu impune un stil de modelare obligatoriu, lucru ce duce la existența unui gol între considerațiile conceptuale și modelarea reală. Acest lucru se întâmplă chiar și în cazul noțiunii de serviciu, care este definit conceptual ca fiind un site Web care permite unei persoane să efectueze anumite acțiuni sau să modifice anumite lucruri din domeniul său. Apoi, serviciile sunt împărțite în servicii simple și complexe. Un serviciu simplu necesită un singur program ce trebuie să fie accesibil prin intermediul Web-ului și nu există nici o interacțiune cu utilizatorul în timpul execuției sale. Un serviciu complex este alcătuit din mai multe servcii simple. Sesame este un serviciu complex, dacă privim fiecare funcționalitate a sa ca fiind un serviciu simplu. În continuare, sunt prezentate două alternative pentru modelarea serviciului Sesame.

Prima alternativă de modelare

Utilizează stilul de modelare folosit în exemplele DAML-S. Am creat o singură instanță a serviciului Sesame. Funcționalitățile componente au fost modelate ca fiind procese atomice P în cadrul modelului de proces P. Deoarece nu există nici o structură de lucru implicită între elementele componenete ale serviciului Sesame, cele șase funcționalități putând fi utilizate în moduri arbitrare pentru a rezolva anumite sarcini, modelul de lucru care era cel mai apropiat de cerințele date era proces:Alegere. Acest lucru exprimă foarte vag legătura dintre componente, iar valoarea sa semantică este mică. Am încercat compensarea acestui lucru la nivelul profilului Pr, când am asociat mai multe instanțe ale profilului cu serviciul respectiv, câte unul pentru fiecare funcționalitate a sa și unul pentru funcționalitatea globală a serviciului (P reprezintă un DepozitOntologic). În final, baza lui Sesame G conține șase baze ale proceselor atomice g1…g6, câte una pentru fiecare proces intern cu operația corespunzătoare WSDL o1…o6.

Figura 4.3. Modelarea tradițională a serviciului Sesame

Această abordare are unele limitări. Unele servicii simple ofereau interfețe și implementări alternative. Deaoarece numai conceptul de Serviciu poate avea diferite baze, care nu sunt procese atomice, implementarea diferită a serviciului atomic duce la o bază diferită pentru întregul serviciu. De aceea, avem de a face cu o multitudine combinatorică de baze pentru serviciul general de fiecare dată când o componentă oferă o nouă implementare. La nivelul de profil, de asemenea, nu există nici o indicație asupra relațiilor ce există între cele șapte servcii. Deși toate serviciile sunt vizibile în momentul realizării corespondenței, deoarece profilul lor este menționat explicit, este necesară o interpretare a întregii descrieri a serviciului complex la utilizarea unui serviciu simplu.

Acest stil de descriere funcționează foarte bine în cazul serviciilor Web compuse din servicii simple, care nu au și alte înțelesuri în afara cadrului serviciului și sunt utilizează conform ciclului de lucru predefinit. În astfel de cazuri, un singur profil este suficient pentru descrierea sarcinii globale care poate fi realizată prin executarea lor. Totuși, niciuna dintre aceste presupuneri nu se aplică în cazul lui sesame, deoarece funcționalitățile sale pot fi utilizate în orice combinație sau de sine stătătoare.

A doua alternativă de modelare

Datorită concluziilor anterioare, am decis modelarea fiecărei funcționalități ca fiind un serviciu separat S1 … S6. Două dintre limitările modelului anterior sunt astfel rezolvate, prolema declarării unei noi implementări a unui serviciu simplu este redusă la declararea unei singure baze atomice, iar, la utilizarea unui serviciu, trebuie interpretată numai descrierea sa. Totuși, rămâne problema modului în care aceste grupe de servicii inter-relaționează. Astfel, am ales ca o grupă de servicii să poată fi utilizată pe un anumit server sesame. În funcție de serviciile utilizate, serverele Sesame pot fi de tipuri diferite, unele putând oferi posibilități de stocare (Ontology Store Sesame 2), altele posibilități de interogare (QueryEngine), iar altele, ambele facilități (OntologyStore și QueryEngine Sesame 1).

Figura 4.4. Modelarea propusă pentru Sesame

În cadrul ontologiei propuse din domeniu, se face o diferență între unelte și funcționalitățile lor și se definesc instrumentele în funcție de funcționalitățile oferite. În termeni de modelare, acest lucru implică existența a două construcții inter-relaționate. În primul rând, profilul DAML-S este specializat în instrumentul SW și funcționalitatea sa. Subclasele primului concept reflectă principalele unelte existente în domeniul Web-ului semantic. Al doilea concept este cel al superclasei pentru toate funcționalitățile. În principiu, am declarat tipurile de funcționalități considerate relevante pentru Sesame și le-am grupat într-un concept mai general. Spre exemplu, metodele RetrieveOntology (GăseșteOntologia) și AskQuery (ExecutăInterogarea) sunt metode pentru aflarea datelor. Superclasa RetrieveData (GăseșteDatele) poate fi extinsă cu alte metode specifice instrumentelor care execută aceleași funcții. Am îndeplinit cerințele unei ontologii din domeniu care e frecvent utilizată, descrisă prin prezentarea de mai jos.

SursadeDate

Format

Parolă

* Damls:Profil

Funcționalitate

RemoveData

RemoveOntology

RemoveStatement

RetrieveData

AskQuery

RetrieveInstances

RetrieveOntology

StoreData

SWTool

OntologyMerge

OntologyStore

QueryEngine

Reasoner

Magazie de date

Utilizator

Utilizarea cunoștințelor din domeniu în cadrul descrierilor DAML-S

Conceptele din domeniu sunt utilizare din mai multe motive în cadrul descrierilor DAML-S. În primul rând, ele exprimă înțelesul funcționalității oferite la nivel de profil. În al doilea rând, cunoștințele din domeniu pot fi folosite pentru a descrie instanțele atât la nivel de profil, cât și de proces.

Se poate indica funcționalitatea unui serviciu prin declararea profilului său ca fiind de tipul care este documentat în cadrul ontologiei din domeniul respectiv. La modelarea unui instrument care oferă mai multe funcționalități, sunt modelate atât instrumentul, cât și funcționalitățile sale ca fiind servicii. Faptul că ele reprezintă un instrument sau o funcționalitate este indicat prin utilizarea unor tipuri potrivite pentru profilurile lor. În figura 4.5 este demontrat acest proces. Sesame1 reprezintă o instanță și profilul său, Sesame1Prof este de tipul OntologyStore, depozit de Ontologii, care reprezintă un profil pentru un tip de instrument SW. În mod asemănător, pentru funcționalitatea AddData, de adăugare a datelor, am declarat o instanța a serviciului , S1AddData, și am asociat-o cu instanța profilului de tipul StoreData, date stocate, care este un profil de tipul Funcționalitate.

Prin declararea profilului Sesame de tipul OntologyStore, se moștenește proprietatea hasFunctionality, definită pentru orice SWTool, instrument pentru Web-ul Semantic. Acest lucru este util în scenariile practice, când mai multe grupuri de utilizatori diferite pot accesa funcționalități diferite. Spre exemplu, o companie care își stochează datele în serviciul Sesame poate dori ca acestea să fie disponibile, atât pentru angajații, cât și pentru clienții săi. Clienții pot doar să citească datele stocate. De aceea, această instanță a serviciului Sesame oferă numai abilitatea de a citi datele. Din contră, angajații pot și să adauge, și să citească datele, astfel instanța serviciului lor referă ambele funcționalități.

Astfel, am reușit exprimarea compoziției, sau interdependența mai mult la nivel de profil, decât la nivel de proces, lucru care era posibil de la început cu DAML-S. La momentul potrivirii, dacă cineva dorește să utilizeze Sesame, primește o listă a profilurilor serviciului și poate descoperi serviciile individuale asociate cu aceste profile.

Figura 4.5. Utilizarea cunoștințelor din domeniu în cadrul profilului

4.4.4. Specificații cauză-efect

În următoarea parte a capitolului, este tratat modul în carepot fi specificați parametrii serviciului. Prima parte a acestei secțiuni își propune o modelare mai flexibilă a parametrilor de intrare, astfel încât intrările care deprind de o condiție să poată fi de asemenea specificate. În a doua parte, este tratată o alternativă pentru specificarea datelor de tipuri complexe.

Intrări condiționate. DAML-S nu are în vedere și cazuri în care intrările depind de o anumită condiție. În prezent, o persoană poate să indice doar obligativitatea intrări pe baza mecanismului de restricție a cardinalității.Pentru fiecare intrare obligatorie, o restricție de cardinalitate trebuie să facă necesară existența sa. Totuși, am întâlnit situații în care o intrare este cerută doar în cazul combinării sale cu o alta. Spre exemplu, la specificarea informațiilor de logare, este necesară o parolă doar când este completat câmpul referitor la utilizator. În cazul serviciului de adăugare a datelor, dacă sunt furnizate datele reale, și nu un URL, trebuie specificată baza URL.

Soluția care se dovedește a fi optimă în cazul versiunii actuale a DAML-S este aceea de a extinde ontologia procesului pentru a permite existența unor intrări condiționate în același mod în care ieșirile și efectele pot fi condiționate. Urmând modelul general de definire a elementelor condiționate, se propune definirea clasei IntrăriCondiționate, care leagă termenul de condiție cu cel de intrare, utilizând două proprietăți, condiția unei intrări condiționate ciCondiție și termenul de intrare. O intrare condiționată este o intrare care are loc atunci când este îndeplinită o condiție.

Figura 4.6. Modelarea actuală și propusă a intrărilor

Acest tip de modelare permite specificarea unui număr mai mare de intrări decât în versiunea actuală. Pot fi descrise intrările care depind de factori externi procesului . Spre exemplu, se poate specifica faptul că orice client din afara Statelor Unite ale Americii nu trebuie să scrie codul poștal, care reprezintă o intrare. În acest caz, localizarea geografică a unui client determină dacă este necesară sau nu introducerea codului poștal. Putem să observăm sau să identificăm situații ca precedenta, în cadrul căreia o intrare este condiționată de existența alteia sau de o condiție generală care implică alte intrări. Modelarea propune o modalitate alternativă de a specifica intrările obligatorii prin intrări condiționate cu o condiție care este întotdeauna adevărată. Intrările oționale pot fi modelate ca Intrări_Necondiționate, spre exemplu intrări care nu depind de nici o condiție.

Tipuri de date complexe. Pentru a asigura descoperirea automată și integrarea operațională a serviciilor Web, adnotările lor textuale trebuie să ofere informații despre semantica metodelor și a mparametrilor lor, cât și despre semnătura lor sintactică, cum ar fi nume de metode, formate de date. Această problemă problemă a modului în care se pot specifica cel mai bine tipurile complexe de date, atât la nivel semantic, cât și sintactic, are o importanță majoră în cazul Sesame, în care patru metode au ca rezultate tipuri de date complexe. Spre exemplu se consideră funcționalitate descrisă mai jos, requestRepository, de solicitare a bazei de date. Ieșirile sunt specificate astfel:

<!ELEMENT listaBazelorDeDate (BazadeDate)*>

<!ELEMENT bazaDeDate(titlu)>

<!ELEMENT titlu (#PCDATA)>

<!ATTLIST (lista de attribute) bazaDeDate

id ID #OBLIGATORIU

PoateFiCitit (adevărat|fals) # OBLIGATORIU

PoateFiScris (adevărat|fals) # OBLIGATORIU

>

Astfel de formate de date complexe sunt definite în partea referitoare la tipurile date date din cadrul unui document WSDL. Pentru o independență maximă față de platformă este utilizată schema XML, numită XSD, ce reprezintă o descriere a structurii și regulilor ce trebuie îndeplinite de un document pentru a fi considerat document XML. Această schemă permite celorlalte instrumente să analizeze toate ieșirile care sunt conforme cu formatul de date impus în document, asigurând astfel o integrare, o legătură de structură facilă între serviciile Web. Totuși, aceste informații nu au semantică.

Soluția DAML-S este de a înlocui definițiile sintactice XSD cu definiții semantice scrise în DAML+OIL, deoarece WSDL permite utilizarea oricărui limbaj de definiții de tip bazat pe XML în cadrul secțiunii referitoare la tipurile de date. Totuși, această opțiune are limitări când se aplică asupra tipurilor coplexe din Sesame. Doar prin utilizarea elementelor DAML+OIL, nu se poate exprima sintaxa complexă a tipurilor de date. Chiar și prin utilizarea definiților bazate pe Owm, scopul nu a fost atins, lucru care este de înțeles, deoarece DAML+OIL și OWL sunt limbaje ontologice, și transferă reprezentarea tipurilor de date în sarcina XSD.

Un document WSDL care utilizează doar tipuri de date bazate pe DAML+OIL ar fi inutilizabil pentru acei utilizatori ai serviciului care nu cunosc DAML+OIL. Ar fi ideal ca o descriere WSDL deja existentă să fie supusă unor schimbări foarte mici când este utilizată împreună cu tehnologia semantică, în scopul asigurării compatibilității cu aplicațiile obișnuite. Din acest motiv, am luat în considerare faptul că multe instrumente vor folosi definițiile XSD ale descririi WSDL din cadrul Sesame și numai câteva dintre ele vor putea înțelege DAML+OIL. Astfel, este de preferat extinderea, și nu înlocuirea tipurilor XSD.

Pentru unele aplicații, nu toate părțile unui tip de date complex sunt considerate ca fiind interesante din punct de vedere semantic. În cadrul exemplului anterior, se dorește specificarea faptului că obiectele de tipul Repository, adică bazăDeDate sunt returnate, dar fără a prezenta mai multe detalii.

Soluția. Ținând cont de observațiile anterioare, am ales utilizarea unei alternative pentru definirea tipurilor complexe de date. Am folosit schema XML pentru a specifica sintaxa ieșirii, a rezultatului, ca și în cazul unei descrieri onișnuite WSDL. Pentru adăugarea semanticilor la tipul de date considerat, am adăugat componentelor sale referințe către conceptele DAML+OIL corespunzătoare. Tagul xsd:adnotare are exact această funcție. Am scris următoarea definiție XSD, și am introdus și concepe definite în ontologia domeniului.

<xsd:nume element ="repositorylist">

<xsd: Tip complex>

<xsd:nume element ="repository">

<xsd:annotation>

<xsd:documentație>do:Repository</xsd:documentație>

</xsd:adnotație>

<xsd: Tip complex >

<xsd: nume element ="titlu" tip="xsd:string"/>

<xsd:nume atribut="id" tip="xsd:string" utilizare="obligatoriu"/>

<xsd: nume atribut ="poateFiCitit" tip="xsd:boolean" utilizare ="required"/>

<xsd: nume atribut ="poateFiScris" tip="xsd:boolean" utilizare ="required"/>

</xsd: Tip complex >

</xsd:element>

</xsd: Tip complex >

</xsd:element>

Această metodă rezolvă toate cerințele. Utilizarea schemei XML pentru a defini tipurile complexe își îdeplinește scopul. Se pot adăuga semantici oricărei părți a unei descrieri, astfel încât aceasta să poată fi utilizată și în cadrul aplicațiilor care nu se bazează pe semantică.

4.5. Concluzii

În urma descrierilor acestor trei servicii, am constatat anumite puncte forte și minusuri referitor la DAML-S.

Aspecte pozitive. DAML-S realizează atât descrierea semantică a unui serviciu, pe lângă cea sintactică. Semantica permite formularea unui raționament despre serviciul respectiv și ajută la descoperirea și utilizarea dinamică a serviciului. Ontologiile DAML-S de nivel superior asigură semantica pentru conceptele de nivel înalt referitoare la serviciile Web. Utilizarea acestor concepte și a unui set de concepte relevante din domeniu, ce pot fi realizate prin ontologia domeniului, duc la formularea unor descrieri cu un înțeles clar, precis și explicit. Acest lucru este de mare folos în realizarea de corespondențe între termeni alternativi. Ontologia din domeniu poate utiliza relația AceeașiClasă ca pentru a identifica sinonime și SubClasăA pentru a determina cuvântul de bază și derivatele unei familii de cuvinte. Acest lucru permite realizarea de corespondențe între nivele diferite de abstractizare considerate de solicitor și de furnizor. Alt aspect cheie al DAML-S este faptul că reprezintă un standard, realizând legătura între industrie și comunitatea Web-ului semantic.

Minusuri

1. Existența modelelor diferite în cadrul DAML-S. Cele trei componente ale DAML-S necesită diverse abordări pentru descrierea serviciilor. La nivelul profilului, un serviciu are patru tipuri de parametri, intrare, ieșire, precondiție și efect. La nivelul procesului intrările și ieșirile sunt tratate diferit din punct de vedere conceptual față de precondiții și efecte, deoarece provin din două vederi diferite asupra serviciului. Diferența conceptuală este și mai mare când un model DAML-S este comparat cu un model WSDL, care definește serviciile sub for a unei colecții de porturi. Aceste modele conceptuale alternative duc la o specificare dificilă a serviciului și la o transformare aproape imposibilă între servcii. Chiar și în cadrul DAML-S, modelele diferite pot duce șa probleme în cadrul specificației.

2. Transformările între părțile DAML-S sunt neclare. Transformarea dintre profil și proces duce la posibile divergențe logice în descrierea finașă a serviciului. Transformarea WSDL limitează expresivitatea DAML-S. Doar prin modelarea unui serviciu simplu am întâmpinat conflicte la două dintre cele trei reguli de transformare. Acest lucru obligă la revizuirea modelelor pentru a crea o bază mai sigură, prin renunțarea la polimorfism sau la o specificație clară a unei structuri interne complexe.

3. Lipsa unei corespondențe cu conceptele din ingineria software. Mulți dintre utilizatorii DAML-S sunt ingineri software. De aceea, am considerat utilă existența unor referințe la concepte de inginerie software, sub forma transormărilor conceptelor, deoarece ar putea asigura o înțelegere mai ușoară a DAML-S. În timp ce WSDL modelează intuitive diferite interfețe ca și TipuridePorturi, și permite gruparea operațiilor în porturile respective, ca și metode ale unei interfețe, DAML-S ia în considerare metodele simple. Conceptele mai complexe, cum ar fi polimorfismul, sau reutilizarea, nu sunt premise. Un model de ingineriae software ar putea elimina ambiguitățile existente în privința acestor concepte și ar putea oferi un cadrul de lucru ce poate fi folosit și de WSDL, și de DAML-S.

4. Dificultatea învățării DAML-S. Una dintre problemele majore o reprezintă faptul că este dificil să începi să scrii cod WSDL. Lipsa modelului conceptual joacă un rol important în această problemă. Alți factori sunt:

Documentația limitată referitoare la instrumentele folosite. La utilizarea editoarelor de texte, sarcina realizării unor descrieri complexe, dar care era alcătuită din doar trei părți interrelaționate, se dovedea a fi foarte dificilă. Această situație este modificată prin editoarele de descrieri ale serviciilor Web semantice, cum este și editorul OWL-S.

Lipsa exemplelor. Site-ul DAML-S oferă doar două exemple, care sunt create artificial pentru a se putea aplica tehnica ontologică, și nu pentru a reflecta realitatea. De aceea, exemplele ignoră anumite situații care pot surveni în cazul serviciilor reale.

Necesarul de cunoaștere a DAML/WSDL/SOAP. Pentru a putea scrie descrieri DAML-S, trebuie ca persoana să cunoască foarte bine DAML, WSDL și SOAP. Pentru utilizatorii care nu sunt familiarizați cu aceste tehnici, învățarea aprofundată a acestora este o adevărată povară.

4.6. Rezumat

În acest capitol, am analizat expresivitatea și utilizabilitatea DAML-S prin utilizarea sa în cadrul a trei servicii din viața reală.

Prima observație ar fi aceea că, din cauza limitelor de modelare și modelului conceptual imprecis, ontologia DAML-S are o expresivitate redusă. Am considerat o serie de soluții posibile pentru a rezolva aceste impedimente.

Deoarece trecerea de la profil la proces ducea la descrieri neclare, ambele ontologii au fost reproiectate.

A fost propus un nou model de implementare, deoarece trecerea la WSDL nu permite modelarea polimorfismului și a altor structuri interne complexe.

Este prezentat un raționament pentru intrările condiționate și o posibilă modelare a lor, precum și o metodă de modelare a serviciilor complexe, alcătuite din mai multe servicii independente.

Fișierele WSDL au fost îmbunătățite prin adăugarea de informații semantice.

Din punct de vedere a utilizabilității, pentru ca acestă să ajungă la limite acceptabile, am identificat un set de situații de modelare, le-am documentat și am dat niște soluții de modelare. Realizarea acestui capitol este aceea că situațiile de modelare prezentate vor putea fi realizate și de alte ontologii. Pentru a putea asigura expresivitatea unei ontologii, este necesară aplicarea acesteia în cazul serviciilor reale. Exemplele se dovedesc a fi de asemenea utile pentru a asigura utilizarea și adoptarea unei ontologii.

CAPITOLUL 5

OWL, ontologie pentru entități software generice

În acest capitol, este tratată problema adaptării OWL-S pentru a descrie tipuri de entități, altele decât serviciile Web. Acest lucru este motivat de două puncte de vedere. În primul rând, este necesară stabilirea generalității OWL-S, astfel încât să poată fi refolosit în domenii similare, ceea ce ar demostra calitatea sa, deoarece reutilizarea informației este unul dintre scopurile ingineriei ontologiilor. În al doilea rând, dacă OWL-S poate fi adaptat pentru a escrie semantic entități software generice, atunci aceste entități pot fi ușor expuse ca serviciile Web descrise semantic, facilitând astfel îmbunătățirea serviciilor Web semantice. Pentru analiză, utilizăm OWL-S ca bază pentru dezvoltarea unei ontologii care să fie fundamentul unui sistem middleware, spre exemplu un server de aplicații. Pe parcursul capitolului se identifică aspectele serverelor de aplicații care beneficiază de tehnologia semantică, pentru ca apoi să se demonstreze modul în care OWL-S a fost reutilizat pentru proiectarea unei ontologii pentru serverele de aplicații.

Motivația practică ce stă la baza reutilizării OWL-S pentru a descrie alte tipuri de entități software și pentru a susține realizarea altor sarcini decât cele specifice serviciilor Web este aceea că în scurt timp se preconizează existența multor entități software diferite, ce vor putea fi accesate ca servicii Web, spre exemplu, componentele care sunt administrate de sistemele middleware sau de controlerele de mecanism. Dacă aceste entități sunt descrise în cadrul unei ontologii derivate din OWL-S, atunci, la momentul publicării lor ca servicii Web, se va putea deriva facil descrierea lor semantică. Acest lucru va sprijini adoptarea tehnologiei serviciilor Web Semantice.

În acest capitol, este tratat gradul de adaptabilitate al OWL-S în contextul sistemelor middleware. În general, sistemele middleware facilitează dezvoltarea aplicațiilor cu mai multe niveleîn cadrul sistemelor informaționale distribuite. Soluțiile middleware obișnuite se axează pe entități software care asigură o interfață de programare, și care se mai numesc module software. Ca și tehnologia actuală pentru serviciile Web, middleware-ul se bazează pe standarde sintactice pentru descrierea modulelor software. Totuși, aceste standarde sintactice au o expresivitate scăzută.

Analiza efectuată asupra adaptabilității OWL-S este realizată în contextul unui server de aplicații concret: Serverul de aplicații pentru Web-ul Semantic (SAWS). Serverele de aplicații sunt produse bazate pe componente ce asigură funcționalitate pentru securitate și mentenanță, pe lângă accesul la date. În ciuda bunei funcționalități a severelor de aplicații, realizarea unui sistem distribuit complex rămâne o sarcină dificilă. Spre exemplu, administrarea dependențelor dintre componente, versiuni și licențe reprezintă o problemă tipică. Dezvoltatorii se confruntă și cu un număr mare de magazii de librării de programare, pentru sarcini standard, ca cele de intrare-ieșire, acces la baze de date, sau lucrul cu XML. Pentru utilizarea acestor resurse, dezvoltatorul are nevoie de ajutor și asistență.

5.1. Motivație

În această parte a capitolului, este prezentat serverul de aplicații pentru Web-ul Semantic și sunt descrise o serie de scenarii de utilizare care necesită descrieri semantice ale modulelor software. Aceste scenarii duc la un set de cerințe care au constituit bazele dezvoltării ontologiei prezentate în subcapitolul 5.3.

5.1.1. Server de aplicație pentru Web-ul Semantic

Integrarea modulelor software existente constituie o problemă de bază pentru Web-ul Semantic, odată ce aplicațiile complexe necesită mai multe module software. Dezvoltatorul unui astfel de sistem vrea să poată combina ușor diferite module software. Totuși, o astfel de integrare trebuia să fie făcută ad-hoc, generând puține posibilități de reutilizare și de extindere viitoare a modulelor individuale, sau a sistemului luat ca întreg.

SAWS rezolvă această problemă prin facilitarea reutilizării modulelor deja existente și ajutând astfel la dezvoltarea și menținerea aplicațiilor de Web Semantic care cuprind aceste module. SAWS combină metodele de coordonare a fluxului de informații dintre module, pentru a defini dependențe, a transmite evenimente între diferite module și pentru a trece de la un tip de date la al Web-ului semantic la un altul. Arhitectura serverului de aplicații se bazează pe abordarea componentelor și a micronucleului. Micronucleul oferă o funcționalitate minimală pentru administrarea, pornirea, oprirea și inițializarea componentelor. Modulele software existente trebuie să fie înregistrate, inițializate și pornite pentru a putea fi administrate de către micronucleu. Acest process asigură transformarea modulului software într-o componentă. La momentul rulării, serverul de aplicație poate să găzduiască mai multe componente cu aceeași interfață a aplicației. Pentru a putea face diferența între componentele de interes direct pentru dezvoltator și cele care asigură funcționalitatea serverului de aplicații, spre exemplu un registru, primele sunt denumite Componente funcționale, iar cele din urmă, Componente de sistem.Pentru a facilita lucrul cu o componentă care este în acțiune, un software client poate utiliza înlocuitori ai acesteia, care sunt obiecte client ce au aceeași API ca și componenta în cauză și care asigură comunicația între ele. Astfel, clientul nu mai trebuie să administreze protocolelel de rețea. La momentul execuției, serverul de aplicație permite clientului să aleagă componenta cu care înlocuitorul acesteia trebuie să comunice.

SAWS se bazează pe dezvoltarea și proiectarea serverelor existente de aplicații, aplicând și crescând numărul conceptelor din cadrul lor pentru a fi utilizate în cadrul Web-ului Semantic. De asemenea, tehnologia semantică din cadrul serverului poate fi utilizată în cadrul mai multor scenarii.

5.1.2. Scenarii

Pentru a rezolva problema administrării și localizării componentelor, este propusă introducerea unei conceptualizări formale a acestor discuții legate de software. Utilizarea acestui formalism permite reprezentarea cunoștințelor despre domeniu, cât și faptul că dependențele dintre componente sunt tranzitive. Utilizarea descrierilor formale ale modulelor software are multiple beneficii. Dezvoltarea unei ontologii permite formularea unor similarități între serverul de aplicații și dezvoltator. De exemplu, ontologia formalizează relații între componentele interne ale serverului. Instrumentele software pot spori cunoștințele specificate prin intermediul unui motor de raționamente. Descrierile semantice ale modulelor software pot îmbunăți multe dintre scenariile care apar în mod frecvent în cadrul unui server de aplicații. Scenariile descrise în continuare se aplică pentru orice server de aplicație, dar acestea sunt detaliate în cadrul setărilor SASW.

S1. Detalii de implementare. Bibliotecile depind deseori de alte biblioteci și o anumită arhivă poate conține în același timp mai multe biblioteci. Dată fiind această informație, un sistem poate să asiste proiectantul în localizarea bibliotecilor necesare. Utilizatorul poate fi de asemenea anunțat în momentul în care două biblioteci necesită versiuni diferite ale unei a treia componente. Spre exemplu, primele versiuni ale analizatoarelor XML produc multe probleme. Sistemul rulează doar dacă bibliotecile sunt incluse într-o anumită ordine în cadrul căii date, astfel încât modulul de încărcare a clasei să poată alege ultima versiune.

S2. Descoperirea componentelor. La momentul execuției, un client poate decide dinamic cu ce componentă trebuie să comunice înlocuitorul acesteia. Spre exemplu, un editor de ontologii poate utiliza un anumit depozit ontologic, totuși pot exista mai multe editoare care sunt pornite în același timp în cadrul serverului de aplicații. În acest moment, sunt importante informațiile care nu se referă la funcționalitate, ci acelea despre proprietățile unei componente, spre exemplu dacă o componentă de depozitare RDF este capabilă să efectueze o tranzacție. Registrul, o componentă a sistemului și un depozit ontologic simplu, conțin descrierile semantice a tuturor componentelor pornite și pot fi interogate în funcție de cerințe.

S3. Descoperirea API. În momentul programării aplicației, dezvoltatorul dorește să găsească un anumit API pentru a putea programa pe baza sa. El va dori să execute această căutare la nivel semantic, spre exemplu să specifice detaliile funcționalităților API. Spre exemplu, un dezvoltator al unui software client poate să aibă nevoie de o Api care să asigure funcționalități de stocare și de găsire a ontologiei. Deoarece pot exista mai multe API-uri inter-relaționate și care funcționează în același timp, sistemul trebuie să o recomande pe cea care se potrivește cel mai bine. Pentru a permite o astfel de căutare semantică, este sugeratădescrierea funcționalităților existente în termenii conceptelor conținute de o taxonomie a unui serviciu obișnuit.

S4. Clasificarea API-urilor. Un dezvoltator poate dori să determine tipul unei interfețe noi, pe baza tipului funcționalității sale., cum ar fi metodele sale. Spre exemplu, o interfață care asigură stocarea ontologiilor și capacităților de inferență va fi atât de tip StocareApi, cât și InferențăAPI.

S5. Publicarea serviciilor Web. Dezvoltatorul poate dori să utilizeze funcționalitatea stocată în componente de tipul serviciilor Web. Un conector de servicii Web poate publica metodele componentelor ținând cont de acest lucru. Pachetele de instrumente de dezvoltare de obicei asigură funcționalitatea pentru crearea părților și a bazelor sau pentru generarea automată a descrierilor interfețelor. Spre exemplu, instrumentul java2wsdl generează definiții WSDL din cadrul implementărilor bazate pe java ale serviciului . Este nevoie de explicații referitoare la instrumente pentru noile limbaje, cum ar fi limbajul de reprezentare OWL-S. În timp ce instrumentele WSDL pot obține toate informațiile de intrare cerute direct din codul sursă, limbajele mai puternice cer și alte măsuri. Utilizarea descrierilor semantice ale API duce la o generare mai ușoară a descrierii OWL-S corespunzătoare.

5.1.3. Cerințe

Scenariile discutate mai sus duc la un set de cerințe care constituie principii de proiectare pentru ontologia prezentată în subcapitolul 5.3.

R1. Implementarea modulelor și Sintaxa de funcționare. Ontologia trebuie să conțină metode de descriere a detaliilor de implementare a modulelor software care vor fi utilizate pentru a asigura implementarea.

R2. Caracteristici ale Modulelor și Semantici ale Funcționalității. Ontologia trebuie să conțină metode de a realiza descrieri la nivel înalt a modulelor software, tipul acestora ca depozite ontologice și intrumente pentru relizarea de raționamente, cât și caracteristicile acestora. Această descriere asigură descoperirea componentelor și interfețelor.

R3. Reutilizare și partajare. Descrierile semantice ale modulelor software trebuie să fie reutilizabile. De aceea, trebuie realizată organizarea descrierilor semantice și sintactice. Alt aspect al reutilizării este acela că ontologia proiectată pentru serverul de aplicații trebuie să cuprindă informațiile și uneltele care sunt dfeja utilizate.

R4. Independeța de domeniu. Ontologia trebuie să poată fi reutilizată în cadrul unui număr mare de domenii, nu numai în cadrul Web-ului semantic, de aceea conceptele generale și specifice unui anumit domeniu trebuie separate.

5.2. Proiectarea unei ontologii

În acest subcapitol este prezentată ontologia proiectată prin adaptarea OWL-S în sprijinul serverului de aplicație SASW. Este prezentată o comparație între ontologiile SASW și OWL-S, apoi este detaliată fiecare subontologie și este arătat modul în care fiecare dintre ele trebuie să îndeplinească o anumită cerință. Un exemplu concret este o descriere a unui modul care arată modul în care aceste ontologii sunt utilizate la nivelul de instanțiere.

Principiile de proiectare OWL-S sunt prezentate în figura următoare.

Figura 5.1. O comparație între OWL-S și ontologia pentru module software

Descrierea Semantică și cea Sintactică.

Am ales separarea descrierilor sintactică și semantică pentru a îndeplini cerințele R1 și R2. Un anumit număr din ontologiile propuse permit descrieri semantice, iar altele sunt utilizate pentru descrieri sintactice. Există o transformare între descrierile ambelor aspecte. Totuși, datorită tipurilor diferite de entități care se doresc a fi descrise, unele ontologii OWL-S au fost modificate, după cum urmează:

am păstrat ontologia de profil OWL-S pentru specificarea informațiilor semantice referitoare la componentele descrise. De asemenea, au fost adăugate și alte concepte pentru descrierea funcționalităților intefețelor și ale metodelor lor. La nivel conceptual. Acest lucru a fost necesar pentru că fiecare construcție a ontologiei de profil xe specifica descrieri funcționale se dovedea a fi superficială. Aceste extensii sunt grupate într-o ontologie redusă ca mărime, numită DescriereAPI.

Nu am folosit ontologia de proces, deoarece analizele anterioare au demonstrat faptul că instrumentele Web-ului Semantic oferă de obicei o serie de funcționalități simple, dar nu există un mod predefinit de invocare a acestora, care ar putea fi o parte a unui flux de date. În cazul modificării tipului componentelor, ontologia proiectată sub formă de module poate fi ușor extinsă cu ontologia de proces.

Am definit limbajul propriu pentru descrierea sintactică a interfețelor,deoarece WSDL este proiectat pentru specificarea punctelor limită ale rețelelor. În acest scop, am formalizat o submulțime de termeni din Limbajul de Descriere a Interfețelor IDL în cadrul ontologiei IDL.

Ca un rezultat al modificărilor precizate, nu am putut reutiliza baza OWL-S existentă, și am ales scrierea ontologia proprii de bază , numită bazaIDL, care permite transformarea între descrierile conceptuale ale interfețelor profilului și specificațiile lor sintactice, IDL.

Cunoștințe generale, respectiv de domeniu.

Au fost utilizate atât ontologiile generale, cât și cele de domeniu, pentrua îndeplini cerințele din R4. OWL-S și WSDL se află la un nivel de cunoștințe general. Același lucru se aplică și în cazul extensiilor OWL-S. Pentru scopurile specifice am construit douâ ontologii de domeniu din câmpul Web-ului Semantic. Prima dintre ele specifică tipul moduluâelor software din cadrul Web-ului semantic la nivel inferior. Cea de-a doua descrie funcționalitatea interfețelor specifice Web-ului Semantic la un nivel detaliat, în termeni de metode și parametri ai acestora. Aceste ontologii pot fi ușor substituite, în funcție de domeniul de aplicabilitate.

Modularitatea.

Modularitatea asigură reutilizarea specificațiilor și posibilitatea de extindere a unei ontologii. O problemă importantă este mărimea părților ce pot fi refolosite. De exemplu, deoarece o instanța Profil conține multe informații, care sunt deseori specifice, cum ar fi informațiile de contact despre furnizori, este mai puțin probabil ca această instanță să fie reutilizată de altă descriere a unui serviciu. De aceea o granularitate inferioară, ce înseamnă mai puține informații în cadrul unui concept, crește posibilitatea reutilizabilității. Am reutilizat acest principiu prin identificarea conținutului relaționat cu un concept central și gruparea tuturor informațiilor în cadrul unor ontologii de mărime redusă, care pot fi reutilizate ca subontologii. Am descris acest proces de izolare a cunoștințelor reutilizabile.

5.3. Componentele unei ontologii

În acest subcapitol sunt descrise subontologiile și relațiile care există între ele. Pentru fiecare ontologie descrisă, sunt indicate scenariile pe care le asigur, cât și cerințele îndeplinite.

În tabelul de mai sus sunt prezentate relațiile dintre cerințe și subontologii, confirmând influența pe care aceste cerințe au avut-o asupra proiectării ontologiei propuse.

Ontologia Modulului Software

Această ontologie este asemănătoare cu cea a serviciului OWL-S, astfel îndeplinind regula R3 referitoare la capacitatea de partajare și reutilizare a standardelor deja existente. Ontologia conține conceptele majore și conceptul dedefiniție pentru fiecare tip de definiție, asigurând o modularitate la nivel inferior a întregii descrieri.

Există unele schimbări:

Am redenumit conceptul de Serviciu în Modul Software, iar ProfillServiciului și Baza serviciului au devenit ProfilulModululuiSoftware și BazaModululuiSoftware.

Am exclus conceptul de model al serviciului, deoarece modalitatea de funcționare a modulelor nu prezintă interes

Am adăugat conceptul de ImplementareAModululuiSoftware care grupeză detaliile de implementare descrise în cadrul ontologiei de implementare.

Aceste trei concepte care descriu un ModulSoftware pot fi specificate prin utilizarea ontologiilor corespunzătoare.

Profilul OWL-S

Am folosit ontologia de profil OWL-S pentru a specifica caracteristicile speciale ale ModululuiSoftware, cum ar fi informațiile de contact ale furnizorilor și unii parametri. De exemplu, un depozit ontologic trebuie să aibă un parametru al serviciului care să specifice limbajul de reprezentare utilizat. De aceea, profilul descrie componentele ca un întreg. Informațiile de acest tip pot fi utilizate în timpul descoperirii componentelor, la momentul rulării, îndeplinind astfel și cerința R2 de asigurare a unor caracteristici generale ale modulelor descrise.

Specificarea descrierilor funcționale ale OWL-S se axează pe exprimarea unei singure funcționalități, în timp ce este necesară descrierea funcționalităților multiple pe care le oferă un modul software, care corespund cu unele metode din cadrul API. Din această cauză am adăugat o nouă proprietate entității Profil, numită areDescriereaAPI, care tratează conceptul de descriere API, ce grupează informațiile utilizate pentru a descrie o interfață și care este împărțită într-o ontologie de dimensiuni reduse. Am separat acest conținut într-o astfel de ontologie, deoarece multe module vor putea să reutilizeze astfel de descrieri ale funcționalității. Profilul a fost păstrat pentru a permite partajarea și reutilizarea standardelor deja existente.

Descrierile API

Ontologia descrierilor API oferă un mediu de lucru pentru a descrie semantic funcționalitatea metodelor interfețelor, spre exemplu adăugarea și ștergerea datelor. Completează astfel profilul OWL-S.

Conceptul de bază al ontologiei, numit DescriereAPI, poate avea mai multe proprietăți de tipul areMetoda pentru diverse instanțe de tipul Metodă. Fiecare instanță a Metodei are un set de parametri cum sunt intrările, ieșirile, precondițiile și efectele. Fiecare parametru are o proprietate areTipul, care referă un concept din cadrul ontologiei din domeniu. Tipurile metodelor și ale descrierilor API sunt specializate în termini de concepte din domeniu. Acest tip de informații sunt utilizate pentru a realize descoperirea interfețelor disponibile, în funcție de funcționalitatea acestora, pentru a clasifica noile API și metode și pentru a deriva descrieri OWL-S pentru servciile Web corespunzătoare.

Implementarea

Ontologia de implementare conține detalii de la nivelul de implementare al unui modul, răspunzând astfel la constrângerea R1. Există două aspecte ale implementării.

Detaliile Codului descriu caracteristici ale codului, cum ar fi clasa care implementează codul, arhivele necesare sau versiunile codului. Toate aceste aspecte sunt modelate ca proprietăți ale conceptului de detalii ale codului. Aceste caracteristici sunt specifice prntru o anumită implementare și nu pot fi reutilizate. Sunt folosite în timpul declanșării funcționării automate a componentelor.

Semnătura unei interfețe conține numele metodelor și parametrilor lor, modelate utilizând ontologia IDL. Conceptul de bază, Componenta, care este o subclasă a ImplementăriiModululuiSoftware, asigură legătura dintre o instanța a DetaliilorCodului și o instanță a unei Interfețe.

IDL

Am formalizat o mică submulțime a specificațiilor IDL în cadrul unei ontologii care permite descrierea semnăturilor interfețelor. Conceptul de Interfață corespunde cu cel al unei interfețe descrise. Are proprietatea areOperația, care trimite către o instanța a Operației. Fiecare operație poate avea un număr de parametri de intrare de un anumit tip. De asemenea, fiecare operație returnează un anume Tip al Operației, care poate fi de asemenea void. Interfețele, operațiile și parametrii au identificatori, care corespund cu numele cu care sunt utilizați în cadrul codului. Acest lucru permite specificarea tuturor detaliilor de implementare și apelare necesare pentru aplecarea automată a metodelor, utilizând un standard des întâlnit.

Baza IDL

Ontologia bazei IDL asigură o transformare între descrierile Interfeței și Descrierii API. Transformarea este directă, conceptele de Bază a Interfeței, Bază a metodei, Bază a intrării și a ieșirii asigură transformarea între conceptele respective din cadrul subontologiilor de Descriere API și de Implementare.

Există posibilitatea unor redundanțe, dar a fost mai importantă realizarea reutilizării și a corespondenței. O descriere a unui anumit nivel de concept poate fi baza mai multor interfețe diferite, care pot părea tehnic, spre exemplu, pot avea semnături diferite.

Ontologiile de domeniu

Am proiectat două ontologii de domeniu care specializează părți ale ontologiei generale prezentate. Prin izolarea cunoștințelor din domeniu în sub-ontologii separate, a fost posibilă îndeplinirea cerinței de independență față de domeniu.

Prima ontologie, Profile ale Web-ului Semantic, descrie în mod general modulele software pentru Web-ul Semantic. Cercetarea duce la observarea mai multor categorii de module software, de proiectare și de evaluare a ontologiilor, iar pentru fiecare categorie propune un anumit set de caracteristici., ce vor fi utilizate pentru compararea modulelor curente.

Am transformat aceste informații într-o ontologie de domeniu, după cum urmează. Am construit o taxonomie de categorii în conformitate cu fiecare document. Fiecare categorie a devenit o sublasă a Profilului. Caracteristicile fiecărei categorii sunt modelate ca subproprietăți ale parametrului serviciului din cadrul OWL-S. De exemplu, am creat categoria Depozit de Ontologii și am adăugat propriietăți cum ar fi Limbaj de interogare, limbaj de reprezentare. Proprietățile adăugate sunt specializări ale Parametrului Serviciului. Am concluzionat că extinderea unui profil OWL-S este facilă, în scopul modelării informației. De asemenea, acest lucru ca permite adăugarea unor noi cunoștințe pe viitor, deoarece această abordare oferă numai un set redus de caracteristici, care nu poate fi extins.

A doua ontologie, DescriereaAPI pentru Web-ul Semantic, descrie funcționările specifice ale Web-ului Semantic. Conține un set de tipuri de funcționări, anume metode, și de interfețe. De exemplu, am declarat conceptual de DepozitAPi, cate modelează API-uri pentru motoare de stocare, și am definit o metodă de adăugare a datelor, cât și una de interogare. Prin combinarea interfețelor simple, se pot realize interfețe complexe. Interfața de stocare și interogare este obținută prin moștenirea metodelor din cadrul ambelor interfețe, și cea de stocare și cea de interogare. În cadrul unui anumit tip de API, pot fi realizate specializări prin declararea de metode adiționale. Schema acestei ontologii este asigurată de ontologia de Descriere API, în care interfețele, anume API, sunt de tipul Descriei API, și funcțiile lor, cum ar fi cea de adăugare a datelor, sunt de tipul Metodă. La proiectarea acestor ontologii de domeniu, am folosit ca bază ontologia creată pentru descrierea Sesame.

Figura 5.2. Ontologia SASW

5.4. Folosirea descrierilor componentelor

În mod obișnuit, descrierile semantice suportă două scenarii principale. În primul rând, „detaliile aplicării”, ca de exemplu încărcarea componentelor, sunt realizate automat folosind detaliile aplicării în fiecare descriere (conform cu ontologia aplicării) și capacitățile de raționament ale serverului. De exemplu, poate fi dedusă închiderea tranzitivă a tuturor librăriilor necesitate de anumite componente. În al doilea rând, „descoperirea componentelor” este susținută în momentul rulării. Deci, clientul poate consulta registrele pentru componentele disponibile, poate alege o componentă din lista de restituire (bazat pe proprietățile acesteia) și poate folosi acea componentă. De exemplu, un editor ontologic care se comportă ca un client poate să ceară depozite sau raționamente ontologice existente, apoi să selecteze și să interacționeze cu oricare dintre componentele disponibile. Trebuie avut în vedere că această situație este superioară aplicațiilor obișnuite ale serverului, unde relația dintre diferiți clienți trebuie să fie codată.

5.5 Activitate asociată

Classical Software Reuse Systems sunt comparabile cu propunerea prezentată, deoarece și acestea trebuia să descrie module de software potrivite pentru o recuperare eficientă și precisă. Tehnicile cum ar fi clasificarea în funcție de astepte sunt limitate la reprezentarea particularităților furnizorului.

Analogical Software Reuse prezintă o reprezentare de module, care este bazată pe funcționalitațile realizate de software, roluri și condiții. UPML, Unified Problem-solving Method Development Language a fost dezvoltat pentru a descrie și aplica arhitecturi inteligente ale agenților, si componente care să faciliteze refolosirea si adaptarea automată. Este un context pentru dezvoltarea cunoașterii intensive a sistemelor raționale bazate pe librării ale componentelor pentru rezolvarea problemelor generale, reprezentate de intrări si ieșiri, preconditii și efecte ale sarcinilor. Aceste modele fie descriu foarte diferit modelele de componente, fie se concentrează exclusiv pe descrierea sintatică sau pe cea semantică, fără a le combina.

Altă unitate a activității asociate sunt adaptările lui OWL-S într-un domeniu anume. De exemplu, se folosește o extensie a OWL-S pentru a descrie serviciile Web în domeniul bio-informaticii. OWL-S este imbogățit cu termeni lingvistici atunci când descrie un factor bazat pe serviciile Web. IDL este îmbogățit cu concepte specificate în Logica Descrierilor. Mai exact, se are în vedere aplicarea următoarelor feluri de informații la o interfață IDL: a) date invariante (folosite în mod deosebit pentru baza de date asemeni constrângerii integrității), b) proceduri ante- și post-condiții, c) modele de comportare ale obiectelor și dinamicii. Astfel, pentru verificarea potriviri exacte dintre client și server , raționamentul afirmărilor formale și al Logicii Descrierilor (LD) permite efectuarea unor sarcini adiționale. Printre ele, Compatibilitatea testării specificatiilor, Verificarea locală a consistenței, Tratamentul mai amănuțit al exceptiilor și Variabilitatea în serviciile furnizate.

Oricum, această abordare doar augmentează partea sintactică a unei descrieri API. Nu se ocupă cu informația semantică despre o metoda funcționala ca abordarea propusă în cadrul acestei lucrări.

5.6 Rezumat

În acest capitol am investigat adaptibilitatea OWL-S în contextul unui anumit server de aplicații, care suportă dezvoltarea unei aplicații Semantic Web complexe. Ca o dovadă a conceptului, am creat o ontologie care adaptează OWL-S astfel încât să întrunească cerințele serverului de aplicații. Ontologia nou creată este deja încorporată în server și folosită pentru aplicarea și descoperirea componentelor (scenariul S1 si S2).

În concluzie, OWL-S încorporeaza câteva principii valoroase de proiectare care îl fac mai ușor de adaptat la descrierea altor tipuri de entităti de software decât serviciile Web. Adaptibilitatea este o trăsătura importantă a ontologiei generale și ar trebui să caracterizeze și alte ontologii folosite pentru servicii de descriere Web.

CAPITOLUL 6

Transformarea OWL-S într-o ontologie de bază

În capitolele precedente am abordat expresivitatea, utilitatea și adaptibilitatea OWL-S. În acest capitol, OWL-S este analizat dintr-o altă perspectivă ontologică. Sunt identificate aspectele problematice și sugerate metodele de trecere la o ontologie de bază. Altă contribuție adusă de lucrare prin acest capitol este Core Ontology of Services, ontologia nucleu a serviciilor, care încearcă să umple golul conceptual dintre ontologia de bază și OWL-S. Această ontologie poate fi refolosită pentru a fi fundamentul altor servicii de limbaj de descrieri Web de asemenea, contribuind astfel la armonizarea acestora.

6.1 Introducere

Claritatea în semantică și o formalizare a acestor semantici sunt cerințe importante pentru ontologiile destinate să fie utilizate la o scară largă, pentru sisteme distribuite și deschise ca Web-ul Semantic. Acest lucru este urmare a faptului faptului că ontologiile ar trebui să faciliteze înțelegerea comună, sau pentru a beneficia de cooperare între multipli agenți artificiali, sau pentru a introduce un consens într-o societate mixtă unde agenții artificiali cooperează cu oamenii. Ontologiile de bază îndeplinesc aceste cerințe, pentru că reprezintă un punct de plecare pentru construirea unor noi ontologii de domeniu și aplicații, furnizează un punct de referință pentru o comparatie ușoară și riguroasă între diferite abordări ontologice și creează un context pentru analizarea, armonizarea și integrarea ontologiilor și metadatelor existente. Claritatea în semantică și formalizarea sunt îndeosebi importante pentru ontologii care descriu serviciile Web (ca OWL-S), pentru că dau posibilitatea ca mai multe sarcini să implice un număr mare de agenti. Contribuția lucrării de față la dezvoltarea OWL-S este de a indentifica unele dintre aspectele problematice ale acestuia, și de a sugera o intensificarei a trecrii către o ontologie fundamentală. Am descoperit că OWL-S are anumite ambiguități conceptuale, duce lipsă de o axiomatizare concisă, este creat prea liber si oferă o vedere prea limitată asupra serviciilor Web. Pe parcursul procesului de reglare, am descoperit posibile intensificări ale acestor aspecte problematice legate de ontologie. Core Ontology of Services s-a dezvoltat ca fiind un strat de mijloc care poate fi folosit pentru reglarea altor limbaje de descriere pentru servicii Web.

Acest capitol este structurat după cum urmeaza. La început, este detaliată activitatea asociată, în Secțiunea 6.2. În subcapitolul 6.3 sunt identificate și explicate câteva aspecte problematice ale OWL-S. În subcapitolul 6.4 este prezentată partea principală a activițatii, reglarea OWL-S la DOLCE, ontologia de bază . În final sunt arătate concluziile și rezultatul acestei cercetări.

6.2 Activitatea asociată

Eforturile precedente au răspuns unor probleme ale OWL-S. Sunt descrise pe scurt cele doua inițiative cunoscute, descriind motivarea lor, părțile OWL-S pe care se axează, tehnicile pe care le folosesc și unele rezultate inițiale (atunci când sunt disponibile).

Prima inițiativă, este motivată de necesitatea semanticilor formale de a descrie, simula, compune automat, a testa și verifica serviciile Web. Se focalizează numai pe ServiceModel al OWL-S, care furnizează construcții pentru modalitățile de compunere specificate. Este stabilit un calcul matematic semantic pentru elementele principale din ServiceModel al OWL-S (procese atomice și complexe, efecte condiționale și ieșiri), acestea fiind apoi transformate în semantici operațional. Acest formalism de reprezentare a informației are un bogat suport teoretic și instrumental pentru diferite sarcini de compunere. Într-adevar, aceste semantici au permis refolosirea unor simulări și modele existente ale mediului. Mai mult de atât, au fost identificate mai multe submulțimi maleabile ale OWL-S (analize mai putin expresive, dar mai eficiente, pentru verificare, compoziție și verificarea modelelor).

A doua lucrare (Ankolekar 2002b) se concentrează numai asupra ServiceModel al OWL-S și propune o semantică operațională concurentă care încorporează subtipuri de polimorfisme. Motivarea pentru această activitate este aceea de a furniza semantici inițiale referențiale care ar descoperi orice posibilă ambiguitate din cadrul limbajului de dezvoltare. Ar fi de folos de asemenea pentru dezvoltarea tehnicii de verificare automată a modulelor OWL-S. În sfârșit, dacă alte standarde Web ar furniza semantici similare ar fi mult mai ușor să fie comparate și să i se inteleagă punctele sale slabe sau puternice. Pe lângă realizarea unei axiomatizări formale, se dorește explicarea conceptelor OWL-S în termenii ontologiei fundamentale care reflectă câteva teorii general acceptate din lingvistică, filosofie, știinte cognitive. Am demonstrat că aceasta analiza „ontologică” a OWL-S scoate de asemenea la suprafață neregularitățile din model .Unul dintre beneficiile de lungă durată ale reglării este că permite comparația dintre câteva ontologii care au fost astfel modificate. Analiza este extinsă către întregul model OWL-S. Dintr-o perspectivă metodologică, abordarea furnizează reconstructia independentă a OWL-S, pe când, în timpul reglării, am introdus modelul OWL-S într-un context mai puțin precis oferit de ontologia fundamentală. Se poate deduce, de exemplu, că OWL-S nu se referă la diferențe dintre un obiect real (carte) și duplicatul de reprezentare într-un sistem de informație (numărul ISBN), o importantă diferență ontologică. În ultimul rând, semanticile stabilite de abordările precedente, nu sunt reflectate în formalizarea actuală a modelului OWL-S. În cazul lucrării de față, modelul moștenește axiomatizarea disponibilă pentru OWL-DL, o versiune a DOLCE.

6.3 Aspecte problematice ale OWL-S

În această secțiune sunt identificate și ilustrate unele aspecte problematice în înțelegerea OWL-S dintr-o perspectivă fundamentală. Aceste probleme sunt prezentate având în vedere calitatea ontologică.

Calitatea ontologică poate fi evaluată folosind trei criterii: acoperirea extensională (privind numărul de entițati care sunt menite să fie descrise de o teorie ontologică), acoperirea intensă (privind ce axiome sunt necesare sa descrie modelel ontologice pe care proiectantul doreste să le acopere) și precizia (pe baza axiomelor care sunt necesare pentru a descrie doar modelele pe care proiectantul a dorit să le reprezinte). Conform acestor criterii, o ontologie bună ar trebui să aproximeze domeniul de discurs care trebuie să fie descris, ar trebui să aibă o semnătură care să schițeze diverse entitați întocmite de proiectanți, și ar trebui să axiomizeze predicatele astfel incât să cuprinda toate modelele proiectate, și să le excludă pe cele ce nu sunt proiectate.

În continuare, sunt detaliate patru probleme întâlnite în OWL-S. Prima dintre ele, ambiguitatea conceptuală, reflectă atât insuficienta acoperire termenilor, precum și precizia prea mare. A doua și a treia problemă, slaba axiomatizare și proiectare, sunt cazuri ale lipsei de precizare. Cea de-a treia problemă este în principal datorată limitelor de expresivitate ale OWL-S. A patra problemă, scopul limitat, se referă la domenii atât extensive, cât și intensive.

6.3.1. Ambiguitatea conceptuală

Este adesea dificil pentru utilizatori să înțeleagă adevăratul sens al unor concepte, relația dintre aceste concepte, precum și modul în care acestea sunt raportate la serviciile modelate. Noțiunea de servicii poate fi definită astfel: „Prin `serviciu` se înțeleg paginile Web care nu furnizează în întregime informație statică, dar permite uneia să afecteze anumite acțiuni în lume, ca vânzarea unui produs sau controlul unui dispozitiv fizic”. „Orice program, senzor sau dispozitiv accesibil prin Web este declarat ca fiind un serviciu ”.

Nici una dintre aceste definiții nu este operaționalizată și nici un concept al unei „pagini Web” sau al „Web” nu apare în ontologie. În schimb, noțiunea unui serviciu este caracterizată numai de relația sa cu un număr de ServiceProfiles, profile ale srviciului, cel mai mult un ServiceModel sau alt număr de ServiceGroundings, baze ale serviciului, care nu sunt suficiente pentru înțelegerea conceptului de Serviciu considerat de OWL-S.

Este ținut cont de faptul că termenul de servicii Web și termenii apropiați (e-Service, Service, etc.) suferă de asemenea de supraîncarcare. În cercetarea asupra unei posibile formalizări, am găsit o varietate de definiții care accentuează diferite aspecte ale unui serviciu: oferirea de funcționalitate (folositoare pentru o anumita sarcină), interoperabilitatea folosind standarde de furnizare pentru interfețe ale unui sistem existent.

6.3.2. Slaba axiomatizare

Descrierile OWL-S ar trebui să fie procesate de un dispozitiv. Este important ca fiecare concept să fie caracterizat de o axiomatizare amănunțită, astfel încât să suporte interfețe care să aibă sens. În general, nivelul de dedicare în OWL-S se așteaptă că o să fie deasemenea ridicat, dacă va suporta sarcini raționale complexe înainte de combinare și ajungerea la un consens al unor înțelesuri.

Spre deosebire de problema menționată în secțiunea precedentă, axiomatizarea deficitară reflectă o problemă mai nesemnificativă atunci când definirea conceptelor este clară, dar axiomatizarea în ontologie are nevoie de îmbunătățiri. În multe privințe, OWL-S arată caracteristicile tipice ale unei ontologii ale aplicației: nu este nici în concept clar sau ierarhie a relației (multe concepte și relații sunt direct subconcepte pentru conceptul și relația din nivelul de vârf) și câteva relații iau owl:thing, anume un obiect owl, ca domeniul sau categoria lor.

Prin adăugarea de informații la OWL-S, nivelul axiomatizării poate fi mărit. Reglarea la o ontologie fundamentală reprezintă asocierea conceptelor și relațiilor unor ontologii la categoriile de bază ale unei cunoașteri umane investigate de filosofie, lingvistică și psihologie. Această abordare are avatajul că restricțiile nivelului sunt moștenite de conceptele din ontologia aplicației. Aceasta solicită inginerului ontologic să își însușească noțiunile pentru distincțiile făcute de această ontologie fundamentală. De asemenea, promovează refolosirea, subliniind generalitățile, care ajută îndeosebi la reducerea înmulțirii relațiilor – un fenomen tipic pentru ontologiile aplicației.

Trecerea la o ontologie fundamentală bine modularizată permite de asemenea importul teoriilor de selectivitate din ontologiiacest lucru este demonstrat în paragraful 6.5, în cadrul căruia este elaborată reglarea contrucției de control a OWL-S la Ontologia Planurilor, care este una dintre extensiile de bază ale ontologiei fundamentale DOLCE.

6.3.3. Proiectarea imprecisă

Un alt aspect problematic al OWL-S din punctul de vedere al unui ontolog, este proiectarea sa dificilă. La baza acestei probleme stă scopul OWL-S de a furniza descrieri ale variatelor aspecte ale serviciilor Web care trebuie să suporte un număr de sarcini diferite de asociere (descoperire, compoziție, invocare).

Serviciile Web trebuie tratate contextual, pentru a reprezenta diferitele puncte de vedere asupra unui serviciu, contexte ce pot avea un anumit nivel de granularitate. Majoritatea acestor “vederi” asupra serviciului se suprapun, deoarece se axează pe același atribut al serviciului.

Modularizarea directă în asemenea cazuri conduce la o ontologie greu de descifrat, încurcată, în cadrul căreia plasarea anumitor cunoștințe devine arbitrară, iar între module este necesară o transformare intensivă.

O rezolvarea a acestei probleme o poate constitui aplicarea legării, inter-relaționării atributelor, pentru a exprima faptul că rezultatul unui proces reprezintă intrarea pentru un alt proces, său că rezultatul unui proces poate fi același cu rezultatul unui subproces din alcătuirea sa. În programare, acest lucru este exprimat prin utilizarea variabilelor, dar cum în OWL nu există conceptul de variabilă, interrelaționarea argumentelor este exprimată prin hărți ale valorilor explicite. O hartă de valori are forma unei liste, atașate unei componente a procesulu. Această listă trebuie să conțină ca membri instanțe ale conceptului ValoareA. Fiecare concept valoareA trebuie să adreseze o singură relație a unui singur concept, prin utilizarea relațiilor Parametrul și înProcesul.

Figura 6.1. Reprezentarea legăturii atributelor în OWL-S

Deși reprezentarea este corectă, apare o consecință nedorită a soluției, și anume faptul că nu putem fi siguri despre scopul restricției impuse de harta de valori. OWL-S sugerează atașarea harții valorilor la procesul ale cărui subprocese sunt descrtise în cadrul hărții. Pot exista mai multe restricții ale hărții de valori asupra intrărilor și ieșirilor unui proces, datorate compunerii serviciilor.

6.3.4. Scopul limitat

Descrierile serviciilor se află la granița între sistemele informaționale, cu obiecte cum ar fi înregistrarea unei cărți, și lumea reală, cu obiecte de tipul cărții fizice. Motivul este acela că serviciile Web constituie doar o parte din întregul serviciu căruia îi este atribuită o valoare de către utilizator. Acest fenomen caracterizează majoritatea serviciilor din lumea reală, în cadrul căreia utilizatorul plătește nu doar pentru stocarea și manipularea informațiilor, ci pentru întregul proces, care include modificări și efecte care au loc în mod curent în lumea reală, cum ar fi spre exemplu livrarea cărții.

În timp ce OWL-S tratează acest aspect al serviciului, nu este clară diferența ce poate fi făcută între obiectele și evenimentele din cadrul unui sistem informațional, cu privire la date și manipularea acestora, pe de o parte, și obiectele și evenimentele din lumea reală, care sunt externe procesului. Utilizarea unei ontologii funcționale este posibilă și necesară pentru proiectantul unei descrieri, pentru ca acesta să poată face astfel de diferențe, deoarece acestea afectează natura ontologică a obiectelor și evenimentelor avute în vedere.

În afară de domeniul restrâns de acoperire intensională, nucleul OWL-S se dovedește a fi foarte axat pe o precizie foarte strictă, de tipul cardinalităților 1:1. Pentru un anumit serviciu, trebuie să existe un singur model al serviciului. Acest lucru face imposibilă considerarea unor modele alternative sau evaluarea relației dintre modelul serviciului, solicitat de client sau de lege, și modelul care stă la baza sistemului furnizorului.

Lucrarea de față își propune să adauge la OWL-S relații pentru transformarea între descrierile serviciului și elementele de funcționare reală ale serviciului. Aceste relații vor fi moștenite direct din ontologia de Descrieri și Situații, un modul al DOLCE.

6.4. Trecerea către DOLCE

În acest paragraf, este descrisă trecerea de la OWL-S la ontologia fundamentală DOLCE. DOLCE este extinsă de o ontologie de Descrieri și Situații. Deoarece există o mare diferență între ontologia OWL-S și cea de Descrieri și Situații, am proiectat o Ontologie de bază de Servicii, prezentată în subcapitolul 6.4.3. În secțiunea 6.4.4, este descris modul în care conceptele OWL-S vor fi exprimate prin utilizarea Ontologiei de bază pentru Servicii. În cadrul părții 6.4.5, este rezumată metodologia de aliniere la ontologia de bază.

6.4.1. DOLCE

Rolul ontologiilor de bază este de a constitui puncte de plecare pentru noi ontologii, pentru realizarea de comparații privind diverse aborrdări în proiectarea de ontologii , și de a crea un mediu de lucru de bază pentru analiza și integrarea standardelor de ontologii și metadate. Ontologiile fundamentale sunt conceptualizări care conțin specificații ale conceptelor independente de domeniu și relații bazate pe principii formale derivate din lingvistică, filosofie și matematică.

DOLCE, Ontologie Descriptivă pentru Ingineria Lingvistică și Cognitivă (Descriptive Ontology for Linguistic and Cognitive Engineering) este proiectată minimal, în sensul că include numai categoriile de nivel superior, reutilizabile și care sunt aplicate la scară larg, este riguroasă în termini de axiomizare și este bogat documentată.

DOLCE se bazează pe o distincție fundamentală între entități durabile și temporare, între care se află o relație de participare, o entitate durează în timp prin participarea la evenimente temporare, spre exemplu, o persoană ce participă la un discurs. Calitățile pot fi privite ca entități de bază pe care le putem observa sau măsura. Calitățile spațiale și temporale codifică atributele în spațiu și timp ale obiectelor sau ale evenimentelor. Abstractizările nu au calități temporale sau spațiale, și nu reprezintă ele însele calități. Spre exemplu, mulțimile sau regiunile codifică măsura calităților, în funcție de un sistem metric sau conceptual.

DOLCE a fost aleasă ca bază ontologică în lucrarea de față datorită structurii sale interne, ce conține o axiomizare bogată, principii de construcție explicite, referințe către literatura de specialitate, pentru modularitatea sa, precum și pentru capacitatea de transformare a altor ontologii și de extindere prin module aparținând diverselor domenii.

Figura 6.3. Taxonomia de nivel înalt a DOLCE

6.4.2. Descrieri și situații

Uneori, înțelesul unor obiecte nefizice, cum ar fi instituțiile sociale, organizațiile, nu pot fi modelate decât în contexte anume, în combinație cu alte entități. Alteori, acest tip de obiecte pot fi tratate ca și entități fizice. Acest lucru înseamnă că o ontologie trebuie să poată modela contextul sau cadrul de referință de care depind entitățile. Reprezentarea contextului este o problemă obișnuită în multe domenii din lumea reală, de la tehnologie la domeniul social.

Figura 6.3. Alinierea Descrierilor și Situațiilor la DOLCE

Descrierilor și Situațiile se dovedesc a reprezenta o teorie de contexte ontologice, deoarece permit descrierea diferitelor noțiuni de context sub forma entităților. D&S (Descrieri și Situații) introduce o nouă categorie, numită Situație, care rafinează o stare și implică existența entităților din ontologia de bază. O Situație satisface o anumită Descriere a Situației (S Descriere), care constituie o entitate Endurant Nonfizic și este alcătuit din entități descriptive , cum ar fi Parametrii, Rolurile Funcționale și Descrierile Evenimentelor.

D&S se dovedește a fi foarte folositoare când este aplicată ca un model, ca un tipar pentru proiectarea ontologiilor, pentru structurarea ontologiilor ce necesită conceptualizare. Acesta este și cazul descrierilor serviciilor Web.

6.4.3. O ontologie de bază a serviciilor

Diferitele puncte de vedere asupra unui serviciu trebuie să poată fi reprezentate în același mod. În loc să trecem OWL-S direct la ontologia de Descrieri și Situații, am dezvoltat o ontologie de bază a serviciilor și am transformat sursele OWL-S conform acestei ontologii. Această trecere treptată este o tehnică des utilizată când există o diferență conceptuală mare între ontologiile sursă și ontologiile fundamentale. Ontologia de bază pentru Servicii oferă o axiomizare foarte bună și poate fi reutilizată în cadrul altor scenarii.

La nivelul descrierii există cinci descrieri care sunt des prezente, fiecare reprezentând un punct de vedere diferit.

Oferta serviciului este punctul de vedere al unei entități legale care asigură serviciul., dar nu poate descrie în întregime modul în care este executat acest serviciu.

Cererea serviciului cuprinde așteptările clientului, care sunt deseori flexibile, și se bazează pe o anumită submulțime de sarcini, roluri și parametri ai activităților serviciului.

Acordul serviciului reprezintă punctul de vedere comun al utilizatorului și al furnizorului asupra modului de reprezentare a serviciului. Acordul semnifică o înțelegere a faptului că serviciul oferă o anumită valoare clientului, care poate sau nu să fie aceeași cu funcționarea inițială a serviciului.

Evaluarea serviciului. În urma încheierii acordului, sunt luate măsuri pentru evaluarea, monitorizarea și controlul execuției serviciului oferit, care verifică compatibilitatea activităților serviciului cu cerințele.

Descrierea normelor serviciului. Aceasta este descrierea convențiilor sociale privind execuția serviciului, fie un cod scris de practică sau o normă. Acest punct de vedere este baza acțiunii legale în momentul în care serviciul se abate de la norme.

6.4.4. Trecerea OWL-S la ontologia de bază a serviciilor

Procesul de trecere s-a dovedit a fi folositor prin faptul că permite separarea rapidă a conceptelor ontologiei care nu au o interpretare ontologică unică și clară. Relațiile cum ar fi numele serviciului sau descrierea textuală privesc pe larg profilul și sunt astfel aliniate cu descrierea ofertei serviciului. Noțiunea de actor din cadrul profilului serviciului este aceeași cu Rolul Funcțional al Agentului. Componenta Procesului devine aceeași cu conceptul de sarcină. Unele construcții de control individuale devin componente ale sarcinilor, spre exemplu o condiție RepeatUntil devine un concept Sarcină Ciclică Until.

Prin utilizarea ontologiei de bază a serviciilor s-au eliminat ambiguitățile referitoare la Intrări, Ieșiri, Precondiții și Efecte. Relațiile dintre conceptele din OWL-S și cele din ontologia de bază sunt prezentate în figura următoare.

Figura 6.4. Trecerea de la OWL-S la Ontologia de Bază a serviciilor

6.4.5. Sumar

Încercarea de transformare ontologică este prezentată în figura de mai jos. Am folosit DOLCE ca ontologie de bază, extinsă de modulul de Descrieri și Situații, am definit ontologia de bază a serviciilor, care a fost folosită pentru transformarea OWL-S. Metodologia de transformare poate fi folosită pentru a compara și a transforma alte descrieri de servicii. Ontologiile pentru domenii specializate și de aplicații ale descrierilor serviciului sunt formulate ținând cont de una dintre aceste ontologii generake.

Metoda din lucrarea de față combină abordări de tip bottom-up și top-down. Ontologiile de pe nivelurile inferitoare oferă cerințe de reprezentare pentru nivelurile superioare, care abstractizează conceptele și relațiile din cadrul celor de nivel inferior. Nivelurile superioare definesc norme de proiectare pentru nivelurile inferioare. Deși scopul lucrării era inițial de a păstra sctructura OWL-S cât mai intactă, metoda sugerează o rearanjare a ontologiei pe baza scheletului D&S.

Figura 6.5. Ierarhia ontologiilor folosite în procesul de transformare

6.6. Concluzii

Încercarea de realizare unei baze pentru OWL-S este folositoare pentru o mai bună înțelegere a OWL-S și pentru adăugarea semanticilor formale care să o îmbunătățească. Rezultatele prezentate sunt un exemplu al beneficiilor alinierii la ontologiile de bază, deoarece metodologia propusă este aplicabilă și în alte domenii. Ontologia de bază pentru Servicii poate fi un cadru de lucru pentru a realiza o corespondență în metodele de caracterizare a serviciilor Web. Alinierea OWL-S la Ontologia de bază a serviciilor semnifică faptul că serviciile Web descrise de OWL-S sunt automat aliniate la DOLCE. Astfel de descrieri pot fi îmbogățite prin adăugarea semanticilor bazate pe DOLCE la conceptele de domeniu implicate. Acest lucru permite motorului de potrivire sau de compunere să raționeze cu semanticile adiționale, în scopul rafinării rezultatelor.

Una dintre problemele metodei de aliniere a ontologiilor a fost aceea că solicită înțelegerea unor principii rar întâlnite ale ontologiei fundamentale. Aceste principii provin din cadrul altor științe, ceea ce înseamnă că acest tip de inginerie soliocită efort intelectual din partea inginerului cunoștințelor. Totuși, prin realizarea ontologiei de bază, ontologiile serviciilor Web pot fi standardizate, pot comunica cu ontologiile de domeniu. O ontologie reutilizabilă ar fi putut fi suficientă pentru realizarea analizei OWL-S, dar pentru a avea acces la standardizarea conceptuală cu alte ontologii de servicii sau domenii, este nevoie de o ontologie flexibilă de bază.

6.7. Rezumat

În acest capitol este finalizată analiza OWL-S prin tratarea sa în amănunt din perspectivă ontologică. OWL-S are probleme majore, cum ar fi ambiguitatea, slaba axiomizare, design-ul nedetaliat și scopul restâns, nereușind să îndeplinească cerințele de semantici clare și de formalizare. Multe dintre aceste aspecte pot fi rezolvate prin transformarea OWL-S către o ontologie de bază formalizată și cu o documentație bogată. Este utilizată o ierarhie de ontologii pentru o ierarhie treptată. Acest tip de transformare nu depinde de DOLCe, deoarece ontologie de Descrieri și Situații poate fi aliniată la o ontologie de bază.

Trecerea la o ontologie fundamentală este o activitate care solicită timp și efort intelectual. Totuși, odată cu legătura realizată de dezvoltarea unei ontologii nucleu, de bază, între ontologia fundamentală și domeniu, se poate obține mult mai ușor o aliniere a altor standarde din domeniu.

Capitolul detaliază analiza ontologiei generice OWL-S pentru serviciile Web.

CAPITOLUL 7

Descrierea unui mediu suport pentru proiectarea și învățarea ontologiilor din domeniul serviciilor Web

Ontologiile din domeniu și cele generice sunt importante pentru descrierea semantică a serviciilor Web. În acestă parte a lucrării, am avut în discuție ontologiile pentru domeniul serviciilor Web. Una dintre problemele ontologiilor din domeniu o constituie faptul că achiziția lor este dificilă și costisitoare. În acest capitol sunt descriși unii dintre factorii care împiedică proiectarea ontologiilor de calitate dintr-un anumit domeniu și sunt expuse cerințele pentru o soluție automată a acestei probleme. În continuare, am prezentat un mediu pentru învățarea ontologiilor, care satisface aceste cerințe. Nota inovatoare nu este dată de metodele de procesare a limbajului natural, ci de modul de organizare a lor în cadrul unui mediu generic specializat pentru serviciile Web. În finalul acestui capitol sunt detaliate unele aspecte de implementare ale acestui mediu sub forma unui sistem prototip și este evaluat mediul prezentat.

7.1. Introducere

Ontologiile din domeniul serviciilor Web joacă un rol foarte important în cadrul descrierilor serviciilor Web. Totuși, există doar câteva ontologii pentru descrierile serviciilor Web, iar proiectarea lor este o sarcină dificilă. În această parte a lucrării am detaliat problema învățării semiautomate a ontologiilor din domeniul serviciilor Web. Contextul serviciilor Web ridică anumite probleme care limitează dezvoltarea unei soluții de învățare a ontologiilor. Am proiectat un mediu pentru realizarea învățării în contextul serviciilor Web, care încearcă să rezolve aceste probleme. Acest mediu folosește particularitățile documentațiilor serviciilor Web pentru a extrage informații utilizate pentru proiectarea ontologiilor. Caracteristicile de sublimbaj ale acestor texte duc la identificarea unor euristici. Aceste euristici sunt implementate ca reguli bazate pe extragerea de modele și tipare, ce constitute informații lingvistice de nivel înalt. Ontologiile învățate sunt utile pentru descrierile serviciilor Web, deoarece conțin atât cunoștințe statice, cât și procedurale.

Am implementat două metode de învățare ce respectă principiile de bază ale mediului, dar utilizează cunoștințe lingvistice diferite. Prima metodă folosește informații de bază referitoare la Părțile de Vorbire și a fost dezvoltată și testată în contextul proiectului WonderWeb. A doua metodă utilizează tehnici aprofundate de stabilire a dependenței sintactico-morfologice pentru achiziția cunoștințelor lingvistice. A fost proiectată și testată pe seturi de date din cadrul proiectului myGrid. În cadrul acestui capitol sunt prezentate mediul și cele două metode.

7.2. Problema proiectării ontologiilor din domeniul serviciilor Web

În această secțiune, este descris procesul de proiectare a unei ontologii realizate în contextul a două proiecte de cercetare: WonderWeb și myGrid. Aceste proiecte oferă anumite cerințe, seturi de date și standarde de evaluare pentru lucrare. În ambele cazuri, sunt detaliate tipurile surselor de date utilizate pentru proiectarea ontologiilor și ontologiile de domeniu proiectate manual. Aceste ontologii proiectate manual reprezintă standarde pentru evaluarea ontologiilor învățate automat. De asemenea, am subliniat și câteva dintre dificultățile întâlnite pe parcursul proiectării acestor ontologii de domeniu.

Proiectele expun unele dintre aspectele majore care fac foarte dificilă proiectarea ontologiilor pentru serviciile Web. Aceste aspecte descriu necesitatea automatizării achiziției ontologiilor de domeniu. Al doilea beneficiul al acestei analize constă în prezentarea unui set de probleme care limitează dezvoltarea metodelor de învățare a ontologiilor în contextul serviciilor Web. Aceste limitări ajută la proiectarea mediului pentru învățarea ontologiilor.

7.2.1 Studiul de caz 1: Instrumentele de stocare WonderWeb RDF

Descrierea proiectului

Acest proiect de cercetare dezvoltă o infrastructură pentru proiectarea la scară largă a ontologiilor în domeniul serviciilor Web. Infrastructura de inginerie a proiectului este furnizată de Serverul de Aplicație KAON, un sistem middleware semantic, ce facilitează interoperabilitatea dintre instrumentele pentru Web-ul Semantic. Ontologiile ce descriu funcționalitatea instrumentelor și serviciilor Web-ului Semantic constituie nucleul arhitecturii acestui middleware. Deoarece instrumentele de stocare și interogare RDF sunt componente esențiale ale oricărei aplicații Web sematice, au fost primele integrate în cadrul KAON și de aceea necesită o ontologie de domeniu pentru descrierea acestui domeniu. În afară de WonderWeb, ontologia pentru descrierea funcționalității de stocare RDF a fost utilizată în proiectul AgentFactory, care asigură configurarea serviciilor Web descrise semantic prin utilizarea algoritmilor de proiectare bazați pe agent.

Sursele de date

Deși există multe instrumente ce asigură stocarea ontologiilor, numai câteva sunt disponibile ca servicii Web. De aceea, este dificilă proiectarea unei ontologii de domeniu de calitate doar prin analizarea serviciilor Web disponibile. Totuși, deoarece serviciile Web sunt expuneri ale software-ului existent în domeniul accesării Web-ului, există corespondențe între funcționalitatea oferită de un serviciu Web și implementarea de la baza serviciului. Pe baza acestei observații, ontologia de domeniu a fost proiectată manual prin analizarea API-urilor a trei instrumente de stocare RDF, și anume Sesame, Jena și KAON.

Sursele de date utilizate pe parcursul proiectării ontologiilor sunt formate din documentația javadoc a tuturor metodelor oferite de aceste APUI-uri. O documentația javadoc conține o descriere generală a funcționalității metodei, cât și o descriere a parametrilor săi, a tipurilor de rezultate și a excepțiilor. Spre exemplu, documentația javadoc a metodei add (de adăugare) din cadrul API-ului Jena este următoarea:

Add

Adăugarea tuturor sintagmelor returnate de un iterator al modelului.

Parametri

Iter – Un iterator ce returnează sintagmele ce trebuie adăugate.

Returnează: acest model

Throw: RDFExcepție – Excepție RDF Generică

Ontologia proiectată manual

Ontologia proiectată manual conține 36 de concepte, organizate în două ierarhii. Prima ierarhie conține concepte ce denotă un set de funcționalități oferite de API-urile analizate. Aceste concepte sunt grupate în conceptul Metodă, care este similar ca semnificație cu conceptul Profil din OWL-S. Această ierarhie conține patru categorii de metode: adăugarea datelor (AddData), ștergerea datelor (RemoveData), găsirea datelor (RetrieveData) și interogarea (QueryMethod). Există mai multe specializări ale acestor metode. Spre exemplu, în funcție de granularitatea datelor adăugate, există diverse metode pentru adăugarea unor sintagme RDF (AddStatement) sau a unei întregi ontologii (AddOntology). Această ontologie reflectă o anumită conceptualizare și nu este unică. În afara ierarhiei Metodă, ontologia conține elemente din modelul de date RDF (RDFStatement – Sintagmă RDF, RDFPredicate – Predicat RDF) și ierarhia lor, grupată sub conceptul de Data.

*Data

*DataRDF

Ontologie

OntologiaRDF

PredicatRDF

ResursăRDF

SintagmăRDF

SubiectRDF

*Metodă

*AddData – AdăugareDate

AddOntology – AdăugareOntologie

AddStatement – AdăugareSintagmă

*QueryMethod – MetodăInterogare

*RemoveData – ȘtergereDate

*RetrieveData – GăsireDate

Figura 7.1. Ontologia de stocare RDF

Ontologia conține multe cunoștințe utile pentru anumite sarcini de executare a raționamentelor. Spre exemplu, definițiile metodelor au fost îmbunătățite în mai multe moduri, cum ar fi impunerea restricțiilor de tip și cardinalitate ale parametrilor, sau descrierea efectelor și tipurilor de comportament specific (idempotența). Proiectarea manuală a unei ontologii reprezintă o indicație a faptului că documentațiile API sunt îndeajuns de puternice pentru a permite construirea ontologiilor din domeniul serviciilor Web.

Probleme întâlnite

Principalul impediment în proiectarea unei ontologii de domeniu pentru descrierea instrumentelor de stocare RDF îl constituie alegerea surselor de date din cadrul cărora se pot proiecta ontologii de domeniu. Odată cu luarea decizilor, au fost necesare trei săptămâni pentru construirea ontologiei. Acest interval include timpul necesar pentru citirea și înțelegerea documentației API, cât și pentru identificarea funcționalităților oferite de API-uri și modelarea lor în cadrul unei ontologii.

7.2.2. Studiul de caz 2: Serviciile Bioinformatice myGrid

Descrierea proiectului

MyGrid este un proiect de test englezesc pentru proiectarea middleware-ului semantic în scopul realizării experimentelor din biologie. Protocolul de experiment este descris sub forma unui ciclu de lucru, cu mulți pași asigurați de serviciile Web. Baza acestei infrastructuri o constituie o ontologie pentru descrierea funcționalității acesror servicii și a semanticii datelor utilizate. Un rol important al unei ontologii este facilitarea descoperirii de către utilizator a serviciilor în momentul construirii acestora. Ontologia nu este proiectată inițial pentru a susține specificațiile ciclului de lucru, descoperirilor serviciilor automate conduse de agenți, invocării sau monitorizării automate.

Sursele de date

Ontologia a fost inițial proiectată folosind documentația pentru 100 de servicii ca sursă de termeni relevanți. Aceste servicii sunt parte a colecției de servicii EMBOSS (European Molecular Biology Open Software Suite). Fiecare serviciu EMBOSS are o descriere detaliată ce conține, printre altele, o scurtă descriere a serviciului, informații detaliate despre argumentele liniei de comandă, exemple de formate ale fișierelor de intrare – ieșire, relațiile serviciului cu alte servicii din colecția EMBOSS sau chiar referințe către publicațiile științifice care descriu funcționalitatea serviciului.

*Proces generic

*Aliniere

Aliniere parțială

*Aliniere globală

Aliniere globală pe perechi

*Aliniere locală

Aliniere locală multiplă

Aliniere locală pe perechi

Calculare

Afișare

Distingere

Filtrare

Grupare

Inserare

Compunere

Figura 7.2. Ontologia myGrid

Ontologia proiectată manual

Ontologia proiectată manual myGrid este mai extinsă și mai complexă decât ontologia RDF relaționată. myGrid conține peste 550 de concepte organizate pe subsecții diferite, ce acoperă domeniile biologiei moleculare, bioinformaticii, informaticii și al sarcinilor generice, toate înglobate în cadrul unei structuri de nivel înalt. Totuși, numai o parte din această ontologie, aproximativ 23% din conceptele sale, asigură concepte pentru adnotarea descrierilor serviciilor Web-ului semantic în cadrul unui instrument de adnotare bazate pe forme. Descrierile serviciilor Web-ului semantic astfel obținute sunt utilizate pentru a facilita descoperirea serviciilor. Ontologia myGrid conține un număr redus de concepte ce denotă funcționalitatea serviciului. Spre deosebire de ontologia RDF, în cadrul myGrid se folosește alt principiu de modelare. Conceptele de funcționalitate descriu acțiunile generice care pot fi executate în bioinformatică, fără a fi implicate și structurile de date utilizate. O explicație posibilă pentru această alegere este faptul că în domeniul bioinformaticii aceste operații pot fi efectuate asupra unei multitudini de structuri de date, enumerarea tuturor acestor combinații nefiind utilă.

Probleme întâlnite

Dezvoltarea ontologiei myGrid este influențată de o serie de factori negativi. În primul rând, proiectarea unei ontologii este o sarcină ce necesită mult timp. Ontologia a fost inițial proiectată pe parcursul a două luni de către experți cu patru ani de experiență în proiectarea ontologiilor biomedicale cu descrieri bazate pe logică. Un al doilea impediment este natura dinamică a acestui domeniu. Creșterea exponențială a numărului de servicii Web biomedicale în ultimii ani a solicitat alte două luni de muncpă pentru mentenanța și extinderea ontologiei. Totuși, conținutul serviciului este întârziat deoarece trebuie să descrie peste 1000 de servicii disponibile pentru comunitate. În al treilea rând, lipsa instrumentelor împiedică procesul. În momentul demarării lucrării, suportul de instrumente pentru module separate din cadrul ontologiei era minimal, deoarece exista o singură ontologie importantă și detaliată.

Al patrulea impediment îl constituie lipsa unor ghiduri despre modul de proiectare aunor ontologii specifice unui domeniu, sau a modului de conectarea a acesteia cu ontologiile de nivel înalt. Din cauză că DAML-S era încă în stadiul de dezvoltare, gestionarii ontologiei au formulat propria schemă generică de descriere a serviciilor Web, pe baza DAML-S, aceasta fiind mult mai simplificată pentru a reflecta cerințele stricte.

7.2.3. Concluzii

Analiza procesului de proiectare a ontologiei duce la formularea a două concluzii majore. În primul rând, proiectarea ontologiilor reprezintă un proces dificil pentru ambele proiecte, ceea ce face necesară o soluție automată a acestei probleme. În cadrul lucrării de față este discutată utilizarea tehnicilor de învățare a ontologiilor pentru proiectarea ontologiilor semiautomate dintr-un anumit domeniu. În al doilea rând, contextul serviciilor Web prezintă o serie de constrângeri, de limite ce trebuie avute în vedere în momentul proiectării unei soluții semiautomate.

Proiectarea unei ontologii este dificilă și trebuie automatizată. Ambele studii de caz s-au confruntat cu același set de factori care au influențează negativ activitatea de proiectare.

Numărul mare de documente textuale. Managerii ontologiei au analizat, și anume au citit, au înțeles și au identificat conceptele comune din cadrul unui număr mare de documente textuale, peste 100 în ambele cazuri, pentru a asigura calitatea ontologiilor. Numărul documentelor analizate este în continuă creștere, odată cu apariția mai multor servicii Web.

Lipsa unor ghiduri. Un al doilea impediment îl constituie lipsa unor linii de ghid referitoare la cunoștințele ce trebuie conținuteîn cadrul ontologiilor și a principiilor de proiectare ce trebuie respectate. Acest lucru adus la formarea unor grupuri de cercetători ce proiectează ontologii diferite pentru a descrie servicii Web. Se poate observa o tehnică diferită de modelare, doar prin analizarea celor două studii de caz. În primul studiu de caz, denumirile conceptelor de funcționalitate descriu atât acțiunea acestei funcționalități, cât și structurile de date utilizate. În al doilea studiu de caz, este utilizat numai verbul ce descrie acțiunea pentru a denumi conceptele de funcționalitate.

Acești factori fac proiectarea unei ontologii o sarcină ce consumă mult timp, fiind astfel necesare instrumente care să ajute gestionarii ontologiilor în extragerea ontologiilor din cadrul colecților de date extinse și în permanentă schimbare.

Trebuie luate în considerate anumite constrângeri pe parcursul proiectării unei soluții automate de învățare a ontologiilor. Cele două activități de proiectare a ontologiilor diferă din anumitepuncte de vedere. În primul rând, domeniile de aplicare sunt diferite, unul dintre ele fiind referitor la știința calculatoarelor, iar celălalt, la biologie. În al doilea rând, sunt folosite surse de date de tipuri difereite ca bază pentru proiectarea ontologiilor: descrierile javadoc ale API-urilor în primul studiu de caz, iar în al doilea, documentațiile detaliate ale serviciilor. Aceste surse diferă din punct de vedere calitativ, descrierile utilizate în primul studiu de caz fiind mai puțin performante. Ontologiile proiectate manual sunt de asemenea diferite. Ontologia myGrid este mai extinsă și mai complexă decât ontologia ce are la bază RDF. Acest lucru nu este neapărat un avantaj, deoarece testele au arătat că numai o mică parte din ontologie este folosită pentru adnotațiile serviciilor Web.

În afara acestor diferențe, ambele studii de caz au și caracteristici comune, descrise în secțiunea următoare, ce constituie un set de cerințe pentru realizarea unui mediu de învățare a ontologiilor pentru domeniul serviciilor Web.

7.3. Cerințe pentru o soluție de învățare a ontologiilor

Pe parcursul analizei procesului de proiectarea ontologiilor în cadrul celor două studii de caz, am identificat o serie de caracteristici fce au o influență majoră asupra modelării soluției de învățare a ontologiilor. Aceste caracteristici au la bază două aspecte ale problemei de învățare.

Calitatea textului analizat. Comentariile textuale atașate serviciilor Web sunt caracterizate printr-o calitate gramaticală redusă și de multe elemente specifice sublimbajelor. Aceste elemente specifice duc la o funcționare suboptimală a instrumentelor existente pentru învățarea ontologiilor . Aceste limitări sunt depășite prin alegerea cu atenție a instrumentelor ce vor fi folosite în cadrul mediului de învățare a ontologiilor.

Caracteristicile ontologiei învățate. Ontologiile de domeniu utilizate oentru descrierile serviciilor Web conceptualizează atât cunoștințele statice, cât și pecele procedurale. Totuși, eforturile pentru învățarea ontologiilor sunt canalizate spre extragerea cunoștințelor statice. De aceea, tehnicile existente au fost adaptate și pentru extragerea cunoștințelor procedurale.

7.3.1. Calitatea gramaticală scăzută

Calitatea gramaticală redusă este o caracteristică importantă a descrierilor formulate în limbaj natural asociate cu serviciile Web. Aceste descrieri sunt comnentarii scurte și informative scrise de dezvoltatori. Punctuația este complet ignorată și există multe erori de scriere. În mod normal, serviciile cu mai mulți utilizatori au o documentație mai bună, în timp ce serviciile mai puțin folosite conțin părți de text abreviat.

Principalul dezavantaj al calității gramaticale scăzute a textelor analizate este faptul că acestea sunt dificil de procesat cu instrumentele existente pentru procesarea limbajului natural. Instrumentele de procesare existente au fost testate pe documente de calitate din cadrul ziarelor, de calitate mult mai bună decât documentațiile serviciilor Web. De exemplu, unele instrumente de adăugare textuală bazate pe regulile morfologice țin cont de majusculele cuvintelor, cuvintele scrise cu inițială mare fiind considerate substantive. O rezolvare posibilă o constituie preprocesarea, cum ar fi scrierea primului cuvânt din propoziție cu literă mare, adăugarea semnelor de puctuație.

Există și două dezavantaje în cazul în care se lucrează cu astfel de documentații. În primul rând, aceste texte sunt formate din propoziții simple, nu din fraze complicate. Ambiguitatea redusă favorizează utilizarea analizei lingvistice detaliate. Instrumentele de analizare a dependențelor funcționează mai bine asupra propozițiilor scurte, decât asupra frazelor complexe. Al doilea avantaj este acela că aceste texte utilizează limbajul natural într-un mod specific, conform unui sublimbaj. Aceste caracteristici ale documentațiilor fac posibilă analizarea lor în mod automat.

7.3.2 Caracteristicile sublimbajelor

Documentația software în general, și descrierile serviciilor Web în particular, implică utilizarea limbajului natural într-un mod specific, sub forma unui sublimbaj. Un sublimbaj este o formă specializată a limbajului natural care este utilizată în cadrul unui anumit domeniu sau într-un anumit subiect de discuție și care este caracterizază printr-un vocabular specializat, relații semantice și sintaxă. Un exemplu intuitiv pentru domeniul medical este faptul că în contextul “… a relevat o tumoră” se pot găsi cuvinte cum ar fi “raze X”, “film”, “scanare tomografică”. Aceste cuvinte aparțin clasei de cuvinte TEST_MEDICAL.Există mai multe constrângeri referitoare la apariția simultană a claselor de cuvinte în cadrul unui sublimbaj. De exemplu, multe dintre propozițiile din sublimbajul medical sunt de forma “TEST_MEDICAL relevă BOALA”, în timp ce propozițiile de tipul “BOALA relevă TEST_MEDICAL” sunt lipsite de înțeles, deși sunt corecte din punct de vedere gramatical. Aceste constrângeri sunt denumite contrângeri de selecție.

În cadrul sublimbajului serviciilor Web analizat pot fi identificate maii multe clase de cuvinte și contrângeri de selecție. Spre exemplu, considerând EXT_VB ca fiind o clasă de cuvinte ce conâine verbe care indică procesul de extragere, cum ar fi extrage, găsește, primește, poate fi utilizat un model care implică această clasă și propoziția “din” pentru a determina ieșirile și sursa de acțiune.

Constrângere de selecție (model)

EXT_VB IEȘIRE din SURSĂ

Exemple:

Extrage date din aaindex.

Extrage cds, mrna și translații din tabele.

Primește date din cutg.

Găsește părți din secvență.

Cunoștințele despre clasele de cuvinte și constrângerile de selecție din cadrul unui sublimbaj pot constitui baza pentru sarcinile de procesare a limbajului natural, cum ar fi extragerea informațiilor. Utilizarea tehnicilor de analiză a sublimbajelor poate fi aplicată și pentru învățarea ontologiilor, deoarece clasele de cuvinte coincid adeseori cu clasele semantice. Constrângerile semantice pot ajuta la determinarea membrilor uinei clase de cuvinte, în cazul în care există cunoștințe despre membrii altor clase de cuvinte implicate în restricții.

Unul dintre aspectele problematice ale analizarii sublimbajelor constră în faptul că determinarea claselor de cuvinte ce prezintă interes și a constrângerilor olor de selecție este un proces ce necesită timp. S-a încercat automatizarea acestui proces. Totuși, pentru primul model al mediului, am luat în considerare doar câteva caracteristici importante ale sublimbajului, care nu au fost greu de identificat. Astfel de modele nu se bazează ppe informațiile lexicale, ci doar pe structurile gramaticale. De exemplu, una dintre primele observații a fost că, în cadrul acestui sublimbaj, aproape fiecare verb indică o acțiune executată de un serviciu Web. Astfel, o clasă de cuvinte ACȚIUNE include toate verbele identificate. Frazele substantivale care apar după un verb de acțiune denotă paricipantul la acțiune și formează clasa de cuvinte PARTICIPANT_la_ACȚIUNE. Aceste clase de cuvinte pot fi ușor identificate doar pe baza unei analize lingvistice minimale. Apariția concomitentă a acestor clase de cuvinte identifică funcționalitatea serviciului Web și asigură materialul de bază pentru un algoritm de învățare a ontologiilor.

7.3.3. Învățarea ontologiilor bazate pe cunoștințe procedurale

Învățarea ontologiilor trebuie adaptată atât pentru caracteristicile datelor de intrare, cât și pentru a produce ontologii care sunt potrivite pentru descrierea serviciilor Web. Ontologiile din domeniul serviciilor Web conțin cunoștințe statice, cum ar fi conceptele de entitate a domeniului, cât și cunoștințe procedurale, de exemplu funcționalitățile oferite de serviciile Web. Cercetările existente în momentul demarării lucrării se axau pe derivarea cunoștințelor statice. Una dintre contribuțiile lucrării este de a extinde aceste tehnici și pentru achiziția cunoștințelor procedurale.

Un alt factor care trebuie luat în considerare este acela că, din cauza lipsei unui ghid de modelare a cunoștințelor procedurale pentru serviciile Web, apar diferite stiluri de proiectare. Mediul propus asigură metode pentru generarea ontologiilor conform ambelor stiluri de modelare din studiile de caz, dar poate fi extins și pentru alte stiluri noi de proiectare.

7.4. Un mediu pentru învățarea ontologiilor din domeniul serviciilor Web

În momentul demarării lucrării, erau disponibile trei instrumente pentru învățarea ontologiilor, TextToOnto, OntoLTși Text2Onto. Am încercat extragerea unei ontologii de domeniu dintr-un set de documente, utilizând TextToOnto, dar rezultatele obținute au fost suboptimale, din cauza particularităților din setul de documente, care au limitat eficiența metodelor generice implementate cu ajutorul acestui instrument.

Descrierea mediului

Mediul de învățare a ontologiilor conține mai multe etape. În continuare sunt prezentate pe scurt acești pași și este arătat modul în care caracteristicile contextului serviciilor Web influențează proiectarea mediului.

Figura 7.3. Principalele etape ale utilizării mediului de învățare a ontologiilor

Extragerea termenilor. În prima etapă sunt identificate din cadrul documentelor cuvintele care sunt relevante pentru proiectarea ontologiilor. Un cuvânt sau un set de cuvinte care sunt identificate ca fiind utile pentru proiectarea ontologiilor formează un “termen”. Extragerea termenilor este realizată în două etape. Prima dată, prin analiza lingvistică documentele sunt adnotate cu informații lingvistice. În a doua fază, se aplică un set de reguli de extragere asupra informațiilor lingvistice pentru a identifica termenii ce prezintă un interes potențial.

Caracteristicile domeniului serviciilor Web au influențat alegerea de proiectare. În primul rând, pentru a depăși limitările impuse de calitatea gramaticală scăzută a textelor, acestea au fost analizate lingvistic. În urma experimentelor, se observă că analizele mai complexe duc la rezultate mai bune. Numărul redus de documente și caracteristicile de sublimbaj facilitează utilizarea unei soluții bazate pe reguli. Caracteristicile de sublimbaj ale documentelor ajută la observarea unor euristici pentru identificarea informațiilor importante și pentru implementarea lor în cadrul regulilor de extragere.

Proiectarea ontologiei. În a doua etapă a mediului, termenii identificați anterior sunt centralizați, analizați și transformați în concepte corespunzătoare și sunt stabilite relațiile ierarhice dintre ei. Faza de proiectare a ontologiilor derivă atât cunoștințele statice, cât și pe cele procedurale, sub forma unei ierarhii de concepte des utilizate în domeniu și a unei ierarhii de funcționalități ale serviciilor Web. Caracteristicile puternice ale sublimbajelor din cadrul documentelor analizate permit extragerea celor mai relevanți termeni pentru proiectarea unei ontologii. De aceea, este suficient să se utilizeze tehnici simple de învățare a ontologiilor și acestea să se adapteze pentru cerințele din domeniu.

Filtrarea ontologiei. Calitatea gramaticală redusă a documentelor utilizate, cât și caracteristicile de sublimbaj duc la o funcționare suboptimală a instrumentelor lingvistice utilizate. De aceea, unele dintre conceptele derivate nu sunt relevante pentru domeniu. Etapa de filtrare exclude copnceptele lipsite de interes dinm cadrul ontologiilor.

7.5. Detalii de implementare

O parte importantă a lucrării o constituie implementarea sistemului prototip. Am încercat proiectarea unui sistem care să poată fi utilizat cu ușurință atât fe dezvoltatori, cât și de utilizatorii metodelor de învățare a ontologiilor. Un instrument prietenos cu utilizatorul ajută la realizarea scopului lucrării, și anume facilitarea procesului de proiectare a ontologiilor pentru domeniul serviciilor Web. În primul rând, am ales o implementare modulară, ușor de înțeles, care să poată fi modificată și adaptată pentru noi domenii de aplicabilitate. Acest lucru a fost realizat prin utilizarea mediului GATE. În al doilea rînd, am folosit tehnicile vizuale pentru o prezentare ușor de înțeles a seturilor de date derivate pe parcursul învățării ontologiei pentru a constitui baza sarcinilor des întâlnite.

Mediul GATE

Mediul GATE oferă multe elemente importante pentru dezvoltatorii instrumentelor de învățare a ontologiilor, cum ar fi modularitatea, identificarea, portabilitatea și evaluarea. GATE este unul dintre puținele medii generice pentru procesarea limbajului natural care a fost proiectat pentru a oferi robustețe, reutilizabilitate, repetabilitate experimentală și scalabilitate. De asemenea, este în prezent singurul mediu de procesare a limbajului natural care permite ingineria ontologiilor pebaza limbajului. Aplicația proiectată, fiind parte a acestui mediu, are de asemenea aceste caracteristici.

GATE este o infrastructură și un mediu pentru dezvoltarea aplicațiilor de procesare alimbajului natural. Resursele de procesare (algoritmi de procesare, cum ar fi cei de căutare a dependențelor) și cele lingvistice (elemente de tip date, cum ar fi documentele și ontologiile) pot fi combinate în cadrul aplicațiilor, fie vizual, fie prin programare. GATE oferă un număr mare de resurse de procesare și posibilitatea extinderii acestora cu ajutorul modulelor personalizate.

Modularitatea. GATE permite proiectarea aplicațiilor modulare. Aplicațiile pot fi construite prin combinarea resurselor de procesare, fie vizual, fie prin intermediul programării. Utilizând GATE, se pot încărca module de procesare a limbajului natural (tokenizere) și structuri de date (ontologii, documente), care se pot combina în diverse aplicații. De exemplu, figura 7.4 prezintă interfața utilizator GATE. Partea stângă arată resursele lingvistice și de procesare încărcate, utilizate. Partea dreaptă arată modul de combinare a acestor resurse pentru proiectarea aplicațiilor. Aceste resurse rulează asupra tuturordocumentelor de test. Aplicația execută etapele de analiză lingvistică și de extragere a termenilor, din cadrul metodei de învățare a ontologiilor bazată pe părți de vorbire. (M_PDV).

Figura 7.4. Proiectarea unei aplicații cu ajutorul interfeței GATE

Figura 7.5. Inspectarea adnotațiilor cu ajutorul interfeței utilizator GATE

Identificarea. În afara combinării facile a resurselor de procesare, GATE asigură și o interfață utilizator pentru inspectarea rezultatelor produse de fiecare dintre aceste resurse. Datele de intrare și de ieșire ale resurselor de procesare sunt reprezentate sub forma adnotațiilor. Adnotațiile sunt descrieri adăugate la anumite părți din textul analizat. Adnotațiile pot fi adăugate cuvintelor individuale, sintagmelor, propozițiilor sau paragrafelor. Adnotațiile pot fi ușor vizualizate în GATE. În figura 7.5 este testat unul dintre documentele utilizate și toate adnotațiile sale. Textul documentului poate fi urmărit în partea mediană inferioară. Partea dreaptă conține toate adnotațiile, grupate în seturi de adnotații. Spre exemplu, setul de adnotații Tokens conține adnotații care prezintă diverse informații. Adnotațiile Token sunt adăugate pentru a identifica toate simbolurile dintr-o propoziție. Adnotațiile NP identifică toate frazele substantivale din cadrul textului. Setul de adnotații Functionalitz conține doar adnotația Funct care se referă la combinațiile de cuvinte ce ar putea descrie funcționalitatea oferită de către serviciu. La selectarea unei adnotații, sunt subliniate toate instanțele acesteia din cadrul textului. În cazul de față, atît adnotațiile NP, cât și cele Funct sunt subliniate. Pot exista suprapuneri între adnotații. În afara numelor lor, adnotațiile pot conține un set decaracteristici, care sunt perechi atribut – valoare. Aceste caracteristici pot fi vizualizateîn partea mediana superioară. Spre exemplu, fiecare adnotație Funct are o caracteristică ce conține eticheta frazei substantivale (np) și un element al cărei caloare este verbul ce determină funcționalitatea (verb). Aceste adnotații pot fi ușor inspectate pentru toate documentele, permițând astfel analiza resurselor de procesare.

Portabilitatea. Prin utilizarea arhitecturii modulare a GATE, o aplicație poate fi adaptată noilor nevoi prin simpla înlocuire sau modificare a unor module.

Evaluarea. GATE oferă două mecanisme pentru evaluarea cantitativă. Prima dintre ele, AnnotationDiff, compară două seturi de adnotații adăugate unui document. Această funcționalitate este utilă pentru compararea unui document adnotat automat cu versiunea documentului adnotat manual a aceluiași document sau pentru compararea adnotațiilor făcute de două sisteme diferite, sau de două versiuni ale aceluiași sistem. Celălalt instrument de evaluare, instrumentul de stabilire a tiparelor, execută evaluarea la nivel de set de documente, nu la nivel de document individual. Instrumentul compară modul în care o adnotație dată este alocată tututor documentelor în cadrul a două versiuni diferite ale culegerii de documente.

Două implementări concrete

Am implementat ambele metode de învățare a ontologiilor, utilizând GATE. Multe dintre tehnicile pe care se bazează aceste metode erau deja disponibile în GATE. Etapa de analiză lingvistică a metodei bazate pe părțile de vorbire M_POS sau M_PDV, a fost executatpă în întregime prin folosirea resurselor de procesare oferite de GATE: un tokenizer (ANNIE English Tokenizer), un instrument e despărțire în propoziții (ANNIE Sentence Splitter) și instrumentul ANNIE pentru identificarea părților de vorbire. În cazul metodei bazate pe dependențe, M_DEP, procesarea lingvistică a fost realizată folosind MINIPAR. Pentru ambele abordări, modelele de extragere au fost implementate prin utilizarea mecanismului bazat pe reguli de exprimare JAPE, care este o parte a GATE. Ultimele două etape sunt executate simultan de un singur modul (Proiectarea și Filtrarea Ontologiilor – Ontology Building & Pruning), care a fost implementat ca resursă de procesare GATE, fiind utilizabil din interfața utilizator GATE. Datele utilizate de aceste metode, cum sunt informațiile lingvistice și structurile identificate de modele, sunt reprezentate sub forma adnotațiilor asupra textului analizat. Ambele reguli de extragere și module individuale reprezintă rezultatele obținute sub forma adnotațiilor.

Prin utilizarea GATE pentru implementare am putut reutiliza mai multe librării existente pentru gestiunea documentelor și pentru reprezentarea ontologiilor. Prin declararea părților metodei ca resurse de procesare GATE și prin folosirea sistemului bazat pe adnotații ca mecanism de transfer al datelor între aceste părți, instrumentul poate fi rulat și gestionat prin intermediul interfeței GATE. Astfel, se pot proiecta și configura aplicații modulare prin selectarea vizuală a resurselor de procesare existente, se pot selecta diverse colecții de documente sau se pot cerceta ieșirile bazate pe adnotații ale fiecărui modul de procesare. Toate aceste lucruri permit o depanare facilă și asigură transparența proceasului de extragere, crescând astfel gradul de utilizabilitate a acestui instrument. Am folosit facilitățile de stocare și evaluare ale mediului GATE pe parcursul dezvoltării sistemului prototip.

Suport vizual pentru învățarea ontologiilor

Există unele sisteme care utilizează tehnicile de vizualizare pentru domeniul Web-ului semantic. Instrumentele de scriere a ontologilor oferă facilități de vizualizare care sunt utile în etapa de dezvoltare a ontologiilor. Prin analizarea acestor instrumente, se observă că vizualizarea folosită de instrumentele de scriere este în principal bazată pe scheme. Motivul acestui lucru îl constituie faptul că utilizatorii acestor instrumente sunt ingineri de ontologii, care trebuie să perceapă complexitatea ontologiei construite. De aceea, aceste instrumente implică tehnici de vizualizare a schemelor care se bazează pe structura ontologiei, pe conceptele ei și relațiile existente în cadrul acesteia. Vizualizarea schemelor nu face diferență din punct de vedere grafic între informațiile schemelor și instanțe, nepermițând vizualizarea multor instanțe și prezentarea elementelor de nivel comune mai multor clase.

În afară de instrumentele de scriere a ontologiilor, există trei abordări de învățare a ontologiilor care implică utilizarea tehnicilor vizuale. Instrumentul TextToOnto implică o vizualizare bazată pe schema TouchGraph pentru a prezenta ontologiile extrase. Este dezvoltată o tehnică de vizualizare pentru a prezenta termenii relaționați extrași din cadrul unei culegeri de documente. Text2Onto se axează pe vizualizarea bazată pe grafuri a conceptelor extrase. Deși sunt foarte utile, aceste vizualizări prezintă relațiile dintre entitățile de același tip, cum ar fi conceptele și termenii. Totuși, din cauza complexității învățării ontologiilor, este foarte importantă cunoașterea modului de inter-relaționare dintre entitățile de tipuri diferite. Pentru realizarea acestui lucru, am utilizat harta clusterelor, o tehnică vizuală dezvoltată de compania daneză Aduna. Spre deosebire de tehnicile de vizualizare utilizate bazate pe scheme, tehnicva hărților clusterelor a fost optimizată pentru vizualizarea ontologiilor instanțiate extinse.

Harta clusterelor este utilizată pentru a vizualiza ontologiile nedetaliate care descriu un domeniu prin intermediul unei serii de clase (concepte) și a relațiilor dintre ele. Această tehnică vizualizează instanțele unui set de clase conform clasificării acestora în clase. Datorită relației de specializare din interiorul ierarhiei, setul de obiecte dintr-o subclasă este un subset al superclasei sale. Setul subclaselor unei clase este incomplet dacă prin unificarea acestora nu sunt obținute toate obiectele unei superclase. Clasele care au instanțe comune nu sunt disjuncte, dacă nu le separă o anumită relație de specializare. Aceste caracteristici sunt comune taxonomiilor. Totuși sunt dificil de reprezentat textual sau cu ajutorul tehnicilor bazate pe scheme, care sunt utilizate în Web-ul semantic. Harta clusterelor este o alternativă în acest domeniu.

Figura 7.6. Exemplul unei hărți de clustere

Figura anterioară prezintă un exemplu pentru o hartă de clustere care vizualizează un set de documente clasificate în funcție de temele discutate în cadrul documentelor. Fiecare sferă reprezintă o instanță. Clasele sunt reprezentate sub forma unor dreptunghiuri cu marginile rotunjite, în cadrul cărora sunt incluse numele și cardinalitățile lor. Marginile direcționate conectează clasele și fac trecerea de la specific la general. Marginile în formă de balon realizează conectarea instanțelor cu cele mai specifice clase ale lor. Instanțele care aparțin aceleiași clase sunt grupate în clustere. Exemplul conține patru clustere, unul dintre ele reprezentând corespondența între clasele de Load Management (Management al sarcinilor) și Energy Management (Management al Energiei).

Organizarea grafului este realizată prin folosirea algoritmului de includere a ramificațiilor. Fiecare nod de tip clasă, respectiv cluster, se resping. Marginile ce conectează două clase sau clusterele cu clasele lor produc o forță de atracție între nodurile conectate.

Vizualizarea propusă este valoroasă datorităn expresivității sale. Clasele și relațiile dintre ele pot fi detectate ușor. Este vizibil imediat care elemente aparțin mai multor clase sau uneia singure, care clase sunt disjuncte, și care nu. Aceste subclase ale clasei rădăcină sunt incomplete, deoarece prin conjuncția lor nu se obține toată superclasa, unii membrii din clasa Management nefiind clasificați.

Un alt aspect important al vizualizării este faptul că apropierea geometrică din cadrul hărții este legată de apropierea semantică, acest lucru fiind o consecință a algoritmului de aranjare sub forma unui graf. Clasele sunt apropiate din puncte de vedere semantic dacă multe obiecte ale lor sunt comune. Obiectele sunt apropiate din punct de vedere semantic dacă aparțin aceleiași clase.

În cadrul prototipului am adaptat harta clusterelor pentru a putea susține situațiile frecvent întâlnite de pe parcursul dezvoltării și utilizării unei metode pentru învățarea ontologiilor. Aceste vizualizări diferite au fost incluse în mediul GATE sub forma unor plugin-uri. Unul dintre plugin-uri permite evaluarea extragerii ontologice, completând astfel instrumentele de evaluare a textului oferite de GATE. Al doilea plugin vizualizează ontologia extrasă și arată modul de relaționare a conceptelor derivate pe baza documentelor din cadrul cărora au fost extrase. Al treilea plugin permite identificarea ajută la identificarea conceptelor ce au fost derivate din mai multe surse de date în cazul îăn care învățarea ontologiei a fost executată pe mai multe culegeri de documente.

Descrierea situației

Metodele de învățare a ontologiilor nu sunt perfecte. În afara extragerii conceptelor irelevante, sunt limitate din punct de vedere al grupării conceptelor în concepte mai generale, cât și în descoperirea relațiilor existente între ele. De aceea, orice ontologie extrasă automat trebuie să fie inspectată de un expert în domeniu care să stabilească relevanța conceptului și să îmbunătățească ontologia cu relații și abstractizări importante. Pentru înțelegerea semnificației unui concept și pentru evaluarea ciorectitudinii sale, este necesară cunoașterea contextului în care conceptul este utilizat în cadrul unui document. Pentru a descoperi noile relații dintre concepte, trebuie stabilit modul în care conceptele interacționează în cadrul documentului.

Vizualizarea propusă

Pentru a realiza aceste sarcini de analiza, am utilizat harta clusterelor într-un mod tradițional. Fiecare concept extras formează o clasă a hărții, documentele din care a fost extras devenind instanțe ale sale. Fiecare instanță conține poziția termenilor ce formează concepte derivate. Documentele din cadrul cărora nu a fost învățat nici un concept sunt adăugate în clasa Top.

Exemple

Această vizualizare permite accesarea tuturor documentelor din care a fost învățat conceptul. Accesul rapid la informațiile de evidență este esențial pentru înțelegerea semnificației conceptului.

Pentru a determina relațiile din cadrul unui set de concepte extrase, aceste concepte simt vizualizate, iar imaginea rezultată este analizată. Am vizualizat conceptele de funcționalitate extrase din domeniul bioinformaticii. Apar două grupe de funcționalități interconectate (Părțile A și B din figura 7.8). Fiecare grup reprezintă funcționalități care sunt deseori oferite simultan de serviciile Web. Prima grupă, A conține funcționalități ce analizează sau modifică partea de conținut, în timp ce partea B conține funcționalități de intrare și de ieșire, cum ar fi Citirea și Scrierea. Expertul din domeniu poate accesa și inspectta documentele care leagă aceste concepte și poate decide dacă este cazul stabilirii unor categorii abstracte (Servicii de Conținut și Servicii de Intrare – Ieșire).

În alt exemplu, partea D a figurii, am vizualizat atât conceptele de metodă (Evaluare și Creare), cât și pe cele de tip al structurii de datederivate din primul studiu de caz al magaziilor RDF. Se formează două grupuri de termeni în jurul verbelor. Apropierea vizuală a acestor concepte sugerează că au unele caracteristici comune. Primul grup, din Evaluare, conține concepte implicate în evaluarea unei interogări (Server Sesame, Depozit, Interogare). Al doilea grup conține concepte care descriu elementele modelului de date RDF. În principiu, această vizualizare este echivalentă cu tehnica restricției de selecție, utilizată deseori în domeniul învățării ontologiilor pentru a determina concepte conectate din punct de vedere semantic. Această tehnică identifică termenii ce apar des în cadrul aceluiași context sintactic și care sunt conectați și din punct de vedere semantic. Spre exemplu, obiectele verbului “ a conduce” din “Ea conduce o mașină” și “El conduce un camion” au caracteristica de a putea fi conduse, aparținând aceleiași clase, și anume Vehicul.

O altă activitate pe care trebuie să o realizeze dezvoltatorul metodei este măsurarea capacității de acoperire a domeniului de către ontologie. În cadrul aplicației prezentate, fiecare document trebuie descris de cel puțin o metodă și de o structură de date. Totuși, la vizualizarea tuturor documentelor din culegerea de documente (Top) din care a fost extras conceptul de Metodă și din care a rezultat un concept de structură de date, doar 101 din 156 de documente îndeplinesc cerințele, iar din 26 de documente nu a fost extras nici un concept. Documentele care nu asigură existența niciunui concept pot fi identificate ușor și se pot stabili motivele apariției acestui dezavantaj. Rezolvarea acestei probleme poate îmbunătăți învățarea ontologiilor.

Deși este flexibilă, paradigma hărții clusterelor necesită experiență pentru a putea fi utilizată la potențial maxim. Acest lucru este valabil în special în cazul în care rolul de clase și de instanțe este jucat de entități diferite. Pentru un utilizator începător, schimbarea modurilor de vizualizare poate fi foarte dificilă.

Tehnicile vizuale pot îmbunătăți dezvoltarea și utilizarea metodelor de învățare a ontologiilor. În mod normal, harta clusterelor nu constituie singura metodă utilizată, alte tehnici putându-se dovedi utile pentru rezolvarea anumitor situații.

7.6. Evaluarea

Evaluarea este o parte integrantă a procesului de dezvoltare a oricărui instrument sau algoritm. Realizarea evaluării mediului prezentat este dioficilă, deoarece nu există metode sau criterii bine definite pentru evaluarea algoritmilor de învățare a ontologiilor. Am realizat două evaluări parțiale, pe măsura dezvoltării metodelor din cadrul mediilor. Am verificat performanța metodei ”parte de vorbire” (M_POS sau M_PDV) asupra seturilor de date din cadrul studiului de caz 1 și am evaluat metoda bazată pe filtrarea dependențelor (M_DEP) în contextul studiului de caz 2. Mediul este aplicabil în mai multe domenii, deoarece ambele metode au rezultate similare asupra seturilor de date din discipline diferite.

Evaluarea învățării ontologiei este o problemă importantă, dar în cele mai multe cazuri nerezolvată. Evaluarea metodelor de învățare a ontologiilor bazate pe text se realizează în două:

Evaluarea la nivel de termen verifică performanța extragerii termenilor relevanți pentru învățarea ontologiilor din cadrul culegerii de documente. Această evaluare poate fi realizată prin utilizarea metricilor recunoaștere și părecizare.

Evaluarea calității ontologiei tratează calitatea ontologiei învățate, care este, de regulă, proporțională cu performanța aplicației care o utilizează.

7.6.1. Criteriile de evaluare alese

Pentru a evalua calitatea ontologiei am ales evaluarea conceptelor din domeniu.

Extragerea termenilor se axează pe stabilirea performanței modulelor de extragere a termenilor. Pentru a măsura performanța acestor module am identificat manual toți termenii relevanți care trebuie să fie extrași din cadrul documentelor. Termenii ortografiați greșit nu sunt luați în considerare pentru etapa de extragere. Am utilizat instrumentul Benchmark Evaluation din cadrul GATE pentru a compara acest set de termeni cu cei identificați părin extragerea bazată pe tipare. Se folosește Recunoașterea Termenilor (TRecall) pentru a determina procentajul termenilor relevanți care sunt extrași din cadrul documentelor analizate (correct extracted) față de totalitatea termenilor care trebuie extrași din documente (all corpus). Precizia termenilor (TPrecision) determină rata termenilor extrași corect față de totalitatea termenilor care au fost extrași (all extracted). De asemenea se calculează Media armonică Fmeasure prin alocarea de coeficienți de importanță egali atât recunoașterii, cât și preciziei.

TRecall = correct extracted / all corpus ; TPrecision = correct extracted / all extracted

Figura 7.7. Rezultatele extragerii termenilor pentru ambele studii de caz

Figura 7.8. Strategiile de evaluare alese

Fmeasure = 2*TPrecision*TRecall / (TPrecision + TRecall).

7.6.2. Evaluarea expertului

În această etapă de evaluare expertul în domeniu realizează o evaluare la nivel de concept a ontologiei învățate. Se calculează precizia ontologiei, care reprezintă procentul conceptelor relevante pentru domeniu din cadrul ontologiei extrase (OPrecision). Standardele Gold proiectate manual omit anumite concepte sau introduc alte concepte care nu există în cadrul documentelor. De aceea, pentru această etapă de evaluare, expertul în domeniu face diferența între două categorii de concepte relevante: acelea care există în standardul Gold (correct) și acelea care sunt omise de acest standard (new). Conceptele irelevante sunt marcate ca fiind false (spurious).

Oprecision = (correct + new) / (correct + new + spurious)

De asemenea este evaluată calitatea relațiilor taxonomice. Pentru aceasta este determinat numărul de relații taxonomice descoperite între conceptele relevante (allRelsRelevant) din domeniu. În continuare un expert stabilește câte dintre relațiile taxonomice exprimă o relație isA relation (all RelsCorrect). Mărimea TaxoPrecision reprezintă raportul relațiilor isA corect identificate la totalitatea relațiilor taxonomice dintre conceptele relevante din domeniu care au fost descoperite automat.

TaxoPrecision = all RelsCorrect / allRelsRelevant

Figura 7.9. Rezultatele primului studiu de caz, pentru evaluarea expertului și compararea ontologică

Figura 7.10. Rezultatele celui de-al doilea studiu de caz, pentru evaluarea expertului și compararea ontologică

7.6.3. Compararea ontologică

În ultima etapă de evaluare, ontologia extrasă este comparată cu ontologiile proiectate manual după standardele Gold din domeniile corespunzătoare. Pentru compararea lexicală, prima mărime arată conceptele comune din cadrul ontologiilor manuale și extrase. Această mărime este denumită numărul relativ de potriviri sau potrivirea lexicală (Lexical Overlap = LO). LO1 reprezintă conceptele extrase relevante pentru domeniu (correct și new) și LO2 este totalitatea conceptrelor din standardele Gold. Potrivirea lexicală se calculează ca raport dintre numărul de concepte comune din ambele ontologii (correct = intersecția acestor două seturi) și numărul tuturor conceptelor din standardele Gold, notat all. Această mărime este echivalentă cu recunoașterea, în timp ce Oprecizion definește precizia. Dacă două sau mai multe concepte corect extrase sunt echivalente cu un singur concept din standardul Gold (AddModel, LoadOntology sunt echivalente cu AddOntology) este numărat numai unul dintre ele. De aceea LO1 LO2 conține doar concepte individuale, notate correct i.

LO (O1, O2) = | LO1 LO2 | / | LO2 | = correct / all

Ontologia extrasă poate să aducă ontologiei manuale unele adăugări importanteprin sublinierea conceptelor care au fost ignorate pe parcursul proiectării sale. De aceea, am definit mărimea Imbunătățirea Ontologiei (Ontology Improvement = OI) ca raport între toate conceprtele relevante pentru domeniu care nu sunt în standardul Gold (notate new) și toate conceptele din standardul Gold.

OI (O1, O2 ) = | LO1 \ LO2 | / | LO2 | = new / all

Pentru compararea structurilor taxonomice ale standardului Gold și a ontologiei extrase se utilizează o strategie similară cu cea din etapa evaluării expertului. În primul rând este determinat numărul relațiilor taxonomice descoperite între două concepte ale standardului Gold (allRelsRelevantGS). Apoi este calculat numărul relațiilor considerate ca fiind relații isA în cadrul standardului Gold (allRelsCorrectGS). Mărimea TaxoPrecisionGS este raportul acestor numere.

TaxoPrecisionGS = allRelsCorrectGS / allRelsRelevantGS

Compararea taxonomică poate fi realizată ușor deoarece ierarhiile comparate deoarece ierarhiile comparate nu au multe nivele, iar potrivirea acestora este redusă.

Figura 7.11. Rezultatele evaluării taxonomice pentru primul studiu de caz, domeniul RDF

Figura 7.12. Rezultatele evaluării taxonomice pentru al doilea studiu de caz, domeniul bioinformaticii

7.6.4. Documente experimentale

Documentele experimentale sunt furnizate de proiectele discutate.

Studiul de caz 1: Instrumentele RDF

Prima culegere, C_RDFS, conține 112 documente extrase din documentația instrumentelor utilizate pentru proiectarea ontologiei manuale. Fiecare document din culegere conține descrierea javadoc a unei metode. Descrierile textuale scurte ale acestor metode conțin majoritatea informațiilor și alte documente javadoc, cum ar fi sintaxa metodei și descrierea parametrilor diminuează performanța extragerii. De aceea, aceste descrieri scurte sunt folosite doar în cadrul experimentelor. De asemenea, este exclusă sintaxa metodei, deoarece introduce termeni tehnici nerelevanți, cum ar fi java, com, org. Pentru exemplificare sunt prezentate unele descrieri ale descreierilor analizate:

Listează toate resursele care sunt subiectul propozițiilor. Operațiile derivate asupra acestor resurse pot modifica modelul. (Jena).

Returnează o resursă url unică pentru model (KAON).

Reînnoiește datele din fluxul de intrare, introducânduâle într-un depozit de cuvinte. (Sesame).

Studiul de caz 2: Serviciile Bioinformatice

Culegerea de documente pentru acest domeniu, C_BIO, conține 158 de descrieri ale serviciilor bioinformatice individuale, care sunt disponibile în cadrul site-ului web EMBOSS. Descrierile detaliate ale serviciilor EMBOSS prezintă o aranjare specifică, ce permite o extragere mai facilă a ontologiei. Totuși, prin utilizarea acestei organizări ar fi axat metodele de extragere propuse doar pe acest tip de documentații. De aceea, se analizează numai aceste descrieri scurte:

Înlocuiește sau șterge secțiunile secvențiale.

Găsește locuri antigenice în proteine.

Statistica utilizării cai codon.

7.7. Concluzii

Scopul acestui capitol îl constituie proiectarea unui instrument pentru învățarea semiautomată a ontologiilor în contextul serviciilor Web. Învățarea ontologiilor în contextul serviciilor Web ridică multe părobleme pe lângă acelea din învățarea ontologiilor în general. Obiectivul capitolului îl reprezintă discutarea și testarea tehnologiilor ce pot fi utilizate. Am tratat o serie de probleme fundamentale, cum ar fi: selectarea sursei de date, alegerea algoritmilor de învățare potriviți, stabilirea metodologiilor ți mărimilor de evaluare și considerarea utilității.

Selectarea surselor de date

Învățarea tradițională a ontologiilor se axează pe învățarea ontologiilor care descriu o serie de documente textuale. În acest caz sursele de date pentru învățarea ontologiei sunt sursele textuale. Totuși, există mai multe surse de date posibile, care pot fi utilizate pentru învățarea ontologiilor din domeniul serviciilor Web. În primul rând resursele conectate la implementarea care se află la baza ontologiei furnizează cunoștințe utile referitoare la funcționalitatea serviciului Web, deoarece serviciile Web sunt produse software care sunt accesibile pe Internet. De exemplu, codul sursă, documentația sa sub formă de text sau diagramele UML existente. În al doilea rând se pot utiliza surse de date specifice serviciilor Web, cum ar fi fișierele WSDL asociate sau log-urile de activitate.

Pe parcursul lucrării am observat că serviciile Web sunt însoțite , în majoritatea cazurilor de o scurtă descriere textuală a funcționalității lor, ceea ce ajută la o înțelegere rapidă a acțiunii realizate de serviciu. Astfel de descrieri există în cadrul magaziilor on-line ale serviciilor Web, cum ar fi XMethods, sau în documentațiile codurilor de tip java.doc. deși sunt sursele cele mai disponibile, descrierile textuale minimale ale serviciilor Web sunt caracterizate printr-o calitate gramaticală redusă și utilizează un sublimbaj specific care asigură procesarea lor automată.

Alegerea tehnicilor de învățare

Obiectivul lucrării îl constituie adaptarea tehnicilor existente de învățare a ontologiilor pentru domeniul serviciiilor Web și nu dezvoltarea altor tehnici noi. Alegerea acestor tehnici depinde de tipul surselor de date considerate. De exemplu, diagramele UML necesită tehnici de transformare semantică foarte diferite de tehnicile de procesare a limbajului natural utilizate pentru sursele textuale. Am proiectat un mediu pentru învățarea ontologiilor ce utilizează descrierile textuale ale serviciilor Web și, în cadrul acestui mediu, am implementat două metode bazate pe tehnicile de procesare a limbajului natural. Pe parcursul proiectării și evaluării acestui mediu am observat următoarele:

Tehnicile simple funcționează corect în cadrul contextelor bine definite. Deși metodele utilizate sunt bazate pe tehnicile simple de extragere a termenilor și de proiectare a ontologiilor, calitatea ontologiilor învățate este bună, deoarece sarcina de învățare a ontologiilor este bine definită și este realizată asupra textelor specializate, cu caracteristici puternice de sublimbaj;

Analiza lingvistică amănunțită mărește performanța. Metoda bazată pe relația de dependență are rezultate mai bune decât metoda bazată pe identificarea părților de vorbire. În primul rând mărește gradul de recunoaștere a extragerii termenilor din cadrul documentelor, influențând negativ foarte puțin precizia extragerii termenilor. Deși tehnologiile extrase sunt mai puțin precise, valorile de îmbunătățire și potrivire ontologică sunt mai mari;

Utilizarea mediului GATE face posibilă proiectarea unui instrument independent de domeniu. Caracteristicile de sublimbaj pe baza cărora sunt construite metodele utilizate pot fi identificate în cadrul descrierilor serviciilor Web scrise pentru diverse domenii. De aceea se poate priecta un instrument de învățare a ontologiilor special pentru serviciile Web, ce poate fi folosit în diverse domenii aplicative. Acest lucru rezultă din faptul că ambele metode utilizate au rezultate similare în două domenii diferite.

Performanța mediului prezentat poate fi sporită prin extinderea metodei cu alte tipare de extragere mai complexe. Tehnicile de învățare computațională pot ajuta la descoperirea unor noi modele. De asemenea, se poate îmbunătăți etapa de proiectare a ontologiilor. Utilizarea informațiilor de sinonimie pe parcursul fazei de conceptualizare constituie o importantă posibilitate de dezvoltare.

Evaluarea

Evaluarea calității unei ontologii este dificilă, deoarece standardele Gold nu reprezintă cu corectitudine cunoștințele din cadrul documentației. Experții în domeniu omit numeroase concepte, deoarece nu se pot citi și analiza toate documentele într-un interval rezonabil de timp. Metodele propuse extrag ontologii care conțin un procentaj ridicat de concepte relevante din domeniu. Cantitatea conceptelor extrase poate fi influențată de modificarea algoritmilor de filtrare.

În cadrul lucrării, am utilizat o serie de metode pentru îmbunătățirea calității ontologiilor serviciilor Web și pentru facilitarea procesului de proiectare a lor, având ca obiectiv realizarea unui suport pentru cercetarea serviciilor Web-ului semantic. Deși au fost discutate mai multe probleme referitoare la acest domeniu, cercetarea va fi aprofundată, încercând să se crească performanța metodelor propuse pentru proiectarea și învățarea ontologiilor din domeniul serviciilor Web.

Bibliografie