[voikko] HY:n morfologinen jäsennin omorfi

[Harri Pitkänen]

On Sunday 30 December 2007 11:01, Flammie Pirinen wrote:
> Yksi asia millä nopeutta voinee parantaa on SFST:n Makefilen
> puukottaminen, ainakin omalla läppärilläni omorfi kääntyy nopeammin
> kuin CSC:n corpuksella, vaikkei pitäisi, ehkä vain siksi että vääntelin
> CFLAGSit vähän maltillisemmiksi.

Hyvä huomio. -O4 ei varmaan nykyään paljon auta, laitoin tuohon nyt 
itse -O2:n.

> > - Omorfista löytyi myös muita tapauksia, joissa generoiduissa
> > sanoissa on kolme samaa kirjainta peräkkäin. Ehkä näistäkin osa
> > johtuu tekemistäni muutoksista, mutta osa voi olla myös
> > alkuperäisessä versiossa (jota en nyt ehdi kääntämään uusiksi että
> > voisin asian varmistaa). Esimerkiksi fst-generate -u omorfi.sfsta |
> > grep ttt tuottaa sanan *mitttelevien (mittelevä<N10><pl><gen>).
>
> Tuollainen astevaihtelubugi onkin helposti jäänyt huomaamatta, kun
> toinen muoto 'mitellä<V><act><pcpva><pl><gen>' toimii oikein. Korjasin
> nyt niin että partisiipit  kehitetään samoin johdoksina kuin ilmankin.

Olen ajatellut rakentaa sellaisen testaussysteemin, jossa tuotetaan Omorfista 
sanoja fst-generatella, muutetaan niitä jonkin fuzzerin (vaikkapa zzuf, 
http://sam.zoy.org/zzuf/) avulla ja syötetään nämä sotketut merkkijonot 
takaisin Omorfiin ja voikkospelliin. Sitten katsotaan, löytyykö merkkijonoja 
jotka toinen hyväksyy ja toinen hylkää. Nämä voivat paljastaa bugeja 
jommastakummasta morfologiasta.

> > - Mitä on suunnitelmissa Omorfin jatkokehityksen suhteen? Onko
> > esimerkiksi yhdyssanojen käsittelylle tarkoitus jossain vaiheessa
> > tehdä jotain?
>
> Vaikuttaa siltä että jo yliopistolla suunnitelmia ja kaikenlaisia
> innostuneita ideoita olisi jos jonkin verran, siis ainakin yhdyssanoja
> ja adjektiiveja tutkittaneen, tuloksista saati aikatauluista nyt ei
> ikinä tiedä. Yksi mielenkiintoinen projekti on taas Googlen OpenFST:n
> ujuttaminen SFST:n tilalle, saataisiin painollisia transduktoreja
> ilmaiseksi ja siitä toisenlainen ratkaisu yhdyssanaongelmiin, joka
> monien mielestä olisi parempi. Kaiken kaikkiaan kai jatkokehityksistä
> yliopistolla parhaan kuvan saanee omorfin seminaarisivuista ja ehkä
> muistakin seminaari- yms. sivuista joita on siroteltu sinne tänne.

OpenFST ei sekään ehkä ole Voikon kannalta täysin pois suljettu vaihtoehto, 
koska tuo Apache-lisenssi on yhteensopiva GPL:n version 3 kanssa. Täytyy 
seurailla tilanteen kehittymistä.

> > Voikon kannalta tämä on varmaan se mielenkiintoisin
> > kysymys. Meillähän on jo pari vuotta ollut TODO-listalla mahdollinen
> > malagan korvaaminen SFST:llä, mutta en ole uskaltanut aloittaa tätä
> > projektia kun en oikein tiedä, pystyykö Voikon yhdyssanasääntöjä
> > järkevästi sen avulla toteuttamaan. Olisi toki kätevää, jos voisimme
> > käyttää Omorfia suoraan Voikossa (teknisesti malagan korvaaminen
> > SFST:llä on aika helppo homma), vaikka sanastona luultavasti
> > käyttäisimmekin nykyistä Voikon sanastoa, emme Kotuksen listaa.
>
> Millaisia voikon yhdyssanasäännöt ovat? Olen ymmärtänyt että aika
> pitkälti käsisäädöllä toteutettuja?

Perusperiaatteet on kirjattu Joukahaisen ohjeisiin:
  http://joukahainen.lokalisointi.org/docs/yhdyssanat.html
Tuo dokumentti on valitettavasti varsin suurpiirteinen, ja todellinen toteutus 
Suomi-malagan Voikko-versiossa on monimutkaisempi (tai bugisempi, miten asian 
haluaa nähdä). Lisäksi sanakohtaiset poikkeukset ovat mahdollisia. 
Aikaisemmin (syyskuulle asti) niitä oli jopa morfologian kuvauksessa mukana, 
mutta nykyään kaikki poikkeavaa käyttäytymistä ohjaavat attribuutit ovat 
sanastossa (Joukahaisessa tai Suomi-malagan lex-tiedostoissa).

Poikkeukset tuskin ovat ongelma SFST:lle, mutta tuo säännöstö itsessään voi 
olla. Kukaan ei nimittäin vielä ole todistanut Voikon hyväksymien sanojen 
muodostavan säännöllistä kieltä. Ja vaikka kieli olisikin säännöllinen (tai 
muokattavissa säännölliseksi kohtuullisella vaivalla) niin ei ole ihan 
selvää, että vastaava SFST-toteutus pysyisi järkevän kokoisena, tai että SFST 
kykenisi rakentamaan kyseisen transduktorin järkevässä ajassa.

> > noista ei vielä selvinnyt, että miten tämän projektin hallinta on
> > konkreettisesti ajateltu järjestää. Ilmeisesti vaiheissa niin, että
> > ensin kehitetään HY:n sisällä projektimuotoisesti, ja sitten kun on
> > saatu tuote riittävän hyvään kuntoon, siirrytään perinteiseen
> > avoimeen kehitykseen?
>
> Hankala sanoa tätä, itse olen hyvin juurtunut perinteiseen open source
> -malliin. Gna-projektin tein itse ja sitä voinee pitää omana forkkinaan
> jolla voi pelata miten haluaa. HY:n, ja mahdollisesti vähän kotuksenkin,
> projektiin liittynee aina kaikennäköisiä vaatimuksia
> oikeuksienluovutuslomakkeista ja ties mistä byrokraattisista kuvioista
> lähtien. Itse en oikein noista lakijutuista ja muista jaksa välittää
> niin tuo gna-projekti toimii minulle hyvänä leikkikenttänä, ja sinne
> sitten saa svn-oikeuksia tms. ihan pyytämällä. Tällä hetkellä kun
> omorfi-palikkaan ei kukaan muu ole koskenut eikä kai lähiaikoina
> koskemassa niin projektin hallinta luonnistuu miten päin tahansa,
> luultavasti yliopistolla olisivat tyytyväisiä jos kitwikiä käytettäisiin
> mahdollisimman paljon, mutta toisaalta taas itse olen tottunut hyvin
> bugihallintasovellusten kanssa pelaamiseen.

Minäkin mieluummin raportoisin bugeja tuonne gna-projektiin kuin wikiin. 
Oikeuksien luovuttaminen on myös sellainen asia, johon suhtaudun melko 
varautuneesti. Tuo ehdotettu sopimusmalli
http://forums.csc.fi/kitwiki/pilot/view/KitWiki/OMorFiJointCopyrightAssignment
on muuten kopioitu suoraan OpenOfficen vastaavasta paperista
http://www.openoffice.org/licenses/jca.pdf
Tämän OOo:n version olen allekirjoittanut, koska en usko sen aiheuttavan 
minulle ongelmia. Mutta esimerkiksi OpenOfficen suomennosprojektille JCA on 
ollut todellinen ongelma. Toisaalta kyllä ymmärrän, miksi noita sopimuksia 
tehdään, mutta sisällöltään ne voisivat olla vähän kehittäjille edullisempia 
silloin kun tehdään työtä ilman rahallista korvausta.

Toisaalta en kyllä ole itse SFST:llä tehnyt juuri enempää kuin muutamia pieniä 
kokeiluja, joten en usko että lähiaikoina pystyn vielä mitään hyödyllistä 
tuon projektin eteen tekemään bugiraporttien lisäksi.

Harri