Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nytt verkty for å sortera taggar og sjekka lexc-strukturen i stems-filene (Bugzilla Bug 2487) #61

Open
albbas opened this issue May 15, 2018 · 19 comments
Assignees
Labels
enhancement New feature or request

Comments

@albbas
Copy link
Contributor

albbas commented May 15, 2018

This issue was created automatically with bugzilla2github

Bugzilla Bug 2487

Date: 2018-05-15T15:41:41+02:00
From: Sjur Nørstebø Moshagen <<sjur.n.moshagen>>
To: Børre Gaup <<borre.gaup>>
CC: elena.j.paulsen, lene.antonsen, linda.wiechetek, maja.l.kappfjell, thomas.omma, trond.trosterud, unhammer+apertium

Last updated: 2018-07-13T22:53:50+02:00

@albbas
Copy link
Contributor Author

albbas commented May 15, 2018

Comment 12826

Date: 2018-05-15 15:41:41 +0200
From: Sjur Nørstebø Moshagen <<sjur.n.moshagen>>

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.

@albbas
Copy link
Contributor Author

albbas commented May 15, 2018

Comment 12827

Date: 2018-05-15 15:46:32 +0200
From: Sjur Nørstebø Moshagen <<sjur.n.moshagen>>

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

@albbas
Copy link
Contributor Author

albbas commented May 15, 2018

Comment 12828

Date: 2018-05-15 16:13:54 +0200
From: Lene Antonsen <<lene.antonsen>>

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.

@albbas
Copy link
Contributor Author

albbas commented May 16, 2018

Comment 12839

Date: 2018-05-16 10:56:10 +0200
From: Sjur Nørstebø Moshagen <<sjur.n.moshagen>>

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.

@albbas
Copy link
Contributor Author

albbas commented May 16, 2018

Comment 12840

Date: 2018-05-16 10:57:47 +0200
From: Sjur Nørstebø Moshagen <<sjur.n.moshagen>>

(In reply to Lene Antonsen from comment giellalt/bugzilla-dummy#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.

@albbas
Copy link
Contributor Author

albbas commented May 16, 2018

Comment 12844

Date: 2018-05-16 14:43:54 +0200
From: Børre Gaup <<borre.gaup>>

Har laget en oversikt over taggene som finnes i langs//src/morphology/stems/.lexc
Oversiktene ligger i langs/*/src/morphology/tags.yaml

@albbas
Copy link
Contributor Author

albbas commented May 16, 2018

Comment 12845

Date: 2018-05-16 17:18:00 +0200
From: Børre Gaup <<borre.gaup>>

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.

@albbas
Copy link
Contributor Author

albbas commented May 18, 2018

Comment 12848

Date: 2018-05-18 08:50:06 +0200
From: Lene Antonsen <<lene.antonsen>>

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.

@albbas
Copy link
Contributor Author

albbas commented May 18, 2018

Comment 12856

Date: 2018-05-18 09:59:45 +0200
From: Sjur Nørstebø Moshagen <<sjur.n.moshagen>>

(In reply to Lene Antonsen from comment giellalt/bugzilla-dummy#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.

@albbas
Copy link
Contributor Author

albbas commented May 18, 2018

Comment 12858

Date: 2018-05-18 10:43:03 +0200
From: Lene Antonsen <<lene.antonsen>>

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" ved at den er med i bidix:
lemmma
og deretter bare refere til i transferfilene?

@albbas
Copy link
Contributor Author

albbas commented Jun 5, 2018

Comment 12913

Date: 2018-06-05 18:36:38 +0200
From: Kevin Brubeck Unhammer <<unhammer+apertium>>

(In reply to Lene Antonsen from comment giellalt/bugzilla-dummy#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" ved at den er med i bidix:
lemmma
og deretter bare refere til 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 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<sem_hum>$' |lt-proc -b sme-nob.autobil.bin|sed 's///g'
^bargi<sem_hum>/ansatt/arbeider$

$ echo '^bargi<sem_hum>$' |lt-proc -b sme-nob.autobil.bin|sed 's///g' | apertium-transfer -b /tmp/foo.t1x /tmp/foo.t1x.bin
^bargi<sem_hum>/ansatt/arbeider$

$ cat /tmp/foo.t1x

Det er litt hackete, men ser jo ut til å fungera.

@albbas
Copy link
Contributor Author

albbas commented Jun 5, 2018

Comment 12914

Date: 2018-06-05 18:49:02 +0200
From: Lene Antonsen <<lene.antonsen>>

Om du har 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.

@albbas
Copy link
Contributor Author

albbas commented Jun 29, 2018

Comment 12918

Date: 2018-06-29 14:17:42 +0200
From: Sjur Nørstebø Moshagen <<sjur.n.moshagen>>

(In reply to Børre Gaup from comment giellalt/bugzilla-dummy#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 :-)

@albbas
Copy link
Contributor Author

albbas commented Jun 29, 2018

Comment 12919

Date: 2018-06-29 14:27:15 +0200
From: Trond Trosterud <<trond.trosterud>>

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
import yaml
ImportError: No module named yaml

@albbas
Copy link
Contributor Author

albbas commented Jul 2, 2018

Comment 12920

Date: 2018-07-02 12:24:53 +0200
From: Børre Gaup <<borre.gaup>>

(In reply to Trond Trosterud from comment giellalt/bugzilla-dummy#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
import yaml
ImportError: No module named yaml

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

sudo port install py-yaml
eller
pip install -U PyYAML

@albbas
Copy link
Contributor Author

albbas commented Jul 11, 2018

Comment 12924

Date: 2018-07-11 16:38:54 +0200
From: Børre Gaup <<borre.gaup>>

(In reply to Sjur Nørstebø Moshagen from comment giellalt/bugzilla-dummy#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å.

@albbas
Copy link
Contributor Author

albbas commented Jul 11, 2018

Comment 12925

Date: 2018-07-11 16:54:02 +0200
From: Børre Gaup <<borre.gaup>>

(In reply to Sjur Nørstebø Moshagen from comment giellalt/bugzilla-dummy#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.

@albbas
Copy link
Contributor Author

albbas commented Jul 11, 2018

Comment 12926

Date: 2018-07-11 16:57:16 +0200
From: Børre Gaup <<borre.gaup>>

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?

@albbas
Copy link
Contributor Author

albbas commented Jul 13, 2018

Comment 12929

Date: 2018-07-13 22:53:50 +0200
From: Trond Trosterud <<trond.trosterud>>

(In reply to Børre Gaup from comment giellalt/bugzilla-dummy#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.

@albbas albbas self-assigned this Sep 10, 2024
@albbas albbas transferred this issue from giellalt/bugzilla-dummy Sep 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant