Guovdageainnu suohkanstivra og hfst-tokenise (Bugzilla Bug 2364)

[albbas]

This issue was created automatically with bugzilla2github

Bugzilla Bug 2364

Date: 2017-03-17T14:31:07+01:00 From: Sjur Nørstebø Moshagen <> To: Kevin Brubeck Unhammer <<unhammer+apertium>> CC: lene.antonsen, linda.wiechetek, sjur.n.moshagen, thomas.omma, trond.trosterud

Last updated: 2019-08-20T08:35:55+02:00

[albbas]

Comment 12212

Date: 2017-03-17 14:31:07 +0100 From: Sjur Nørstebø Moshagen <>

Jf dei to analysene her:

$ printf "Guovdageainnu\nsuohkanstivra" | hfst-tokenise --giella-cg tools/preprocess/tokeniser-disamb-gt-desc.pmhfst "" "Guovdageaidnu" N Prop Sem/Plc Sg Acc "Guovdageaidnu" N Prop Sem/Plc Sg Gen "Guovdageaidnu" N Prop Sem/Sur Sg Acc "Guovdageaidnu" N Prop Sem/Sur Sg Gen "geaidnu" N Sem/Route Sg Acc "guovda" N Sem/Plc Cmp/SgNom Cmp "geaidnu" N Sem/Route Sg Gen "guovda" N Sem/Plc Cmp/SgNom Cmp :\n "" "suohkanstivra" N Sem/Org Sg Nom "stivra" N Sem/Org Sg Nom "suohkan" N Sem/Org Cmp/SgGen Cmp "stivra" N Sem/Org Sg Nom "suohkan" N Sem/Org Cmp/SgNom Cmp

$ echo Guovdageainnu suohkanstivra | hfst-tokenise --giella-cg tools/preprocess/tokeniser-disamb-gt-desc.pmhfst "" "stivra" N Sem/Org Sg Nom "Guovdageainnu suohkan" N Prop Sem/Org Cmp/SgNom Cmp :\n

Den einaste skilnaden er at eg i den fyrste kommandoen la inn eit lineskift mellom orda for å tvinga fram ei anna lesing. Spørsmålet mitt er:

kvifor får vi ikkje lesinga Guovdageaidnu + suohkanstivra i den andre kommandoen? Etter det eg kan sjå er dette eit perfekt døme på tvetydig tokenisering.

Mens eg skriv dette, så går det opp for meg kva som manglar: vi treng ein markør for å tvinga hfst-tokenise til å reanalysera - den analysen som kjem opp no vinn fordi det blir lengste match, og han prøver seg ikkje på alternativ fordi det er den einaste analysen med denne segmenteringa.

Neste spørsmål blir då: blir det for heftig å tvinga fram reanalyse ved alle samansette proprium? Eller må / bør vi leggja inn ein reanalysetagg for kvart ord som vi meiner kan føra til slik tvetydigheit?

[albbas]

Comment 12215

Date: 2017-03-17 15:25:23 +0100 From: Kevin Brubeck Unhammer <<unhammer+apertium>>

(In reply to Sjur Nørstebø Moshagen from comment #0)

kvifor får vi ikkje lesinga Guovdageaidnu + suohkanstivra i den andre kommandoen? Etter det eg kan sjå er dette eit perfekt døme på tvetydig tokenisering.

Mens eg skriv dette, så går det opp for meg kva som manglar: vi treng ein markør for å tvinga hfst-tokenise til å reanalysera - den analysen som kjem opp no vinn fordi det blir lengste match, og han prøver seg ikkje på alternativ fordi det er den einaste analysen med denne segmenteringa.

Me har jo det; to faktisk. Me kan legga inn ein eksplisitt fleirordsanalyse av den første tokeniseringa skilt med @P.Pmatch.Loc@, eller me kan legga inn @P.Pmatch.Backtrack@ i den andre tokeniseringa.

Neste spørsmål blir då: blir det for heftig å tvinga fram reanalyse ved alle samansette proprium? Eller må / bør vi leggja inn ein reanalysetagg for kvart ord som vi meiner kan føra til slik tvetydigheit?

Kor ofte skjer det i praksis at dei faktisk er tvetydige? Ofte legg ein jo til lange fleirordsuttrykk i leksikon nettopp fordi dei er eintydige når dei står saman, så slepp ein den disambigueringa. Viss det skjer relativt sjeldan, så ville eg heller hatt det inn eksplisitt (om me då bruker Loc på den eine eller Backtrack på den andre blir vel hipp som happ).

[albbas]

Comment 12217

Date: 2017-03-17 15:51:19 +0100 From: Sjur Nørstebø Moshagen <>

(In reply to Kevin Brubeck Unhammer from comment #1)

Neste spørsmål blir då: blir det for heftig å tvinga fram reanalyse ved alle samansette proprium? Eller må / bør vi leggja inn ein reanalysetagg for kvart ord som vi meiner kan føra til slik tvetydigheit?

Kor ofte skjer det i praksis at dei faktisk er tvetydige? Ofte legg ein jo til lange fleirordsuttrykk i leksikon nettopp fordi dei er eintydige når dei står saman, så slepp ein den disambigueringa. Viss det skjer relativt sjeldan, så ville eg heller hatt det inn eksplisitt (om me då bruker Loc på den eine eller Backtrack på den andre blir vel hipp som happ).

Poenget er at samansetjinga er dynamisk. Vi har leksikalisert 'Guovdageainnu suohkan' fordi det er eit namn som dukkar opp med jamne mellomrom i tekstane våre, men samansetjinga med 'stivra' er dynamisk.

Det mest nærliggjande er å leggja det inn i alle bøyingsleksikona for slike namn:

Guovdageainnu% suohkan+MWE:Guovdageainnu% suohkan9 LONDON-org ;

LEXICON LONDON-org +N+Prop+Sem/Org:%> LONDONDECL_PLC-ORG ;

LEXICON LONDONDECL_PLC-ORG ! Final foot structure (X.) and (X..) => Loc:is @U.Cap.Obl@ LONDON-UCASE_PLC-ORG ;

LEXICON LONDON-UCASE_PLC-ORG +Cmp/SgNom: RHyph ; +Cmp/SgNom+Use/-Spell: RProp ; <=== her

Samtidig ser eg her at vi har ikkje med denne typen samsnsetjingar i stavekontrollen, dvs at grammatikkontrollen og stavekontrollen vil vera i konflikt. Det er ikkje bra.

Så ei enno enklare løysing vil vera å seia at vi ikkje tillet slik samansetjing i grammatikkontrollen (men at vi legg inn backtracking-trigger for korpusanalyse).

Synspunkt?

[albbas]

Comment 12219

Date: 2017-03-17 16:44:09 +0100 From: Lene Antonsen <>

Så ei enno enklare løysing vil vera å seia at vi ikkje tillet slik samansetjing i grammatikkontrollen (men at vi legg inn backtracking-trigger for korpusanalyse).

Synspunkt?

Slike MWEer er viktige å beholde i tokeniseringa som brukes for MT. For korpusanalyse, så er det heller motsatt. Jeg synes det ville være best å ikke ha disse som MWE. (Jeg har opplevd dette problemet som er meldt inn i denne bz. i MT)

[albbas]

Comment 12220

Date: 2017-03-17 16:51:03 +0100 From: Kevin Brubeck Unhammer <<unhammer+apertium>>

(In reply to Lene Antonsen from comment #3)

Så ei enno enklare løysing vil vera å seia at vi ikkje tillet slik samansetjing i grammatikkontrollen (men at vi legg inn backtracking-trigger for korpusanalyse).

Synspunkt?

Slike MWEer er viktige å beholde i tokeniseringa som brukes for MT. For korpusanalyse, så er det heller motsatt. Jeg synes det ville være best å ikke ha disse som MWE. (Jeg har opplevd dette problemet som er meldt inn i denne bz. i MT)

Meiner du at det er viktig å ha med begge tokeniseringane, at det er viktig å ha med éin viss av dei?

[albbas]

Comment 12221

Date: 2017-03-17 17:01:14 +0100 From: Lene Antonsen <>

Meiner du at det er viktig å ha med begge tokeniseringane, at det er viktig å ha med éin viss av dei?

Vi trenger Prop MWE inn i MT bl.a. for å kunne gi idiomatiske oversettinger av dem. Det er også viktig at hvis Guovdageainnu suohkan er MWE, så må den ikke stoppe Guovdageainnu suohkanstivra.

Jeg foreslår at vi tar et møte om dette, det er lettere å se på de forskjellige alternativene og konsekvensene det får muntlig enn å ha en forsinka diskusjon i Bz. Denne saka er ikke helt enkel, den har mange konsekvenser

[albbas]

Comment 12222

Date: 2017-03-17 17:03:23 +0100 From: Sjur Nørstebø Moshagen <>

(In reply to Lene Antonsen from comment #3)

Slike MWEer er viktige å beholde i tokeniseringa som brukes for MT. For korpusanalyse, så er det heller motsatt. Jeg synes det ville være best å ikke ha disse som MWE. (Jeg har opplevd dette problemet som er meldt inn i denne bz. i MT)

Tanken var å få fram begge lesingane i disamb-tokeniseringa, slik at vi kan velja kva for ei lesing som er den relevante i kvart tilfelle (MWE eller ikkje).

No la eg inn ein kode i lexc som eg trudde skulle tvinga fram begge lesingane (sjå svn rev 150114), men resultatet vart ikkje slik eg tenkte meg:

$ echo Guovdageainnu suohkanstivra | hfst-tokenise --giella-cg tools/preprocess/tokeniser-disamb-gt-desc.pmhfst "" "stivra" N Sem/Org Sg Nom "Guovdageainnu suohkan" N Prop Sem/Org Cmp/SgNom Cmp "stivra" N Sem/Org Sg Nom "" "Guovdageainnu suohkan" N Prop Sem/Org Sg Nom "" "stivra" N Sem/Org Sg Nom "" "Guovdageainnu suohkan" N Prop Sem/Org Sg Gen Allegro "" "stivra" N Sem/Org Sg Nom "" "Guovdageainnu suohkan" N Prop Sem/Org Attr "" :\n

Kevin - har du ei forklåring på den manglande analysen?

[albbas]

Comment 12223

Date: 2017-03-17 17:04:29 +0100 From: Sjur Nørstebø Moshagen <>

(In reply to Lene Antonsen from comment #5)

Jeg foreslår at vi tar et møte om dette, det er lettere å se på de forskjellige alternativene og konsekvensene det får muntlig enn å ha en forsinka diskusjon i Bz. Denne saka er ikke helt enkel, den har mange konsekvenser

Vi kan godt ta eit møte, anten måndag eller fredag neste veke (dei andre dagane er eg på reise).

[albbas]

Comment 12227

Date: 2017-03-19 10:55:56 +0100 From: Kevin Brubeck Unhammer <<unhammer+apertium>>

(In reply to Sjur Nørstebø Moshagen from comment #6)

(In reply to Lene Antonsen from comment #3)

Slike MWEer er viktige å beholde i tokeniseringa som brukes for MT. For korpusanalyse, så er det heller motsatt. Jeg synes det ville være best å ikke ha disse som MWE. (Jeg har opplevd dette problemet som er meldt inn i denne bz. i MT)

Tanken var å få fram begge lesingane i disamb-tokeniseringa, slik at vi kan velja kva for ei lesing som er den relevante i kvart tilfelle (MWE eller ikkje).

No la eg inn ein kode i lexc som eg trudde skulle tvinga fram begge lesingane (sjå svn rev 150114), men resultatet vart ikkje slik eg tenkte meg:

$ echo Guovdageainnu suohkanstivra | hfst-tokenise --giella-cg tools/preprocess/tokeniser-disamb-gt-desc.pmhfst "" "stivra" N Sem/Org Sg Nom "Guovdageainnu suohkan" N Prop Sem/Org Cmp/SgNom Cmp "stivra" N Sem/Org Sg Nom "" "Guovdageainnu suohkan" N Prop Sem/Org Sg Nom "<Guovdageainnu suohkan>" "stivra" N Sem/Org Sg Nom "" "Guovdageainnu suohkan" N Prop Sem/Org Sg Gen Allegro "" "stivra" N Sem/Org Sg Nom "" "Guovdageainnu suohkan" N Prop Sem/Org Attr "" :\n

Kevin - har du ei forklåring på den manglande analysen?

Eg har ikkje så oversikt over leksikona, men det såg ut som backtrack-flagget stod i slutten av ordet? Viss me skal prøva reanalyse på mellomrommet, så må flagget stå på (før/etter) mellomrommet; står det til slutt, prøver det å reanalysera dei to strengane "Guovdageainnu suohkan" og "", som ikkje hjelper så mykje :-)

[albbas]

Comment 12228

Date: 2017-03-19 10:57:07 +0100 From: Kevin Brubeck Unhammer <<unhammer+apertium>>

(In reply to Kevin Brubeck Unhammer from comment #8)

(In reply to Sjur Nørstebø Moshagen from comment #6)

(In reply to Lene Antonsen from comment #3)

Slike MWEer er viktige å beholde i tokeniseringa som brukes for MT. For korpusanalyse, så er det heller motsatt. Jeg synes det ville være best å ikke ha disse som MWE. (Jeg har opplevd dette problemet som er meldt inn i denne bz. i MT)

Tanken var å få fram begge lesingane i disamb-tokeniseringa, slik at vi kan velja kva for ei lesing som er den relevante i kvart tilfelle (MWE eller ikkje).

No la eg inn ein kode i lexc som eg trudde skulle tvinga fram begge lesingane (sjå svn rev 150114), men resultatet vart ikkje slik eg tenkte meg:

$ echo Guovdageainnu suohkanstivra | hfst-tokenise --giella-cg tools/preprocess/tokeniser-disamb-gt-desc.pmhfst "" "stivra" N Sem/Org Sg Nom "Guovdageainnu suohkan" N Prop Sem/Org Cmp/SgNom Cmp "stivra" N Sem/Org Sg Nom "" "Guovdageainnu suohkan" N Prop Sem/Org Sg Nom "<Guovdageainnu suohkan>" "stivra" N Sem/Org Sg Nom "" "Guovdageainnu suohkan" N Prop Sem/Org Sg Gen Allegro "" "stivra" N Sem/Org Sg Nom "" "Guovdageainnu suohkan" N Prop Sem/Org Attr "" :\n

Kevin - har du ei forklåring på den manglande analysen?

Eg har ikkje så oversikt over leksikona, men det såg ut som backtrack-flagget stod i slutten av ordet? Viss me skal prøva reanalyse på mellomrommet, så må flagget stå på (før/etter) mellomrommet; står det til slutt, prøver det å reanalysera dei to strengane "Guovdageainnu suohkan" og "", som ikkje hjelper så mykje :-)

… eller dei to strengane "Guovdageainnu suohkan" og "stivra", i dette tilfellet.

[albbas]

Comment 12229

Date: 2017-03-20 09:15:34 +0100 From: Sjur Nørstebø Moshagen <>

(In reply to Kevin Brubeck Unhammer from comment #8)

Kevin - har du ei forklåring på den manglande analysen?

Eg har ikkje så oversikt over leksikona, men det såg ut som backtrack-flagget stod i slutten av ordet? Viss me skal prøva reanalyse på mellomrommet, så må flagget stå på (før/etter) mellomrommet; står det til slutt, prøver det å reanalysera dei to strengane "Guovdageainnu suohkan" og "", som ikkje hjelper så mykje :-)

Eg brukte @P.Pmatch.Backtrack@ som backtracking- og reanalysemerke, og trudde at berre førekomsten av dette symbolet - uansett plass - var nok til å tvinga fram alle alternative segmenteringar:/

No la eg inn symbolet rett før mellomrom, og resultatet vart akkurat slik vi vil ha det:

Gamalt oppsett:

"" "Guovdageaidnu" N Prop Sem/Plc Sg Acc "Guovdageaidnu" N Prop Sem/Plc Sg Gen "Guovdageaidnu" N Prop Sem/Sur Sg Acc "Guovdageaidnu" N Prop Sem/Sur Sg Gen "" "suohkanstivra" N Sem/Org Sg Nom

Nytt oppsett med hfst-tokenise:

"" "stivra" N Sem/Org Sg Nom "Guovdageainnu suohkan" N Prop Sem/Org Cmp/SgNom Cmp "suohkanstivra" N Sem/Org Sg Nom "Guovdageaidnu" N Prop Sem/Plc Sg Acc "suohkanstivra" N Sem/Org Sg Nom "Guovdageaidnu" N Prop Sem/Plc Sg Gen "suohkanstivra" N Sem/Org Sg Nom "Guovdageaidnu" N Prop Sem/Sur Sg Acc "suohkanstivra" N Sem/Org Sg Nom "Guovdageaidnu" N Prop Sem/Sur Sg Gen

Herifrå kan ein disambiguera seg fram til kva for ei segmentering ein vil ha:)

Sidan @P.Pmatch.Backtrack@ er ein ganske lang tekststreng å leggja inn ved alle mellomrom som skal ha alternativ segmentering vil eg føreslå at vi nyttar eit anna symbol i staden, som vi så kan byta ut automatisk som ein del av kompileringa. Kva med: 😵?

Assosiasjonen er: x = del meg (i to).

Men det kan gjerne vera noko anna.

[albbas]

Comment 12231

Date: 2017-03-20 10:07:06 +0100 From: Kevin Brubeck Unhammer <<unhammer+apertium>>

(In reply to Sjur Nørstebø Moshagen from comment #10)

(In reply to Kevin Brubeck Unhammer from comment #8)

Kevin - har du ei forklåring på den manglande analysen?

Eg har ikkje så oversikt over leksikona, men det såg ut som backtrack-flagget stod i slutten av ordet? Viss me skal prøva reanalyse på mellomrommet, så må flagget stå på (før/etter) mellomrommet; står det til slutt, prøver det å reanalysera dei to strengane "Guovdageainnu suohkan" og "", som ikkje hjelper så mykje :-)

Eg brukte @P.Pmatch.Backtrack@ som backtracking- og reanalysemerke, og trudde at berre førekomsten av dette symbolet - uansett plass - var nok til å tvinga fram alle alternative segmenteringar:/

hfst-tokenise prøver berre å dela opp der symbolet står. Me vil jo t.d. kunna dela opp mellom teikn som elles ikkje er tokengrensar («leago» som «lea|go» eller liknande), så om backtrack-symbolet skulle gitt alle oppdelingar, ville me måtta prøvd: G|uovdageainnu suohkan Guovda|geainnu| |suohkan G|u|o|v|d|a|g|e|a|i|n|n|u| |s|u|o|h|kan G|u|o|v|d|a|g|e|a|i|n|n|u| |s|u|o|h|k|a|n osb.

No la eg inn symbolet rett før mellomrom, og resultatet vart akkurat slik vi vil ha det:

Gamalt oppsett:

"" "Guovdageaidnu" N Prop Sem/Plc Sg Acc "Guovdageaidnu" N Prop Sem/Plc Sg Gen "Guovdageaidnu" N Prop Sem/Sur Sg Acc "Guovdageaidnu" N Prop Sem/Sur Sg Gen "" "suohkanstivra" N Sem/Org Sg Nom

Nytt oppsett med hfst-tokenise:

"" "stivra" N Sem/Org Sg Nom "Guovdageainnu suohkan" N Prop Sem/Org Cmp/SgNom Cmp "suohkanstivra" N Sem/Org Sg Nom "Guovdageaidnu" N Prop Sem/Plc Sg Acc "suohkanstivra" N Sem/Org Sg Nom "Guovdageaidnu" N Prop Sem/Plc Sg Gen "suohkanstivra" N Sem/Org Sg Nom "Guovdageaidnu" N Prop Sem/Sur Sg Acc "suohkanstivra" N Sem/Org Sg Nom "Guovdageaidnu" N Prop Sem/Sur Sg Gen

Herifrå kan ein disambiguera seg fram til kva for ei segmentering ein vil ha:)

:-D

Sidan @P.Pmatch.Backtrack@ er ein ganske lang tekststreng å leggja inn ved alle mellomrom som skal ha alternativ segmentering vil eg føreslå at vi nyttar eit anna symbol i staden, som vi så kan byta ut automatisk som ein del av kompileringa. Kva med: 😵?

Assosiasjonen er: x = del meg (i to).

x? (har bz brukt ein auto-emoji-funksjon her?)

Men det kan gjerne vera noko anna.

Det bør vel stå på begge sidar av FST-tapen – det er jo viktig at det kjem på rett stad i form-strengen.

[albbas]

Comment 12233

Date: 2017-03-20 10:58:19 +0100 From: Sjur Nørstebø Moshagen <>

(In reply to Kevin Brubeck Unhammer from comment #11)

hfst-tokenise prøver berre å dela opp der symbolet står.

Ok, takk for oppklaring og forklaring :)

Sidan @P.Pmatch.Backtrack@ er ein ganske lang tekststreng å leggja inn ved alle mellomrom som skal ha alternativ segmentering vil eg føreslå at vi nyttar eit anna symbol i staden, som vi så kan byta ut automatisk som ein del av kompileringa. Kva med: 😵?

Assosiasjonen er: x = del meg (i to).

x? (har bz brukt ein auto-emoji-funksjon her?)

Emojien har x over augo, difor x-en. Og det er eg som har skrive inn emojien manuelt - emojiar er svært usannsynlege som symbol midt inne i ord i vanleg tekst, så sjansane for kollisjonar med annan bruk er minimal. Og så blir det lett å sjå kor ein har lagt inn slike symbol i lexc-koden :)

Men det kan gjerne vera noko anna.

Det bør vel stå på begge sidar av FST-tapen – det er jo viktig at det kjem på rett stad i form-strengen.

Absolutt. Det må vera symmetrisk. Men emojiane vil bli bytta ut mot @P.Pmatch.Backtrack@ automatisk som ein del av kompileringa, og vil slik sett bli "usynlege" for verda utanfor hfst.

[albbas]

Comment 12280

Date: 2017-04-03 21:44:00 +0200 From: Lene Antonsen <>

Jeg har testa med P.Pmatch.Backtrack:

gii@P.Pmatch.Backtrack@% nu+MWE+Pron+Indef+Sg+Nom:gii@P.Pmatch.Backtrack@% nu # ;

Men jeg har fortsatt problemer med 'gii nuppi' som skulle vært 'gii' og 'nuppi':

echo Dalseng, gii nuppi sadjái lea nammaduvvon. | apertium -d. sme-nob-biltrans ^Dalsengnp><cog><sg><nom><@VOC/Dalsengnp><cog><sg><nom><@VOC$^,/,$ ^gii nuppi/gii nuppi$ ^sadjin><sem_plc_pos><sg><ill><@ADVL→/stedn><nt><maydetind><sem_plc_pos><sg><ill><@ADVL→/plassn><m><maydetind><sem_plc_pos><sg><ill><@ADVL→$ ^leatvblex><iv><indic><pres><p3><sg><@+FAUXV/værevblex><impers><pres><p3><sg><@+FAUXV/havblex><pers><pres><p3><sg><@+FAUXV/måttevblex><pers><pres><p3><sg><@+FAUXV$ ^nammaditvblex><tv><der_passl><vblex><iv><prfprc><@-FMAINV/utnevnevblex><pers><pp><pasv><@-FMAINV$^../..$

[albbas]

Comment 12281

Date: 2017-04-03 22:12:22 +0200 From: Kevin Brubeck Unhammer <<unhammer+apertium>>

(In reply to Lene Antonsen from comment #13)

Jeg har testa med P.Pmatch.Backtrack:

gii@P.Pmatch.Backtrack@% nu+MWE+Pron+Indef+Sg+Nom:gii@P.Pmatch.Backtrack@% nu # ;

Men jeg har fortsatt problemer med 'gii nuppi' som skulle vært 'gii' og 'nuppi':

echo Dalseng, gii nuppi sadjái lea nammaduvvon. | apertium -d. sme-nob-biltrans ^Dalsengnp><cog><sg><nom><@VOC/Dalsengnp><cog><sg><nom><@VOC$^,/,

$ ^*gii nuppi/*gii nuppi$ ^sadji<@ADVL→>/ sted<@ADVL→>/ plass<@ADVL→>$ ^leat<@+FAUXV>/ være<@+FAUXV>/ ha<@+FAUXV>/ måtte<@+FAUXV>$ ^nammadit<@-FMAINV>/ utnevne<@-FMAINV>$^../..$

hfst-tokenise er ikkje i bruk i apertium, så fram til det skjer må det nok spesifiserast på gamlemåten viss det skal inn der (dvs. alle lesingar eksplisitt i leksikon)

[albbas]

Comment 13585

Date: 2019-08-20 08:35:55 +0200 From: Sjur Nørstebø Moshagen <>

Vi løyste det på den måten at vi blokkerte dynamisk samansetjing for MWE-tagga ord. Dette blokkerer samansetjinga med G. suohkan + stivra, og tvingar fram ei eintydig analyse slik:

$ echo 'Guovdageainnu suohkanstivra'	hfst-tokenise -g tools/tokenisers/tokeniser-gramcheck-gt-desc.pmhfst "" "Guovdageaidnu" N Prop Sem/Plc Sg Acc "Guovdageaidnu" N Prop Sem/Plc Sg Gen "geaidnu" N Sem/Route Sg Acc "guovda" N Sem/Plc Cmp/SgNom Cmp "geaidnu" N Sem/Route Sg Gen "guovda" N Sem/Plc Cmp/SgNom Cmp

"" "stivra" N Sem/Org Sg Nom "suohkan" N Sem/Org Cmp/SgGen Cmp "stivra" N Sem/Org Sg Nom "suohkan" N Sem/Org Cmp/SgNom Cmp "suohkanstivra" N Sem/Org Sg Nom :\n

Det ser ut til å vera eit akseptabelt og funksjonelt kompromiss for grammatikkontrollen, og eg avsluttar denne lusmeldinga.