Agglutination - Revision history

Unhammer at 06:30, 20 October 2014

2014-10-20T06:30:35Z

Unhammer at 06:25, 20 October 2014

2014-10-20T06:25:48Z

Bech: Category:Documentation in English

2012-03-24T11:26:29Z

Category:Documentation in English

Francis Tyers at 12:23, 6 April 2009

2009-04-06T12:23:34Z

Unhammer at 11:38, 31 March 2009

2009-03-31T11:38:45Z

Unhammer at 10:36, 31 March 2009

2009-03-31T10:36:35Z

Francis Tyers at 11:21, 28 March 2009

2009-03-28T11:21:10Z

158.227.114.9 at 09:47, 9 March 2009

2009-03-09T09:47:04Z

Francis Tyers at 07:22, 6 March 2008

2008-03-06T07:22:20Z

Francis Tyers at 22:30, 23 November 2007

2007-11-23T22:30:00Z

← Older revision		Revision as of 06:30, 20 October 2014
Line 1:		Line 1:
			An '''agglutinative''' language in the strict definition will form words by joining together unchangable stems and affixes, where these don't fuse or change form dependent on other affixes. But "agglutinative" is also often used incorrectly as a synonym for the wider category "synthetic", which includes fusional and inflected languages ('''synthetic''' languages have a high morpheme-to-word ratio).

	There some difficulties with agglutinative languages like Quechua.		There some difficulties with agglutinative languages like Quechua.

@@ Line 1: / Line 1: @@
-Both the current Apertium system and the suggested plugin system face another set of difficulties with agglutinative languages like Quechua.
+There some difficulties with agglutinative languages like Quechua.
-==Existing tools==
-* [[SFST]] (see also [[Omorfi]])
-* [[Hunmorph]]
 ==Example==
@@ Line 31: / Line 26: @@
 This sort of complex would actually fit quite well into the current Apertium model, although each paradigm would have a great number of possible members due to the large numbers of suffixes (and this is complicated by the fact that suffix order is variable).  It could also be handled by form generation, again with the drawback that many thousands of possible forms would need to be generated.
+: Paradigms can refer to other paradigms, so this kind of thing should work just fine?
+==Alternatives to lttoolbox==
+Other systems popular for agglutinative languages:
+* [[HFST]]
+* [[SFST]] (see also [[Omorfi]])
+* [[Hunmorph]]
 == See also ==

@@ Line 36: / Line 36: @@
 [[Category:Development]]
 [[Category:Writing dictionaries]]
+[[Category:Documentation in English]]

@@ Line 3: / Line 3: @@
 ==Existing tools==
+* [[SFST]] (see also [[Omorfi]])
+* [[Hunmorph]]
 ==Example==
@@ Line 31: / Line 33: @@
 == See also ==
-[[Prefixes and infixes]]
+* [[Prefixes and infixes]]
 [[Category:Development]]

← Older revision		Revision as of 11:38, 31 March 2009
Line 35:		Line 35:

	[[Category:Development]]		[[Category:Development]]

			[[Category:Writing dictionaries]]

@@ Line 1: / Line 1: @@
-Both the current Apertium system and the suggested plugin system face another set of difficulties with agglutinative languages like Quechua.  For instance:
+Both the current Apertium system and the suggested plugin system face another set of difficulties with agglutinative languages like Quechua.
+==Existing tools==
+==Example==
+For instance:
 :'''wasi''' &mdash; house
@@ Line 22: / Line 29: @@
 This sort of complex would actually fit quite well into the current Apertium model, although each paradigm would have a great number of possible members due to the large numbers of suffixes (and this is complicated by the fact that suffix order is variable).  It could also be handled by form generation, again with the drawback that many thousands of possible forms would need to be generated.
-An alternative method might entail slightly adjusting the way the morphological analyser works.  In this approach, the binary dictionaries would consist only of stems and affixes, and instead of having the morphological analyser read to the end of the orthographic word, it would read only to the end of possible morphological boundaries within the word.  A naïve algorithm for this might be:
-# Start at the first letter of the word.
-# Collect all matches in the stem dictionary where that letter is the first letter.
-# Read the next letter.
-# Discard all items in the matched set that do not have that letter as second letter.
-# Repeat 3 and 4 until the shortest stem that is present in the stem dictionary is found.
-# Put this in a stem array and start using the affix dictionary as well.  Set a new morphological boundary after that letter.
-# For each subsequently-read letter, add matching stems to the stem array (working from the word-beginning), and add matching affixes to a new affix array (working from the previous morphological boundary).
-# Each time an affix match is found, set a new morphological boundary after that letter, and start a new affix array.
-# Add matches to the stem and affix arrays as appropriate until the end of the word.
-If we take an imaginary set of stems '''ku''', '''kuti''', '''kutima''', and an imaginary set of affixes '''-ti''', '''-m''', '''-ana''', '''-ma''', '''-na''', possible segmentations for the imaginary '''kutimana''' would be:
-:'''ku-ti-m-ana'''
-:'''ku-ti-ma-na'''
-:'''kuti-m-ana'''
-:'''kuti-ma-na'''
-:'''kutima-na'''
-These segmentations could be generated by the process above as shown in Table 1 (where '''NM''' = no match, '''M''' = match, and '''->Arr''' = start new array), with the output in Table 2.  Of course, using [http://en.wikipedia.org/wiki/Trie tries] or something similar may be a much more efficient way of doing this than the naïve process above.
-{|class="wikitable"
-|k || NM ||  ||  ||  ||  ||  ||  ||  ||
-|-
-|ku || M || ->Arr||  ||  ||  ||  ||  ||  ||
-|-
-|kut || NM || t || NM ||  ||  ||  ||  ||  ||
-|-
-|kuti || M || ti || M || ->Arr||  ||  ||  ||  ||
-|-
-|kutim || NM || tim || NM || m || M || ->Arr||  ||  ||
-|-
-|kutima || M || tima || NM || ma || M || a || NM || ->Arr (from ma) ||
-|-
-|kutiman || NM || timan || NM || man || NM || an || NM || n || NM
-|-
-|kutimana || NM || timana || NM || mana || NM || ana || M || na || M
-|}
-<center>Table 1 - Example of stem/affix analysis</center>
-{|class="wikitable"
-|ku || -ti || -m || -ana || -na
-|-
-|kuti ||  || -ma ||  ||
-|-
-|kutima ||  ||  ||  ||
-|}
-<center>Table 2 - Output from stem/affix analysis</center>
-Once a matrix of possible segmented forms has been generated for the word, there would then be the need to choose which of these are the ones intended.
-One way of working towards this might be to have a table of possible affix combinations, with a likelihood assigned to each one.  Something like the corpus generated by Kevin Scannell's Crubadán (http://borel.slu.edu/crubadan/index.html) might help here - a corpus is being collected for Bolivian Quechua and Ecuadorean Quichua (though not for Peruvian Quechua, which has more speakers).
-Indeed, another way of approaching the segmentation issue would be to use such a table directly, but working backwards from the end of the orthographical word - this would require the analyser to reverse each word before analysis, and then remove the segment which matched the longest affix sequence in the table.
-Either of these approaches (intra-word segmentation, affix table) would minimise the number of forms produced either by the current Apertium paradigm model, or by the suggested form generation model.  It is likely that these techniques could also be used with other Native American languages.
 [[Category:Development]]

@@ Line 18: / Line 18: @@
 :'''etxe gorria''' la casa roja
 :'''etxe gorri zaharra''' la casa roja y vieja
-:'''etxe gorri zaharrarekin'''  para la casa roja y vieja
+:'''etxe gorri zaharrarekin'''  con la casa roja y vieja
+:'''etxe gorri zaharrarentzat'''  para la casa roja y vieja
 This sort of complex would actually fit quite well into the current Apertium model, although each paradigm would have a great number of possible members due to the large numbers of suffixes (and this is complicated by the fact that suffix order is variable).  It could also be handled by form generation, again with the drawback that many thousands of possible forms would need to be generated.