TICCL-unk: vraag naar werking opschoning samengevoegde ngram-lijst

[martinreynaert]

Wellicht een bug: TICCL-unk lijkt niet alle componenten van bi- and trigrammen volledig op te schonen.

In file: (unk-file = reynaert@red:/reddata/TICCLAT/UNK/TESTacro1950NGRAMS.5.punct)
'voor_een_kW"atóërtje?öpgehaald'^^^ voor_een_kW"atóërtje?öpgehaald'^^^
'voor_de_, voor_de_,

Zelfs bij unigrammen:
(taxatie_66) taxatie_66)
(taxatie_66), taxatie_66),

Voor je dit fixt, volgende vraag:

Ik voer TICCL-unk momenteel een samengevoegde frequentielijst van uni-, bi- en trigrammen. Worden die als aparte items geevalueerd en opgeschoond? Of doe je eerst de unigrammen en editeer je dan met het resultaat daarvan de bi- en trigrammen? (In laatste geval zouden de drie lijsten zoals geleverd door FoLiA- of TICCL-stats door TICCL-unk apart ingelezen en samengevoegd kunnen worden).

Ter overweging aanverwant punt: heeft het zin in de lijst *unk de niet weerhouden bi- en trigrammen op te nemen?

Dit zijn misschien al weer 3 issues door elkaar...

[kosloot]

1. Dat die komma er achter staat is een bug. Beetje raar, maar zal een gevolg zijn van recente edits
2. ik bekijk gewoon elk 'woord' uit de .tsv file en als dat een meer-gram is, splits ik het en bekijk de delen.
   editen beperkt zich tot puncts verwijderen en eventueel naar de punt file schrijven (wat dus beetje mis gaat)
3. verder classificeert TICC-unk elk onderdeel van de n-gram apart en 'berekent' een overal classificatie.

[martinreynaert]

Punt 1: ok, is dus een nieuwe bug. Dat geldt echter niet denk ik voor de ')' en '^' gevallen. Die moeten ook opgelost worden

Punt 2. Als je elk 'woord', dus elke string herbekijkt, dan bekijk je de unigramstrings op zijn minst 6 keer (1 unigram, 2 bigrammen en 3 trigrammen. 'Op zijn minst' is dan voor hapaxen. Is het niet veel efficienter elk unigram 1 keer te evalueren, bij te houden wat de conclusie is (clean of punct of unk) en die conclusie dan bij editen van de bi- en trigrammen (= search en evt. replace op basis van de lijst verzameld voor de unigrammen) die conclusie door te trekken naar het ngram?

Als een string een unk is, hebben we verder in het verhaal ook niet veel aan bigrammen en trigrammen met die string in. Het zelfde geldt voor ngrammen met getallen, bv.

Punt 3. Dit lijkt hier en daar scheef te gaan. Voor acroniemen in het bijzonder, zover ik tot nu toe zie:

reynaert@red:/reddata/TICCLAT/UNK$ grep 'H.S.C' TESTacro1950NGRAMS.5.acro |wc
3 6 29
reynaert@red:/reddata/TICCLAT/UNK$ grep 'H.S.C' TESTacro1950NGRAMS.5.unk |wc
1472 2944 29264
reynaert@red:/reddata/TICCLAT/UNK$ grep 'H.S.C' TESTacro1950NGRAMS.5.unk |head
H.S.C, 117
H.S.C., 23
tegen_H.S.C, 20
van_H.S.C, 14
H.S.C._— 13
H.S.C,_en 11
—_H.S.C. 10
tegen_H.S.C. 9
van_H.S.C. 9
6_H.S.C. 8

Dit zijn wat mij betreft helemaal geen unk-gevallen.

Hetzelfde gebeurt ook met andere acroniemen. Graag dit eerst bekijken a.u.b!

[kosloot]

Ok, ik heb die komma's even uitgezocht. 't is weer moeilijker dan gedacht :)

Eerst: taxatie_66)
taxatie is een CLEAN word. Geen probleem.
66) wordt zonder punctuatie 66 en dat is een getal ==> IGNORE status
daarna wordt het hele woord overgenomen. dat lijkt me idd een bug.

Dan 'voor_de_,
de , is het derde deel van een 3-gram. Weglaten lijkt me hier niet goed,
maar opnemen als PUNCT ook niet. Een ander bug dus.

Tot slot: 'voor_een_kW"atóërtje?öpgehaald'^^^
voor en een zijn CLEAN
kW"atóërtje?öpgehaald'^^^ is bijzonder: 19 letters zitten in het alfabet, 6 niet.
De verhouding letters/woordlengte is 19/25 ofwel 0.76 en dat is net genoeg voor de kwalificatie CLEAN! (die eist een verhouding > 0.75)
Daarnaast (en dat is de echte crux) tellen ^^^ symbolen NIET als punctuatie. Dus blijft dat deel onveranderd.
Het hele 3-gram is dus alleen een PUNCT voor het eerste ' voor 'voor dus de uitvoer is correct volgens de huidige regels.
Conclusie:
2 bugs, die ik ga fixen
1 vraag: meer symbolen als punctuatie beschouwen?

[martinreynaert]

Dank voor het opzoeken en de toelichting!!

De IGNORE status voor bv. 66 mag er niet in resulteren dat de bi- en trigrammen wel overgenomen worden. Moet erin resulteren eerder dat ook die niet in clean opgenomen worden, dus verder ook gewoon 'ignored' worden.

1 enkel extern punctuatieteken als onderdeel van een ngram heeft bitter weinig waarde toe te voegen voor gelijkaardige strings. Deze ngrammen moeten ook ignored worden.

Er moeten inderdaad dan meer tekens als 'punctuatie' behandeld worden. Zeker '^'. er kunnen er best nog meer zijn.

Dus: kW"atóërtje?öpgehaald'^^^ moet in punct opgenomen worden als: kW"atóërtje?öpgehaald

Aan de andere kant zie ik dat gesplitte samenstellingen met een koppelteken van dat koppelteken ontdaan worden, dat mag juist niet gebeuren. Dit kunnen bigrammen, bv. 'ge-_ split' of 'ge_-split' of ook trigrammen zijn: 'ge_-_split'.

't Is verduiveld complex!

[kosloot]

Ok, ik denk dat we een duidelijkere beslisboom nodig hebben.
NB: even er van uitgaande

• dat we correct weten wat punctuatie is en wat niet.
• van de huidige situatie: n-grammen splitsen en per deel bekijken.
  een cache met de resultaten per unigram kan een idee zijn. Maar dat kan later.

Voor unigram is het simpel:
Als CLEAN: sla op in .clean
Als PUNCT: sla op in .punct
Als IGNORE: vergeet
Als UNK: sla op in .unk

Voor n-grammen is het nu niet helemaal goed uitgewerkt, en warrig.
Misschien het beste met wat voorbeelden vragen:
Invoer:

V.S.	3
K.N.I.L.	4
(taxatie_66),	1
(taxatie_66)	1
'voor_een_kW"atóërtje?öpgehaald'^^^	1
'voor_de_,	1
ge-_split	1
ge_-_split	1
!$#a!%@@Q&@	1
goed_!$#!%@@&@	1

op dit moment (kleine bugs gefixt...) is
de unk file:

!$#!a%@@Q&@	1

de clean file:

K.N.I.L.	4
V.S	3
ge-_split	1
voor_een_kW"atóërtje?öpgehaald	1

en de punct file:

'voor_een_kW"atóërtje?öpgehaald'^^^	voor_een_kW"atóërtje?öpgehaald
V.S.	V.S

Dit lijkt me niet 'optimaal', maar wat wil je er wel uitkrijgen?
moet ge_-_split ook in de clean file? etc.
Bijv: wat als een UNK deel is van een verder clean woord, etc.
Dit is allemaal niet heel triviaal .

[kosloot]

My suggestion is, that we create a small gold standard .tsv file with several 'hard' cases together with the desired .unk, .clean, .punct and .acro files.
This allows me to make code that handles all cases correctly, and can be tested automatically.
The standard should include all kinds of punctuation, 1-, 2- and 3-grams (4-grams too?) and weird characters. Of course also some neat and clean words.

Whenever a new unexpected case pops up, we can add it to the standard. (at first this will happen quite often, but at the end we should cover all)
The above examples might be a start.

[martinreynaert]

OK, good suugestion! I will work on that.

Verder heb ik geprobeerd een en ander op een rijtje te krijgen:

Vroege processing in TICCL-unk:

• Alles wat lijkt op een hyphen of '-' wordt een regulier toetsenbord hyphen of '-'.
• Een hyphen wordt nooit weggeveegd.
• Apostrofe of "'" wordt weggeveegd indien voor- of achteraan. Dit geldt eigenlijk voor alle quotes.

Gaan (niet) naar CLEAN:

• Geen bigrammen met samen (dus spatie inbegrepen) minder dan 6 karakters (dus niet: 'de_el', maar wel 'de_zee').

• Geen trigrammen met samen minder dan 8 karakters

• Geen bigrammen met een 'woord' bestaande uit 1 enkel punctuatiekarakter (of ander niet-alfanumeriek symbool).

• Geen trigrammen met 1 enkel punctuatiekarakter (of ander niet-alfanumeriek symbool) als 'woord' ergens, anders dan een hyphen in het midden. (I.e. Niet: ',in_deze'. Niet: 'was_de-'. Wel: 'de_-_zelfde'.

• Volledig cleane ngrammen gaan naar 'clean'.

• De gecleande versie van 'punct' gaat naar 'clean'.

• Ignore gaat nergens heen. Bij extensie gaan ngrammen met een of meer ignore nergens heen.

• UNK gaat naar 'unk'. Hogere ngrammen met een of meer UNKs gaan nergens heen.

De acroniemen

De lijst acroniemen die momenteel gegenereerd wordt bevat een grote hoeveelheid varianten van acroniemen. In de KBkranten van 1950 zien we dat de meest voorkomende vorm dominant de volledig gepunctueerde vorm is, bv. 'A.C.R.O.'. We zijn uitgegaan van de niet gepunctuurde vorm, e.g. 'ACRO'. Ik denk dat voor de gebruiker en voor de andere werking wat betreft punten '.' in diverse indexeersystemen (functioneren als single character wildcard in Delpher, bijvoorbeeld. Blijken niet goed opzoekbaar in b.v. OpenSoNaR+) raadzaam is te normaliseren naar de niet-gepunctueerde vorm.

Momenteel vatten we niet alle varianten. Indien de gepunctueerde vorm zonder eindpunt gebruikt wordt in een regex en daarbij toegelaten wordt dat of geen punt, dan wel twee punten of 1 ander karakter mogelijk is, dan vatten we uit de input frequentielijst wellicht nagenoeg alle varianten. De 'tussenliggende' karakters kunnen daarbij ook door de OCR gecreeerde alfanumerieke karakters zijn.

Zodra we deze vollediger lijst acroniemen kunnen genereren, lijkt het me aangewezen meteen te zorgen dat alleen de genormaliseerde varianten en hun aangepaste bi-/trigrammen naar 'clean' gaan. De paren 'variant - cleane acroniemversie' kunnen meteen als lijst 'correcties' (a la 'rank' qua format) opgeslagen worden. Ik laat open of dit in TICCL-unk gebeurt of als tussenliggende stap tussen TICCL-unk en TICCL-anahash.

Verder gelden voor acroniemen-ngrammen dezelfde regels als hierboven wat betreft clean/ignore of unk.

[Wordt vervolgd / verder aangevuld]

[kosloot]

Ok, hier kan ik al mee aan de slag.
Wel een opmerking over 'normalisatie' (zoals alle soorten hypens ==> -)

1. is dat een taak van TICCL-unk, of eerder in het proces?
2. Als je normaliseert, dan moet je dat consequent, en overal doen, want anders gaan er zaken scheef lopen. Gaan we genormaliseerde woorden bijv in frog schieten?
3. de normalisatie functie moet ook door niet-TICCL programma's gebruikt of geëmuleerd kunnen worden, denk ik. Stel dat we over‒weg vervangen door over-weg, wie voorkomt bijvoorbeeld dat iemand in Sonar toch weer over‒weg gaat zoeken? (via cut/paste bijv). Dan moet dus ook SoNAr deze zelfde transformatie doen.
   Misschien niet direct ons probleem. Maar beter wel in de gaten houden.

[martinreynaert]

Ja, dit wijst me meteenal op een tekort in de beschrijving hierboven...

Punt 1: ja, dit is dus een taak van TICCL-unk want de originele en herschreven strings moeten dus wel naar 'punct' en de herschreven ook naar 'clean'. Maar gezien er nog andere regels overheen gaan, zou je dit misschien toch samen daarmee moeten kunnen doen. Want als het bv. '^^over‒weg,' is, moet het toch in punct en in clean 'over-weg' worden.

Punt 2. Als 'in frog schieten' betekent 'aan frog voeren', dan: uiteraard. Zie je hier problemen mee? EN zo ja, welke en waarom? Het moeten juist woordvormen worden waar Frog minder moeite mee heeft.

Punt 3. Wij kunnen SoNaR niet zomaar gaan herschrijven, maar de teksten erin die ik verwerkt heb (alles wat niet tot bepaalde nieuwe media behoort) is wel al eerder door een Latin-9 filter gegaan.
Wat betreft de KB collecties: die kunnen wij nog veel minder herschrijven. Mensen moeten daar op alles kunnen zoeken, bv. na cut & paste. Op basis van onze TICCL-lijsten kan evt. wel de mogelijkheid benut worden dat wat mensen ook erin gooien, de query geexpandeerd wordt met alle andere varianten in de TICCL-lijsten. Dan krijg je queries met alle varianten gebaseerd op bv. verschillende soorten hyphens.

Ik denk dat je TICCL-unk moet zien als 1 grote normalizatiemodule. Die kan ook toegepast worden ten bate van andere programma's. Misschien moeten we het straks maar TICCL-norm ofzo gaan noemen. (Maar we moeten niet lichtzinnig programmanamen gaan veranderen...). En als dit gebeurt, moeten ook andere.

[kosloot]

1. Ok, TICCL-unk wordt dus heel uitgebreid, maar dat kan.Maar ik zie het herschrijven toch nog niet helemaal helder. Waar leg je vast dat over‒weg over-weg wordt?
   Niet in de clean lijst, niet in de punct lijst.... Maar dan kun je dus ook niet terugvinden welke transformaties er geweest zijn. Nog een uitvoer lijst dan maar?
2. genormaliseerde teksten aan Frog voeren is inderdaad alleen maar goed. Maar er is dan niet triviaal een terugmapping naar het originele woord.
3. Dus ALS je frog resultaten opslaat (zoals in Sonar) dan kun je helemaal niet meer zoeken met over‒weg , want dat staat er niet in. Daarom zeg ik dus dat je dan ook de query moet normaliseren.
   Een gebruiker die wel over‒weg maar niet over-weg wil zoeken komt denk ik sowieso in de problemen....
   Vergeet ook niet dat een tranformatie dus een N-op-1 zaak is, en een terug-transformatie dus 1-op-n,
   waarbij je niet meer weet waar welke variant precies stond.