cldf-clts / clts-legacy

Cross-Linguistic Transcription Systems
Apache License 2.0
4 stars 3 forks source link

nasal+click-cluster currently defined as "nasalized" #68

Closed LinguList closed 6 years ago

LinguList commented 6 years ago

but we should handle them as clusters (see discussion here: #66).

LinguList commented 6 years ago

Update by @afehn:

nasal clicks like <n!> are commonly not treated as clusters, but as complex stop segments. The status of postoralized clicks <ng!> is less clear; one might consider treating them as prenasalised stops, i.e., +<g!>.

So these need to be defined, currently, I'd be inclined to add "nasal-click" as "manner", to distinguish it from the rest.

tresoldi commented 6 years ago

A good and consistent solution, and in line with IPA sound descriptors.

And @afehn 's suggestion on postoralized clicks seem very good in terms of using what is available (one might dispute when the vellum actually moves during the click production/release, but it is a far too specific problem and we should definitely follow the intuition of a specialist).

tresoldi commented 6 years ago

Some more material on clicks: http://u.osu.edu/miller.5592/files/2016/01/TBC_018.final-207vef2.pdf

afehn commented 6 years ago

Not sure I am replying correctly using the list, so if I did something wrong, please let me know.

I already quoted this paper in my section on cluster analysis. Miller is a supporter of unit analysis, but discusses both frameworks and a variety of other stuff. Worth a read, but not universally accepted and possibly problematic for some computational analyses dealing with sound changes click > non-click.

On 28/12/17 14:03, Tiago Tresoldi wrote:

Some more material on clicks: http://u.osu.edu/miller.5592/files/2016/01/TBC_018.final-207vef2.pdf

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cldf/clts/issues/68#issuecomment-354293141, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ0eTHHMyDOHdUFO2R46cW8tPxQihN4Kks5tE5-ogaJpZM4RKVft.

tresoldi commented 6 years ago

Just to confirm: @afehn , the email reply is automatically posted to GitHub.

As for Miller, my intention was to include the refence here, especially given that the full chapter was made public by the author (I stumbled upon it while working on my system). But even as a non-specialist on clicks (or phonology, for that matter), Nakagawa's description seem more appropriate for CLTS and featural systems in general, despite Miller using features to explain airstream contour very well.

I am still completely unsure about which approach is better suited for historical linguistics, i.e., which one is more parsimonious (and even "elegant") in terms of explains sound changes involving clicks, especially "clickgenesis".

afehn commented 6 years ago

@tiago, thanks for the confirmation!

Working on sound changes involving clicks in the Khoe-Kwadi family, my gut feeling is that all of them can be much better explained using the cluster, rather than the unit analysis. However, we should keep in mind that southern African Khoisan is actually three unrelated families, so it is entirely possible that certain clicks should be analyzed as units in some languages, and as clusters in others. Miller's main argument against the cluster analysis is that not all C-offset that appear in N//ng, the language she mostly worked on, also appear as independent non-click C in the consonant inventory. She further notes that there is no language with obstruent-obstruent clusters that does not also have obstruent-sonorant clusters (which would be the case in southern African Khoisan if we apply cluster analysis).

I am not sure we need to explain "click genesis" as a historical process. There was one single example of assumed click-genesis in the Khoe family, which involved a correspondence between Kalahari Khoe /ts'/ and Khoekhoe /ǀqx'/. Honken (don't remember the reference) assumed that this was a case of click genesis in Khoekhoe. However, now that we have data from the higher-order relative Kwadi (almost extinct, but two rememberers alive and kicking+Westphal's recordings), we know that the proto-sound was the [+click] form, probably an ejective click /ǀ'/. So for an unknown reason, Proto-Kalahari Khoe lost a subset of its dental ejective clicks and replaced them with a non-click ejective affricate /ts'/.

Clicks in Bantu were almost certainly borrowed, so no need to explain "click genesis" from a historical linguistics perspective here either. For now, I would stick with the cluster analysis for all of southern African Khoisan, but would be very happy to shift to unit analysis if it works better for individual languages or families.

On 28/12/17 14:20, Tiago Tresoldi wrote:

Just to confirm: @afehn https://github.com/afehn , the email reply is automatically posted to GitHub.

As for Miller, my intention was to include the refence here, especially given that the full chapter was made public by the author (I stumbled upon it while working on my system). But even as a non-specialist on clicks (or phonology, for that matter), Nakagawa's description seem more appropriate for CLTS and featural systems in general, despite Miller using features to explain airstream contour very well.

I am still completely unsure about which approach is better suited for historical linguistics, i.e., which one is more parsimonious (and even "elegant") in terms of explains sound changes involving clicks, especially "clickgenesis".

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cldf/clts/issues/68#issuecomment-354295405, or mute the thread https://github.com/notifications/unsubscribe-auth/AQ0eTBEtwzZMVT8R0JiKGOl2pguE8McYks5tE6OYgaJpZM4RKVft.

tresoldi commented 6 years ago

I can see the point of both theories, but the more I play with data and make strange sounds with my own mouth, the more a cluster analysis of clicks seems appropriate for this line of work. In fact, even the understandable objections of Miller on the isolated occurrence of the constituent segments becomes less relevant with our different goals, not only following what I believe is Güldemann's reasoning, but also as a consequence of the difference between sounds and segments that I am adopting. The fact that clicks are borrowable also supports the theory, even when considering that the borrowing likely took place among bilingual speakers at first (am I right?).

As for "click genesis", I was using it as an extreme example of sound change. By the way, I am a bit intrigued: do we know about some general tendencies for sound changes involving clicks? I always assumed that a somewhat common pattern of manner might be stop <---> ejective/implosive <---> clicks, and that clicks could colour neighbouring vowels due to place of articulation, but from the few examples I see this does not hold very well. Is my memory betraying me or you once mentioned that there is an attested shift, a group of words in a Khoisan language that was recorded with stops in the 19th century but which are pronounced with clicks today?

And to Mattis, sorry for somewhat hijacking the GitHub issue. :)

LinguList commented 6 years ago

No problem, my main concern is to have a consistent system which is as productive as possible, i.e., where I have to define as few parameters (features, base sounds) as possible, while generating as many of those weird sounds as possible. The main argument for clusters is again productivity: if you look, what people propose as "sound inventories", including click-clusters, it is obvious that we'd have to come up with a really complicated system like Phoible where we explicitly model each sound with the features, in order to get only a few of the things we can expect to be found in the data out there. For this reasons, I will always prefer a more productive/generative handling for CLTS, and if anybody feels like those things should be better modeled differently to handle sound change (which is anyway not the case for the moment, as no useful algos to handle sound change based on features exist so far), they can explicitly define this kind of data as "transcription data", proposing their feature system, etc. Otherwise, this project will die before it has even started.

LinguList commented 6 years ago
one might consider treating them as prenasalised stops, i.e., +<g!>.

If they are pre-nasalized, I'll change the symbol in representation, so ŋg! becomes n-superscript g!, and ŋg! becomes an alias.

tresoldi commented 6 years ago

I agree it is better, this notation seems to be more common and it better represents what goes on in phonetic terms. The non-subscript alternative might make more sense from an articulatory point-of-view (that is what I do in my system, but the grapheme representation nonetheless uses the superscript), but as far as I remember only Ladefoged uses it among the most known authors.

Just to make sure, all other graphemes that could use IPA superscripts are using them in the default, with non-subscript as alias, correct? Just for consistency.

Em 2 de jan de 2018 10:32 AM, "Johann-Mattis List" notifications@github.com escreveu:

one might consider treating them as prenasalised stops, i.e., +<g!>.

If they are pre-nasalized, I'll change the symbol in representation, so ŋg! becomes n-superscript g!, and ŋg! becomes an alias.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cldf/clts/issues/68#issuecomment-354757361, or mute the thread https://github.com/notifications/unsubscribe-auth/AAar96zPuUQd_1GuIWwiWs_TFsR3oDzsks5tGiHTgaJpZM4RKVft .

LinguList commented 6 years ago

We have discussed this here before.

tresoldi commented 6 years ago

Good, same reasoning -- and a mental note for myself, read all other issues.

Em 2 de jan de 2018 10:42 AM, "Johann-Mattis List" notifications@github.com escreveu:

We have discussed this here https://github.com/cldf/clts/issues/41 before.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cldf/clts/issues/68#issuecomment-354758899, or mute the thread https://github.com/notifications/unsubscribe-auth/AAar9wgH-klCOfL8evNfWP9xnrE57FAIks5tGiRDgaJpZM4RKVft .