Bug 2487

Summary: Nytt verkty for å sortera taggar og sjekka lexc-strukturen i stems-filene
Product: Infrastructure Reporter: Sjur Nørstebø Moshagen <sjur.n.moshagen>
Component: LexiconAssignee: Børre Gaup <borre.gaup>
Status: ASSIGNED ---    
Severity: enhancement CC: elena.j.paulsen, lene.antonsen, linda.wiechetek, maja.l.kappfjell, thomas.omma, trond.trosterud, unhammer+apertium
Priority: P3 - Within a week    
Version: unspecified   
Hardware: All   
OS: All   

Description Sjur Nørstebø Moshagen 2018-05-15 15:41:41 CEST
Eg føreslår, slik eg nemnde i ein e-posttråd frå denne veka, at vi (=Børre) lagar eit nytt verkty som sjekkar at lexc-filene er slik dei skal vera. Verktyet skal sjekka (og ev retta):

* bruken av mellomrom i stems-filene
* rekkjefylgja på taggar (akkurat kva den rekkjefylgja skal vera kan/bør vi diskutera)
* setja inn manglande taggar (t.d. ordklassetaggar)

Det skal vera mogleg å gjera språkspesifikke unnatak og tilpassingar i ei config-fil som kan liggja til dømes i src/morphology/ for kvart språk.
Comment 1 Sjur Nørstebø Moshagen 2018-05-15 15:46:32 CEST
Mitt forslag til taggrekkjefylgje er (lista er vertikal slik at ein kan kommentera, men dei skal sjølvsagt stå etter kvarandre i lexc, slik at den øvste taggen står lengst til venstre i taggrekka):

+vN
+HomN
+Ordklasse
+Sem/tagg
+CmpN/taggar
+CmpNP/taggar

Taggar som eg ikkje har synspunkt på (enno) er t.d.:

+OLang/taggar
+Err/taggar
+Dial/taggar
+Der/taggar
Comment 2 Lene Antonsen 2018-05-15 16:13:54 CEST
I tillegg har vi for diskusjon følgende
+G3 +NomAg

Disse to karakteriserer morfologiske/morfofonologiske trekk ved lemmaet, og i noen tilfeller blir de dermed identifiserende for homonymer.
Comment 3 Sjur Nørstebø Moshagen 2018-05-16 10:56:10 CEST
For å gjera det mogleg for Børre å laga eit robust verkty utan alt for mykje spesialkode og unnatak, bør vi konsekvent flytta all affiks-kode til affixes/. Slik det er no så er det mange av dei lukka ordklassene som blandar affiks- og stammeleksikon i same fil.
Comment 4 Sjur Nørstebø Moshagen 2018-05-16 10:57:47 CEST
(In reply to Lene Antonsen from comment #2)
> I tillegg har vi for diskusjon følgende
> +G3 +NomAg
> 
> Disse to karakteriserer morfologiske/morfofonologiske trekk ved lemmaet, og
> i noen tilfeller blir de dermed identifiserende for homonymer.

Mitt syn på desse er at dei av nettopp den grunnen du nemner bør sjåast på som homonymitaggar, og behandlast/plasserast i samsvar med det. Vi tek eit eige møte på det neste veke.
Comment 5 Børre Gaup 2018-05-16 14:43:54 CEST
Har laget en oversikt over taggene som finnes i langs/*/src/morphology/stems/*.lexc
Oversiktene ligger i langs/*/src/morphology/tags.yaml
Comment 6 Børre Gaup 2018-05-16 17:18:00 CEST
I langtech r166851 sorterer virkelig skriptet tagger i stems/*.lexc.
Dere kan kjøre det og se hva det gjør med lexc-filene. Det tar en stund å kjøre det siden det går igjennom de fleste språkene i langs.

Kjør det ved å skrive:
giella-core/devtools/lexc-tag-sorter.py

Feil jeg vet om:
* legger ikke inn POS
* flytter på POS og MWE om det finnes
* beholder samme orden innad i Cmp- og Sem-taggene
 
Når dere kjører det, så ser man ganske tydelig på diffene hvilke deler av koden i stems/*.lexc som bør flyttes til affixes.
Comment 7 Lene Antonsen 2018-05-18 08:50:06 CEST
Litt bakgrunn for diskusjonen om taggene som skiller mellom varianter eller homonymer. 

varianter: +vN
NDS: taggen er synlig i analysator, men usynlig i generator, bare +v1 blir generert. De andre variantene er ikke med i generatoren
MT: taggen er ikke synlig, bare +v1 blir generert. De andre variantene er ikke med i generatoren. Ingen referanse til taggen i bidix eller transferfiler

homonymer
+HomN +G3 +NomAg
NDS: taggene er synlige i analysator, og obligatoriske i generator
MT: taggene er synlige i analysator, og obligatoriske i generator, de er med i bidix når det er behov for å skille mellom homonymer. Hvis det ikke er homonymer, trenger man ikke skrive taggen i bidix, bortsett fra hvis man av andre grunner trenger å gjengi hele taggrekka. Default er at det er nok med PoS, men det forutsetter at PoS kommer foran taggen.

+HomN er rett etter lemmaet og blir omvandlet til superskript i MT: lemma1 lemma2 
Det er svært få +Hom-tagger og bare i sma for MT, og kun for å skille homonymer.
Comment 8 Sjur Nørstebø Moshagen 2018-05-18 09:59:45 CEST
(In reply to Lene Antonsen from comment #7)
> Litt bakgrunn for diskusjonen om taggene som skiller mellom varianter eller
> homonymer. 
> 
> varianter: +vN
> NDS: taggen er synlig i analysator, men usynlig i generator, bare +v1 blir
> generert. De andre variantene er ikke med i generatoren
> MT: taggen er ikke synlig, bare +v1 blir generert. De andre variantene er
> ikke med i generatoren. Ingen referanse til taggen i bidix eller
> transferfiler

Desse er enkle og rett fram å forhalda seg til.

> homonymer
> +HomN +G3 +NomAg
> NDS: taggene er synlige i analysator, og obligatoriske i generator
> MT: taggene er synlige i analysator, og obligatoriske i generator, de er med
> i bidix når det er behov for å skille mellom homonymer. Hvis det ikke er
> homonymer, trenger man ikke skrive taggen i bidix, bortsett fra hvis man av
> andre grunner trenger å gjengi hele taggrekka. Default er at det er nok med
> PoS, men det forutsetter at PoS kommer foran taggen.
> 
> +HomN er rett etter lemmaet og blir omvandlet til superskript i MT: lemma1
> lemma2 
> Det er svært få +Hom-tagger og bare i sma for MT, og kun for å skille
> homonymer.

Slik eg har forstått problemet med å flytta G3 og NomAg så gjeld det berre MT. Men om vi ser på dei som ekte homonymitaggar (sjølv om dei ikkje alltid speglar ein reell homonymi, dvs det finst ikkje noko parord utan G3- eller NomAg-taggen), og krev at dei alltid står rett etter lemmaet, __og alltid står i bidix__, så burde det ikkje vera noko problem? Dvs at vi gjer G3 og NomAg obligatorisk i alle samanhengar, på lik line med resten av lemmaet.
Comment 9 Lene Antonsen 2018-05-18 10:43:03 CEST
> og krev at dei alltid står rett etter lemmaet, __og alltid
> står i bidix__, så burde det ikkje vera noko problem? Dvs at vi gjer G3 og
> NomAg obligatorisk i alle samanhengar, på lik line med resten av lemmaet.

Dette vil gjøre bidix mye mindre robust. Dvs at alle som arbeider med bidix for sme-par, må kunne nordsamisk morfologi. +NomAg og +G3 er våre interne tagger som ikke finnes i ordbøker. I MT arbeidet trenger vi folk som er flinke i det andre språket i paret. I så tilfelle ville det være en bedre løsning at man skal bruke +NomAg og +G3 bare i de tilfellene at det er et reellt homonymipar, på linje med +HomN. 

Men +NomAg og +G3 har en verdi utover MT, nemlig i pedagogiske programmer, og kanskje grammatikkontrollen, kan man på grunnlag av disse taggene gi metalingvistisk informasjon til brukeren om at ordene ikke har stadieveksling i ortografien. For +NomAg kan man også kommentere diftongforenkling (slik som normen er no, skal det være diftongforenkling til tross for at halvparten av talerne ikke har det i sin dialekt.). Derfor er det nyttig å ha disse taggene også utenom homonymiparene.

Det ville ellers være bra å få kommentar fra Kevin ang. transferfilene. HomN taggene er en del av lemmaet (govledh¹), men hvordan kan man løse +NomAg. Må denne også inn i lemmaet, f.eks: lemma_nomag, evt nomag som superskript, eller ville man kunne "usynliggjøre" <nomag> ved at den er med i bidix:
lemmma<s n="nomag"/><s n="n"/>
og deretter bare refere til <n> i transferfilene?
Comment 10 Kevin Brubeck Unhammer 2018-06-05 18:36:38 CEST
(In reply to Lene Antonsen from comment #9)
> > og krev at dei alltid står rett etter lemmaet, __og alltid
> > står i bidix__, så burde det ikkje vera noko problem? Dvs at vi gjer G3 og
> > NomAg obligatorisk i alle samanhengar, på lik line med resten av lemmaet.
> 
> Dette vil gjøre bidix mye mindre robust. Dvs at alle som arbeider med bidix
> for sme-par, må kunne nordsamisk morfologi. +NomAg og +G3 er våre interne
> tagger som ikke finnes i ordbøker. I MT arbeidet trenger vi folk som er
> flinke i det andre språket i paret. I så tilfelle ville det være en bedre
> løsning at man skal bruke +NomAg og +G3 bare i de tilfellene at det er et
> reellt homonymipar, på linje med +HomN. 
> 
> Men +NomAg og +G3 har en verdi utover MT, nemlig i pedagogiske programmer,
> og kanskje grammatikkontrollen, kan man på grunnlag av disse taggene gi
> metalingvistisk informasjon til brukeren om at ordene ikke har
> stadieveksling i ortografien. For +NomAg kan man også kommentere
> diftongforenkling (slik som normen er no, skal det være diftongforenkling
> til tross for at halvparten av talerne ikke har det i sin dialekt.). Derfor
> er det nyttig å ha disse taggene også utenom homonymiparene.
> 
> Det ville ellers være bra å få kommentar fra Kevin ang. transferfilene. HomN
> taggene er en del av lemmaet (govledh¹), men hvordan kan man løse +NomAg. Må
> denne også inn i lemmaet, f.eks: lemma_nomag, evt nomag som superskript,
> eller ville man kunne "usynliggjøre" <nomag> ved at den er med i bidix:
> lemmma<s n="nomag"/><s n="n"/>
> og deretter bare refere til <n> i transferfilene?

Om det er del av lemmaet er jo enklast for transfer (og høyrest eigentleg logisk ut, sidan homonymiar er sånt som tilfeldigvis (eller av historiske årsakar) har same lemma). Men det ser kanskje ikkje så pent ut med 

    bargiⁿ

eller kva det skulle vore.

Om du har <nomag> som første tagg, så kunne du kanskje hatt eit steg etter bidix og føre ekte transfer som berre har taggreinsk som oppgåve. Det ser ut som det er mogleg med `apertium-transfer`:

$ echo '^bargi<n><nomag><sem_hum><sg><nom>$' |lt-proc -b sme-nob.autobil.bin|sed 's/<n><nomag>/<nomag><n>/g' 
^bargi<nomag><n><sem_hum><sg><nom>/ansatt<adj><m><pst><sg><nom>/arbeider<n><m><maydetind><sg><nom>$

$ echo '^bargi<n><nomag><sem_hum><sg><nom>$' |lt-proc -b sme-nob.autobil.bin|sed 's/<n><nomag>/<nomag><n>/g' | apertium-transfer -b /tmp/foo.t1x /tmp/foo.t1x.bin 
^bargi<n><sem_hum><sg><nom>/ansatt<adj><m><pst><sg><nom>/arbeider<n><m><maydetind><sg><nom>$

$ cat /tmp/foo.t1x
<?xml version="1.0" encoding="utf-8"?>
<transfer default="chunk">
  <section-def-cats>
    <def-cat n="nomag">
      <cat-item tags="nomag.*"/>
    </def-cat>
  </section-def-cats>
  <section-def-attrs>
    <def-attr n="a_nomag">
      <attr-item tags="nomag"/>
    </def-attr>
  </section-def-attrs>

  <section-def-vars>
    <def-var n="out" />
  </section-def-vars>

  <section-def-macros>
    <def-macro n="foo" npar="1">
      <let><clip pos="1" side="sl" part="a_nomag"/><lit v=""/></let>
    </def-macro>
  </section-def-macros>

  <section-rules>
    <rule>
      <pattern>
        <pattern-item n="nomag"/>
      </pattern>
      <action>
        <let><clip pos="1" side="sl" part="a_nomag"/><lit v=""/></let>
        <let>
          <var n="out"/>
          <concat>
            <lit v="^"/>
            <clip pos="1" side="sl" part="whole"/>
            <lit v="$"/>
          </concat>
        </let>
        <out><var n="out"/></out>
      </action>
    </rule>
  </section-rules>
</transfer>


Det er litt hackete, men ser jo ut til å fungera.
Comment 11 Lene Antonsen 2018-06-05 18:49:02 CEST
 > Om du har <nomag> som første tagg, så kunne du kanskje hatt eit steg etter
> bidix og føre ekte transfer som berre har taggreinsk som oppgåve. Det ser ut
> som det er mogleg med `apertium-transfer`:

Hvis jeg tolker dette riktig, så er det to løsninger:
1) at taggen legges som superskript på lemmaet
2) at taggen flyttes til etter n i et eget steg innafor apertium.

Jeg mener at vi ikke skal flytte +NomAg og +G3 til foran PoS hvis det ikke er gode grunner for det. Det skaper støy og en mindre robust bidix, og taggene inneholder informasjon utover det som +HomN taggene gjør, så derfor er de ikke helt sammenliknbare. For å få et likt system, vil jeg heller gå inn for å flytte +HomN taggen til etter PoS.
Comment 12 Sjur Nørstebø Moshagen 2018-06-29 14:17:42 CEST
(In reply to Børre Gaup from comment #6)
> Kjør det ved å skrive:
> giella-core/devtools/lexc-tag-sorter.py
> 
> Feil jeg vet om:
> * legger ikke inn POS
> * flytter på POS og MWE om det finnes
> * beholder samme orden innad i Cmp- og Sem-taggene

Andre feil eg fann:

I chp/ blir tre filer forandra. pronouns.lexc er ok/harmlaus/korrekt (men burde ikkje ha semtagg i seg), dei to andre filene blir øydelagde: + framfor taggar blir fjerna. Fint om du rettar slike feil før eg testar på nytt :-)
Comment 13 Trond Trosterud 2018-06-29 14:27:15 CEST
Mine feil er meir grunnleggjande: 

tf4-hsl-m0024:main trond$ giella-core/devtools/lexc-tag-sorter.py
Traceback (most recent call last):
  File "giella-core/devtools/lexc-tag-sorter.py", line 37, in <module>
    import yaml
ImportError: No module named yaml
Comment 14 Børre Gaup 2018-07-02 12:24:53 CEST
(In reply to Trond Trosterud from comment #13)
> Mine feil er meir grunnleggjande: 
> 
> tf4-hsl-m0024:main trond$ giella-core/devtools/lexc-tag-sorter.py
> Traceback (most recent call last):
>   File "giella-core/devtools/lexc-tag-sorter.py", line 37, in <module>
>     import yaml
> ImportError: No module named yaml

Du må installere yaml-modulen, f.eks:

sudo port install py-yaml
eller
pip install -U PyYAML
Comment 15 Børre Gaup 2018-07-11 16:38:54 CEST
(In reply to Sjur Nørstebø Moshagen from comment #12)

> 
> Andre feil eg fann:
> 
> I chp/ blir tre filer forandra. pronouns.lexc er ok/harmlaus/korrekt (men
> burde ikkje ha semtagg i seg), dei to andre filene blir øydelagde: + framfor
> taggar blir fjerna. Fint om du rettar slike feil før eg testar på nytt :-)

Feilen med + foran tagger som blir fjernet er i orden nå.
Comment 16 Børre Gaup 2018-07-11 16:54:02 CEST
(In reply to Sjur Nørstebø Moshagen from comment #1)
> Mitt forslag til taggrekkjefylgje er (lista er vertikal slik at ein kan
> kommentera, men dei skal sjølvsagt stå etter kvarandre i lexc, slik at den
> øvste taggen står lengst til venstre i taggrekka):
> 
> +vN
> +HomN
> +Ordklasse
> +Sem/tagg
> +CmpN/taggar
> +CmpNP/taggar
> 

Taggene blir nå sortert i denne rekkefølgen.
Comment 17 Børre Gaup 2018-07-11 16:57:16 CEST
Denne linjen i langs/vro/src/morphology/stems/punctuation.lexc

 +Sg+Nom+: # ;              ! §

blir endret til dette:

 ++Sg+Nom: # ;              ! §

Er det noe nytte i det siste plusstegnet i den opprinnelige linjen, eller kan den bare bli sløyfet?
Comment 18 Trond Trosterud 2018-07-13 22:53:50 CEST
(In reply to Børre Gaup from comment #17)
> Denne linjen i langs/vro/src/morphology/stems/punctuation.lexc
> 
>  +Sg+Nom+: # ;              ! §
> 
> blir endret til dette:
> 
>  ++Sg+Nom: # ;              ! §
> 
> Er det noe nytte i det siste plusstegnet i den opprinnelige linjen, eller
> kan den bare bli sløyfet?

Ei slik linje finst for vro, sma, smj, og for dei to förste med +, for smj utan +. Eg forstår ikkje kva funksjon desse linjene har, men + etter Nom mp rett og slett vere feil.

==> fjern pluss-symbolet, for vro og sma. Kva det enn resulterer i vil bli det smj har i dag.