Lexical selection provides a way to deal with what you do when a single word in one language translates to more than one word in another language. The formalism used in Apertium allows you to choose translations based on the lemma and/or part of speech of surrounding words. In the Apertium pipeline, it modifies the stream after lexical transfer and before structural transfer.
Lexical selection rules are in the
apertium-abc-xyz.abc-xyz.lrx file in your language pair. You can find information about and examples of the formalism on the Apertium wiki: constraint-based lexical selection module, how to get started with lexical selection rules.
In short, you use the surrounding words (with morphological analyses) as context to decide which translation is the correct one.
An example that might need lexical selection is the following:
- yard (a unit of length)
- yard (an enclosed area)
What's different about these words? Spelling, pronunciation, part of speech? What [different] contexts might each occur in?
Can we decide which translation is right from the surrounding words?
- (kir) кол → (eng) hand; arm
- (kir) күн → (eng) sun; day
- (kir) жаш → (eng) age; tear (eye water)
- (kir) бир → (eng) one; a/an
- (eng) paper → (kir) кагаз (material); доклад (written work)
- (eng) horse → (kir) ат (for riding, working); жылкы (for herding, eating)
- (eng) sister → (kir) сиңди (younger, of female); карындаш (younger, of male); эже (older)
What do we do with examples like this?
- (eng) tear → (kir) жаш (eye water); айыр (rip)
- (eng) plant → (kir) өсүмдүк (growing thing); отургуз (put in the ground to grow)
- (kir) өч → (eng) revenge; be extinguished
- (kir) кыл → (eng) strand of hair; string (of instrument); do; make
The structure of lrx files
lrx file is written in xml. It consists of a list of rules surrounded by <rules>
...</rules>. Each <rule>
...<rule> block contains some combination of <match><select ... /></match> blocks and <match .../> blocks. <match ...> tags can contain attributes like
tags="". Multiple <match .../> blocks may be included within <or>
...</or> so that multiple rules don't have to be written in cases of multiple matching criteria.
Here is an example to try in class:
- Көзүнөн жаш акты.
- Анын жашын билбейм.
You may wish to make a "default" translation and then some more specific rules. Because of what appears currently be a bug in the lexical selection code, the more less specific rule (the "default") may override the more specific rules. Currently, the best way to do this seems to be with weights—i.e., give a lower weight to the default rule than to the specific ones (e.g., by just giving a weight below 1 to the default rule). You will also want to go through your
modes.xml and replace
lrx-proc -m so that the lexical selection module actually uses these weights.
Due on Friday of the 10th week of class (this semester, Friday, April 6th, 2018, by the end of the day (midnight))
- Make a new page on the wiki,
Language1_and_Language2/Lexical_selection, linking to it from the main page for your language pair, and adding it to the category Category:Sp18_LexicalSelection.
- Add two sections,
abc → xyzand
xyz → abc.
- In each section, add the two cases of ambiguous translations you came up with in the previous assignment.
- For each ambiguous translation you work on, determine some generalisation for how to decide which translation is right, documenting these generalisations on the wiki. It may be that there is no generalisation that can be made for a given lexical selection problem; in this case, choose a default form to select and find some other one-to-many translation that can be solved with lexical selection. You must have at least one [mostly] solvable problem per translation direction.
- Add example sentences or phrases that can be tested for each destination of the word with the ambiguous translation (minimum: two sentences).
- In your
lrxfile, set up any necessary default translations, and at least one set of lexical selection rules for one solvable lexical selection problem. Add the example sentences/phrases in a comment before the relevant rule.
- Commit your code.