Subject: [VCARDDAV] Phonetic Transcription field in vCard 4.0

From: Valerio Ricci <[email-masked]>
Date: Fri, 25 Feb 2011 18:27:42 +0100

Hi everyone,
I searched through the various lists, searched on
http://www.vcarddav.org/wiki and googled a bit, but found no discussion
about phonetic transcription in vCard.

For the ones who don't know what I'm talking about phonetic transcription is
a field for the reading of names and surname (in some cases other field
also) for ideographic languages, in particular Japanese and Chinese.

It is actually used as an extension of the standard as
X-PHONETIC-FIRST-NAME;
X-PHONETIC-LAST-NAME;
or
SOUND;X-IRMC-N;

I think such a feature, because it refers to the name field, should in v4.0
be added to the "core" of vCard format instead of remaining an undefined
extension.
If any further explanation is required please fell free to ask me.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 25 Feb 2011 10:32:19 -0700

On 2/25/11 10:27 AM, Valerio Ricci wrote:
> For the ones who don't know what I'm talking about phonetic
> transcription is a field for the reading of names and surname (in some
> cases other field also) for ideographic languages, in particular
> Japanese and Chinese.
> 
> I think such a feature, because it refers to the name field, should in
> v4.0 be added to the "core" of vCard format instead of remaining an
> undefined extension.

That might be a nice idea, but in my opinion it does *not* belong in the
core. The core is *done* except for a few open issues that the document
editor is working on. We need to publish version 4 as soon as humanly
possible.

However, feel free to work on a vcard4 extension defining phonetic
equivalents.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Feb 2011 12:50:59 -0500

> editor is working on. We need to publish version 4 as soon as humanly

Agreed.

Moreover, it might already be available in core. This email says that
these two properties can be replaced by SORT-AS:
http://www.ietf.org/mail-archive/web/vcarddav/current/msg01657.html

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Valerio Ricci <[email-masked]>
Date: Fri, 25 Feb 2011 19:25:25 +0100

In my opinion because of the fact that phonetic transcription has the same
format of the name field it could have logically the same format as the name
N field.
One thing that I'm not sure of is the encoding. I read that charset feature
has been dismissed but this should not be a problem, because UTF8 encoding
gives the possibility to phonetically transcript also in Japanese kana and
Chinese bopomofo.
I'm not a technician and not really aware of the possible difficulties of
implementing this kind of stuff, so please give me some feedback on this.

---

From: Valerio Ricci <[email-masked]>
Date: Fri, 25 Feb 2011 19:36:38 +0100

On Fri, Feb 25, 2011 at 6:50 PM, Simon Perreault <
[email-masked]> wrote:

> I do not agree, Phonetic transcription is theoretically different from
sorting, and in addition to it in name field there is the need to specify
which is the first and which is the last name.
And sorting could be done also by different criteria than name or surname,
ad for example grouping all doctors under Doc. A.B. Doc B.C., ecc.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 25 Feb 2011 13:59:03 -0500

On 2011-02-25 13:36, Valerio Ricci wrote:
> in name field there is the need to
> specify which is the first and which is the last name.
> And sorting could be done also by different criteria than name or
> surname, ad for example grouping all doctors under Doc. A.B. Doc B.C., ecc.

SORT-AS allows that. See the many examples in section 5.8.

Simon

---

From: Valerio Ricci <[email-masked]>
Date: Sat, 26 Feb 2011 01:41:38 +0100

> SORT-AS allows that. See the many examples in section 5.8.

I saw the examples and I see your point, but I insist that phonetic
transcription has nothing to do with sorting.  Phonetic is an attribute of
the name, and sorting is the way name is ordered in a list.
In practical situations I think that this could also be a problem.
For example: given the Japanese name 平林太郎 you transcribe it phonetically as
ﾋﾗﾊﾞﾔｼ ﾀﾛｳ and you could wish to sort it as Hirabayashi Tarō for coherence
to an alphabetical sorting.
The half width katakana is the standard method of giving the phonetic
transcription in Japan. I don't know exactly the situation in China, which
is maybe different because as far as I know pinyin is widely used instead of
bopomofo. But again, I'm not really sure.

Anyway, the main point in that under a logical point of view phonetic
transcription has nothing to to with sorting, and in my opinion the two
things should be clearly divided.

It could seem that I am a bit exaggerating the thing but in Japan phonetic
transcription has always been an obscure point in vCard, and different
vendors are using different formats.
It seems that recently due to the huge base of users of Google and Apple
products, X-PHONETIC-FIRST-NAME; X-PHONETIC-LAST-NAME; are the most used
ones, but I think that some clear position must be taken about an issue that
refers to the name of a contact (!) in order to improve interoperability.

---

From: Likepeng <[email-masked]>
Date: Sat, 26 Feb 2011 01:04:29 +0000

>I don't know exactly the situation in China, which is maybe different because as far as
>know pinyin is widely used instead of bopomofo. But again, I'm not really sure.

Yes, in China, pinyin is widely used and usually the address book is sorted by the pinyin of the last name.

As far as I know, in China, many implementations don’t design pinyin as attribute of the name. The mobile phone can automatically get the pinyin from the Chinese character and sort them accordingly.

Kind Regards
Kepeng
发件人: [email-masked] [mailto:[email-masked]] 代表 Valerio Ricci
发送时间: 2011年2月26日 8:42
收件人: [email-masked]
主题: Re: [VCARDDAV] Phonetic Transcription field in vCard 4.0

On Fri, Feb 25, 2011 at 7:59 PM, Simon Perreault <[email-masked]<mailto:[email-masked]>> wrote:

Simon

I saw the examples and I see your point, but I insist that phonetic transcription has nothing to do with sorting.  Phonetic is an attribute of the name, and sorting is the way name is ordered in a list.
In practical situations I think that this could also be a problem.
For example: given the Japanese name 平林太郎 you transcribe it phonetically as ﾋﾗﾊﾞﾔｼ　ﾀﾛｳ and you could wish to sort it as Hirabayashi Tarō for coherence to an alphabetical sorting.
The half width katakana is the standard method of giving the phonetic transcription in Japan. I don't know exactly the situation in China, which is maybe different because as far as I know pinyin is widely used instead of bopomofo. But again, I'm not really sure.

Anyway, the main point in that under a logical point of view phonetic transcription has nothing to to with sorting, and in my opinion the two things should be clearly divided.

It could seem that I am a bit exaggerating the thing but in Japan phonetic transcription has always been an obscure point in vCard, and different vendors are using different formats.
It seems that recently due to the huge base of users of Google and Apple products, X-PHONETIC-FIRST-NAME; X-PHONETIC-LAST-NAME; are the most used ones, but I think that some clear position must be taken about an issue that refers to the name of a contact (!) in order to improve interoperability.

---

From: Valerio Ricci <[email-masked]>
Date: Sat, 26 Feb 2011 02:28:42 +0100

On Sat, Feb 26, 2011 at 2:04 AM, Likepeng <[email-masked]> wrote:

>
> As far as I know, in China, many implementations don’t design pinyin as
> attribute of the name. The mobile phone can automatically get the pinyin
> from the Chinese character and sort them accordingly.
>
>
>
Well, in Japan this is impossible because same characters can have different
readings
For example the name 饗庭 can be read as
Aeba, Aiba, Aeniwa, Eniwa, Kyuba, Kyotei, Kyoniwa, Kyoba, Makiba, ...

For this reason having a way of writing down the phonetic name of the person
you are in contact with is fundamental.

---

From: Likepeng <[email-masked]>
Date: Sat, 26 Feb 2011 01:39:54 +0000

If this is the case, I agree with Peter that it would be good to design it as an extension draft, not in the base vCard 4, because it is useful for some countries, but not for all.

Kind Regards
Kepeng
发送时间: 2011年2月26日 9:29

On Sat, Feb 26, 2011 at 2:04 AM, Likepeng <[email-masked]<mailto:[email-masked]>> wrote:

Well, in Japan this is impossible because same characters can have different readings
For example the name 饗庭 can be read as
Aeba, Aiba, Aeniwa, Eniwa, Kyuba, Kyotei, Kyoniwa, Kyoba, Makiba, ...

For this reason having a way of writing down the phonetic name of the person you are in contact with is fundamental.

---

From: Valerio Ricci <[email-masked]>
Date: Sat, 26 Feb 2011 12:48:58 +0100

> However, feel free to work on a vcard4 extension defining phonetic
I am not sure that I can create something of this kind by myself, it seems
like an hard work that implies some knowledge that I do not have right now.
Anyway where can I find some  other extensions to see how they work or
something to base my work on?
And what "standards" I'm supposed to meet for that.
I know is quite a general question, but I sincerely hope there are some
guidelines or at least some solid model or something like that.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 27 Feb 2011 11:55:44 -0500

> the name, and sorting is the way name is ordered in a list.

I agree with Valerio here.  Even in western scripts we might have
situations where we want phonetic versions of names, because they're
not pronounced the way people are used to reading them.

Siobhán is pronounced "sha-VAWN", but we don't want to sort it in "sha".
Sometimes Ralph is pronounced "rayf", but we still want all the Ralphs
to be sorted together.
Taken to silly British extremes, we have some surnames that have what
seem like completely odd pronunciations, and we need to be able to
specify them without altering the sort order:
Cholmondeley is pronounced "chumley".
Taliaferro is sometimes pronounced "tolliver".
And so on.

I need to tell people that my own surname is pronounced "LEE-bah" (not
"LYE-bah"), without altering the sort.

There's a system called Soundex ( http://en.wikipedia.org/wiki/Soundex
) that handles this sort of thing.  But whatever we use, the
pronunciation guide for the name has to be separate from the sort
info.

Barry

---

From: Kurt Zeilenga <[email-masked]>
Date: Sun, 27 Feb 2011 09:54:04 -0800

> pronunciation guide for the name has to be separate from the sort

Soundex is a 'phonetic algorithm'.  They are used in "sounds like" matching.  Directory servers sometimes use phonetic algorithms in their implementation of approximate matching.   I don't see how an indexing algorithm would be used here.

A better fit here, I think, would be a standard representation of how a name (or other value) is to be pronounced, such as the International Phonetic Alphabet.

I can also see it useful to express a more informal pronunciation guidance to the vCard consumer, such as "pronounced same as Shawn" (for "Sean"), "sounds like ...", "rhymes with ..." or "pronounced as "the second" (for "II").

-- Kurt

---

From: Barry Leiba <[email-masked]>
Date: Sun, 27 Feb 2011 13:17:09 -0500

> A better fit here, I think, would be a standard representation of how a name (or other
> value) is to be pronounced, such as the International Phonetic Alphabet.
>
> I can also see it useful to express a more informal pronunciation guidance to the
> vCard consumer, such as "pronounced same as Shawn" (for "Sean"), "sounds
> like ...", "rhymes with ..." or "pronounced as "the second" (for "II").

Yes; I'd like to be able to do it formally or informally -- perhaps
with an optional property called "IPA" for the formal part, and a
free-form text value for the informal part.

Barry

---

From: Kevin Marks <[email-masked]>
Date: Sun, 27 Feb 2011 10:42:45 -0800

As the standard now allows multiple FNs, could this just be an FN with an
ALTID and a suitably defined language parameter to indicate the language and
script?
This should cope with kana, pinyin, and IPA.

We could have a language of en-ipa-x-sortorder

On Sun, Feb 27, 2011 at 10:17 AM, Barry Leiba <[email-masked]>wrote:

> _______________________________________________
> VCARDDAV mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/vcarddav
>

---

From: Valerio Ricci <[email-masked]>
Date: Mon, 28 Feb 2011 00:48:25 +0100

> This should cope with kana, pinyin, and IPA.

Reading the documentation more deeply I found out that many values can have
ALTIDs, for example under point 5.4. ALTID we have:

     N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
     N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
     (<U+XXXX> denotes a UTF8-encoded Unicode character.)

Which seems to be linked with the issue we are talking about.
In my opinion anyway it is a bit obscure. The main problems are
1-In these examples ALTIDs are linked with languages and a phonetic
transcription of a Japanese kanji name is Japanese also in his kana
transcription, so the two fields will end in not being properly specified
and illegal as here.

     N;ALTID=1;LANGUAGE=jp:<U+5C71><U+7530>;<U+592A><U+90CE>;;;
     N;ALTID=1;LANGUAGE=en:Yamada;Taro;;;
     N;ALTID=1;LANGUAGE=en:Smith;John;;;
     (The last line should probably have ALTID=2. But that would be
      illegal because N has cardinality *1.)

2-Languages are defined by a specification and also if there is the
possibility of custom values for them it seems to me that this is only a
partial and confusing solution.
3-Phonetic transcription should, in my opinion be clearly visible. Because
of its nature it tends to differ in various implementation. At present times
the feature is not widely used, but some BIG companies like Google, Apple
and many Japanese companies are using the extensions I gave on my first
mail.
Having a clear structure should encourage the adoption of the defined
standard form, enhancing the interoperability between systems.

PS: About the FN property I'd like to report this comment found here:
https://wiki.mozilla.org/VCard4#section_6.2.1._FN

"There is no advice/guidance/example given regarding how to treat multiple
FNs and thus I fear this new capability may introduce some interoperability
problems.

I suggest some wording and examples clarifying what the purpose may be for
multiple FNs"

---

From: Kevin Marks <[email-masked]>
Date: Sun, 27 Feb 2011 17:08:44 -0800

There are examples in RFC5646 of the more complex language tags that include
script, region and extension. That may be better than introducing another
alternative name field.

http://tools.ietf.org/html/rfc5646#section-2.2.3

---

From: Daisuke Miyakawa <[email-masked]>
Date: Sun, 27 Feb 2011 18:31:01 -0800

Hi,

> It is actually used as an extension of the standard as

I'll describe what I know about "phonetic" and "sort" in Japan. I hope it
will help the community.

I have Japanese old mobile phone which uses "SOUND;X-IRMC-N;" in vCard 2.1,
for "Yomigana" field, or "phonetic name" field.
Other Japanese mobile phones are sometimes using SORT-STRING in vCrad 3.0
for exactly same usage.
They are, from the view of users, exactly same looking: "Yomigana", or
"phonetic name".

Historically, Japanese Kanji names are hard to sort, as mentioned before,
while vCard 2.1 doesn't have any relevant fields.
That is why Japanese careers have used "SOUND;X-IRMC-N".
They (SOUND;X-IRMC-N and SORT-STRING) are also used to correctly pronounce
it.

The point here is that, those purposes are not separate (in Japan), and not
in vCard 3.0.

According to my understanding, the term "phonetic" is from MS convention,
which has been both for "sorting" and "pronouncing".
ms-DS-Phonetic-Company-Name is one example, which is mainly for sorting
company names.
The "phonetic" term has been used for both of goals: "sort" and "phonetic
expression"

As for X-PHONETIC-FIRST-NAME, I think it was needed as SORT-STRING doesn't
accept multiple elems (family, given, middle, for example), while SORT-AS
has it.

Japanese have not been accustomed to have another field "just" for phonetic
expression.
Usually, or almost always, "phonetic" stuffs have been tightly bound to
sorting.
This means that, if we have two fields for sort and phonetic, existing
application won't be able to handle that.
Also, most of Japanese will be just confused about that.

It's ok for vCard 4.0 to have two fields along with this issue, as vCard 4.0
is specification anyway, and any application hide it.
But please remember that, the term "phonetic" has not been used for the
separate field which may be introduced from vCard 4.0, at least in Japan.
Old and even recent applications will get confused when translating old
vCard to the vCard 4.0 with exact phonetic stuff support.

My understanding is that SORT-STRING in vCard 3.0 and SORT-AS in vCard 4.0
is "more" than phonetic names.
How it sorts often contains how it is pronounced. Depending on culture, we
can understand exactly what it is.
vCard 3.0 has had SORT-STRING, which SORT-AS is along with.
Adding phonetic stuffs apart from SORT-AS would confuse future direction.
Translating old convention to vCard 4.0 would be very difficult.

If the other countries have different big issue(s) in which they really want
separate fields for sort and phonetic, it's ok to have both anyway.

> 3-Phonetic transcription should, in my opinion be clearly visible.
Just as for Japanese, we can simply translate "sort" to "phonetic". I agree
it is a bit confusing, but convention is usually so.
Introducing another "phonetic" stuff will confuse an established convention,
which I'm really concerning here.

multiple FNs"

I agree. My impression was like this:

FN;LANG=ja:宮川大輔
FN;LANG=en:Daisuke Miyakawa

"宮川大輔" is my name with Kanji.

2011/2/27 Kevin Marks <[email-masked]>

> There are examples in RFC5646 of the more complex language tags that
> include script, region and extension. That may be better than introducing
> another alternative name field.
>
>> On Sun, Feb 27, 2011 at 7:42 PM, Kevin Marks <[email-masked]>wrote:
>>
>> Reading the documentation more deeply I found out that many values can
>> have ALTIDs, for example under point 5.4. ALTID we have:
>>

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

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Feb 2011 08:58:30 -0500

On 2011-02-26 06:48, Valerio Ricci wrote:
> I am not sure that I can create something of this kind by myself, it
> seems like an hard work that implies some knowledge that I do not have
> right now.Anyway where can I find some  other extensions to see how
> they work or something to base my work on?

I'm looking at the document list here:
http://tools.ietf.org/wg/vcarddav/

I see the following extension drafts which you could look at:
draft-cauchie-vcarddav-oma-cab-extensions
draft-george-vcarddav-vcard-extension
draft-li-vcarddav-vcard-id-property-extensions

I would suggest draft-li-vcarddav-vcard-id-property-extensions as a good
example.

See draft-ietf-vcarddav-vcardrev section 10.2 for more information on
vCard extensions in general.

Simon