Theiling Online    Sitemap    Conlang Mailing List HQ   

Re: Phonetics

From:John Vertical <johnvertical@...>
Date:Monday, April 2, 2007, 10:42
>Ok, bad example. Pick a different character/language, then. Spanish >a with acute, say, which has its own Braille representation (an extra >dot, IIRC). > >-- >Mark J. Reed
Wait... I think I now see where you're going with this, and why there's an entirely different reason it won't work. To simplify the situation a little, let's just consider a plain "a", which is consistently translitterated by a single corresponding caracter in Braille, Cyrillic, Thai etc; which all represent, approximately, [a]. (And a few steps down, Unicode and all the different encodings of it have their own multiple ways of representing all these glyphs for [a].) Doing fine so far. Next, there is the fact that Latin <a> can have other meanings, like [e] in English. Likewise the Braille upper left dot. And then you the proceed to postulate an abstract "a" that's behind both a Braille upper left dot and a Latin <a> regardless of whether they represents [a] or [e]? Okay, but what would you say about a Braille upper left dot representing the 1st tone of Mandarin? Mandarin written in the Latin alphabet uses <a> for a completely different purpose (namely: its usual vocalic value). So which one would you choose here as representing the previously-established abstract "a"? Or maybe both? Regardless of your choice, however, you'll have to allo either or both of: 1) one glyph can stand for multiple abstract caracters 2) one abstract caracter can be represented by multiple glyphs in an alphabet (Hmm, "abstract caracter" is a bit long to write over and over. I think I'll portmanteau it to "absker".) The first of those two choices, however, will completely wreck your original argument that Braille "a" representing [a] has to be the same absker as Latin <a> representing [e] - because there could then just as well also be TWO abskers in play that both surface as a Latin <a>. I mean, how do you tell? Surely you're not giving the Latin alphabet preferential treatment in that those letters are the ur-values of the abskers and always correspond to a single absker, while letters from any other alphabets can have more than one absker behind them? A more equal choice could be to equate the abskers with the actual semantic meanings (in this case: [a], [e], Mandarin tone 1), but then they wouldn't be strictly abstract any more. Not good for your theory. So in order to avoid that, let's take the 2nd choice. To still have an absker for every letter, we'll need to get *very* abstract! Greek beta can be translitterated as Latin <b> or <v> depending what sort of Greek we're talking about, so they belong to the same absker. <v> in Classical Latin can be transcribed with the IPA upsilon, as can Latin <u> in English so those are also the same, and then we can take another trip over to Greek and add in <y>. It is also used for translitteration of Cyrillic short I, but so is <j>; etc, etc, and eventually you'll find that absolutely EVERYTHING falls under one single absker, at which point it's not really an useful concept. And remember, if you allo even ONE glyph to stand for more than one absker, you will either need a reason for the excuse - I can't think of one; can you? - or you will have to allo ANY glyph to stand for more than one absker, at which point the argument from the previous paragraph comes into effect. So in summary, I don't think you can form a definition of an absker that simultaneously 0) assigns an absker to every glyph, encoding, etc. 1) is internally consistent, 2) alloes for more than one absker to exist, 3) doesn't "play favorits" among alphabets, 4) is independant of meaning or glyph form. If this is just a strawman or an unrelated sidetrack in your opinion, do say so, but I'd like you to come up with your own formal description of an absker in that case. John Vertical _________________________________________________________________ Ota käyttöön Windows Live Messenger ja sano kyllä kivuttomalle viestinnälle!


Mark J. Reed <markjreed@...>