Linked Open Data a Entity Linking

[bodnarIQ]

Pre sprístupnenie dát z K+ ako Linked Open Data je potrebné implementovať Entity Linking - proces prepojenia rozpoznaných entít z textu na nejakú externú databázu(napr. wikidata). Toto má niekoľko výziev:

• variabilné pomenovania rovnakých entít - jedna a tá istá logická entita môže byť reprezentovaná rôznymi textovými pomenovaniami, napr. New York, NY, Big Apple, prípadne preklepy v textoch (New Yokr)
• nejednoznačnosť - rovnaký textový reťazec môže reprezentovať rôzne entity v závislosti od kontextu, napr. Paris = Paris Hilton alebo Pariz vo Fr?
• entita sa nemusí v konkrétnej externej db nachádzať, môže však neskôr pribudnúť, čo môže byť problém detekovať bez nutnosti opätovného spustenia algoritmu
• algoritmus musí byť dostatočne rýchly a škálovateľný, čo pri veľkých databázach ako je wikidata môže byť problém
  Podarilo sa mi nájsť zopár existujúcich riešení, žiadne však nepodporujú český model.
  DBPedia Spotlight - vlastny NER, nepodporuje cz
  MAG - vlastný NER, možnosť určiť klientom rozpoznané entity v inpute, nepodporuje cz

Entity Linking je nevyhnutný pre previazanie rozpoznaných entít s externými databázami a vystavenia dát ako Linked Open Data. Vyvinúť takýto nástroj v rámci projektu DL4DH nebude podľa mňa zrealizovateľné, a existujúci nástroj, ktorý by podporoval český jazyk som nenašiel. Viete o nejakom? Bez takéhoto nástroja nebude možné sprístupniť dáta ako LOD a prepojiť s externými DB

[motyc]

K výše napsanému - nemyslím, že napojení na externích databázi je podmínka toho, abychom poskytovali K+ jako LOD. Podmínkou je, aby byla data reprezentována jako trojice, aby každá entita měla svou pURL, aby existovala dokumentace užité ontologie a aby existoval SPARQL endpoint. Jestli si to pak někdo bude chtít napojit na Wikidata nebo na cokoli jiného je už věc uživatele, nikoli našich nástrojů.

Tím samozřejmě neříkám, že by napojení na externí databázi nemohlo být v některých případech užitečné.

[bodnarIQ]

Problémy popísané vyššie ale stále ostávajú, aj bez napojenia na externú databázu. Ide o to, že musíme tieto entity, reprezentujúce jednotlivé autority, vytvoriť my z miliónov naskenovaných textov. NameTag nám síce pomôže rozlíšiť, či ide o Paris - osobu alebo Paris - mesto, no nedokážeme rozhodnúť, že ide o entitu tú istú. Nedokážeme spracovať semantický význam rozpoznanej entity. Jeden text môže hovoriť o Prahe na Slovensku, zatiaľ čo iný text bude spomínať Prahu českú, a my by sme to spojili a pracovali s tým ako s jednou entitou, pretože by sme nemali ako rozhodnúť, o ktorú prahu sa jedná. Takisto pri synonymách (New York, NY, ...) by pre každé pomenovanie vznikla samostatná entita.

Mala by takáto databáza význam bez prepojenia na externé DB? Keby sa nám podarilo takúto DB postaviť, k čomu by sa užívateľ mal vedieť dostať po získani PUID rozoznanej entity? Keďže nevedieme žiadne informácie o rozpoznanej entite(tým myslím informácie ako má napríklad WikiData o každej rozpoznanej entite, keďže budeme viesť databázu s publikáciami), jediné, čo ma momentálne napadá, je vzťah Entita - vyskytuje sa v - dielo, čo by malo rovnaký efekt ako fultextové vyhľadávanie entity.

[motyc]

Ono ve skutečnosti záleží ale na tom, jak si nadefinujeme naší ontologii. Pokud se rozhodneme, že nebudeme řešit skutečné významy entit ale pouze jejich formální lematizované znění, pak problém nevznikne. Je to tedy více teoretická než technická otázka. Stejně tak je arbitrární, na jakém základě vytvoříme vazby mezi entitami a hlavně mezi jakými. Nevím, zda k tomuto v lingvistice a strojovém zpracování textu existují nějaké standardy, nebo zda je nějaké řešení využité v jiných projektech. Pokud nikoli, budeme muset sami navrhnout řešení, které bude vhodné pro náš případ.

V podstatě je řešením je i vytvořit síť ze všech jednotlivých slov, vytvořit mezi nimi vazby a tyto propojit na základě příslušnosti k odstavci/stránce, tyto zase k celé publikaci atd. Rozpoznané entity pak mohou být chápány pouze jako speciální typ slova = řekneme "toto slovo je podle nás geografické jméno".

To co popisujete, je ideální řešení, ke kterému ale asi nedospějeme. Navíc výhodou LOD je právě to, že struktura jde doplnit a obohatit o přesnější určení kdykoli v budoucnu, třeba s lepšími nástroji. Zatím jde o to data poskytnout přes SPARQL, aby byla jako LOD vůbec k použití, protože nějaké rest API či OAI-PMH může být na řadu operací nepraktické.

[bodnarIQ]

Ak je našim hlavným cieľom vystaviť SPARQL endpoint, tak predpokladám, že nemá zmysel diskutovať o použití tripplestore databázy vs grafovej databázy?
Rozdiel pekne popísaný tu

[motyc]

Zde už neumím reagovat, asi bych to případně nechal k projednání na schůzku, kde si to můžeme vysvětlit (diskusi v odkazu si pročtu).

[motyc]

Po přečtení už rozumím, kam míříte. Já vždy oba pojmy trošku zaměňoval a triplestore chápal jen jako druh grafové databáze. Což asi platí. Potřebujeme však triplestore, protože naším cílem je uládat "primitivní" hodnoty, tj. jednotlivá slova a k nim pomocí property linkovat jiné primitivní hodnoty, jako třeba určení slovního druhu, typ entity nebo konkrétní místo užití.

[JanMeritus]

@bodnarIQ @motyc myslim ze issue se posunulo od konkretni implementace LOD do obecnejsi roviny diskuse o bazi, indexu a endpointu ktere se neustale vraci uz od zacatku projektu, zalozil som pro tuto obecnejsi rovinu nove issue #14

[bodnarIQ]

Tu by som ešte dodal, že pokiaľ je našim cieľom ukladať "primitívne" hodnoty, nedokázali by sme celý obsah K+ uložiť iba pomocou primitývnych hodnôt a vzťahov medzi nimi (t.j. použitím triplestore). Už ked ide iba napr. o rozoznanie lemmy - aby sme mohli spojiť lemmatizovaný tvar s konkrétnym slovom v texte, každé slovo v texte by muselo byť uložené ako samostatný uzol v tripplestore. To by znamenalo, že rovnaké slová by boli pod jedným uzlom, a v tom momente by sme stratili kontext.

Ak by sme chceli ulozit slovo 'stromu' a naviazať ho raz na pád GENITIV a raz na DATIV, boli by to dve trojice:
stromu - maPad - GENITIV a stromu - maPad - DATIV

• ulozeny vztah, ze sa slovo vztahuje k danej stranke publikacie
  pid:123 - obsahujeSlovo - stromu a pid124 - obsahujeSlovo - stromu

a akonahle by sme chceli spatne ziskat metadata pre jednu stranku publikacie, nevedeli by sme urcit, ktory vztah plati pre nasu publikaciu(pid:123 - obsahujeSlovo - stromu a stromu - maPad - X, tak X by malo viacero hodnot)

Preto si myslim, ze by sme mali ako primarnu databazu pouzit inu ako tripleStore, s moznostou vystavit tripleStore v buducnosti ako sekundarnu DB sluziacu na vystavenie dat ako LOD, kde by sa medzi trojice neukladalo vsetko, iba niektore vztahy, napr. stranka - namedEntity

[motyc]

Ano, navržené řešení mi přijde po Vaší analýze jako racionální řešení. Je rozhodně pravda, že ne všechny vztahy podstatné pro K+/Feeder musíme vystavovat jako LOD.

[JanMeritus]

taky za mne 👍 TS jako doplnkova baze je idealni reseni, zjednodusujici mnozstvi problemu a umoznujuci potencialni rust dle potreb

[stranak]

Jen stručný komentář k tomu Named Entity Linkingu (NEL): souhlasím s rozdělením od problému LOD, i když to souvisí.

linking:

• je složitý vědecký problém a nemá smysl, abychom to zkoušeli řešit zde
• zároveň ale můžeme počítat s tím, že třeba za rok až dva externí nástroj na NEL mít budeme
  • plánujeme o NEL rozšířit NameTag, který v současnosti dělá jen NER. I kdyby to nevyšlo, jsou na to jiné nástroje (i když třeba ne natrénované na češtinu)
• až linking bude, tak to bude součást rozeznané entity a bude to odkaz do databáze.
  • např. pro geo entity tam tedy nebudou koordináty aj. atributy, ale jen ten odkaz do nějaké báze typu wikidata.

Čili by ideálně systém s budoucím linkingem počítat měl, i když v prvotní implementaci nebude. Ovšem samozřejmě, že i když linking bude, určitě nebude dobře fungovat všude.

[bukovskyIQ]

Vyřešeno, prozatím zavírám tento issue.