Analüsaatori JSONi väljundis puuduvad sisendis olnud lisaväljad

[alumae]

Analüsaator etana kaotab ära sisendis olnud lisaväljad, nagu id ja tag allolevas näites.

Sisend:

{
  "documents":[
     {
        "paragraphs":[
           {
              "sentences":[
                 {
                    "words":[
                       {
                          "text":"Tere"
                       }
                    ],
                    "id":"1",
                    "tag":"foo"
                 }
              ]
           }
        ]
     }
   ]     
}

Väljund:

{
    {
        "sentences": [
            {
                "words": [
                    {
                        "analysis": [
                            {
                                "clitic": "",
                                "ending": "0",
                                "form": "",
                                "partofspeech": "I",
                                "root": "tere"
                            },
                            {
                                "clitic": "",
                                "ending": "0",
                                "form": "sg g",
                                "partofspeech": "S",
                                "root": "tere"
                            },
                            {
                                "clitic": "",
                                "ending": "0",
                                "form": "sg n",
                                "partofspeech": "S",
                                "root": "tere"
                            }
                        ],
                        "text": "Tere"
                    }
                ]
            }
        ]
    }
}

Oodatav väljund (nagu spetsifikatsioonis):

{
  {
    "sentences": [
      {
        "words": [
          {
            "analysis": [
              {
                "clitic": "",
                "ending": "0",
                "form": "",
                "partofspeech": "I",
                "root": "tere"
              },
              {
                "clitic": "",
                "ending": "0",
                "form": "sg g",
                "partofspeech": "S",
                "root": "tere"
              },
              {
                "clitic": "",
                "ending": "0",
                "form": "sg n",
                "partofspeech": "S",
                "root": "tere"
              }
            ],
            "text": "Tere"
          }
        ],
        "id":"1",
        "tag":"foo"           
      }
    ]
  }
}

[alumae]

Märkasin veel, et ka struktuur läheb kaduma, s.t. etana väljastab ainult sentences osa. Ootaks, et väljund oleks sama baas-struktuuriga, mis sisend:

{
  "documents": [
    {
      "paragraphs": [
        {
          "sentences": [
            {
              "words": [
                {
                  "analysis": [
                    {
                      "clitic": "",
                      "ending": "0",
                      "form": "",
                      "partofspeech": "I",
                      "root": "tere"
                    },
                    {
                      "clitic": "",
                      "ending": "0",
                      "form": "sg g",
                      "partofspeech": "S",
                      "root": "tere"
                    },
                    {
                      "clitic": "",
                      "ending": "0",
                      "form": "sg n",
                      "partofspeech": "S",
                      "root": "tere"
                    }
                  ],
                  "text": "Tere"
                }
              ],
              "id": "1",
              "tag": "foo"
            }
          ]
        }
      ]
    }
  ]
}

[PRR24]

Siin on kaks asja koos.

1. analüsaatorile antud sisend ei vasta analüsaatori ootustele. Sisendisse oodatakse vaid ühte dokumenti, mis on jaotatud lõikudeks ja lauseteks. Selgelt on näha, et see osa vajab paremat dokumentatsiooni. Esialgu palun kasutage test.json-eid refereeringuks.
2. analüüsi väljund jaotatakse täielikult ringi. Näiteks on võimalik, et sisendsõnade ja väljundsõnade hulk erineb. Tarkvara käitumine tundmatute väärtustega sisendfailis ei ole defineeritud.

[alumae]

Spetsifikatsioonis (Lisa B) on kirjas, et JSON dokumendi struktuur peaks säilima ja lisaväljad peaks ka säilima.

Sel viisil on morfoanalüsaatori kasutajal lihtne saata läbi analüsaatori mitmesuguse lisainfoga varustatud teksti (näiteks kommentaarid, identifikaatorid), ilma et peaks neid hakkama pärast analüsaatori tööd uuesti õigesse kohta tagasi toppima.

Ühe dokumendi piirang tundub samuti liiga karm. Mul on tekstikorpuses praegu üle miljoni dokumendi, tahaks, et nende koos töötlemine oleks võimalikult hõlbus (OK, kõigi nende JSONiks tegemine ja saadud JSONI parsimine vist poleks eriti kiire nagunii, aga see on juba kasutaja probleem).

[PRR24]

Tänan ettepaneku eest. Analüsaator ja süntesaator ei järgi spetsifikatsiooni lisa B (Sisendi ja valjundi soovituslik formaat), vaid kasutas seda soovitusena. Näiteks väljastab analüsaator rohkem infot, kui soovituslik formaat kirjeldab. Samas ei ole realiseeritud mitme-dokumendi-tuge ega ka tundmatuid välju.

Tänapäevases multi-core maailmas soovitan mitme-dokumendi analüüsil forkida protsesse üle dokumentide ja käivitada analüüse paralleelselt.

Lisaväljade soov on arusaadav, ent see on puudu üheltpoolt jsoni parseri piiratuse ja teiselt poolt sõnade ringipaigutamise tõttu. Head ideed võimeka streamiva jsoni parseri osas on teretulnud.

[alumae]

Millisel juhul sõnad "ringi paigutatakse"? See võiks olla dokumenteeritud.

[PRR24]

Kokku paigutatakse sõnad, mis moodustavad ühe terviku, ent ei ole eraldi võttes eesti keeles korrektsed sõnad. Näiteks New ja York analüüsitakse kokku üheks linnanimeks. Konkreetne näide on ka ka näitefailis (test.json).

[kristiank]

Kas see tähendab, et läbi analüsaatori ei saa saata mitmesuguse lisainfoga varustatud teksti (näiteks kommentaarid, identifikaatorid) nagu alumae kirjeldas? See tundub väga raske piiranguna kasutajale, kui peab eelnevad (teised) analüüsi resultaadid pärast morfanalüüsi tagasi "pookima".

[PRR24]

Jah, hetkeversiooni cmdline utiliitide kasutamisel peaks arvestama, et tundmatute lisaväljadega käitumine ei ole defineeritud. Need võivad jõuda väljundisse või võivad kaduda.

[Kaljurand]

Minu meelest oleks selgem, kui vaikimisi sellist sõnade kokku paigutamist ei toimuks, st analüsaator eeldaks, et sisend on juba kasutaja poolt tokeniseeritud. (Mida ta ongi, sellise JSON faili puhul.) Praegu on imelik olukord, kus text="New York" jääb analüüsimata, aga text="New", text="York" saab analüüsitud. Vt ka: https://github.com/Kaljurand/vabamorf/blob/a9bea58b1c68b7309221735461ca036248ed3a79/doc/json/etana/ex2_analyze_phonetic.json

[alumae]

Ma saan aru, et Vabamorf tahab tegelikult ise teksti tokeniseerida. Sel juhul oleks üheks lahenduseks see, kui sisend koosneks lausetest, millele analüüsi käigus lisatakse sõnade kaupa analüüsid. Siis oleks lihtne ka lisavälju ja struktuuri säilitada. See ei võimaldaks ka kasutajal saada illusiooni, et sisendi ja väljundi sõnade vahel on alati üks-ühene vastavus.

Näiteks sisend:

{
  "foo": [
    {
      "paragraphs": [
        {
          "sentences": [
            {
              "text": "See on New York",
              "fii" : 2
            }
          ]
        }
      ]
    }
  ]
}

Ja väljund:

{
  "foo": [
    {
      "paragraphs": [
        {
          "sentences": [
            {
              "text": "See on New York",
              "fii": 2,
              "words": [
                {
                  "analysis": [
                    {
                      "clitic": "",
                      "ending": "0",
                      "form": "sg n",
                      "partofspeech": "P",
                      "root": "s<ee"
                    }
                  ],
                  "text": "See"
                },
                {
                  "analysis": [
                    {
                      "clitic": "",
                      "ending": "0",
                      "form": "b",
                      "partofspeech": "V",
                      "root": "ole"
                    },
                    {
                      "clitic": "",
                      "ending": "0",
                      "form": "vad",
                      "partofspeech": "V",
                      "root": "ole"
                    }
                  ],
                  "text": "on"
                },
                {
                  "analysis": [
                    {
                      "clitic": "",
                      "ending": "0",
                      "form": "sg n",
                      "partofspeech": "H",
                      "root": "New Y<ork"
                    }
                  ],
                  "text": "New York"
                }
              }
            ]
          }
        ]
      }
    ]
  }

[PRR24]

Lause kaupa sisend ei tundu väga mõistlik, sest lausestamiseks on üldjuhul vaja dokument juba tokeniseerida. Morfi jaoks laused uuesti kokku liita, et neid siis taas tükeldama hakata, tundub ebaefektiivne. Lisaks oleks Vabamorfi tehtav tükeldamine tõenäoliselt erinev kui esmatükeldaja tehtu.

Üsna lihtsalt on saavutatav panna morf tööle nii, et ta aktsepteeriks New ja Yorki eraldi sõnadena (nagu speller seda teeb), aga sel juhul kaoks (minu arvates kasulik) näide, kuidas mitmesõnaliste väljendite analüüsi Vabamorfiga teha, mis ei ole ka nagu hea.

Püüan mõelda selle peale, äkki tuleb mõni hea idee.

[alumae]

Minu teada tehakse tavaliselt lausestamine enne tokeniseerimist. Mina teen ka nii. Lause tundub olevat lihtsalt väikseim tükk, mida Vabamorf resegmenteerimata vastu võtab ja lausestamise eripäradest tekkivad lahknevused analüüsis ei tohiks ka kuigi suured olla.

Aga jah, pigem ma hääletaks, et New ja York oleks eraldi sõnad ja Vabamorf ei retokeniseeriks.

[PRR24]

Analüüsisin erinevaid variante ja jõudsin järeldusele, et

• Mitme-sõna kokkupaneku toe eemaldamine vähendaks tarkvara funktsionaalsust ja kasvõi näitena on selle toe hoidmine põhjendatud. Ehk et seda praegu ei muuda.
• jsonist lisa-andmete eemaldamisel programmi poolt ei ole põhjendatud. Uus versioon jätab lisaandmed alles. Sõnade kokkupanekul säilitatakse esimese sõna lisaandmed.

[Kaljurand]

Ma hääletan ka selle poolt, et vaikimisi ei toimuks (re)tokeniseerimist (mis vähemalt hetkel pole kuigi selgelt defineeritud operatsioon: kas kokku pannakse ainult naabreid? kas sõnu tehaks vajadusel ka pooleks? jne). Lihtsam ülesandepüstitus lihtsustaks ka näiterakendust (etana.cpp), kus hetkel on funktsioonid nagu StrctKomadLahku ja TrimRight. (Ma ei tea, mida nad teevad aga nimede põhjal arvan, et tokeniseerivad. ;))

Sisend analüsaatorile on ju ikkagi sõna, mitte sõnade jada või sõna, mille küljes võib olla koma. Näiterakenduse kasutajale ei tohiks jääda muljet, et sõna kontekst mõjutab sõna analüüsi. (See moment tuleb sisse alles ühestamise puhul.)

[merisiga]

Morf analüüs ja sõnestamine on algselt olnud minu kapsamaa. Alguses arvasin, et morfi asi on ainult puhaste sõnadega tegelda, s.t. et sõnestamine pole morfi asi. Seejärel märkasin, et mitmesõnaliste nimede puhul on hästi loomulik nad kokku võtta (Buenos Aires, Rio de Janeiro) ja et punktuatsioon on mõnikord sõne lahutamatu osa, nt. järgarvude ja lühendite puhul, aga ka lühendatud sõnadel nagu "puu- ja köögiviljad". Sidekriips on üks eriti tüütu asi: Ida-Virumaa, TASS-ile, kohe-läheb-jamaks, 1-0 jne. Mulle näis, et sõna lemma tundmisest on sõnestamisel kasu. Seejärel hakkasime ühestamise jaoks punktuatsiooni sõnadest lahku tõstma. (Mis pole üldse iseenesestmõistetav, vaid lihtsalt tol ajal kehtinud tava, mille aluseks oli inglise keel, kus morfi ju polegi.) Praegu ma ei teagi, kas ja kuidas tuleks sõnestamist käsitleda. Näiteks New York on mitmeti samasugune nagu Juhan Juurikas: käänamisel muutub ainult viimane sõna... Samas, netikeele sõnestamisel, kui tuleb sõnaga kokkukleepunud emotikone tuvastada, siis tundub jälle, et oleks hea teada, kas mingi tähejada on sõna või ei... Kokkuvõttes: ma oleks ettevaatlik, enne kui otsustaks, kuidas sõnestamine ja morf ja üldse tekstitasemel töötlus omavahel seotud peaksid olema.

[kristiank]

Kui vaadata uuemaid märgendamisprintsiipe, kus on võimalik mitu erinevat kihti (nt ISO LAF, linguistic analysis framework), siis oleks ehk hea, kui vaadata morfmärgendamist mitmetasemeliselt. Sellisel puhul oleks Vabamorfi oma sõnestamine ainult üks kiht, ja olgu seda kas-või vaikimisi. Aga teisalt saaks kreatiivsem kasutaja ise määrata sõnestamise-üksustamise tasandi nii nagu ise tahab ja näeb otstarbekas, ja Vabamorf peaks oma parima tegema sellise sisendi analüüsimiseks (ja mitte sisendit ümberüksustama ehk retokeniseerida).

See võimaldaks mitmeid paralleelseid seotusi või seoseid eri tekstitasemete vahel.

[merisiga]

Ma ei oska seda kuidagi kommenteerida... Minu arvates saab morfi mitmel eri moel kasutada ja see, kas ja kuidas ortograafia tavadega seotud asjad (sõnestamine) on sõltumatud keelest (morf), on väljakutsuja asi (nii läbi mõelda kui ka realiseerida).

[PRR24]

Eemaldasin etana uusimast versioonist lausete ringistruktureerimise. Analüsaator vaatleb nüüd sõnu kontekstiväliselt, speller vaatleb endiselt konteksti (ent ei struktureeri lauset ringi).

[merisiga]

Okei. Sel juhul see githubi versioon ei tööta täpselt samal moel kui see, mis on kasutusel ülikooli sisevõrgus. Loodetavasti see kedagi ei häiri; võib-olla isegi rõõmustab.

[PRR24]

Teema sai kaetud ja rohkem kommentaare ei tundu olevat, panen teema kinni.