Subject: Re: [VCARDDAV] phonetic-given-name and phonetic-family-name

From: Teiichiro Fukuda <[email-masked]>
Date: Fri, 30 Aug 2013 06:46:12 +0000 (UTC)

Tantek Çelik <tantek <at> cs.stanford.edu> writes:

Hi Tantek,
 
> Greetings,
> 
> In iOS and MacOS Address Book interfaces, in addition to the usual
> name fields such as given-name, family-name, the Address Book provides
> phonetic-given-name and phonetic-family-name fields for users to enter
> for a contact.
> 
> The UI use case of these is sorting by given or family name
> explicitly, beyond a simple "canonical" sort which the 'sort-as'
> parameter would suffice.
> 
> The options of sort by given name (first name) or sort by family name
> (last name) are provided which sort according to phonetic-given-name
> if any otherwise given-name, and phonetic-family-name if any otherwise
> family-name, respectively. This feature is apparently particularly
> useful in Japanese.
> 
> phonetic-given-name and phonetic-family-name could be added as
> sub-components of the 'n' property similar to given-name and
> family-name, or they could be made their own properties as well,
> similar to nickname.

I agree with you.

In Gmail's and iOS, the name field and the family name field are defined as 
follows.

e.g.

N:山田;太郎;;;
FN:山田 太郎
X-PHONETIC-FIRST-NAME:たろう
X-PHONETIC-LAST-NAME:やまだ

> What do others think?
> 
> Should these properties/components be proposed as a vCard4 extension?

Yes.
I think that I should propose the functionality expansion of vCard4.0.

Thanks,

Teiichiro Fukuda

---

From: Dan Brickley <[email-masked]>
Date: Fri, 30 Aug 2013 08:37:44 +0100

Hi all,

> explicitly, beyond a simple "canonical" sort which the 'sort-as'

 Looking at Teiichiro Fukuda's example,

N:山田;太郎;;;
FN:山田 太郎

... it seems the convention is to use the same implied natural language
setting as the main naming fields, e.g. kanji vs hirigana here both express
Japanese but the latter carries pronunciation information. How many
languages does that generalize to?

I can see the value for sorting in several languages, but wonder about
addressing the broader question of pronunciation. The risk is of running
speculatively ahead of implementations/product esp authoring tools. Are
there any uses of something like
http://en.wikipedia.org/wiki/International_Phonetic_Alphabet in the wild
for this?

See also http://www.w3.org/html/wg/wiki/PronunciationSemantics
http://www.w3.org/html/wg/tracker/issues/49 for investigations into this in
an HTML context. W3C's speech work is also relevant - see examples at
http://www.w3.org/TR/pronunciation-lexicon/#S5 also
http://www.w3.org/2006/10/SSML/agenda.html
It seems from
http://en.wikipedia.org/wiki/Pronunciation_Lexicon_Specification they allow
less formal mechanisms than IPA, e.g. <lexeme><grapheme>BBC 1</grapheme>
<alias>be be sea one</alias></lexeme>.

If I understand correctly, the mechanism proposed in this thread would
- for at least some major languages - transfer control of sorting from
publishers/authors (who have it now via 'sort-as') to users/consumers
by allowing more fields to be directly sortable, assuming the phonetic
mapping is made available. What would the intended ordering behaviour
be when only some records had the new fields? If the underlying use
case here is discovery (looking up a record from a larger collection),
searching (and exploiting pronunciation info only where it exists)
could have stronger impact than sort-based browsing in the case of
mixed collections where only some records have phonetics information.

Looking at other phonetics mechanisms - I'm not sure if IPA
pronunciation data would be sufficient to produce the expected sort
orders, but would help with speech synthesis, perhaps with speech
recognition, and most importantly also those awkward occasions where
you need to know how someone's name is spoken. Thinking of this in
terms of the incentive for authors/publishers, the latter use case
could be a good motivation - many people (and organizations) have a
strong preference for their name to be pronounced correctly.

Dan

ps. BTW how does one pronounce 'Çelik'? In English for 'c' variants people
often write "c as in church/loch/cat/sea" etc.; I assume such
phonetics-by-analogy are out of scope for X-PHONETIC-LAST-NAME?

---

From: Simon Perreault <[email-masked]>
Date: Fri, 30 Aug 2013 15:11:24 +0200

Le 2013-08-30 09:37, Dan Brickley a écrit :
> setting as the main naming fields, e.g. kanji vs hirigana here both
> express Japanese but the latter carries pronunciation information. How
> many languages does that generalize to?

Well, the SORT-AS examples in RFC 6350 demonstrate usefulness in various
languages other than Japanese.

https://tools.ietf.org/html/rfc6350#section-5.9

> there any uses of something
> like http://en.wikipedia.org/wiki/International_Phonetic_Alphabet in the
> wild for this?

My understanding so far is that the X-PHONETIC properties are used for
sorting, not pronunciation.

Simon

---

From: Daisuke Miyakawa <[email-masked]>
Date: Sat, 31 Aug 2013 14:05:51 +0900

Hi,

Just my two cents..

> sorting, not pronunciation.

My knowledge says that you're right.
I think SORT-AS can replace X-PHONETIC for sorting.

One possible concern here *might* be that, Siri may not use SORT-AS, so we
need something else.

I think X-PHONETIC have been used almost for just sorting, but from its
naming they also imply
"(Japanese) people pronounce those names this way".
This means applications like Siri can use X-PHONETIC effectively for
pronunciation
while they may not use SORT-AS because specifically it is just for sorting.

SOUND property? I'm not sure.

-- 
Daisuke Miyakawa (宮川大輔)
[email-masked]