Subject: [VCARDDAV] New sub-property: Initials (Issue 154)

From: Andy Mabbett <[email-masked]>
Date: Mon, 14 Jul 2008 23:31:20 +0100

For issue 154, "New sub-property: Initials":

        <http://www.vcarddav.org/issues.xhtml#154>

the comment and proposed solution are:

        It looks like all these cases could be expressed with the
        current spec.

        [...]

        >    given-name:      Theophilus
        >    middle-initials: P.
        >    family-name:     Wildebeest

        N:Wildebeest;Theophilus;P.;;

        > and:
        >    initials:       J.
        >    given-name:     Paul
        >    family-name:    Getty

        N:Getty;Paul;J.;;

        Therefore, the current proposal is to close this issue without
        action.

However, the two solutions cited do not seem to differentiate between a
middle (as in "Theophilus P. Wildebeest") and first (as in "J. Paul
Getty") initial; the latter might subsequently be rendered, wrongly, as
"Paul J. Getty".

The "N" property is specified as:

        Type special note: The structured type value corresponds, in
        sequence, to the Family Name, Given Name, Additional Names,
        honorific Prefixes, and Honorific Suffixes. The text components
        are separated

thus in the other example, "A. N.. Other", the proposed solution:

        N:Other;A.;N.;;

insists that "A." is the given name and "N." is an additional name. If
Mr Other is known to all and sundry as "Nigel", this does not seem
reasonable.

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

---

From: Simon Perreault <[email-masked]>
Date: Sat, 26 Jul 2008 14:39:05 -0700

> Getty") initial; the latter might subsequently be rendered, wrongly, as

I'm sorry, English is not my primary language and I was under the 
impression that a given name was synonymous with a first name (i.e. the 
first part of a full name, be it an initial or not). I also thought that 
an initial was always simply the first letter of any part of a name, not 
a named part of a full name. So in my understanding, for "J. Paul 
Getty", "J." would be the given name (and would also happen to be an 
initial, but vCard doesn't know about that), "Paul" would be an 
additional name, and "Getty" would be a family name.

To be more explicit, I thought it was like this:

GIVEN-NAME *ADDITIONAL-NAME FAMILY-NAME

where any part might be an initial (but vCard treats initials and 
non-initials identically, as opaque strings).

> Mr Other is known to all and sundry as "Nigel", this does not seem

In that case it wouldn't it seem reasonable to add a NICKNAME?

N:Other;A.;N.;;
NICKNAME:Nigel

---

From: Andy Mabbett <[email-masked]>
Date: Sat, 26 Jul 2008 16:25:38 +0100

In message <[email-masked]>, Simon Perreault
<[email-masked]> writes

>first part of a full name, be it an initial or not). I also thought
>that an initial was always simply the first letter of any part of a
>name, not a named part of a full name.

I think part of the problem is that there is not clear definition of
"given-name". Some would argue that, as I am formally

        Andrew John Mabbett

I have two given names, "Andrew" and "John".

The full Oxford English dictionary defines "given name" as:

        the name given at baptism, the Christian name.

using singular in both cases.

The difficulty arises because of the unsuitability of other terms
"Christian name" may be offensive to non-Christians, "first name" or
"forename" do not apply to cultures where the family name is given
first.

Indeed, in many cases, no distinction other than ordering, is made
between a "first name" and a "middle name".

> So in my understanding, for "J. Paul Getty", "J." would be the given
>name (and would also happen to be an initial, but vCard doesn't know
>about that), "Paul" would be an additional name, and "Getty" would be a
>family name.

It might be more accurate to say that the "given names" are, as one data
item, "J. Paul" and that his "preferred name" is "Paul", just as my
given names are "Andrew John" and my preferred name is "Andy". My friend
Lindsey has given names of "Karen Lindsey"; a first-name of Karen and a
middle, and preferred, name of "Lindsey".

>In that case it wouldn't it seem reasonable to add a NICKNAME?

Perhaps, but that does not differentiate between his "Nigel" (or my
"Andy" and true nicknames, like "wiseguy" or "Sting".

---

From: "Javier Godoy" <[email-masked]>
Date: Sun, 27 Jul 2008 07:13:16 -0300

After reading the last messages in this thread, I have some questions and
comments:

1. Do we need to distinguish between "first given name" and "other additional
names"?

Proposal:  N property. The structured property value corresponds, in
      sequence, to the Family Name, Given Names, Honorific Prefixes, and
Honorific Suffixes.

Then we have:
   n-value      = 0*3(text-value *("," text-value) ";")
                   text-value *("," text-value)
         ; Family; Given; Prefix; Suffix.

(I don't know by sure if "given names" is the exact term in English, as it is
not my primary language either.)

2. From the ABNF above (copied from vcardrev-03, with removal of "Middle" name),
it is possible to specify several family or given because each component is
text-value *("," text-value). For consistency, should we write "Family Names"
instead of "Family Name" in the special notes for the N property?

3. There is a discussion about how to identify the preferred given name.

> "Andy" and true nicknames, like "wiseguy" or "Sting".

Agree. If there were several nicknames, I wouldn't know which of them is the
preferred name, and which are true nicknames.

Other point of view about this issue is that presenting the preferred name as a
nickname does not actually says it is the preferred name. E.g.,
 N:Other;Albert.;Nigel.;;
 NICKNAME:Nigel
 NICKNAME:wiseguy

I (human) may guess that Nigel is his preferred name, but human intervention is
not acceptable here because the N property was intended to automatic
locale-independent processing. Besides, I would expect information about the N
property to be contained in the N property and not elsewhere.

Approach 1 (less intrusive, less powerful) define a "given" attribute for the N
property. This attribute would represent which name is preferred. This (plus my
previous proposal of merging first and additional names in a single name
component) would result in:
N;given=2:Getty;John,Paul
N;given=2:Other;A.,Nigel
N;given=1:Mabbett;Andrew,John

Appoach 2: someone may argue that approach 1 is rather simple and it does not
address other cases (such as several names and some combination of them being
preferred, or several preferred combinations). Alternatively we could introduce
a PN (preferred name) property. The value of PN may be used as a replacement for
all given names

--preferred: first initial and second given name-- 
N:Getty;John,Paul
FN:John Paul Getty
PN:J. Paul

--preferred: second given name--
N;given=2:Other;A.,Nigel
FN:A. Nigel Other
PN:Nigel

--preferred: nickname from first given name--
N:Mabbett;Andrew,John
FN:Andrew John Mabbett
PN:Andy

Best Regards

N:Godoy;Roberto,Javier
PN:Javier

---

From: Simon Perreault <[email-masked]>
Date: Sun, 27 Jul 2008 11:35:09 +0100

>      sequence, to the Family Name, Given Names, Honorific Prefixes, and

+1

> instead of "Family Name" in the special notes for the N property?

The alternative would be to limit to a single family name. +0.5 each, I 
don't care either way.

> If there were several nicknames, I wouldn't know which of them is 
> the

True. This is something that vCard currently doesn't provide.

Approach 0: use the PREF parameter

N:Getty;John,Paul
N:Other;A.,Nigel
N;PREF:Mabbett;Andrew,John

> --preferred: first initial and second given name-- N:Getty;John,Paul
> FN:John Paul Getty
> PN:J. Paul
> 

Note that this is simply another use case for the more general problem 
of indicating preference among many instances of a property. Let's focus 
on the general problem instead of just for name properties.

Here are the current proposals:

1. Allow PREF to be used with all properties (except those that can only 
appear once).

2. Remove PREF altogether.

3. #1 + add integer value to PREF parameter to be able to sort properties.

4. #2 + pecify that ordering matters.

I'm leaning toward 4.

---

From: "Javier Godoy" <[email-masked]>
Date: Sun, 27 Jul 2008 08:15:29 -0300

Simon Perreault wrote:

> The alternative would be to limit to a single family name. +0.5 each, I don't 
> care either way.

I'm *sligthly* biased towards allowing multiple family names, since (at least in 
the Spanish-speaking world) two surnames are not the same as a compound surname 
[1], and some single surnames (such as "de la Puente") are composed by several 
words and not separated by hyphens or other characters. I guess it may be the 
case for other cultures too.

[1] http://purl.net/net/es2en/es.wikipedia.org/wiki/Apellido

>> If there were several nicknames, I wouldn't know which of them is the 

I don't understand your approach. How does it tell that the preferred given name 
is Andrew, instead of John?

> Note that this is simply another use case for the more general problem of 
> indicating preference among many instances of a property.

Not exactly. N:Mabbett;Andrew,John is a single property and the preference is 
among the components (either "Andrew" or "John").
I didn't propose it as a general preference problem because of this reason, and 
because there is/was some bias (which I don't share) against preferences .

>Let's focus on the general problem instead of just for name properties.

OK. I will try to avoid them, but think of them as syntactyical metavariables 
instead of suggested property/attribute names. The proposal in my previous mail 
could have been written as "either define an integer-valued attribute for the N 
property for representing which name is preferred, or a new property whose value 
may be used as a  replacement for all given names." I think it was clearer with 
some examples, and I needed a property name for the examples.

> 4. #2 + pecify that ordering matters.

I prefer #3 because it allows properties with no preference specified and 
properties with equal preferences.
On the other hand, #4 would impose a non-strict ordering of preference (e.g: 
greater or equal than).

Best Regards

Javier

---

From: Simon Perreault <[email-masked]>
Date: Sun, 27 Jul 2008 14:49:31 +0100

Javier Godoy wrote:
> I don't understand your approach. How does it tell that the preferred 
> given name is Andrew, instead of John?

It is I that did not understand what you were trying to achieve. Never 
mind what I said.

Here's my opinion, for what it's worth: letting one specify the 
preferredness of parts of a name is a feature we don't want. There's 
almost no use case for it, and it will end up being ugly and will not 
even fulfill its purpose because it won't be generic enough. Unless 
there's a compelling use case for it with wide applicability, let's 
leave it for a potential extension.

Plus, you could use FN with an eventual generic preferredness mechanism.

>> 1. Allow PREF to be used with all properties (except those that can 
>> only appear once).
>>
> I prefer #3 because it allows properties with no preference specified 
> and properties with equal preferences.
> On the other hand, #4 would impose a non-strict ordering of preference 
> (e.g: greater or equal than).

Good point.

---

From: Andy Mabbett <[email-masked]>
Date: Sun, 27 Jul 2008 16:32:43 +0100

In message <[email-masked]>, Simon Perreault
<[email-masked]> writes

>almost no use case for it

I can see at least two sue-cases:

Firstly, to aid searching (i.e. for a search value of "Andy Mabbett",
return anything with N:Mabbett;Andrew,John, PN = Andy")

Second, suppose you inherit a number of vCard data records, say for your
new employer's clients; it will be useful to know that:

        PN = Andy

prefers to be addressed as "Andy" not "Andrew", "John" nor
"Andrew-John".

>>  I prefer #3 because it allows properties with no preference
>>specified  and properties with equal preferences.
>> On the other hand, #4 would impose a non-strict ordering of
>>preference  (e.g: greater or equal than).
>
>Good point.

+1

---

From: Andy Mabbett <[email-masked]>
Date: Sun, 27 Jul 2008 16:46:06 +0100

In message <[email-masked]>, Andy Mabbett 
<[email-masked]> writes

>I can see at least two sue-cases:

IANAL!

---

From: "Javier Godoy" <[email-masked]>
Date: Mon, 28 Jul 2008 05:56:05 -0300

> preferredness of parts of a name is a feature we don't want. There's almost no 
> use case for it, and it will end up being ugly and will not even fulfill its 
> purpose because it won't be generic enough.

Ugly? The proposed approaches were quite simple; there may be other flaws, but 
ugliness is not one of them.

On the other hand, a generic solution should allow preferences among name 
representations (not only among given names, but also combinations of last 
names, prefixes and suffixes). I though it was too much, because it would 
require repeating information which is already in the N or FN properties (then 
my proposal using an integer-valued attribute). I'm neutral about extending this 
mechanism to other name components.

> Unless there's a compelling use case for it with wide applicability, let's 

IMHO the use cases mentioned by Andy are compelling enough.  However,  f we 
write an extension document immediatly after vcardrev, this issue may be left 
out of the core spec.

> Plus, you could use FN with an eventual generic preferredness mechanism.

I thought FN was non-repeatable (issue #306). Indeed, an example of the FN 
property with PID parameter was removed in the last version of the draft because 
"[PID] MUST NOT
appear on properties that only may have one instance per vCard".

If FN were repeatable a "generic preferredness mechanism" could be used, but 
multiple FN may also require specifying which is the "complete" one.

Other possible solution (instead of allowing multiple FN or defining a new 
property) is using the NICKNAME property and a generic preference mechanism.

Example:

N:Other;A.,N.
FN:A. N. Other
NICKNAME;PREF:Nigel
NICKNAME:wiseguy

means that A. N. Other prefers to be addressed as "Nigel" (Nigel Other), and

N:Other;A.,Nigel
FN:A. Nigel Other
NICKNAME:Nigel
NICKNAME;PREF:wiseguy

means that A. N. Other prefers to be addressed as "wiseguy" (Wiseguy Other)

Javier.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 28 Jul 2008 10:05:04 +0100

Javier Godoy wrote:
> I thought FN was non-repeatable (issue #306). Indeed, an example of the 
> FN property with PID parameter was removed in the last version of the 
> draft because "[PID] MUST NOT

That's still up for discussion. If there's a compelling use case for any 
property not to be marked as non-repeatable, then it will be marked so.

> Other possible solution (instead of allowing multiple FN or defining a 
> new property) is using the NICKNAME property and a generic preference 
> mechanism.
> 
> Example:
> 
> N:Other;A.,N.
> FN:A. N. Other
> NICKNAME;PREF:Nigel
> NICKNAME:wiseguy
> 

+1