» » » » » » Extragerea informatizată a cunoașterii din surse structurate și nestructurate

Extragerea informatizată a cunoașterii din surse structurate și nestructurate

postat în: Cunoaşterea | 0

Extragerea cunoașterii

Extragerea cunoașterii constă în stabilirea de cunoștințe din surse structurate (baze de date relaționale, XML) și nestructurate (text, documente, imagini). Cunoașterea care rezultă și trebuie să fie într-un format care poate fi citit și interpretat de mașină și trebuie să reprezinte cunoașterea într-un mod care să faciliteze inferența. Deși este dpdv metodic similară cu extragerea informației (procesarea limbajului natural, NLP) și depozitul de date (extracție, transformare, încărcare, ETL), principalul criteriu este că rezultatul extracției merge dincolo de stabilirea unor informații structurate sau transformarea într-o schemă relațională. Impune fie reutilizarea cunoștințelor existente formale (reutilizarea de identificatori sau ontologii) fie generarea unui sistem bazat pe datele sursă.

Grupul W3C RDB2RDF standardizează în prezent un limbaj pentru extragerea RDF din bazele de date relaționale. Un alt exemplu popular pentru extragerea cunoașterii este transformarea Wikipedia în date structurate și de asemenea maparea la cunoștințele existente (a se vedea DBpedia și Freebase).

Privire de ansamblu

După standardizarea limbajelor de reprezentare a cunoașterii precum RDF și OWL, au fost efectuate multe cercetări în domeniu, în special în ceea ce privește transformarea bazelor de date relaționale în RDF, rezoluția identității, descoperirea de cunoștințe și învățarea ontologiei. Procesul general utilizează metode tradiționale de extragere a informației și extragere, transformare și încărcare (ETL), care transformă datele din surse în formate structurate.

Următoarele criterii pot fi utilizate pentru a clasifica abordările în acest domeniu (unele dintre ele contează doar pentru extragerea din bazele de date relaționale):

  • Sursă – Ce surse de date sunt acoperite: Text, Baze de date relaționale, XML, CSV
  • Expunere – Cum este făcută explicit extragerea cunoașterii (fișier ontologie, baze de date semantice)? Cum se poate interoga?
  • Sincronizarea – Este procesul de extragere a cunoașterii executat doar pentru a produce o stocare sau rezultatul este sincronizat cu sursa? Static sau dinamic. Sunt schimbările în rezultat scrise înapoi (bi-direcționale)
  • Refolosirea vocabularelor – Acest instrument poate refolosi vocabularele existente în extracție. De exemplu, coloana de tabel „firstName” poate fi mapată la foaf: firstName. Unele abordări automate nu sunt capabile să mapeze vocabulare.
  • Automatizarea – Gradul în care extracția este asistată/automatizată. Manual, GUI, semi-automată, automată.
  • Necesită o ontologie de domeniu – Este necesară o ontologie pre-existentă pentru a mapa. Deci sau este creată o mapare sau este învățat o schemă de la sursă (învățarea ontologică).

Exemple

Legarea entităților

1. DBpedia Spotlight, OpenCalais, Dandelion dataTXT, Zemanta API, Extractiv și PoolParty Extractor analizează un text liber prin recunoașterea entității numite și apoi elimină ambiguitatea candidaților prin rezoluția numelui și leagă entitățile găsite la baza de cunoaștere DBpedia (Dandelion dataTXT demo sau DBpedia Spotlight demo web sau PoolParty Extractor Demo).

Președintele Obama a apelat miercuri la Congres pentru a extinde o scutire de impozit pentru studenții inclusă în pachetul de stimulare economică de anul trecut, susținând că această politică oferă o asistență mai generoasă.

În calitate de președinte Obama este legat de o resursă LinkedData DBpedia, alte informații de top pot fi preluate automat și un sistem de raționament semantic poate, de exemplu, deduce că entitatea menționată este de tipul Person (folosind software FOAF) și de tipul Presidents of the United States ( folosind YAGO). Contraexemplu: Metode care recunosc numai entități sau leagă de articole și alte resurse care nu oferă în continuare extragerea datelor structurate și a cunoașterii formale.

Baze de date relaționale RDF

1. Triplify, D2R Server, Ultrawrap și Virtuoso RDF Views sunt instrumente care transformă bazele de date relaționale RDF. În timpul acestui proces ele permit reutilizarea vocabularelor existente și a ontologiilor în timpul procesului de conversie. La transformarea unui tabel relațional tipic numit utilizatori, o coloană (de ex., nume) sau o agregare de coloane (de ex., nume_familie și prenume) trebuie să furnizeze URI-ul entității create. În mod normal, se utilizează cheia primară. Fiecare altă coloană poate fi extrasă ca o relație cu această entitate. Apoi sunt folosite proprietăți cu semantici definite formal (și refolosite) pentru a interpreta informațiile oferite. De exemplu, o coloană într-un tabel de utilizatori numit căsătoritCu poate fi definită ca o relație simetrică și o coloană pagina_acasă poate fi transformată într-o proprietate din Vocabularul FOAF numită foaf:homepage, astfel calificându-se drept o proprietate funcțională inversă. Apoi, fiecare intrare a tabelei utilizator poate fi făcută o instanță a clasei foaf:Person (Populație ontologică). În plus, cunoașterea de domeniu (sub forma unei ontologii) ar putea fi creată din status_id, fie prin norme create manual (dacă status_id este 2, intrarea aparține clasei Profesor) sau prin metode (semi)automate (învățarea ontologică). Iată un exemplu de transformare:

Name marriedTo homepage status_id
Peter Mary http://example.org/Peters_page 1
Claus Eva http://example.org/Claus_page 2

 :marriedTo a owl:SymmetricProperty .
:Peter foaf:homepage  <http://example.org/Peters_page> .
:Peter a foaf:Person .
:Peter a :Student .
:Claus a :Teacher .

Extragerea din surse structurate în RDF

1:1 Maparea din tabele/vizionări RDB în entități/atribute/valori RDF

Atunci când construim o reprezentare RDB a unui domeniu problemă, punctul de plecare este în mod frecvent o diagramă entitate-relație (ERD). În mod tipic, fiecare entitate este reprezentată ca un tabel tip bază de date, fiecare atribut al entității devine o coloană în acel tabel, iar relațiile dintre entități sunt indicate de chei externe. Fiecare tabel definește în mod obișnuit o clasă particulară a entității, fiecare coloană una dintre atributele sale. Fiecare rând din tabel descrie o instanță a entității, unic identificată printr-o cheie primară. Rândurile din tabel descriu în mod colectiv un set de entitate. Într-o reprezentare echivalentă RDF a setului aceleiași entități:

  • Fiecare coloană din tabel este un atribut (adică, predicat)
  • Fiecare valoare a coloanei este o valoare a atributului (adică, obiect)
  • Fiecare cheie de rând reprezintă un ID al entității (adică, subiect)
  • Fiecare rând reprezintă o instanță a entității
  • Fiecare rând (instanță a entității) este reprezentat în RDF de o colecție de triplete cu un subiect comun (ID-ul entității).

Deci, pentru a crea o viziune echivalentă bazată pe semantici RDF, algoritmul de mapare de bază ar fi după cum urmează:

  1. crearea unei clase RDFS pentru fiecare tabel
  2. convertirea tuturor cheilor primare și externe în RII
  3. atribuirea un predicat IRI fiecărei coloane
  4. atribuiea unui predicat de tip rdf pentru fiecare rând, legându-l de o clasă IRI RDFS corespunzătoare tabelului
  5. pentru fiecare coloană care nu este nicio parte a unei chei primare sau externe, se construiește un triplu conținând cheia primară IRI ca subiect, coloana IRI ca predicat și valoarea coloanei ca obiect.

Există o menționare timpurie a acestei mapări bază sau directe în comparația modelului ER cu modelul RDF de către Tim Berners-Lee.

Mapări complexe ale bazelor de date relaționale RDF

Maparea 1:1 menționată mai sus expune datele moștenite ca RDF într-un mod simplu, rafinări suplimentare putând fi folosite pentru a îmbunătăți utilitatea la ieșire a lui RDF respectiv de cazurile de utilizare date. În mod normal informația este pierdută în timpul transformării unei diagrame entitate-relație (ERD) în tabele relaționale (detalii pot fi găsite în nepotrivirea de impedanță obiect-relatională) și trebuie să permită ingineria inversă. Din punct de vedere conceptual, abordările de extracție pot veni din două direcții. Prima direcție încearcă să extragă sau să învețe o schemă OWL sintr-o schemă dată a bazei de date. Abordări timpurii au folosit o sumă fixă de reguli de mapare create manual pentru a rafina maparea 1:1. Metode mai elaborate folosesc euristica sau învățarea algoritmilor pentru a induce informații schematice (metode suprapuse cu învățarea ontologică). În timp ce unele abordări încearcă să extragă informația din structura inerentă în schema SQL (analizând de ex. chei externe), altele analizează conținutul și valorile din tabele pentru a crea ierarhii conceptuale (de exemplu, oloane cu puține valori sunt candidate la a deveni categorii). Cea de a doua direcție încearcă să mapeze schema și conținutul acesteia într-un domeniu de ontologii pre-existente. De multe ori, totuși, o ontologie de domeniu adecvată nu există și trebuie creată mai întâi.

XML

XML este structurat ca un arbore, orice dată poate fi cu ușurință reprezentată în RDF, care este structurat ca un grafic. XML2RDF este un exemplu de abordare care folosește noduri goale RDF și transformă elementele și atributele XML în proprietăți RDF. Totuși subiectul este mai complex, la fel ca în cazul bazelor de date relaționale. Într-un tabel relațional cheia primară este un candidat ideal pentru a deveni subiect al tripletelor extrase. Un element XML, totuși, poate fi transformat – în funcție de context – ca subiect, predicat sau obiect al unui triplet. XSLT pot fi utilizat într-un limbaj standard de transformare pentru a converti manual XML în RDF.

Metode/Instrumente

Nume Sursa de date Expunere de date Sincronizarea datelor Limbaj mapare Reutilizare vocabular Automatizare mapare Obligativitatea ontologiei domeniului Folosește GUI
O mapare directă a datelor relaționale în RDF Date relaționale SPARQL/ETL dinamic NU fals automatic fals fals
CSV2RDF4LOD CSV ETL static RDF adevărat manual fals fals
Convert2RDF Fișier text delimitat ETL static RDF/DAML adevărat manual fals adevărat
D2R Server RDB SPARQL bi-direcțional D2R Map adevărat manual fals fals
DartGrid RDB own query language dinamic Visual Tool adevărat manual fals adevărat
DataMaster RDB ETL static proprietar adevărat manual adevărat adevărat
Google Refine’s RDF Extension CSV, XML ETL static niciunul semi-automatic fals adevărat
Krextor XML ETL static xslt adevărat manual adevărat fals
MAPONTO RDB ETL static proprietar adevărat manual adevărat fals
METAmorphoses RDB ETL static xml proprietar bazat pe limbaj mapare adevărat manual fals adevărat
MappingMaster CSV ETL static MappingMaster adevărat GUI fals adevărat
ODEMapster RDB ETL static proprietar adevărat manual adevărat adevărat
OntoWiki CSV Importer Plug-in – DataCube & Tabular CSV ETL static The RDF Data Cube Vocaublary adevărat semi-automatic fals adevărat
Poolparty Extraktor (PPX) XML, Text LinkedData dinamic RDF (SKOS) adevărat semi-automatic adevărat fals
RDBToOnto RDB ETL static niciunul fals automatic, utilizatorul are în continuare posibilitatea de rafinare a rezultatelor fals adevărat
RDF 123 CSV ETL static fals fals manual fals adevărat
RDOTE RDB ETL static SQL adevărat manual adevărat adevărat
Relational.OWL RDB ETL static niciunul fals automatic fals fals
T2LD CSV ETL static fals fals automatic fals fals
RDF Data Cube Vocabulary Date statistice multidimensionale în foi de calcul Data Cube Vocabulary adevărat manual fals
TopBraid Composer CSV ETL static SKOS fals semi-automatic fals adevărat
Triplify RDB LinkedData dinamic SQL adevărat manual fals fals
Ultrawrap RDB SPARQL/ETL dinamic R2RML adevărat semi-automatic fals adevărat
Virtuoso RDF Views RDB SPARQL dinamic Limbaj scheme meta adevărat semi-automatic fals adevărat
Virtuoso Sponger Surse de date structurate și semi-structurate SPARQL dinamic Virtuoso PL & XSLT adevărat semi-automatic fals fals
VisAVis RDB RDQL dinamic SQL adevărat manual adevărat adevărat
XLWrap: Foaie de calcul în RDF CSV ETL static TriG Syntax adevărat manual fals fals
XML în RDF XML ETL static fals fals automatic fals fals

Traducere din Wikipedia

Lasă un răspuns

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *