[Håvard Korsvoll]
Obs obs, navneord=substantiv i databasen vår (det var iallefall slik det var tenkt), bruk særnamn eller egennavn for nøkkelord for navn på personer og liknande.
Nettopp. Jeg tenke egennavn men skrev navneord. :)
Eg har no oppdatert filformat.html med ein tabell med oversikt over ordklassar og bøyingsformer. Ta ein titt og sjå om det ser fornuftig ut.
Jeg synes ikke det ser helt fornuftig ut. Her er sitat fra URL:http://no.speling.org./filformat.html:
CLASS: Ordklasse. Ordklassane er: +-------------------------------------------------------------------------+ |Ordklasse |Bøyingsform | |----------------------------+--------------------------------------------| |Substantiv hokjønn (sf) |bunden(b)/ubunden(u) eintal(1)/fleirtal(2) | |----------------------------+--------------------------------------------| |Substantiv hankjønn (sm) |bunden(b)/ubunden(u) eintal(1)/fleirtal(2) | |----------------------------+--------------------------------------------| |Substantiv inkjekjønn/ |bunden(b)/ubunden(u) eintal(1)/fleirtal(2) | |intetkjønn (sn) | |
Klassen bør være substantiv, og kjønn være et annet felt? I tillegg tror jeg det er lurt å en bestemt streng som skal stå i databasefilen, slik at de automatiske systemene som skal behandle dette slipper å da høyde for språklige variasjoner. Dvs. at vi velger enten 'inkjekjønn' eller 'intetkjønn', men ikke tillater begge deler. De som har oppheng i stavemåter får tilpasse sine klienter slik at de viser det brukeren liker å se, mens selve utvekslingsformatet og det som lagres i databasen er entydig. Jeg synes av samme grunn at vi ikke skal tillate både b2 og 'bunden eintall', men velge kun en av dem.
|----------------------------+--------------------------------------------| |Verb (v) |infinitiv presens fortid perf-part imperativ|
Vi bør ikke godta både 'v' og 'Verb', men kun en av dem.
|----------------------------+--------------------------------------------| |Utsagnsord | | |----------------------------+--------------------------------------------| |Tilleggsord | | |----------------------------+--------------------------------------------| |Særnamn (egennavn) | |
Det er vel ikke noe poeng i å bruke hele 'Særnavn (egennavn)' i utvekslingsformatet hvis en av dem er tilstrekkelig? Parantes-biten (eller det andre) bør flyttes til beskrivelses-feltet, og kun et av ordene bør brukes i formatet.
|----------------------------+--------------------------------------------| |Adjektiv (forholdsord) |hokjønn hankjønn inkjekjønn eintal fleirtal | | |bunden ubunden |
Veldig bra å få listet opp navn på alternative bøyningsformer. Det bør vel gjøres for flere ord. :)
|----------------------------+--------------------------------------------| |Biord | | |----------------------------+--------------------------------------------| |Stadord (Stedord) | | |----------------------------+--------------------------------------------| |Talord | | |----------------------------+--------------------------------------------| |Konjunksjon (Bindeord) | | |----------------------------+--------------------------------------------| |Utropsord | | +-------------------------------------------------------------------------+
Legg merke til at vi ikkje reknar særnamn som substantiv.
Greit for meg. :)
Viss eit ord tilhøyrer fleire klassar, så kan du føre det opp med komma mellom. Til dømes ordet hoppe som både er ein hest og verbet å hoppe: CLASS: Substantiv hokjønn, Verb
Dette tror jeg er en dårlig ide. Slike ord bør føres opp to ganger, en gang som substantiv, og en gang som verb. De to oppføringene vil jo ha ulik informasjon om bøyning i CONJUGATION-feltet, og for maskinell behandling blir det vanskelig å vite hvilken av de to klassene hver conjugation hører til.
Ein kan også nytte orda i parentes, så for dømet over er det ekvivalent å bruke: CLASS: sf, v
Og dette tror jeg er en tilsvarende dårlig ide, da det øker kompleksiteten i programvaren som skal lese og forstå databasen.
Elles vil vel eit felt for frekvensinformasjon vere ønskeleg i databasen. Jacob, er det mulig å få til?
Jeg tror frekvensinformasjon bør være en separat database, da det jo vil være forskjellig for både språk, tidsperiode og fagfelt.