From Apertium
Revision as of 10:57, 26 September 2010 by Unhammer (talk | contribs) (→‎Analysis)
Jump to navigation Jump to search

Some languages in Indo-European, particularly Germanic languages and Proto-Indo-Iranian languages like Sanskrit, make long compound words with low frequency that are unlikely to be found in dictionaries. Typically for any "normal" noun, there can be around 10—100 compound nouns which inflect in exactly the same way (at least for Afrikaans).

  • Afrikaans: infrastruktuurontwikkelingsplan, infrastruktuur+ontwikkelings+plan ("infrastructure development plan"), (cf. personeelverminderingsprosedure, "personnel protection procedure")
  • Dutch : "hulpagina" (help page), "woordbetekenis" (meaning of a word), "inwonertal" (number of inhabitants)
  • German: Kontaktlinsenverträglichkeitstest, Kontakt+linsen+verträglichkeits+test ("contact-lens compatibility test")
  • Danish: Kontaktlinsevæske, Kontaktlinse+væske ("contact-lens liquid")
  • Sanskrit: विद्या + आतुर = विद्यातुर , vidyā + ātur = vidyātur ("eager to gain knowledge")
  • Esperanto: Vikitraduko, Vikio+traduko (Wiki translation). Tradukoservo (==tradukservo), traduko+servo (translation service). Poŝtelefono, poŝa+telefono (pocket phone). Bonkvalita, bona+kvalita (good quality). Diaro, dio+aro (god collection),

There should be some method of attempting to resolve unknown compound words into their constituent parts.

See also the bug report

Differences in left-parts and right-parts of compounds

In Germanic languages at least (possibly most others too?), compounds typically only inflect in the last part:

  • mobiltelefon = cell phone
  • mobiltelefonar = cell phones
  • NOT: *mobilartelefon ("cells phone")

The way this is solved in the current compound implementation in lttoolbox-java is to have one symbol for word forms that may be a non-final part of a compund, compound-only-L, and one for forms that may end a compound, compound-R:

<pardef n="ep__n">
  <e>       <p><l>ane</l>       <r><s n="n"/><s n="m"/><s n="pl"/><s n="def"/><s n="compound-R"/></r></p></e>
  <e>       <p><l>ar</l>        <r><s n="n"/><s n="m"/><s n="pl"/><s n="ind"/><s n="compound-R"/></r></p></e>
  <e>       <p><l>en</l>        <r><s n="n"/><s n="m"/><s n="sg"/><s n="def"/><s n="compound-R"/></r></p></e>
  <e>       <p><l></l>          <r><s n="n"/><s n="m"/><s n="sg"/><s n="ind"/><s n="compound-R"/></r></p></e>
  <e r="LR"><p><l></l>          <r><s n="n"/><s n="m"/><s n="sg"/><s n="ind"/><s n="compound-only-L"/></r></p></e>
<e lm="mobil"><i>mobil</i><par n="ep__n"/></e>
<e lm="telefon"><i>telefon</i><par n="ep__n"/></e>

The "only" in here compound-only-L means that this form may only appear as part of a compound, not alone. The reason for this is explained below.

Note: the compound symbols do not appear in the output, they only signal to lt-proc-j that this form may appear in compounds.


Many compounds have (epenthetics), letters which connect the two words but perhaps only occur in compounds:

  • kransekake => krans+e+kake ≈ 'ring cake'
  • ungdomsfyll => ungdom+s+fyll = 'youth drunkenness'

The epenthetics do not have a meaning in themselves, and can typically only appear between compound parts (not when the word is by itself).

Epenthetic analysis

We solve the analysis in lttoolbox-java by the following type of paradigm:

<pardef n="krans__n">
  <e>       <p><l>ane</l>       <r><s n="n"/><s n="m"/><s n="pl"/><s n="def"/><s n="compound-R"/></r></p></e>
  <e>       <p><l>ar</l>        <r><s n="n"/><s n="m"/><s n="pl"/><s n="ind"/><s n="compound-R"/></r></p></e>
  <e>       <p><l>en</l>        <r><s n="n"/><s n="m"/><s n="sg"/><s n="def"/><s n="compound-R"/></r></p></e>
  <e>       <p><l></l>          <r><s n="n"/><s n="m"/><s n="sg"/><s n="ind"/><s n="compound-R"/></r></p></e>
  <e r="LR"><p><l>e</l>         <r><s n="n"/><s n="m"/><s n="sg"/><s n="ind"/><s n="compound-only-L"/></r></p></e>

As noted above, we have a difference between

  • compound-R meaning "this might be the right part of a compound, but might also stand alone", and
  • compound-only-L meaning "this might be the left part of a compound, but can't stand alone".

The above paradigm specifies that "kranse" may only appear as a left-part of a compound, it can't stand alone.

Objection 1: why not have just compound-L and compound-R, meaning "might be the left/right part or might stand alone"? Because you're never going to see "kakee" on its own, right?
Answer: True, we won't see "kakee" on its own, but "kranse" is a verb with another meaning, and tagging the noun as "compound-L" and allowing it to be analysed on its own would lead to unnecessary ambiguity.
Objection 2: Hey, you've got compound-only-L but not compound-L and not compund-only-R. You can't analyse Klingon!
Answer: This isn't even implemented yet. Once two symbols are implemented and working, we can think about adding the rest of the possibilites.
Objection 3: You really should have some sort of compound-both symbol for your <l/> entry instead of one with compound-only-L and one with compound-R, it'll mess up your tagger.
Answer: These symbols are removed in the output.

Epenthetic generation

When generating a compound, apertium-nn-nb at least simply adds the tag <cmp> to the left-part. The generator can then tell whether the left-part should have an epenthetic or not.

Example: after transfer we might have ^krans<n><m><sg><ind><cmp>$^kake<n><f><sg><ind>$. Then the generator just needs a pardef for krans that has the line

  <e r="RL"><p><l>e</l>         <r><s n="n"/><s n="m"/><s n="sg"/><s n="ind"/><s n="cmp"/></r></p></e>

in order to output the correct kransekake (epenthetic e).

If the output from transfer is ^gulrot<n><m><sg><ind><cmp>$^kake<n><f><sg><ind>$ ("carrot cake"), and the generator has

  <e r="RL"><p><l></l>         <r><s n="n"/><s n="m"/><s n="sg"/><s n="ind"/><s n="cmp"/></r></p></e>

in the pardef for gulrot, we get the correct gulrotkake (no epenthetic).

Meaning of epenthetics

The epenthetic has no meaning in itself, but if you can have the same word with or without an epenthetic, it might signal a difference. Compare:

  • sjefsekretær = 'chief of secretaries' (Norwegian)
  • sjefssekretær = 'the boss's secretary'
  • gjestfri = 'hospitable'
  • gjestefri = 'guest free' (as in "guest free zone")

(gjestfri would typically be listed in the dictionary, gjestefri being compositional.)

Solution: add these to your dictionaries :-)

Outstanding questions

Where would compound processing go in the pipeline? Presumably after initial analysis? e.g. in between lt-proc and apertium-tagger.
This is essentially what happens in lttoolbox-java, lt-proc-j first tries to analyse as a regular word, and only if it is unknown does it try analysing it as a compound. Of course, it could be run as its own module if we just xslt-proc the compoundable paths into their own separate analyser.

Proposed algorithms



input: ^*infrastruktuurontwikkelingsplan$

  1. Read word from left to right.
  2. Take the shortest match first from the dictionaries, e.g. infrastruktuurontwikkelingsplan,
    1. Read i-n-f-r-a-s-t-r-u-k-t-u-u-r (add, because no words have +o)
    2. Read o-n-t-w-i-k-k-e-l-i-n-g-s (add, because no words have +p)
    3. Read p-l-a-n
  3. Output in order.

output: ^infrastruktuur<n><sg>$ ^ontwikkeling<n><pl>$ ^plan<n><sg>$

This won't work for Esperanto and other languages where the root without word ending is never seen (correct in Esperanto is infrastruktur+evolu+plano, not infrastrukturo+evoluo+plano)
This means these entries have to be in the dictionaries, we could treat it the same way as epenthetics. Say that we have a marker on (or inside) <e> that says that this is <e> may be the left side of a compound. Then for Esperanto, you'd have to add, to your pardef or whatever:
   <e (left-compoundable)>              <p><l>evolu</l> <r>evoluo</r></p></e>
   <e (non-compoundable, regular entry)><p><l>evoluo</l><r>evoluo</r></p></e>
However, the reason we need Left-to-right longest-match is that the baseline method might not find all possible matches, e.g. if the input was orddeling ("word splitting"), the correct analysis being ord+deling, but the dictionary contained the form orddel ("word part"), the baseline method would analyse orddel, read ing which is not a word, and give up. The method below, however, would find ord+deling.

Left-to-right longest-match

input: ^*infrastruktuurontwikkelingsplan$

  1. Read word from left to right.
  2. Take the longest match first from the dictionaries, e.g. infrastruktuurontwikkelingsplan,
  3. While not found:
    1. Read infrastruktuurontwikkelingsplan
    2. Read infrastruktuurontwikkelingspla
    3. Read infrastruktuurontwikkelingspl
    4. ...
  4. When a word is found, e.g. "infrastruktuur", remove it from the string, put it in the output queue, and start the process again with ontwikkelingsplan.
  5. Output each item from the output queue in order.

output: ^infrastruktuur<n><sg>$ ^ontwikkeling<n><pl>$ ^plan<n><sg>$

This is implemented in lttoolbox-java.


If we have translated a string of input words from English to Afrikaans and now want to compound the ones that can be compounded, we have a problem that instead of:


we have:

infrastruktuur ontwikkeling plan

One way of resolving this would be to compile a wordlist (without morphological info) into a tree, and then scan the tree as we scan the output, concatenating words where they appear in the wordlist. Wordlists are substantially more numerous than morphological resources so it would be quite cheap. In order to avoid false-positives, we could just set a length requirement of something like 9 characters or more.

Isn't this just a problem of removing the spaces in transfer, like nn-nb does?

Further reading