The encoder should be able to work in two modes:

• Preserving as much information as possible, even if the resulting tag is a new (unexpected by the designers of the tagset) combination of feature values.
• Strictly keeping the original set of possible tags, by forcing selected features to compatible values. This should be default, if available.

Although this requirement has been known since the very beginning of this work, no driver so far implements strict encoding. It would almost double the work needed to write the encode() function and I have not needed the strict conversions so far.

The process of strict encoding could be automated using the list() function of the driver. A service function could decode every possible tag (as listed by list()) and build a graph of feature values. The strict encoding would correspond to a path through the graph. Every node in the graph would correspond to a partially encoded tag. The set of edges leaving the node would be pruned so as not to allow any unexpected combination of features.

The graph would not be constructed in full. Such a process would be too costly. Instead, every feature would be given a numeric priority, and there would be a total ordering of the features according to their priorities. The encoding process would always consider the features with higher priority first, thus the graph would be a tree with as many leaves as there are tags in the tagset.

How will the strict encoding look in practice? A service function will read the feature tree and a set of feature values to be encoded. The function will traverse the tree and adjust the feature values to match a tag from the list. Then the normal encode() function of the driver will be called. A prerequisite is that the driver keeps the condition encode(decode(x))=x. This has not been tested so far but the drivers indeed should conform to it.

2 druhy striktního kódování:

• Opravdu striktní zajistí, že na výstupu se neobjeví značka, která není na seznamu.
• Mírnější přístup tohle nepožaduje, ale pomůže překódovat hodnoty, které se v cílové sadě nevyskytují. Např. pokud cílová sada nezná duál, uděláme z něj plurál, aby cílový ovladač nemusel testovat i duál (resp. on by měl, ale tohle je naše ochrana proti nedbalosti jeho autora). Nicméně nebudeme hlídat, že cílová sada třeba nerozlišuje číslo u přídavných jmen a plurál u nich vůbec nečeká (ale je schopna ho zakódovat).

• Check whether decode() sets only known features.
• Check whether decode() sets features only to known values.
• Unset features:
  • Return list of unset features.
  • Fill one or all unset features with default values.
  • Fill one or all unset features with arrays of all possible values.
• Query feature value: a shared function detects array and if it is array, searches it for a given value.
• Společná funkce: před encode(): máme-li list(), pravděpodobně umíme doplnit povinné neznámé vlastnosti na základě známých. (To nám výrazně usnadní strict encoding.)

• Přejmenovat compdeg = norm na pos (pozitiv).
• Přejmenovat number=plu na plur?
• Sloučit vlastnosti verbform a mood.
• Udělat z poss opět jenom subpos?
• Přece jen přidat kategorie zájmen? Dánové mají: demonstrative, indefinite, interrogative/relative, personal, possessive, reciprocal. Zrušit podkategorie wh?
• Ze subpos=clit udělat samostatnou vlastnost, aby se usnadnil dotaz, zda je zájmeno osobní.
• Udělat tu dotazovací funkci (viz výše)! Kromě technické práce s poli ještě přidat hierarchii hodnot: když se někdo ptá na “rel” a já vidím “wh”, odkývám mu to!
• Obdobně pro funkci decode() udělat servisní funkci, která nabídne hodnoty pro nevyplněné vlastnosti na základě jiných vyplněných (např. ukazovací zájmeno implikuje určitost a atributivnost). Musí se to ale pořádně promyslet - např. pokud jazyk nemá compdeg=abs, je pro něj asi nejlepší sup, jak ale víme, že nemá abs?
• Udělat přehled častých prvků, které nemají vlastní slovní druh. Např. jak se řeší částice označující infinitiv.
• Jemněji roztřídit interpunkci. Dánové mají vlastní interpunkci, potom symboly (+, $), potom podivnosti, které my ani za interpunkci nepovažujeme. “U-21”.
• Předělat binární vlastnosti na hodnoty “yes” a “no”.
• Přejmenovat compdeg na degree.
• Příčestí by mělo mít vlastní slovní druh. S tím, že některé sady ho řadí pod sloveso a jiné pod přídavné jméno, jsou jenom problémy.
• Subjektform a objektform u švédských zájmen asi není samostatná vlastnost! Mělo by se to prohlásit za pády (nominativ a akuzativ)!
• Členy a zájmena by se možná vůbec měly rozlišit jinak. Na nejvyšší úrovni by se rozlišovala substantivnost/atributivnost, pak teprve zda to má být raději člen nebo zájmeno. Případně osobní a přivlastňovací zájmena by mohla být zvlášť už na nejvyšší úrovni, protože ta se s žádnými členy plést nebudou.
• Classification of coordinative conjunctions: copulative, adversative etc. Example: sv::mamba.

• cs::pdt - reimplement “type L” pronouns as collective pronouns (introduced due to Bulgarian)

Poznámky o časové náročnosti konverze morfologických značek

Ruský treebank (nejen značky, ale vůbec převod formátu):
12:36

Arabské značky (Otovy i Buckwalterovy, ještě bez Intersetu, 22.3.2006):
4:45+1+1:40 = 7:25

České značky PDT (přes 4000 značek; jádro Intersetu vzniklo jako vedlejší produkt, když jsem dělal tohle)
asi 2 dny, tedy dejme tomu 18 hodin

Dánské značky DDT/Parole (144 značek s košatým popisem)
asi 7 hodin

Švédské značky Mamba (48 značek)
asi 3 hodiny

Penn Treebank (36 značek)
asi 3 hodiny, ale tady jsem to ještě neměřil, takže to je jen hrubý zpětný odhad

Hajičovy švédské značky
0:32 - tady zjevně chybí úplná statistika

Arabské značky CoNLL
4:33+5:19+3:16 = 13:08

České značky PDT (CoNLL verze? Nebo to jsou jen opravy, když jsem začal ovladače testovat?)
1:44+3:20+6:05 = 11:09

Bulharské značky CoNLL
0:20+1:00+0:26+5:44+2:00+6:15+1:20+0:46+1:26+2:30+0:48 = 22:35
(ale u bulharštiny jsem se dost natrápil s jevy, které do té doby nebyly v intersetu podchycené)

Anglické značky CoNLL
0:48 - možná tady chybí statistika, ale možná taky ne, protože stačilo upravit existující ovladač Penn Treebanku, ne?

Žádné z výše uvedených převodů (tedy vše napsané před říjnem 2007) ještě neměly k dispozici chytré funkce pro nahrazování nepovolených hodnot.