How does tone evolve in Tukanoan?

[nataliacp]

Given the latest discussions on how to represent tone, if tone should be encoded with the vowel and nasality in one symbol etc, I would like to put forward a question that I think is at the heart of all this. How do you think tone evolves in Tukanoan languages? From my very little background on tonal languages and tone, I have understood that tone may affect sound change (justifying e.g. treating it as one entity with the vowel), but not always. I have also the impression that tone can be considered as a supra-segmental feature that has its own evolution, e.g. being able to jump from one syllable to a nearby one. I don't know what of these if any hold true for Tukanoan. But I think this is the kind of stuff that will guide us into what kind of represenation we need. Maybe after all it is better to separate tone after each syllable (or bimoraic thing, sorry for my terminology) represented by a capital letter as you have done or by a number.

[LinguList]

Yes, I am explicitly d'accord with this. Why? Since things that are suprasegmental should be represented suprasegmental, and we can hadnle them easily in LingPy by exactly aligning tone for tone in alignments, but what you need is that it is displayed at the beginning or the end of a syllabic unit, so that alignments look nice. And if it's independent of the vowel, one should not mix information here. Tone is an important piece of evidence in reconstruction, but I think that the tone-on-vowel practice may often prevent people to actually perceive it as independent thing.

[levmichael]

Regarding your question, @nataliacp's, yes, tone is clearly suprasegmental in Tukanoan languages, and it has in part evolved in the manner you sketch, with tones and tonal patterns developing independently of the segmental material on which they occur. There is also clear evidence linking the evolution of segmental and tonal elements, as in the case of the development of lexical low tone in Mai through the loss of glottal stop. @amaliaskilton and @thiagochacon are probably more knowledgeable than I am about the specifics here, but the evolution of tone is an area where I feel we still have a great deal to learn in Tukanoan.

The idea that @nataliacp and @LinguList raise, of very clearly symbolically decoupling the segmental and tonal representations is an interesting one. If it seems like something we want to do at some stage, this can presumably be automated, no? For the quasi-phonemic representation we would need a tone symbol after (or otherwise associated with) each mora -- i.e. after each vowel, given our conclusions regarding long vowels and diphthongs. There will be some complications posed by languages that exhibit elements that have associated with them tonal melodies that are partially realized on adjacent elements, but nothing that we couldn't deal with, I feel.

[nataliacp]

I discussed this with Seb at some length today and he thinks he can automate it if he is given enough info about the "realm of possibilities". We were mainly working on maihiki today so my observations come from this language. Since there is this bimoraic entity that we think is something in between two syllables and a diphthong (correct me if I am wrong, that's what I got from the discussion till now), isn't this the entity that carries the tone? So, my idea was to mark the tone after each group of 2 vowels (or one vowel when we have cases like that). Seb and I talked about letters and numbers and we think that the best solution visually is a superscript number (I think Mattis uses something similar). From what I saw in Maihiki, it seems we are ok with 4 things: high, low, rising and falling.

[levmichael]

The question of the prosodic size of the entity for which tone is marked depends on the level of representation. At the quasi-phonemic level -- which is the level at which we are working -- the tone would be marked for each mora (i.e. vowel). At the phonemic level in Máíhɨ̃ki (and in general in the family), you're right that the tonal specification occurs at the morpheme level (which are indeed mostly bimoraic if they are roots), with docking and spreading rules producing the surface distribution of tones.

Superscripts could work nicely -- they are easy to read -- but I'm not sure if other considerations militate against them. I would vastly prefer letters to numbers myself, though. We should only need two tones, I believe, H and L -- at least thats' true for the Tukanoan languages I'm familiar with. The other Tukanoanists can let us know if that's not enough.

[amaliaskilton]

@nataliacp on your original question, the only case in which it is clear (to me) that a sound change took a segmental feature and produced a tone is low tone tonogenesis in Mai. There, proto Western Tukanoan glottal stops were lost and yielded a lexical low tone on the preceding TBU (= mora), as Lev mentioned. However, H and zero tones in Mai and Koreguaje (closely related and not extremely different in tone) do not seem to correspond to segmental features in the other languages, eastern or western. So in general, I would tentatively say that tone probably did change with relatively little influence from segmental phonology, and when it was influenced by segmental phonology the influence came from glottal stop and not from voicing or aspiration as in Asian languages.

On Wednesday, February 17, 2016, levmichael notifications@github.com wrote:

The question of the prosodic size of the entity for which tone is marked depends on the level of representation. At the quasi-phonemic level -- which is the level at which we are working -- the tone would be marked for each mora (i.e. vowel). At the phonemic level in Máíhɨ̃ki (and in general in the family), you're right that the tonal specification occurs at the morpheme level (which are indeed mostly bimoraic if they are roots), with docking and spreading rules producing the surface distribution of tones.

Superscripts could work nicely -- they are easy to read -- but I'm not sure if other considerations militate against them. I would vastly prefer letters to numbers myself, though. We should only need two tones, I believe, H and L -- at least thats' true for the Tukanoan languages I'm familiar with. The other Tukanoanists can let us know if that's not enough.

— Reply to this email directly or view it on GitHub https://github.com/digling/tukano-project/issues/22#issuecomment-185282507 .

[thiagochacon]

I want to address this issue and the one about tukano tone in more detail later, but given the discussion about the level of represenration (phonological or ohonetic) and the form of representation (letters or diacritics) I would like to make a suggestion. Clearly we want the two level of representations: phonological and phonetic. but we do not have both for all the languages. My suggestion is that we allow some lanagues to have tones only innthe phonological or phonetic forms, but does not spend to much (now) on normalizing the data on tones now. As for how to represent tones, I prefer letters to. In phontetic terms it should be one tone letter per vowel. Phonologically one unserlying tone or tone melody per morpheme or word. Tones could be represented in a separate field since they are suprasegmentals. For phonetic tones, there could be a function in Reflex and Linpy which aligns one letter tone per each vowel (or two.letter.tone per vowel if a contour tone). Whaat you guys think?

-------- Mensagem original --------

De: amaliaskilton notifications@github.com

Data: 17/02/2016 11:39 (GMT-05:00)

Para: digling/tukano-project tukano-project@noreply.github.com

Cc: thiagochacon thiago_chacon@hotmail.com

Assunto: Re: [tukano-project] How does tone evolve in Tukanoan? (#22)

@nataliacp on your original question, the only case in which it is clear (to me) that a sound change took a segmental feature and produced a tone is low tone tonogenesis in Mai. There, proto Western Tukanoan glottal stops were lost and yielded a lexical low tone on the preceding TBU (= mora), as Lev mentioned. However, H and zero tones in Mai and Koreguaje (closely related and not extremely different in tone) do not seem to correspond to segmental features in the other languages, eastern or western. So in general, I would tentatively say that tone probably did change with relatively little influence from segmental phonology, and when it was influenced by segmental phonology the influence came from glottal stop and not from voicing or aspiration as in Asian languages. On Wednesday, February 17, 2016, levmichael notifications@github.com wrote: > The question of the prosodic size of the entity for which tone is marked > depends on the level of representation. At the quasi-phonemic level -- > which is the level at which we are working -- the tone would be marked for > each mora (i.e. vowel). At the phonemic level in Máíhɨ̃ki (and in general > in the family), you're right that the tonal specification occurs at the > morpheme level (which are indeed mostly bimoraic if they are roots), with > docking and spreading rules producing the surface distribution of tones. > > Superscripts could work nicely -- they are easy to read -- but I'm not > sure if other considerations militate against them. I would vastly prefer > letters to numbers myself, though. We should only need two tones, I > believe, H and L -- at least thats' true for the Tukanoan languages I'm > familiar with. The other Tukanoanists can let us know if that's not enough. > > — > Reply to this email directly or view it on GitHub > https://github.com/digling/tukano-project/issues/22#issuecomment-185282507 > . --- Reply to this email directly or view it on GitHub: https://github.com/digling/tukano-project/issues/22#issuecomment-185289232

[LinguList]

I'd propose to stick to the Chinese annotatioin framework for tones, using digits and thinking of them like a melody on 5 different scales:

35 means rising from the mid to the top, 51 means falling, contours are written as 214, and flat tones can be written as 3 indicating shorter duration, or 33 indicating longer duration.

Tone letters should follow after the syllable, which is important if there are closed syllables, but equivalent to after the vowel otherwise.

Using such a system, there won't be any problem of aligning data.

[levmichael]

Tukanoan languages only have two tone levels (H and L) and none of the ones I'm familiar with have contour tones (in the sense of having multiple tones on a single TBU), so, fwiw, I think the Chinese annotation framework is a bit of overkill. I saw above that @thiagochacon likewise voted for letters, and I think this will be the general feeling of the Tukanoanists (though if anyone feels differently, they should definitely speak up). So, to be explicit, I'd like to reiterate the counterproposal for the quasiphonemic level: H or L after every vowel -- to which we'll need to add some annotational mechanism for floating tones realized on adjacent morphemes (this will require some discussion).

[nataliacp]

so, I don't think we can do superscripts capital letters (superscript numbers are unicode characters, while letters no from what I understand) and I personally think that having H and L all over the forms is very distracting. Since there are only two levels, I think it is very easy to just write 1 and 2 in superscript and there is no room for confusion and one can read the form normally as well.

On Thu, Feb 18, 2016 at 5:22 PM, levmichael notifications@github.com wrote:

Tukanoan languages only have two tone levels (H and L) and none of the ones I'm familiar with have contour tones (in the sense of having multiple tones on a single TBU), so, fwiw, I think the Chinese annotation framework is a bit of overkill. I saw above that @thiagochacon https://github.com/thiagochacon likewise voted for letters, and I think this will be the general feeling of the Tukanoanists (though if anyone feels differently, they should definitely speak up). So, to be explicit, I'd like to reiterate the counterproposal for the quasiphonemic level: H or L after every vowel -- to which we'll need to add some annotational mechanism for floating tones realized on adjacent morphemes (this will require some discussion).

— Reply to this email directly or view it on GitHub https://github.com/digling/tukano-project/issues/22#issuecomment-185800155 .

[LinguList]

You have all of them superscript letters in unicode now, even H and L, but I also definitely vote for superscripts and in the end of syllables for those trivial cases (both 1 and 2 or H and L fine with me). For the others with spreading tone, let's keep thinking.

[nataliacp]

ah ok, good to know! no problem with H and L then! Can somebody explain to me the spreading/floating tone issue so i can think of possible solutions reflex-wise? is it the case that phonemically the tone belongs to syllable/vowel 1 and it is realized along with syllable/vowel 2?

On Thu, Feb 18, 2016 at 5:42 PM, Johann-Mattis List < notifications@github.com> wrote:

You have all of them superscript letters in unicode now, even H and L, but I also definitely vote for superscripts and in the end of syllables for those trivial cases (both 1 and 2 or H and L fine with me). For the others with spreading tone, let's keep thinking.

— Reply to this email directly or view it on GitHub https://github.com/digling/tukano-project/issues/22#issuecomment-185808063 .

[levmichael]

Oh, yes, if it wasn't clear, I'm also in favor of superscripts

[amaliaskilton]

The floating tone situation is more common in ET than in the languages I am familiar with, but yes, you have a tone that is underlyingly associated with TBU 1 but which is realized on TBU 2, i.e. just to the left or the right of the TBU that has the tone underlyingly. An example from Elsa's work is the causative morpheme -Hò in Tatuyo: the morph is itself L but it induces an H on the preceding TBU. Floating tones are therefore a case where (even though there are no contour tones on a single TBU) you can have multiple tones associated with a single TBU.

On Thu, Feb 18, 2016 at 8:56 AM, Natalia Chousou-Polydouri < notifications@github.com> wrote:

ah ok, good to know! no problem with H and L then! Can somebody explain to me the spreading/floating tone issue so i can think of possible solutions reflex-wise? is it the case that phonemically the tone belongs to syllable/vowel 1 and it is realized along with syllable/vowel 2?

On Thu, Feb 18, 2016 at 5:42 PM, Johann-Mattis List < notifications@github.com> wrote:

You have all of them superscript letters in unicode now, even H and L, but I also definitely vote for superscripts and in the end of syllables for those trivial cases (both 1 and 2 or H and L fine with me). For the others with spreading tone, let's keep thinking.

— Reply to this email directly or view it on GitHub < https://github.com/digling/tukano-project/issues/22#issuecomment-185808063

.

— Reply to this email directly or view it on GitHub https://github.com/digling/tukano-project/issues/22#issuecomment-185814389 .

[thiagochacon]

Tone letters is what we need. Contour tones exist in Tukano and Barasana. Floating tones in several ET languages.

I don't really like the idea of a tone letter superscrit to a vowel (or syllable for languages like Kubeo where there is no tone contrast in VV sequences). First because it is really distracting when analying the segmental data. Second, because I am afraid this may impose some difficulties when using the data in other contexts, such as publications and the like, where we would prefer to have IPA in the phonetic representations.

So I insist on my suggestion to have tone letters for underlying tones in a separate field and IPA for phonetic tones. Pleas let me know why this wouldn't be an option and whether my concern with tone letters superscripts is not a problem for using the data in different contexts.

[nataliacp]

I think there is one question that should be our main guide in how to represent tone and at which level. This is a comparative-historical project, so we want a representation of the data that gives us most access to how things evolve. If we largely believe that tone and segments are different entities evolutionarily (that sometimes interact), then they should not be considered one entity. In terms of alignments, the most straightforward way I can imagine is to have separate columns for the segment and the tone.

I should mention here, that in Reflex there is a special field for tone, a completely separate one where somebody could write things as H H L or HL H etc. Filling in such a field may be useful to search all words of a specific tonal melody, but I don't think this should be the only place tone is stored in the database in my opinion, as it is really isolated from the segments.

In terms of ease of representation now, we have many options and tons of fields. Nothing prevents us from having a phonemic representation with the underlying tones, a phonetic one with all the surface tones noted as stress marks and another one as superscripts. I consider this decision secondary. In a publication, one can select this or the other field to be displayed for the same entry, depending on what he or she is trying to show. But on the level of analysis we need comparable data with the maximum ability to give us useful phylogenetic characters (in the broad sense of phylogenetic, good indicators of history).

Now, on the issue of what level of representation we need. It seems to me that the analysis of tone in Tukano with the 3 underlying tones etc is highly abstract. It may well be that it is very useful for the description of the language synchronically, but this doesn't mean that it is revealing diacrhonically. is there evidence that those 3 underlying tones are historical entities, are "things" that are passed down in the whole family? or are they a system that emerges in Tukano? I am afraid that by building a lot of underlying structure in our representations we may complicate them to a degree that it is not comparable across languages. I agree that clear morphophonological rules, such as the case of the causative suffix, shouldn't be represented, but the Tukano case seems different to me.

My understanding up to now is that the alignment algorithm of Mattis will consider á as one thing and à as another thing, while in most cases we don't want that. Back in reflex, diacritics are coded separately in any case, so tones would be detachable manually (or in a separate automatic operation that would need to be developed). But since Mattis's algorithm handles tone already as a separate thing (when encoded in superscript), it seems really convoluted to me to treat is as unified in edictor and then as separate in reflex.

Finally, about deferring the regularization of tone marking to the future, i am really against this solution. After importing things in a database and building all the superstructure that is cognate sets and alignments it is a pain to modify representations. One shortcut that I could imagine though is to align just segments in order to recognize cognate sets and code them for presence absence for the purposes of the upcoming talk and then figure out the tone and a bunch of other things and do the real importation then (of course accompanied by a new round of alignments on the newest representations to take advantage of the automation).

[LinguList]

My understanding up to now is that the alignment algorithm of Mattis will consider á as one thing and à as another thing, while in most cases we don't want that. Back in reflex, diacritics are coded separately in any case, so tones would be detachable manually (or in a separate automatic operation that would need to be developed). But since Mattis's algorithm handles tone already as a separate thing (when encoded in superscript), it seems really convoluted to me to treat is as unified in edictor and then as separate in reflex.

The alignment algorithm doesn't care, since it uses sound classes, but if you feed it tone, it converts to tone classes, and there it cares. So if you just use the diachritics, it will be fine, but I won't be happy, since I want to map all symbols to CLPA, a new project I follow up, where I try to give explicit phonetic (as best as possible) definitions of sounds in data. As a sub-dialect of IPA, this will be a system that breaks down variation and would ideally allow for cross-linguistic comparison, since it is a standard that can be easily checked against a dataset, while the "ipa-ness" of a given transcription is not possible to be checked, since there are too many variants. For this reason, I would prefer a tonal representation that is independent of vowels, and also conforms to what is regularly and often used for tone representation, which is why I brought up Chinese numerical markers. For clarifiation on the CLPA idea, you can have a look here: http://github.com/lingulist/clpa/, the list I'm currently using is here: https://github.com/LinguList/clpa/blob/master/clpa/clpa.test.tsv, but this is all in the begiinning, and descriptions of symbols will changed. Anyway, this tool would ideally become a phonetic equivalent to the concepticon, and we really need something like that in linguistics in order to make sure we can globally compare patterns.

[levmichael]

I agree with @nataliacp that deferring the decision on how to deal with tone is a bad idea, so I think it makes sense to reach a decision now. I can definitely see the advantages for our work for having a representation where tone is separate from vowels, e.g. as represented with following tone letters (whether superscripted or not), and occupying their own slot for alignment purposes, so I in general support this idea.

It seems to me that @thiagochacon's concerns about the legibility of decomposed representation are reasonable, so I wonder if would be possible for the data to live in decomposed form in the field for the quasi-phonemic representation, but for a composed representation to be automatically generated from this and sent to another field for those who would prefer to view it that way. Another alternative would be in the alignment view to be able to 'hide' the tones with some kind of toggle, if they are getting distracting for segmental alignment purposes. These or other similar solutions would require a little work by Seb, but the would allow us to have the best of both worlds.

As for level of representation for the tones, I think it is useful to remember that we are mainly concerned with the quasi-phonemic level, and so the tricky questions surrounding the more abstract phonological representation of tones can, I think, be legitimately evaded. And for the quasi-phonemic level, I think the representation is fairly straightforward: each vowel is associated with its surface (quasi-phonemic) tone -- for most languages just H or L.

[thiagochacon]

I also think that the decision must be made now but I am skeptical whether we will be able to implement it in time though.

Enviado do meu smartphone Samsung Galaxy.

-------- Mensagem original --------

De: levmichael notifications@github.com

Data: 20/02/2016 09:41 (GMT-05:00)

Para: digling/tukano-project tukano-project@noreply.github.com

Cc: thiagochacon thiago_chacon@hotmail.com

Assunto: Re: [tukano-project] How does tone evolve in Tukanoan? (#22)

I agree with @nataliacp that deferring the decision on how to deal with tone is a bad idea, so I think it makes sense to reach a decision now. I can definitely see the advantages for our work for having a representation where tone is separate from vowels, e.g. as represented with following tone letters (whether superscripted or not), and occupying their own slot for alignment purposes, so I in general support this idea.

It seems to me that @thiagochacon's concerns about the legibility of decomposed representation are reasonable, so I wonder if would be possible for the data to live in decomposed form in the field for the quasi-phonemic representation, but for a composed representation to be automatically generated from this and sent to another field for those who would prefer to view it that way. Another alternative would be in the alignment view to be able to 'hide' the tones with some kind of toggle, if they are getting distracting for segmental alignment purposes. These or other similar solutions would require a little work by Seb, but the would allow us to have the best of both worlds.

As for level of representation for the tones, I think it is useful to remember that we are mainly concerned with the quasi-phonemic level, and so the tricky questions surrounding the more abstract phonological representation of tones can, I think, be legitimately evaded. And for the quasi-phonemic level, I think the representation is fairly straightforward: each vowel is associated with its surface (quasi-phonemic) tone -- for most languages just H or L.

---

Reply to this email directly or view it on GitHub: https://github.com/digling/tukano-project/issues/22#issuecomment-186619223

[thiagochacon]

We need to represent floating tones at least in one level of representation. It could be in the PHM and not in the FUN but I would rather have it on both though

Enviado do meu smartphone Samsung Galaxy.

-------- Mensagem original --------

De: levmichael notifications@github.com

Data: 20/02/2016 09:41 (GMT-05:00)

Para: digling/tukano-project tukano-project@noreply.github.com

Cc: thiagochacon thiago_chacon@hotmail.com

Assunto: Re: [tukano-project] How does tone evolve in Tukanoan? (#22)

I agree with @nataliacp that deferring the decision on how to deal with tone is a bad idea, so I think it makes sense to reach a decision now. I can definitely see the advantages for our work for having a representation where tone is separate from vowels, e.g. as represented with following tone letters (whether superscripted or not), and occupying their own slot for alignment purposes, so I in general support this idea.

It seems to me that @thiagochacon's concerns about the legibility of decomposed representation are reasonable, so I wonder if would be possible for the data to live in decomposed form in the field for the quasi-phonemic representation, but for a composed representation to be automatically generated from this and sent to another field for those who would prefer to view it that way. Another alternative would be in the alignment view to be able to 'hide' the tones with some kind of toggle, if they are getting distracting for segmental alignment purposes. These or other similar solutions would require a little work by Seb, but the would allow us to have the best of both worlds.

As for level of representation for the tones, I think it is useful to remember that we are mainly concerned with the quasi-phonemic level, and so the tricky questions surrounding the more abstract phonological representation of tones can, I think, be legitimately evaded. And for the quasi-phonemic level, I think the representation is fairly straightforward: each vowel is associated with its surface (quasi-phonemic) tone -- for most languages just H or L.

---

Reply to this email directly or view it on GitHub: https://github.com/digling/tukano-project/issues/22#issuecomment-186619223

[levmichael]

We need to represent floating tones at least in one level of representation. It could be in the PHM and not in the FUN but I would rather have it on both though

Yeah, I agree. I suppose what I said about the quasi-phonemic representation sounded like I wasn't interested in having floating tones represented at that level -- but I do!

[nataliacp]

I think that what Lev suggested is feasible. What I still don't fully understand is what a representation of a floating tone looks like. In Amalia's example for the causative, I assume that the floating tone is the "hidden" one that is realized on the root when the causative is attached, but, this being a lexical dataset makes me wonder if and how we want to have morphemes in isolation represented. Are there other cases where floating tones are involved that are not morphological and what do they look like there?

[levmichael]

Floating tones are always associated with a root or affix in Tukanoan languages, and are realized on preceding or following roots or affixes. When tones are marked with diacritics, as the typically are in the representations linguists use, the floating tones are often depicted as tone letters preceding or following the root or morpheme, depending on whether they are realized on preceding or following segmental material, respectively.

[gomezimb]

Sorry but I was in a family meeting and couldn’t read/answer the storm of messages you sent since the 11th. I could read them in the train yesterday and I think the most urgent point is TONES. Let me remind you that before we started entering the data we made some decisions concerning tones. We had two levels of representation (I don’t know if they correspond to your PHM, FUN … I’m a bit lost):

• only lexical tones in the underlying // representation: /gúu/ has an underlying H; representing it on the first mora doesn’t mean that it is linked to that mora underlyingly but that, by the association convention, that is the initial linking done in derivations; the quasi-phonemic $gúú$ indicates the spreading to the right
• if an underlying tone remains unassociated, it is marked by H or L as in Barasana (BAS) where a root such as $wìí$ ‘longhouse, house’ is HL but, given that the first mora is extrametrical, the H associates to the second mora and the L remains floating: we decided to represent it as /wiíL/; the TAT causative example Hò- given by Amalia is another good example
• it is true that tones in Tukanoan languages are associated with roots and affixes, with one exception: BAS has tonal prefixes without segmental support
• representing the Utones in // and the surface tones in $$ means that we have a good knowledge and info of each system which is not the case (see KAR, TUY and the Huber& Reed if you decide to import it) concerning the Tatuyo (TAT) and Barasana (BAS) lists that I started and we completed with Amalia, we followed those decisions
• concerning an autosegmental representation in a special row it is a good idea but we will not be able to fill the info for all languages
• Why are we changing these conventions? As Lev wrote, for a global profile of the family we just need two levels: H, L. There are no contour tones in BAS (Thiago!): a contour tone results of the association of two level tones to a single tone bearing unit (TBU, mora) giving a raising or a falling tone; the only ET language that allows it is Tukano (TUK). We must interpret Ramirez ‘^’ and ‘´’ tones to be able to compare them with the rest (his low tone is not phonological)
• ^ is a H linked to the 2nd mora followed by L; H spreads to the left ũyû 'avocado' [ṹɲṹ] [ṹɲṹrè], a spreading blocked by a glottal feature (a glottal stop or the preaspiration of a voiceless C2) in which case V1 receives a default L: petâ 'port' [pèʰtá] [pèʰtárè] ; TUK is the clearest ET case of interaction between segments and tones
• ´ is a LH sequence that, in a bimoraic root=word associates to the 2nd mora and gives a raising tone (suggesting that the 1st one is extra metrical (thanks Amalia for this idea)) [pèʰtǎ] ’tocandira’; in longer words there is a tonal shift to the right [pèʰtàré], shift blocked by a glottal stop
• a possibility is to interpret ^ as HL and ´ as LH.

[thiagochacon]

Anything decided on here? I understood that we will have $$ quasi-phonemic representation with surface tones on each mora plus a floating tone. What was not clear to me is what symbols we will use to write the tones: IPA, tone letters or numbers?

I understand there are many issue regarding the computational aspect of it, so I would like to insist to have tones represented in a separate field, one letter tone for each mora separataded by a space.

Thus a word lie /kàdá L/ would have the folowing representations: L H ( L ), where parenthesis would indicate a floating tone.

Now, I am concerned that we will spend a lot (a lot!) of time fixing the representation of tones from whatever we decided (Elsa's data seems the most consistent one, of ocurse, regarding underlying and surface tones). In my case, I just can't provide surface tones for every word in Kubeo and Tukano. The underlying tones (or Ramirez very good! orthographic notations) are there, and surface tones are predictable from them.

So may be a consistent tone notation and a tone comparative project could e postponed at this point.

[levmichael]

Just to make sure that I understand what you're proposing, @thiagochacon, are you proposing that we have two representations? One in which the segmental material and tones are combined, e.g. $kaLdaH(L)$ (setting aside the issues of superscripts and numbers vs. letters), and a second which would consist just of the tonal melody, e.g. LH(L)?

[krstenzel]

Hi All,

I have joined the Github thing but didn’t see any posts with examples related to our discussion the other day. I thought someone was going to summarize the suggestions with examples for us to refer to. I’m really quite unsure as to what entries are supposed to look like at this point.

We had a full set of guidelines for the original entries which my student and I tried to follow the best we could (I still have to check the entries she did to make sure that those rules were followed.) Am I right that now I will have to go back and change every entry? Help! I’m confused.

Kris

From: levmichael [mailto:notifications@github.com] Sent: Wednesday, February 24, 2016 11:22 AM To: digling/tukano-project Subject: Re: [tukano-project] How does tone evolve in Tukanoan? (#22)

Just to make sure that I understand what you're proposing, @thiagochacon https://github.com/thiagochacon , are you proposing that we have two representations? One in which the segmental material and tones are combined, e.g. $kaLdaH(L)$ (setting aside the issues of superscripts and numbers vs. letters), and a second which would consist just of the tonal melody, e.g. LH(L)?

— Reply to this email directly or view it on GitHub https://github.com/digling/tukano-project/issues/22#issuecomment-188274203 .

[levmichael]

@krstenzel, you're right to be confused :). There is still much to be decided on the tonal representation, but this is the thread that we'll be doing that on. Watch this space for more!

[krstenzel]

OK, I’ll wait to see what’s decided. I still have checking to do, but since time is so tight for me, I would rather do the checking and make changes all at once rather than have to do it several times.

From: levmichael [mailto:notifications@github.com] Sent: Wednesday, February 24, 2016 11:38 AM To: digling/tukano-project Cc: krstenzel Subject: Re: [tukano-project] How does tone evolve in Tukanoan? (#22)

@krstenzel https://github.com/krstenzel , you're right to be confused :). There is still much to be decided on the tonal representation, but this is the thread that we'll be doing that on. Watch this space for more!

— Reply to this email directly or view it on GitHub https://github.com/digling/tukano-project/issues/22#issuecomment-188281551 .

[levmichael]

Agreed -- it makes sense to do both at the same time.

[nataliacp]

I was supposed to do the summary and restart the discussion, but I was completely exhausted today and ended up staying at home. I am sorry. I will get to this either tonight or tomorrow morning.

On Wed, Feb 24, 2016 at 3:44 PM, levmichael notifications@github.com wrote:

Agreed -- it makes sense to do both at the same time.

— Reply to this email directly or view it on GitHub https://github.com/digling/tukano-project/issues/22#issuecomment-188283868 .

[nataliacp]

ok, here are some of the things that came out from the skype meeting and what I think we still need to address in order to reach a clear decision on tone representation. Things on which I think everybody agrees:

1. We want tone to be a different entity (and here I mean historical entity) than the vowels for the alignments. This approach reflects that tone often evolves independently of vowel quality, but gives us also the opportunity to treat tone and vowel quality as "context" of the other. (just a side note here, I think you all would like to consider nasality as part of the vowel quality, right?)
2. We agree that we want surface tones to be represented, as opposed to more abstract representations of tonal systems.
3. Thiago mentioned at some point that he would like a purely tonal field containing the tonal melody only. This is already implemented in Reflex, as well as some "primitive" scripts to extract it automatically from one of the form fields. So, this is definitely doable as things stand.

Please, speak up if the things above are not accurate!

Now, things we still need to address:

1. How do we want tone to be represented (i.e. numbers, letters, superscripts etc). This is a purely practical matter and we should keep in mind that although technology and automation is here to help us, it is best to be ready to be a bit adaptable. (What I want to say is that in the end it is no big deal to get used to a slightly different symbol if that makes easier the life of the people behind the algorithms). I will come later with a summary and suggestions on this practical side, and I would also like Mattis to clarify what is possible right now in lingpy and what is easily achieved with some modification.
2. What are we going to do with floating tones (I am going to open a new issue for this, as I think there are some conceptual things we need to settle first, before going to the practicality of how to represent it)
3. Do we all agree on what the surface tones are? (or to rephrase, are we willing to trust each other's and other researchers' work on this?). I think it is quite clear that for me, we have to do that, we have to base ourselves on other people's work and on each other's work. No work is flawless, and indeed comparative work can point back to problems in the original data. I think this is the only way to proceed and of course we are going to be going back and forth the original data and our analyses throughout the project. (a side note on this, which is directly linked with Reflex's philosophy, is that in general we do not alter what the source says. this is done for a reason, because we may change our minds later, or different scholars may have different views. the more we stick to what the original source says and keep our comments and interpretations separate and clearly noted, the easier it is to disentangle problems later on.) During the skype meeting, I think that Thiago mentioned that there are some languages for which no surface tones are available. Is that correct? I think we need to have a plan for how to deal with these languages and this may be language specific in the end. I would advise to open a new issue for languages without surface tones in which it is explained exactly where the problem is, i.e. why we can't arrive at the surface tones.

[amaliaskilton]

On Thu, Feb 25, 2016 at 10:34 AM, Natalia Chousou-Polydouri < notifications@github.com> wrote:

ok, here are some of the things that came out from the skype meeting and what I think we still need to address in order to reach a clear decision on tone representation. Things on which I think everybody agrees:

1. We want tone to be a different entity (and here I mean historical entity) than the vowels for the alignments. This approach reflects that tone often evolves independently of vowel quality, but gives us also the opportunity to treat tone and vowel quality as "context" of the other.

I think everyone agrees that tone and segments should be treated separately, with the important proviso that there are diachronic interactions between segments and tones (they are simply not as numerous as the tone-only and segment-only changes).

(just a side note here, I think you all would like to consider nasality as part of the vowel quality, right?)

Yes, for the FUN forms, nasality can be represented as part of the vowel (and consonant) quality. Phonologically we treat it as a feature of the morpheme or syllable, and when it changes diachronically, the entire morph often changes at once due to harmony. This means that we will have a lot of 'sporadic' sound changes in our data taking b > m, d > n, and so on.

1. We agree that we want surface tones to be represented, as opposed to more abstract representations of tonal systems.

I think everyone is on board with this principle, but I also want to acknowledge that (as Elsa stated) for historical tonology, it is sometimes very informative to refer to underlying forms as well as surface forms. I think this could be most appropriately made possible in AmLex by making phonemic forms visible in the same pane that we use to align FUN forms. Is that technically feasible?

1. Thiago mentioned at some point that he would like a purely tonal field containing the tonal melody only.

I would also find this useful.

This is already implemented in Reflex, as well as some "primitive" scripts to extract it automatically from one of the form fields. So, this is definitely doable as things stand.

Please, speak up if the things above are not accurate!

Now, things we still need to address:

1. How do we want tone to be represented (i.e. numbers, letters, superscripts etc). This is a purely practical matter and we should keep in mind that although technology and automation is here to help us, it is best to be ready to be a bit adaptable. (What I want to say is that in the end it is no big deal to get used to a slightly different symbol if that makes easier the life of the people behind the algorithms).

My personal preference is for superscripts. I do not care if they are numbers or letters - I am used to both. Floating tones should be distinguished from segmentally supported tones, but it is not important to me how we represent that distinction.

I will come later with a summary and suggestions on this practical side, and I would also like Mattis to clarify what is possible right now in lingpy and what is easily achieved with some modification.

1.

What are we going to do with floating tones (I am going to open a new issue for this, as I think there are some conceptual things we need to settle first, before going to the practicality of how to represent it) 2.

Do we all agree on what the surface tones are? (or to rephrase, are we willing to trust each other's and other researchers' work on this?). I think it is quite clear that for me, we have to do that, we have to base ourselves on other people's work and on each other's work. No work is flawless, and indeed comparative work can point back to problems in the original data. I think this is the only way to proceed and of course we are going to be going back and forth the original data and our analyses throughout the project. (a side note on this, which is directly linked with Reflex's philosophy, is that in general we do not alter what the source says. this is done for a reason, because we may change our minds later, or different scholars may have different views. the more we stick to what the original source says and keep our comments and interpretations separate and clearly noted, the easier it is to disentangle problems later on.) During the skype meeting, I think that Thiago mentioned that there are some languages for which no surface tones are available. Is that correct?

Yes, there are several sources that do not show any tones (underlying or surface). Off the top of my head, these include Koreguaje (a small handful of entries show the tone, majority do not) and Carapana. My attitude toward these sources is that the data quality is what it is. The sources are OK in other respects and should be used, although taken with a large pinch of salt.

1.

I think we need to have a plan for how to deal with these languages and this may be language specific in the end. I would advise to open a new issue for languages without surface tones in which it is explained exactly where the problem is, i.e. why we can't arrive at the surface tones.

The reason for Koreguaje and Carapana is very simple. The problem is not that we don't agree on the surface tones, it's that the source just provides no information whatsoever about prosody, so there is nothing to agree or disagree about.

[levmichael]

Let me just briefly add that I agree with all of @amaliaskilton's responses to @nataliacp in the above message. I would only add that yes, we have to take as given the surface tones given or deducible (i.e. from underlying tones) from the sources we are working on. If there are multiple sources with conflicting information for a given language, that is a bridge we will cross when we encounter it.

[gomezimb]

Comments to Thiago, Natalia & Amalia messages:

1. We want tone to be a different entity (and here I mean historical entity) than the vowels for the alignments. This approach reflects that tone often evolves independently of vowel quality, but gives us also the opportunity to treat tone and vowel quality as "context" of the other.

I think everyone agrees that tone and segments should be treated separately, with the important proviso that there are diachronic interactions between segments and tones (they are simply not as numerous as the tone-only and segment-only changes).

E: Of course, tone is a different synchronic and diachronic entity; its autonomy gave rise to the auto segmental phonology which is still today the reference for understanding tonal systems.

(just a side note here, I think you all would like to consider nasality as part of the vowel quality, right?) Yes, for the FUN forms, nasality can be represented as part of the vowel (and consonant) quality. Phonologically we treat it as a feature of the morpheme or syllable, and when it changes diachronically, the entire morph often changes at once due to harmony. This means that we will have a lot of 'sporadic' sound changes in our data taking b > m, d > n, and so on.

E: I agree with Amalia's statement. We start with the hypothesis that nasality was not a morphemic or syllabic supra segment in ProtoTUK; ET languages developed a morphemic/syllabic supra segment, while WT kept it segmental in some cases. It's important to compare // to $$ in this case too.

1. We agree that we want surface tones to be represented, as opposed to more abstract representations of tonal systems. I think everyone is on board with this principle, but I also want to acknowledge that (as Elsa stated) for historical tonology, it is sometimes very informative to refer to underlying forms as well as surface forms. I think this could be most appropriately made possible in AmLex by making phonemic forms visible in the same pane that we use to align FUN forms. Is that technically feasible?

E: For historical tonology we have to refer to underlying forms. Let us take TUY, a language where only one H surfaces in the word where different kinds of Hs are competing to surface: for historical purposes it is important to know which morphemes in the word are tonal and not which one wins.

1. Thiago mentioned at some point that he would like a purely tonal field containing the tonal melody only. I would also find this useful. This is already implemented in Reflex, as well as some "primitive" scripts to extract it automatically from one of the form fields. So, this is definitely doable as things stand.

   Please, speak up if the things above are not accurate!

E: Will the tonal field reflect the U tones or the surface tones?

I think we have a problem with tonal info. In the available lists we have no U or surface tones for 5 languages: KOR, TUY, KAR, DES, TAN; SIO is said to be a stress language but we don't have any precise characterization; we have tonal data for MAI, KOT, TAT, BAS; for TUK we have a description an identification of Utones that is not accurate but that can be be reinterpreted and be used for surface tones; for KUB Thiago wrote that he can't provide surface tones for every word, why? if we build our Usystem on surface tones

[thiagochacon]

1. Tones must have an independent representation
2. We want surface and underlying tones
3. A pure tonal field would begreat, where surface tones would have a tone letter H or L, and a floating tone would be in parenthesis (H) or (L)

Now things we still need to do

• For language we have no source's tones, we can't provide any underlying or surface tones. They remain as they are (Which are: Kor, Sio, .
• Tuy: Barnes dictionary only gives pitch indication if they occurr in the first mora of the root. This is the exceptional pattern in the language. The default pattern is for high pitch in the second mora. But then there are two distinctions she does not make explicit in the dictionary: there are two kinds of high pitch in the second mora, an 'associated' one and an 'unassociated' one. The difference between them can be observed when suffixes are added. We can't provide this distinction, unfortunately, though it would be really important for a comparative analysis of tones. Tuy is, thus, underrepresented regarding tones.
• TUK: As I showed before, Ramirez systems is quite consistent so we can provide surface tones from his notation. Now for an underlying tone representation, @gomezimb seems to want to suggest that we use her reinterpretation of Ramiez data, which if I remember correctly is basically H and LH underlying tones, linked to the second mora of the root. There are some problems with this analysis from a theoretical, comparative and descriptive perspective. I have my own analysis of Tukano underlying system too, but I don't think we should spend to much time arguing for a particular reanalysis of Ramirez, since the Rising and High are good descriptive labels for comparing tone patterns.
• Kub: As I said, I have the underlying tones for most words, but surface tones for about 1/3 of the data. Providing surface tones is very time consuming. That is the reason, @gomezimb , why I don't have surface tones for some forms. You know how it is when you get used to the tones of a language: you hear it phonetically, and just write the phonological pattern. I really would like to work with @nataliacp @sflavier @LinguList and see if we can provide the surface tones automatically in Kubeo.

Teaching is starting now for me, and I have one book and an article to finish this semester, plus Amazonicas and other things. So if I have to add Tukano and Kubeo surface tones by hand, I expect a few months for doing this.

[nataliacp]

ok, so from what I understand, we want underlying tones in one representation (including floating tones I assume), we want surface tones and floating tones represented for alignment and we want a purely tonal field. here is my suggestion for how to store all that in Reflex and a couple of questions for you:

1. FUN field has surface tones and floating tones represented in a convenient way for alignemnt (something we are discussing on another thread)
2. PHM (phonemic field) can have phonemic representation and underlying tones (that sounds like a good combination, no?)
3. STO field will hold only the tones (question 1: should they be underlying or surface? I have no opinion on this)
4. another field (probably PHT-phonetic unless you see a problem with it) to have the surface form with IPA-noted tones, i.e. with accent marks over the vowels. (question 2: I think you wanted this for publications and as easier to read. Do you still want it and if yes, should it include floating tones and is it ok to put it in the phonetic representation?)

[nataliacp]

@amaliaskilton:

I think this could be most appropriately made possible in AmLex by making phonemic forms visible in the same pane that we use to align FUN forms. Is that technically feasible?

Right now, I don't think it is feasible. The alignment view shows only the FUN forms. But I think it is possible to have the cognate set loaded below in the available elements zone with any of its fields visible. In short, this can be made possible in any case if it is not already somehow there already.

[thiagochacon]

I like all you 4 fields, @nataliacp .

As for question-1: Only surface tones + floating tones, since underlying tones will be in the PHM field. Question-2: I think PHT sould only have surface tones, and no floating tones (which will be represented in several other fields).

[nataliacp]

great! if everybody agrees with these, we can close this issue and move on with the field decisions we made!

[levmichael]

Sounds good to me.

[thiagochacon]

E

Enviado do meu smartphone Samsung Galaxy.f