ressurect tie-bars?

[drammock]

@bambooforest I'm starting to think that life would be better if we ressurected our use of the tiebar. Specifically, it would make it easier for the script to do the right thing when auto-building feature vectors based on the glyph components. For example, doubly-articulated stops like kp are almost always a simultaneous closure, so they should not get features like +,- labial and -,+ dorsal. If we had a tiebar in there, then whenever the script saw a tiebar, it would let let + override -, and whenever there was no tiebar it would create a contour feature. WDYT? It might mean editing the raw data files to put the tiebars back in, which sounds brutal, but I will volunteer to do it. Unless we have a way of systematically figuring out which phonemes deserve tiebars and being sure that they always deserve tiebars regardless of which language they occur in...?

[bambooforest]

i'm ok with this decision. you may be able to glean what's complex and not by using the features chart.

are we going to be completely consistent throughout the database? meaning if we use the tie-bar for complex segments like /kp/, do we also use it for /t̠ʃ/ and all affricates?

historically, IPA allowed the tie-bar to represent affricates (revision 1932) with the tie-bar (also as two consecutive consonants, or ligatures). it was in the 1938 IPA revision that the tie-bar's semantics were broadened to indicate simultaneously articulation. later also for diphthongs.

so we should be clear, also in updating our conventions, when the tie-bar is used and not used.

note there's the issue of tie-bar above and tie-bar below, but i suppose we'll go with strict above because no matter how it's rendered it may be ugly. also, in my experience dealing with the tie-bar in segmentation is a bit of a pain because of how Unicode treats it. it combines with the left most character and does not mind the the latter character. this gets complicated with diacritics and the like. i have a bit of a hack to combine and tokenize tie-bars here:

https://github.com/bambooforest/segments/blob/master/segments/tokenizer.py#L349-L406

[drammock]

1. it's easy enough to accept both above and below tiebars in the input, and the code can standardize on one of them.
2. my thinking was that the tiebar would be used for affricates and doubly-articulated sounds, but we would not bother using it for diphthongs because they always get contour features anyway (i.e., you can't make a "simultaneous" /i/ and /a/ in the same sense that you can make a simultaneous /k/ and /p/).
3. This would be a database-wide change, yes (it would have to be in order for the auto-built features to be consistent across different data sources).

I'm going to meditate on this for another couple days before I bite the bullet and go for it.

[bambooforest]

regarding:

1. well i hope the unicode string handling library is better at this in R than in Python... tie-bar is notoriously difficult
2. sounds good (plus i like how we handle diphthongs atm)
3. if we do do a database-wide change, should we also consider standardizing more the use of diacritics, like dental, as in make sure that a multi-segment segment that is dental contains dentals on either just the first segment or on all base segments. or will this be automated? i'd bet there a straggler or a few in this regard

ohmmm

[drammock]

• the R stringi package is actually quite good (it calls the underlying ICU C-libraries). I'm surprised to learn that python doesn't have something similar...
• I thought we had done pretty well with standardizing diacritics for affricates. You're probably right though, there are bound to be some stragglers. Seems like a good excuse to write a test, at least, even if we don't end up auto-correcting them.

[drammock]

closing because the new auto-build approach in #198 deals with affricates just fine.