Produs Program Pentru Laboratorul de Lingvistica
Produs program pentru laboratorul de lingvistică
Introducere
1.1 Procesarea limbajelor naturale
Domeniul de acțiune al procesării limbajelor naturale (NLP – Natural Language Processing) s-a schimbat dramatic în ultimii ani. Dacă acum cinci ani problemele în acest domeniu se concentrau doar pe aspecte teoretice, cum ar fi reprezentarea cunoștințelor, astăzi s-a ajuns la aplicații specifice, sisteme de evaluare și, mai mult, la sisteme de procesare a limbajelor naturale pe scară largă.
Problema care se pune în momentul actual este nevoia de a introduce metode de analiză a limbajului scris și vorbit pe baza unei munci de culegere a acestuia utilizând multitudinea de texte incluse în text-corpora ( o colecție vastă de texte, limbaj scris și vorbit). Acest lucru se poate realiza folosind dicționare electronice în ideea de a dezvolta sisteme rapide de analiză. În acest sens guvernul SUA a demonstrat un interes deosebit nu numai în cazul procesării de corpora în limba engleză, dar și pentru alte limbi. Procesarea de corpora în limba engleză a devenit, astfel, o bază de dezvoltare pentru aplicații de interes în diferite limbaje, altele decât cele anglo-saxone.
Interesul pentru acest domeniu s-a materializat într-o formă instituționalizată, punându-se astfel bazele “Consorțiului Lingvistic ( Linguistic Data Consortium )” la Universitatea Pennsylvania (Pennsylvania University ) și a “Consorțiului de Cercetare Lexicală ( Consortium for Lexical Research) ” la Universitatea din New Mexico ( New Mexico State University ) cu ajutorul unor fonduri guvernametale. Prin aceasta s-a dorit consolidarea resurselor teoretice obținute pănă atunci, cooperarea internațională în documentarea și cercetarea în domeniu. Dar, poate cel mai mult, s-a dorit, realizarea și testarea de sisteme de analiză a limbajelor naturale, care puteau astfel fi testate pe scară largă în dorința de a obține performanțe mai bune. S-a dorit, prin aceasta, realizarea de conexiuni cu baze de date ce conțin părți de corpora scrisă sau vorbită care să permită extragerea rapidă a informației din texte de dimensiuni medii și mari.
Vorbirea liberă este, fără nici un dubiu, esența limbajului natural. Anumiți lingviști au iterat pericolul pe care îl reprezintă privirea pur automatizată asupra limbajului natural, arătând faptul că vorbirea liberă este un proces continuu evolutiv care nu poate fi inclus într-o rigurozitate totală impusă de un produs program definitoriu. Totuși, firma IBM a reușit să încorporeze metodologia vorbirii într-o mașină de traducere bazată pe o vastă corpora în mai multe limbi.
Dar aceste aplicații de anvergură în domeniul analizei limbajelor naturale nu sunt specifice numai Statelor Unite. Astfel, în Japonia, analiza limbajelor naturale stă la baza realizării proiectului “ Generația a 5 –a ( the Fifth Generation Project )”. Acest proiect pune accentul pe interpolarea dintre analiza limbajelor naturale și inteligența artificială ca un tot unitar. Această abordare este unică, spre deosebire de abordările europene sau americane. “Centrul de Cercetare Dicționare Electronice ( The Electronic Dictionary Research Center ) “ a fost creat la Tokyo pentru a studia și accentua rolul pe care dicționarele electronice de mare anvergură îl au în realizarea unei analize a limbajelor naturale de o acuitate ridicată.
În Europa a existat proiectul Eurotra , o mașină de traducere automată finanțată de Uniunea Europeană timp de 10 ani, în ideea de a realiza o traducere multilingvă cu cel puțin calitatea sistemului Systran ( un cunoscut sistem de traducere automata multilingvă implementat în SUA ). Totuși, în final, s-a renunțat la proiect chiar dacă perioada de “training” – acumulare și învățare – a mașinii a fost destul de îndelungată.
Mult mai productive au fost proiectele de mare anvergură în domeniul analizei lexicale precum Aquilex și Genelex care au avut ca scopuri aceleași ca și cele din SUA sau Japonia, dar cu o modalitate diferită de abordare a problemelor, rezultate din cooperarea internațională necesară unui organism ca Uniunea Europeană.
Extragerea informației
Introducere
Numărul de texte care se află la un moment dat în format electronic poate depăși imaginația celui mai vizionar lingvist sau specialist în domeniul analizei limbajelor naturale, pe baza unei corpora de limbă vorbită sau scrisă. Totuși, această imensă cantitate de informație poate fi ignorată deoarece nici o ființă umană nu poate citi, înțelege și sintetiza megabytes de text dintr-o vastă panoplie de domenii. Informații neglijate și oportunități pierdute la un moment dat din cauza mărginirii capabilităților ființei umane i-a determinat pe specialiști să dezvolte diferite strategii de management informațional pentru a stabili reguli stricte în “jungla” informațională actuală.
Astfel, cele mai comune strategii sunt captarea informației utile ( IR – Information Retrieval ) și filtrare informației. O abordare relativ nouă a celei din urmă poartă numele de extragerea informației ( IE – Information Extraction ).
Putem vedea sistemele de captare a informației utile ( IR systems ) ca niște combine agricole care “adună” material folositor din texte din domenii diferite, aflate sub formă electronică. Cu cantități deosebite de informație astfel culeasă, un sistem de extragere a informației ( IE system ) poate transforma acest vast material, prin rafinare și reducere, la un format asemănător cu textul inițial dar cu posibilități mult mai mari de regăsire a informației. Să presupunem că un analist financiar investighează producția de semiconductori a unei companii producătoare de astfel de subansamble. Astfel, el este interesat de anumite lucruri, cum ar fi:
care sunt produsele chimice care trebuie incluse în procesul de producție aflate în depozitele întreprinderii;
cât de subțiri sunt semiconductorii obținuți;
temperatura de producție;
cine utilizează produsul astfel obținut.
Astfel de informații sunt adesea regăsite în diverse articole din ziare și reviste de specialitate. În acest moment sistemele de captare a informației utile ( IR systems ) pot colecta articolele cu texte relevante în acest domeniu și în acestă problemă, în particular. Sistemul de extragere a informației ( IE system ) pornește cu o colecție de astfel de texte filtrate după domeniul specific al problemei prezentate anterior. Apoi le transformă în informații care pot fi mult mai bine citite și analizate de către specialistul în cauză.
Sistemul de extragere a informației ( IE system ) “izolează” fragmente de text relevante pentru aspectele problemei, extrage informația relevantă din aceste fragmente și apoi așează informația cerută într-o formă coerentă, ușor de citit și analizat. De exemplu, un articol poate cuprinde informații referitoare la diferite substanțe chimice, temperaturi, procese și specificații tehnologice, însă, doar una sau mai multe informații dintre acestea este de interes pentru un specialist. De aceea, scopul sistemului de extragere a informației ( IE system) este de a găsi și lega informații relevante concomitent cu ignorarea celor ce nu sunt relevante sau sunt redundante.
Sistemul de extragere a informației ( IE system ) are numeroase posibilități de utilizare. De exemplu, informația disponibilă într-un text nestructurat poate fi translatată în baze de date pe care diferiți utilizatori le pot interoga standard, în dorința de a obține informații utile și necesare. De exemplu, dorim să obținem informații referitoare la profitul obținut de societăți de exploatare forestieră dintr-o anumită țară și să le comparăm cu cele din altă țară. Informația relevantă cuprinde numele companiei, naționalitatea, apartenența la industria forestieră și mărimea defalcată pe domenii a profitului companiei respective. Un sistem de extragere a informației ( IE system ) în acest domeniu care studiază știrile din domeniu poate updata o bază de date odată ce informațiile căutate devin disponibile și satisfac cerințele exprimate anterior. Astfel, acest sistem determină noile apariții în domeniu, cu informațiile atașate corespunzător referitoare la cerințele respective ale problemei.
Alte sisteme de extragere a informației ( IE systems ) pot procesa diferite canale de știri, agenții de presă, obținând informații referitoare la întâlnirile dintre diferite personalități marcante ale momentului, formarea de noi companii, sau anunțurile legate de apariția a noi produse pe piață.
Extragerea informației și limbajele naturale
Din punctul de vedere al analizei limbajelor naturale, extragerea informației este atractivă din mai multe motive, printre care se află și acestea:
extragerea informației este bine definită;
sistemele de extragere a informației ( IE systems ) folosesc texte comune ce conțin fragmente de corpora ( limbaj scris și vorbit );
sistemele de extragere a informației ( IE systems ) rezolvă o serie de probleme importante și interesante în cadrul analizei limbajelor naturale;
performața sistemelor de extragere a informației ( IE systems ) poate fi comparată cu cea umană, din punct de vedere a realizării acelorași sarcini;
Faptul că perfomanțele sistemelor de extragere a informației ( IE systems ) pot fi comparate cu cele umane în aceleași domenii, a atras atenția a numeroși specialiști dar și a diferitelor agenții guvernamentale, care au pus bazele în SUA a proiectului “ ARPA’s Tipster Text Program ”, care coordonează numeroase grupuri de cercetători și agenții guvernamentale în încercarea de a îmbunătăți performanțele sistemelor de colectare și de extragere a informației ( IE systems ).
O mică diferență față de sistemele de extragere a informației ( IE systems ) din text o reprezintă sistemele de extragere a cunoștințelor (Knowledge Extraction Systems).
Sistemele de extragere a cunoștințelor (Knowledge Extraction Systems) trebuie să facă față acelorași tipuri de probleme întâmpinate și de sistemele de extragere a informației ( IE systems ), dar spre deosebire de acestea din urmă, sistemele de extragere a cunoștințelor (Knowledge Extraction Systems) caută să deducă o regulă de bază sau model de domeniu pe baza tehnică a textului analizat. Acest efort include o puternică componentă-mașină care poate ”învăța” alături de componenta standard de analiză a limbajului natural. Sistemul de extragere a cunoștințelor (Knowledge Extraction System) se bazează pe ideea sistemelor expert sau a sistemelor decizionale. Acest proiect referitor la sistemele de extragere a cunoștințelor (Knowledge Extraction Systems) este unul mult mai îndrăzneț decât cel al sistemelor de extragere a informației ( IE systems ), în care rezolvarea problemelor implicate de utilizarea lor în analiza limbajelor naturale se leagă, în mare parte, de completarea unui formular rezultat din metodele de “învățare” ale sistemului.
Tipuri de sisteme de extragere a informației ( IE systems )
Unul dintre primele sisteme de extragere a informației ( IE systems ) care opera pe texte cu o topică nerestrictivă a fost implementat de Gerald deJong. Acesta a utilizat rețeaua de transmitere a știrilor a unei agenții de presă ca sursă pentru textele de analizat. Programul lui deJong numit FRUMP monitoriza această rețea cu ajutorul unor scripturi simple destinate pentru a verifica fiecare tip de știre în momentul emiterii ei. FRUMP realiza potrivirea fiecărei știri cu un script relevant pe baza unor cuvinte cheie și pe baza unei analize conceptuale a frazei. FRUMP era un sistem orientat pe semantica frazei, care utiliza presupuneri pe domenii specifice pentru a instanția descrieri de evenimente bazate pe cunoașterea scriptică.
Un alt proiect creat înainte de FRUMP , în anii 1970, pentru a extrage informația utilă din diferite texte, a fost condus de Naomi Sager pentru grupul “ Linguistic String Project ”, la Universitatea din New York (New York University). Proiectul, sponsorizat de “ American Medical Association ”, s-a dorit să realizeze traducerea fișelor medicale almele de extragere a informației ( IE systems ), dar spre deosebire de acestea din urmă, sistemele de extragere a cunoștințelor (Knowledge Extraction Systems) caută să deducă o regulă de bază sau model de domeniu pe baza tehnică a textului analizat. Acest efort include o puternică componentă-mașină care poate ”învăța” alături de componenta standard de analiză a limbajului natural. Sistemul de extragere a cunoștințelor (Knowledge Extraction System) se bazează pe ideea sistemelor expert sau a sistemelor decizionale. Acest proiect referitor la sistemele de extragere a cunoștințelor (Knowledge Extraction Systems) este unul mult mai îndrăzneț decât cel al sistemelor de extragere a informației ( IE systems ), în care rezolvarea problemelor implicate de utilizarea lor în analiza limbajelor naturale se leagă, în mare parte, de completarea unui formular rezultat din metodele de “învățare” ale sistemului.
Tipuri de sisteme de extragere a informației ( IE systems )
Unul dintre primele sisteme de extragere a informației ( IE systems ) care opera pe texte cu o topică nerestrictivă a fost implementat de Gerald deJong. Acesta a utilizat rețeaua de transmitere a știrilor a unei agenții de presă ca sursă pentru textele de analizat. Programul lui deJong numit FRUMP monitoriza această rețea cu ajutorul unor scripturi simple destinate pentru a verifica fiecare tip de știre în momentul emiterii ei. FRUMP realiza potrivirea fiecărei știri cu un script relevant pe baza unor cuvinte cheie și pe baza unei analize conceptuale a frazei. FRUMP era un sistem orientat pe semantica frazei, care utiliza presupuneri pe domenii specifice pentru a instanția descrieri de evenimente bazate pe cunoașterea scriptică.
Un alt proiect creat înainte de FRUMP , în anii 1970, pentru a extrage informația utilă din diferite texte, a fost condus de Naomi Sager pentru grupul “ Linguistic String Project ”, la Universitatea din New York (New York University). Proiectul, sponsorizat de “ American Medical Association ”, s-a dorit să realizeze traducerea fișelor medicale ale pacienților scrise în limba engleză la o formă care să poată fi folosită de către sistemul de gestiune a bazelor de date discutat la conferința anuală “CODASYL” (Conference on Data Systems Languages).
În anul 1980, DaSilva și Dwiggins au reușit să extragă informații referitoare la mișcarea sateliților geostaționari, din rapoartele trimise de aceștia la mai multe stații de observare astronomică din întreaga lume, dar sistemul era restrâns la propoziții simple și nu cuprindea metodologii de extragere a informațiilor complete referitoare la evenimentele descrise.
În Franța, în anii `80, s-a pus bazele proiectului Zarri legat de sistemele de extragere a informației ( IE systems ). Textele folosite pentru analiză se refereau la acțiunile diferitelor figuri istorice franceze. Sistemul se dorea a fi un mod eficient de extragere a informațiilor referitoare la relațiile și întâlinirile dintre aceste personalități istorice.
În 1981, Cowie a dezvoltat un sistem de extragere a informației ( IE systems ) care extrăgea informații referitoare la structura canonică a unor plante și animale din diferite descrieri. Sistemul folosea informații simple pentru a popula o structură de informații cu formă fixă.
Principala diferență dintre sistemele de extragere a informației ( IE systems ) dezvoltate în anii `80 și cele dezvoltate în anii `90 o reprezintă cantitatea considerabilă de timp și energie necesară pentru a colecta documentele relevante și de a crea o serie de template-uri (“machete”) sau „chei”, care să producă teste de corpora ( colecție de texte ).
De exemplu, deși crearea de texte cu cheile lor asociate de un analist pentru programul de analiză a limbajelor naturale Tipster necesită un efort destul de mare, fizic și financiar, fiind destul de complicat, aceste resurse – textul și cheile lui asociate – au făcut din sistemele de extragere a informației ( IE systems ) un proiect unic și respectat în domeniul analizei limbajelor naturale.
Exemplul din Figura 1 este relevant. Un analist financiar investighează producția de semiconductori a unei companii producătoare de astfel de subansamble. Astfel, el este interesat de anumite lucruri, cum ar fi:
care sunt produsele chimice care trebuie incluse în procesul de producție aflate în depozitele întreprinderii;
cât de subțiri sunt semiconductorii obținuți;
temperatura de producție;
cine utilizează produsul finit astfel obținut.
Astfel de informații sunt adesea regăsite în diverse articole din ziare și reviste de specialitate. În acest moment sistemele de captare a informației utile ( IR systems ) pot colecta articolele cu texte relevante în acest domeniu și în acestă problemă, în particular. Sistemul de extragere a informației ( IE system ) pornește cu o colecție de astfel de texte filtrate după domeniul specific al problemei prezentate anterior. Apoi le transformă în informații care pot fi mult mai bine citite și analizate de către specialistul în cauză.
Figura 1 – Exemplu de IE System
Template-urile (“machetele”) fac posibilă evaluarea performanței sistemelor de extragere a informației ( IE systems ) în analiza textelor.
Interesul DARPA pentru sistemele de extragere a informației ( IE systems ) a determinat punerea bazelor unor unor proiecte de mare anvergură, utilizând diferite modalități de abordare, toate având un scop final comun. De exemplu, proiectul Tipster a fost creat pentru a îmbina sistemele de captare a informației utile ( IR systems ) cu cele de extragere a informației ( IE systems ). În prima parte a realizării proiectului ( 1991 – 1993 ) cercetările în fiecare domeniu amintit anterior s-au desfășurat independent unul de celălalt. În partea a doua a sa, realizatorii proiectului s-au întâlnit lunar în grupuri de lucru pentru a pune la punct modalități comune de rezolvare a unor probleme legate, de exemplu, de adnotarea părților de vorbire și recunoașterea numelor proprii.
Proiectul Tipster încurajează crearea de sisteme portabile și care pot fi reconfigurate. De exemplu, proiectul Murasachi, care permite portabilitatea multilingvă, putând să proceseze texte scrise în două limbi – spaniolă și japoneză. Domeniul acestui proiect este de a prelucra informațiile referitoare la rapoarte apărute în lume care conțin cazuri de Sida. Realizatorii proiectului Tipster au ales ca domenii de acțiune a cercetării lor lumea afacerilor și rapoartele apărute referitoare la inovațiile în tehnica producerii de semiconductori. Independența de limbă și portabilitatea au fost asigurate prin crearea de sisteme care folosesc atât limba engleză cât și limba japoneză. Patru mii de texte și template-uri (“machete”) au fost necesare pentru a “antrena” sistemele create împreună cu alte texte adiționale. Template-urile (“machete”) pentru Tipster au fost create de specialiști familiarizați cu acest tip de sarcină. Rezultatul acestui proiect este o resursă indispensabilă și unică în procesul de analiză a limbajelor naturale.
Tipuri de sisteme comerciale de extragere a informației ( IE systems )
O modalitate de exprimare a viabilității sistemelor de extragere a informației ( IE systems ) o reprezintă apariția pe piață a unor sisteme de acest tip cu format comercial, cu posibilități de utilizare în diferite domenii.
Astfel, printre primele sisteme de extragere a informației ( IE systems ) cu format comercial se numără ATRANS, care a fost creat pentru a superviza telexurile ce cuprindeau transferuri bancare internaționale de monedă. Acest sistem folosea tehnici de analiză a frazei similare cu cele utilizate de sistemul FRUMP și exploata conținutul predictibil al telexurilor ce cuprindeau transferuri bancare internaționale. ATRANS a demonstrat faptul că tehnicile relativ simple de procesare a limbajelor naturale sunt adecvate pentru realizarea de sisteme de extragere a informației ( IE systems ).
JASPER este un alt sistem de extragere a informației ( IE systems ) care folosește rapoartele de achiziții ale unor corporații, adăugând noutăți în ideea robusteții capabilităților de analiză a limbajelor naturale prin tehnici ce cuprind template-uri (“machete”) de analiză textuală, referitoare la fragmente reduse de text. Funcționarea lui JASPER depinde de inspecția manuală a sistemului în timpul funcționării sale, împreună cu evaluarea on-line a rezultatelor obținute pe baza unor seturi de teste reprezentative.
SCISOR este un prototip care încorporează capabilități de extragere a informației într-un sistem integrat ce utilizează analiza parțială a textului de procesat. Un mecanism de filtrare selectează numai articolele legate de achizițiile și fuziunile între diferite corporații, putându-se astfel realiza o extragere fiabilă a informației referitoare la companiile care achiziționează sau sunt achiziționate, precum și prețul pe acțiunea vândută/achiziționată. Aceste informații sunt înregistrate într-o bază de cunoștințe care suportă diferite tipuri de interogări.
Toate aceste sisteme au fost dezvoltate în SUA. Totuși, realizări notabile de sisteme comerciale de extragere a informației ( IE systems ) se regăsesc și în alte țări. Astfel, proiectul Zarri continuă să funcționeze la Paris. Profesorul Udo Hahn de la Universitatea din Freiburg (Germania) cercetează modalități de extragere a informației cu ajutorul microprocesoarelor din articole de reviste. Problema pe care încearcă să o rezolve se referă la topica de bază a structurii unui text. Grupul Fiat din Milano, Italia, folosește capabilitățile oferite de sistemele de extragere a informației ( IE systems ) pentru a procesa rapoartele realizate de mecanici auto. Un grup de la Universitatea din Sussex, Marea Britanie, a dezvoltat un sistem care procesează mesajele din rapoartele poliției rutiere locale. În ultimele două sisteme, mesajele de intrare sunt scurte și nu este nevoie de analiza discursului în cadrul mesajului introdus, deși cele două sisteme trebuie să rezolve probleme de referință între mesajele individuale.
Părțile componente ale unui sistem de extragere a informației
Ultimele cercetări în domeniul extragerii informației au dezvăluit importanța unor domenii de cercetare neglijate până atunci, precum și faptul că metodele simple de analiză sunt adecvate pentru rezolvarea a numeroase probleme legate de analiza textelor.
Astfel, după ultimele standarde în domeniu, un sistem de extragere a informației ( IE system ) are următoarea structură:
Filtrarea – Nivelul text – se determină relevanța unor părți de text sau a unor texte întregi pe baza unor statistici efectuate pe cuvinte sau pe baza apariției unor forme particulare standard.
Adnotarea părților de vorbire – Nivelul cuvânt – se marchează cuvintele cu părțile de vorbire pe care le pot lua. De obicei, se folosesc metode statistice pe texte care nu au fost prelucrate în prealabil.
Adnotarea frazei. – Nivelul parte de frază – recunoașterea unităților sintactice majore în domeniul de analiză și marcarea lor cu informații semantice.
Analiză – Nivelul frazei – mapează elementele constitutive ale frazei într-o structură care arată relațiile dintre ele.
Analiza discursului – Nivelul inter-fraze – realizează suprapunerea și unirea între structurile produse de analiză; recunoaște și unifică expresiile referențiale.
Ieșirea – Nivelul template (machetă) – formatează rezultatele după un format predefinit de ieșire a datelor.
Marea majoritate a sistemelor de extragere a informației ( IE systems) depind de componenete off-line pentru a produce date și reguli care sunt folosite pentru activitățile on-line. Automatizarea și rapiditatea cu care acționează aceste componente sunt indispensabile pentru portabilitatea sistemelor respective. Viteza de acțiune a sistemului în cauză este, de altfel, un factor critic în procesul de obținere a unor rezultate de înaltă calitate și acuratețe în ciclul de dezvoltare a sistemelor de extragere a informației ( IE systems ).
Două aspecte ale activității de procesare a informației cu ajutorul acestor sisteme par a fi comune, și anume:
– programele de adnotare a părților de vorbire în textul analizat pentru a permite o recunoaștere preliminară a părțior de frază în text;
– reguli cu statut special pentru recunoașterea claselor semantice ale unităților frazale, inclusiv a numelor de companii, obiective turistice, nume proprii de persoane, valute și nume de echipamente.
Textele de analizat conțin numeroase nume proprii și expresii pentru date, valori și unități de măsură. Aceste părți de frază sunt folosite în mod uzual de oameni în vorbire și scriere, ele neproducând nici un inconvenient. Totuși, în cadrul programelor de analiză, de exemplu, în cazul proiectului Tipster, regulile referitoare la numele unei companii sunt destul de ambigui într-o formulare de genul : “ Sumaito of Malaysia a anunțat astăzi …” Astfel, programul nu știe dacă “ of Malaysia ” este parte a numelui propriu al companiei sau nu.
Natura acestor unități de vorbire necesită ca să nu fie stocate într-un dicționar de expresii ci să poată fi recunoscute automat de un sistem cu ajutorul unor tipare de subunități de text sau cu ajutorul contextelor de utilizare a acestor expresii. Sistemele de extragere a informației (IE systems) ar trebui să recunoască asemenea construcții cu acuratețe. Pentru unele aplicații o bază de date alcătuită din texte și cuvinte luate din aceste texte permit o analiză de calitate a oricăror texte introduse de utilizator. Aceste capabilități pot oferi suport eficient și pentru sistemele de captare a informației utile ( IR systems ).
Tipster pune la dispoziția utilizatorilor o largă gamă de informații – nume proprii prin extragerea lor din diferite template-uri (machete) sau din resurse standard ( de exemplu, “Tipster Gazetter” conține 250.000 de nume geografice ) și din resurse generate și partajate de utilizatori, ca de exemplu liste cu nume de companii.
Bogăția resurselor lexicale produce numeroase probleme, deoarece ambiguitatea lexicală apare și în cazul numelor proprii. Astfel, pentru textele în limba engleză, scrierea cu majuscule, respectiv, cu litere mici poate rezolva în parte aceste probleme, dar multe din știrile de pe canalele agențiilor de presă este încă transmis numai cu majuscule.
Deoarece multe din părțile de analiză sintactică cuprind substantive proprii, acestea din urmă pot fi folosite pentru a determina unele legături. Astfel, delimitatori precum titlurile (formule politicoase de adresare), ca de exemplu “Dl. (sau Domnul X)”, “Dr.” și determinanții de companii sau societăți comerciale, ca de exemplu “Corp.(Societatea…S.A.)” sau “Inc.(Societatea…srl)” pot fi folosiți cu succes pentru a rezolva problema ambiguității numelor proprii în cazul unor texte de analizat.
Astfel, un dicționar extins poate cuprinde și cuvinte care nu au deja introdusă o explicație, dar care, în conjuncție cu astfel de indicatori pot forma tipare noi de nume proprii.
Performanța, în astfel de cazuri de utilizare a acestor modalități de obținere (îmbogățire) a numelor proprii într-un dicționar, poate fi cuprinsă pe o scară valorică de la 40% până la 90%, în funcție de domeniul și tehnicile folosite.
Utilizarea analizei parțiale a frazei
Analiza parțială a frazei se referă la un stil de analiză a propoziției ca parte componentă a frazei care nu necesită o analiză completă a propoziției pentru a determina toate părțile componente, în vederea unei analize semantice mult mai detaliate. Specialiștii care încurajează crearea de analizoare de propoziții bazate pe analiza semantică a acesteia au argumentat timp de 20 de ani că analiza parțială a frazei este viabilă, dar totuși, în acest sens, nu s-au făcut prea multe. Tradiționalismul în cadrul comunității de cercetători în lingvistică a favorizat analiza sintactică totală a frazei, o idee care a dominat lingvistica computațională timp de aproape 30 de ani.
Din păcate, o analiză sintactică totală a tuturor frazelor dintr-un text este foarte anevoioasă în fața cerințelor numeroase ale utilizatorilor unor astfel de sisteme de analiză, care duc la carențe serioase din punct de vedere al rapidității obținerii de rezultate fiabile. Produse program care doresc să realizeze o analiză sintactică completă a frazelor unui text se găsesc prinse într-un ciclu prea lent de rezolvare a acestei probleme, neavând posibilități de experimentare din partea utilizatorilor cu care au un feed-back redus.
Analiza sintactică completă a frazelor unui text operează într-un timp cu o formă polinomială. Astfel, aceste tipuri de sisteme de analiză completă a textului pot fi blocate dacă se introduc spre analizare texte ce cuprind fraze cu peste 20, 30 cuvinte fiecare. Această problemă i-a determinat pe specialiști să ia în considerare posibilitatea de analiză sintactică parțială a frazelor unui text. Unele produse program au luat, astfel, în considerare posibilitatea de a menține ideea de analiză sintactică completă a frazelor dar cu separarea lor în cele relevante și eliminarea din analiza textuală a celor considerate, după anumite principii, irelevante. Alte produse au redus strictețea regulilor de analiză sintactică pentru a produce fragmente de arbori de analiză sintactică sau arbori de analiză sintactică incompleți.
Totuși, anumite programe de analiză a textelor au renunțat la ideea unei analize complete a textelor, în detrimentul unor analize parțiale a frazelor de înaltă calitate. În particular, gramaticile IDC (independente de context) au fost folosite cu succes ca modalități eficiente pentru realizarea unor sisteme de analiză parțială a frazelor cu o acuratețe ridicată. Mai devreme sau mai târziu, capabilitatea de a înlocui analiza totală a unui text cu una parțială care să aibă aceleași rezultate va deveni o cerință de bază în realizarea unor sisteme eficiente de analiză sintactică a textelor, componente de corpora.
Curentul introdus în teoria și practica metodologiilor de analiză a textelor reprezentat de tehnicile de analiză parțială a frazei nu reprezintă posibilitatea absolută de rezolvare a problemelor de analiză textuală în cadrul tuturor aplicațiilor de procesare a limbajelor naturale. Totuși, se poate afirma faptul că analiza sintactică completă nu mai reprezintă o modalitate a priori care să fie cuprinsă în toate sistemele de procesare a limbajelor naturale.
Analiza discursului (textul liber)
Analiza discursului implică rezolvarea a trei probleme importante:
– analiza sintactică a frazei cu recunoașterea expresiilor și analiza semantică a părților de vorbire complexe (alcătuite din mai multe cuvinte);
– împărțirea în propoziții a frazelor și realizarea relațiilor de dependență dintre ele;
– recunoașterea legăturilor relaționale care sunt folosite pentru a structura simbolurile memorate de sistemele de extragere a informației structurate într-o formă de rețea de legături pentru o utilizare mai rapidă;
O problemă importantă pentru analiza unui discurs (text liber) o reprezintă euristica domeniilor dependente/independente pentru textul respectiv. Există o diferență în a implementa reguli de analiză a textelor libere pentru un anumit domeniu sau aplicație, spre deosebire de o abordare generală care să rezolve astfel de probleme. Astfel, este o provocarea ideea de a crea capabilități de analiză a textelor, independentă de domeniul de care acestea sunt legate. Dacă se realizează un sistem de analiză bazat pe reguli dependente/independente de context atunci trebuie să se cunoască foarte clar arhitectura acestui tip de sistem. Astfel, dacă o regulă a acestui sistem este înlocuită sau scoasă definitiv din sistem, atunci sistemul trebuie astfel construit încât să poată ști dacă noua regulă ar trebui să fie folosită în locul celei pe care a înlocuit-o sau într-o altă conotație. Regulile multiple interacționează între ele creând un sistem integrat de analiză a textului. Totuși, nu este ușor de înlocuit un set de reguli dependente de contextul de analiză cu un nou set dacă interacțiunile dintre acest set de reguli dependente și cele independente de context existente deja trebuie reevaluate în totalitate.
Sisteme de procesare a limbajelor naturale
Cercetătorii în domeniul procesării limbajelor naturale au utilizat funcționalitățile oferite de sistemele de extragere a informației prezentate anterior, în încercarea de realiza sisteme de analiză cu o acoperire vastă de domenii de activitate și cu o portabilitate ridicată pentru o utilizare în domenii noi de activitate umană de către persoane care nu au nici o pregătire în domeniul lingvisticii computaționale.
O modalitate de rezolvare a acestor probleme o reprezintă posibilitatea de a obține automat date și reguli necesare sistemului, pentru a putea acționa pentru diferite noi domenii sau limbaje naturale prin “antrenarea” lui în realizarea acestor deziderate. Această opțiune este posibilă în condițiile în care se pot accesa vaste domenii de corpora, texte deja adnotate sintactic sau semantic precum și dicționare multilingve on-line.
Mai multe sisteme care utilizează metode statistice au demonstrat valoarea “antrenării” în cadrul sistemelor de extragere a informației pentru adnotarea părților de vorbire, pentru recunoașterea părțior relevante de text pentru analiză și pentru recunoașterea părților de vorbire din textul analizat.
Adnotarea părților de vorbire utilizând modele statistice de text este o modalitate comună de abordare a ideii de analiză a textelor. De exemplu, Bolt, Beranek și Newman au dezvoltat produsul program Part-Of-Speech Tagger (POST) utilizând ca sursă de texte de analizat articole din “Wall Street Jurnal ” care au fost deja adnotate manual de un grup de specialiști în procesarea limbajelor naturale de la Universitatea din Pennsylvania. Cu ajutorul unor reguli conexe, adăugate acestui tip de sistem de analiză pentru a mări capacitatea și performanța în analiza unor cuvinte necunoscute sau noi pentru sistem, performanța lui POST este chiar impresionantă, ajungând la un grad de corectitudine a analizei de până la 95%. Acest rezultat este comparabil cu rezultatele obținute de alte sisteme de analiză a textelor bazate pe metode statistice de lucru.
Un sistem de analiză bazat pe metode statistice pentru texte în limba japoneză, care rezolvă și problema recunoșterii legăturilor dintre cuvinte, a fost realizat la Kyoto. Programul, numit JUMAN, segmentează textul în limba japoneză în timp ce realizează adnotarea părților de vorbire și a structurii semantice a frazei.
Adnotarea textelor implică anumite diferențe de abordare în realizarea acestui lucru, dar toate produsele program care realizează acest lucru depend de modul de analiză a frecvenței de apariție a perechii cuvânt/parte de vorbire (POS) urmată de orice altă pereche cuvânt/POS. Uneori este folosită frecvența de apariție a trigramelor (succesiuni de trei cuvinte) pentru adnotarea textelor de analizat. O dată stabilite aceste frecvențe, estimarea probabilității de apariție a fiecărei perechi poate fi calculată. Pentru propoziții noi adăgate la modelul de analiză, secvența de perechi cu probabilitatea cea mai mare este calculată cu ajutorul unui model statistic Markov. Informațiile obținute în acest fel reduc la minim ambiguitatea sintactică, permițând realizarea de fragmente clare de analizat și simplificând analiza sintactică a frazei.
Multe sisteme de extragere a informației (IE systems) includ un filtru de documente ca parte integrantă a pre-procesării textelor, permițând sistemelor să ignore părți de text sau texte întregi dacă acestea nu satisfac anumite condiții. Chiar dacă textele procesate de sistemele de extragere a informației (IE systems) sunt rezultate în urma unui proces de filtrare realizat de sistemele de captare a informației utile ( IR systems ), aceste texte nu sunt considerate în totalitate ca fiind relevante pentru analiză. În particular, sistemele de captare a informației utile ( IR systems ) bazate pe funcții booleane pot determina acele documente irelevante care pot produce probleme sistemelor de procesare a limbajelor naturale. De exemplu, șapte din cele 1.000 de articole analizate de Tipster referitoare la microelectronice (microchips) se referă la cipsuri de cartofi.
Unele texte trebuie eliminate și din alte motive. De exemplu, o regulă care este utilizată de un sistem de extragere a informației referitoare la atacurile teroriste poate trece peste un atac terorist asupra unei ținte militare deoarece regula definește ca ținte ale atacurilor teroriste doar acelea care sunt ținte civile.
De altfel, unele texte pot conține informații relevante doar în câteva paragrafe; capabilitatea de a ignora restul textului ar putea fi de folos, deși nu neapărat necesară dacă sistemul de extragere a informației (IE system) este destul de specific în modul intern de procesare, pentru a ignora acest material.
Anumite sisteme au experimentat modele probabilistice ale frecvenței cuvintelor pentru a calcula relevanța unui text. Aceste sisteme depind de disponibilitatea unor documente relevante sau nu. Template-urile („machetele”) pot determina relevanța acestor texte, iar cheile care conțin informații utile provin din texte relevante.
Pentru a detecta relevanța paragrafelor într-un text valorile acestor texte pot fi comparate cu informațiile din paragrafele respective. Astfel obținute paragrafele sau textele relevante, este, totuși, necesar să se găsescă cuvintele distinctive și să se calculeze frecvența lor relativ la textele relevante, respectiv la cele irelevante. Aceste cuvinte relevante trebuie să apară în frecvențe relative diferite în textele relevante, respectiv în cele irelevante. Acest mod de comparație se folosește pentru a determina probabilitatea ca un text să fie relevant pe baza unei frecvențe de apariție a cuvintelor distinctive din textul respectiv. Acest mod de lucru funcționează dacă sunt determinate în mod corect frecvențele respective.
Se obține astfel o modalitate în plus de filtrare aplicată textelor asupra cărora se efectuează analiza cu o cerere din ce în ce mai redusă a efortului uman pentru a seta procesul de filtrare și analiză.
Un exemplu de utilizare a produsului Tipster utilizând metodele de realizare a filtrării textului prezentate anterior se poate obeserva în Figura 2.
Figura 2 – Exemplu de analiză realizată de Tipster
Probleme referitoare la extragerea informației
Definirea temptate-urilor (machetelor) care conțin informația extrasă din text este un proces dificil și complex. Temptate-uri (machete) pot fi generate pentru orice tip de text. Temptate-urile (machetele) pentru Tipster sunt de forma unor obiecte care conțin pointeri către alte obiecte. Ele reduc redundanța la introducerea informației utile ceea ce face ca să fie destul de greu de utilizat și completat. Figura 2 dezvăluie un template tipic pentru Tipster care reține informația utilă în sloturi care au nume specifice, unele din aceste nume fiind preluate din text. O mare parte din această informație este convertită la o formă normalizată în concordanță cu regulile unui sistem care să asigure o consistență ridicată a analizei de text. Unele din aceste reguli pot fi lungi și complexe, după cum se poate observa din Figura 2.
Definirea sarcinilor de extragere a informației pentru un volum mare de date este o sarcină complexă care trebuie asociată produsului Tipster. Cel care le definește trebuie să cunoască domeniul subiectului la care se referă textul, tipul de informații care sunt disponibile în mod normal în texte de genul respectiv și capabilitățile pe care sistemele de procesare a limbajelor naturale le oferă în acest sens. „The Computing Research Laboratory ” a dezvoltat produse („tools”) care pot crea temptate-uri (machete) pentru Tipster. Primul dintre acestea a fost menținut pe piață doar șase luni datorită schimbărilor apărute în definirea temptate-urilor (machetelor).
Problema definirii temptate-urilor (machetelor) trebuie rezolvată înainte ca aceste tipuri de sisteme să fie lansate pe piață. O modalitate ar putea fi definirea unor temptate-uri (machete) cu o structură mult mai simplă care pot extrage seturi de informații minimale care pot fi folosite cu succes în analiza textelor.
Dezvoltarea de sisteme de extragere a informației
Nevoia creării de sisteme rapide de extragere a informației s-a simțit mult mai acut începând cu anul 1992. În anul 1991, multe din produsele în acest domeniu se mulțumeau să ofere un mod operațional de realizare a extragerii informației și de prelucrare a ei. Din anul 1992 s-a realizat faptul că dezvoltarea de sisteme fiabile în domeniul extragerii informației trebuie să cuprindă și rapiditate și eficiență ca factori definitorii.
Dezvoltarea de sisteme competitive de extragere a informației trebuie să îndeplinească patru cerințe de bază, și anume:
– timp rapid de execuție;
– eficiența extragerii cunoștințelor;
– interfețe eficiente în extragerea informației utile;
– medii eficiente de realizare a prelucrării informației deja extrase;
Ideea că dezvoltarea de soft competitiv se leagă nemijlocit de o analiză și o inginerie competitivă în proiectarea unor astfel de sisteme trebuie luată în considerare și în cazul dezvoltării de sisteme competitive de extragere și analiză a informației, deoarece o parte din specialiștii în procesarea limbajelor naturale omit adeseori acest lucru.
Din momentul în care specialiștii în procesarea limbajelor naturale sunt implicați în cercetarea diferitelor părți de corpora, viteza și eficiența procesării unui număr mare de texte într-un interval de timp relativ redus, devin factori de prim rang în munca de cercetare. Întrebat despre rolul acestor factori în cadrul muncii de cercetare, unul din specialiștii în procesarea limbajelor naturale a declarat următoarele: „Singurul mod de a obține o analiză competitivă în domeniul limbajelor naturale se leagă nemijlocit de corpora, corpus de limbă vorbită sau scrisă. Abordările cele mai bune în acest domeniu trebuie să fie destul de rapide astfel încât să poată analiza cantități mari de texte, pentru că aceasta este singura modalitate de a putea testa fiabilitatea unui sistem de extragere și analiză a informației.”
Modalități de realizare a unui analizor semantic de texte
Utilizarea generatoarelor de analizoare lexicale și sintectice
ANTLR – un generator de analizoare lexicale și sintactice în C++ și Java
Un generator de analizoare lexicale și sintactice poate fi folosit nu numai pentru a crea compilatoare, dar și pentru cei care doresc să se ocupe cu rezolvarea problemelor legate de analiza textelor dintr-o corpora, pentru care este necesară existența unor analizoare lexicale și sintactice care să poată rezolva eficient problemele de extragere și prelucrare a informației, prezentate pe larg în capitolele anterioare.
Să presupunem că, în concordanță cu cele prezentate în capitolul referitor la extragerea informației, un program care analizează pagini HTML preia toate URL-urile corespunzătoare tag-ului <IMG SRC>. Codul corespunzător generării tuturor URL-urilor poate fi destul de complicat dacă nu se utilizează un generator de analizoare.
ANTLR (ANother Tool for Language Recognition) este un generator de analizoare lexicale și sintactice de generația a doua. Prima generație de astfel de generatoare a fost reprezentată de PCCTS (Purdue Compiler Construction Tool Set), ambele generații fiind implementate de Terence Parr.
Analiza lexicală în ANTLR care analizează o linie dintr-un fișier HTML de forma <IMG SRC = “URL”> este realizată doar prin scrierea a câtorva reguli care sunt în concordanță cu regulile de extragere a informației utile din textele de analizat prezentate în capitolele anterioare. Astfel, forma acestor reguli este următoarea:
TAG_IMG : “IMG”;
TAG_SRC : “SRC”;
WS : ‘ ‘ | ‘\t’ | ‘\n’;
LITERA : ‘\\’ | ‘/’ | ‘A’..’Z’ | ‘0’ ..’9’ | ‘a’..’z’;
CUVANT : ‘\\’ | ‘/’ | ‘A’..’Z’ | ‘0’ ..’9’ | ‘a’..’z’;
URL : LITERA (CUVANT) * ;
IMG_SRC : ‘<’ (WS)* TAG_IMG (WS)+ TAG_SRC (WS)* ‘=’ (WS)* “\””URL”\”” (WS)* ‘>’ {/* accesare URL */} ;
Cu alte cuvinte, în loc să rezolve problema particulară propusă, “se descoperă” faptul că este vorba de o problemă mult mai generală și se utilizează un instrument general corespunzător în modul de extragere a informației utile, adică un analizor lexical sau sintactic. Algoritmul executat de către un analizor lexical/sintactic nu depinde de gramatica pentru care se face analiza (verificarea/prelucrarea). În acest moment apare deja o problemă legată de tematica acestei lucrări și posibilitățile oferite de acest produs în scopul realizării unei analize semantice/sintactice a unui text scris în limba română, a cărui configurație depinde în mare măsură de gramatica cu care a fost construit.
De aceea este nevoie de un analizor care, pornind de la descrierea unei gramatici cu ajutorul căreia a fost creat un text sau o colecție de texte, să se poată realiza o serie de prelucrări semantice și sintactice asupra textului (textelor respective). În mod corespunzător există generatoare care pornind de la o descriere a gramaticii și a prelucrărilor asociate recunoașterii diferitelor construcții, generează analizoare semantice sau sintactice.
În general, avantajul utilizării unui generator de analizoare sintactice sau lexicale constă din faptul că permite programatorului să lucreze la un nivel mai înalt de abstractizare. Astfel, modificările ulterioare se fac mult mai ușor dacă se folosește un generator de analizoare. În plus, înțelegerea gramaticii este mult mai ușoară față de codul ce construiește analizorul pentru gramatica respectivă.
Problema care se ivește în cazul realizării unui analizor semantic bazat pe analiza lexicală a unui text scris în limba română se leagă de bogăția semnatica a acestei gramatici și imposibilitatea de a crea un set de reguli intergrale care să acopere toate cererile de extragere a informației utile din text din punct de vedere al analizei morfolgice ce poate fi realizată în paralel de un lingvist. Această problemă poate fi privită și din imposibilitatea realizării stabilității regulilor gramaticii ce ar trebui folosită de un analizor lexical sau sintactic aplicat pe un text scris în limba română. De menționat faptul că, până la realizarea acestui material, nu s-a realizat încă un analizor semantic performant pentru texte scrise în limba română, și, de asemenea, faptul că nu există un format electronic adecvat al unei gramatici a limbii române care să poată fi folosită de un generator de analizor lexical sau sintactic.
Lex și Yacc sunt cele mai cunoscute generatoare de analizoare lexicale și, respectiv, sintactice. Ele fac parte din moștenirea UNIX și asta înseamnă că primele versiuni au apărut în anii ’70. Spre deosebire de Lex și Yacc care necesită specificații separate, pentru analiza lexicală și sintactică, ANTLR-ul folosește o singură descriere, ceea ce face utilizarea mai simplă.
În Lex specificarea regulilor pentru descrierea construcțiilor lexicale se face folosind expresii regulate. ANTLR-ul permite folosirea construcțiilor independente de context și în faza de analiză lexicală.
ANTLR-ul este implementat în Java și poate genera cod Java, C++ sau Sather pornind de la aceeași structură a regulilor. Ceea ce se modifică în funcție de limbajul generat sunt instrucțiunile din cadrul regulilor ce folosesc funcții din limbajul respectiv.
ANTLR-ul acceptă trei tipuri de specificații pentru analizorul lexical, analizorul sintactic și analizorul arborilor de derivare. Toate cele trei tipuri de specificații sunt de tipul LL(k) – parcurg șirul de intrare de la stânga la dreapta, generează analizoare descendente, k reprezentând numărul de simboli de la intrare care sunt luați în considerare pentru a decide ce producție a gramaticii va fi considerată la pasul următor. În mod implicit, k este egal cu 1.
Fișierele generate de ANTLR pentru limbajul de programare Java sunt distribuite astfel:
descrierea gramaticii făcută într-un fișier cu extensia “.g”;
proiectarea analizorului în limbajul Java;
Proiectarea ANTLR-ului este obiect orientată. Structura unui fișier de descriere cu specificații pentru analizorul lexical, sintactic și cel al arborilor de derivare va conține:
Clasa corespunzătoare analizorului lexical (derivată din clasa Lexer);
Clasa analizorului sintactic (derivată din clasa Parser);
Clasa analizorului arborilor de derivare (derivată din clasa TreeParser);
Tabelul1. Fișiere generate de ANTLR
Utilizarea ANTLR pentru generarea unui analizor lexical
Un analizor lexical este un program care împarte un text în unități lexicale numite atomi lexicali. Ca exemple de atomi lexicali putem considera: numere, identificatori, cuvinte rezervate, separatori, operatori, etc. Un analizor lexical poate fi generat pornind de la descrierea atomilor lexicali ce urmează a fi identificați și a secvențelor de cod care urmează să fie executate la recunoașterea fiecărui tip de atom lexical. Pe baza acestor informații se vor genera funcții ce vor putea fi utilizate în programe ce au nevoie de analiză lexicală. Execuția analizorului lexical realizează căutarea într-un șir de caractere a unui subșir care să se potrivească cu unul din modelele descrise în specificații. Dacă un astfel de șir este găsit atunci se va executa acțiunea asociată modelului respectiv. În cazul ANTLR-ului, descrierea atomilor lexicali se face folosind construcții independente de context. De exemplu, modelul pentru recunoașterea parantezelor drepte bine formate este:
ACȚIUNE : ‘[‘ ( ACȚIUNE | ~ ‘]’ )* ‘]’ ;
spre deosebire de analizoarele care utilizează pentru descrierea atomilor lexicali expresii regulate cu o descriere mult mai complicată.
Numele regulilor din descrirea analizorului lexical încep cu literă mare. Fiecare regulă va deveni o metodă în clasa analizorului lexical generat. În cadrul analizorului lexical se pot folosi predicate semantice și sintactice.
Toate funcțiile generate pe baza regulilor au ca rezultat un obiect care conține textul corespunzător potrivirii găsite și tipul său, adică, partea stângă a regulilor. ANTLR-ul oferă funcții care pot seta atât textul căt și tipul obiectului întors. Pentru ca o regulă să nu întoarcă nici un obiect analizatorului sintactic, aceasta va fi declarată protected (regula va fi folosită doar în cadrul analizorului lexical). O regulă protected poate primi argumente și poate întoarce valori. Pot fi definite variabile locale în cadrul regulilor.
Structura locală a instalării ANTLR-ului are forma următoare a directoarelor:
Figura 3 – Structura ANTLR
ANTLR-ul este un generator de analizoare lexicale și sintactice care rulează de la linia de comandă (deși multe medii de dezvoltare a unor programe bazate pe interfețe atractive pentru utilizator permit acestuia să ruleze ANTLR pe diferite fișiere care conțin gramatici din interiorul acestor medii de programare). Principala metodă care se rulează din pachetul antlr.Tool este cea prin care se introduce gramatica cu care se generează analizorul lexical sau sintactic. Aceasta are forma următoare:
java antlr.Tool file.g
Linia de comandă conține și opțiuni precum -diagnostic, care generează un fișier text pentru fiecare clasă a analizoarelor rezultate în urma fiecărei generări, care descrie mulțimile de obiecte generate. De menționat că există o mulțime de opțiuni care permit celui care utilizează ANTLR să specifice mai bine gramatica care va fi folosită pentru generare și nivelul de analiză al acesteia.
Opțiuni ca -trace, -traceParser, -traceTreeParser pot fi utilizate pentru a urmări lexerul, parserul și arborele de derivare obținut.
ANTLR generează un analizator descendent recursiv. Sintaxa descrierii regulilor este aceeași pentru analizorul lexical, sintactic și cel al arborilor de derivare. Pentru implementarea analizorului lexical se utilizează o stivă, ceea ce lărgește clasa limbajelor acceptate, față de cazul în care implementarea se bazează pe simularea unui automat finit determinist. ANTLR generează cod orientat obiect (Java, C++ sau Sather) astfel încât să poată fi moștenită funcționalitatea metodelor sale.
Utilizarea acestui tip de generator de analizor lexical și sintactic în cadrul actualului proiect nu ar fi benefică datorită imposibilității de a folosi o gramatică performantă din punct de vedere electronic pentru realizarea unui analizor lexical performant.
Jlex – un generator de analizor lexical pentru limbajul Java
Poate cel mai cunoscut analizor lexical este Lex. Lex este un generator de analizoare lexicale pentru sistemul de operare UNIX realizat pentru limbajul de programare C. Lex preia un fișier special formatat cu o specificație clară conținând detalii pentru analiza lexicală. Acest utilitar crează un fișier sursă C asociat unei tabele de analiză lexicală.
JLex este un utilitar care se bazează pe modelul generatorului de analizor lexical Lex. JLex preia un fișier cu o specificție similară cu cea a uneia acceptată de Lex și crează un fișier sursă Java pentru analizorul lexical corespunzător.
JLex va prelua un fișier special formatat cu o specificație clară conținând detalii pentru analiza lexicală și-l va transforma într-un fișier sursă Java pentru analizorul lexical corespunzător.
Analizorul lexical generat se află stocat în clasa Yylex. Există doi constructori pentru această clasă, ambii cerând un singur argument:, șirul de intrare care trebuie să fie analizat lexical. Șirul de intrare poate avea următoarele tipuri: java.io.InputStream sau java.io.Reader (asemenea unui StringReader).
Funcția de acces la analizorul lexical este Yylex.yylex(), care returnează următoarea componentă lexicală (token) din șirul de intrare. Tipul returnat este Yytoken iar funcția este declarată după cum urmează:
class Yylex {…
public Yytoken yylex(){
…}
Utilizatorul trebuie să declare tipul pentru Yytoken. De exemplu, pentru ca Yylex.yylex() să returneze un tip întreg de forma java.lang.Integer integer, utilizatorul trebie să introducă următoarea secvență de cod:
Class Yytoken extends java.lang.Integer {}
Astfel, în analiza lexicală întregii obținuți în urma analizei șirului de intrare vor fi returnați în felul următor:
{…
return new java.lang.Integer(0);
…}
De asemnea, secțiunea de cod creată de utilizator, o clasă poate fi definită declarând constante care corespund pentru fiecare din tipurile de componente ale analizei lexicale.
class TokenCodes { …
public static final STRING = 0;
public static final INTEGER = 1;
…}
Apoi, în secțiunea de acțiune a analizorului lexical, aceste componente ale analizei lexicale (token-uri) pot fi returnate astfel:
{…
return new java.lang.Integer(STRING);
…}
Acestea sunt doar câteva exemple simple. În cazul unei analize lexicale mai complexe se va defini o clasă de analiză care va conține mult mai multe informații decât extragerea codului unei valori întregi.
Aceste exemple ilustrează tehnicile obiect – orientate pe care un utilizator le poate utiliza pentru a obține un analizor lexical complex din punct de vedere al tipurilor componentelor de analizat, returnate de metoda Yylex.yylex(). În mod deosebit, principiul moștenirii permite utilizatorului să returneze prin funcția de analiză mai mult decât o singură componentă (token) de analizat.
class Yytoken { … }
class IntegerToken extends Yytoken { … }
class StringToken extends Yytoken { … }
Apoi, utilizatorul poate returna tipurile IntegerToken și StringToken din analizorul lexical.
Numele clasei analizorului lexical poate fi modificat, la fel ca și funcțiile de analiză sau tipurile returnate de analizor prin utilizarea directivelor puse la dispoziție de JLex.
Structura de directoare pentru Jlex are forma următoare:
Figura 4 – Structura JLex
Un exemplu de utilizare pentru generatorul JLex de analizoare lexicale ar fi contorizarea numărului de cuvinte, caractere și linii ale unui fișier cu orice format. Astfel, pentru a obține acest rezultat, utilizând un fișier scris în conformitate cu normele impuse de Jlex, trebuie compilat fișierul ce cuprinde gramatica scrisă pentru acest exemplu, și anume CalcWord.l. Pentru acest lucru se tastează următoarea linie de comandă:
java JLex.Main CalcWord.l
Acest lucru ulilizează metoda Main din pachetul JLex deja instalat. În urma acestei comenzi se obține un fișier cu extensia .java care poate fi compilat cu compilatorul de java ca orice fișier cu format java. Acest fișier conține analizorul lexical necesar rezolvării problemei și care a fost generat de JLex. Astfel, se compilează fișierul java CalcWord.l.java :
javac CalcWord.l.java
În urma compilării se obține fișierul Yylex.class care este formatul executabil al analizorului lexical necesar rezolvării problemei numărului de cuvinte, linii și caractere ale unui fișier oarecare.
Astfel, pentru a obține rezultatul final se tastează următoarea linie de comandă:
java Yylex nume_fișier_de_analizat
Rezultatele unei astfel de modaltăți de utilizare ale unui generator de analizoare lexicale pentru determinarea numărului de cuvinte, caractere și linii ale unui fișier cu orice format se pot observa în figura următoare:
De menționat faptul că fișierul de analizat are forma ex.txt cu următorul conținut: mama are mere.
Trebuie arătat faptul că analizorul generat de JLex este unul rapid, fapt demonstrat de o analiză competentă a timpilor de execuție în comparație cu analizoare scrise direct de programatori. Astfel, în urma analizei timpului de execuție a analizei lexicale s-au obținut următoarele rezultate:
Astfel, în proiectul de față, se poate utiliza acest generator de analizoare lexicale, cel puțin pentru partea statistică referitoare la o extragere rapidă a informației utile și la prelucrarea ei.
Java CUP (Java(tm) Based Constructor of Useful Parsers)– un generator de analizoare limbajul Java
Java CUP este un sistem de generare de analizoare (parsere) cu ajutorul unor specificații simple. Are același mod de utilizare ca și mai bine cunoscutul YACC și oferă, în principiu aceleași rezultate. Spre deosebire de YACC, generatorul CUP este scris în Java utilizând specificațiile incluse în limbajul Java și având ca rezultate analizoare implementate tot în Java.
Utilizarea generatorului de analizoare lexicale și sintactice CUP implică crearea unui fișier de specificație care cuprinde gramatica pentru care analizorul este creat împreună cu realizarea unui „scaner” capabil să poată despărți în unități lexicale (cuvinte cheie, numere, simboluri speciale) care să poată avea un sens în analiza realizată.
De exemplu, să considerăm un sistem de evaluare a unei expresii matematice cu numere întregi. Acest sistem citește expresii de la intrarea standard care sunt analizate și se returnează rezultatul la ieșirea standard. O gramatică pentru analiza fișierului de intrare ar arăta în felul următor:
expr_list ::= expr_list expr_part | expr_part
expr_part ::= expr ';'
expr ::= expr '+' expr | expr '-' expr | expr '*' expr
| expr '/' expr | expr '%' expr | '(' expr )'
| '-' expr | number
Pentru a specifica un analizor bazat pe această gramatică este nevoie să identificăm și să notăm, ca atare, mulțimea simbolurilor terminale care apar în fișierul de intrare precum și mulțimea de neterminale. În acest caz mulțimea simbolurilor neterminale este formată din:
expr_list, expr_part and expr .
Pentru mulțimea de terminale se poate utiliza următoarele:
SEMI, PLUS, MINUS, TIMES, DIVIDE, MOD, NUMBER, LPAREN,
RPAREN
Se observă, totuși că fișierul care ar conține gramatica prezentată mai sus are o problemă. Este ambiguă. O gramatică este ambiguă în momentul în care dat un fișier de intrare, acesta se poate reduce la unități lexicale în două moduri diferite, ambele corecte din punct de vedere al analizei. Astfel, pentru un șir de intrare de felul următor:
3 + 4 * 6, gramatica deja creată poate evalua fie 3 + 4 = 7 * 6 = 42 sau poate evalua 4 * 6 = 24 + 3 = 27. Versiunile mai vechi de CUP obligă utilizatorul să scrie gramatici care să nu poată fi interpretate ambiguu, dar în prezent, există o posibilitate de a specifica precedențele și asocierile dintre terminali. Bazându-ne pe o astfel de specificație, o gramatică specifică pentru Java CUP în rezolvarea problemei precedente ar avea următoarea formă:
// specificațiile CUP pentru un evaluator simlu de expresii aritmetice (fără acțiuni după evaluare)
import java_cup.runtime.*;
/* Preliminarii de setare și utilizare a “scanerului” */
init with {: scanner.init(); :};
scan with {: return scanner.next_token(); :};
/* Terminale (token-uri returnate de scanner). */
terminal SEMI, PLUS, MINUS, TIMES, DIVIDE, MOD;
terminal UMINUS, LPAREN, RPAREN;
terminal Integer NUMBER;
/* Non terminale */
non terminal expr_list, expr_part;
non terminal Integer expr, term, factor;
/* Precedențe */
precedence left PLUS, MINUS;
precedence left TIMES, DIVIDE, MOD;
precedence left UMINUS;
/* Gramatica */
expr_list ::= expr_list expr_part |
expr_part;
expr_part ::= expr SEMI;
expr ::= expr PLUS expr
| expr MINUS expr
| expr TIMES expr
| expr DIVIDE expr
| expr MOD expr
| MINUS expr %prec UMINUS
| LPAREN expr RPAREN
| NUMBER
;
Din ceea ce a fost deja prezentat se poate observa că fișierul de specificare a gramaticii de utilizat în creerea analizorului este format din patru părți. Prima parte permite declarații preliminare pentru specificarea modului în care analizorul trebuie generat și cuprinde părți de cod. În acest moment sunt importate clasele din pachetul java_cup.runtime urmat de codul de inițializare și cod pentru invocarea scanerului în obținerea de unități lexicale din textul de intrare.
A doua parte a specificării gramaticii cuprinde declararea terminalelor și non-terminalelor și asocierile de clase cu aceste tipuri de obiecte. Terminalele sunt declarate fără tip sau de tip întreg. Tipul terminalelor sau non-terminalelor este tipul returnat pentru valorile acestora. Dacă nu este declarat nici un tip pentru terminale sau neterminale acestea nu întorc nici o valoare. În gramatica prezentată anterior, faptul că terminalele sau neterminalele nu au tip indică faptul că nu conțin nici o valoare.
Ultima parte a specificației gramaticii conține gramatica însăși.
Pentru a produce un analizor din această specificație se utilizează generatorul Java CUP. Dacă aceste specificații au fost stocate într-un fișier numit parser.cup atunci se invocă generatorul Java CUP cu ajutorul liniei de comandă:
java java_cup.Main < parser.cup
În acest caz, sistemul de analiză va produce două fișiere sursă Java care vor conține părțile componente ale analizorului generat: sym.java și parser.java. Aceste două fișiere conțin declarații pentru clasele sym și parser.
Clasa sym conține o serie de de declarații de constante, una pentru fiecare simbol terminal. Aceasta este utilizată de scaner pentru a se refiri la simbolurile generate (e.g. – cu un cod de forma "return new Symbol(sym.SEMI);" ). Clasa parser implementează analizorul generat.
Specificațiile de mai sus nu efectuează nici o acțiune semantică; generatorul astfel obținut indică succesul sau eșecul generării analizei (a creării analizorului atașat). Pentru a calcula și afișa valori pentru fiecare expresie analizată trebuie scris cod Java în interiorul analizorului generat pentru a realiza diferite acțiuni.
În Java CUP acțiunile sunt conținute în structuri speciale de forma code strings care sunt cuprinse între delimitatori de forma {: and :}. În general, sistemul de analiză înregistrează toate caracterele dintre delimitatori, dar nu verifică dacă acest cod este valid din punct de vedere al limbajului de programare Java.
Un exemplu complet de gramatică necesar sistemului de analiză a expresiilor matematice cu acțiuni atașate operațiilor de analiză este prezentat în cele ce urmează:
import java_cup.runtime.*;
/* Preliminarii de setare și utilizare a scaner-ului. */
init with {: scanner.init(); :};
scan with {: return scanner.next_token(); :};
/* Terminale (token-uri returnate de scaner). */
terminal SEMI, PLUS, MINUS, TIMES, DIVIDE, MOD;
terminal UMINUS, LPAREN, RPAREN;
terminal Integer NUMBER;
/* Non terminale */
non terminal expr_list, expr_part;
non terminal Integer expr;
/* Precedențe */
precedence left PLUS, MINUS;
precedence left TIMES, DIVIDE, MOD;
precedence left UMINUS;
/* Gramatică */
expr_list ::= expr_list expr_part
|
expr_part;
expr_part ::= expr:e
{: System.out.println("= " + e); :}
SEMI
;
expr ::= expr:e1 PLUS expr:e2
{: RESULT = new Integer(e1.intValue() + e2.intValue()); :}
|
expr:e1 MINUS expr:e2
{: RESULT = new Integer(e1.intValue() – e2.intValue()); :}
|
expr:e1 TIMES expr:e2
{: RESULT = new Integer(e1.intValue() * e2.intValue()); :}
|
expr:e1 DIVIDE expr:e2
{: RESULT = new Integer(e1.intValue() / e2.intValue()); :}
|
expr:e1 MOD expr:e2
{: RESULT = new Integer(e1.intValue() % e2.intValue()); :}
|
NUMBER:n
{: RESULT = n; :}
|
MINUS expr:e
{: RESULT = new Integer(0 – e.intValue()); :}
%prec UMINUS
|
LPAREN expr:e RPAREN
{: RESULT = e; :}
;
Ultimul pas în realizarea unui analizor funcțional este crearea unui scanner (cunoscut și sub numele de analizor lexical sau mai simplu lexer). Analizorul este responsabil de citirea caracterelor individuale, eliminarea caracterelor albe (blank-uri) și comentariilor și recunoaștrea caracterelor care formează terminale ale gramaticii respective. În final, analizorul returnează obiectele de tip Symbol reprezentând simbolurile recunoscute de analizor pentru terminale. Terminalele vor fi returnate în urma unei instanțe a clasei analizorului generat (de exemplu scanner.next_token()).
Analizorul returnează astfel obiecte de tipul java_cup.runtime.Symbol. Aceste obiecte de tipul amintit anterior conțin instanțe pentru valori ale variabilelor de tip Object , care vor fi setate de analizor. Aceste variabile se referă la valorile acestor simboluri, iar tipul obiectului returnat prin aceste valori trebuie să fie de același tip cu tipul declarat pentru terminale sau neterminale.
În exemplul anterior, dacă analizorul returnează un token de tipul NUMBER se crează un Symbol cu o valoare a instanței variabilei ce conține un obiect de tipul Integer. Terminalele și non-terminalele cu nici o valoare au un camp de valoare de tipul null.
Structura pentru Java CUP are forma următoare:
O dată cu execuția generatorului având ca fișier de intrare gramatica stocată într-un fișier cu extensia .cup analizatorul astfel obținut indică succesul sau eșecul generării analizei (a creării analizorului atașat). După afirmarea la consolă a succesului execuției unei astfel de generări sunt create cele doua fișiere Java care pot fi modificate în scopul de a realiza o analiză specifică cu cerințele utilizatorului. Codul acestor fișiere poate fi modificat pentru ca după compilare să poată afișa la execuție rezultatele specifice analizei sintactice a textului introdus din fișierul de intrare introdus de utilizator.
Rezultatul generării inițiale a analizorului lexical prin utilizarea Java CUP are forma următoare:
De menționat faptul că în linia de comandă dată cu forma:
java java_cup.Main < java11.cup fișierul care conține gramatica de generare este java11.cup după versiunea folosită, și anume, versiunea 1.1 a generatorului Java CUP. Fișierul java11.cup conține specificațiile de generare a analizorului lexical stocat în fișierele generate Parser.java și Sym.java.
Formatul fișierului java11.cup ce conține gramatica de generare a analizorului lexical are următoarea formă:
QTAG 3.0 – un generator de adnotare a textelor în limba engleză
QTAG este un proiect comun al universităților din Birmingham și Lancaster în vederea obținerii unor rezultate de marcă în analiza textelor în limba engleză.
Adnotarea se realizează cu ajutorul unui set de notații comun acceptate de ambele universități și care sunt prezentate utilizatorului acestui program ca punct de plecare în realizarea adnotării oricăror tipuri de texte ce cuprind părți de corpora scrisă sau vorbită în limba engleză.
Acest set de tag-uri (nume de simboluri de adnotare a textelor) sunt cuprinse într-un fișier text numit sugestiv BLT.txt (build – a construi – în limba engleză). Lista de nume de tag-uri este următoarea:
BE be
BEDR were
BEDZ was
BEG being
BEM am
BEN been
BER are
BEZ is
CC conjunction, coordinating (and)
CD number, cardinal (four)
CS conjunction, subordinating (until)
DO do
DOD did
DOG doing
DON done
DOZ does
DT determiner, general (a, the, this, that)
EX existential <em>there</em>
FW foreign word (ante, de)
HV have
HVD had (past tense)
HVG having
HVN had (past participle)
HVZ has
IN preposition (on, of)
JJ adjective, general (near)
JJR adjective, comparative (nearer)
JJS adjective, superlative (nearest)
MD modal auxiliary (might, will)
NN noun, common singular (action)
NNS noun, common plural (actions)
NP noun, proper singular (Thailand, Thatcher)
NPS noun, proper plural (Americas, Atwells)
OD number, ordinal (fourth)
PDT determiner, pre- (all, both, half)
PN pronoun, indefinite (anyone, nothing)
POS possessive particle (', 's)
PP pronoun, personal (I, he)
PP$ pronoun, possessive (my, his)
PPX pronoun, reflexive (myself, himself)
RB adverb, general (chronically, deep)
RBR adverb, comparative (easier, sooner)
RBS adverb, superlative (easiest, soonest)
RP adverbial particle (back, up)
SYM symbol or formula (US$500, R300)
TO infinitive marker (to)
UH interjection (aah, oh, yes, no)
VB verb, base (believe)
VBD verb, past tense (believed)
VBG verb, -ing (believing)
VBN verb, past participle (believed)
VBZ verb, -s (believes)
WDT det, wh- (what, which, whatever, whichever)
WP pronoun, wh- (who, that)
WP$ pronoun, possessive wh- (whose)
WRB adv, wh- (how, when, where, why)
XNOT negative marker (not, n't)
! !
" quotation mark
' apostrophe
( ( ) ) , , – –
. . … … : : ; ;
? ? ??? unclassified
Aceste notații sunt încapsulate într-un fișier care conține regulile și modalitățile de realizare a adnotării textelor ce poartă numele BLT.dat.
Este de menționat faptul că, întregul program este realizat în limbajul Java. Astfel, pentru a lansa în execuție programul este nevoie de a utiliza fișierul jar executabil qtag.jar care permite folosirea utilităților de care dispune QTAG 3.0.
Structura de directoare a programului este următoarea:
Pentru a putea utiliza QTAG 3.0 este nevoie de următoarea linie de comandă:
java -jar qtag.jar BLT.dat < input.txt > output.txt ,
unde input.txt este fișierul de analizat scris în limba engleză, iar output.txt este fișierul care va conține rezultatele adnotării acestui text. QTAG 3.0 permite utilizatorilor să-și creeze propriile lor fișiere de resurese de forma BLT.dat care să conțină modalitățile și notațiile prin care se poate realiza adnotarea textelor. Astfel, este nevoie să se realizeze o pre-adnotare a textelor prin realizarea unei strategii generale de adnotare a unor părți largi de corpus lingvistic.
Această generalizare a adnotării textelor prin realizarea unei modalități de adnotare a unor părți de corpora trebuie să îndeplinească următoarele condiții:
fiecare componentă de analizat (token) să fie urmată de numele adnotării sale (tag) separate prin spațiu;
fiecare pereche de acest fel să fie scrisă pe o singură linie;
De exemplu:
The det
cat noun-sing
sat verb-past
on prep
the det
mat noun-sing
. punct
După realizarea unui astfel de fișier se lansează componenta LexiconCreator pentru a creea efectiv fișierul .dat ce va fi folosit ca sursă de analiză pentru produsul QTAG 3.0. Adnotarea care va fi făcută de QTAG 3.0 după realizarea acestui fișier va avea ca rezultat un model obținut din cerințele și resursele de analiză pe care utilizatorul le-a specificat în fișierul al cărui conținut l-am prezentat mai sus.
Linia de comandă care trebuie executată pentru a obține un fișier utilizator ce conține modalitățile de adnotare a textelor este următoarea:
java -cp qtag.jar qtag.LexiconCreator catparse.dat < cat.txt,
unde catparse.dat este fișierul care va fi generat de LexiconCreator din fișierul de intrare pentru această comandă, și anume cat. txt al cărui conținut este cel prezentat mai sus, el fiind modalitatea utilizator de analiză a textului și adnotare a lui, alta decât cea standard oferită de QTAG 3.0 prin fișierul BLT.dat.
Astfel, după realizarea fișierului ce cuprinde modalitățile de adnotare a textelor introduse de analizator, se poate obține analiza efectivă a textelor prin reluarea comenzii uzuale:
java -jar qtag.jar catparse.dat < mytext.in > mytext.out
Rezultatul unei astfel adnotări prin utilizarea produsului QTAG 3.0 ar putea fi următorul:
<w pos="det">The</w>
<w pos="noun-sing">cat</w>
<w pos="verb-past">sat</w>
<w pos="prep">on</w>
<w pos="det">the</w>
<w pos="noun-sing">mat</w>
<w pos="punct">.</w>,
el fiind obținut în urma aplicării modalităților de adnotare exprimate în fișierul cat.txt.
Un exemplu de utilizare a produsului QTAG 3.0 ar fi următorul, prezentat prin figuri care indică pașii ce sunt urmați de către utlilizator pentru a obține o adnotare corectă a textului de analizat:
În urma realizării acestei linii de comandă se obține un fișier de analiză output2.txt care cuprinde rezultatele adnotării textului în limba engleză pe baza fișierului de modalități de adnotare BLT.dat. Conținutul fișierului rezultat în urma analizei este următorul:
<w pos="DT">Every</w>
<w pos="NN">thing</w>
<w pos="BEZ">is</w>
<w pos="CD">22</w>
<w pos="???">*</w>
<w pos="CD">33</w>
<w pos="SYM">+</w>
<w pos="CD">245667</w>
<w pos="DO">do</w>
<w pos="PN">something</w>,
unde fișierul de intrare care este astfel analizat are următorul format:
Every thing is 22 * 33 + 245667
do something
De remarcat faptul că, produsul QTAG 3.0 poate fi modificat ca structură de analiză din punct de vedere al codului care realizează adnotare, el fiind freeware ceea ce face ca sursele sale Java să poată fi primite de cel care îl utilizează în programare și implementare.
Utilizarea bazelor de date sub formă de dicționare electronice
O abordare care necesită o altă perspectivă asupra modului de efectuare a analizei textelor o reprezintă modalitatea prin care sunt utilizate ca bază de pornire în realizarea analizei, dicționare on-line. Acestea permit un contact permanent a celui care utilizează produse de analiză de corpora cu o bază de date ce cuprinde o multitudine de cuvinte și expresii care sunt utilizate în procesul de analiză. Aceste dicționare sunt astfel construite încât pot fi modificate și completate în momentul în care, în urma analizei unui text, se constată că anumite părți de analiză formate din cuvinte sau expresii nu fac parte din analiza efectuată. Astfel, posibilitățile on-line pot acoperi la un moment dat lipsa de consistență a analizei prin adăugarea în dicționar a elementelor noi de limbă vorbită sau scrisă care apar la o analiză aprofundată a elementelor de corpora. Miza este consistența și acuratețea procesului de analiză.
Această modalitate de realizare a analizei semantice sau sintactice a unui text oarecare se bazează pe o bază de date bine structurată care reprezintă background-ul aplicației care efectuează analiza propriu-zisă. Premiza de la care se pornește în realizarea unui astfel de proiect o reprezintă circularitatea efortului de analiză. Trebuie remarcat faptul că, la prima vedere, utilizatorul unui astfel de program de analiză trebuie să aibă posibilitatea de a realiza procesul interactiv. Acest lucru rezolvă o caracteristică primară a limbajului care stă la baza textelor de corpora, și anume, procesul continuu evolutiv al limbajului care nu poate fi inclus într-o rigurozitate totală impusă de un produs program definitoriu. Astfel, utilizatorul trebuie să aibă posibilitatea ca pe lângă procesul de analiză, să poată avea acces direct la baza de date cu ajutorul căreia se realizează procesul de analiză. Utilizatorul trebuie să aibă posibilitatea de a adăuga în dicționarul on-line, în orice moment, cuvinte și expresii care apar noi în textele analizate.
Interactivitatea este elementul definitoriu care rezolvă în orice moment al utilizării aplicației de analiză caracteristica evolutivă a limbajului utilizat în textele ce alcătuiesc corpusul lingvistic. Astfel, este nevoie de o aplicație integrată de analiză ce cuprinde posibilități de accesare a unui dicționar.
Aplicație integrată de analiză a textelor pe baza unui dicționar on-line
Prezentare de ansamblu a aplicației generale
Ideea de integrare a procesului de analiză a textelor introduse de utilizator cu posibilitatea de adăugare de cuvinte sau expresii în dicționarul cu ajutorul căruia se realizează procesul de analiză, este cuprinsă într-o pagină de web generală. La accesarea acestei pagini principale a aplicației integrate, utilizatorul are la dispoziție mai multe link-uri către diferite modalități de update-are a dicționarului on-line precum și către posibilitatea de analiză textuală. De remarcat faptul că, la realizarea aplicației s-a pus accentul pe circularitatea efortului de analiză a textelor utilizator care necesită prezența în background a dicționarului on-line. Capabilitățile de analiză și adăugare de noi informații în dicționar sunt extinse de o abordare distribuită. Astfel, pentru dimensiuni mari de corpora analizate, există posibilitatea ca mai mulți utilizatori să poată realiza fie analiză de text, fie adăugări de cuvinte sau expresii în dicționar care sunt utilizate în procesul de analiză.
În momentul lansării aplicației principale clientul este pus în fața unei decizii lesnicioase, care asigură integralitatea efortului de analiză și updatare a dicționarului on-line. Pagina principală a aplicației are următoarea formă:
Posibilitatea de a realiza analiza de text este văzută ca o aplicație de sine stătătoare care este, totuși, integrată cu posibiltățile oferite de adăugarea on-line de cuvinte. Aplicația de analiză a textelor introduse de utilizator poate fi rulată de oricare din utilizatorii care rulează aplicația principală, atât local cât și distribuit într-o rețea. În același mod, adăugarea de cuvinte în dicționar respectă această modalitate de analiză locală sau distribuită.
Adăugarea de cuvinte în dicționarul on-line se poate realiza distribuit din pagina principală a aplicației la care se poate adăuga analiza de texte, sau se poate realiza local, pe fiecare calculator pe care este instalată aplicația principală și aplicația de analiză a textelor. Astfel, în orice situație, local sau distribuit în rețea, analiza efectuată direct asupra textelor de corpora este integrată la nivelul aplicației principale.
Prezentarea aplicației de analiză de text în contextul aplicației generale
Analizatorul de text este o aplicație scrisă în Java în mediul de dezvoltare Symantec Visual Cafe 4.0 Expert Edition. Aplicația are la bază conceptele pe care Java le pune la dispoziție referitoare la baze de date și accesul la acestea. În acest sens, conceptele care însoțesc paradigmele JDBC și ODBC sunt scheletul activității de extragere a informației din textele de analizat. Astfel, utilizarea pentru efortul de extragere a informației din textul de analizat, a bazelor de date relaționale este o altă modalitate de abordare de către specialiștii în procesarea limbajelor naturale a procesului de IE – Information Extraction.
Utilizarea analizatorului de text este indicată în momentul în care se dorește extragerea de informații referitoare la structura semantică a textului introdus de utilizator pentru analiză. Pe lângă posibilitatea de a vedea ce părți de vorbire, din punct de vedere statistic, sunt în textul de analizat, programul permite afișarea explicațiilor cuvintelor căutate fie în dicționar, fie în text, precum și părțile de vorbire pe care le pot lua cuvintele căutate, în funcție de modul în care au fost introduse în dicționar.
Utilizatorul poate alege, în funcție de partea de vorbire pe care o poate lua cuvântul/cuvintele căutate, explicația pentru fiecare parte de vorbire în parte. Se rezolvă, pentru moment, aspectul contextual al cuvintelor în textul de analizat. Pentru fiecare parte de vorbire pe care un cuvânt o poate lua într-un text există o explicație care să prezinte într-un mod destul de larg contextul de utilizare a cuvâtului respectiv în textele din corpora limbii române. Aspectele contextuale sunt una din problemele pe care aplicația încearcă să o rezolve, într-o măsură mai mare sau mai mică.
Spre deosebire de gramatica limbii engleze în care problemele contextuale sunt reduse și pentru care se poate face o analiză a textelor mult mai corectă și completă, gramatica limbii române este mult mai complexă. Dacă pentru limba engleză există deja standarde de analiză contextuală a părților de corpora, la fel cum s-a văzut din capabilitățile pe care le oferă generatoarele de analizoare semantice sau sintactice prezentate în capitolele anterioare, pentru gramatica limbii române nu există încă o serie de standarde clare referitoare la extragerea informației utile pentru analizatoare electronice de text.
JDBC – Java Database Connectivity
Marea majoritate a aplicațiilor distribuite în rețele care sunt accesate concomitent de mai mulți utilizatori sunt centrate în jurul accesului la date. La baza oricărei astfel de aplicații se află o bază de date de un anumit tip. Aplicațiile de acest tip se bazează pe baze de date relaționale care permit utilizatorilor concurența și controlul tranzacțiilor, precum și posibilități avansate de recuperare a datelor în cazul căderii sistemului.
La baza acestor baze de date relaționale se află standardul de definire și extragere a datelor SQL. Standardul SQL a permis programatorilor unor astfel de tipuri de baze de date să creeze capabilități puternice și universale de definire a structurilor de date, astfel încât aceste modele concepute să poată fi independente de baza de date.
Modelul relațional, care a fost destul de controversat la începutul anilor ’80, este astăzi un model universal acceptat pentru concepția bazelor de date. API-ul (Application User Interface) Java JDBC (Java Data Base Connectivity) definește un mod standard de accesare a unei baze de date relaționale dintr-o aplicație Java, indiferent de mașina de pe care se rulează aplicația respectivă sau de mașina unde se află stocată baza de date. Astfel, JDBC suportă mai mulți clienți într-o rețea care să acceseze concomitent aceeași bază de date într-un mod transparent.
Această independență de platforma de implementare este de o mare importanță. Astfel, programele care lucrează cu baze de date pot fi scrise fie ca aplicații de sine stătătoare (stand alone) sau applete ce rulează din pagini web. Acestea din urmă permit accesul la depărtare aproape instantaneu la datele stocate în bazele da date relaționale ca și cum aceste baze de date s-ar afla pe mașina celui care rulează aplicația distribuită.
Având la dispoziție portabilitatea limbajului de programare Java care permite dezvoltarea de modele de obiecte independente de platforma de implementare prin utilizarea portabilității limbajului de programare și a independenței de mașină a acestuia, rezultatul este reprezentat tot de modele care la rândul lor sunt portabile.
Utilizarea JDBC
API-ul (Application User Interface) Java JDBC (Java Data Base Connectivity) este un API “thin” (“subțire”) deoarece el împachetează limbajul SQL precum și răspunsurile la diferite interogări ale bazelor de date realizate în acest limbaj în diferite obiecte recunoscute de limbajul de programare Java.
Marea majoritate a programelor Java care utilizează API-ul JDBC realizează următoarele:
– lansează un driver JDBC;
– stabilesc o conexiune la o bază de date prin specificarea căii (URL – ului) bazei de date respective;
– interogarea opțională a bazei de date pentru seturi de date pe care le cuprinde;
– extragerea opțională a shemei de meta-structură a informațiilor din baza de date;
– crearea unui obiect SQL sau unei interogări standard a bazei de date și trimiterea de interogări spre baza de date;
– procesarea rezultatelor interogărilor adresate bazei de date;
– închiderea conexiunii;
JDBC se bazează pe protocolul ODBC, între cele două existând numeroase similitudini. De fapt, firma Sun pune la dispoziție o interfață între cele două protocoale astfel încât utilizatorul să poată accesa orice bază de date care are descrisă un driver ODBC prin utilizarea API-ului JDBC.
O componentă importantă a implementării protocolului JDBC o reprezintă driverul JDBC. Driverul stabilește conexiunea cu baza de date și implementează orice protocol cerut pentru a transmite interogări și date între client și server.
Din perspectiva unui API (Application User Interface) driverul realizează acest lucru prin crearea unui obiect care implementează interfața java.sql.Connection pentru aplicarea cerințelor JDBC.
Din perspectiva unui protocol, obiectul Connection creat de driver trebuie să transforme cererile asupra bazei de date în cereri native API pentru DBMS (Data Base Motor Sequence) pentru un driver de tipul 1 sau 2, sau să împacheteze cererile într-un stream și să le transporte la componenta intermediară aflată la distanță (care poate avea propriul driver pentru conectarea la baza de date ca server). Această componentă intermediară aflată la distanță nu are nici o legătură cu protocolul JDBC.
În plus, driverul trebuie să realizeze o mapare a tipurilor de date între JDBC și tipurile incluse în baza de date, precum și interpretarea secvențelor escape SQL. Specificațiile JDBC permit extinderea tipurilor de date, astfel încât driverul JDBC poate mapa tipuri de date specifice bazelor de date ale diferiților producători de sisteme de gestiune a bazelor de date la tipuri specifice de pachete ale diferiților producători de aplicații și pachete utile limbajului Java.
Tipuri de drivere JDBC
Selectarea tipului corect și util de driver pentru o aplicație este o decizie critică pentru realizatorii unui proiect. Nu trebuie considerat faptul că “toate driverele sunt la fel” sau că un driver este o parte comună a unei aplicații de baze de date. Driverele adaugă valoare semnificativă unui sistem iar capabilitățile fiecărui tip variază foarte mult de la unul la altul. Nu în ultimul rând, driverele de baze de date trebuie să asigure flexibilitatea și capabilitățile asigurate de JDBC. Astfel, în Java aceste tipuri de drivere sunt definite după un anumit număr. Acest număr determină o categorie de drivere. Aceste categorii sunt următoarele:
Tipul 1: JDBC/ODBC;
Tipul 2: Native – API;
Tipul 3: Open Protocol-Net;
Tipul 4:Proprietary Protocol-Net.
Tipul de protocol utilizat de aplicația în speță, anume analizatorul de text folosește protocolul de tipul 1, și anume protocolul JDBC/ODBC. De aceea vom face o descriere pe scurt a acestui tip de protocol.
Astfel, Tipul1:JDBC/ODBC este un protocol care nu are nici o capabilitate de adresă de redirectare, și necesită ca un driver de ODBC pentru baze de date să fie deja instalat pe mașina care utilizează protocolul JDBC. Un driver de acest tip transformă în timp rezonabil interogările realizate prin intermediul său în interogări ODBC echivalente și le transmite mai departe, de obicei, prin rutine native API direct către driverul de ODBC. O dată ce ritinele native API sunt incluse în modul de accesare a unui driver ODBC, un driver JDBC de tip 1 folosește, de obicei, componentele bibliotecii native care sunt accesate cu metode native. Driverul JDBC/ODBC (sun.jdbc.odbc.JdbcOdbcDriver), pus la dispoziție de firma Sun împreună cu mediul de dezvoltare Java SDK a programelor Java, este un exemplu de driver de tip 1. Modalitatea standard de configurare și utilizare a unui driver de tip 1 este prezentată în figura următoare:
Figura 12 – Driverul JDBC de tip 1
4.3 Lansarea unui driver
Managerul de drivere (java.sql.DriverManager) utilizează proprietatea „sql.drivers” pentru a identifica clasele care conțin driverele JDBC. Managerul de drivere va înregistra aceste drivere într-o listă. Orice aplicație poate seta această proprietate, dar în practică, driverele sunt înregistrate automat prin lansarea clasei care le conține. Astfel, se înregistrează automat pe sine însuși prin execuția unei secvențe statice de cod. De aceea, tot ceea ce un programator trebuie să facă este, fie să realizeze o nouă instanță a driverului, de exemplu
MyVendorsDriver driver = new MyVendorsDriver(),
sau să lanseze explicit clasa care cuprinde driverul respectiv, de exemplu
Class.forName(„MyVendorsDriver”);
Când un driver este utilizat pentru a completa o conexiune la baza de date specificată de un URL, managerul de drivere va încerca să încarce fiecare driver care a fost deja înregistrat până când unul dintre ele va anunța că suportă protocolul acelei URL (returnează true în urma lansării metodei acceptsURL() ).
JDBC pentru aplicații
O aplicație Java care utilizează JDBC poate identifica driverul de utilizat prin „listarea” clasei de drivere în proprietatea sql.drivers, sau prin încărcarea explicită a clasei care conține driver-ul. În acest caz clasa driverului trebuie să fie conținută în proprietatea căii mașini virtuale (inclusă în classpath pentru java.class.path ).
O dată ce driverul a fost încărcat, un driver de tipul 1 sau 2 ar trebui să fie de ajuns pentru conectarea la o bază de date identificată printr-o URL locală (de exemplu, pe mașina locală), sau la o bază de date care poate fi accesată de orice driver nativ care suportă la rândul lui driverul JDBC., De exemplu, dacă se utilizează un driver de legătură de tip ODBC, se poate efectua conectarea la orice bază de date care are un driver ODBC instalat. Acest lucru se poate observa din următoarea figură:
Figura 13 – Driverul JDBC de tip 1 pe aceeași mașină cu baza de date
Conectarea efectivă la o bază de date
Pentru a deschide o conexiune la o bază de date se utilizează metoda statică getConnection() a managerului de drivere la care se asigură un URL pentru localizarea bazei de date:
Connection con = DriverManager.getConnection ( “jdbc : my_vendors_driver : //host : port / datasource_name”, user_id, password);
Dacă baza de date nu se află pe aceeași mașină cu aplicația care lansează driverul JDBC, dar poate fi accesată prin drivere intermediare care utilizează un protocol de baze de date în rețea cum ar fi SQL*Net, acest protocol trebuie să cunoască locația efectivă a bazei de date pentru a putea permite interfața cu driverul de JDBC care încearcă să acceseze la distanță această bază de date. De aceea specificarea URL-ului în rețea este mult mai complexă, având nevoie să fie specificate două nume de gazdă în declarația de conectare.
Analizatorul de text – modalități de utilizare a dicționarelor on-line în extragerea informației
Aplicația de analiză a textelor pe baza unui dicționar on-line urmează îndeaproape modalitățile de accesare și interogare a bazelor de date oferite de limbajul Java. Protocolul JDBC este cel care permite programatorului să realizeze o interfață între datele din dicționarul on-line aflat sub forma unei baze de date, realizată cu Microsoft Access, și programul în sine, care se dorește a fi o modalitate lesnicioasă de accesare a acestor date.
Proiectul de față folosește ca mod de abordare a lucrului cu bazele de date capabilitățile oferite de limbajul Java prin mediul Symantec Visual Cafe 4.0 Expert Edition de dezvoltare a proiectelor în acest limbaj. În acest sens, o parte a metodelor și claselor prezentate în capitolul anterior, referitoare la lucrul efectiv cu baze de date, sunt rescrise de acest mediu, putând fi folosite ca și componente de sine stătătoare. De aceea, multe din clasele comune limbajului Java referitoare la bazele de date precum și la lucrul cu interfețe sunt unele particulare, special create și rescrise de mediul Symantec Visual Cafe 4.0 Expert Edition de dezvoltare a proiectelor în acest limbaj. Ele sunt stocate în biblioteci speciale care însoțesc acest mediu vizual, putând fi apelate în orice moment, în urma specificării căilor corecte la inițializarea programului. În proiectul de față, aceste biblioteci de clase pe care programul le utilizează se afle stocate în directorul clase ale aplicației.
Pentru ca aplicația să poată rula trebuie să existe cel puțin un driver de ODBC instalat pe calculatororul pe care rulează aplicația. Referitor la interfața dintre acest driver de ODBC și driverul de JDBC folosit de aplicație pentru a putea accesa baza de date există mai multe modalități de setare, fiecare modalitate fiind realizată în funcție de caracterul local sau distribuit al modului de accesare a bazei de date în procesul de analiză.
Astfel, se poate seta un mod local de realizare a interfeței la baza de date prin joncțiunea protocoalelor JDBC/ODBC prezentate în capitolul anterior. Pentru a seta corect driverul ODBC și interfața acestuia cu driverul JDBC, care este utilizat de program pentru putea realiza o conexiune la baza de date, se urmăresc etapele de mai jos:
Se apelează din mediul Windows icoana de Control Panel din care se accesează ODBC (32 bit) pentru a putea realiza configurarea driverului de ODBC și a interfeței acestuia cu driverul de JDBC. Acest lucru se poate vedea și din figura următoare:
După accesarea icoanei ODBC (32 bit) se trece la crearea unei interfețe proprii pentru driverul de ODBC prin adăugarea unui nume utilizator sursei din care se vor extrage datele prin această interfață. După descrierea numelui sursei de date pentru proiectul în cauză, se trece la identificarea căii fizice unde se află baza de date spre care se face interfața. Prin această specificare se indică tipul și calea de directoare spre baza de date care va fi folosită de aplicație prin intermediul driverului de ODBC și a interfeței acestuia cu JDBC. Acest lucru se poate observa din figura alăturată:
De menționat faptul că, la meniul anterior, prin accesarea butonului Advanced… se pot seta elementele de acces la baza de date referitoare la utilizatori și parole, precum și la modul în care se efectuează tranzacțiile asupra bazei da date într-un mod de lucru distribuit. Aceste setări trebuie să fie comune cu cele care au fost deja făcute de aplicația integrată ce cuprinde și analizatorul de texte.
Setările referitoare la utilizator/utilizatori și parolele lor sunt utilizate de aplicație în momentul în care se dorește să se realizeze conectarea standard Java la baza de date. Modalitatea de realizare soft a acestei conectări a fost prezentată din punct de vedere conceptual și ca șablon în capitolul Conectarea efectivă la o bază de date.
În cazul proiectului de față, acest lucru este realizat prin următoarea secvență de cod din clasa principală a aplicației:
String dbUrl = "jdbc:odbc:MS Access Database";
String user = "user";
String password = "user";
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection c = DriverManager.getConnection(dbUrl, user, password);
Se pot observa setările driverului ODBC referitoare la numele sursei de date, precum și setările interfeței dintre driverul ODBC și JDBC, acesta din urmă asigurând accesul la datele din dicționar, pe baza apelării claselor și metodelor specificate prin metoda Class.forName(“sun.jdbc.odbc.JdbcOdbcDriver”). Se observă modul de conectare prin utilizarea metodei statice getConnection() având ca parametri URL-ul unde se află baza de date (URL obținut din setările făcute pentru driverul de ODBC după modelul prezentat anterior și care conțin fie calea absolută către baza de date, fie calea de rețea în cazul unei baze de date aflată la distanță pe un alt calculator). Acest mod de conectare static la baza de date este utilizat pentru a obține rezultate în urma realizării de interogări asupra bazei de date. Trebuie remarcat faptul că, modalitatea de extragere a informației pentru analiza de texte utilizând o bază de date sub forma unui dicționar on-line are atât avantaje cât și dezavantaje.
Avantajele pe care le oferă o astfel de abordare sunt reprezentate de modalitatea rapidă și aproape naturală de extragere a informației, bazatâ pe interogări în limbajul SQL care reduc la nivelul mașină problemele de analiză pe care și le pun, în mod normal, specialiștii în analiza limbajelor naturale.
Astfel, modalitatea de transpunere a interogărilor asupra unui text în formatul unei interogări SQL, care să fie similară cu cea din limbajul natural și să poată fi interpretată de programul în sine și de baza de date asupra căreia se realizează aceste interogări, este realizabilă cu un efort mediu din partea programatorului. Problemele care se pun în acest moment se leagă de acuratețea și corectitudinea în care sunt rezolvate problemele de extragere a informației. Apar, astfel, dificultăți în ceea ce privește modul de extragere a informației. Acestea se leagă de modul în care se face efectiv analiza lexicală la nivel de lexemă.
De aceea, la nivel de utilizare în analiza unui text, din punct de vedere al utilizării limbii române ca limbă de scriere și analiză, trebuie să se ia în considerare internaționalizarea aplicației, prin setarea unor proprietăți locale referitoare la recunoașterea setului de caratere românești (“ă”, ”â”, ”î”, ”ș”, “ț”, “Δ, “Ș”, “Ț”). Aceste cerințe sunt legate de posibilitatea de recunoaștere a caracterelor românești în procesul de extragere a informației din textul analizat și comparare a rezultatelor cu cele obținute de specialiștii lingviști care nu au utilizat produsul program de analiză în cauză.
Marea majoritate a bazelor de date nu au probleme în a păstra drept date de intrare șiruri de caratere unicode (șiruri de caractere multibyte specifice scrierii în diferite limbi, altele decât limba engleză, și care păstrează specificul scrierii în limba respectivă). De exemplu, dacă se introduce în baza de date șirul cu valoarea “W\u00e4hrung” (“Währung” care înseamnă valoare monetară în limba germană) cu următoarea comandă SQL (care poate fi adaptată și din punct de vedere al limbajului Java împreună cu JDBC):
stmt.executeUpdate(“INSERT INTO dept VALUES (60, ‘Währung’,’Berlin’)”);
și dacă se încearcă obținerea aceleași valori printr-o interogare simplă a bazei de date, se va obține aceeași valoare, în mod normal. De aceea, dacă se dorește internaționalizarea aplicației și recunoașterea diferitelor seturi de caractere specifice diferitelor limbi pentru care se realizează acest lucru, este nevoie să se știe dacă baza de date și driverul atașat acesteia care realizează interfața cu aplicația pot suporta șiruri Unicode.
Dezavantajele apar în momentul în care se încearcă să se realizeze o analiză corectă, după anumite criterii, utilizând capabilitățile oferite de internaționalizarea aplicației – lucru ce apare și în cazul aplicației noastre, în care căutările de cuvinte în texte sau în dicționarul atașat cu care se face analiza trebuie să se facă de forma locale-sensitive (să încorporeze în cadrul căutărilor aspectele locale ale limbii române scrise, și anume setul de caractere speciale “ă”, ”â”, ”î”, ”ș”, “ț”, “Δ, “Ș”, “Ț” care nu apar în localul standard reprezentat de limba engleză clasică ).
De aceea, ar trebui îmbinate într-un mod armonios atât analizoarele lexicale generate pe baza unor gramatici de intrare, care să surpindă dependența sau independența de context, cu analizoarele bazate pe dicționare on-line, care să rezolve în totalitate dependențele de context și aspectul local al problemei analizei de texte, din punct de vedere al utilizării limbii române ca limbă de analiză.
5.1 Prezentare detaliată a analizorului de text – modalități de realizare și implementare
Analizatorul de texte bazat pe dictionarul on-line este parte integrantă a produsului de anvergură care cuprinde modalități distribuite sau locale de lucru cu un dicționar on-line al limbii române, precum și produsul de față care realizează o analiză lexicală a textului introdus de utilizator.
Pe lângă analiza propriu-zisă a textelor, analizatorul permite o interactivitate a utilizatorului cu dicționarul on-line. Această interactivitate se rezumă la posibilitatea de a obține on-line explicația/explicațiile cuvintelor căutate în textul introdus, împreună cu părțile de vorbire pe care aceste cuvinte le pot avea în diferite contexte de utilizare în limba română.
Pentru a putea prezenta mai bine capabilitățile oferite de analizator în contextul aplicației integrate vom prezenta în figura ce urmează imaginea inițială, de ansamblu, a momentului lansării în execuție a acestuia.
Algoritmul după care se desfășoară procesul de analiză împreună cu modul în care sunt tratate diferite probleme sub forma unor evenimente care interferează cu procesul de analiză ar putea avea următoarea formă:
Deschidere aplicație din pagina principală a produsului integrat de analiză;
Cât timp nu_e_deschis_fișier_de_analizat
Dezactivare capabilități_de_căutare_în_dicționar pentru cuvinte din text;
Căutare cuvânt în dicționar;
Dacă lungimea_cuvântului_de_căutat <> 0 atunci
begin
Căutare_cuvânt_în_baza_de_date;
Afișare_explicații;
Selectare_părți_de_vorbire_posibile;
end;
altfel
Afișare_mesaj_eroare;
end_dacă
Deschidere fișier_de_analizat
Dacă este_fișier_text atunci
begin
Afișare_statistică_fișier;
Activare capabilități_de_căutare_în_dicționar_pentru_cuvinte_din_text;
Căutare_cuvânt_în_text;
Contorizare_număr_apariții_cuvânt_în_text;
Afișare_explicații;
Selectare_părți_de_vorbire_posibile;
Analizează morfologic textul
Dacă există_substantive atunci
begin
Afișare_substantive_în_text;
Atenționare_părți_vorbire_multiple;
Contorizare_apariții_substantiv_în_text;
end;
altfel
begin
Afișare_mesaj_eroare;
Activare capabilități_adăugare_cuvinte_în_dicționar;
end;
Dacă există_adjective atunci
begin
Afișare_adjective_în_text;
Atenționare_părți_vorbire_multiple;
Contorizare_apariții_adjectiv_în_text;
end;
altfel
begin
Afișare_mesaj_eroare;
Activare capabilități_adăugare_cuvinte_în_dicționar;
end;
Analog pentru adverbe și verbe…
end;
altfel
begin
Afișare_mesaj_eroare;
Dezactivare capabilități_de_căutare_în_dicționar pentru cuvinte din text;
Activare capabilități_de_căutare_în_dicționar;
end;
end_dacă;
Închidere aplicație de analiză lexicală;
Revenire în aplicația integrată;
STOP.
Algoritmul prezentat mai sus surprinde, în linii mari, modalitatea de abordare de către produsul program a ideii de analiză a textului introdus de utilizator. Sunt tratate, de asemenea diferite erori sau ambiguități în analiza textului sau în căutările on-line care se pot efectua. Se pornește de la premiza că utilizatorul care folosește acest produs nu este familiarizat cu ideea de analiză a textelor utilizând produse program. De aceea, aplicația prezintă o interfață simplă cu utilizatorul care să pemită acestuia utilizarea programului chiar dacă nu este încă familiarizat cu modalitățile electronice de analiză lexicală sau sintactică a componentelor de corpora.
Acțiunile pe care programul trebuie să le execute și care sunt surprinse în algoritmul anterior prin nume sugestive (de exemplu, Afișare_explicații sau Căutare_cuvânt_în_baza_de_date) cuprind mai multe etape de dezvoltare și implementare, fiecare etapă având un mod riguros de prezentare în capitolele următoare. Aceste acțiuni definesc posibilitățile pe care programul în sine le oferă utilizatorului în realizarea analizei de text. Deschiderea unui fișier text de către utilizator în vederea realizării unei analize lexicale a textului este elementul de început în mecanismul de extragere a informației utile din text, pe baza dicționarului on-line. După deschiderea fișierului de analizat forma aplicației este următoarea:
5.2 Modalități de căutare a informației în text
Am amintit în capitolul introductiv de problemele care apar referitor la căutarea informației utile într-o bază de date. Aceste probleme pot apare și la căutarea informației utile în text în urma unei cereri explicite din partea utilizatorului. Pentru a rezolva problema căutării de informații în textul deschis spre analiză, programul de față pune la dispoziția utilizatorului un “motor de căutare” care are formatul unei ferestre de dialog, permițând utilizatorului să aibă contact direct la eforul de căutare a informației dorite în text.
Acest “motor” este creat în limbajul Java sub forma unei clase care extinde clasa standard Dialog. Motorul de căutare a informației utile în text rescrie metodele unui obiect de bază în operațiile de căutare, și anume FindReplaceEngine. Acest obiect este scris în Java, iar metodele lui rescrise de “motorul de căutare” extind clasa java.lang.Object. Formatul clasei obiectului FindReplaceEngine care stă la baza operațiilor de regăsire a informației utile în textul de analizat are următoarea formă:
import java.lang.*;
import java.awt.*;
public class FindReplaceEngine extends java.lang.Object
{private FindReplace FR;
public FindReplaceEngine(FindReplace thefindreplace){
FR = thefindreplace;}
void FindIt() {
int suspect_length;
int foundit_index;
String found_string;
String string_to_find;
String body;
boolean foundit;
boolean eofReached;
body = FR.getBody().getText();//Setează toate șirurile la majuscule pt. comparare
body = body.toUpperCase();
foundit = false;
FR.setFoundIt(foundit);
eofReached = false;
string_to_find = FR.getFind().toUpperCase();
suspect_length = string_to_find.length();
while(!foundit && !eofReached) {
foundit_index = body.indexOf(string_to_find, FR.getIndex());
if(foundit_index == -1) eofReached = true;
else {
if(FR.isCase()) {
found_string = FR.getBody().getText().substring(foundit_index, foundit_index + suspect_length);
if(found_string.equals(FR.getFind())) {
foundit = true;
} else { FR.setIndex(foundit_index + suspect_length); }
} else foundit = true;
if(foundit) {
FR.setIndex(foundit_index + suspect_length-1);
FR.getBody().select(foundit_index, foundit_index + suspect_length);
FR.incOccur();
}
}
}
FR.setFoundIt(foundit);
}
public int LinesDown(int ending)
{ String working_body;
int whichchar = 0;
int line = 0;
working_body = FR.getBody().getText();
while(whichchar <= ending) {
if(working_body.charAt(whichchar) == '\n') line++;
whichchar++;
}
return line;
}
}
Metodele clasei FindReplaceEngine formează metodele obiectului ce stau la baza realizării clasei de dialog FindDialog prin rescrierea lor într-o nouă instanță a clasei FindReplaceEngine, de bază în realizarea căutărilor în textul de analizat.
Clasa FindDialog este cea care implementează fereastra de dialog cu utilizatorul în vedearea satisfacerii cererilor acestuia în privința extragerii informației utile din text.
În momentul realizării căutărilor în text fereastra de dialog cu utilizatorul care instanțiază clasa FindDialog se deschide în formă modală pentru a permite aplicației principale să poată fi vizibilă împreună cu fereastra de dialog activă în momentul căutărilor. Forma sub care apare fereastra de dialog în momentul în care utilizatorul dorește să realizeze o căutare în text se prezintă astfel:
Metoda principală a clasei FindDialog este una privată și se instanțiază automat o dată cu instanțierea clasei definitorii. Numele este sugestiv, și anume find(). Această metodă folosește, la rândul ei, instanțele metodelor obiectului FindReplaceEngine , definitoriu în operațiile de căutare a informației utile în textele de analizat. Modalitatea de instanțiere a clasei FindDialog în aplicația principală se poate observa din construcția metodei find() a cărei instanță în programul principal rezolvă atât problema căutării informației utile în text, dar și vizualizarea, pe pași, a regăsirii informației în textul analizat, chiar și în cazul mai multor apariții ale acesteia. Forma codului metodei find() din clasa principală Frame1() a aplicației este următoarea:
void find()
{ int select_start;
int select_end;
int select_diff;
int start_index;
String select_body;
textArea1.select(0,0);
select_start = textArea1.getSelectionStart();
select_end = textArea1.getSelectionEnd();
select_diff = select_end – select_start;
if(select_diff > 0 && select_diff < 20) {
m_findReplace.setFind(textArea1.getSelectedText());
start_index = textArea1.getSelectionStart() + select_diff;
m_findReplace.setIndex(start_index);
}
else {
m_findReplace.setFind("");
m_findReplace.setIndex(textArea1.getSelectionStart());
}
m_findReplace.setOccur(0);
FindDialog m_findDialog2 = new FindDialog(this, "Cauta cuvant in text…", true, m_findReplace);
m_findDialog2.setLocation(410, 110);
m_findDialog2.show();
}
Metoda find() din clasa principală folosește atât metode rescrise ale obiectului de bază FindReplaceEngine în extragerea de informație utilă din text , cât și o nouă instanțiere a clasei de dialog FindDialog care realizează atât feed-back-ul cu utilizatorul în ceea ce privește modul de căutare a informației utile în text și a regăsirii ei, cât și contorizarea numărului de apariții a informației căutate în text.
Modalitatea în care acționează o instanță a clasei FindDialog este surprinsă în interiorul metodei proprii private find() care are următorul format:
FindReplace m_find;
private void find()
{FindReplaceEngine fre;
m_find.setFind(m_findText.getText().trim());
m_find.setCase(m_matchCase.getState());
fre = new FindReplaceEngine(m_find);
fre.FindIt();
if(m_find.isFoundIt()) m_statuslabel.setText("Nr. gasiri " + m_find.getOccur() );
else {m_statuslabel.setText("Sfarsit text: " + m_find.getOccur() + " regasiri");
this.getToolkit().beep();}
m_statuslabel.setVisible(true);}
Trebuie menționat faptul că, atât clasa FindDialog() cât și modalitatea de regăsire în text a informației utile extrasă de “motorul de căutare” vor fi folosite în rezolvarea problemelor legate de analiza morfologică a textului introdus de utilizator.
5.3 Modalități de căutare a informației în dicționar
Modul în care sunt regăsite informațiile în textul de analizat influențează și modul în care vor fi regăsite informațiile în baza de date ce stă la baza analizei efective de text. Și totuși există destul de multe diferențe de abordare a acestei probleme.
De la început trebuie arătat faptul că modul de căutare a informației în baza de date aflată la dispoziția analizatorului de text se leagă de capabilitățile oferite de JDBC și de limbajul de definire și extragere a datelor SQL. Extragerea efectivă a informației din baza de date se realizează prin interogarea directă prin conexiune a bazei de date, dar nu prin extragerea de informații direct din tabele, ci dimpotrivă, din interogări (query) deja existente în baza de date. Aceste interogări care există în baza de date au fost create în prealabil de către programatorul acestei aplicații de analiză a textelor utilizator având în vedere două lucruri esențiale în proiectarea și lucrul cu bazele de date, și anume:
integritatea referențială a datelor, care este cea mai importantă, și
rapiditatea accesului la datele care sunt necesare procesului de analiză;
Aceste interogări predefinite pe baza de date de către programator, care au fost realizate direct în mediul Microsoft Access pe baza de date, sunt universal valabile pentru toate tipurile de extrageri de informații din bază, în cadrul procesului de analiză a textului utilizator. Aceste interogări predefinite vin în ajutorul simplificării efortului de programare a modalităților de extragere a informației din baza de date. Se reduce, astfel, mărimea codului SQL din programul Java, ceea ce face ca aplicația să poată accesa mult mai rapid datele necesare din baza de date pentru efectuarea analizei.
Astfel, în plus față de structura bazei de date care este utilizată pentru a implementa dicționarul on-line utilizat în procesul de analiză a textului, în structura de QUERY a bazei de date dicționar_xp.mdb au fost introduse următoarele interogări: substantive, adjective, adverbe, verbe_all, vebe_cojugate. Acestea sunt rezultatul unui întreg set de subinterogări a bazei de date între care există relații de legătură (join) prin structura diagramei de relații între entități (ER – Entity Relationship).
Aceste interogări standard finale sunt utilizate de clasa principală a aplicației în vederea extragerii informațiilor utile referitoare la părțile de vorbire, explicațiile sau alte elemente care alcătuiesc, la un moment dat, rezultatul unei interogări utilizator asupra unui text, în concordanță cu datele introduse până în acel moment în baza de date.
O dată cu realizarea conexiunii cu baza de date, după cum s-a prezentat într-un capitol anterior, se poate trece efectiv la analiza textului sau a unui cuvânt ales din text sau din dicționar.
Trebuie amintit faptul că, analiza morfologică a unui cuvânt din text extinde atât modul de analiză a unui cuvânt căutat în dicționar, dar și modul în care este regăsit în text , modalitate prezentată mai sus. De aceea, vom prezenta în cadrul acestei modalități de analiză, felul în care decurge din punct de vedere al codului realizat, acțiunea de extragere a informației utile folosind ca sursă de date dicționarul on-line ca interfață către baza de date dicționar_xp.mdb.
După regăsirea cuvântului căutat în text folosind modalitățile de extragere și regăsire a informației prezentate în capitolul anterior, se trece la utilizarea codului SQL prin JDBC pentru interogarea acelui query standard realizat și prezentat anterior, care cuprinde cuvântul, partea/părțile de vorbire pe care le poate lua acesta în funcție de modul în care a fost introdus în dicționar, precum și explicația. Rezultatele unei astfel de interogări având ca parametru cuvântul căutat în text și în baza de date sunt trecute într-o structură specială de date (ResultSet), care poate fi parcursă cu metode native specifice. Codul SQL introdus într-o declarație (Statement) JDBC are următorul format:
Connection cc = DriverManager.getConnection(dbUrl, user, password);
Statement ss = cc.createStatement();
r2 = ss.executeQuery("SELECT cuvant,parteDeVorbire,explicatie FROM cuv_parteV_explicatie " +"WHERE " + "(cuvant='" + textField2.getText() + "') " ),
unde cc este conexiunea JDBC la baza de date, iar r2 este ResultSet-ul în care se stochează rezultatele interogării. De asemenea, cuvânt este câmpul din interogarea standard cuv_parteV_explicatie din baza de date după care se face căutarea.
Rezultatele sunt afișate alături de posibilitatea pe care utilizatorul o are de putea vedea, prin click de mouse, o anumită explicație pentru o anumită parte de vorbire pe care cuvântul respectiv o poate lua în textul respectiv.
Analiza morfologică a textului – parte integrantă a sistemului de extragere a informației din dicționar
În ceea ce privește analiza morfologică a textului, modalitatea de abordare este destul de asemănătoare cu cea prezentată anterior. Spre deosebire de modul în care era extrasă informația utilă pentru un singur cuvânt din dicționar, în momentul în care se dorește, de exemplu, să se cunoască substantivele dintr-un text, precum și numărul de apariții pentru fiecare în parte, apar anumite probleme specifice. Astfel, una din ele, chiar poate cea mai importantă, este eliminarea redundanței informației care trebuie analizată din text.
Eliminarea redundanței informației dintr-un text de analizat se poate realiza în modul următor: se trece textul împărțit în elemente unice de analizat (cuvinte simple delimitate de , ‘ . … – ! ? / și alți delimitatori) într-un șir dinamic din care se elimină replicile elementelor introduse obținându-se eliminarea redundanței de apariție a cuvintelor în textul respectiv. Pe structura nou obținută, din care s-a eliminat redundanța, se trece la analiza morfologică efectivă.
Modalitățile de regăsire a informației utile în cazul analizei morfologice sunt, în mare parte, asemănătoare cu cele de regăsire a unui cuvânt în dicționar împreună cu părțile de vorbire pe care acesta le poate lua. Astfel, de exemplu, dacă se dorește regăsirea substantivelor dintr-un text introdus de utilizator, se “perie” textul introdus în noua structură de date obținută în urma eliminării redundanțelor și se vede dacă, prin consultarea interogării standard substantive din baza de date, există vreo potrivire între elementele din structura nouă și rezultatul aplicării interogării standard asupra bazei de date.
Modul în care se face trecerea textului de analizat într-o structură care să permită eliminarea redundanței informației din text se poate observa în codul sursă de mai jos:
try {
BufferedReader fiS = new BufferedReader(new FileReader( m_dirName + m_fileSeparator + m_fileName ));
String s = new String("");
while ((s = fiS.readLine()) != null)
{StringTokenizer st = new StringTokenizer(s," ,.?!:;-()[]{}");
while(st.hasMoreTokens())
{ind1.addElement(st.nextToken());
}
}
fiS.close();
}
catch(IOException e)
{System.out.println("Eroare:"+e.getMessage());},
unde ind1 este o instanță a clasei java.lang.Vector(). Se observă trecerea textului, prin aplicarea unei împărțiri în unități lexicale, într-o structură dinamică care poate fi prelucrată ușor în vederea eliminării redundanței informației. Astfel, această idee este surprinsă în următoarea secvență de cod:
ind2.addElement(ind1.elementAt(0));
for (int i=1;i<ind1.size();i++)
{if(ind2.indexOf(ind1.elementAt(i))!=-1){}
else ind2.addElement(ind1.elementAt(i)); }
După eliminarea redundanței informației această nouă structură dinamică de date care nu este altceva decât o nouă instanță a clasei java.lang.Vector() poate fi folosită cu succes în procesul de analiză morfologică a textului introdus de utilizator. În acest moment derularea execuției programului este asemănătoare cu modul în care se extrage informația utilă, mod prezentat în paragrafele precedente.
Un exemplu de model de analiză morfologică pe un text se poate observa în figura următoare. Analiza se rezumă la extragerea substantivelor din text și afișarea lor în fereastra de dialog împreună cu numărul de apariții din text și modul de regăsire în textul analizat.
În loc de concluzie…
Prezentul proiect s-a dorit a fi un mod de evaluare a posibilităților care sunt în momentul actual la dispoziția producătorilor de programe în ceea ce privește modalitățile de proiectare și realizare a unei aplicații integrate de analiză de corpora în limba română.
Faptul că prezentul proiect nu rezolvă multe din problemele care apar în momentul în care se dorește o analiză fiabilă din punct de vedere lexical și sintactic dovedește lipsa sau capacitatea redusă de versatilitate a materialului deja existent în acest domeniu, dar care este orientat exclusiv spre realizarea unor proiecte de anvergură în acest domeniu doar pentru limba engleză, în special.
Nu se poate spune că în momentul actual nu există o bază solidă de dezvoltare a unor aplicații profesionale de analiză lexicală sau sintactică. Acest lucru s-a putut vedea și din materialul de documentare referitor la modalitățile de realizare a unor aplicații care au, însă, ca obiect de studiu, gramatica limbii engleze, existând în acest sens o pleiadă de formate electronice care să permită dezvoltarea de tehnologii noi în domeniul analizei corpusului lingvistic englez.
Problema majoră cu care se confruntă acest proiect este lipsa de material logistic pentru dezvoltarea de aplicații similare și în limba română.
Pe lângă aceasta, alte probleme care își au rădăcina în lipsa logisticii pentru o analiză eficientă a corporei de limbă română, scrisă și vorbită, și care au rămas la nivel de apreciere teoretică sunt următoarele:
imposibilitatea de face localul românesc din internaționalizarea aplicației să poată fi recunoscut integral (singurul caracter care este scris și recunoscut în acțiunile de extragere a informației din baza de date fiind “î”);
vizualizarea dependențelor de context pentru analiza morfologică a frazei prin stabilirea exactă, în funcție de context, a tipului de parte de vorbire pe care cuvântul respectiv îl ia în textul analizat.
În ceea ce privește ultimul aspect, s-a încercat surprinderea faptului că analiza efectuată nu depinde în mare măsură de context prin atenționarea utilizatorului de posibilitatea, ca în momentul în care efectuează analiza, pot exista situații în care un cuvânt poate avea mai multe tipuri de părți de vorbire în interiorul aceluiași text.
Se poate spune, în final, că analizatorul de text prezentat pe larg în capitolele anterioare, în contextul unei aplicații mai ample destinată studiului sistematic al corporei de limbă română, este o încercare și un mod de abordare “contextual” referitor la capabilitățile pe care aplicații de anvergură destinate, în principal, pentru limba engleză pot fi folosite ca model în realizarea acestui proiect. Lipsa de flexibilitate a acestor proiecte implementate pentru limba engleză în ceea ce privește aplicabilitatea pentru corpore în alte limbi, altele decât engleză, a dus la modul de abordare a problemelor similare pentru corpora de limba română prezentate în această lucrare.
Bibliografie
1. Communications of the ACM
Natural Language Processing;
Information Extraction;
AONE, C., BLEJER, H., FLANK, S., McKEE, D., SHINN, S., The MURASACHI Project: Multilingual Natural Language Understanding in “PROCEEDINGS OF THE DARPA SPOKEN AND WRITTEN LANGUAGE WORKSHOP”, 1996.
DeJONG, G. F., An overview of the FRUMP system in “STRATEGIES FOR NATURAL LANGUAGE PROCESSING”. W.G. LEHNERT and M.H. RINGLE, eds. ERLBAUM, HILLSDALE, N.J., 1982, pag. 149 – 176.
DELANNOY, J. F., FENG., C., MATWIN, S., and, SZPAKOWICZ, S., “Knowledge Extraction from Text: Machine Learning for Text-to-Rule Translation” in “PROCEEDINGS OF WORKSHOP ON MACHINE LEARNING TECHNIQUES AND TEXT ANALYSIS”, ECML(Vienna), 1993.
Simona COSTINESCU, Irina ATHANASIU, “Analiza sintactică cu JavaCC”, PC Report, aprilie 1998, NET REPORT, septembrie 2001.
BERG, Clifford, J., “Java Database Connectivity” in “ADVANCED Java 2 – Development for Enterprise Applications”, 2nd EDITION, Prentice Hall, 1998 – 2000, pag. 310 – 348.
Resurse internet:
– www.antlr.org;
– www.cs.princeton.edu/~appel/modern/java/CUP/index.html;
– www. .cs.princeton.edu/~appel/modern/java/JLex/index.html;
– www.cogsci.princeton.edu/~wn/;
Copyright Notice
© Licențiada.org respectă drepturile de proprietate intelectuală și așteaptă ca toți utilizatorii să facă același lucru. Dacă consideri că un conținut de pe site încalcă drepturile tale de autor, te rugăm să trimiți o notificare DMCA.
Acest articol: Produs Program Pentru Laboratorul de Lingvistica (ID: 149148)
Dacă considerați că acest conținut vă încalcă drepturile de autor, vă rugăm să depuneți o cerere pe pagina noastră Copyright Takedown.